[要約] RFC 2634は、S/MIMEのための強化セキュリティサービスに関する規格であり、デジタル署名や暗号化などのセキュリティ機能を提供します。目的は、電子メールのセキュリティを向上させ、データの機密性と信頼性を確保することです。
Network Working Group P. Hoffman, Editor
Request for Comments: 2634 Internet Mail Consortium
Category: Standards Track June 1999
Enhanced Security Services for S/MIME
Status of this Memo
このメモの位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (1999). All Rights Reserved.
著作権（C）インターネット協会（1999）。全著作権所有。
This document describes four optional security service extensions for S/MIME. The services are:
この文書では、S / MIMEのための4つのオプションのセキュリティサービスの拡張機能について説明します。サービスは以下のとおりです。
- signed receipts - security labels - secure mailing lists - signing certificates
- セキュリティラベル - - 安全なメーリングリスト - 署名証明書の領収書に署名しました
The first three of these services provide functionality that is similar to the Message Security Protocol [MSP4], but are useful in many other environments, particularly business and finance. Signing certificates are useful in any environment where certificates might be transmitted with signed messages.
これらのサービスの最初の3つはメッセージセキュリティプロトコル[MSP4]と同様の機能を提供しますが、他の多くの環境、特にビジネスと金融のに有用です。署名証明書は、証明書が署名されたメッセージで送信される可能性がありますどのような環境においても有用です。
The services described here are extensions to S/MIME version 3 ([MSG] and [CERT]), and some of them can also be added to S/MIME version 2 [SMIME2]. The extensions described here will not cause an S/MIME version 3 recipient to be unable to read messages from an S/MIME version 2 sender. However, some of the extensions will cause messages created by an S/MIME version 3 sender to be unreadable by an S/MIME version 2 recipient.
【SMIME2]ここで記述されたサービスは、S / MIMEバージョン3（[MSG]と[CERT]）の拡張であり、そのうちのいくつかはまた、S / MIMEバージョン2に添加することができます。ここで説明する拡張は、S / MIMEバージョン3受信者がS / MIMEバージョン2の送信者からのメッセージを読み取ることができないことはありません。しかし、拡張のいくつかは、S / MIMEバージョン3送信者によって作成されたメッセージは、S / MIMEバージョン2受信者が読めないことになります。
This document describes both the procedures and the attributes needed for the four services. Note that some of the attributes described in this document are quite useful in other contexts and should be considered when extending S/MIME or other CMS applications.
この文書では、手順や4つのサービスのために必要な属性の両方を説明しています。この文書で説明する属性のいくつかは、他のコンテキストで非常に有用であり、S / MIMEやその他のCMSアプリケーションを拡張する際に考慮されるべきであることに注意してください。
The format of the messages are described in ASN.1:1988 [ASN1-1988].
メッセージの形式は、ASN.1に記載されている：1988 [ASN1-1988]。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [MUSTSHOULD].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります【MUSTSHOULD]に記載されているように解釈されます。
Some of the features of each service use the concept of a "triple wrapped" message. A triple wrapped message is one that has been signed, then encrypted, then signed again. The signers of the inner and outer signatures may be different entities or the same entity. Note that the S/MIME specification does not limit the number of nested encapsulations, so there may be more than three wrappings.
各サービスの機能の一部は、「トリプルラップ」メッセージの概念を使用します。トリプルラップメッセージが再度署名、暗号化された後、署名されたものです。内側と外側の署名の署名者は、異なるエンティティまたは同じエンティティであってもよいです。 S / MIME仕様は、ネストされたカプセル化の数を制限しないのでつ以上の包装が存在してもよいことに留意されたいです。
Not all messages need to be triple wrapped. Triple wrapping is used when a message must be signed, then encrypted, and then have signed attributes bound to the encrypted body. Outer attributes may be added or removed by the message originator or intermediate agents, and may be signed by intermediate agents or the final recipient.
いないすべてのメッセージはトリプルラップする必要があります。メッセージは暗号化され、その後、署名されている必要があり、その後、暗号化されたボディにバインドされた属性を締結したとき、トリプルラッピングが使用されています。外側の属性が追加または削除メッセージ発信または中間エージェントによって、中間剤または最終受信者によって署名されてもよいしてもよいです。
The inside signature is used for content integrity, non-repudiation with proof of origin, and binding attributes (such as a security label) to the original content. These attributes go from the originator to the recipient, regardless of the number of intermediate entities such as mail list agents that process the message. The signed attributes can be used for access control to the inner body. Requests for signed receipts by the originator are carried in the inside signature as well.
内部署名は、コンテンツの完全性、起源の証明と否認防止、および元のコンテンツに（例えばセキュリティラベルなどの）属性を結合するために使用されます。これらの属性に関係なく、このようなメッセージを処理するメールリスト剤としての中間エンティティの数の、発信元から受信者に進みます。署名属性は、内側本体へのアクセス制御に使用することができます。発信元によって署名された領収書の要求も内側署名で運ばれます。
The encrypted body provides confidentiality, including confidentiality of the attributes that are carried in the inside signature.
暗号化された本体は、内部署名で運ばれる属性の機密性など、機密性を提供します。
The outside signature provides authentication and integrity for information that is processed hop-by-hop, where each hop is an intermediate entity such as a mail list agent. The outer signature binds attributes (such as a security label) to the encrypted body. These attributes can be used for access control and routing decisions.
外部署名はホップバイホップ、各ホップは、メールリスト剤として中間エンティティで処理される情報の認証および完全性を提供します。外側の署名が暗号化された本体に（例えばセキュリティラベルなどの）属性を結合します。これらの属性は、アクセス制御とルーティング決定のために使用することができます。
The steps to create a triple wrapped message are:
トリプルラップメッセージを作成する手順は以下のとおりです。
2. Encapsulate the original content with the appropriate MIME Content-type headers, such as "Content-type: text/plain". An exception to this MIME encapsulation rule is that a signed receipt is not put in MIME headers.
2.このような「text / plainのコンテンツタイプ」などの適切なMIMEコンテンツタイプヘッダと元のコンテンツをカプセル化。このMIMEカプセル化規則の例外は、署名された領収書がMIMEヘッダに入れていないということです。
3. Sign the result of step 2 (the inner MIME headers and the original content). The SignedData encapContentInfo eContentType object identifier MUST be id-data. If the structure you create in step 4 is multipart/signed, then the SignedData encapContentInfo eContent MUST be absent. If the structure you create in step 4 is application/pkcs7-mime, then the SignedData encapContentInfo eContent MUST contain the result of step 2 above. The SignedData structure is encapsulated by a ContentInfo SEQUENCE with a contentType of id-signedData.
3.ステップ2（インナーMIMEヘッダと元のコンテンツ）の結果をサイン。 SignedData encapContentInfoのeContentTypeオブジェクト識別子は、IDデータでなければなりません。手順4で作成した構造は、マルチパート/署名されている場合は、SignedDataのencapContentInfo e-コンテンツが存在してはなりません。手順4で作成した構造は、アプリケーション/ PKCS7-パントマイムであれば、SignedDataのencapContentInfo e-コンテンツは、上記のステップ2の結果を含まなければなりません。 SignedData構造は、ID-たsignedDataのcontentTypeのとContentInfo配列によってカプセル化されます。
4. Add an appropriate MIME construct to the signed message from step 3 as defined in [MSG]. The resulting message is called the "inside signature".
[MSG]で定義されるように4ステップ3からの署名されたメッセージに適切なMIME構築物を追加。得られたメッセージは、「内部の署名」と呼ばれます。
- If you are signing using multipart/signed, the MIME construct added consists of a Content-type of multipart/signed with parameters, the boundary, the result of step 2 above, the boundary, a Content-type of application/pkcs7-signature, optional MIME headers (such asContent-transfer-encoding and Content-disposition), and a body part that is the result of step 3 above.
- あなたの署名/マルチパート使用して署名されている場合、追加MIME構築物は、マルチパート/パラメータを使用して署名され、境界、上記ステップ2の結果、境界、アプリケーション/ PKCS7署名のコンテンツタイプのコンテンツタイプで構成され、オプションのMIMEヘッダ（例えばasContent転送エンコード及びコンテンツ配置）、及び上記ステップ3の結果であり、身体部分。
- If you are instead signing using application/pkcs7-mime, the MIME construct added consists of a Content-type of application/pkcs7-mime with parameters, optional MIME headers (such as Content-transfer-encoding and Content-disposition), and the result of step 3 above.
- あなたが代わりにアプリケーション/ PKCS7-MIMEを使用して署名されている場合、追加MIME構築物は、パラメータ（例えば、コンテンツ転送符号化およびコンテンツ配置など）任意のMIMEヘッダを持つアプリケーション/ PKCS7-MIMEのコンテンツタイプから成り、そして上記ステップ3の結果。
5. Encrypt the result of step 4 as a single block, turning it into an application/pkcs7-mime object. The EnvelopedData encryptedContentInfo contentType MUST be id-data. The EnvelopedData structure is encapsulated by a ContentInfo SEQUENCE with a contentType of id-envelopedData. This is called the "encrypted body".
単一のブロックとして前記暗号化ステップ4の結果を、アプリケーション/ PKCS7-MIMEオブジェクトにそれを回します。 EnvelopedDataのencryptedContentInfoのcontentTypeは、IDデータでなければなりません。 EnvelopedDataの構造は、ID-EnvelopedDataのののcontentTypeと共にContentInfo配列によってカプセル化されます。これは、「暗号化されたボディ」と呼ばれています。
6. Add the appropriate MIME headers: a Content-type of application/pkcs7-mime with parameters, and optional MIME headers such as Content-transfer-encoding and Content-disposition.
パラメータを持つアプリケーション/ PKCS7-MIMEのコンテンツタイプ、及びそのようなコンテンツ転送符号化およびコンテンツ配置のような任意のMIMEヘッダ6.適切なMIMEヘッダを追加します。
7. Using the same logic as in step 3 above, sign the result of step 6 (the MIME headers and the encrypted body) as a single block
上記のステップ3と同じロジックを使用して7、単一のブロックとしてステップ6（MIMEヘッダおよび暗号化された身体）の結果に署名
8. Using the same logic as in step 4 above, add an appropriate MIME construct to the signed message from step 7. The resulting message is called the "outside signature", and is also the triple wrapped message.
8.上記のステップ4と同じロジックを使用し、ステップ7から署名されたメッセージに適切なMIME構築物を追加得られたメッセージは、「外部署名」と呼ばれ、また、トリプルラップされたメッセージです。
A triple wrapped message has many layers of encapsulation. The structure differs based on the choice of format for the signed portions of the message. Because of the way that MIME encapsulates data, the layers do not appear in order, and the notion of "layers" becomes vague.
トリプルラップメッセージは、カプセル化の多くの層を持っています。構造は、メッセージの署名された部分のためのフォーマットの選択に基づいて異なります。なぜならMIMEは、データをカプセル化する方法のため、層が順に表示されませんし、「層」の概念が曖昧になります。
There is no need to use the multipart/signed format in an inner signature because it is known that the recipient is able to process S/MIME messages (because they decrypted the middle wrapper). A sending agent might choose to use the multipart/signed format in the outer layer so that a non-S/MIME agent could see that the next inner layer is encrypted; however, this is not of great value, since all it shows the recipient is that the rest of the message is unreadable. Because many sending agents always use multipart/signed structures, all receiving agents MUST be able to interpret either multipart/signed or application/pkcs7-mime signature structures.
受信者がS / MIMEメッセージを処理することが可能であることが知られているので（それらは中央のラッパーを復号化しているため）内の署名にマルチパート/署名された形式を使用する必要がありません。送信エージェントは、非S / MIMEエージェントは次内層が暗号化されていることを見ることができるように、外側層にマルチパート/署名された形式を使用することを選択するかもしれません。すべてのそれは受信者がメッセージの残りの部分が読めないということであることを示しているので、しかし、これは、大きな価値がありません。多くの送信エージェントは常にマルチパート/署名した構造を使用しているため、すべての受信エージェントは、マルチパート/署名またはアプリケーション/ PKCS7-MIME署名構造のいずれかを解釈できなければなりません。
The format of a triple wrapped message that uses multipart/signed for both signatures is:
両方の署名にマルチパート/署名されたを使用し、トリプルラップされたメッセージの形式は次のとおりです。
[step 8] Content-type: multipart/signed;
[step 8] protocol="application/pkcs7-signature";
[step 8] boundary=outerboundary
[step 8]
[step 8] --outerboundary
[step 6] Content-type: application/pkcs7-mime; )
[step 6] smime-type=enveloped-data )
[step 6] )
[step 4] Content-type: multipart/signed; | )
[step 4] protocol="application/pkcs7-signature"; | )
[step 4] boundary=innerboundary | )
[step 4] | )
[step 4] --innerboundary | )
[step 2] Content-type: text/plain % | )
[step 2] % | ) [step 1] Original content % | ) [step 4] | ) [step 4] --innerboundary | ) [step 4] Content-type: application/pkcs7-signature | ) [step 4] | ) [step 3] inner SignedData block (eContent is missing) | ) [step 4] | ) [step 4] --innerboundary-- | ) [step 8] [step 8] --outerboundary [step 8] Content-type: application/pkcs7-signature [step 8] [step 7] outer SignedData block (eContent is missing) [step 8] [step 8] --outerboundary--
[ステップ2]％| ）[ステップ1]オリジナルコンテンツ％| ）[ステップ4] | ）[ステップ4] --innerboundary | ）[ステップ4]コンテンツタイプ：アプリケーション/ PKCS7署名| ）[ステップ4] | ）[工程3]内のSignedDataブロック（e-コンテンツが欠落しています）| ）[ステップ4] | ）[ステップ4] --innerboundary-- | ）[ステップ8] [ステップ8] --outerboundary [ステップ8]コンテンツタイプ：アプリケーション/ PKCS7署名[ステップ8] [ステップ7]外側のSignedDataブロック（e-コンテンツが欠落している）[ステップ8] [ステップ8] - -outerboundary--
% = These lines are what the inner signature is computed over. | = These lines are what is encrypted in step 5. This encrypted result is opaque and is a part of an EnvelopedData block. ) = These lines are what the outer signature is computed over.
％=これらの線は、内側署名がにわたって計算されるものです。 | =これらの線は、この暗号化された結果は不透明であり、EnvelopedDataのブロックの一部であるステップ5で暗号化されているものです。 ）=これらの線は、外側の署名がにわたって計算されるものです。
The format of a triple wrapped message that uses application/pkcs7- mime for the both signatures is:
両方の署名するためのアプリケーション/ pkcs7- MIMEを使用し、トリプルラップされたメッセージの形式は次のとおりです。
[step 8] Content-type: application/pkcs7-mime; [step 8] smime-type=signed-data [step 8] [step 7] outer SignedData block (eContent is present) O [step 6] Content-type: application/pkcs7-mime; ) O [step 6] smime-type=enveloped-data; ) O [step 6] ) O [step 4] Content-type: application/pkcs7-mime; | ) O [step 4] smime-type=signed-data | ) O [step 4] | ) O [step 3] inner SignedData block (eContent is present) I | ) O [step 2] Content-type: text/plain I | ) O [step 2] I | ) O [step 1] Original content I | ) O
[ステップ8]コンテンツタイプ：アプリケーション/ PKCS7-MIME。 [ステップ8] SMIME型=署名されたデータ[ステップ8] [ステップ7]外側のSignedDataブロック（e-コンテンツが存在している）O [ステップ6]コンテンツタイプ：アプリケーション/ PKCS7-MIME。 ）O [ステップ6] SMIME型=エンベロープデータ。 ）O [ステップ6]）O [ステップ4]コンテンツタイプ：アプリケーション/ PKCS7-MIME。 | ）O [ステップ4] SMIME型=署名されたデータ| ）O [ステップ4] | ）O [ステップ3]内のSignedDataブロック（e-コンテンツが存在している）I | ）O [ステップ2]コンテンツタイプ：text / plainのI | ）O [ステップ2] I | ）O [ステップ1] Iオリジナルコンテンツ| ）O
I = These lines are the inner SignedData block, which is opaque and contains the ASN.1 encoded result of step 2 as well as control information. | = These lines are what is encrypted in step 5. This encrypted result is opaque and is a part of an EnvelopedData block. ) = These lines are what the outer signature is computed over.
私は、これらの線は不透明であり、ステップ2のASN.1符号化された結果と同様の制御情報が含まれている内側のSignedDataブロックであります= | =これらの線は、この暗号化された結果は不透明であり、EnvelopedDataのブロックの一部であるステップ5で暗号化されているものです。 ）=これらの線は、外側の署名がにわたって計算されるものです。
O = These lines are the outer SignedData block, which is opaque and contains the ASN.1 encoded result of step 6 as well as control information.
O =これらの線は不透明であり、ステップ6のASN.1符号化された結果と同様に、制御情報を含む外側のSignedDataブロックです。
The first three security services described in this document are used with triple wrapped messages in different ways. This section briefly describes the relationship of each service with triple wrapping; the other sections of the document go into greater detail.
この文書で説明した第1の3つのセキュリティサービスは、さまざまな方法でトリプルラップメッセージで使用されています。このセクションでは、簡単に三重のラッピングと各サービスの関係を説明します。文書の他のセクションでは、より詳細に入ります。
A signed receipt may be requested in any SignedData object. However, if a signed receipt is requested for a triple wrapped message, the receipt request MUST be in the inside signature, not in the outside signature. A secure mailing list agent may change the receipt policy in the outside signature of a triple wrapped message when that message is processed by the mailing list.
署名された領収書は、任意のSignedDataオブジェクトに要求することができます。署名された領収書を三重に巻き付けメッセージのために要求される場合は、領収書要求は、内部署名ではなく、外部署名していなければなりません。そのメッセージがメーリングリストによって処理されるとき、セキュアメーリングリスト剤は、トリプルラップされたメッセージの署名外側に受領ポリシーを変更することができます。
Note: the signed receipts and receipt requests described in this memo differ from those described in the work done by the IETF Receipt Notification Working Group. The output of that Working Group, when finished, is not expected to work well with triple wrapped messages as described in this document.
注意：このメモで説明する署名領収書や領収書の要求はIETF受信通知ワーキンググループによって行われた仕事に記載されているものとは異なります。終了したら、そのワーキンググループの出力は、この文書で説明したように、トリプルラップメッセージでうまく動作することが期待されていません。
A security label may be included in the signed attributes of any SignedData object. A security label attribute may be included in either the inner signature, outer signature, or both.
セキュリティラベルは、任意のSignedDataオブジェクトの署名の属性に含まれていてもよいです。セキュリティ・ラベル属性は内側の署名、外側の署名、または両方に含まれてもよいです。
The inner security label is used for access control decisions related to the plaintext original content. The inner signature provides authentication and cryptographically protects the integrity of the original signer's security label that is in the inside body. This strategy facilitates the forwarding of messages because the original signer's security label is included in the SignedData block which can be forwarded to a third party that can verify the inner signature which will cover the inner security label. The confidentiality security service can be applied to the inner security label by encrypting the entire inner SignedData block within an EnvelopedData block.
内側のセキュリティラベルは平文オリジナルコンテンツに関連するアクセス制御の決定のために使用されています。内側の署名は、認証を提供し、暗号内側体であるオリジナルの署名者のセキュリティ・ラベルの完全性を保護します。オリジナルの署名者のセキュリティラベルは、内部セキュリティラベルをカバーするインナー署名を検証することができ、第三者に転送することができるのSignedDataブロックに含まれているため、この戦略は、メッセージの転送を容易にします。機密性のセキュリティサービスがEnvelopedDataのブロック内の全体の内側のSignedDataブロックを暗号化することによって、内部のセキュリティラベルに適用することができます。
A security label may also be included in the signed attributes of the outer SignedData block which will include the sensitivities of the encrypted message. The outer security label is used for access control and routing decisions related to the encrypted message. Note that a security label attribute can only be used in a signedAttributes block. An eSSSecurityLabel attribute MUST NOT be used in an EnvelopedData or unsigned attributes.
セキュリティ・ラベルはまた、暗号化されたメッセージの感度を含む外側のSignedDataブロックの署名された属性に含まれていてもよいです。外側のセキュリティラベルは、アクセス制御と暗号化されたメッセージに関連するルーティングの決定のために使用されています。セキュリティラベル属性はsignedAttributesのブロックでのみ使用できることに注意してください。 eSSSecurityLabel属性はEnvelopedDataのか、署名属性で使用してはいけません。
Secure mail list message processing depends on the structure of S/MIME layers present in the message sent to the mail list agent. The mail list agent never changes the data that was hashed to form the inner signature, if such a signature is present. If an outer signature is present, then the agent will modify the data that was hashed to form that outer signature. In all cases, the agent adds or updates an mlExpansionHistory attribute to document the agent's processing, and ultimately adds or replaces the outer signature on the message to be distributed.
安全なメールリストメッセージ処理は、メールリストエージェントに送信されるメッセージ内に存在するS / MIME層の構造に依存します。メールリストエージェントは、このような署名が存在する場合、内側の署名を形成するためにハッシュされたデータを変更することはありません。外側の署名が存在する場合、エージェントは、その外側の署名を形成するためにハッシュされたデータを変更します。全ての場合において、薬剤は、追加または更新エージェントの処理を文書化するmlExpansionHistory属性を、そして最終的に配信されるメッセージに、外側の署名を追加または置き換え。
Certain attributes should be placed in the inner or outer SignedData message; some attributes can be in either. Further, some attributes must be signed, while signing is optional for others, and some attributes must not be signed. ESS defines several types of attributes. ContentHints and ContentIdentifier MAY appear in any list of attributes. contentReference, equivalentLabel, eSSSecurityLabel and mlExpansionHistory MUST be carried in a SignedAttributes or AuthAttributes type, and MUST NOT be carried in a UnsignedAttributes, UnauthAttributes or UnprotectedAttributes type. msgSigDigest, receiptRequest and signingCertificate MUST be carried in a SignedAttributes, and MUST NOT be carried in a AuthAttributes, UnsignedAttributes, UnauthAttributes or UnprotectedAttributes type.
特定の属性は、内側または外側のSignedDataメッセージ中に配置されるべきです。いくつかの属性のいずれかにすることができます。さらに、署名は他の人のためのオプションである一方で、いくつかの属性は、署名しなければならない、といくつかの属性が署名してはいけません。 ESSは、属性のいくつかのタイプを定義します。 ContentHintsとContentIdentifierは属性のいずれかのリストに表示されることがあります。 contentReference、equivalentLabel、eSSSecurityLabelとmlExpansionHistoryはsignedAttributesのかAuthAttributesタイプで運ばなければならない、とUnsignedAttributes、UnauthAttributesまたはUnprotectedAttributesタイプで運ばれてはなりません。 msgSigDigest、receiptRequestとsigningCertificateはsignedAttributesの中で行わなければならない、とAuthAttributes、UnsignedAttributes、UnauthAttributesまたはUnprotectedAttributesタイプで運ばれてはなりません。
The following table summarizes the recommendation of this profile. In the OID column, [ESS] indicates that the attribute is defined in this document.
次の表は、このプロファイルの勧告をまとめました。 OID列で、[ESS]は属性がこの文書で定義されていることを示しています。
| |Inner or |
Attribute |OID |outer |Signed
------------------|----------------------------- |----------|--------
contentHints |id-aa-contentHint [ESS] |either |MAY
contentIdentifier |id-aa-contentIdentifier [ESS] |either |MAY
contentReference |id-aa-contentReference [ESS] |either |MUST
contentType |id-contentType [CMS] |either |MUST
counterSignature |id-countersignature [CMS] |either |MUST NOT
equivalentLabel |id-aa-equivalentLabels [ESS] |either |MUST
eSSSecurityLabel |id-aa-securityLabel [ESS] |either |MUST
messageDigest |id-messageDigest [CMS] |either |MUST
msgSigDigest |id-aa-msgSigDigest [ESS] |inner only|MUST
mlExpansionHistory|id-aa-mlExpandHistory [ESS] |outer only|MUST
receiptRequest |id-aa-receiptRequest [ESS] |inner only|MUST
signingCertificate|id-aa-signingCertificate [ESS]|either |MUST
signingTime |id-signingTime [CMS] |either |MUST
smimeCapabilities |sMIMECapabilities [MSG] |either |MUST
sMIMEEncryption-
KeyPreference |id-aa-encrypKeyPref [MSG] |either |MUST
CMS defines signedAttrs as a SET OF Attribute and defines unsignedAttrs as a SET OF Attribute. ESS defines the contentHints, contentIdentifier, eSSecurityLabel, msgSigDigest, mlExpansionHistory, receiptRequest, contentReference, equivalentLabels and signingCertificate attribute types. A signerInfo MUST NOT include multiple instances of any of the attribute types defined in ESS. Later sections of ESS specify further restrictions that apply to the receiptRequest, mlExpansionHistory and eSSecurityLabel attribute types.
CMSは、属性の集合としてsignedAttrsを定義し、属性の集合としてunsignedAttrsを定義します。 ESSはcontentHints、contentIdentifier、eSSecurityLabel、msgSigDigest、mlExpansionHistory、receiptRequest、contentReference、equivalentLabelsとsigningCertificate属性タイプを定義します。 SignerInfoはESSで定義された属性タイプのいずれかの複数のインスタンスを含んではいけません。 ESSのその後のセクションでは、属性タイプreceiptRequest、mlExpansionHistoryとeSSecurityLabelに適用されるさらなる制限を指定します。
CMS defines the syntax for the signed and unsigned attributes as "attrValues SET OF AttributeValue". For all of the attribute types defined in ESS, if the attribute type is present in a signerInfo, then it MUST only include a single instance of AttributeValue. In other words, there MUST NOT be zero, or multiple, instances of AttributeValue present in the attrValues SET OF AttributeValue.
CMSは、「AttributeValueの一連のattrValues」として符号付きと符号なしの属性の構文を定義します。属性タイプは、のSignerInfo中に存在する場合、ESSで定義された属性タイプの全てについては、それだけAttributeValueの単一のインスタンスを含まなければなりません。換言すれば、AttributeValueのOF attrValuesセット内AttributeValueの存在のゼロ、または複数のインスタンスがあってはなりません。
If a counterSignature attribute is present, then it MUST be included in the unsigned attributes. It MUST NOT be included in the signed attributes. The only attributes that are allowed in a counterSignature attribute are counterSignature, messageDigest, signingTime, and signingCertificate.
副署属性が存在する場合、それは未署名の属性に含まれなければなりません。これは、署名した属性に含まれてはいけません。副署属性で許可されている属性だけが副署、するMessageDigest、signingTime、およびsigningCertificateです。
Note that the inner and outer signatures are usually those of different senders. Because of this, the same attribute in the two signatures could lead to very different consequences.
内側と外側の署名は、通常、異なる送信者のものであることに留意されたいです。このため、2人の署名で同じ属性は非常に異なる結果を招く可能性があります。
ContentIdentifier is an attribute (OCTET STRING) used to carry a unique identifier assigned to the message.
ContentIdentifierは、メッセージに割り当てられた固有の識別子を運ぶために使用される属性（オクテット文字列）です。
Some security gateways sign messages that pass through them. If the message is any type other than a signedData type, the gateway has only one way to sign the message: by wrapping it with a signedData block and MIME headers. If the message to be signed by the gateway is a signedData message already, the gateway can sign the message by inserting a signerInfo into the signedData block.
一部のセキュリティ・ゲートウェイは、それらを通過するメッセージに署名します。メッセージがたsignedDataタイプ以外のタイプの場合、ゲートウェイは、メッセージに署名する唯一の方法がありますたsignedDataブロックとMIMEヘッダとそれを包むことによって。ゲートウェイによって署名されるべきメッセージが既にたsignedDataメッセージである場合、ゲートウェイはたsignedDataブロックへのSignerInfoを挿入することにより、メッセージに署名することができます。
The main advantage of a gateway adding a signerInfo instead of wrapping the message in a new signature is that the message doesn't grow as much as if the gateway wrapped the message. The main disadvantage is that the gateway must check for the presence of certain attributes in the other signerInfos and either omit or copy those attributes.
ゲートウェイの主な利点のSignerInfoを添加する代わりに、新しい署名にメッセージをラップは、メッセージがゲートウェイがメッセージを包んだかのように同じくらい成長しないということです。主な欠点は、ゲートウェイが他signerInfosに特定の属性の存在を確認し、それらの属性を省略するか、コピーのいずれかでなければならないことです。
If a gateway or other processor adds a signerInfo to an existing signedData block, it MUST copy the mlExpansionHistory and eSSSecurityLabel attributes from other signerInfos. This helps ensure that the recipient will process those attributes in a signerInfo that it can verify.
ゲートウェイまたは他のプロセッサは、既存たsignedDataブロックへのSignerInfoを追加する場合、それはmlExpansionHistoryとeSSSecurityLabelが他signerInfosから属性をコピーする必要があります。これは、受信者がそれを確認することができることのSignerInfoにそれらの属性を処理するようになります。
Note that someone may in the future define an attribute that must be present in each signerInfo of a signedData block in order for the signature to be processed. If that happens, a gateway that inserts signerInfos and doesn't copy that attribute will cause every message with that attribute to fail when processed by the recipient. For this reason, it is safer to wrap messages with new signatures than to insert signerInfos.
誰かが将来的に署名を処理するためにたsignedDataブロックの各々のSignerInfo中に存在しなければならない属性を定義することができることに留意されたいです。その場合は、signerInfosを挿入し、その属性をコピーしないゲートウェイは、受信者によって処理されたときにその属性を持つすべてのメッセージが失敗します。 signerInfosを挿入するよりも、このような理由から、新しい署名付きのメッセージをラップする方が安全です。
The object identifiers for many of the objects described in this memo are found in [CMS], [MSG], and [CERT]. Other object identifiers used in S/MIME can be found in the registry kept at <http://www.imc.org/ietf-smime/oids.html>. When this memo moves to standards track within the IETF, it is intended that the IANA will maintain this registry.
このメモで記述されたオブジェクトの多くのオブジェクト識別子が[CMS]に見出される、[MSG]、および[CERT]。 S / MIMEで使用される他のオブジェクト識別子は、レジストリで見つけることができる<http://www.imc.org/ietf-smime/oids.html>に保ちました。標準にこのメモの移動はIETF内に追跡すると、IANAは、このレジストリを維持することが意図されています。
Returning a signed receipt provides to the originator proof of delivery of a message, and allows the originator to demonstrate to a third party that the recipient was able to verify the signature of the original message. This receipt is bound to the original message through the signature; consequently, this service may be requested only if a message is signed. The receipt sender may optionally also encrypt a receipt to provide confidentiality between the receipt sender and the receipt recipient.
署名された領収書を返すことは、メッセージの配信の発信証明を提供し、発信者が受信者は、元のメッセージの署名を確認することができた第三者に証明することを可能にします。この領収書は、署名を介して元のメッセージに結合されます。結果的に、このサービスは、メッセージが署名されている場合にのみ要求することができます。レシートの送信者はまた、必要に応じてレシートの送信者と受信先との間の機密性を提供するために領収書を暗号化することができます。
The originator of a message may request a signed receipt from the message's recipients. The request is indicated by adding a receiptRequest attribute to the signedAttributes field of the SignerInfo object for which the receipt is requested. The receiving user agent software SHOULD automatically create a signed receipt when requested to do so, and return the receipt in accordance with mailing list expansion options, local security policies, and configuration options.
メッセージの発信者は、メッセージの受信者から署名付き領収書を要求することができます。要求は、領収書が要求されているのSignerInfoオブジェクトのsignedAttributesのフィールドにreceiptRequest属性を追加することによって示されます。受信ユーザエージェントソフトウェアは自動的にそうするように要求されたときに署名した領収書を作成し、メーリングリストの拡張オプション、ローカルセキュリティポリシー、およびコンフィギュレーションオプションに従って領収書を返すべきです。
Because receipts involve the interaction of two parties, the terminology can sometimes be confusing. In this section, the "sender" is the agent that sent the original message that included a request for a receipt. The "receiver" is the party that received that message and generated the receipt.
領収書は、両当事者の相互作用を伴うので、専門用語は時々混乱することができます。このセクションでは、「送信者」は、領収書を求める要求が含まれ、元のメッセージを送信した薬剤です。 「受信機」は、そのメッセージを受信し、領収書を生成した当事者です。
The steps in a typical transaction are:
典型的なトランザクションの手順は次のとおりです。
1. Sender creates a signed message including a receipt request attribute (Section 2.2).
1.送信者は、受信要求属性（セクション2.2）を含む署名されたメッセージを作成します。
2. Sender transmits the resulting message to the recipient or recipients.
2.送信者は、受信者または受信者に結果のメッセージを送信します。
3. Recipient receives message and determines if there is a valid signature and receipt request in the message (Section 2.3).
3.受信者は、メッセージを受信し、メッセージ（セクション2.3）で有効な署名と受信要求があるかどうかを判定する。
5. Recipient transmits the resulting signed receipt message to the sender (Section 2.5).
5.受信者は、送信者（セクション2.5）に、得られた署名された受信メッセージを送信します。
6. Sender receives the message and validates that it contains a signed receipt for the original message (Section 2.6). This validation relies on the sender having retained either a copy of the original message or information extracted from the original message.
6.送信者は、メッセージを受信し、元のメッセージ（セクション2.6）のために署名している領収書が含まれていることを検証します。この検証は、元のメッセージから抽出された元のメッセージまたは情報のコピーのいずれかを保持した送信者に依存しています。
The ASN.1 syntax for the receipt request is given in Section 2.7; the ASN.1 syntax for the receipt is given in Section 2.8.
領収書の要求のためのASN.1構文は2.7節で与えられています。領収書のためのASN.1構文は2.8節で与えられています。
Note that a sending agent SHOULD remember when it has sent a receipt so that it can avoid re-sending a receipt each time it processes the message.
送信エージェントは、それが再送信をレシートにそれがメッセージを処理するたびに避けることができるように、それは領収書を送信した際に忘れてはならないことに注意してください。
A receipt request can indicate that receipts be sent to many places, not just to the sender (in fact, the receipt request might indicate that the receipts should not even go to the sender). In order to verify a receipt, the recipient of the receipt must be the originator or a recipient of the original message. Thus, the sender SHOULD NOT request that receipts be sent to anyone who does not have an exact copy of the message.
領収書要求は、領収書が（実際には、領収書の要求は、領収書も送信者に行くべきではないことを示している可能性があります）だけでなく、送信者に、多くの場所に送ることができることを示しています。領収書を確認するために、領収書の受信者は、発信者または元のメッセージの受信者でなければなりません。したがって、送信者は、領収書がメッセージの正確なコピーを持っていない人に送信されることを要求すべきでありません。
Multi-layer S/MIME messages may contain multiple SignedData layers. However, receipts may be requested only for the innermost SignedData layer in a multi-layer S/MIME message, such as a triple wrapped message. Only one receiptRequest attribute can be included in the signedAttributes of a SignerInfo.
多層S / MIMEメッセージは、複数のSignedData層を含んでいてもよいです。しかし、領収書は、トリプルラップされたメッセージのように、唯一の多層S / MIMEメッセージ内の最も内側のSignedData層のために要求されてもよいです。一つだけreceiptRequest属性のSignerInfoのsignedAttributesの中に含ませることができます。
A ReceiptRequest attribute MUST NOT be included in the attributes of a SignerInfo in a SignedData object that encapsulates a Receipt content. In other words, the receiving agent MUST NOT request a signed receipt for a signed receipt.
ReceiptRequest属性は、領収書の内容をカプセル化するSignedDataオブジェクト内のSignerInfoの属性に含まれてはいけません。換言すれば、受信エージェントは、署名された領収書のために署名している領収書を要求してはいけません。
A sender requests receipts by placing a receiptRequest attribute in the signed attributes of a signerInfo as follows:
送信者は、次のようにのSignerInfoの署名属性にreceiptRequest属性を置くことによって、領収書を要求します。
2. A signed content identifier for the message is created and assigned to the signedContentIdentifier field. The signedContentIdentifier is used to associate the signed receipt with the message requesting the signed receipt.
メッセージが作成され、signedContentIdentifierフィールドに割り当てられている2. Aは、コンテンツ識別子を署名しました。 signedContentIdentifierは、署名された領収書を要求するメッセージで署名された領収書を関連付けるために使用されます。
3. The entities requested to return a signed receipt are noted in the receiptsFrom field.
3.署名した領収書を返すように要求されたエンティティはreceiptsFrom欄に記載されています。
4. The message originator MUST populate the receiptsTo field with a GeneralNames for each entity to whom the recipient should send the signed receipt. If the message originator wants the recipient to send the signed receipt to the originator, then the originator MUST include a GeneralNames for itself in the receiptsTo field. GeneralNames is a SEQUENCE OF GeneralName. receiptsTo is a SEQUENCE OF GeneralNames in which each GeneralNames represents an entity. There may be multiple GeneralName instances in each GeneralNames. At a minimum, the message originator MUST populate each entity's GeneralNames with the address to which the signed receipt should be sent. Optionally, the message originator MAY also populate each entity's GeneralNames with other GeneralName instances (such as directoryName).
4.メッセージの発信者は、受信者が署名した領収書を送信する必要があります誰に各エンティティのGeneralNamesでreceiptsToフィールドを移入する必要があります。メッセージの発信元が受信者が発信元に署名した領収書を送信したい場合には、発信者はreceiptsTo分野における自体のGeneralNamesを含まなければなりません。 GeneralNamesはいるGeneralNameのシーケンスです。 receiptsTo各GeneralNamesエンティティを表しているGeneralNamesのシーケンスです。各GeneralNames内に複数のGeneralNameインスタンスがあるかもしれません。最低でも、メッセージの発信元は署名領収書が送らすべきアドレスで各エンティティのGeneralNamesを移入する必要があります。必要に応じて、メッセージの発信者は、（例えばdirectoryNameでのような）他のGeneralNameインスタンスと各エンティティのGeneralNamesを移入するかもしれません。
5. The completed receiptRequest attribute is placed in the signedAttributes field of the SignerInfo object.
5.完成receiptRequest属性はのSignerInfoオブジェクトのsignedAttributesのフィールドに置かれています。
There can be multiple SignerInfos within a SignedData object, and each SignerInfo may include signedAttributes. Therefore, a single SignedData object may include multiple SignerInfos, each SignerInfo having a receiptRequest attribute. For example, an originator can send a signed message with two SignerInfos, one containing a DSS signature, the other containing an RSA signature.
そこSignedDataオブジェクト内の複数SignerInfosすることができ、それぞれのSignerInfoはsignedAttributesのを含んでいてもよいです。したがって、単一のSignedDataオブジェクトは、それぞれのSignerInfoがreceiptRequest属性を有する、複数SignerInfosを含むことができます。例えば、発信者は、二つのSignerInfos、DSS署名を含有するもの、他方はRSA署名を含んで署名されたメッセージを送信することができます。
Each recipient SHOULD return only one signed receipt.
各受信者は、唯一の署名領収書を返すべきです。
Not all of the SignerInfos need to include receipt requests, but in all of the SignerInfos that do contain receipt requests, the receipt requests MUST be identical.
ないSignerInfosの全ては、領収書の要求を含める必要がありますが、領収書要求が含まれていませんSignerInfosの全てに、領収書要求は同一でなければなりません。
The sending agent MUST retain one or both of the following items to support the validation of signed receipts returned by the recipients.
送信エージェントは、受信者によって返された署名された領収書の検証をサポートするために、1つまたは以下の項目の両方を保持しなければなりません。
- the original signedData object requesting the signed receipt
- 署名された領収書を要求元のSignedDataオブジェクト
- the message signature digest value used to generate the original signedData signerInfo signature value and the digest value of the Receipt content containing values included in the original signedData object. If signed receipts are requested from multiple recipients, then retaining these digest values is a performance enhancement because the sending agent can reuse the saved values when verifying each returned signed receipt.
- メッセージ署名は、元たsignedDataのSignerInfo署名値と元のSignedDataオブジェクトに含まれる値を含むレシートコンテンツのダイジェスト値を生成するために使用されるダイジェスト値。署名した領収書が複数の受信者から要求された場合は、各返された署名領収書を検証する際に送信するエージェントが保存された値を再利用することができますので、これらのダイジェスト値を保持すると、パフォーマンスの強化です。
A receiptRequest is associated only with the SignerInfo object to which the receipt request attribute is directly attached. Receiving software SHOULD examine the signedAttributes field of each of the SignerInfos for which it verifies a signature in the innermost signedData object to determine if a receipt is requested. This may result in the receiving agent processing multiple receiptRequest attributes included in a single SignedData object, such as requests made from different people who signed the object in parallel.
receiptRequestのみ領収書要求属性が直接取り付けられるのSignerInfoオブジェクトに関連付けられています。ソフトウェアを受信することは、領収書が要求されているかどうかを判断するために、最も内側のSignedDataオブジェクトに署名を検証するためSignerInfosのそれぞれのsignedAttributesのフィールドを調べる必要があります。これは、複数receiptRequest属性を処理する受信エージェントをもたらすことができるように並列にオブジェクトを締結異なる人々から作られた要求として、単一のSignedDataオブジェクトに含まれます。
Before processing a receiptRequest signedAttribute, the receiving agent MUST verify the signature of the SignerInfo which covers the receiptRequest attribute. A recipient MUST NOT process a receiptRequest attribute that has not been verified. Because all receiptRequest attributes in a SignedData object must be identical, the receiving application fully processes (as described in the following paragraphs) the first receiptRequest attribute that it encounters in a SignerInfo that it verifies, and it then ensures that all other receiptRequest attributes in signerInfos that it verifies are identical to the first one encountered. If there are verified ReceiptRequest attributes which are not the same, then the processing software MUST NOT return any signed receipt. A signed receipt SHOULD be returned if any signerInfo containing a receiptRequest attribute can be validated, even if other signerInfos containing the same receiptRequest attribute cannot be validated because they are signed using an algorithm not supported by the receiving agent.
receiptRequest signedAttributeを処理する前に、受信エージェントはreceiptRequest属性をカバーするのSignerInfoの署名を検証しなければなりません。受信者が確認されていないreceiptRequest属性を処理してはいけません。 receiptRequestはSignedDataオブジェクトの属性全て同一である必要があり、受信側アプリケーション完全プロセス（以下の段落で説明したように）第一receiptRequestは、それが検証することのSignerInfoに遭遇する属性、それは他のすべてのreceiptRequestがsignerInfosの属性ことを確実にするためそれは確認していることに遭遇する最初のものと同じです。が確認されている場合ReceiptRequestは同じではありませんどの属性が、その後、処理ソフトウェアは、すべての署名領収書を返してはなりません。 receiptRequest属性を含む任意のSignerInfoを検証することができれば署名された領収書は、それらが受信エージェントによってサポートされていないアルゴリズムを使用して署名されているため、同じreceiptRequest属性を含む他signerInfosが検証できない場合であっても、返されるべきです。
If a receiptRequest attribute is absent from the signed attributes, then a signed receipt has not been requested from any of the message recipients and MUST NOT be created. If a receiptRequest attribute is present in the signed attributes, then a signed receipt has been requested from some or all of the message recipients. Note that in some cases, a receiving agent might receive two almost-identical messages, one with a receipt request and the other without one. In this case, the receiving agent SHOULD send a signed receipt for the message that requests a signed receipt.
receiptRequest属性は署名の属性に存在しない場合には、署名した領収書は、メッセージ受信者のいずれかから要求されていないと作成されてはなりません。 receiptRequest属性が署名した属性に存在している場合は、署名領収書は、メッセージ受信者の一部または全てから要求されています。いくつかのケースでは、受信エージェントは、2つのほとんど同一のメッセージ、領収書要求に1つずつのない他を受ける可能性があることに注意してください。この場合、受信エージェントは、署名された領収書を要求するメッセージの署名された領収書を送るべきです。
If a receiptRequest attribute is present in the signed attributes, the following process SHOULD be used to determine if a message recipient has been requested to return a signed receipt.
receiptRequest属性が署名した属性に存在している場合は、次のプロセスは、メッセージ受信者が署名した領収書を返すように要求されているかどうかを判断するために使用されるべきです。
1. If an mlExpansionHistory attribute is present in the outermost signedData block, do one of the following two steps, based on the absence or presence of mlReceiptPolicy:
1. mlExpansionHistory属性はmlReceiptPolicyの有無に基づいて、次の2つの手順のいずれかを実行し、最も外側たsignedDataブロックに存在する場合：
1.1. If an mlReceiptPolicy value is absent from the last MLData
element, a Mail List receipt policy has not been specified
and the processing software SHOULD examine the
receiptRequest attribute value to determine if a receipt
should be created and returned.
1.2. If an mlReceiptPolicy value is present in the last MLData element, do one of the following two steps, based on the value of mlReceiptPolicy:
1.2. mlReceiptPolicy値は、最後のMLData要素に存在する場合、mlReceiptPolicyの値に基づいて、次の2つの手順のいずれかを実行します。
1.2.1. If the mlReceiptPolicy value is none, then the receipt
policy of the Mail List supersedes the originator's
request for a signed receipt and a signed receipt MUST
NOT be created.
1.2.2. If the mlReceiptPolicy value is insteadOf or inAdditionTo, the processing software SHOULD examine the receiptsFrom value from the receiptRequest attribute to determine if a receipt should be created and returned. If a receipt is created, the insteadOf and inAdditionTo fields identify entities that SHOULD be sent the receipt instead of or in addition to the originator.
1.2.2. mlReceiptPolicy値がinsteadOfかinAdditionToであれば、処理ソフトウェアは、領収書が作成され、返されるべきかどうかを決定するためにreceiptRequest属性からreceiptsFrom値を調べる必要があります。領収書が作成されている場合は、insteadOfとinAdditionToフィールドは、代わりに、または発信元に加えて、領収書を送ってくださいエンティティを識別します。
2. If the receiptsFrom value of the receiptRequest attribute allOrFirstTier, do one of the following two steps based on the value of allOrFirstTier.
2. receiptRequest属性allOrFirstTierのreceiptsFrom値であれば、allOrFirstTierの値に基づいて、次の2つの手順のいずれかを実行します。
2.1. If the value of allOrFirstTier is allReceipts, then a signed
receipt SHOULD be created.
2.2. If the value of allOrFirstTier is firstTierRecipients, do one of the following two steps based on the presence of an mlExpansionHistory attribute in an outer signedData block:
2.2. allOrFirstTierの値がfirstTierRecipientsであれば、外側たsignedDataブロックのmlExpansionHistory属性の存在に基づいて、次の2つの手順のいずれかを実行します。
2.2.1. If an mlExpansionHistory attribute is present, then
this recipient is not a first tier recipient and a
signed receipt MUST NOT be created.
2.2.2. If an mlExpansionHistory attribute is not present, then a signed receipt SHOULD be created.
2.2.2. mlExpansionHistory属性が存在しない場合、署名領収書を作成する必要があります。
3. If the receiptsFrom value of the receiptRequest attribute is a receiptList:
3. receiptRequest属性のreceiptsFrom値はreceiptListの場合：
3.1. If receiptList contains one of the GeneralNames of the
recipient, then a signed receipt SHOULD be created.
3.2. If receiptList does not contain one of the GeneralNames of the recipient, then a signed receipt MUST NOT be created.
3.2. receiptListは、受信者のGeneralNamesのいずれかが含まれていない場合は、署名領収書を作成してはなりません。
A flow chart for the above steps to be executed for each signerInfo for which the receiving agent verifies the signature would be:
受信エージェントは、署名があろう検証するための各のSignerInfoのために実行される上記の手順のフローチャート。
0. Receipt Request attribute present? YES -> 1. NO -> STOP 1. Has mlExpansionHistory in outer signedData? YES -> 1.1. NO -> 2. 1.1. mlReceiptPolicy absent? YES -> 2. NO -> 1.2. 1.2. Pick based on value of mlReceiptPolicy. none -> 1.2.1. insteadOf or inAdditionTo -> 1.2.2. 1.2.1. STOP. 1.2.2. Examine receiptsFrom to determine if a receipt should be created, create it if required, send it to recipients designated by mlReceiptPolicy, then -> STOP. 2. Is value of receiptsFrom allOrFirstTier? YES -> Pick based on value of allOrFirstTier. allReceipts -> 2.1. firstTierRecipients -> 2.2. NO -> 3. 2.1. Create a receipt, then -> STOP. 2.2. Has mlExpansionHistory in the outer signedData block? YES -> 2.2.1. NO -> 2.2.2. 2.2.1. STOP. 2.2.2. Create a receipt, then -> STOP. 3. Is receiptsFrom value of receiptRequest a receiptList? YES -> 3.1. NO -> STOP. 3.1. Does receiptList contain the recipient? YES -> Create a receipt, then -> STOP. NO -> 3.2. 3.2. STOP.
0領収書の要求が存在属性？ YES - > 1. NO - > STOP 1.アウターたsignedDataでmlExpansionHistoryていますか？ YES - > 1.1。 NO - > 2. 1.1。 mlReceiptPolicyの不在？ YES - > 2. NO - > 1.2。 1.2。 mlReceiptPolicyの値に基づいて選択してください。なし - > 1.2.1。 insteadOfまたはinAdditionTo - > 1.2.2。 1.2.1。やめる。 1.2.2。その後、mlReceiptPolicyで指定した受信者に送信し、必要であれば、それを作成し、領収書を作成する必要があるかどうかを判断するためにreceiptsFromを調べ - > STOP。 2. receiptsFrom allOrFirstTierの値はありますか？ YES - > allOrFirstTierの値に基づいて選択してください。 allReceipts - > 2.1。 firstTierRecipients - > 2.2。 NO - > 3. 2.1。 > STOP - を、その後、領収書を作成します。 2.2。 mlExpansionHistoryは、外側たsignedDataブロックにいますか？ YES - > 2.2.1。 NO - > 2.2.2。 2.2.1。やめる。 2.2.2。 > STOP - を、その後、領収書を作成します。 3. receiptRequest receiptListのreceiptsFromの値はありますか？ YES - > 3.1。 NO - > STOP。 3.1。 receiptListは、受信者が含まれていますか？ YES - >領収書を作成し、それから - > STOP。 NO - > 3.2。 3.2。やめる。
A signed receipt is a signedData object encapsulating a Receipt content (also called a "signedData/Receipt"). Signed receipts are created as follows:
署名された領収書は、（また、「たsignedData /領収書」と呼ばれる）受領コンテンツをカプセル化するSignedDataオブジェクトです。以下のように署名された領収書が作成されます。
1. The signature of the original signedData signerInfo that includes the receiptRequest signed attribute MUST be successfully verified before creating the signedData/Receipt.
1. receiptRequest署名された属性を含むオリジナルたsignedDataのSignerInfoの署名は、正常たsignedData /領収書を作成する前に確認する必要があります。
1.1. The content of the original signedData object is digested as
described in [CMS]. The resulting digest value is then
compared with the value of the messageDigest attribute
included in the signedAttributes of the original signedData
signerInfo. If these digest values are different, then the
signature verification process fails and the
signedData/Receipt MUST NOT be created.
1.2. The ASN.1 DER encoded signedAttributes (including messageDigest, receiptRequest and, possibly, other signed attributes) in the original signedData signerInfo are digested as described in [CMS]. The resulting digest value, called msgSigDigest, is then used to verify the signature of the original signedData signerInfo. If the signature verification fails, then the signedData/Receipt MUST NOT be created.
1.2. [CMS]で説明したように、オリジナルたsignedDataのSignerInfoで（おそらくするMessageDigest、receiptRequestと、他の署名された属性を含む）ASN.1のDER符号化されたsignedAttributesのが消化されます。 msgSigDigest呼ば得られたダイジェスト値が、元たsignedDataのSignerInfoの署名を検証するために使用されます。署名検証に失敗した場合は、たsignedData /領収書を作成してはなりません。
2.2. The object identifier from the contentType attribute included in the original signedData signerInfo that includes the receiptRequest attribute is copied into the Receipt contentType.
2.2. contentType属性からオブジェクト識別子はreceiptRequest属性がレシートのcontentTypeにコピーされたsignedData含む元のSignerInfoに含まれます。
2.3. The original signedData signerInfo receiptRequest signedContentIdentifier is copied into the Receipt signedContentIdentifier.
2.3. オリジナルたsignedDataのSignerInfo receiptRequest signedContentIdentifierはレシートsignedContentIdentifierにコピーされます。
2.4. The signature value from the original signedData signerInfo that includes the receiptRequest attribute is copied into the Receipt originatorSignatureValue.
2.4. receiptRequest属性を含むオリジナルたsignedDataのSignerInfoの署名値は、レシートoriginatorSignatureValueにコピーされます。
3. The Receipt structure is ASN.1 DER encoded to produce a data stream, D1.
3.受領構造が、D1をデータ・ストリームを生成する符号化されたASN.1 DERです。
4. D1 is digested. The resulting digest value is included as the messageDigest attribute in the signedAttributes of the signerInfo which will eventually contain the signedData/Receipt signature value.
4. D1が消化されます。得られたダイジェスト値は、最終的にたsignedData /領収書の署名値を含むことになるのSignerInfoのsignedAttributesの中のMessageDigest属性として含まれます。
5. The digest value (msgSigDigest) calculated in Step 1 to verify the signature of the original signedData signerInfo is included as the msgSigDigest attribute in the signedAttributes of the signerInfo which will eventually contain the signedData/Receipt signature value.
5.オリジナルたsignedDataのSignerInfoの署名を検証するために、ステップ1で算出したダイジェスト値（msgSigDigest）は結局たsignedData /領収書の署名値を含むことになるのSignerInfoのsignedAttributesの中msgSigDigest属性として含まれます。
6. A contentType attribute including the id-ct-receipt object identifier MUST be created and added to the signed attributes of the signerInfo which will eventually contain the signedData/Receipt signature value.
ID-CT-レシートオブジェクト識別子を含む6 A contentType属性が作成され、結局たsignedData /領収書の署名値を含むことになるのSignerInfoの署名された属性に加えなければなりません。
7. A signingTime attribute indicating the time that the signedData/Receipt is signed SHOULD be created and added to the signed attributes of the signerInfo which will eventually contain the signedData/Receipt signature value. Other attributes (except receiptRequest) may be added to the signedAttributes of the signerInfo.
たsignedData /領収書が署名されている時間を示す7. A signingTime属性が作成され、結局たsignedData /領収書の署名値を含むことになるのSignerInfoの署名された属性に追加されるべきです。 （receiptRequest除く）他の属性は、のSignerInfoのsignedAttributesのに加えてもよいです。
8. The signedAttributes (messageDigest, msgSigDigest, contentType and, possibly, others) of the signerInfo are ASN.1 DER encoded and digested as described in [CMS]. The resulting digest value is used to calculate the signature value which is then included in the signedData/Receipt signerInfo.
8のSignerInfoのsignedAttributesの（おそらくするMessageDigest、msgSigDigest、のcontentType及び、その他）[CMS]で説明されるように符号化され、消化されたASN.1のDERです。得られたダイジェスト値は、次にたsignedData /領収書のSignerInfoに含まれる署名値を計算するために使用されます。
9. The ASN.1 DER encoded Receipt content MUST be directly encoded within the signedData encapContentInfo eContent OCTET STRING defined in [CMS]. The id-ct-receipt object identifier MUST be included in the signedData encapContentInfo eContentType. This results in a single ASN.1 encoded object composed of a signedData including the Receipt content. The Data content type MUST NOT be used. The Receipt content MUST NOT be encapsulated in a MIME header or any other header prior to being encoded as part of the signedData object.
9. ASN.1のDER符号化された領収書の内容は、直接[CMS]で定義されたsignedData encapContentInfo e-コンテンツオクテット文字列内で符号化されなければなりません。 ID-CT-レシートオブジェクト識別子たsignedData encapContentInfoのeContentTypeに含まれなければなりません。これは、レシートコンテンツを含むたsignedDataからなる単ASN.1符号化されたオブジェクトをもたらします。データのコンテンツタイプを使用してはいけません。領収書の内容は、MIMEヘッダまたはSignedDataオブジェクトの一部として符号化される前の任意の他のヘッダでカプセル化してはいけません。
10. The signedData/Receipt is then put in an application/pkcs7-mime MIME wrapper with the smime-type parameter set to "signed-receipt". This will allow for identification of signed receipts without having to crack the ASN.1 body. The smime-type parameter would still be set as normal in any layer wrapped around this message.
10.たsignedData /領収書は、その後、「レシートを締結」に設定SMIME型パラメータを持つアプリケーション/ PKCS7-MIME MIMEラッパーに置かれます。これはASN.1の本体を解読することなく、署名された領収書の同定を可能にします。 SMIME-typeパラメータは、まだこのメッセージに巻き付けいずれの層に、通常のように設定されます。
11. If the signedData/Receipt is to be encrypted within an envelopedData object, then an outer signedData object MUST be created that encapsulates the envelopedData object, and a contentHints attribute with contentType set to the id-ct-receipt object identifier MUST be included in the outer signedData SignerInfo signedAttributes. When a receiving agent processes the outer signedData object, the presence of the id-ct-receipt OID in the contentHints contentType indicates that a signedData/Receipt is encrypted within the envelopedData object encapsulated by the outer signedData.
11.たsignedData /領収書がEnvelopedDataのオブジェクト内に暗号化される場合、外側のSignedDataオブジェクトがEnvelopedDataのオブジェクトをカプセル化すること作成する必要があり、そしてcontentHintsはcontentTypeの持つ属性は、ID-CT-レシートオブジェクト識別子にセットに含まれなければなりませんアウターたsignedDataのSignerInfo signedAttributesの。受信エージェントは外側のSignedDataオブジェクトを処理するとき、contentHintsのcontentTypeのid-CT-受信OIDの存在がたsignedData /領収書は、外側たsignedDataによって封入EnvelopedDataのオブジェクト内に暗号化されていることを示しています。
All sending agents that support the generation of ESS signed receipts MUST provide the ability to send encrypted signed receipts (that is, a signedData/Receipt encapsulated within an envelopedData). The sending agent MAY send an encrypted signed receipt in response to an envelopedData-encapsulated signedData requesting a signed receipt. It is a matter of local policy regarding whether or not the signed receipt should be encrypted. The ESS signed receipt includes the message digest value calculated for the original signedData object that requested the signed receipt. If the original signedData object was sent encrypted within an envelopedData object and the ESS signed receipt is sent unencrypted, then the message digest value calculated for the original encrypted signedData object is sent unencrypted. The responder should consider this when deciding whether or not to encrypt the ESS signed receipt.
ESSの生成をサポートするすべての送信剤は、領収書（つまり、EnvelopedDataの内に封入たsignedData /領収書）で暗号化され署名された領収書を送信する能力を提供しなければならない署名しました。送信エージェントは、署名された領収書を要求するEnvelopedDataのカプセル化たsignedDataに応じて暗号化された署名領収書を送信することができます。これは、署名された領収書を暗号化する必要があるか否かのローカルポリシーの問題です。 ESSは、領収書が署名された領収書を要求元のSignedDataオブジェクトのために計算されたメッセージダイジェスト値を含む署名されました。オリジナルSignedDataオブジェクトをEnvelopedDataのオブジェクト内に暗号化して送信し、ESSは、領収書に署名した場合に暗号化されずに送信され、元の暗号化されたSignedDataオブジェクトのために計算されたメッセージダイジェスト値が暗号化されずに送信されます。 ESSは、領収書に署名し暗号化するかどうかを決定する場合レスポンダはこのことを考慮すべきです。
An MLExpansionHistory attribute MUST NOT be included in the attributes of a SignerInfo in a SignedData object that encapsulates a Receipt content. This is true because when a SignedData/Receipt is sent to an MLA for distribution, then the MLA must always encapsulate the received SignedData/Receipt in an outer SignedData in which the MLA will include the MLExpansionHistory attribute. The MLA cannot change the signedAttributes of the received SignedData/Receipt object, so it can't add the MLExpansionHistory to the SignedData/Receipt.
MLExpansionHistory属性は、領収書の内容をカプセル化するSignedDataオブジェクト内のSignerInfoの属性に含まれてはいけません。 SignedData /領収書が配布のためにMLAに送信された場合、その後、MLAは常にMLAはMLExpansionHistory属性が含まれる外側のSignedDataで受信のSignedData /領収書をカプセル化しなければならないので、これは本当です。それはのSignedData /領収書にMLExpansionHistoryを追加することはできませんので、MLAは、受信のSignedData /領収書オブジェクトのsignedAttributesのを変更することはできません。
If a signed receipt was created by the process described in the sections above, then the software MUST use the following process to determine to whom the signed receipt should be sent.
署名された領収書は、上記のセクションに記載された方法によって作成された場合、ソフトウェアは、署名された領収書を送信しなければならない誰に決定するために、以下のプロセスを使用しなければなりません。
1. The receiptsTo field must be present in the receiptRequest attribute. The software initiates the sequence of recipients with the value(s) of receiptsTo.
1. receiptsToフィールドはreceiptRequest属性に存在しなければなりません。ソフトウェアはreceiptsToの値（S）と受信者のシーケンスを開始します。
2. If the MlExpansionHistory attribute is present in the outer SignedData block, and the last MLData contains an MLReceiptPolicy value of insteadOf, then the software replaces the sequence of recipients with the value(s) of insteadOf.
2. MlExpansionHistory属性は、外側のSignedDataブロック中に存在し、そして最後MLDataはinsteadOfのMLReceiptPolicy値が含まれている場合、ソフトウェアはinsteadOfの値（S）と受信者の配列を置き換えます。
3. If the MlExpansionHistory attribute is present in the outer SignedData block and the last MLData contains an MLReceiptPolicy value of inAdditionTo, then the software adds the value(s) of inAdditionTo to the sequence of recipients.
3. MlExpansionHistory属性は、外側のSignedDataブロック中に存在し、最後MLDataはinAdditionToのMLReceiptPolicy値が含まれている場合、ソフトウェアは、受信者の配列にinAdditionToの値（複数可）を付加します。
A signed receipt is communicated as a single ASN.1 encoded object composed of a signedData object directly including a Receipt content. It is identified by the presence of the id-ct-receipt object identifier in the encapContentInfo eContentType value of the signedData object including the Receipt content.
署名された領収書を直接受領コンテンツを含むSignedDataオブジェクトからなる単ASN.1符号化されたオブジェクトとして伝達されます。これは、受領コンテンツを含むSignedDataオブジェクトのencapContentInfoのeContentType値のID-CT-レシートオブジェクト識別子の存在によって同定されます。
Although recipients are not supposed to send more than one signed receipt, receiving agents SHOULD be able to accept multiple signed receipts from a recipient.
受信者が複数の署名領収書を送ることになっていませんが、受信エージェントは、受信者から複数の署名領収書を受け入れることができべきです。
A signedData/Receipt is validated as follows:
次のようにたsignedData /領収書が検証されています。
2. Extract the contentType, signedContentIdentifier, and originatorSignatureValue from the decoded Receipt structure to identify the original signedData signerInfo that requested the signedData/Receipt.
2.たsignedData /領収書を要求元たsignedDataのSignerInfoを識別するために、復号された領収書の構造からのcontentType、signedContentIdentifier、及びoriginatorSignatureValueを抽出します。
3. Acquire the message signature digest value calculated by the sender to generate the signature value included in the original signedData signerInfo that requested the signedData/Receipt.
3.たsignedData /領収書を要求元たsignedDataのSignerInfoに含まれる署名値を生成するために送信者によって算出された値をメッセージダイジェスト署名を取得します。
3.1. If the sender-calculated message signature digest value has
been saved locally by the sender, it must be located and
retrieved.
3.2. If it has not been saved, then it must be re-calculated based on the original signedData content and signedAttributes as described in [CMS].
3.2. それが保存されていない場合、それは、[CMS]で説明したように、オリジナルたsignedDataの内容とsignedAttributesのに基づいて再計算する必要があります。
4. The message signature digest value calculated by the sender is then compared with the value of the msgSigDigest signedAttribute included in the signedData/Receipt signerInfo. If these digest values are identical, then that proves that the message signature digest value calculated by the recipient based on the received original signedData object is the same as that calculated by the sender. This proves that the recipient received exactly the same original signedData content and signedAttributes as sent by the sender because that is the only way that the recipient could have calculated the same message signature digest value as calculated by the sender. If the digest values are different, then the signedData/Receipt signature verification process fails.
送信者によって算出4.メッセージ署名ダイジェスト値は、次にたsignedData /領収書のSignerInfoに含まmsgSigDigest signedAttributeの値と比較されます。これらのダイジェスト値が同一である場合、そのメッセージの署名が受信した元SignedDataオブジェクトに基づいて受取人によって計算された値を消化することを証明している送信者によって算出さと同じです。これは、送信者によって送信されたように、その受信者が送信者によって計算される同一のメッセージの署名をダイジェスト値を算出している可能性が唯一の方法であるため、受信者は、正確に同一のオリジナルたsignedDataコンテンツとsignedAttributesのを受け取ったことを証明します。ダイジェスト値が異なる場合、次にたsignedData /領収書の署名検証処理が失敗します。
5. Acquire the digest value calculated by the sender for the Receipt content constructed by the sender (including the contentType, signedContentIdentifier, and signature value that were included in the original signedData signerInfo that requested the signedData/Receipt).
5.（たsignedData /領収書を要求元たsignedDataのSignerInfoに含まれていたのcontentType、signedContentIdentifier、及び署名値を含む）の送信者によって構築レシートコンテンツの送信者によって算出ダイジェスト値を得ます。
5.1. If the sender-calculated Receipt content digest value has
been saved locally by the sender, it must be located and
retrieved.
5.2. If it has not been saved, then it must be re-calculated. As described in section above, step 2, create a Receipt structure including the contentType, signedContentIdentifier and signature value that were included in the original signedData signerInfo that requested the signed receipt. The Receipt structure is then ASN.1 DER encoded to produce a data stream which is then digested to produce the Receipt content digest value.
5.2. それが保存されていない場合、それは再計算する必要があります。上記のセクション、ステップ2で説明したように、署名された領収書を要求元たsignedDataのSignerInfoに含まれていたのcontentType、signedContentIdentifier及び署名値を含むレシート構造を作成します。レシート構造は次いで受領コンテンツがダイジェスト値を生成するために消化されたデータストリームを生成する符号化されたASN.1 DERです。
6. The Receipt content digest value calculated by the sender is then compared with the value of the messageDigest signedAttribute included in the signedData/Receipt signerInfo. If these digest values are identical, then that proves that the values included in the Receipt content by the recipient are identical to those that were included in the original signedData signerInfo that requested the signedData/Receipt. This proves that the recipient received the original signedData signed by the sender, because that is the only way that the recipient could have obtained the original signedData signerInfo signature value for inclusion in the Receipt content. If the digest values are different, then the signedData/Receipt signature verification process fails.
6.送信者によって算出受領コンテンツダイジェスト値は、その後のMessageDigest signedAttributeの値と比較されたsignedData /領収書のSignerInfoに含まれます。これらのダイジェスト値が同一である場合、それは、受信者による受信コンテンツに含まれる値たsignedData /領収書を要求元たsignedDataのSignerInfoに含まれていたものと同一であることを証明しています。このことは、受取人が受領コンテンツに含めるためのオリジナルたsignedDataのSignerInfo署名値を取得している可能性が唯一の方法であるため、受信者は、送信者によって署名されたオリジナルたsignedDataを受け取ったことを証明します。ダイジェスト値が異なる場合、次にたsignedData /領収書の署名検証処理が失敗します。
7. The ASN.1 DER encoded signedAttributes of the signedData/Receipt signerInfo are digested as described in [CMS].
[CMS]に記載されているように7たsignedData /領収書のSignerInfoのASN.1のDER符号化されたsignedAttributesのが消化されます。
8. The resulting digest value is then used to verify the signature value included in the signedData/Receipt signerInfo. If the signature verification is successful, then that proves the integrity of the signedData/receipt signerInfo signedAttributes and authenticates the identity of the signer of the signedData/Receipt signerInfo. Note that the signedAttributes include the recipient-calculated Receipt content digest value (messageDigest attribute) and recipient-calculated message signature digest value (msgSigDigest attribute). Therefore, the aforementioned comparison of the sender-generated and recipient-generated digest values combined with the successful signedData/Receipt signature verification proves that the recipient received the exact original signedData content and signedAttributes (proven by msgSigDigest attribute) that were signed by the sender of the original signedData object (proven by messageDigest attribute). If the signature verification fails, then the signedData/Receipt signature verification process fails.
8.ダイジェスト得られた値は、次にたsignedData /領収書のSignerInfoに含まれる署名値を検証するために使用されます。署名検証が成功した場合、それはたsignedData /領収書のSignerInfo signedAttributesのの整合性を証明してたsignedData /領収書のSignerInfoの署名者の身元を認証します。 signedAttributesのは（msgSigDigest属性）の値をダイジェスト値（のMessageDigest属性）とレシピエント計算メッセージ署名ダイジェストレシピエント計算受領コンテンツを含むことに留意されたいです。したがって、送信側で生成し、受信者が生成した前述の比較が成功したsignedData /領収書の署名検証と組み合わせてダイジェスト値を受信者が送信者によって署名された正確なオリジナルたsignedDataコンテンツと（msgSigDigest属性によって証明）signedAttributesのを受け取ったことを証明します（のMessageDigest属性によって証明）、元SignedDataオブジェクト。署名検証に失敗した場合は、たsignedData /領収書の署名検証プロセスは失敗します。
The signature verification process for each signature algorithm that is used in conjunction with the CMS protocol is specific to the algorithm. These processes are described in documents specific to the algorithms.
CMSプロトコルと共に使用される各署名アルゴリズムのための署名検証処理は、アルゴリズムに固有です。これらのプロセスは、アルゴリズムに固有の文書に記載されています。
A receiptRequest attribute value has ASN.1 type ReceiptRequest. Use the receiptRequest attribute only within the signed attributes associated with a signed message.
receiptRequest属性値はASN.1タイプReceiptRequestを持っています。唯一の署名されたメッセージに関連付けられた署名属性内receiptRequest属性を使用します。
ReceiptRequest ::= SEQUENCE {
signedContentIdentifier ContentIdentifier,
receiptsFrom ReceiptsFrom,
receiptsTo SEQUENCE SIZE (1..ub-receiptsTo)) OF GeneralNames }
ub-receiptsTo INTEGER ::= 16
id-aa-receiptRequest OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 1}
ContentIdentifier ::= OCTET STRING
id-aa-contentIdentifier OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 7}
A signedContentIdentifier MUST be created by the message originator when creating a receipt request. To ensure global uniqueness, the minimal signedContentIdentifier SHOULD contain a concatenation of user-specific identification information (such as a user name or public keying material identification information), a GeneralizedTime string, and a random number.
領収書要求を作成するときsignedContentIdentifierはメッセージ発信元によって作成されなければなりません。グローバルな一意性を保証するために、最小signedContentIdentifierは、GeneralizedTimeの列、及び乱数（例えば、ユーザ名またはパブリックキーイングマテリアル識別情報として）ユーザ固有の識別情報の連結を含むべきです。
The receiptsFrom field is used by the originator to specify the recipients requested to return a signed receipt. A CHOICE is provided to allow specification of:
receiptsFromフィールドは、受信者を指定するために発信元によって使用される署名した領収書を返すように要求されています。 CHOICEはの仕様を可能にするために提供されています。
- receipts from all recipients are requested - receipts from first tier (recipients that did not receive the message as members of a mailing list) recipients are requested - receipts from a specific list of recipients are requested
- すべての受信者からの領収書が要求されている - 最初の層からの領収書の受取人が要求されている（メーリングリストのメンバーとしてメッセージを受信しなかった受信者） - 受信者の特定のリストから領収書が要求されています
ReceiptsFrom ::= CHOICE {
allOrFirstTier [0] AllOrFirstTier,
-- formerly "allOrNone [0]AllOrNone"
receiptList [1] SEQUENCE OF GeneralNames }
AllOrFirstTier ::= INTEGER { -- Formerly AllOrNone
allReceipts (0),
firstTierRecipients (1) }
The receiptsTo field is used by the originator to identify the user(s) to whom the identified recipient should send signed receipts. The message originator MUST populate the receiptsTo field with a GeneralNames for each entity to whom the recipient should send the signed receipt. If the message originator wants the recipient to send the signed receipt to the originator, then the originator MUST include a GeneralNames for itself in the receiptsTo field.
receiptsToフィールドは、識別された受信者は、署名された領収書を送信しなければならない誰にユーザー（複数可）を識別するために発信者によって使用されます。メッセージの発信者は、受信者が署名した領収書を送信する必要があります誰に各エンティティのGeneralNamesでreceiptsToフィールドを移入する必要があります。メッセージの発信元が受信者が発信元に署名した領収書を送信したい場合には、発信者はreceiptsTo分野における自体のGeneralNamesを含まなければなりません。
Receipts are represented using a new content type, Receipt. The Receipt content type shall have ASN.1 type Receipt. Receipts must be encapsulated within a SignedData message.
領収書は、領収書を新しいコンテンツタイプを使用して表されます。領収書のコンテンツタイプは、ASN.1タイプの領収書を持たなければなりません。領収書はSignedDataのメッセージ内にカプセル化する必要があります。
Receipt ::= SEQUENCE {
version ESSVersion,
contentType ContentType,
signedContentIdentifier ContentIdentifier,
originatorSignatureValue OCTET STRING }
id-ct-receipt OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-ct(1) 1}
ESSVersion ::= INTEGER { v1(1) }
The version field defines the syntax version number, which is 1 for this version of the standard.
バージョンフィールドは、標準のこのバージョンの1である構文バージョン番号を規定します。
Many applications find it useful to have information that describes the innermost signed content of a multi-layer message available on the outermost signature layer. The contentHints attribute provides such information.
多くのアプリケーションは、それが有用最外署名層上で利用可能な多層メッセージの最も内側の署名されたコンテンツを記述する情報を有することを見つけます。 contentHints属性は、そのような情報を提供します。
Content-hints attribute values have ASN.1 type contentHints.
コンテンツのヒントは、値がASN.1タイプcontentHintsを持っている属性。
ContentHints ::= SEQUENCE {
contentDescription UTF8String (SIZE (1..MAX)) OPTIONAL,
contentType ContentType }
id-aa-contentHint OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 4}
The contentDescription field may be used to provide information that the recipient may use to select protected messages for processing, such as a message subject. If this field is set, then the attribute is expected to appear on the signedData object enclosing an envelopedData object and not on the inner signedData object. The (SIZE (1..MAX)) construct constrains the sequence to have at least one entry. MAX indicates the upper bound is unspecified. Implementations are free to choose an upper bound that suits their environment.
contentDescriptionフィールドは、受信者が、メッセージの件名として、処理のために保護されたメッセージを選択するために使用することができるという情報を提供するために使用され得ます。このフィールドが設定されている場合、その属性はEnvelopedDataのオブジェクトを囲むSignedDataオブジェクトではなく内側のSignedDataオブジェクトに表示されることが予想されます。 （SIZE（1..MAX））構築物は、配列が少なくとも1つのエントリを有するように制約します。 MAXは上限が不定であることを示します。実装は、自分の環境に合った上限を自由に選択できます。
Messages which contain a signedData object wrapped around an envelopedData object, thus masking the inner content type of the message, SHOULD include a contentHints attribute, except for the case of the data content type. Specific message content types may either force or preclude the inclusion of the contentHints attribute. For example, when a signedData/Receipt is encrypted within an envelopedData object, an outer signedData object MUST be created that encapsulates the envelopedData object and a contentHints attribute with contentType set to the id-ct-receipt object identifier MUST be included in the outer signedData SignerInfo signedAttributes.
したがって、メッセージの内部コンテンツタイプのマスキング、EnvelopedDataのオブジェクトに巻き付けSignedDataオブジェクトを含むメッセージは、contentHintsデータコンテンツタイプの場合を除いて、属性を含むべきです。特定のメッセージのコンテンツタイプは、力またはいずれかの属性contentHintsの包含を排除することができます。たsignedData /領収書がEnvelopedDataのオブジェクト内に暗号化されている場合、例えば、外側のSignedDataオブジェクトはEnvelopedDataのオブジェクトをカプセル化し、その作成されなければならないとcontentHintsはcontentTypeの持つ属性ID-CT-レシートオブジェクト識別子に設定外側たsignedDataに含まれなければなりませんSignerInfo signedAttributesの。
The msgSigDigest attribute can only be used in the signed attributes of a signed receipt. It contains the digest of the ASN.1 DER encoded signedAttributes included in the original signedData that requested the signed receipt. Only one msgSigDigest attribute can appear in a signed attributes set. It is defined as follows:
msgSigDigest属性は署名した領収書の署名属性で使用することができます。これはASN.1のDER符号化されたsignedAttributesののダイジェストが署名している領収書を要求元たsignedDataに含ま含ま。一つだけmsgSigDigest属性が設定署名の属性に表示されます。これは次のように定義されます。
msgSigDigest ::= OCTET STRING
id-aa-msgSigDigest OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 5}
The contentReference attribute is a link from one SignedData to another. It may be used to link a reply to the original message to which it refers, or to incorporate by reference one SignedData into another. The first SignedData MUST include a contentIdentifier signed attribute, which SHOULD be constructed as specified in section 2.7. The second SignedData links to the first by including a ContentReference signed attribute containing the content type, content identifier, and signature value from the first SignedData.
contentReference属性が1のSignedDataから他へのリンクです。参照する元のメッセージへの返信をリンクする、または別に参照ずつのSignedDataを組み込むために使用されてもよいです。最初のSignedDataは、セクション2.7で指定されるように構成されるべきであるcontentIdentifier署名された属性を含まなければなりません。最初のSignedDataからContentReference署名付きコンテンツタイプを含む属性、コンテンツ識別子、及び署名値を含むことによって最初に第二のSignedDataリンク。
ContentReference ::= SEQUENCE {
contentType ContentType,
signedContentIdentifier ContentIdentifier,
originatorSignatureValue OCTET STRING }
id-aa-contentReference OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 10 }
This section describes the syntax to be used for security labels that can optionally be associated with S/MIME encapsulated data. A security label is a set of security information regarding the sensitivity of the content that is protected by S/MIME encapsulation.
このセクションでは、必要に応じてS / MIMEカプセル化されたデータに関連付けることができるセキュリティ・ラベルに使用する構文を説明しています。セキュリティラベルは、S / MIMEカプセル化によって保護されたコンテンツの感度に関するセキュリティ情報のセットです。
"Authorization" is the act of granting rights and/or privileges to users permitting them access to an object. "Access control" is a means of enforcing these authorizations. The sensitivity information in a security label can be compared with a user's authorizations to determine if the user is allowed to access the content that is protected by S/MIME encapsulation.
「認可は、」彼らにオブジェクトへのアクセスを許可するユーザーに権利および/または権限を付与する行為です。 「アクセス制御」は、これらの権限を強化する手段です。セキュリティラベルで感度情報は、ユーザーがS / MIMEカプセル化によって保護されたコンテンツにアクセスすることを許可されているかどうかを判断するために、ユーザの権限と比較することができます。
Security labels may be used for other purposes such as a source of routing information. The labels often describe ranked levels ("secret", "confidential", "restricted", and so on) or are role-based, describing which kind of people can see the information ("patient's health-care team", "medical billing agents", "unrestricted", and so on).
セキュリティラベルは、ルーティング情報のソースのような他の目的に使用することができます。ラベルは、多くの場合、ランクのレベル（「秘密」、「機密」、「制限」など）を記述するか、役割ベースで、人々のどの種類（「患者の医療チームを」の情報を見ることができ、「医療費請求を記述する薬」、 『）』無制限、など。
A sending agent may include a security label attribute in the signed attributes of a signedData object. A receiving agent examines the security label on a received message and determines whether or not the recipient is allowed to see the contents of the message.
送信エージェントはSignedDataオブジェクトの署名属性内のセキュリティラベルの属性を含むことができます。受信エージェントは、受信したメッセージにセキュリティ・ラベルを調べて、受信者がメッセージの内容を見ることが許可されているか否かを判断します。
A sending agent that is using security labels MUST put the security label attribute in the signedAttributes field of a SignerInfo block. The security label attribute MUST NOT be included in the unsigned attributes. Integrity and authentication security services MUST be applied to the security label, therefore it MUST be included as a signed attribute, if used. This causes the security label attribute to be part of the data that is hashed to form the SignerInfo signature value. A SignerInfo block MUST NOT have more than one security label signed attribute.
セキュリティラベルを使用している送信エージェントはのSignerInfoブロックのsignedAttributesのフィールドにセキュリティラベル属性を置く必要があります。セキュリティラベル属性は未署名の属性に含まれてはいけません。使用している場合、署名している属性として整合性と認証セキュリティサービスは、セキュリティラベルに適用されなければならないので、それを含まなければなりません。これは、セキュリティラベル属性がのSignerInfoの署名値を形成するためにハッシュされたデータの一部になります。 SignerInfoブロックは、複数のセキュリティラベルに署名属性を持ってはいけません。
When there are multiple SignedData blocks applied to a message, a security label attribute may be included in either the inner signature, outer signature, or both. A security label signed attribute may be included in a signedAttributes field within the inner SignedData block. The inner security label will include the sensitivities of the original content and will be used for access control decisions related to the plaintext encapsulated content. The inner signature provides authentication of the inner security label and cryptographically protects the original signer's inner security label of the original content.
メッセージに適用される複数のSignedDataブロックがある場合、セキュリティラベル属性は内側の署名、外側の署名、または両方に含まれてもよいです。属性に署名したセキュリティラベルは、内側のSignedDataブロック内signedAttributesのフィールドに含まれてもよいです。内部セキュリティ・ラベルは、元のコンテンツの感度を含むであろうし、平文カプセル化されたコンテンツに関連するアクセス制御の決定に使用されます。内側の署名は、内部セキュリティラベルの認証を提供し、暗号オリジナルコンテンツの元の署名者の内側のセキュリティー・ラベルを保護します。
When the originator signs the plaintext content and signed attributes, the inner security label is bound to the plaintext content. An intermediate entity cannot change the inner security label without invalidating the inner signature. The confidentiality security service can be applied to the inner security label by encrypting the entire inner signedData object within an EnvelopedData block.
発信者が平文コンテンツと署名の属性に署名すると、内部セキュリティラベルは平文コンテンツにバインドされています。中間エンティティは、内側の署名を無効にすることなく、内部セキュリティラベルを変更することはできません。機密性のセキュリティサービスがEnvelopedDataのブロック内で内面全体SignedDataオブジェクトを暗号化することで、内部のセキュリティラベルに適用することができます。
A security label signed attribute may also be included in a signedAttributes field within the outer SignedData block. The outer security label will include the sensitivities of the encrypted message and will be used for access control decisions related to the encrypted message and for routing decisions. The outer signature provides authentication of the outer security label (as well as for the encapsulated content which may include nested S/MIME messages).
属性に署名したセキュリティラベルは、外側のSignedDataブロック内signedAttributesのフィールドに含まれてもよいです。外側のセキュリティ・ラベルは、暗号化されたメッセージの感度を含むであろうし、暗号化されたメッセージに関連するアクセス制御の決定およびルーティング決定に使用されます。外側の署名は、外側のセキュリティ・ラベルの認証（およびネストされたS / MIMEメッセージを含むことができるカプセル化コンテンツのための）を提供します。
There can be multiple SignerInfos within a SignedData object, and each SignerInfo may include signedAttributes. Therefore, a single SignedData object may include multiple eSSSecurityLabels, each SignerInfo having an eSSSecurityLabel attribute. For example, an originator can send a signed message with two SignerInfos, one containing a DSS signature, the other containing an RSA signature. If any of the SignerInfos included in a SignedData object include an eSSSecurityLabel attribute, then all of the SignerInfos in that SignedData object MUST include an eSSSecurityLabel attribute and the value of each MUST be identical.
そこSignedDataオブジェクト内の複数SignerInfosすることができ、それぞれのSignerInfoはsignedAttributesのを含んでいてもよいです。したがって、単一のSignedDataオブジェクトは、それぞれのSignerInfoがeSSSecurityLabel属性を有する、複数eSSSecurityLabelsを含むことができます。例えば、発信者は、二つのSignerInfos、DSS署名を含有するもの、他方はRSA署名を含んで署名されたメッセージを送信することができます。 SignerInfosのいずれかSignedDataオブジェクトに含まれている場合eSSSecurityLabel属性を含み、そのSignedDataオブジェクトでSignerInfosの全ては同一でなければなりませんeSSSecurityLabel属性とそれぞれの値を含まなければなりません。
Before processing an eSSSecurityLabel signedAttribute, the receiving agent MUST verify the signature of the SignerInfo which covers the eSSSecurityLabel attribute. A recipient MUST NOT process an eSSSecurityLabel attribute that has not been verified.
eSSSecurityLabel signedAttributeを処理する前に、受信エージェントはeSSSecurityLabel属性をカバーするのSignerInfoの署名を検証しなければなりません。受信者が確認されていないeSSSecurityLabel属性を処理してはいけません。
A receiving agent MUST process the eSSSecurityLabel attribute, if present, in each SignerInfo in the SignedData object for which it verifies the signature. This may result in the receiving agent processing multiple eSSSecurityLabels included in a single SignedData object. Because all eSSSecurityLabels in a SignedData object must be identical, the receiving agent processes (such as performing access control) on the first eSSSecurityLabel that it encounters in a SignerInfo that it verifies, and then ensures that all other eSSSecurityLabels in signerInfos that it verifies are identical to the first one encountered. If the eSSSecurityLabels in the signerInfos that it verifies are not all identical, then the receiving agent MUST warn the user of this condition.
存在する場合、受信エージェントは、署名を検証するためのSignedDataオブジェクトにそれぞれのSignerInfoにおいて、eSSSecurityLabel属性を処理しなければなりません。これは、単一のSignedDataオブジェクトに含まれる複数のeSSSecurityLabelsを処理する受信エージェントをもたらすことができます。 SignedDataオブジェクト内のすべてのeSSSecurityLabelsが同一でなければならないので、（そのようなアクセス制御を行うように）受信エージェントプロセス最初eSSSecurityLabelにそれが検証ことのSignerInfoに遭遇し、それが検証することsignerInfos内の他のすべてのeSSSecurityLabelsが同一であることを保証すること最初に遭遇したものに。それが検証さsignerInfos内eSSSecurityLabelsはすべて同一でない場合は、受信エージェントは、この状態をユーザに警告しなければなりません。
Receiving agents SHOULD have a local policy regarding whether or not to show the inner content of a signedData object that includes an eSSSecurityLabel security-policy-identifier that the processing software does not recognize. If the receiving agent does not recognize the eSSSecurityLabel security-policy-identifier value, then it SHOULD stop processing the message and indicate an error.
受信エージェントは、処理ソフトウェアが認識しないeSSSecurityLabelセキュリティポリシー識別子を含むSignedDataオブジェクトの内側の内容を表示するか否かのローカルポリシーを持っているべきです。受信エージェントはeSSSecurityLabelセキュリティポリシー識別子の値を認識しない場合、それは、メッセージの処理を停止し、エラーを示すべきです。
The eSSSecurityLabel syntax is derived directly from [MTSABS] ASN.1
module. (The MTSAbstractService module begins with "DEFINITIONS
IMPLICIT TAGS ::=".) Further, the eSSSecurityLabel syntax is
compatible with that used in [MSP4].
ESSSecurityLabel ::= SET {
security-policy-identifier SecurityPolicyIdentifier,
security-classification SecurityClassification OPTIONAL,
privacy-mark ESSPrivacyMark OPTIONAL,
security-categories SecurityCategories OPTIONAL }
id-aa-securityLabel OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 2}
SecurityPolicyIdentifier ::= OBJECT IDENTIFIER
SecurityClassification ::= INTEGER {
unmarked (0),
unclassified (1),
restricted (2),
confidential (3),
secret (4),
top-secret (5) } (0..ub-integer-options)
ub-integer-options INTEGER ::= 256
ESSPrivacyMark ::= CHOICE {
pString PrintableString (SIZE (1..ub-privacy-mark-length)),
utf8String UTF8String (SIZE (1..MAX))
}
ub-privacy-mark-length INTEGER ::= 128
SecurityCategories ::= SET SIZE (1..ub-security-categories) OF
SecurityCategory
ub-security-categories INTEGER ::= 64
SecurityCategory ::= SEQUENCE {
type [0] OBJECT IDENTIFIER,
value [1] ANY DEFINED BY type -- defined by type
}
--Note: The aforementioned SecurityCategory syntax produces identical --hex encodings as the following SecurityCategory syntax that is --documented in the X.411 specification:
--Note：上述SecurityCategory構文は、X.411仕様で--documentedれる以下SecurityCategory構文と同じ--hexエンコーディングを生成します。
--
--SecurityCategory ::= SEQUENCE {
-- type [0] SECURITY-CATEGORY,
-- value [1] ANY DEFINED BY type }
--
--SECURITY-CATEGORY MACRO ::=
--BEGIN
--TYPE NOTATION ::= type | empty
--VALUE NOTATION ::= value (VALUE OBJECT IDENTIFIER)
--END
This section gives more detail on the the various components of the eSSSecurityLabel syntax.
このセクションでは、eSSSecurityLabel構文のさまざまなコンポーネントの詳細を提供します。
A security policy is a set of criteria for the provision of security services. The eSSSecurityLabel security-policy-identifier is used to identify the security policy in force to which the security label relates. It indicates the semantics of the other security label components.
セキュリティポリシーは、セキュリティサービスの提供のための基準のセットです。 eSSSecurityLabelセキュリティポリシー識別子は、セキュリティラベルが関係する力のセキュリティポリシーを識別するために使用されます。これは、他のセキュリティ・ラベル・コンポーネントの意味を示します。
This specification defines the use of the Security Classification field exactly as is specified in the X.411 Recommendation, which states in part:
この仕様はまさに一部で述べX.411勧告に指定されているようセキュリティ分類フィールドの使用を定義しています。
If present, a security-classification may have one of a hierarchical list of values. The basic security-classification hierarchy is defined in this Recommendation, but the use of these values is defined by the security-policy in force. Additional values of security-classification, and their position in the hierarchy, may also be defined by a security-policy as a local matter or by bilateral agreement. The basic security-classification hierarchy is, in ascending order: unmarked, unclassified, restricted, confidential, secret, top-secret.
存在する場合、セキュリティ分類は、値の階層リストの一つを有することができます。基本的なセキュリティ分類階層は、この勧告で定義されているが、これらの値の使用は力のセキュリティポリシーによって定義されます。追加のセキュリティ分類の値、および階層内の位置は、また、ローカルの問題として、あるいは二国間の合意により、セキュリティポリシーによって定義することができます。マークされていない、未分類、制限された、機密、秘密、極秘：基本的なセキュリティ分類階層は、昇順で、あります。
This means that the security policy in force (identified by the eSSSecurityLabel security-policy-identifier) defines the SecurityClassification integer values and their meanings.
これは、（eSSSecurityLabelセキュリティポリシー識別子によって識別される）力のセキュリティポリシーがSecurityClassification整数値とその意味を定義することを意味します。
An organization can develop its own security policy that defines the SecurityClassification INTEGER values and their meanings. However, the general interpretation of the X.411 specification is that the values of 0 through 5 are reserved for the "basic hierarchy" values of unmarked, unclassified, restricted, confidential, secret, and top-secret. Note that X.411 does not provide the rules for how these values are used to label data and how access control is performed using these values.
組織はSecurityClassification INTEGER値とその意味を定義する独自のセキュリティポリシーを策定することができます。しかし、X.411仕様の一般的な解釈は、0〜5の値は、マークされていない未分類、制限された、機密、秘密、そして極秘の「基本的な階層」の値のために予約されていることです。 X.411は、これらの値をデータとどのようにアクセス制御が、これらの値を使用して行われるの標識に使用されている方法のための規則を提供しないことに注意してください。
There is no universal definition of the rules for using these "basic hierarchy" values. Each organization (or group of organizations) will define a security policy which documents how the "basic hierarchy" values are used (if at all) and how access control is enforced (if at all) within their domain.
これらの「基本的な階層」の値を使用するためのルールの普遍的な定義はありません。各組織（または組織のグループ）は、（すべての場合）「基本階層」の値が使用されている方法を文書化し、（すべての場合）どのようにアクセス制御が自分のドメイン内で施行されたセキュリティポリシーを定義します。
Therefore, the security-classification value MUST be accompanied by a security-policy-identifier value to define the rules for its use. For example, a company's "secret" classification may convey a different meaning than the US Government "secret" classification. In summary, a security policy SHOULD NOT use integers 0 through 5 for other than their X.411 meanings, and SHOULD instead use other values in a hierarchical fashion.
したがって、セキュリティ分類値は、その使用のためのルールを定義するセキュリティポリシー識別子の値を添付しなければなりません。たとえば、会社の「秘密」の分類は、米国政府の「秘密」の分類とは異なる意味を伝えることができます。要約すると、セキュリティポリシーは、彼らのX.411の意味以外に、5までの整数0を使用してはならず、代わりに階層的に他の値を使用すべきです。
Note that the set of valid security-classification values MUST be hierarchical, but these values do not necessarily need to be in ascending numerical order. Further, the values do not need to be contiguous.
有効なセキュリティ分類値のセットが階層的でなければならないことに注意してください、これらの値は、必ずしも数値の昇順にする必要はありません。さらに、値が連続している必要はありません。
For example, in the Defense Message System 1.0 security policy, the security-classification value of 11 indicates Sensitive-But-Unclassified and 5 indicates top-secret. The hierarchy of sensitivity ranks top-secret as more sensitive than Sensitive-But-Unclassified even though the numerical value of top-secret is less than Sensitive-But-Unclassified.
例えば、防御メッセージシステム1.0セキュリティポリシーで、11のセキュリティ分類値がsensitive-しかし、未分類を示し、図5は、トップシークレットを示します。感度の階層は、トップシークレットの数値は未分類敏感-しかし-未満であっても未分類敏感-しかし、より感度として極秘にランクされています。
(Of course, if security-classification values are both hierarchical and in ascending order, a casual reader of the security policy is more likely to understand it.)
（セキュリティ分類値が階層と昇順で両方ある場合はもちろん、セキュリティポリシーのカジュアルな読者はそれを理解しやすくなります。）
An example of a security policy that does not use any of the X.411 values might be:
X.411値のいずれかを使用していないセキュリティポリシーの例は次のようになります。
10 -- anyone 15 -- Morgan Corporation and its contractors 20 -- Morgan Corporation employees 25 -- Morgan Corporation board of directors
10 - 誰15 - モルガン社およびその請負業者20 - モルガン社の従業員25 - 取締役のモルガン・コーポレーションボード
An example of a security policy that uses part of the X.411 hierarchy might be:
X.411階層の一部を利用したセキュリティポリシーの例は次のようになります。
0 -- unmarked 1 -- unclassified, can be read by everyone
0 - 無印1 - 分類されていない、誰もが読むことができ
2 -- restricted to Timberwolf Productions staff 6 -- can only be read to Timberwolf Productions executives
2 - TIMBERWOLFプロダクションのスタッフ6に制限は - のみTIMBERWOLFプロダクション幹部に読み取ることができます
If present, the eSSSecurityLabel privacy-mark is not used for access control. The content of the eSSSecurityLabel privacy-mark may be defined by the security policy in force (identified by the eSSSecurityLabel security-policy-identifier) which may define a list of values to be used. Alternately, the value may be determined by the originator of the security-label.
存在する場合、eSSSecurityLabelプライバシーマークは、アクセス制御に使用されていません。 eSSSecurityLabelプライバシーマークの含有量は、使用される値のリストを定義することができる（eSSSecurityLabelセキュリティポリシー識別子によって識別される）力のセキュリティポリシーによって定義することができます。代わりに、値は、セキュリティラベルの創始によって決定することができます。
If present, the eSSSecurityLabel security-categories provide further granularity for the sensitivity of the message. The security policy in force (identified by the eSSSecurityLabel security-policy-identifier) is used to indicate the syntaxes that are allowed to be present in the eSSSecurityLabel security-categories. Alternately, the security-categories and their values may be defined by bilateral agreement.
存在する場合、eSSSecurityLabelセキュリティ・カテゴリは、メッセージの感度をさらに細分性を提供します。 （eSSSecurityLabelセキュリティポリシー識別子によって識別される）力のセキュリティポリシーはeSSSecurityLabelセキュリティ・カテゴリに存在することが許可されている構文を示すために使用されます。代わりに、セキュリティカテゴリとその値は、二国間の合意によって定義することができます。
Because organizations are allowed to define their own security policies, many different security policies will exist. Some organizations may wish to create equivalencies between their security policies with the security policies of other organizations. For example, the Acme Company and the Widget Corporation may reach a bilateral agreement that the "Acme private" security-classification value is equivalent to the "Widget sensitive" security-classification value.
組織は、独自のセキュリティポリシーを定義することが許可されているので、多くの異なるセキュリティポリシーが存在します。一部の組織では、他の組織のセキュリティポリシーに彼らのセキュリティポリシーとの等価性を作成することもできます。たとえば、Acme社とウィジェット・コーポレーションは、「アクメ民間の」セキュリティ分類値が「ウィジェット敏感な」セキュリティ分類値と等価である二国間合意に達することがあります。
Receiving agents MUST NOT process an equivalentLabels attribute in a message if the agent does not trust the signer of that attribute to translate the original eSSSecurityLabel values to the security policy included in the equivalentLabels attribute. Receiving agents have the option to process equivalentLabels attributes but do not have to. It is acceptable for a receiving agent to only process eSSSecurityLabels. All receiving agents SHOULD recognize equivalentLabels attributes even if they do not process them.
受信エージェントは、エージェントが属性equivalentLabelsに含まれたセキュリティポリシーに元eSSSecurityLabel値を変換するために、その属性の署名者を信頼していない場合equivalentLabelsは、メッセージに属性を処理してはいけません。受信エージェントは、equivalentLabels属性を処理するためのオプションを持っていますが、する必要はありません。それだけで、プロセスeSSSecurityLabelsに受信エージェントが許容されます。すべての受信エージェントは、彼らはそれらを処理していない場合でも、equivalentLabels属性を認識すべきです。
The EquivalentLabels signed attribute is defined as:
属性に署名したEquivalentLabelsは次のように定義されています。
EquivalentLabels ::= SEQUENCE OF ESSSecurityLabel
id-aa-equivalentLabels OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 9}
As stated earlier, the ESSSecurityLabel contains the sensitivity values selected by the original signer of the signedData. If an ESSSecurityLabel is present in a signerInfo, all signerInfos in the signedData MUST contain an ESSSecurityLabel and they MUST all be identical. In addition to an ESSSecurityLabel, a signerInfo MAY also include an equivalentLabels signed attribute. If present, the equivalentLabels attribute MUST include one or more security labels that are believed by the signer to be semantically equivalent to the ESSSecurityLabel attribute included in the same signerInfo.
先に述べたように、ESSSecurityLabelはたsignedDataの元の署名者によって選択された感度値を含みます。 ESSSecurityLabelはのSignerInfoに存在する場合、signedDataでのすべてのsignerInfosはESSSecurityLabelを含まなければならないし、それらはすべて同じでなければなりません。 ESSSecurityLabelに加えて、のSignerInfoは、属性に署名したequivalentLabelsを含むこともできます。存在する場合、equivalentLabels属性がESSSecurityLabel属性が同じのSignerInfoに含まに意味的に等価であることを署名者によって考えられている1つまたは複数のセキュリティラベルを含まなければなりません。
All security-policy object identifiers MUST be unique in the set of ESSSecurityLabel and EquivalentLabels security labels. Before using an EquivalentLabels attribute, a receiving agent MUST ensure that all security-policy OIDs are unique in the security label or labels included in the EquivalentLabels. Once the receiving agent selects the security label (within the EquivalentLabels) to be used for processing, then the security-policy OID of the selected EquivalentLabels security label MUST be compared with the ESSSecurityLabel security-policy OID to ensure that they are unique.
すべてのセキュリティ・ポリシーのオブジェクト識別子は、ESSSecurityLabelとEquivalentLabelsセキュリティラベルのセット内で一意でなければなりません。 EquivalentLabels属性を使用する前に、受信エージェントは、すべてのセキュリティ・ポリシーOIDは、セキュリティラベルやラベルで一意であることを確認しなければならないEquivalentLabelsに含まれています。受信エージェントは、処理のために使用される（EquivalentLabels内）セキュリティ・ラベルを選択すると、選択EquivalentLabelsセキュリティラベルのセキュリティポリシーOIDは、それらが一意であることを保証するためにESSSecurityLabelセキュリティポリシーOIDと比較しなければなりません。
In the case that an ESSSecurityLabel attribute is not included in a signerInfo, then an EquivalentLabels attribute may still be included. For example, in the Acme security policy, the absence of an ESSSecurityLabel could be defined to equate to a security label composed of the Acme security-policy OID and the "unmarked" security-classification.
ESSSecurityLabel属性はのSignerInfoに含まれていない場合には、その後EquivalentLabels属性がまだ含まれていてもよいです。例えば、Acme社のセキュリティポリシーで、ESSSecurityLabelの不在はアクメセキュリティポリシーOIDと「無印」セキュリティ分類からなるセキュリティ・ラベルに等しいように定義することができます。
Note that equivalentLabels MUST NOT be used to convey security labels that are semantically different from the ESSSecurityLabel included in the signerInfos in the signedData. If an entity needs to apply a security label that is semantically different from the ESSSecurityLabel, then it MUST include the sematically different security label in an outer signedData object that encapsulates the signedData object that includes the ESSSecurityLabel.
equivalentLabelsは、意味的にESSSecurityLabel異なるがたsignedDataでsignerInfosに含まれているセキュリティラベルを伝えるために使用してはいけないことに注意してください。エンティティはESSSecurityLabelから意味的に異なるセキュリティ・ラベルを適用する必要がある場合、それはESSSecurityLabelを含むSignedDataオブジェクトをカプセル化する外SignedDataオブジェクトにsematically異なるセキュリティ・ラベルを含まなければなりません。
If present, the equivalentLabels attribute MUST be a signed attribute; it MUST NOT be an unsigned attribute. [CMS] defines signedAttributes as a SET OF Attribute. A signerInfo MUST NOT include multiple instances of the equivalentLabels attribute. CMS defines the ASN.1 syntax for the signed attributes to include attrValues SET OF
存在する場合、equivalentLabels属性が署名している属性でなければなりません。それは未署名の属性にすることはできません。 [CMS]は属性の集合としてsignedAttributesのを規定します。 SignerInfoはequivalentLabels属性の複数のインスタンスを含んではいけません。 CMSは、一連のattrValuesを含めるために署名した属性のASN.1構文を定義します
AttributeValue. A equivalentLabels attribute MUST only include a single instance of AttributeValue. There MUST NOT be zero or multiple instances of AttributeValue present in the attrValues SET OF AttributeValue.
AttributeValueの。 equivalentLabels属性はAttributeValueの単一のインスタンスを含まなければなりません。 AttributeValueのOF attrValuesセットに存在するAttributeValueのゼロか複数のインスタンスがあってはなりません。
A receiving agent SHOULD process the ESSSecurityLabel before processing any EquivalentLabels. If the policy in the ESSSecurityLabel is understood by the receiving agent, it MUST process that label and MUST ignore all EquivalentLabels.
受信エージェントは、任意のEquivalentLabelsを処理する前にESSSecurityLabelを処理しなければなりません。 ESSSecurityLabelでポリシーを受信エージェントが理解されている場合は、そのラベルを処理しなければならないし、すべてのEquivalentLabelsを無視しなければなりません。
When processing an EquivalentLabels attribute, the receiving agent MUST validate the signature on the EquivalentLabels attribute. A receiving agent MUST NOT act on an equivalentLabels attribute for which the signature could not be validated, and MUST NOT act on an equivalentLabels attribute unless that attribute is signed by an entity trusted to translate the original eSSSecurityLabel values to the security policy included in the equivalentLabels attribute. Determining who is allowed to specify equivalence mappings is a local policy. If a message has more than one EquivalentLabels attribute, the receiving agent SHOULD process the first one that it reads and validates that contains the security policy of interest to the receiving agent.
EquivalentLabels属性処理するときに、受信エージェントはEquivalentLabels属性に署名を検証しなければなりません。受信エージェントは、署名を検証できなかったequivalentLabels属性に作用してはならない、とequivalentLabelsは、その属性はエンティティによって署名されていない限り、セキュリティポリシーに元eSSSecurityLabel値を変換するために、信頼できるequivalentLabelsに含まれる属性に作用してはなりません属性。等価のマッピングを指定することが許可されている者の決定は、ローカルポリシーです。メッセージが複数のEquivalentLabels属性を持っている場合は、受信エージェントは、それが読み、それが受信エージェントへの関心のセキュリティポリシーが含まれている検証最初のものを処理しなければなりません。
Sending agents must create recipient-specific data structures for each recipient of an encrypted message. This process can impair performance for messages sent to a large number of recipients. Thus, Mail List Agents (MLAs) that can take a single message and perform the recipient-specific encryption for every recipient are often desired.
送付エージェントは、暗号化されたメッセージの受信者ごとに受信者固有のデータ構造を作成する必要があります。このプロセスは、多数の受信者に送信されるメッセージの性能を損なうことができます。このように、単一のメッセージを取り、すべての受信者の受信者固有の暗号化を行うことができますメールリストエージェント（のMLA）がしばしば望まれています。
An MLA appears to the message originator as a normal message recipient, but the MLA acts as a message expansion point for a Mail List (ML). The sender of a message directs the message to the MLA, which then redistributes the message to the members of the ML. This process offloads the per-recipient processing from individual user agents and allows for more efficient management of large MLs. MLs are true message recipients served by MLAs that provide cryptographic and expansion services for the mailing list.
MLAは、通常のメッセージの受信者としてメッセージの発信者に表示されますが、MLAは、メールリスト（ML）のメッセージ展開点として作用します。メッセージの送信者は、次いで、MLのメンバーにメッセージを再配布MLA、にメッセージを向けます。このプロセスは、個々のユーザエージェントから受信者ごとの処理をオフロードし、大型のMLのより効率的な管理を可能にします。 MLSはメーリングリストのための暗号化と拡張サービスを提供するのMLAによって提供される真のメッセージ受信者です。
In addition to cryptographic handling of messages, secure mailing lists also have to prevent mail loops. A mail loop is where one mailing list is a member of a second mailing list, and the second mailing list is a member of the first. A message will go from one list to the other in a rapidly-cascading succession of mail that will be distributed to all other members of both lists.
メッセージの暗号化処理に加えて、安全なメーリングリストは、メールループを防ぐ必要があります。 1つのメーリングリストは、第二メーリングリストのメンバーであるメールループであり、第二のメーリングリストは、最初のメンバーです。メッセージは、両方のリストの他のすべてのメンバーに配布されるメールの急速カスケード連続して他の1つのリストから移動します。
To prevent mail loops, MLAs use the mlExpansionHistory attribute of the outer signature of a triple wrapped message. The mlExpansionHistory attribute is essentially a list of every MLA that has processed the message. If an MLA sees its own unique entity identifier in the list, it knows that a loop has been formed, and does not send the message to the list again.
メールループを防ぐために、のMLAは、トリプルラップメッセージの外側の署名のmlExpansionHistory属性を使用します。 mlExpansionHistory属性は、本質的にメッセージを処理したすべてのMLAのリストです。 MLAがリストに独自のエンティティの識別子を見れば、それはループが形成されていることを知って、そして再びリストにメッセージを送信しません。
Mail list expansion processing is noted in the value of the mlExpansionHistory attribute, located in the signed attributes of the MLA's SignerInfo block. The MLA creates or updates the signed mlExpansionHistory attribute value each time the MLA expands and signs a message for members of a mail list.
メールリストの展開処理は、MLAののSignerInfoブロックの署名の属性に位置mlExpansionHistory属性の値に注目されます。 MLAは、MLAが膨張してメールリストのメンバーのメッセージに署名するたびに署名したmlExpansionHistory属性値を作成または更新します。
The MLA MUST add an MLData record containing the MLA's identification information, date and time of expansion, and optional receipt policy to the end of the mail list expansion history sequence. If the mlExpansionHistory attribute is absent, then the MLA MUST add the attribute and the current expansion becomes the first element of the sequence. If the mlExpansionHistory attribute is present, then the MLA MUST add the current expansion information to the end of the existing MLExpansionHistory sequence. Only one mlExpansionHistory attribute can be included in the signedAttributes of a SignerInfo.
MLAは、メールリスト拡張履歴シーケンスの最後に拡張のMLAの識別情報、日付と時刻を含むMLDataレコード、およびオプションの領収書ポリシーを追加しなければなりません。 mlExpansionHistory属性が存在しない場合には、MLAは、属性を追加しなければならないと現在の拡張は、シーケンスの最初の要素となります。 mlExpansionHistory属性が存在している場合は、MLAは、既存のMLExpansionHistoryシーケンスの最後に、現在の拡張情報を追加する必要があります。一つだけmlExpansionHistory属性のSignerInfoのsignedAttributesの中に含ませることができます。
Note that if the mlExpansionHistory attribute is absent, then the recipient is a first tier message recipient.
mlExpansionHistory属性が存在しない場合、受信者は最初の層のメッセージ受信者であることに留意されたいです。
There can be multiple SignerInfos within a SignedData object, and each SignerInfo may include signedAttributes. Therefore, a single SignedData object may include multiple SignerInfos, each SignerInfo having a mlExpansionHistory attribute. For example, an MLA can send a signed message with two SignerInfos, one containing a DSS signature, the other containing an RSA signature.
そこSignedDataオブジェクト内の複数SignerInfosすることができ、それぞれのSignerInfoはsignedAttributesのを含んでいてもよいです。したがって、単一のSignedDataオブジェクトは、それぞれのSignerInfoはmlExpansionHistory属性を有する、複数SignerInfosを含むことができます。例えば、MLAは、二つSignerInfos、DSS署名を含有するもの、他方はRSA署名を含んで署名されたメッセージを送信することができます。
If an MLA creates a SignerInfo that includes an mlExpansionHistory attribute, then all of the SignerInfos created by the MLA for that SignedData object MUST include an mlExpansionHistory attribute, and the value of each MUST be identical. Note that other agents might later add SignerInfo attributes to the SignedData block, and those additional SignerInfos might not include mlExpansionHistory attributes.
MLAはmlExpansionHistory属性を含んでいるのSignerInfoを作成する場合、そのSignedDataオブジェクトのためのMLAによって作成SignerInfosの全てはmlExpansionHistory属性を含まなければなりません、そしてそれぞれの値は同一でなければなりません。他のエージェントは、後のSignerInfoはのSignedDataブロックに属性を追加可能性があり、これらの追加SignerInfosがmlExpansionHistory属性が含まれていない可能性があることに注意してください。
A recipient MUST verify the signature of the SignerInfo which covers the mlExpansionHistory attribute before processing the mlExpansionHistory, and MUST NOT process the mlExpansionHistory attribute unless the signature over it has been verified. If a SignedData object has more than one SignerInfo that has an mlExpansionHistory attribute, the recipient MUST compare the mlExpansionHistory attributes in all the SignerInfos that it has verified, and MUST NOT process the mlExpansionHistory attribute unless every verified mlExpansionHistory attribute in the SignedData block is identical. If the mlExpansionHistory attributes in the verified signerInfos are not all identical, then the receiving agent MUST stop processing the message and SHOULD notify the user or MLA administrator of this error condition. In the mlExpansionHistory processing, SignerInfos that do not have an mlExpansionHistory attribute are ignored.
受信者はmlExpansionHistoryを処理する前にmlExpansionHistory属性をカバーするのSignerInfoの署名を検証しなければならない、そしてそれを超える署名が検証されていない限り、mlExpansionHistory属性を処理してはいけません。 SignedDataオブジェクトがmlExpansionHistory属性を持つ複数のSignerInfoを持っている場合は、mlExpansionHistoryを比較しなければならない受信者は、それが確認されたすべてのSignerInfosの属性、およびのSignedDataブロック内のすべての検証mlExpansionHistory属性が同じでない限り、mlExpansionHistory属性を処理してはいけません。 mlExpansionHistoryを検証signerInfosの属性場合、受信エージェントがメッセージの処理を停止しなければならないし、このエラー状態のユーザ又はMLA管理者に通知する必要があり、全て同一ではありません。 mlExpansionHistory処理では、mlExpansionHistory属性を持っていないSignerInfosは無視されます。
Prior to expanding a message, the MLA examines the value of any existing mail list expansion history attribute to detect an expansion loop. An expansion loop exists when a message expanded by a specific MLA for a specific mail list is redelivered to the same MLA for the same mail list.
メッセージを拡大する前に、MLAは、拡張ループを検出するために、既存のメールリスト拡張履歴属性の値を調べます。特定のメールリストの特定MLAによって拡張メッセージが同一のメールリストに同じMLAに再配信されたときに膨張ループが存在します。
Expansion loops are detected by examining the mailListIdentifier field of each MLData entry found in the mail list expansion history. If an MLA finds its own identification information, then the MLA must discontinue expansion processing and should provide warning of an expansion loop to a human mail list administrator. The mail list administrator is responsible for correcting the loop condition.
拡張ループはメールリスト拡張歴史の中で見つかった各MLDataエントリのmailListIdentifierフィールドを調べることによって検出されています。 MLAは、自身の識別情報を検出した場合、MLAは、拡張処理を中止しなければならないし、人間のメールリストの管理者に拡張ループの警告を提供する必要があります。メールリストの管理者は、ループ条件を補正するための責任があります。
The first few paragraphs of this section provide a high-level description of MLA processing. The rest of the section provides a detailed description of MLA processing.
このセクションの最初のいくつかの段落では、MLA処理の高レベルの記述を提供します。セクションの残りの部分は、MLA処理の詳細な説明を提供します。
MLA message processing depends on the structure of the S/MIME layers in the message sent to the MLA for expansion. In addition to sending triple wrapped messages to an MLA, an entity can send other types of messages to an MLA, such as:
MLAメッセージ処理は、拡張のためにMLAに送信されたメッセージ内のS / MIME層の構造に依存します。 MLAにトリプルラップメッセージを送信することに加えて、実体は、次のような、MLAに他のタイプのメッセージを送ることができます。
- a single wrapped signedData or envelopedData message - a double wrapped message (such as signed and enveloped, enveloped and signed, or signed and signed, and so on) - a quadruple-wrapped message (such as if a well-formed triple wrapped message was sent through a gateway that added an outer SignedData layer)
- 単一包まれたsignedData又はEnvelopedDataのメッセージ - （SOサインオンとエンベロープ、エンベロープ及び署名または署名され署名され、そのように）二重ラップされたメッセージ - 四重ラップされたメッセージ（例えば、十分に形成されたトリプルラップされたメッセージの場合と同様）外側のSignedData層を追加して、ゲートウェイを介して送信されました
In all cases, the MLA MUST parse all layers of the received message to determine if there are any signedData layers that include an eSSSecurityLabel signedAttribute. This may include decrypting an EnvelopedData layer to determine if an encapsulated SignedData layer includes an eSSSecurityLabel attribute. The MLA MUST fully process each eSSSecurityLabel attribute found in the various signedData layers, including performing access control checks, before distributing the message to the ML members. The details of the access control checks are beyond the scope of this document. The MLA MUST verify the signature of the signerInfo including the eSSSecurityLabel attribute before using it.
全ての場合において、MLAはeSSSecurityLabel signedAttributeを含む任意たsignedData層が存在するかどうかを決定するために受信されたメッセージのすべての層を解析する必要があります。これは、カプセル化のSignedData層がeSSSecurityLabel属性を含むかどうかを決定するためにEnvelopedDataの層を解読含むことができます。 MLAは、完全MLメンバーにメッセージを配布する前に、アクセス制御チェックを行うことを含む種々たsignedData層で見つかった各eSSSecurityLabel属性を処理しなければなりません。アクセス制御チェックの詳細は、このドキュメントの範囲を超えています。 MLAは、それを使用する前にeSSSecurityLabel属性を含めてのSignerInfoの署名を検証しなければなりません。
In all cases, the MLA MUST sign the message to be sent to the ML members in a new "outer" signedData layer. The MLA MUST add or update an mlExpansionHistory attribute in the "outer" signedData that it creates to document MLA processing. If there was an "outer" signedData layer included in the original message received by the MLA, then the MLA-created "outer" signedData layer MUST include each signed attribute present in the original "outer" signedData layer, unless the MLA explicitly replaces an attribute (such as signingTime or mlExpansionHistory) with a new value.
すべての場合において、MLAは新しい「外側」たsignedData層でMLメンバーに送信するメッセージに署名しなければなりません。 MLAは、MLA処理を文書化するために作成することを「外」たsignedDataにmlExpansionHistory属性を追加または更新しなければなりません。 MLAによって受信された元のメッセージに含まれる「外側」たsignedData層があった場合にMLAを明示的に置き換えられていない限り、その後MLA-作成された「外」たsignedData層は、元の「外側」たsignedData層中に存在する各署名された属性を含まなければなりません新しい値を持つ属性（例えばsigningTimeまたはmlExpansionHistoryなど）。
When an S/MIME message is received by the MLA, the MLA MUST first determine which received signedData layer, if any, is the "outer" signedData layer. To identify the received "outer" signedData layer, the MLA MUST verify the signature and fully process the signedAttributes in each of the outer signedData layers (working from the outside in) to determine if any of them either include an mlExpansionHistory attribute or encapsulate an envelopedData object.
S / MIMEメッセージがMLAによって受信されると、MLAは、まず、「外側」たsignedData層であれば、たsignedData層を受信したかを決定しなければなりません。受信した「外側」たsignedData層を識別するために、MLAは、それらのいずれかのいずれかがmlExpansionHistory属性を含むか、EnvelopedDataのをカプセル化するかどうかを決定するために、署名を検証し、完全に外側たsignedData層（外側から作業）のそれぞれにsignedAttributesのを処理しなければなりませんオブジェクト。
The MLA's search for the "outer" signedData layer is completed when it finds one of the following:
それは次のいずれかを見つけると「外側」たsignedData層のためのMLAの検索が完了しています：
- the "outer" signedData layer that includes an mlExpansionHistory attribute or encapsulates an envelopedData object - an envelopedData layer - the original content (that is, a layer that is neither envelopedData nor signedData).
EnvelopedDataの層 - - 元のコンテンツ（すなわち、EnvelopedDataのたりたsignedDataでもない層である） - mlExpansionHistory属性を含むか、EnvelopedDataのオブジェクトをカプセル化する「外側」たsignedData層。
If the MLA finds an "outer" signedData layer, then the MLA MUST perform the following steps:
MLAが「外」たsignedData層を発見した場合は、MLAは、次の手順を実行する必要があります。
1. Strip off all of the signedData layers that encapsulated the "outer" signedData layer
1.ストリップオフ「外側」たsignedData層をカプセル封入たsignedData層の全て
2. Strip off the "outer" signedData layer itself (after remembering the included signedAttributes)
「外側」たsignedData層自体オフ2.ストリップ（含まsignedAttributesのを思い出した後）
4. Sign the message to be sent to the ML members in a new "outer" signedData layer that includes the signedAttributes (unless explicitly replaced) from the original, received "outer" signedData layer.
（明示的に交換しない限り）4.元からsignedAttributesのを含む新しい「外側」たsignedData層にMLメンバーに送信するメッセージに署名、「外側」たsignedData層を受けました。
If the MLA finds an "outer" signedData layer that includes an mlExpansionHistory attribute AND the MLA subsequently finds an envelopedData layer buried deeper with the layers of the received message, then the MLA MUST strip off all of the signedData layers down to the envelopedData layer (including stripping off the original "outer" signedData layer) and MUST sign the expanded envelopedData in a new "outer" signedData layer that includes the signedAttributes (unless explicitly replaced) from the original, received "outer" signedData layer.
MLAはmlExpansionHistory属性を含む「外側」たsignedData層を見つけ、MLAは、その後、受信したメッセージの層でより深い埋め込みEnvelopedDataの層を見つけ、その後、MLAは（EnvelopedDataの層までたsignedData層の全てを取り除く必要がある場合元の「外側」たsignedData層）の剥離を含む、明示的に置き換えない限りsignedAttributesのを含む新しい「外側」たsignedData層（に展開EnvelopedDataのに署名しなければならない）原稿から、「外側」たsignedData層を受けました。
If the MLA does not find an "outer" signedData layer AND does not find an envelopedData layer, then the MLA MUST sign the original, received message in a new "outer" signedData layer. If the MLA does not find an "outer" signedData AND does find an envelopedData layer then it MUST expand the envelopedData layer, if present, and sign it in a new "outer" signedData layer.
MLAが「外」たsignedData層が見つからず、EnvelopedDataの層が見つからない場合は、MLAは、新たな「外側」たsignedData層で元、受信したメッセージに署名しなければなりません。 MLAが「外」たsignedDataを見つけることができません。また、EnvelopedDataの層を見つけない場合、それは存在する場合、EnvelopedDataの層を展開し、新たな「外側」たsignedData層でそれに署名しなければなりません。
The following examples help explain the rules above:
次の例では、上記の規則を説明するのに役立ちます。
1) A message (S1(Original Content)) (where S = SignedData) is sent to the MLA in which the signedData layer does not include an MLExpansionHistory attribute. The MLA verifies and fully processes the signedAttributes in S1. The MLA decides that there is not an original, received "outer" signedData layer since it finds the original content, but never finds an envelopedData and never finds an mlExpansionHistory attribute. The MLA calculates a new signedData layer, S2, resulting in the following message sent to the ML recipients: (S2(S1(Original Content))). The MLA includes an mlExpansionHistory attribute in S2.
1）メッセージ（S1（オリジナルコンテンツ））（S =のSignedData）がたsignedData層がMLExpansionHistory属性を含まないでMLAに送られます。 MLAを検証し、完全S1でsignedAttributesのを処理します。それは、元のコンテンツを見つけ、決してEnvelopedDataのを見つけ、mlExpansionHistory属性を見つけたことがないので、MLAは、元がないと判断し、「外側」たsignedData層を受け取りました。 （S2（S1（オリジナルコンテンツ）））：MLAは、ML受信者に送信された次のメッセージをもたらす、新しいたsignedData層、S2を算出します。 MLAはS2でmlExpansionHistory属性を含んでいます。
2) A message (S3(S2(S1(Original Content)))) is sent to the MLA in which none of the signedData layers includes an MLExpansionHistory attribute. The MLA verifies and fully processes the signedAttributes in S3, S2 and S1. The MLA decides that there is not an original, received "outer" signedData layer since it finds the original content, but never finds an envelopedData and never finds an mlExpansionHistory attribute. The MLA calculates a new signedData layer, S4, resulting in the following message sent to the ML recipients: (S4(S3(S2(S1(Original Content))))). The MLA includes an mlExpansionHistory attribute in S4.
2）メッセージ（S3（S2（S1（オリジナルコンテンツ））））たsignedData層のいずれもMLExpansionHistory属性が含まれていないいるMLAに送られます。 MLAは、検証と完全S3、S2およびS1でsignedAttributesの処理を行います。それは、元のコンテンツを見つけ、決してEnvelopedDataのを見つけ、mlExpansionHistory属性を見つけたことがないので、MLAは、元がないと判断し、「外側」たsignedData層を受け取りました。 MLAは、ML受信者に送信された次のメッセージをもたらす、新しいたsignedData層、S4を算出する（S4（S3（S2（S1（オリジナルコンテンツ）））））。 MLAはS4でmlExpansionHistory属性を含んでいます。
3) A message (E1(S1(Original Content))) (where E = envelopedData) is sent to the MLA in which S1 does not include an MLExpansionHistory attribute. The MLA decides that there is not an original, received "outer" signedData layer since it finds the E1 as the outer layer. The MLA expands the recipientInformation in E1. The MLA calculates a new signedData layer, S2, resulting in the following message sent to the ML recipients: (S2(E1(S1(Original Content)))). The MLA includes an mlExpansionHistory attribute in S2.
3）メッセージ（E1（S1（オリジナルコンテンツ）））（E = EnvelopedDataの）はS1がMLExpansionHistory属性を含まないでMLAに送信されます。それは外層としてE1を見出すためMLAは、原稿がないと判断し、「外側」たsignedData層を受けました。 MLAはE1でrecipientInformationを拡張します。 MLAは、ML受信者に送信された次のメッセージをもたらす、新しいたsignedData層、S2を算出する（S2（E1（S1（オリジナルコンテンツ））））。 MLAはS2でmlExpansionHistory属性を含んでいます。
4) A message (S2(E1(S1(Original Content)))) is sent to the MLA in which S2 includes an MLExpansionHistory attribute. The MLA verifies the signature and fully processes the signedAttributes in S2. The MLA finds the mlExpansionHistory attribute in S2, so it decides that S2 is the "outer" signedData. The MLA remembers the signedAttributes included in S2 for later inclusion in the new outer signedData that it applies to the message. The MLA strips off S2. The MLA then expands the recipientInformation in E1 (this invalidates the signature in S2 which is why it was stripped). The nMLA calculates a new signedData layer, S3, resulting in the following message sent to the ML recipients: (S3(E1(S1(Original Content)))). The MLA includes in S3 the attributes from S2 (unless it specifically replaces an attribute value) including an updated mlExpansionHistory attribute.
4）メッセージ（S2（E1（S1（オリジナルコンテンツ））））S2がMLExpansionHistory属性を含む、MLAに送られます。 MLAは、署名を検証し、完全S2でsignedAttributesの処理を行います。 MLAはS2でmlExpansionHistory属性を見つけたので、S2は「外側」signedDataであると判断しました。 MLAはsignedAttributesのは、それがメッセージに適用される新しいアウターたsignedDataの後の包含のためS2に含まれて覚えています。 MLAは、S2を取り除き。 MLAは、次いで、（これは、それがストリッピングされた理由であるS2に署名を無効）E1にrecipientInformationを拡大します。 nMLAは、ML受信者に送信された次のメッセージをもたらす、新しいたsignedData層、S3を計算する（S3（E1（S1（オリジナルコンテンツ））））。 MLAはS3で更新mlExpansionHistory属性を含むS2から属性を（それが具体的に属性値を置き換えない限り）を含みます。
5) A message (S3(S2(E1(S1(Original Content))))) is sent to the MLA in which none of the signedData layers include an MLExpansionHistory attribute. The MLA verifies the signature and fully processes the signedAttributes in S3 and S2. When the MLA encounters E1, then it decides that S2 is the "outer" signedData since S2 encapsulates E1. The MLA remembers the signedAttributes included in S2 for later inclusion in the new outer signedData that it applies to the message. The MLA strips off S3 and S2. The MLA then expands the recipientInformation in E1 (this invalidates the signatures in S3 and S2 which is why they were stripped). The MLA calculates a new signedData layer, S4, resulting in the following message sent to the ML recipients: (S4(E1(S1(Original Content)))). The MLA includes in S4 the attributes from S2 (unless it specifically replaces an attribute value) and includes a new mlExpansionHistory attribute.
5）メッセージ（S3（S2（E1（S1（オリジナルコンテンツは）））））たsignedData層のいずれもMLExpansionHistory属性を含まないいるMLAに送られます。 MLAは、署名を検証し、完全S3とS2でsignedAttributesの処理を行います。 MLAは、E1に遭遇すると、それはS2はE1をカプセル化するので、S2は「外側」たsignedDataであると判断します。 MLAはsignedAttributesのは、それがメッセージに適用される新しいアウターたsignedDataの後の包含のためS2に含まれて覚えています。 MLAはS3とS2を取り除き。 MLAは、次いで、（これは、それらがストリッピングされた理由であるS3及びS2で署名を無効）E1にrecipientInformationを拡大します。 MLAは、ML受信者に送信された次のメッセージをもたらす、新しいたsignedData層、S4を算出する（S4（E1（S1（オリジナルコンテンツ））））。 MLAはS4にS2からの属性を含む（これは具体的に属性値を置き換えない場合）と新しいmlExpansionHistory属性を含んでいます。
6) A message (S3(S2(E1(S1(Original Content))))) is sent to the MLA in which S3 includes an MLExpansionHistory attribute. In this case, the MLA verifies the signature and fully processes the signedAttributes in S3. The MLA finds the mlExpansionHistory in S3, so it decides that S3 is the "outer" signedData. The MLA remembers the signedAttributes included in S3 for later inclusion in the new outer signedData that it applies to the message. The MLA keeps on parsing encapsulated layers because it must determine if there are any eSSSecurityLabel attributes contained within. The MLA verifies the signature and fully processes the signedAttributes in S2. When the MLA encounters E1, then it strips off S3 and S2. The MLA then expands the recipientInformation in E1 (this invalidates the signatures in S3 and S2 which is why they were stripped). The MLA calculates a new signedData layer, S4, resulting in the following message sent to the ML recipients: (S4(E1(S1(Original Content)))). The MLA includes in S4 the attributes from S3 (unless it specifically replaces an attribute value) including an updated mlExpansionHistory attribute.
6）メッセージ（S3（S2（E1（S1（オリジナルコンテンツは）））））S3がMLExpansionHistory属性を含む、MLAに送られます。この場合には、MLAは、署名を検証し、完全S3でsignedAttributesの処理を行います。 MLAはS3にmlExpansionHistoryを見つけたので、S3は「外側」signedDataであると判断しました。 MLAはsignedAttributesのは、それがメッセージに適用される新しいアウターたsignedDataの後の包含のためS3に含まれて覚えています。内に含まれる任意のeSSSecurityLabel属性がある場合、それは判断しなければならないので、MLAは、カプセル化層の構文解析を続けています。 MLAは、署名を検証し、完全S2でsignedAttributesの処理を行います。 MLAは、E1に遭遇すると、それはS3とS2を取り除き。 MLAは、次いで、（これは、それらがストリッピングされた理由であるS3及びS2で署名を無効）E1にrecipientInformationを拡大します。 MLAは、ML受信者に送信された次のメッセージをもたらす、新しいたsignedData層、S4を算出する（S4（E1（S1（オリジナルコンテンツ））））。 MLAはS4で更新mlExpansionHistory属性を含むS3から属性を（それが具体的に属性値を置き換えない限り）を含みます。
The processing used depends on the type of the outermost layer of the message. There are three cases for the type of the outermost data:
使用される処理は、メッセージの最も外側の層の種類に依存します。最も外側のデータのタイプには3つのケースがあります。
- EnvelopedData - SignedData - data
- EnvelopedDataの - のSignedData - データ
1. The MLA locates its own RecipientInfo and uses the information it contains to obtain the message key.
1. MLAは、独自のRecipientInfoを検索し、メッセージ鍵を取得するために含まれている情報を使用します。
2. The MLA removes the existing recipientInfos field and replaces it with a new recipientInfos value built from RecipientInfo structures created for each member of the mailing list. The MLA also removes the existing originatorInfo field and replaces it with a new originatorInfo value built from information describing the MLA.
2. MLAは、既存のrecipientInfosフィールドを削除し、メーリングリストの各メンバーのために作成したのRecipientInfo構造から構築された新しいのrecipientInfos値に置き換えます。 MLAは、既存のoriginatorInfoフィールドを削除し、MLAを記述した情報から構築された新しいoriginatorInfo値に置き換えます。
3. The MLA encapsulates the expanded encrypted message in a SignedData block, adding an mlExpansionHistory attribute as described in the "Mail List Expansion" section to document the expansion.
3. MLAは、拡張を文書化するために「メールリスト展開」セクションで説明したようにmlExpansionHistory属性を追加すること、のSignedDataブロックに拡張暗号化されたメッセージをカプセル化します。
4. The MLA signs the new message and delivers the updated message to mail list members to complete MLA processing.
4. MLAは新しいメッセージに署名し、MLA処理を完了するために、メールリストのメンバーに更新メッセージを配信します。
MLA processing of multi-layer messages depends on the type of data in each of the layers. Step 3 below specifies that different processing will take place depending on the type of CMS message that has been signed. That is, it needs to know the type of data at the next inner layer, which may or may not be the innermost layer.
多層メッセージのMLA処理層のそれぞれにおけるデータのタイプに依存します。ステップ3は、以下の異なる処理が署名されたCMSメッセージの種類に応じて行われることを指定します。つまり、それは、または最も内側の層であってもなくてもよい次の内層におけるデータのタイプを知る必要があります。
1. The MLA verifies the signature value found in the outermost SignedData layer associated with the signed data. MLA processing of the message terminates if the message signature is invalid.
1. MLAは、署名されたデータに関連付けられている最も外側のSignedData層で見つかった署名値を検証します。メッセージの署名が無効な場合、メッセージのMLA処理が終了します。
2. If the outermost SignedData layer includes a signed mlExpansionHistory attribute, the MLA checks for an expansion loop as described in the "Detecting Mail List Expansion Loops" section, then go to step 3. If the outermost SignedData layer does not include a signed mlExpansionHistory attribute, the MLA signs the whole message (including this outermost SignedData layer that doesn't have an mlExpansionHistory attribute), and delivers the updated message to mail list members to complete MLA processing.
最も外側のSignedData層が署名mlExpansionHistory属性「を検出メールリスト拡張ループ」のセクションで説明したように、膨張ループのMLAのチェックが含まれている場合、最も外側のSignedData層が署名mlExpansionHistoryが含まれていない場合2.次にステップ3に進み属性は、MLAは（mlExpansionHistory属性を持っていない、この最も外側のSignedData層を含む）全体のメッセージに署名し、そしてMLA処理を完了するために、メールリストのメンバーに更新メッセージを配信します。
3. Determine the type of the data that has been signed. That is, look at the type of data on the layer just below the SignedData, which may or may not be the "innermost" layer. Based on the type of data, perform either step 3.1 (EnvelopedData), step 3.2 (SignedData), or step 3.3 (all other types).
3.署名されたデータのタイプを決定します。つまり、または「最も内側」層であってもなくてもよいだけでSignedDataの下の層、上のデータの種類を見ています。データの種類に基づいて、ステップ3.1（EnvelopedDataの）、ステップ3.2（のSignedData）、またはステップ3.3（すべての他のタイプ）のいずれかを行います。
3.1. If the signed data is EnvelopedData, the MLA performs
expansion processing of the encrypted message as
described previously. Note that this process invalidates the
signature value in the outermost SignedData layer associated
with the original encrypted message. Proceed to section 3.2
with the result of the expansion.
3.2. If the signed data is SignedData, or is the result of expanding an EnvelopedData block in step 3.1:
3.2. 署名されたデータはSignedDataのある、またはステップ3.1でEnvelopedDataのブロックを拡大した結果である場合：
3.2.1. The MLA strips the existing outermost SignedData layer
after remembering the value of the mlExpansionHistory
and all other signed attributes in that layer, if
present.
3.2.2. If the signed data is EnvelopedData (from step 3.1), the MLA encapsulates the expanded encrypted message in a new outermost SignedData layer. On the other hand, if the signed data is SignedData (from step 3.2), the MLA encapsulates the signed data in a new outermost SignedData layer.
3.2.2. 署名されたデータがEnvelopedDataの（ステップ3.1）である場合、MLAは新しい最も外側のSignedData層に展開暗号化されたメッセージをカプセル化します。署名されたデータのSignedData（ステップ3.2）であり、一方、MLAは新しい最も外側のSignedData層で署名されたデータをカプセル化します。
3.2.3. The outermost signedData layer created by the MLA replaces the original outermost signedData layer. The MLA MUST create an signed attribute list for the new outermost signedData layer which MUST include each signed attribute present in the original outermost signedData layer, unless the MLA explicitly replaces one or more particular attributes with new value. A special case is the mlExpansionHistory attribute. The MLA MUST add an mlExpansionHistory signed attribute to the outer signedData layer as follows:
3.2.3. MLAによって作成された最も外側たsignedData層は、元の最も外側たsignedData層を置き換えます。 MLAは、MLAは、明示的に新たな値を有する1つまたは複数の特定の属性を置換しない限り、元の最外たsignedData層中に存在する各署名された属性を含まなければならない新しい最外たsignedData層のための署名された属性リストを作成する必要があります。特殊なケースはmlExpansionHistory属性です。 MLAはmlExpansionHistoryを追加しなければならない、次のように外側たsignedData層に属性を署名しました。
3.2.3.1. If the original outermost SignedData layer
included an mlExpansionHistory attribute, the
attribute's value is copied and updated with the
current ML expansion information as described in
the "Mail List Expansion" section.
3.2.3.2. If the original outermost SignedData layer did not include an mlExpansionHistory attribute, a new attribute value is created with the current ML expansion information as described in the "Mail List Expansion" section.
3.2.3.2。オリジナルの最も外側のSignedData層がmlExpansionHistory属性が含まれていなかった場合は、新しい属性値が「メールリスト展開」セクションで説明したように、現在のML拡張情報を使用して作成されます。
3.3.1. The MLA encapsulates the received signedData object in
an outer SignedData object, and adds an
mlExpansionHistory attribute to the outer SignedData
object containing the current ML expansion information
as described in the "Mail List Expansion" section.
4. The MLA signs the new message and delivers the updated message to mail list members to complete MLA processing.
4. MLAは新しいメッセージに署名し、MLA処理を完了するために、メールリストのメンバーに更新メッセージを配信します。
A flow chart for the above steps would be:
上記の手順のフローチャートは次のようになります。
1. Has a valid signature? YES -> 2. NO -> STOP. 2. Does outermost SignedData layer contain mlExpansionHistory? YES -> Check it, then -> 3. NO -> Sign message (including outermost SignedData that doesn't have mlExpansionHistory), deliver it, STOP. 3. Check type of data just below outermost SignedData.
1.有効な署名をしていますか？ YES - > 2. NO - > STOP。 2.最も外側のSignedData層がmlExpansionHistoryが含まれていますか？ YES - > 3. NO - - >そして、それを確認してください（mlExpansionHistoryを持っていない、最も外側のSignedDataを含む）>ログインメッセージ、それを実現し、STOP。ただ、最も外側のSignedData以下のデータの3.確認タイプ。
EnvelopedData -> 3.1. SignedData -> 3.2. all others -> 3.3. 3.1. Expand the encrypted message, then -> 3.2. 3.2. -> 3.2.1. 3.2.1. Strip outermost SignedData layer, note value of mlExpansionHistory and other signed attributes, then -> 3.2.2. 3.2.2. Encapsulate in new signature, then -> 3.2.3. 3.2.3. Create new signedData layer. Was there an old mlExpansionHistory? YES -> copy the old mlExpansionHistory values, then -> 4. NO -> create new mlExpansionHistory value, then -> 4. 3.3. Encapsulate in a SignedData layer and add an mlExpansionHistory attribute, then -> 4. 4. Sign message, deliver it, STOP.
EnvelopedDataの - > 3.1。 SignedData - > 3.2。他のすべて - > 3.3。 3.1。その後、暗号化されたメッセージを展開 - > 3.2。 3.2。 - > 3.2.1。 3.2.1。 > 3.2.2 - 次に、最外のSignedData層、mlExpansionHistoryの音符値と他の署名された属性を、ストリップ。 3.2.2。その後、新しい署名にカプセル化 - > 3.2.3。 3.2.3。新たsignedData層を作成します。古いmlExpansionHistoryはありましたか？ YES - >その後、古いmlExpansionHistory値をコピー - > 4. NO - >新しいmlExpansionHistory値を作成し、それから - > 4. 3.3。 SignedData層中にカプセル化し、mlExpansionHistory属性を追加し、 - > 4. 4.ログインメッセージ、それを実現し、STOP。
1. The MLA encapsulates the message in a SignedData layer, and adds an mlExpansionHistory attribute containing the current ML expansion information as described in the "Mail List Expansion" section.
1. MLAはSignedDataの層にメッセージをカプセル化し、そして「メールリスト拡張」セクションで説明したように現在のML拡張情報を含むmlExpansionHistory属性を付加します。
2. The MLA signs the new message and delivers the updated message to mail list members to complete MLA processing.
2. MLAは新しいメッセージに署名し、MLA処理を完了するために、メールリストのメンバーに更新メッセージを配信します。
If a mailing list (B) is a member of another mailing list (A), list B often needs to propagate forward the mailing list receipt policy of A. As a general rule, a mailing list should be conservative in propagating forward the mailing list receipt policy because the ultimate recipient need only process the last item in the ML expansion history. The MLA builds the expansion history to meet this requirement.
メーリングリスト（B）は別のメーリングリスト（A）のメンバーである場合、リストBは、多くの場合、原則としてAのメーリングリスト受領ポリシーを前方に伝播する必要がある、メーリングリストは、前方メーリングリストを伝播に保守的であるべきです領収書ポリシー最終的な受信者のみがMLの拡張の歴史の中で最後の項目を処理する必要があるため。 MLAは、この要件を満たすために拡張履歴を構築します。
The following table describes the outcome of the union of mailing list A's policy (the rows in the table) and mailing list B's policy (the columns in the table).
次の表は、メーリングリストAのポリシー（テーブルの行）と、メーリングリストBのポリシー（テーブルの列）の労働組合の結果を説明します。
| B's policy
A's policy | none insteadOf inAdditionTo missing
-----------------------------------------------------------------------
none | none none none none
insteadOf | none insteadOf(B) *1 insteadOf(A)
inAdditionTo | none insteadOf(B) *2 inAdditionTo(A)
missing | none insteadOf(B) inAdditionTo(B) missing
*1 = insteadOf(insteadOf(A) + inAdditionTo(B)) *2 = inAdditionTo(inAdditionTo(A) + inAdditionTo(B))
* 1 =の代わりに（代わりに、（A）+ inAdditionTo（B））* 2 = inAdditionTo（I AdditionTo（A）+ inAdditionTo（B））
An mlExpansionHistory attribute value has ASN.1 type MLExpansionHistory. If there are more than ub-ml-expansion-history mailing lists in the sequence, the receiving agent should provide notification of the error to a human mail list administrator. The mail list administrator is responsible for correcting the overflow condition.
mlExpansionHistory属性値はASN.1タイプMLExpansionHistoryを持っています。 UB-ML-拡張の歴史よりも多くのメーリングリストが連続して存在する場合、受信エージェントは、人間のメールリストの管理者にエラーの通知を提供する必要があります。メールリストの管理者は、オーバーフロー状態を補正するための責任があります。
MLExpansionHistory ::= SEQUENCE
SIZE (1..ub-ml-expansion-history) OF MLData
id-aa-mlExpandHistory OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 3}
ub-ml-expansion-history INTEGER ::= 64
MLData contains the expansion history describing each MLA that has processed a message. As an MLA distributes a message to members of an ML, the MLA records its unique identifier, date and time of expansion, and receipt policy in an MLData structure.
MLDataは、メッセージを処理した各MLAを説明する展開履歴を含んでいます。 MLAはMLのメンバーにメッセージを配信するように、MLAはMLData構造におけるそのユニークな識別子、膨張の日時、およびレシート・ポリシーを記録します。
MLData ::= SEQUENCE {
mailListIdentifier EntityIdentifier,
expansionTime GeneralizedTime,
mlReceiptPolicy MLReceiptPolicy OPTIONAL }
EntityIdentifier ::= CHOICE {
issuerAndSerialNumber IssuerAndSerialNumber,
subjectKeyIdentifier SubjectKeyIdentifier }
The receipt policy of the ML can withdraw the originator's request for the return of a signed receipt. However, if the originator of the message has not requested a signed receipt, the MLA cannot request a signed receipt. In the event that a ML's signed receipt policy supersedes the originator's request for signed receipts, such that the originator will not receive any signed receipts, then the MLA MAY inform the originator of that fact.
MLの領収書ポリシーは、署名された領収書の返還のための発信者の要求を撤回することができます。メッセージの発信元が署名した領収書を要求していない場合は、MLAは、署名された領収書を要求することはできません。 MLの署名領収書ポリシーが署名した領収書のための発信者の要求を優先した場合に、発信者が任意の署名領収書を受け取らないように、そして、MLAは、その事実の発信元を通知することができます。
When present, the mlReceiptPolicy specifies a receipt policy that supersedes the originator's request for signed receipts. The policy can be one of three possibilities: receipts MUST NOT be returned (none); receipts should be returned to an alternate list of recipients, instead of to the originator (insteadOf); or receipts should be returned to a list of recipients in addition to the originator (inAdditionTo).
存在する場合、mlReceiptPolicyは、署名された領収書のための発信者の要求に取って代わる領収書ポリシーを指定します。ポリシーは、三つの可能性のいずれかになります。領収書は、（なし）返されないであってはなりません。領収書の代わりに、発信者（insteadOf）に、受信者の代替リストに戻さなければなりません。または領収書は、発信（inAdditionTo）に加えて、受信者のリストに返されるべきです。
MLReceiptPolicy ::= CHOICE {
none [0] NULL,
insteadOf [1] SEQUENCE SIZE (1..MAX) OF GeneralNames,
inAdditionTo [2] SEQUENCE SIZE (1..MAX) OF GeneralNames }
Concerns have been raised over the fact that the certificate which the signer of a CMS SignedData object desired to be bound into the verification process of the SignedData object is not cryptographically bound into the signature itself. This section addresses this issue by creating a new attribute to be placed in the signed attributes section of a SignerInfo object.
懸念はCMS SignedDataオブジェクトの署名者がSignedDataオブジェクトの検証プロセスに縛られることを望ま証明書は暗号署名自体に結合していないという事実の上に提起されています。このセクションでは、のSignerInfoオブジェクトの署名属性セクションに配置される新しい属性を作成することで、この問題に対処しています。
This section also presents a description of a set of possible attacks dealing with the substitution of one certificate to verify the signature for the desired certificate. A set of ways for preventing or addressing these attacks is presented to deal with the simplest of the attacks.
このセクションでは、目的の証明書のための署名を検証するために、1つの証明書の置換を扱うことができ、攻撃のセットの説明を提示しています。予防またはこれらの攻撃に対処するための方法のセットは攻撃の最も簡単に対処するために提示されます。
Authorization information can be used as part of a signature verification process. This information can be carried in either attribute certificates and other public key certificates. The signer needs to have the ability to restrict the set of certificates used in the signature verification process, and information needs to be encoded so that is covered by the signature on the SignedData object. The methods in this section allow for the set of authorization certificates to be listed as part of the signing certificate attribute.
許可情報は、署名検証プロセスの一部として使用することができます。この情報は、属性証明書および他の公開鍵証明書のいずれかで行うことができます。署名者は、署名検証プロセスで使用される証明書のセットを制限する機能を持っている必要があり、情報は、それはSignedDataオブジェクトの署名によって覆われるように符号化される必要があります。このセクションの方法には、署名証明書の属性の一部としてリストされるように、認証証明書のセットを可能とします。
Explicit certificate policies can also be used as part of a signature verification process. If a signer desires to state an explicit certificate policy that should be used when validating the signature, that policy needs to be cryptographically bound into the signing process. The methods described in this section allows for a set of certificate policy statements to be listed as part of the signing certificate attribute.
明示的な証明書ポリシーはまた、署名検証プロセスの一部として使用することができます。署名者が署名を検証する際に使用されるべき明示的な証明書ポリシーを述べることを望む場合、そのポリシーは、暗号署名プロセスにバインドする必要があります。このセクションで説明する方法は、署名証明書の属性の一部としてリストされる証明書ポリシーステートメントのセットを可能にします。
At least three different attacks can be launched against a possible signature verification process by replacing the certificate or certficates used in the signature verification process.
少なくとも3回の異なる攻撃は、署名検証プロセスで使用される証明書またはcertficatesを置き換えることによって可能署名検証処理に対して起動することができます。
The first attack deals with simple substitution of one certificate for another certificate. In this attack, the issuer and serial number in the SignerInfo is modified to refer to a new certificate. This new certificate is used during the signature verification process.
最初の攻撃は、別の証明書のための証明書の簡単な置換を扱っています。この攻撃では、のSignerInfoで発行者およびシリアル番号は、新しい証明書を参照するように変更されます。この新しい証明書は、署名の検証プロセス中に使用されます。
The first version of this attack is a simple denial of service attack where an invalid certificate is substituted for the valid certificate. This renders the message unverifiable, as the public key in the certificate no longer matches the private key used to sign the message.
この攻撃の最初のバージョンは無効な証明書が有効な証明書を置換するサービス攻撃の簡単な否定です。証明書の公開鍵は、もはやメッセージの署名に使用する秘密鍵と一致するように、これは、メッセージが検証不可能レンダリングしません。
The second version is a substitution of one valid certificate for the original valid certificate where the public keys in the certificates match. This allows the signature to be validated under potentially different certificate constraints than the originator of the message intended.
第二のバージョンは、証明書内の公開鍵が一致して、元の有効な証明書のための1つの有効な証明書の置換です。これは、署名が意図されたメッセージの発信者よりも潜在的に異なる証明書の制約の下で検証されることを可能にします。
The second attack deals with a certificate authority (CA) re-issuing the signing certificate (or potentially one of its certificates). This attack may start becoming more frequent as Certificate Authorities reissue their own root certificates, or as certificate authorities change policies in the certificate while reissuing their root certificates. This problem also occurs when cross certificates (with potentially different restrictions) are used in the process of verifying a signature.
認証局（CA）の再発行署名証明書（または潜在的にその証明書のいずれか）を有する第二の攻撃を扱っています。この攻撃は、そのルート証明書を再発行しながら、認証局が証明書にポリシーを変更すると証明機関が独自のルート証明書を再発行、またはとしてより頻繁になってきて起動することがあります。 （潜在的に異なる制約を有する）は、クロス証明書が署名を検証するプロセスで使用される場合、この問題が発生します。
The third attack deals with a rogue entity setting up a certificate authority that attempts to duplicate the structure of an existing CA. Specifically, the rogue entity issues a new certificate with the same public keys as the signer used, but signed by the rogue entity's private key.
第三の攻撃は、既存のCAの構造を複製しようとする認証局を設定する不正なエンティティを扱います具体的には、不正なエンティティが使用され、署名者と同じ公開鍵で新しい証明書を発行したが、不正なエンティティの秘密鍵で署名しました。
This document does not attempt to solve all of the above attacks; however, a brief description of responses to each of the attacks is given in this section.
この文書では、上記の攻撃のすべてを解決しようとしません。しかし、攻撃のそれぞれに対する応答の簡単な説明は、このセクションに記載されています。
The denial of service attack cannot be prevented. After the certificate identifier has been modified in transit, no verification of the signature is possible. There is also no way to automatically identify the attack because it is indistinguishable from a message corruption.
サービス拒否攻撃を防止することができません。証明書識別子が転送中に変更された後、署名のない検証が不可能です。それはメッセージの破損と区別できないため、自動的に攻撃を特定する方法もありません。
The substitution of a valid certificate can be responded to in two different manners. The first is to make a blanket statement that the use of the same public key in two different certificates is bad practice and has to be avoided. In practice, there is no practical way to prevent users from getting new certificates with the same public keys, and it should be assumed that they will do this. Section 5.4 provides a new attribute that can be included in the SignerInfo signed attributes. This binds the correct certificate identifier into the signature. This will convert the attack from a potentially successful one to simply a denial of service attack.
有効な証明書の置換は、二つの異なる方法でに対応することができます。最初は、二つの異なる証明書で同じ公開鍵の使用は悪い習慣で、避けなければならない毛布文を作ることです。実際には、そこに同じ公開鍵で新しい証明書を取得してからユーザーを防ぐために、実用的な方法ではありません、彼らがこれを行うことが想定されなければなりません。 5.4節はのSignerInfo署名の属性に含めることのできる新しい属性を提供します。これは、署名に正しい証明書識別子を結合します。これは、サービス攻撃の単純拒否に潜在的に成功したものからの攻撃を変換します。
A CA should never reissue a certificate with different attributes. Certificate Authorities that do so are following poor practices and cannot be relied on. Using the hash of the certificate as the reference to the certificate prevents this attack for end-entity certificates.
CAは、異なる属性を持つ証明書を再発行することはありません。そうする認証局は、以下の貧しい慣行があると当てにすることはできません。証明書への参照として、証明書のハッシュを使用すると、エンドエンティティ証明書のこの攻撃を防ぐことができます。
Preventing the attack based on reissuing of CA certificates would require a substantial change to the usage of the signingCertificate attribute presented in section 5.4. It would require that ESSCertIDs would need to be included in the attribute to represent the issuer certificates in the signer's certification path. This presents problems when the relying party is using a cross-certificate as part of its authentication process, and this certificate does not appear on the list of certificates. The problems outside of a closed PKI make the addition of this information prone to error, possibly causing the rejection of valid chains.
CA証明書の再発行に基づいて攻撃を防ぐことは、セクション5.4で提示signingCertificate属性の利用に実質的な変化が必要となります。それはESSCertIDsは、署名者の証明書パスでの発行者証明書を表すために、属性に含まれる必要があることが必要となります。依存者はその認証プロセスの一環として、クロス証明書を使用している、そしてこの証明書は、証明書のリストに表示されないとき、これは問題を提起します。閉じられたPKIの外側の問題は、おそらく有効なチェーンの拒絶反応を引き起こし、エラーこの情報の追加が発生しやすい作り。
The best method of preventing this attack is to avoid trusting the rogue CA. The use of the hash to identify certificates prevents the use of end-entity certificates from the rogue authority. However the only true way to prevent this attack is to never trust the rogue CA.
この攻撃を防止する最善の方法は、不正なCAを信頼しないようにすることです証明書を識別するためにハッシュを使用すると、不正な権威からのエンドエンティティ証明書の使用を防止します。しかし、この攻撃を防ぐための唯一の真の方法は、不正なCAを信頼したことがないことです
Some applications require that additional information be used as part of the signature validation process. In particular, authorization information from attribute certificates and other public key certificates or policy identifiers provide additional information about the abilities and intent of the signer. The signing certificate attribute described in Section 5.4 provides the ability to bind this context information as part of the signature.
一部のアプリケーションでは、追加情報が、署名検証プロセスの一部として使用されることを必要とします。具体的には、属性証明書および他の公開鍵証明書またはポリシー識別子から認証情報は、署名者の能力や意図に関する追加情報を提供しています。セクション5.4で説明署名証明書属性は、署名の一部として、このコンテキスト情報を結合する能力を提供します。
Some applications require that authorization information found in attribute certificates and/or other public key certificates be validated. This validation requires that the application be able to find the correct certificates to perform the verification process; however there is no list of the certificates to used in a SignerInfo object. The sender has the ability to include a set of attribute certificates and public key certificates in a SignedData object. The receiver has the ability to retrieve attribute certificates and public key certificates from a directory service. There are some circumstances where the signer may wish to limit the set of certificates that may be used in verifying a signature. It is useful to be able to list the set of certificates the signer wants the recipient to use in validating the signature.
一部のアプリケーションは、属性証明書および/またはその他の公開鍵証明書で見つかった認証情報を検証する必要があります。この検証は、アプリケーションが検証プロセスを実行するために、正しい証明書を見つけることができることが必要です。しかし、のSignerInfoオブジェクトで使用する証明書のないリストはありません。送信者はSignedDataオブジェクトの属性証明書と公開鍵証明書のセットを含める機能を持っています。受信機は、ディレクトリサービスから属性証明書と公開鍵証明書を取得する機能を持っています。署名者は、署名の検証に使用することができる証明書のセットを制限することを望むかもしれないいくつかの状況があります。署名者が受信者が署名の検証に使用したい証明書のセットを一覧表示することができると便利です。
A related aspect of the certificate binding is the issue of multiple certification paths. In some instances, the semantics of a certificate in its use with a message may depend on the Certificate Authorities and policies that apply. To address this issue, the signer may also wish to bind that context under the signature. While this could be done by either signing the complete certification path or a policy ID, only a binding for the policy ID is described here.
結合の証明書の関連する態様は、複数の認証パスの問題です。いくつかの例では、メッセージとその使用中の証明書のセマンティクスが適用されます認証局との方針に依存してもよいです。この問題に対処するために、署名者はまた、署名の下にそのコンテキストをバインドしたい場合があります。これは署名の完全な証明書パスまたはポリシーIDのいずれかによって行うことができますが、唯一のポリシーIDのバインディングがここに記載されています。
The signing certificate attribute is designed to prevent the simple substitution and re-issue attacks, and to allow for a restricted set of authorization certificates to be used in verifying a signature.
署名証明書属性は、単純な置換と再発行攻撃を防ぐために、署名の検証に使用する認証証明書の制限されたセットを可能にするように設計されています。
The definition of SigningCertificate is
SigningCertificateの定義は、
SigningCertificate ::= SEQUENCE {
certs SEQUENCE OF ESSCertID,
policies SEQUENCE OF PolicyInformation OPTIONAL
}
id-aa-signingCertificate OBJECT IDENTIFIER ::= { iso(1)
member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
smime(16) id-aa(2) 12 }
The first certificate identified in the sequence of certificate identifiers MUST be the certificate used to verify the signature. The encoding of the ESSCertID for this certificate SHOULD include the issuerSerial field. If other constraints ensure that issuerAndSerialNumber will be present in the SignerInfo, the issuerSerial field MAY be omitted. The certificate identified is used during the signature verification process. If the hash of the certificate does not match the certificate used to verify the signature, the signature MUST be considered invalid.
証明書識別子のシーケンスで同定された最初の証明書は、署名を検証するために使用される証明書でなければなりません。この証明書のESSCertIDのエンコーディングはissuerSerialフィールドを含むべきです。他の制約がissuerAndSerialNumberがのSignerInfoで存在するであろうことを確実にした場合、issuerSerialフィールドは省略されるかもしれません。同定された証明書は、署名検証処理の間に使用されます。証明書のハッシュが署名を検証するために使用される証明書と一致しない場合は、署名が無効であると見なされなければなりません。
If more than one certificate is present in the sequence of ESSCertIDs, the certificates after the first one limit the set of authorization certificates that are used during signature validation. Authorization certificates can be either attribute certificates or normal certificates. The issuerSerial field (in the ESSCertID structure) SHOULD be present for these certificates, unless the client who is validating the signature is expected to have easy access to all the certificates requred for validation. If only the signing certificate is present in the sequence, there are no restrictions on the set of authorization certificates used in validating the signature.
複数の証明書がESSCertIDsの配列中に存在する場合、最初の後の証明書は、署名検証の際に使用される許可証明書のセットを制限します。認証証明書は、属性証明書または通常の証明書のいずれかになります。署名を検証しているクライアントは、検証のためにrequredすべての証明書への容易なアクセスを持つことが期待されていない限り（ESSCertID構造の）issuerSerialフィールドは、これらの証明書のために存在しなければなりません。唯一の署名証明書は、配列中に存在する場合は、署名の検証に使用される許可証明書のセットに制限はありません。
The sequence of policy information terms identifies those certificate policies that the signer asserts apply to the certificate, and under which the certificate should be relied upon. This value suggests a policy value to be used in the relying party's certification path validation.
ポリシー情報項目の順序は、署名者が証明書に適用されますアサートそれらの証明書ポリシーを識別し、その下で証明書が依拠しなければなりません。この値は、証明書利用者の証明書パスの検証に使用されるポリシーの値を示唆しています。
If present, the SigningCertificate attribute MUST be a signed attribute; it MUST NOT be an unsigned attribute. CMS defines SignedAttributes as a SET OF Attribute. A SignerInfo MUST NOT include multiple instances of the SigningCertificate attribute. CMS defines the ASN.1 syntax for the signed attributes to include attrValues SET OF AttributeValue. A SigningCertificate attribute MUST include only a single instance of AttributeValue. There MUST NOT be zero or multiple instances of AttributeValue present in the attrValues SET OF AttributeValue.
存在する場合、SigningCertificate属性は署名している属性でなければなりません。それは未署名の属性にすることはできません。 CMSは、属性の集合としてsignedAttributesのを定義します。 SignerInfoはSigningCertificate属性の複数のインスタンスを含んではいけません。 CMSはAttributeValueの一連のattrValuesを含めるために署名した属性のASN.1構文を定義します。 SigningCertificate属性はAttributeValueのの単一のインスタンスだけを含まなければなりません。 AttributeValueのOF attrValuesセットに存在するAttributeValueのゼロか複数のインスタンスがあってはなりません。
The best way to identify certificates is an often-discussed issue. [CERT] has imposed a restriction for SignedData objects that the issuer DN must be present in all signing certificates. The issuer/serial number pair is therefore sufficient to identify the correct signing certificate. This information is already present, as part of the SignerInfo object, and duplication of this information would be unfortunate. A hash of the entire certificate serves the same function (allowing the receiver to verify that the same certificate is being used as when the message was signed), is smaller, and permits a detection of the simple substitution attacks.
証明書を特定するための最良の方法は、多くの場合、議論の問題です。 【CERTは]のSignedDataのための制限は発行者DNは、すべての署名証明書内に存在しなければならないことオブジェクト課しています。発行者/シリアル番号のペアが正しい署名証明書を識別することは十分です。この情報は、のSignerInfoオブジェクトの一部として、既に存在し、この情報の複製は不幸なことであろう。全体証明書のハッシュが小さい、（受信機が同一の証明書は、メッセージが署名されたときのように使用されていることを確認することを可能にする）同じ機能を果たし、そして単純な置換攻撃の検出を可能にします。
Attribute certificates and additional public key certificates containing authorization information do not have an issuer/serial number pair represented anywhere in a SignerInfo object. When an attribute certificate or an additional public key certificate is not included in the SignedData object, it becomes much more difficult to get the correct set of certificates based only on a hash of the certificate. For this reason, these certificates SHOULD be identified by the IssuerSerial object.
証明書とのSignerInfoオブジェクトの任意の場所で表さ発行者/シリアル番号のペアを持っていない認証情報を含む追加の公開鍵証明書を属性。属性証明書または追加の公開鍵証明書がSignedDataオブジェクトに含まれていない場合には、それだけで、証明書のハッシュに基づいて証明書の正しいセットを取得するためにはるかに困難になります。このため、これらの証明書はIssuerSerialオブジェクトによって特定されるべきです。
This document defines a certificate identifier as:
この文書では、証明書の識別子としてを定義します。
ESSCertID ::= SEQUENCE {
certHash Hash,
issuerSerial IssuerSerial OPTIONAL
}
Hash ::= OCTET STRING -- SHA1 hash of entire certificate
IssuerSerial ::= SEQUENCE {
issuer GeneralNames,
serialNumber CertificateSerialNumber
}
When creating an ESSCertID, the certHash is computed over the entire DER encoded certificate including the signature. The issuerSerial would normally be present unless the value can be inferred from other information.
ESSCertIDを作成する場合、CERTHASHは署名を含む全体のDER符号化された証明書にわたって計算されます。値は他の情報から推測することができない限りissuerSerialは、通常存在するであろう。
When encoding IssuerSerial, serialNumber is the serial number that uniquely identifies the certificate. For non-attribute certificates, the issuer MUST contain only the issuer name from the certificate encoded in the directoryName choice of GeneralNames. For attribute certificates, the issuer MUST contain the issuer name field from the attribute certificate.
IssuerSerialをコードする場合、serialNumberを一意の証明書を識別するシリアル番号です。非属性証明書については、発行者はGeneralNamesのdirectoryNameでの選択でエンコードされた証明書からのみ発行者名を含まなければなりません。属性証明書については、発行者は、属性証明書から発行者名フィールドを含まなければなりません。
All security considerations from [CMS] and [SMIME3] apply to applications that use procedures described in this document.
[CMS]と[SMIME3]からすべてのセキュリティ上の考慮事項は、この文書に記載されている手順を使用するアプリケーションに適用されます。
As stated in Section 2.3, a recipient of a receipt request must not send back a reply if it cannot validate the signature. Similarly, if there conflicting receipt requests in a message, the recipient must not send back receipts, since an attacker may have inserted the conflicting request. Sending a signed receipt to an unvalidated sender can expose information about the recipient that it may not want to expose to unknown senders.
2.3節で述べたように、それは、署名を検証できない場合は、領収書要求の受信者が返信を返送してはいけません。メッセージ内の受信要求が競合した場合、攻撃者が競合する要求を挿入した可能性があるので、同様に、受信者は、領収書を返送してはなりません。未検証の送信者に署名した領収書を送信すると、それは未知の送信者に公開したくないかもしれない受信者に関する情報を公開することができます。
Senders of receipts should consider encrypting the receipts to prevent a passive attacker from gleaning information in the receipts.
領収書の送信者は、領収書に記載されている情報を落穂拾いから受動的攻撃を防ぐために、領収書の暗号化を検討すべきです。
Senders must not rely on recipients' processing software to correctly process security labels. That is, the sender cannot assume that adding a security label to a message will prevent recipients from viewing messages the sender doesn't want them to view. It is expected that there will be many S/MIME clients that will not understand security labels but will still display a labelled message to a recipient.
送信者は、正しくセキュリティラベルを処理するために受信者の処理ソフトウェアに依存してはいけません。つまり、送信者がメッセージにセキュリティラベルを追加すると、送信者がそれらを表示したくないメッセージを表示してから受信者を防ぐことができますと仮定することはできません。セキュリティラベルを理解することはありませんが、それでも受信者にラベルされたメッセージが表示されます多くのS / MIMEクライアントが存在するであろうことが期待されます。
A receiving agent that processes security labels must handle the content of the messages carefully. If the agent decides not to show the message to the intended recipient after processing the security label, the agent must take care that the recipient does not accidentally see the content at a later time. For example, if an error response sent to the originator contains the content that was hidden from the recipient, and that error response bounces back to the sender due to addressing errors, the original recipient can possibly see the content since it is unlikely that the bounce message will have the proper security labels.
セキュリティラベルを処理受信エージェントは、慎重にメッセージの内容を処理する必要があります。エージェントは、セキュリティラベルを処理した後、目的の受信者にメッセージを表示しないことを決定した場合、エージェントは、受信者が誤って、後でコンテンツが表示されません注意しなければなりません。発信者に送信エラー応答が受信者から隠されたコンテンツが含まれており、そのエラー応答が原因のエラーに対処することを送信者にバウンスならば、それはバウンスとは考えにくいので、たとえば、元の受信者は、おそらく、コンテンツを見ることができますメッセージには、適切なセキュリティラベルを持っています。
A man-in-the-middle attack can cause a recipient to send receipts to an attacker if that attacker has a signature that can be validated by the recipient. The attack consists of intercepting the original message and adding a mLData attribute that says that a receipt should be sent to the attacker in addition to whoever else was going to get the receipt.
man-in-the-middle攻撃は、攻撃者が受信者によって検証することができます署名を持っている場合、受信者が攻撃者に領収書を送信することがあります。攻撃は元のメッセージを傍受し、領収書が領収書を取得しようとしていた他の誰に加えて、攻撃者に送信されるべきであると述べているmLData属性を追加することで構成されています。
Mailing lists that encrypt their content may be targets for denial-of-service attacks if they do not use the mailing list management described in Section 4. Using simple RFC822 header spoofing, it is quite easy to subscribe one encrypted mailing list to another, thereby setting up an infinite loop.
彼らは、単純なRFC822ヘッダーのスプーフィングを使用して、セクション4で説明したメーリングリストの管理を使用しない場合はサービス妨害（DoS）攻撃の標的となり得る、それらの内容を暗号化メーリングリスト、それによって、別の暗号化されたメーリングリストを購読することは非常に簡単です無限ループを設定します。
Mailing List Agents need to be aware that they can be used as oracles for the the adaptive chosen ciphertext attack described in [CMS]. MLAs should notify an administrator if a large number of undecryptable messages are received.
メーリングリストエージェントは、[CMS]で説明適応的選択暗号文攻撃のための神託として使用することができることを認識する必要があります。 undecryptable多数のメッセージを受信した場合のMLAは、管理者に通知しなければなりません。
When verifying a signature using certificates that come with a [CMS] message, the recipient should only verify using certificates previously known to be valid, or certificates that have come from a signed SigningCertificate attribute. Otherwise, the attacks described in Section 5 can cause the receiver to possibly think a signature is valid when it is not.
[CMS]メッセージが付属して証明書を使用して署名を検証する際に、受信者は署名のみSigningCertificate属性から来ている、以前に有効であることが知られている証明書、または証明書を使用して確認する必要があります。それ以外の場合は、5章で説明された攻撃は、受信機は、おそらくそれがないときに署名が有効であると考えることがあります。
A. ASN.1 Module
A. ASN.1モジュール
ExtendedSecurityServices { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) modules(0) ess(2) }
ExtendedSecurityServices {ISO（1）部材本体（2）米国（840）RSADSI（113549）PKCS（1）PKCS-9（9）SMIME（16）モジュール（0）ESS（2）}
DEFINITIONS IMPLICIT TAGS ::=
BEGIN
IMPORTS
輸入
-- Cryptographic Message Syntax (CMS) ContentType, IssuerAndSerialNumber, SubjectKeyIdentifier FROM CryptographicMessageSyntax { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) modules(0) cms(1)}
- 暗号メッセージ構文（CMS）のContentType、IssuerAndSerialNumber、暗号メッセージ構文FROM SubjectKeyIdentifier {ISO（1）部材本体（2）米国（840）RSADSI（113549）PKCS（1）PKCS-9（9）SMIME（16）モジュール（ 0）CMS（1）}
-- PKIX Certificate and CRL Profile, Sec A.2 Implicitly Tagged Module, -- 1988 Syntax PolicyInformation FROM PKIX1Implicit88 {iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7)id-mod(0) id-pkix1-implicit-88(2)}
- PKIX証明書およびCRLプロファイル、秒A.2暗黙的にタグ付けモジュール、 - 1988構文PolicyInformation PKIX1Implicit88 FROM {ISO（1）同定された組織（3）DOD（6）インターネット（1）セキュリティ（5）機構（5） PKIX（7）ID-MOD（0）ID-pkix1-暗黙-88（2）}
-- X.509 GeneralNames, CertificateSerialNumber FROM CertificateExtensions {joint-iso-ccitt ds(5) module(1) certificateExtensions(26) 0};
- X.509のGeneralNames、CertificateSerialNumber CertificateExtensions FROM {関節-ISO-CCITT DS（5）モジュール（1）certificateExtensions（26）0}。
-- Extended Security Services
- 拡張セキュリティサービス
-- The construct "SEQUENCE SIZE (1..MAX) OF" appears in several ASN.1 -- constructs in this module. A valid ASN.1 SEQUENCE can have zero or -- more entries. The SIZE (1..MAX) construct constrains the SEQUENCE to -- have at least one entry. MAX indicates the upper bound is unspecified. -- Implementations are free to choose an upper bound that suits their -- environment.
このモジュール中の構築 - - いくつかのASN.1に表示されて構築物「のシーケンスSIZE（1..MAX）」。複数のエントリ - 有効なASN.1シーケンスがゼロかを持つことができます。 SIZE（1..MAX）構築物にSEQUENCEを拘束 - 少なくとも1つのエントリを有しています。 MAXは上限が不定であることを示します。 - 環境 - 実装は自分に合った上限を自由に選択できます。
UTF8String ::= [UNIVERSAL 12] IMPLICIT OCTET STRING
-- The contents are formatted as described in [UTF8]
-- Section 2.7
- セクション2.7
ReceiptRequest ::= SEQUENCE {
signedContentIdentifier ContentIdentifier,
receiptsFrom ReceiptsFrom,
receiptsTo SEQUENCE SIZE (1..ub-receiptsTo) OF GeneralNames }
ub-receiptsTo INTEGER ::= 16 id-aa-receiptRequest OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 1}
ContentIdentifier ::= OCTET STRING
id-aa-contentIdentifier OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 7}
ReceiptsFrom ::= CHOICE {
allOrFirstTier [0] AllOrFirstTier,
-- formerly "allOrNone [0]AllOrNone"
receiptList [1] SEQUENCE OF GeneralNames }
AllOrFirstTier ::= INTEGER { -- Formerly AllOrNone
allReceipts (0),
firstTierRecipients (1) }
-- Section 2.8
- セクション2.8
Receipt ::= SEQUENCE {
version ESSVersion,
contentType ContentType,
signedContentIdentifier ContentIdentifier,
originatorSignatureValue OCTET STRING }
id-ct-receipt OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-ct(1) 1}
ESSVersion ::= INTEGER { v1(1) }
-- Section 2.9
- セクション2.9
ContentHints ::= SEQUENCE {
contentDescription UTF8String (SIZE (1..MAX)) OPTIONAL,
contentType ContentType }
id-aa-contentHint OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 4}
-- Section 2.10
- 2.10
MsgSigDigest ::= OCTET STRING
id-aa-msgSigDigest OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 5}
-- Section 2.11
- 2.11
ContentReference ::= SEQUENCE {
contentType ContentType,
signedContentIdentifier ContentIdentifier,
originatorSignatureValue OCTET STRING }
id-aa-contentReference OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 10 }
-- Section 3.2
- セクション3.2
ESSSecurityLabel ::= SET {
security-policy-identifier SecurityPolicyIdentifier,
security-classification SecurityClassification OPTIONAL,
privacy-mark ESSPrivacyMark OPTIONAL,
security-categories SecurityCategories OPTIONAL }
id-aa-securityLabel OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 2}
SecurityPolicyIdentifier ::= OBJECT IDENTIFIER
SecurityClassification ::= INTEGER {
unmarked (0),
unclassified (1),
restricted (2),
confidential (3),
secret (4),
top-secret (5) } (0..ub-integer-options)
ub-integer-options INTEGER ::= 256
ESSPrivacyMark ::= CHOICE {
pString PrintableString (SIZE (1..ub-privacy-mark-length)),
utf8String UTF8String (SIZE (1..MAX))
}
ub-privacy-mark-length INTEGER ::= 128
SecurityCategories ::= SET SIZE (1..ub-security-categories) OF
SecurityCategory
ub-security-categories INTEGER ::= 64
SecurityCategory ::= SEQUENCE {
type [0] OBJECT IDENTIFIER,
value [1] ANY DEFINED BY type -- defined by type
}
--Note: The aforementioned SecurityCategory syntax produces identical
--hex encodings as the following SecurityCategory syntax that is
--documented in the X.411 specification:
--
--SecurityCategory ::= SEQUENCE {
-- type [0] SECURITY-CATEGORY,
-- value [1] ANY DEFINED BY type }
--
--SECURITY-CATEGORY MACRO ::=
--BEGIN
--TYPE NOTATION ::= type | empty
--VALUE NOTATION ::= value (VALUE OBJECT IDENTIFIER)
--END
-- Section 3.4
- セクション3.4
EquivalentLabels ::= SEQUENCE OF ESSSecurityLabel
id-aa-equivalentLabels OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 9}
-- Section 4.4
- セクション4.4
MLExpansionHistory ::= SEQUENCE
SIZE (1..ub-ml-expansion-history) OF MLData
id-aa-mlExpandHistory OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 3}
ub-ml-expansion-history INTEGER ::= 64
MLData ::= SEQUENCE {
mailListIdentifier EntityIdentifier,
expansionTime GeneralizedTime,
mlReceiptPolicy MLReceiptPolicy OPTIONAL }
EntityIdentifier ::= CHOICE {
issuerAndSerialNumber IssuerAndSerialNumber,
subjectKeyIdentifier SubjectKeyIdentifier }
MLReceiptPolicy ::= CHOICE {
none [0] NULL,
insteadOf [1] SEQUENCE SIZE (1..MAX) OF GeneralNames,
inAdditionTo [2] SEQUENCE SIZE (1..MAX) OF GeneralNames }
-- Section 5.4
- セクション5.4
SigningCertificate ::= SEQUENCE {
certs SEQUENCE OF ESSCertID,
policies SEQUENCE OF PolicyInformation OPTIONAL
}
id-aa-signingCertificate OBJECT IDENTIFIER ::= { iso(1)
member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
smime(16) id-aa(2) 12 }
ESSCertID ::= SEQUENCE {
certHash Hash,
issuerSerial IssuerSerial OPTIONAL
}
Hash ::= OCTET STRING -- SHA1 hash of entire certificate
IssuerSerial ::= SEQUENCE {
issuer GeneralNames,
serialNumber CertificateSerialNumber
}
END -- of ExtendedSecurityServices
END - 拡張セキュリティサービスの
B. References
B.リファレンス
[ASN1-1988] "Recommendation X.208: Specification of Abstract Syntax Notation One (ASN.1)".
【ASN1-1988「勧告X.208：抽象構文記法1（ASN.1）の仕様」。
[ASN1-1994] "Recommendation X.680: Specification of Abstract Syntax Notation One (ASN.1)".
【ASN1-1994「勧告X.680：抽象構文記法1（ASN.1）の仕様」。
[CERT] Ramsdell, B., Editor, "S/MIME Version 3 Certificate Handling", RFC 2632, June 1999.
[CERT] Ramsdell、B.、エディタ、 "S / MIMEバージョン3証明書の取り扱い"、RFC 2632、1999年6月。
[CMS] Housley, R., "Cryptographic Message Syntax", RFC 2630, June 1999.
[CMS] Housley氏、R.、 "暗号メッセージ構文"、RFC 2630、1999年6月。
[MSG] Ramsdell, B., Editor, "S/MIME Version 3 Message Specification", RFC 2633, June 1999.
[MSG] Ramsdell、B.、エディタ、 "S / MIMEバージョン3メッセージ仕様"、RFC 2633、1999年6月。
[MUSTSHOULD] Bradner, S., "Key Words for Use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[MUSTSHOULD]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[MSP4] "Secure Data Network System (SDNS) Message Security Protocol (MSP) 4.0", Specification SDN.701, Revision A, 1997-02-06.
[MSP4]、1997年2月6日、仕様SDN.701、リビジョンA "データネットワークシステム（SDNS）メッセージセキュリティプロトコル（MSP）4.0セキュア"。
[MTSABS] "1988 International Telecommunication Union (ITU) Data Communication Networks Message Handling Systems: Message Transfer System: Abstract Service Definition and Procedures, Volume VIII, Fascicle VIII.7, Recommendation X.411"; MTSAbstractService {joint-iso-ccitt mhs-motis(6) mts(3) modules(0) mts-abstract-service(1)}
[MTSABS]「1988国際電気通信連合（ITU）のデータ通信ネットワークメッセージ処理システムでは：メッセージ転送システム：抽象サービス定義と手順、ボリュームVIII、分冊VIII.7、勧告X.411の」。 MTSAbstractService {関節-ISO-CCITTのMHS-MOTIS（6）、MTS（3）モジュール（0）MTS-抽象サービス（1）}
[PKCS7-1.5] Kaliski, B., "PKCS #7: Cryptographic Message Syntax", RFC 2315, March 1998.
[PKCS7-1.5] Kaliski、B.、 "PKCS＃7：暗号メッセージ構文"、RFC 2315、1998年3月。
[SMIME2] Dusse, S., Hoffman, P., Ramsdell, B., Lundblade, L. and L. Repka"S/MIME Version 2 Message Specification", RFC 2311, March 1998, and Dusse, S., Hoffman, P. and B. Ramsdell,"S/MIME Version 2 Certificate Handling", RFC 2312, March 1998.
【SMIME2] Dusse、S.、ホフマン、P.、Ramsdell、B.、Lundblade、L.及びL. Repka "S / MIMEバージョン2メッセージ仕様"、RFC 2311、1998年3月、及びDusse、S.、ホフマン、 P.とB. Ramsdell、 "S / MIMEバージョン2の証明書の取扱い"、RFC 2312、1998年3月。
[UTF8] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 2279, January 1998.
[UTF8] Yergeau、F.、 "UTF8、ISO 10646の変換フォーマット"、RFC 2279、1998年1月。
C. Acknowledgments
C.謝辞
The first draft of this work was prepared by David Solo. John Pawling did a huge amount of very detailed revision work during the many phases of the document.
この作品の最初の草案はデビッド・ソロにより調製しました。ジョンPawlingは、文書の多くの段階で非常に詳細な改訂作業の膨大な量をしました。
Many other people have contributed hard work to this memo, including:
：他の多くの人々には、このメモにハードワークを貢献しています
Andrew Farrell Bancroft Scott Bengt Ackzell Bill Flanigan Blake Ramsdell Carlisle Adams Darren Harter David Kemp Denis Pinkas Francois Rousseau Jim Schaad Russ Housley Scott Hollenbeck Steve Dusse
アンドリュー・ファレルバンクロフトスコットベングトAckzellビル・フラニガンブレイクRamsdellカーライルアダムスダレン・ハーターデビッド・ケンプデニスピンカス・フランソワ・ルソージムSchaadラスHousleyスコットホレンベックスティーブDusse
Editor's Address
編集者の住所
Paul Hoffman Internet Mail Consortium 127 Segre Place Santa Cruz, CA 95060
ポール・ホフマンインターネットメールコンソーシアムセグレ127場所サンタクルス、CA 95060
EMail: phoffman@imc.org
メールアドレス：phoffman@imc.org
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (1999). All Rights Reserved.
著作権（C）インターネット協会（1999）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の制限は永久で、インターネット学会やその後継者や譲渡者によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。