RFC2634 日本語訳
2634 Enhanced Security Services for S/MIME. P. Hoffman, Ed.. June 1999. (Format: TXT=131153 bytes) (Updated by RFC5035) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group P. Hoffman, Editor Request for Comments: 2634 Internet Mail Consortium Category: Standards Track June 1999
ワーキンググループのP.ホフマン、コメントを求めるエディタ要求をネットワークでつないでください: 2634年のインターネットメール共同体カテゴリ: 標準化過程1999年6月
Enhanced Security Services for S/MIME
S/MIMEのための警備の強化サービス
Status of this Memo
この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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright(C)インターネット協会(1999)。 All rights reserved。
1. Introduction
1. 序論
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つの最初のサービスが、Message Securityプロトコル[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.
ここで説明されたサービスはS/MIMEバージョン3([MSG]と[CERT])への拡大です、そして、また、S/MIMEバージョン2[SMIME2]にそれらのいくつかは追加できます。 ここで説明された拡大は、S/MIMEバージョン3受取人がS/MIMEバージョン2送付者からメッセージを読むことができないことを引き起こさないでしょう。 しかしながら、拡大のいくつかがS/MIMEバージョン2受取人が読みにくくなるようにS/MIMEバージョン3送付者によって作成されたメッセージを引き起こすでしょう。
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.
このドキュメントは四軍に必要である手順と属性の両方について説明します。 本書では説明された属性のいくつかが他の文脈でかなり役に立って、S/MIMEか他のCMSアプリケーションを広げるとき考えられるべきであることに注意してください。
Hoffman Standards Track [Page 1] RFC 2634 Enhanced Security Services for S/MIME June 1999
ホフマン標準化過程[1ページ]RFC2634は1999年6月にS/MIMEのためのセキュリティー・サービスを機能アップしました。
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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[MUSTSHOULD]で説明されるように本書では解釈されることであるべきですか?
1.1 Triple Wrapping
1.1 三重のラッピング
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.
それぞれのサービスの特徴のいくつかが「3倍包装された」メッセージの概念を使用します。 三重の包装されたメッセージは署名されて、次に、暗号化されて、次に再び署名されたものです。 内側の、そして、外側の署名の署名者は、異なった実体か同じ実体であるかもしれません。 3つ以上のラッピングがあることができるようにS/MIME仕様が入れ子にされたカプセル化の数を制限しないことに注意してください。
1.1.1 Purpose of Triple Wrapping
1.1.1 三重のラッピングの目的
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.
すべてのメッセージが、3倍包装される必要があるというわけではありません。 次に、メッセージで署名されて、暗号化して、次に、暗号化されたボディーに署名している属性を縛らなければならないとき、三重のラッピングは使用されています。 外側の属性は、メッセージ創始者か仲介物質によって加えられるか、または取り除かれて、仲介物質か最終的な受取人によって署名されるかもしれません。
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.
外の署名はホップごとに処理される情報に認証と保全を提供します、各ホップがメール・リストエージェントなどの中間的実体であるところで。 外側の署名は属性(機密保護ラベルなどの)を暗号化されたボディーに縛ります。 アクセスコントロールとルーティング決定にこれらの属性を使用できます。
Hoffman Standards Track [Page 2] RFC 2634 Enhanced Security Services for S/MIME June 1999
ホフマン標準化過程[2ページ]RFC2634は1999年6月にS/MIMEのためのセキュリティー・サービスを機能アップしました。
1.1.2 Steps for Triple Wrapping
1.1.2 三重のラッピングのためのステップ
The steps to create a triple wrapped message are:
三重の包装されたメッセージを作成するステップは以下の通りです。
1. Start with a message body, called the "original content".
1. 「オリジナルコンテンツ」と呼ばれるメッセージ本体から始まってください。
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. 適切な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オブジェクト識別子はイドデータであるに違いありません。 あなたがステップ4で作成する構造が複合か署名されるなら、SignedData encapContentInfo eContentは欠けているに違いありません。 あなたがステップ4で作成する構造がpkcs7アプリケーション/パントマイムであるなら、SignedData encapContentInfo eContentは上のステップ2の結果を含まなければなりません。 SignedData構造はイド-signedDataのcontentTypeと共にContentInfo SEQUENCEによってカプセル化されます。
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".
4. [MSG]で定義されるように適切なMIME構造物をステップ3から署名しているメッセージに追加してください。 結果として起こるメッセージは「内面の署名」と呼ばれます。
- 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構造物は複合かパラメタで署名されることの文書内容から成ります、境界、上では、境界、pkcs7アプリケーション/署名に関する文書内容、任意のMIMEヘッダー(そのようなasContent転送コード化とContent-気質)、およびボディーが分ける上のステップ3の結果であるステップ2の結果。
- 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構造物はパラメタがあるpkcs7アプリケーション/パントマイムに関する文書内容、任意のMIMEヘッダー(Content転送コード化やContent-気質などの)、およびステップ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".
5. それをpkcs7アプリケーション/パントマイムオブジェクトに変えて、単滑車としてステップ4の結果を暗号化してください。 EnvelopedData encryptedContentInfo contentTypeはイドデータであるに違いありません。 EnvelopedData構造はイド-envelopedDataのcontentTypeと共にContentInfo SEQUENCEによってカプセル化されます。 これは「暗号化されたボディー」と呼ばれます。
Hoffman Standards Track [Page 3] RFC 2634 Enhanced Security Services for S/MIME June 1999
ホフマン標準化過程[3ページ]RFC2634は1999年6月にS/MIMEのためのセキュリティー・サービスを機能アップしました。
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.
6. 適切なMIMEヘッダーを加えてください: パラメタがあるpkcs7アプリケーション/パントマイム、およびContent転送コード化やContent-気質などの任意の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
7. 同じ論理を使用して、上では、ステップ3のように単滑車としてステップ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のように適切なMIME構造物をステップ7から署名しているメッセージに追加してください。 結果として起こるメッセージは、「外の署名」と呼ばれて、また、三重の包装されたメッセージです。
1.2 Format of a Triple Wrapped Message
1.2 三重の包装されたメッセージの形式
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アプリケーション/まねている署名構造は解釈できなければなりません。
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 % | )
[ステップ8] 文書内容: 複合か署名される。 [ステップ8]は=「pkcs7アプリケーション/署名」について議定書の中で述べます。 [ステップ8] 境界はouterboundary[ステップ8][ステップ8]--outerboundary[ステップ6]文書内容と等しいです: pkcs7アプリケーション/パントマイム。 ) [おおわれたステップ6] smime-タイプ=データ) [ステップ6) [ステップ4] 文書内容: 複合か署名される。 | ) [ステップ4]は=「pkcs7アプリケーション/署名」について議定書の中で述べます。 | ) [ステップ4] 境界=innerboundary| ) [ステップ4]| ) [ステップ4] --innerboundary| ) [ステップ2] 文書内容: テキスト/明瞭な%| )
Hoffman Standards Track [Page 4] RFC 2634 Enhanced Security Services for S/MIME June 1999
ホフマン標準化過程[4ページ]RFC2634は1999年6月にS/MIMEのためのセキュリティー・サービスを機能アップしました。
[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]| ) 内側のSignedDataが妨げる(eContentはなくなっています)[ステップ3] | ) [ステップ4]| ) [ステップ4]--innerboundary--| ) [ステップ8] [ステップ8] --outerboundary[ステップ8]文書内容: pkcs7アプリケーション/署名[ステップ8][ステップ7]外側のSignedDataブロック(eContentはなくなっています) [ステップ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.
これらの%=系列は内側の署名が何に関して計算されるかということです。| = これらの系列はステップ5で暗号化されることです。 この暗号化された結果は、不透明であり、1つのEnvelopedDataブロックの一部です。 ) = これらの系列は外側の署名が何に関して計算されるかということです。
The format of a triple wrapped message that uses application/pkcs7- mime for the both signatures is:
用途アプリケーション/pkcs7がまねる三重の包装されたメッセージの形式、両方の署名、あります:
[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アプリケーション/パントマイム。 [ステップ8] smime-タイプは署名しているデータ[ステップ8][ステップ7]外側のSignedDataブロック(eContentは存在している)O[ステップ6]文書内容と等しいです: pkcs7アプリケーション/パントマイム。 ) O[ステップ6]smime-タイプはおおわれたデータと等しいです。 ) O[ステップ6) O[ステップ4]文書内容: pkcs7アプリケーション/パントマイム。 | ) O[ステップ4]smime-タイプは署名しているデータと等しいです。| ) O[ステップ4]| ) O[ステップ3]内側のSignedDataブロック(eContentは存在しています) I| ) O[ステップ2]文書内容: テキスト/明瞭な私| ) ○ [ステップ2]私| ) O[ステップ1]オリジナルの満足している私| ) 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.
これらの私=系列が内側のSignedDataブロックである、どれが不透明であり、ASN.1を含んでいるかが制御情報と同様にステップ2の結果をコード化しました。 | = これらの系列はステップ5で暗号化されることです。 この暗号化された結果は、不透明であり、1つのEnvelopedDataブロックの一部です。 ) = これらの系列は外側の署名が何に関して計算されるかということです。
Hoffman Standards Track [Page 5] RFC 2634 Enhanced Security Services for S/MIME June 1999
ホフマン標準化過程[5ページ]RFC2634は1999年6月にS/MIMEのためのセキュリティー・サービスを機能アップしました。
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.
○ = これらの系列が外側のSignedDataブロックである、どれが不透明であり、ASN.1を含んでいるかが制御情報と同様にステップ6の結果をコード化しました。
1.3 Security Services and Triple Wrapping
1.3 セキュリティサービスと三重のラッピング
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.
本書では説明された最初の3つのセキュリティー・サービスが三重の包装されたメッセージと共に異なった方法で使用されます。 このセクションは三重のラッピングで簡潔にそれぞれのサービスの関係について説明します。 ドキュメントの他のセクションは詳細に述べます。
1.3.1 Signed Receipts and Triple Wrapping
1.3.1 署名している領収書と三重のラッピング
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 Receipt Notification作業部会によって行われた仕事で説明されたものと異なっています。 終わっていると、その作業部会の出力が本書では説明されるように三重の包装されたメッセージでうまくいかないと予想されます。
1.3.2 Security Labels and Triple Wrapping
1.3.2 機密保護ラベルと三重のラッピング
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
また、機密保護ラベルは暗号化メッセージの敏感さを含んでいる外側のSignedDataブロックの署名している属性に含まれるかもしれません。 外側の機密保護ラベルは暗号化メッセージに関連するアクセスコントロールとルーティング決定に使用されます。 注意
Hoffman Standards Track [Page 6] RFC 2634 Enhanced Security Services for S/MIME June 1999
ホフマン標準化過程[6ページ]RFC2634は1999年6月にS/MIMEのためのセキュリティー・サービスを機能アップしました。
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.
signedAttributesブロックで機密保護ラベル属性を使用できるだけです。 EnvelopedDataか未署名の属性にeSSSecurityLabel属性を使用してはいけません。
1.3.3 Secure Mailing Lists and Triple Wrapping
1.3.3 安全なメーリングリストと三重のラッピング
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属性を加えるか、またはアップデートして、加えるか、または取り替えます。
1.3.4 Placement of Attributes
1.3.4 属性のプレースメント
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のどんなリストにも現れるかもしれなくて、SignedAttributesでequivalentLabel、eSSSecurityLabel、およびmlExpansionHistoryを運ばなければならないか、AuthAttributesはタイプして、UnsignedAttributesで運ばれてはいけません、とUnauthAttributesかUnprotectedAttributesがタイプします。msgSigDigest、receiptRequest、およびsigningCertificateはSignedAttributesで運ばなければならなくて、AuthAttributesで運ばれてはいけません、とUnsignedAttributes、UnauthAttributesまたはUnprotectedAttributesがタイプします。
Hoffman Standards Track [Page 7] RFC 2634 Enhanced Security Services for S/MIME June 1999
ホフマン標準化過程[7ページ]RFC2634は1999年6月にS/MIMEのためのセキュリティー・サービスを機能アップしました。
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
| |または内側。| 属性|OID|外側|署名されます。------------------|----------------------------- |----------|-------- contentHints|イド-aa-contentHint[ESS]|どちらか|5月のcontentIdentifier|イド-aa-contentIdentifier[ESS]|どちらか|5月のcontentReference|イド-aa-contentReference[ESS]|どちらか|必須contentType|イド-contentType[cm]|どちらか|必須副署|イド副署[CMS]|どちらか|必須NOT equivalentLabel|イド-aa-equivalentLabels[ESS]|どちらか|必須eSSSecurityLabel|イド-aa-securityLabel[ESS]|どちらか|必須messageDigest|イド-messageDigest[cm]|どちらか|必須msgSigDigest|イド-aa-msgSigDigest[ESS]|内側、唯一|必須mlExpansionHistory|イド-aa-mlExpandHistory[ESS]|外側、唯一|必須receiptRequest|イド-aa-receiptRequest[ESS]|内側、唯一|必須signingCertificate|イド-aa-signingCertificate[ESS]|どちらか|必須signingTime|イド-signingTime[cm]|どちらか|必須smimeCapabilities|sMIMECapabilities[MSG]|どちらか|必須sMIMEEncryption- KeyPreference|イド-aa-encrypKeyPref[MSG]|どちらか|必須
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をSET OF Attributeと定義して、unsignedAttrsをSET OF Attributeと定義します。 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セット」と構文を定義します。 ESSで定義された属性タイプのすべてに関しては、属性タイプがsignerInfoに出席しているなら、それはAttributeValueのただ一つのインスタンスを含むだけでよいです。 言い換えれば、attrValues SET OF AttributeValueの現在の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.
counterSignature属性が存在しているなら、未署名の属性にそれを含まなければなりません。 署名している属性にそれを含んではいけません。 counterSignature属性で許容されている唯一の属性が、counterSignatureと、messageDigestと、signingTimeと、signingCertificateです。
Hoffman Standards Track [Page 8] RFC 2634 Enhanced Security Services for S/MIME June 1999
ホフマン標準化過程[8ページ]RFC2634は1999年6月にS/MIMEのためのセキュリティー・サービスを機能アップしました。
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はメッセージに割り当てられたユニークな識別子を運ぶのに使用される属性(OCTET STRING)です。
1.4 Required and Optional Attributes
1.4 必要で任意の属性
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タイプ以外のあらゆるタイプであるなら、ゲートウェイには、メッセージに署名する1つの方法しかありません: 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.
だれかが将来署名が処理されるために1つのsignedDataブロックの各signerInfoで存在しなければならない属性を定義するかもしれないことに注意してください。 それが起こると、受取人によって処理されると、signerInfosを挿入して、その属性をコピーしないゲートウェイはその属性があるあらゆるメッセージに失敗されるでしょう。 この理由で、新しい署名でメッセージを包装するのはsignerInfosを挿入するより安全です。
1.5 Object Identifiers
1.5 オブジェクト識別子
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がこの登録を維持することを意図します。
Hoffman Standards Track [Page 9] RFC 2634 Enhanced Security Services for S/MIME June 1999
ホフマン標準化過程[9ページ]RFC2634は1999年6月にS/MIMEのためのセキュリティー・サービスを機能アップしました。
2. Signed Receipts
2. 領収書であると署名されます。
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.
署名している領収書を返すのは、メッセージの創始者配達証明に前提として、創始者が、受取人がオリジナルのメッセージの署名について確かめることができたのを第三者に示すのを許容します。 この領収書は署名でオリジナルのメッセージに縛られます。 その結果、メッセージが署名される場合にだけ、このサービスは要求されるかもしれません。 また、領収書送付者は、領収書送付者と領収書受取人の間に秘密性を提供するために任意に領収書を暗号化するかもしれません。
2.1 Signed Receipt Concepts
2.1は、領収書が概念であると署名しました。
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属性を加えることによって、示されます。 メーリングリスト拡張オプション、ローカルの安全保障政策、および設定オプションに応じて、そうして、領収書を返すよう要求されているとき、受信ユーザエージェントソフトウェアSHOULDは自動的に署名している領収書を作成します。
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.
領収書が2回のパーティーの相互作用を伴うので、用語は時々混乱させられることができます。 このセクションでは、「送付者」は領収書を求める要求を含んでいたオリジナルのメッセージを送ったエージェントです。 「受信機」はそのメッセージを受け取って、領収書を作ったパーティーです。
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)で有効な署名と領収書要求があるかを決心しています。
4. Recipient creates a signed receipt (Section 2.4).
4. 受取人は署名している領収書(セクション2.4)を作成します。
5. Recipient transmits the resulting signed receipt message to the
sender (Section 2.5).
5. 受取人は送付者(セクション2.5)に領収書メッセージであると署名される結果になることを伝えます。
Hoffman Standards Track [Page 10] RFC 2634 Enhanced Security Services for S/MIME June 1999
ホフマン標準化過程[10ページ]RFC2634は1999年6月にS/MIMEのためのセキュリティー・サービスを機能アップしました。
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.
セクション2.7で領収書要求のためのASN.1構文を与えます。 セクション2.8で領収書のためのASN.1構文を与えます。
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.
送付エージェントSHOULDが、それがいつそれがメッセージを処理するたびに領収書を再送するのを避けることができるように領収書を送ったかを覚えていることに注意してください。
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.
領収書要求は、領収書が送付者だけではなく、多くの場所に送られるのを示すことができます(事実上、領収書要求は、領収書が送付者のものになりさえするはずがないのを示すかもしれません)。 領収書を確かめるために、領収書の受取人は、オリジナルのメッセージの創始者か受取人でなければなりません。 したがって、送付者SHOULD NOTは、領収書がメッセージの正確なコピーを持っていないだれにも送られるよう要求します。
2.2 Receipt Request Creation
2.2 領収書要求作成
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層のためだけに要求されているかもしれません、三重の包装されたメッセージのように。 SignerInfoのsignedAttributesに1つのreceiptRequest属性しか含むことができません。
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.
Receiptが内容であるとカプセル化するSignedDataオブジェクトのSignerInfoの属性にReceiptRequest属性を含んではいけません。 言い換えれば、受信エージェントは署名している領収書のために署名している領収書を要求してはいけません。
A sender requests receipts by placing a receiptRequest attribute in the signed attributes of a signerInfo as follows:
送付者は以下のsignerInfoの署名している属性にreceiptRequest属性を置くことによって、領収書を要求します:
1. A receiptRequest data structure is created.
1. 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.
2. メッセージのための署名している満足している識別子は、signedContentIdentifier分野に作成されて、割り当てられます。 signedContentIdentifierは、署名している領収書を要求するメッセージに署名している領収書を関連づけるのに使用されます。
3. The entities requested to return a signed receipt are noted in the
receiptsFrom field.
3. 署名している領収書を返すよう要求された実体はreceiptsFrom分野に述べられます。
Hoffman Standards Track [Page 11] RFC 2634 Enhanced Security Services for S/MIME June 1999
ホフマン標準化過程[11ページ]RFC2634は1999年6月にS/MIMEのためのセキュリティー・サービスを機能アップしました。
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によるSEQUENCE OF GeneralName. receiptsToが各GeneralNamesが実体を表すSEQUENCE OF GeneralNamesであるということです。 複数のGeneralNameインスタンスが各GeneralNamesにあるかもしれません。 最小限では、メッセージ創始者は署名している領収書が送られるべきであるアドレスで各実体のGeneralNamesに居住しなければなりません。 また、任意に、メッセージ創始者は他のGeneralNameインスタンス(directoryNameなどの)で各実体のGeneralNamesに居住するかもしれません。
5. The completed receiptRequest attribute is placed in the
signedAttributes field of the SignerInfo object.
5. 完成したreceiptRequest属性はSignerInfoオブジェクトのsignedAttributes分野に置かれます。
2.2.1 Multiple Receipt Requests
2.2.1 複数の領収書要求
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オブジェクトは複数のSignerInfos、receiptRequest属性を持っている各SignerInfoを含むかもしれません。 例えば、創始者は2SignerInfos、1があるDSS署名を含む署名しているメッセージ、他の含有にRSA署名を送ることができます。
Each recipient SHOULD return only one signed receipt.
それぞれの受取人SHOULDは領収書であると署名されるものだけを返します。
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のすべてでは、領収書要求は同じであるに違いありません。
2.2.2 Information Needed to Validate Signed Receipts
2.2.2 情報は、署名している領収書を有効にする必要がありました。
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オブジェクトに値を含むのを含んでいて、メッセージ署名ダイジェスト価値は、以前はよくオリジナルのsignedData signerInfoがReceipt内容の署名値とダイジェスト値であると生成していました。 署名している領収書が複数の受取人から要求されるなら、それぞれの返された署名している領収書を確かめるとき、送付エージェントが保存している値を再利用できるので、これらのダイジェスト値を保有するのは、パフォーマンス強化です。
Hoffman Standards Track [Page 12] RFC 2634 Enhanced Security Services for S/MIME June 1999
ホフマン標準化過程[12ページ]RFC2634は1999年6月にS/MIMEのためのセキュリティー・サービスを機能アップしました。
2.3 Receipt Request Processing
2.3 領収書要求処理
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オブジェクトだけに関連しています。 受信ソフトウェアSHOULDはそれが領収書が要求されているかどうか決定するために最も奥深いsignedDataオブジェクトで署名について確かめるそれぞれのSignerInfosのsignedAttributes分野を調べます。 これは単一のSignedDataオブジェクトに複数のreceiptRequest属性を含んでいて、処理する受信エージェントをもたらすかもしれません、平行なオブジェクトに署名した異なった人々からされた要求などのように。
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属性を処理してはいけません。 SignedDataオブジェクトのすべてのreceiptRequest属性が同じであるに違いないので、受信アプリケーションはそれが確かめるSignerInfoで遭遇する最初のreceiptRequest属性を完全に処理します、そして、(以下のパラグラフで説明されるように)次に、それはそれが確かめるsignerInfosの他のすべてのreceiptRequest属性が確実に1つが遭遇した1日と同じになるようにします。 同じでないReceiptRequest属性が確かめられるなら、処理ソフトウェアは少しの署名している領収書も返してはいけません。 同じreceiptRequest属性を含む他のsignerInfosがそうすることができないでも、何かreceiptRequest属性を含むsignerInfoを有効にすることができるなら署名している領収書SHOULDを返して、受信エージェントによってサポートされなかったアルゴリズムを使用することで彼らが署名されるので、有効にされてください。
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属性が署名している属性で存在しているなら、署名している領収書はメッセージ受取人のいくつかかすべてから要求されます。 いくつかの場合、受信エージェントが領収書要求ともう片方で1なしで2つのほとんど同じメッセージ、1を受け取るかもしれないことに注意してください。 この場合、受信エージェントSHOULDは署名している領収書を要求するメッセージのために署名している領収書を送ります。
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属性が署名している属性で存在しているなら、以下はSHOULDを処理します。メッセージ受取人が署名している領収書を返すよう要求されているかどうか決定するのが使用されてください。
Hoffman Standards Track [Page 13] RFC 2634 Enhanced Security Services for S/MIME June 1999
ホフマン標準化過程[13ページ]RFC2634は1999年6月にS/MIMEのためのセキュリティー・サービスを機能アップしました。
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属性が一番はずれのsignedDataブロックに存在しているなら、以下の2ステップの1つをしてください、mlReceiptPolicyの不在か存在に基づいて:
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.1. mlReceiptPolicy値が最後のMLData要素から欠けるなら、メールList領収書方針は指定されていなくて、処理ソフトウェアSHOULDは、領収書が作成されて、返されるべきであるかどうか決定するためにreceiptRequest属性値を調べます。
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要素に存在しているなら、以下の2ステップの1つをしてください、mlReceiptPolicyの値に基づいて:
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.1. mlReceiptPolicy値がなにもであるなら、メールListの領収書方針は署名している領収書を求める創始者の要求に取って代わります、そして、署名している領収書は作成されてはいけません。
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であるなら、処理ソフトウェアSHOULDは、領収書が作成されて、返されるべきであるかどうか決定するためにreceiptRequest属性からreceiptsFrom値を調べます。 領収書が作成されるなら、insteadOfとinAdditionTo分野は実体を特定します。創始者か創始者に加えて領収書をSHOULDに送ります。
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ステップの1つをしてください。
2.1. If the value of allOrFirstTier is allReceipts, then a signed
receipt SHOULD be created.
2.1. allReceipts、当時の署名している領収書はallOrFirstTierの値であるならSHOULDです。作成されます。
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ステップの1つをしてください:
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.1. mlExpansionHistory属性が存在しているなら、この受取人は最初の層の受取人ではありません、そして、署名している領収書は作成されてはいけません。
2.2.2. If an mlExpansionHistory attribute is not present,
then a signed receipt SHOULD be created.
2.2.2. 属性はmlExpansionHistoryであるなら存在していなくて、次に、署名している領収書はSHOULDです。作成されます。
3. If the receiptsFrom value of the receiptRequest attribute is a
receiptList:
3. receiptRequest属性のreceiptsFrom値がreceiptListであるなら:
Hoffman Standards Track [Page 14] RFC 2634 Enhanced Security Services for S/MIME June 1999
ホフマン標準化過程[14ページ]RFC2634は1999年6月にS/MIMEのためのセキュリティー・サービスを機能アップしました。
3.1. If receiptList contains one of the GeneralNames of the
recipient, then a signed receipt SHOULD be created.
3.1. receiptListがGeneralNamesの1つを含むなら、受取人、領収書SHOULDであると署名される当時のaでは、作成されてください。
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の1つを含んでいないなら、署名している領収書を作成してはいけません。
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. 領収書Request属性プレゼント? はい、->1。 いいえ->は1を止めます。 外側のsignedDataにmlExpansionHistoryを持っていますか? はい、->1.1。 ->2がありません。 1.1. mlReceiptPolicy休みますか? はい、->2。 ->1.2がありません。 1.2. mlReceiptPolicyなにもの値に基づいて、->1.2.1insteadOfかinAdditionTo->1.2.2を選んでください。 1.2.1. 止まってください。 1.2.2. receiptsFromを調べて、領収書が作成されるべきであるかどうか決定してくださいといって、必要なら、それを作成してください、そして、mlReceiptPolicy、当時の->STOPによって任命された受取人にそれを送ってください。 2. receiptsFrom allOrFirstTierが値がありますか? はい->Pickは2.1firstTierRecipients->2.2をallOrFirstTier. allReceipts->の値に基礎づけました。 ->3がありません。 2.1. 領収書、当時の->STOPを作成してください。 2.2. 外側のsignedDataブロックにmlExpansionHistoryを持っていますか? はい->2.2.1。 いいえ->2.2.2。 2.2.1. 止まってください。 2.2.2. 領収書、当時の->STOPを作成してください。 3. receiptRequestのreceiptsFrom値はreceiptListですか? はい、->3.1。 ->停止がありません。 3.1. receiptListは受取人を含みますか? はい、->Create a領収書、当時の->STOP。 ->3.2がありません。 3.2. 止まってください。
Hoffman Standards Track [Page 15] RFC 2634 Enhanced Security Services for S/MIME June 1999
ホフマン標準化過程[15ページ]RFC2634は1999年6月にS/MIMEのためのセキュリティー・サービスを機能アップしました。
2.4 Signed Receipt Creation
2.4は、領収書が作成であると署名しました。
A signed receipt is a signedData object encapsulating a Receipt content (also called a "signedData/Receipt"). Signed receipts are created as follows:
署名している領収書はReceiptが内容(また、「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. signedData/領収書を作成する前に、首尾よく属性であると署名されるreceiptRequestを含んでいるオリジナルのsignedData signerInfoの署名について確かめなければなりません。
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.1. オリジナルのsignedDataオブジェクトの内容は[CMS]で説明されるように読みこなされます。 そして、結果として起こるダイジェスト値はオリジナルのsignedData signerInfoのsignedAttributesに含まれているmessageDigest属性の値にたとえられます。 これらのダイジェスト値が異なるなら、署名照合プロセスは失敗します、そして、signedData/領収書は作成されてはいけません。
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のコード化されたsignedAttributes(messageDigest、receiptRequest、およびことによると他の署名している属性を含んでいる)が読みこなされるASN.1DER。 そして、msgSigDigestと呼ばれる結果として起こるダイジェスト値は、オリジナルのsignedData signerInfoの署名について確かめるのに使用されます。 署名照合が失敗するなら、signedData/領収書を作成してはいけません。
2. A Receipt structure is created.
2. Receipt構造は作成されます。
2.1. The value of the Receipt version field is set to 1.
2.1. Receiptバージョン分野の値は1に設定されます。
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. receiptRequest属性を含んでいるオリジナルのsignedData signerInfoにcontentType属性を含むのからのオブジェクト識別子はReceipt contentTypeにコピーされます。
2.3. The original signedData signerInfo receiptRequest
signedContentIdentifier is copied into the Receipt
signedContentIdentifier.
2.3. オリジナルのsignedData signerInfo receiptRequest signedContentIdentifierはReceipt 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からの署名値はReceipt originatorSignatureValueにコピーされます。
3. The Receipt structure is ASN.1 DER encoded to produce a data
stream, D1.
3. Receipt構造はデータ・ストリーム、D1を生産するためにコード化されたASN.1DERです。
Hoffman Standards Track [Page 16] RFC 2634 Enhanced Security Services for S/MIME June 1999
ホフマン標準化過程[16ページ]RFC2634は1999年6月にS/MIMEのためのセキュリティー・サービスを機能アップしました。
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は読みこなされます。 messageDigestが署名値を結局signedDataを含むsignerInfoのsignedAttributesで結果と考えるか、または領収書を出させるとき、結果として起こるダイジェスト値は含まれています。
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. msgSigDigestが署名値を結局signedDataを含むsignerInfoのsignedAttributesで結果と考えるか、または領収書を出させるとき、オリジナルのsignedData signerInfoの署名について確かめるためにStep1で計算されたダイジェスト値(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.
6. 結局signedData/領収書署名価値を含むsignerInfoの署名している属性にイドct領収書オブジェクト識別子を含むcontentType属性を、作成されて、加えなければなりません。
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.
7. signedData/領収書がSHOULDであると署名される時間が結局signedData/領収書署名価値を含むsignerInfoの署名している属性に作成されて、加えられるのを示すsigningTime属性。 他の属性(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.1DERです。 結果として起こるダイジェスト値は、次に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. [CMS]で定義されたsignedData encapContentInfo eContent OCTET STRINGの中で直接Receipt満足していた状態でコード化されたASN.1DERをコード化しなければなりません。 signedData encapContentInfo eContentTypeにイドct領収書オブジェクト識別子を含まなければなりません。 これはReceipt内容を含むsignedDataで構成された独身のASN.1のコード化されたオブジェクトをもたらします。 Data content typeを使用してはいけません。 signedDataオブジェクトの一部としてコード化される前に、MIMEヘッダーかいかなる他のヘッダーでもReceipt内容をカプセル化してはいけません。
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. そして、smime-型引数が「署名している領収書」に設定されていた状態で、signedData/領収書はpkcs7アプリケーション/パントマイムMIMEラッパーに入れられます。 ASN.1ボディーを割る必要はなくて、これは署名している領収書の識別を考慮するでしょう。 smime-型引数はまだこのメッセージに巻きつけられたどんな層の中でも同じくらい正常なセットです。
Hoffman Standards Track [Page 17] RFC 2634 Enhanced Security Services for S/MIME June 1999
ホフマン標準化過程[17ページ]RFC2634は1999年6月にS/MIMEのためのセキュリティー・サービスを機能アップしました。
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オブジェクトの中に暗号化されることであるならenvelopedDataオブジェクトをカプセルに入れる外側のsignedDataオブジェクトを作成しなければなりません、そして、外側のsignedData SignerInfo signedAttributesにイドct領収書オブジェクト識別子に用意ができているcontentTypeがあるcontentHints属性を含まなければなりません。 受信エージェントが外側のsignedDataオブジェクトを処理するとき、contentHints contentTypeでのイド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の世代をサポートするすべての送付エージェントが暗号化された署名している領収書を送る能力を提供しなければなりません(すなわち、signedData/領収書はenvelopedDataの中で要約されました)。 送付エージェントは署名している領収書を要求するenvelopedDataによってカプセル化されたsignedDataに対応して暗号化された署名している領収書を送るかもしれません。 それは署名している領収書が暗号化されるべきであるかどうかに関するローカルの方針の問題です。 領収書であると署名されるESSは署名している領収書を要求したオリジナルのsignedDataオブジェクトのために計算されたメッセージダイジェスト値を含んでいます。 envelopedDataオブジェクトの中に暗号化されていた状態でオリジナルのsignedDataオブジェクトを送って、署名している領収書が送られるESSが非暗号化したなら、予測されたオリジナルの暗号化されたsignedDataが送られるのを反対させるメッセージダイジェスト値は非暗号化されました。 領収書であると署名されるESSを暗号化するかどうか決めるとき、応答者はこれを考えるべきです。
2.4.1 MLExpansionHistory Attributes and Receipts
2.4.1 MLExpansionHistory属性と領収書
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.
Receiptが内容であるとカプセル化するSignedDataオブジェクトのSignerInfoの属性にMLExpansionHistory属性を含んではいけません。 次に、分配のためにSignedData/領収書をMLAに送るときMLAがいつもMLAがMLExpansionHistory属性を含んでいる外側のSignedDataの受け取られていているSignedData/領収書をカプセル化しなければならないので、これは本当です。 MLAが受け取られていているSignedData/領収書オブジェクトのsignedAttributesを変えることができないので、それはSignedData/領収書にMLExpansionHistoryを追加できません。
2.5 Determining the Recipients of the Signed Receipt
2.5 署名している領収書の受取人を決定すること。
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の値で受取人の系列を開始します。
Hoffman Standards Track [Page 18] RFC 2634 Enhanced Security Services for S/MIME June 1999
ホフマン標準化過程[18ページ]RFC2634は1999年6月にS/MIMEのためのセキュリティー・サービスを機能アップしました。
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の値に取り替えます。
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の価値を受取人の系列に高めます。
2.6. Signed Receipt Validation
2.6. 領収書合法化であると署名されます。
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.
Receipt内容を含んでいて、独身のASN.1がsignedDataオブジェクトで直接構成されたオブジェクトをコード化したので、署名している領収書は伝えられます。 それはReceipt内容を含むsignedDataオブジェクトのencapContentInfo eContentType値における、イド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.
受取人は1つ以上の署名している領収書を送るべきではありませんが、エージェントSHOULDを受けて、受取人から複数の署名している領収書を受け入れることができてください。
A signedData/Receipt is validated as follows:
signedData/領収書は以下の通り有効にされます:
1. ASN.1 decode the signedData object including the Receipt content.
1. ASN.1はReceipt内容を含む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. 解読されたReceipt構造からcontentType、signedContentIdentifier、およびoriginatorSignatureValueを抽出して、signedData/領収書を要求したオリジナルのsignedData signerInfoを特定してください。
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.1. 送付者によって計算されたメッセージ署名ダイジェスト価値が送付者によって局所的に節約されたなら、それを見つけられていて、検索しなければなりません。
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
4. そして、送付者によって計算されたメッセージ署名ダイジェスト価値はsignedData/領収書signerInfoに含まれているmsgSigDigest signedAttributeの値にたとえられます。 これらのダイジェスト値が同じであるなら、それは、メッセージ署名が受け取られているのに基づく受取人によって計算された値を読みこなすと立証します。
Hoffman Standards Track [Page 19] RFC 2634 Enhanced Security Services for S/MIME June 1999
ホフマン標準化過程[19ページ]RFC2634は1999年6月にS/MIMEのためのセキュリティー・サービスを機能アップしました。
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.
オリジナルの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. 送付者によって構成されたReceipt内容のために送付者によって計算されたダイジェスト値を取得してください(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.1. 送付者によって計算されたReceipt満足しているダイジェスト価値が送付者によって局所的に節約されたなら、それを見つけられていて、検索しなければなりません。
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、および署名値を含むReceipt構造を作成してください。 そして、Receipt構造は次にReceiptの満足しているダイジェスト価値を生産するために読みこなされるデータ・ストリームを起こすためにコード化されたASN.1DERです。
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. そして、送付者によって計算されたReceiptの満足しているダイジェスト価値はsignedData/領収書signerInfoに含まれているmessageDigest signedAttributeの値にたとえられます。 これらのダイジェスト値が同じであるなら、それは、Receipt内容に受取人によって含まれた値がsignedData/領収書を要求したオリジナルのsignedData signerInfoに含まれていたものと同じであると立証します。 これは、受取人が送付者によって署名されたオリジナルのsignedDataを受け取ったと立証します、それが受取人が元のsignedData signerInfo署名価値をReceipt内容での包含に得たかもしれない唯一の方法であるので。 ダイジェスト値が異なるなら、signedData/領収書署名照合プロセスは失敗します。
7. The ASN.1 DER encoded signedAttributes of the signedData/Receipt
signerInfo are digested as described in [CMS].
7. [CMS]で説明されたsignedData/領収書signerInfoのコード化されたsignedAttributesが読みこなされるASN.1DER。
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
8. そして、結果として起こるダイジェスト値は、signedData/領収書signerInfoに値を含んでいて、署名について確かめるのに使用されます。 署名照合がうまくいくなら、それは、signedData/領収書signerInfo signedAttributesの保全を立証して、signedData/領収書の署名者のアイデンティティを認証します。
Hoffman Standards Track [Page 20] RFC 2634 Enhanced Security Services for S/MIME June 1999
ホフマン標準化過程[20ページ]RFC2634は1999年6月にS/MIMEのためのセキュリティー・サービスを機能アップしました。
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.
signerInfo。 signedAttributesが受取人によって計算されたReceipt満足しているダイジェスト価値(messageDigest属性)と受取人によって計算されたメッセージ署名ダイジェスト価値(msgSigDigest属性)を含んでいることに注意してください。 したがって、うまくいっているsignedData/領収書署名照合に結合された送付者が発生していて受取人が発生しているダイジェスト値の前述の比較は、受取人がオリジナルのsignedDataオブジェクト(messageDigest属性で、立証される)の送付者によって署名された正確なオリジナルのsignedData内容とsignedAttributes(msgSigDigest属性で、立証される)を受け取ったと立証します。 署名照合が失敗するなら、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プロトコルに関連して使用されるそれぞれの署名アルゴリズムのための署名照合プロセスはアルゴリズムに特定です。 これらのプロセスはアルゴリズムに特定のドキュメントで説明されます。
2. 7 Receipt Request Syntax
2. 7領収書要求構文
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 }
ReceiptRequest:、:= 系列signedContentIdentifier ContentIdentifier、receiptsFrom ReceiptsFrom、GeneralNamesのreceiptsTo系列サイズ(1..ub-receiptsTo)
ub-receiptsTo INTEGER ::= 16
ub-receiptsTo整数:、:= 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}
イド-aa-receiptRequestオブジェクト識別子:、:= iso(1)は(2) 私たち(840)rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)イド-aa(2)1をメンバーと同じくらい具体化させます。
ContentIdentifier ::= OCTET STRING
ContentIdentifier:、:= 八重奏ストリング
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}
イド-aa-contentIdentifierオブジェクト識別子:、:= iso(1)は(2) 私たち(840)rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)イド-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 SHOULDはユーザ特有の識別情報(材料確認情報を合わせるユーザ名か公衆などの)、GeneralizedTimeストリング、および乱数の連結を含んでいます。
Hoffman Standards Track [Page 21] RFC 2634 Enhanced Security Services for S/MIME June 1999
ホフマン標準化過程[21ページ]RFC2634は1999年6月にS/MIMEのためのセキュリティー・サービスを機能アップしました。
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 }
ReceiptsFrom:、:= 選択allOrFirstTier[0]AllOrFirstTier--、以前「allOrNone[0]AllOrNone」receiptList[1]SEQUENCE OF GeneralNames
AllOrFirstTier ::= INTEGER { -- Formerly AllOrNone
allReceipts (0),
firstTierRecipients (1) }
AllOrFirstTier:、:= 整数--、以前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を入れなければなりません。
2.8 Receipt Syntax
2.8領収書構文
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.
Receipt、領収書は、新しいcontent typeを使用することで表されます。 Receipt content typeで、ASN.1はReceiptをタイプするものとします。 SignedDataメッセージの中で領収書をカプセル化しなければなりません。
Receipt ::= SEQUENCE {
version ESSVersion,
contentType ContentType,
signedContentIdentifier ContentIdentifier,
originatorSignatureValue OCTET STRING }
以下を領収書を出させてください:= 系列バージョン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}
イドct領収書OBJECT IDENTIFIER:、:= iso(1)は(2) 私たち(840)rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)イドct(1)1をメンバーと同じくらい具体化させます。
ESSVersion ::= INTEGER { v1(1) }
ESSVersion:、:= 整数v1(1)
The version field defines the syntax version number, which is 1 for this version of the standard.
バージョン分野は構文バージョン番号を定義します。(それは、規格のこのバージョンのための1です)。
Hoffman Standards Track [Page 22] RFC 2634 Enhanced Security Services for S/MIME June 1999
ホフマン標準化過程[22ページ]RFC2634は1999年6月にS/MIMEのためのセキュリティー・サービスを機能アップしました。
2.9 Content Hints
2.9 内容は暗示します。
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 }
ContentHints:、:= 系列contentDescription UTF8String(サイズ(1..MAX))任意である、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}
イド-aa-contentHintオブジェクト識別子:、:= iso(1)は(2) 私たち(840)rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)イド-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分野は受取人が処理への保護されたメッセージを選択するのに使用するかもしれない情報を提供するのに使用されるかもしれません、メッセージ対象のように。 この分野が設定されるなら、属性が内側のsignedDataオブジェクトの上に現れるのではなく、envelopedDataオブジェクトを同封する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オブジェクトに巻きつけられた、その結果、メッセージの内側のcontent typeにマスクをかけたsignedDataオブジェクトを含むメッセージ、SHOULDはcontentHints属性を含んでいます、データcontent typeに関するケースを除いて。 特定のメッセージcontent typeは、contentHints属性の包含を強制するか、または排除するかもしれません。 signedData/領収書がenvelopedDataオブジェクトの中に暗号化されるとき、例えば、envelopedDataオブジェクトをカプセルに入れる外側のsignedDataオブジェクトを作成しなければなりません、そして、外側のsignedData SignerInfo signedAttributesにイドct領収書オブジェクト識別子に用意ができているcontentTypeがあるcontentHints属性を含まなければなりません。
Hoffman Standards Track [Page 23] RFC 2634 Enhanced Security Services for S/MIME June 1999
ホフマン標準化過程[23ページ]RFC2634は1999年6月にS/MIMEのためのセキュリティー・サービスを機能アップしました。
2.10 Message Signature Digest Attribute
2.10 メッセージ署名ダイジェスト属性
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属性を使用できるだけです。 それは署名している領収書を要求したオリジナルのsignedDataにsignedAttributesを含んでいて、コード化されたASN.1DERのダイジェストを含んでいます。 1つのmsgSigDigest属性しか署名している属性セットに現れることができません。 それは以下の通り定義されます:
msgSigDigest ::= OCTET STRING
msgSigDigest:、:= 八重奏ストリング
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}
イド-aa-msgSigDigestオブジェクト識別子:、:= iso(1)は(2) 私たち(840)rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)イド-aa(2)5をメンバーと同じくらい具体化させます。
2.11 Signed Content Reference Attribute
2.11は、内容照会が属性であると署名しました。
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属性は1SignedDataから別のものへのリンクです。 それは、それが参照されるオリジナルのメッセージに回答をリンクするか、または参照で1SignedDataを別のものに組み込むのに使用されるかもしれません。 最初のSignedDataは属性であると署名されるcontentIdentifierを含まなければならなくて、どのSHOULDがセクション2.7で指定されるように組み立てられますか? ContentReferenceを含んでいるのによる1日への2番目のSignedDataリンクは、最初のSignedDataから属性含有がcontent typeと、満足している識別子と、署名値であると署名しました。
ContentReference ::= SEQUENCE {
contentType ContentType,
signedContentIdentifier ContentIdentifier,
originatorSignatureValue OCTET STRING }
ContentReference:、:= 系列contentType ContentType、signedContentIdentifier ContentIdentifier、originatorSignatureValue八重奏ストリング
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 }
イド-aa-contentReferenceオブジェクト識別子:、:= iso(1)は(2) 私たち(840)rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)イド-aa(2)10をメンバーと同じくらい具体化させます。
3. Security Labels
3. 機密保護ラベル
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に関連づけることができる機密保護ラベルに使用されるために構文について説明します。 機密保護ラベルは1セットの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カプセル化によって保護される内容にアクセスできるかどうか決定するために機密保護ラベルの感度情報をユーザの承認にたとえることができます。
Hoffman Standards Track [Page 24] RFC 2634 Enhanced Security Services for S/MIME June 1999
ホフマン標準化過程[24ページ]RFC2634は1999年6月に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).
機密保護ラベルはルーティング情報の源などの他の目的に使用されるかもしれません。 ラベルは、しばしば格付けされた(「秘密で」、「秘密で」、「制限され」、とてもオン)であるレベルについて説明するか、またはどの種類の人々が情報(「患者の健康管理チーム」、「無制限で」、とてもオンな「医療費請求事務エージェント」)を見ることができるかを説明して、基づく役割です。
3.1 Security Label Processing Rules
3.1 機密保護ラベル処理規則
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オブジェクトの署名している属性で機密保護ラベル属性を入れるかもしれません。 受信エージェントは、受信されたメッセージで機密保護ラベルを調べて、受取人がメッセージのコンテンツを拝見するかどうかと決心しています。
3.1.1 Adding Security Labels
3.1.1 機密保護ラベルを加えること。
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.
機密保護ラベルを使用している送付エージェントは1つのSignerInfoブロックのsignedAttributes分野に機密保護ラベル属性を置かなければなりません。 未署名の属性に機密保護ラベル属性を含んではいけません。 保全と認証セキュリティー・サービスを機密保護ラベルに適用しなければなりません、したがって、署名している属性としてそれを含めなければなりません、使用されるなら。 これは、機密保護ラベル属性がSignerInfo署名価値を形成するために論じ尽くされるデータの一部であることを引き起こします。 SignerInfoブロックで、属性であると1個以上の機密保護ラベルに署名してはいけません。
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
また、属性であると署名される機密保護ラベルは外側のSignedDataブロックの中のsignedAttributes分野に含まれるかもしれません。 外側の機密保護ラベルは暗号化の敏感さを含むでしょう。
Hoffman Standards Track [Page 25] RFC 2634 Enhanced Security Services for S/MIME June 1999
ホフマン標準化過程[25ページ]RFC2634は1999年6月にS/MIMEのためのセキュリティー・サービスを機能アップしました。
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).
暗号化メッセージに関連するアクセス制御決定とルーティング決定において使用されているために通信して、望んでください。 外側の署名は外側の機密保護ラベルの認証を提供します(よく入れ子にされた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オブジェクトは複数のeSSSecurityLabels、eSSSecurityLabel属性を持っている各SignerInfoを含むかもしれません。 例えば、創始者は2SignerInfos、1があるDSS署名を含む署名しているメッセージ、他の含有にRSA署名を送ることができます。 SignedDataオブジェクトに含まれていたSignerInfosのどれかがeSSSecurityLabel属性を含んでいるなら、そのSignedDataオブジェクトのSignerInfosのすべてがeSSSecurityLabel属性を含まなければなりません、そして、それぞれの値は同じであるに違いありません。
3.1.2 Processing Security Labels
3.1.2 処理機密保護ラベル
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.
受信エージェントはeSSSecurityLabel属性を処理しなければなりません、存在しているなら、それが署名について確かめるSignedDataオブジェクトの各SignerInfoで。 これは受信をもたらして、単一のSignedDataオブジェクトに複数のエージェント処理eSSSecurityLabelsを含むかもしれません。 SignedDataオブジェクトのすべてのeSSSecurityLabelsが同じであるに違いないので、それが確かめるsignerInfosでその他のeSSSecurityLabelsを確かめて、次に確実にするSignerInfoで遭遇する最初のeSSSecurityLabelの上の受信エージェントプロセス(アクセスコントロールを実行などなどの)は1つが遭遇した1日と同じです。 それが確かめる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.
受信エージェントSHOULDには、処理ソフトウェアが認識しないeSSSecurityLabelセキュリティ方針識別子を含んでいるsignedDataオブジェクトの内側の内容を示しているかどうかに関するローカルの方針があります。 受信エージェントはeSSSecurityLabelセキュリティ方針識別子価値を認めないで、次に、それはSHOULDです。メッセージを処理するのを止めてください、そして、誤りを示してください。
Hoffman Standards Track [Page 26] RFC 2634 Enhanced Security Services for S/MIME June 1999
ホフマン標準化過程[26ページ]RFC2634は1999年6月にS/MIMEのためのセキュリティー・サービスを機能アップしました。
3.2 Syntax of eSSSecurityLabel
eSSSecurityLabelの3.2構文
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構文は直接[MTSABS]ASN.1モジュールから引き出されます。 (MTSAbstractServiceモジュールが始まる、「定義、内在しているタグ: : =、」、)。 さらに、eSSSecurityLabel構文は[MSP4]で使用されるそれと互換性があります。
ESSSecurityLabel ::= SET {
security-policy-identifier SecurityPolicyIdentifier,
security-classification SecurityClassification OPTIONAL,
privacy-mark ESSPrivacyMark OPTIONAL,
security-categories SecurityCategories OPTIONAL }
ESSSecurityLabel:、:= セットします。セキュリティ方針識別子SecurityPolicyIdentifier、セキュリティ分類SecurityClassification OPTIONAL、プライバシーマークESSPrivacyMark OPTIONAL、セキュリティカテゴリ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}
イド-aa-securityLabelオブジェクト識別子:、:= iso(1)は(2) 私たち(840)rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)イド-aa(2)2をメンバーと同じくらい具体化させます。
SecurityPolicyIdentifier ::= OBJECT IDENTIFIER
SecurityPolicyIdentifier:、:= オブジェクト識別子
SecurityClassification ::= INTEGER {
unmarked (0),
unclassified (1),
restricted (2),
confidential (3),
secret (4),
top-secret (5) } (0..ub-integer-options)
SecurityClassification:、:= INTEGER、無印の(0)、(1)、部外秘な(2)、秘密の(3)、秘密(4)、トップシークレットの(5)を非分類しました。(0..ub整数オプション)
ub-integer-options INTEGER ::= 256
ub整数オプションINTEGER:、:= 256
ESSPrivacyMark ::= CHOICE {
pString PrintableString (SIZE (1..ub-privacy-mark-length)),
utf8String UTF8String (SIZE (1..MAX))
}
ESSPrivacyMark:、:= 選択pString PrintableString(サイズ(1..ubプライバシーマークの長さ))、utf8String UTF8String(サイズ(1..MAX))
ub-privacy-mark-length INTEGER ::= 128
ubプライバシーマークの長さのINTEGER:、:= 128
SecurityCategories ::= SET SIZE (1..ub-security-categories) OF
SecurityCategory
SecurityCategories:、:= SecurityCategoryのサイズ(1..ubセキュリティカテゴリ)を設定してください。
ub-security-categories INTEGER ::= 64
ubセキュリティカテゴリINTEGER:、:= 64
SecurityCategory ::= SEQUENCE {
type [0] OBJECT IDENTIFIER,
value [1] ANY DEFINED BY type -- defined by type
}
SecurityCategory:、:= 系列値[1]ANY DEFINED BYはタイプします--[0] OBJECT IDENTIFIERをタイプしてください、そして、タイプによって定義されます。
--Note: The aforementioned SecurityCategory syntax produces identical --hex encodings as the following SecurityCategory syntax that is --documented in the X.411 specification:
--以下に注意してください。 前述のSecurityCategory構文は同じ状態で作成されます--以下のSecurityCategory構文--X.411仕様に記録されるとしてencodingsに魔法をかけてください:
Hoffman Standards Track [Page 27] RFC 2634 Enhanced Security Services for S/MIME June 1999
ホフマン標準化過程[27ページ]RFC2634は1999年6月にS/MIMEのためのセキュリティー・サービスを機能アップしました。
--
--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
-- --SecurityCategory:、:= SEQUENCE--[0] タイプSECURITY-CATEGORY--値[1]ANY DEFINED BYタイプ----SECURITY-CATEGORY MACRO、:、:= --始まってください--記法をタイプしてください:、:= タイプ| --VALUE NOTATIONを空にしてください:、:= 値(VALUE OBJECT IDENTIFIER)の--END
3.3 Security Label Components
3.3 機密保護ラベルの部品
This section gives more detail on the the various components of the eSSSecurityLabel syntax.
このセクションはeSSSecurityLabel構文の様々な成分に関するその他の詳細を与えます。
3.3.1 Security Policy Identifier
3.3.1 安全保障政策識別子
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.
安全保障政策はセキュリティー・サービスの支給のための1セットの評価基準です。 機密保護ラベルが関係するeSSSecurityLabelセキュリティ方針識別子は大挙して安全保障政策を特定するのが使用されます。 それは他の機密保護ラベルの部品の意味論を示します。
3.3.2 Security Classification
3.3.2 セキュリティ分類
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 Recommendationで指定されていた状態でSecurity Classification分野の使用を定義します。(X.411 Recommendationは以下を一部述べます)。
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.
存在しているなら、セキュリティ分類には、値の階層的なリストの1つがあるかもしれません。 基本的なセキュリティ分類階層構造はこのRecommendationで定義されますが、これらの値の使用は安全保障政策で大挙して定義されます。 また、セキュリティ分類の加算値、および階層構造の彼らの立場は地域にかかわる事柄としての安全保障政策か二国間条約によって定義されるかもしれません。 基本的なセキュリティ分類階層構造が昇順であります: 無印の、そして、非分類されて、制限されて、秘密の、そして、秘密の最高機密。
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
組織はSecurityClassification INTEGER値とそれらの意味を定義するそれ自身の安全保障政策を開発できます。 しかしながら、X.411仕様の一般的な解釈は0〜5の値が「基本的な階層構造」値のために予約されるということです。
Hoffman Standards Track [Page 28] RFC 2634 Enhanced Security Services for S/MIME June 1999
ホフマン標準化過程[28ページ]RFC2634は1999年6月にS/MIMEのためのセキュリティー・サービスを機能アップしました。
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.
無印の、そして、非分類されて、制限されて、秘密の秘密、および最高機密について。 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意味、およびSHOULDを除いて、SHOULD NOTが整数0〜5を使用する安全保障政策では、代わりに階級的なファッションで他の値を使用してください。
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.
例えば、ディフェンスメッセージシステムによる11の値が示すセキュリティ分類Sensitiveだけ1.0安全保障政策、Unclassified、および5は最高機密を示します。 トップシークレットの数値はSensitiveにもかかわらず、Unclassified以下ですが、感度の階層構造はSensitiveにもかかわらず、Unclassifiedより敏感であるとしてトップシークレットで格付けします。
(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)を読むことができます。
Hoffman Standards Track [Page 29] RFC 2634 Enhanced Security Services for S/MIME June 1999
ホフマン標準化過程[29ページ]RFC2634は1999年6月にS/MIMEのためのセキュリティー・サービスを機能アップしました。
2 -- restricted to Timberwolf Productions staff 6 -- can only be read to Timberwolf Productions executives
2(Timberwolf Productionsスタッフ6に制限される)しかTimberwolf Productions幹部社員に読み込むことができません。
3.3.3 Privacy Mark
3.3.3 プライバシーマーク
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セキュリティ方針識別子で、特定される)定義されるかもしれません(使用されるために値のリストを定義するかもしれません)。 交互に、値は機密保護ラベルの創始者によって決定されるかもしれません。
3.3.4 Security Categories
3.3.4 セキュリティカテゴリ
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セキュリティカテゴリで存在しているのが許容されています。 交互に、セキュリティカテゴリとそれらの値は二国間条約によって定義されるかもしれません。
3.4 Equivalent Security Labels
3.4 同等な機密保護ラベル
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.
組織がそれら自身の安全保障政策を定義できるので、多くの異なった安全保障政策が存在するでしょう。 それらの安全保障政策の間で他の組織の安全保障政策でequivalenciesを作成したがっているかもしれない組織もあります。 例えば、Acme社とWidget社は「頂上個人的な」セキュリティ分類が「ウィジェット敏感な」セキュリティ分類値に同等であることを評価する二国間条約に達するかもしれません。
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を処理するだけが、許容できます。 それらを処理しないでも、すべての受信エージェントSHOULDがequivalentLabels属性を認識します。
3.4.1 Creating Equivalent Labels
3.4.1 同等なラベルを作成すること。
The EquivalentLabels signed attribute is defined as:
属性であると署名されるEquivalentLabelsは以下と定義されます。
Hoffman Standards Track [Page 30] RFC 2634 Enhanced Security Services for S/MIME June 1999
ホフマン標準化過程[30ページ]RFC2634は1999年6月にS/MIMEのためのセキュリティー・サービスを機能アップしました。
EquivalentLabels ::= SEQUENCE OF ESSSecurityLabel
EquivalentLabels:、:= 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}
イド-aa-equivalentLabelsオブジェクト識別子:、:= iso(1)は(2) 私たち(840)rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)イド-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属性は同じsignerInfoにESSSecurityLabel属性を含んでいると意味的に相当していると署名者によって信じられている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属性を使用する前に、受信エージェントはすべての安全保障政策OIDsが確実に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安全保障政策では、Acme安全保障政策OIDで構成された機密保護ラベルと「無印」のセキュリティ分類に一致するようにESSSecurityLabelの不在を定義できました。
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.
signedDataのsignerInfosにESSSecurityLabelを含むのと意味的に異なった機密保護ラベルを運ぶのにequivalentLabelsを使用してはいけないことに注意してください。 実体が、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をSET OF Attributeと定義します。 signerInfoはequivalentLabels属性の複数のインスタンスを含んではいけません。 署名している属性がattrValues SET OFを含むように、CMSはASN.1構文を定義します。
Hoffman Standards Track [Page 31] RFC 2634 Enhanced Security Services for S/MIME June 1999
ホフマン標準化過程[31ページ]RFC2634は1999年6月にS/MIMEのためのセキュリティー・サービスを機能アップしました。
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のただ一つのインスタンスを含むだけでよいです。 attrValues SET OF AttributeValueの現在のAttributeValueのゼロか複数のインスタンスがあるはずがありません。
3.4.2 Processing Equivalent Labels
3.4.2 処理の同等なラベル
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.
SHOULDがどんな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属性は影響してはいけません。 だれが等価性マッピングを指定できるかを決定するのは、ローカルの方針です。 メッセージに1つ以上のEquivalentLabels属性があるなら、受信エージェントSHOULDは最初のものを処理します。それを読んで、有効にするのが受信エージェントにとって、興味深い安全保障政策を含んでいます。
4. Mail List Management
4. メール・リスト管理
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.
送付エージェントは暗号化メッセージの各受取人のために受取人特有のデータ構造を作成しなければなりません。 このプロセスは多くの受取人に送られたメッセージのために性能を損なうことができます。 したがって、すべての受取人のためにただ一つの伝言を受け取て、受取人特有の暗号化を実行できるメールListエージェント(MLAs)が、しばしば望まれています。
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はメールList(ML)のためのメッセージ拡張ポイントとして機能します。 メッセージの送付者はMLAにメッセージを向けます。(次に、MLAはMLのメンバーにメッセージを再配付します)。 このプロセスは、個々のユーザエージェントから1受取人あたりの処理を積み下ろして、大きいMLsの、より効率的な管理を考慮します。 MLsはメーリングリストのための暗号と拡張サービスを提供するMLAsによって役立たれた本当のメッセージ受取人です。
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
メッセージの暗号の取り扱いに加えて、安全なメーリングリストもメール輪を防がなければなりません。 メール輪は1つのメーリングリストが2番目のメーリングリストのメンバーと、2番目であるところです。
Hoffman Standards Track [Page 32] RFC 2634 Enhanced Security Services for S/MIME June 1999
ホフマン標準化過程[32ページ]RFC2634は1999年6月にS/MIMEのためのセキュリティー・サービスを機能アップしました。
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.
メール輪を防ぐために、MLAsは三重の包装されたメッセージの外側の署名のmlExpansionHistory属性を使用します。 mlExpansionHistory属性は本質的にはメッセージを処理したあらゆるMLAのリストです。 MLAがリストのそれ自身のユニークなエンティティ識別名を見るなら、それは、輪が形成されて、再びメッセージをリストに送らないのを知っています。
4.1 Mail List Expansion
4.1 メール・リスト拡張
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は署名しているmlExpansionHistory属性値を作成するか、またはMLAがメール・リストのメンバーへのメッセージを広げて、署名するたびにアップデートします。
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 MUSTはメール・リスト拡張歴史系列の終わりまでMLAの識別情報、拡張の日時、および任意の領収書方針を含むMLData記録を加えます。 mlExpansionHistory属性が休みます、次に、MLA MUSTが属性を加えるということであり、現在の拡張が系列の最初の原理になるなら。 mlExpansionHistory属性が存在しているなら、MLA MUSTは既存のMLExpansionHistory系列の終わりに現在の拡張情報を加えます。 SignerInfoのsignedAttributesに1つのmlExpansionHistory属性しか含むことができません。
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オブジェクトは複数のSignerInfos、mlExpansionHistory属性を持っている各SignerInfoを含むかもしれません。 例えば、MLAは2SignerInfos、1がある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属性を含まないかもしれません。
Hoffman Standards Track [Page 33] RFC 2634 Enhanced Security Services for S/MIME June 1999
ホフマン標準化過程[33ページ]RFC2634は1999年6月にS/MIMEのためのセキュリティー・サービスを機能アップしました。
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属性を持っている1SignerInfoがあるなら、受取人は、それが確かめたすべてのSignerInfosでmlExpansionHistory属性を比較しなければならなくて、SignedDataブロックのあらゆる確かめられたmlExpansionHistory属性が同じであるというわけではないなら、mlExpansionHistory属性を処理してはいけません。 確かめられたsignerInfosのmlExpansionHistory属性がすべて同じでないなら、受信エージェントは、メッセージを処理するのを止めなければなりません、そして、SHOULDはこのエラー条件についてユーザかMLA管理者に通知します。 mlExpansionHistory処理では、mlExpansionHistory属性を持っていないSignerInfosが無視されます。
4.1.1 Detecting Mail List Expansion Loops
4.1.1 メール・リスト伸縮ループを検出すること。
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は拡張処理を中止しなければならなくて、人間のメール・リスト管理者に伸縮ループに関する警告を提供するはずです。 メール・リスト管理者は輪の状態を修正するのに責任があります。
4.2 Mail List Agent Processing
4.2 メール・リストエージェント処理
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メッセージ--二重包装されたメッセージ(など署名されて、おおわれて、おおわれて、署名されるか、署名されて、または署名されるように)--4倍で包装されたメッセージ(ゲートウェイを通して整形式の三重の包装されたメッセージを送ったならそれが外側のSignedData層を加えたようなもの)
Hoffman Standards Track [Page 34] RFC 2634 Enhanced Security Services for S/MIME June 1999
ホフマン標準化過程[34ページ]RFC2634は1999年6月にS/MIMEのためのセキュリティー・サービスを機能アップしました。
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 MUSTは何かeSSSecurityLabel signedAttributeを含んでいるsignedData層があるかどうか決定する受信されたメッセージのすべての層を分析します。 これは、カプセル化されたSignedData層がeSSSecurityLabel属性を含んでいるかどうか決定するためにEnvelopedData層を解読するのを含むかもしれません。 MLA MUSTは様々なsignedData層で見つけられたそれぞれのeSSSecurityLabel属性を完全に処理します、アクセス制御チェックを実行するのを含んでいて、MLメンバーにメッセージを分配する前に。 アクセス制御チェックの詳細はこのドキュメントの範囲を超えています。 MLA MUSTはそれを使用する前に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 MUSTは新しい「外側」のsignedData層のMLメンバーに送られるべきメッセージに署名します。 MLA MUSTはそれがドキュメントMLA処理に作成する「外側」のsignedDataでmlExpansionHistory属性を加えるか、またはアップデートします。 MLAによって受け取られたオリジナルのメッセージに含まれていた「外側」のsignedData層があったなら、MLAによって作成された「外側」のsignedData層はオリジナルの「外側」のsignedData層の中の現在のそれぞれの署名している属性を含まなければなりません、MLAが明らかに、属性(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 MUSTは、最初に、もしあればどの容認されたsignedData層が「外側」のsignedData層であるかを決定します。 容認された「外側」のsignedData層を特定するなら、MLA MUSTは、署名について確かめて、彼らのどれかがmlExpansionHistory属性を含んでいるか、またはenvelopedDataオブジェクトをカプセルに入れるかを決定するためにそれぞれの外側のsignedData層(中で外部から働いていて)でsignedAttributesを完全に処理します。
The MLA's search for the "outer" signedData layer is completed when it finds one of the following:
以下の1つを見つけると、「外側」の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).
- mlExpansionHistory属性を含んでいるか、またはenvelopedDataオブジェクト--envelopedData層--オリジナルコンテンツが(すなわち、envelopedDataでなくてまたsignedDataでない層)であるとカプセル化する「外側」のsignedData層。
If the MLA finds an "outer" signedData layer, then the MLA MUST perform the following steps:
MLAが「外側」のsignedData層を見つけるなら、MLA MUSTは以下のステップを実行します:
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)
2. 「外側」のsignedData層自体を全部はぎ取ってください。(含まれているsignedAttributesを覚えていた後の)
Hoffman Standards Track [Page 35] RFC 2634 Enhanced Security Services for S/MIME June 1999
ホフマン標準化過程[35ページ]RFC2634は1999年6月にS/MIMEのためのセキュリティー・サービスを機能アップしました。
3. Expand the envelopedData (if present)
3. envelopedDataを広げてください。(存在しているなら)
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. オリジナルの、そして、容認された「外側」のsignedData層からsignedAttributesを含んでいる(明らかに取り替えられない場合)新しい「外側」のsignedData層のMLメンバーに送られるべきメッセージに署名してください。
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が「外側」のsignedData層を見つけるなら、それはmlExpansionHistory属性を含んでいます、そして、MLAは次に、受信されたメッセージの層で、より深く埋められたenvelopedData層を見つけます; 次に、signedDataのすべてのMLA MUST片は、envelopedData層(オリジナルの「外側」のsignedData層を全部はぎ取るのを含んでいる)まで層にして、オリジナルの、そして、容認された「外側」のsignedData層からsignedAttributesを含んでいる(明らかに取り替えられない場合)新しい「外側」のsignedData層の中で拡張envelopedDataに署名しなければなりません。
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 MUSTは新しい「外側」のsignedData層の中でオリジナルの、そして、受信されたメッセージに署名します。 MLAが「外側」のsignedDataを見つけないで、envelopedData層を見つけるなら、それは、存在しているならenvelopedData層を膨張させて、新しい「外側」のsignedData層の中でそれに署名しなければなりません。
4.2.1 Examples of Rule Processing
4.2.1 規則処理に関する例
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(オリジナルのContent)) (SがSignedDataと等しいところ) signedData層がMLExpansionHistory属性を含んでいないMLAに送ります。 MLAはS1でsignedAttributesを確かめて、完全、処理します。 MLAはオリジナルコンテンツを見つけるのでオリジナルの、そして、容認された「外側」のsignedData層がないと決めますが、envelopedDataを見つけて、mlExpansionHistory属性は決して見つけません。 ML受取人に送られた以下のメッセージをもたらして、MLAは新しいsignedData層、S2について計算します: (S2(S1(オリジナルコンテンツ))。) 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
2) メッセージ(S3(S2(S1(オリジナルのContent))))をsignedData層のいずれもMLExpansionHistory属性を含んでいないMLAに送ります。 MLAはS3、S2、およびS1でsignedAttributesを確かめて、完全、処理します。 MLAはオリジナルコンテンツを見つけるのでオリジナルの、そして、容認された「外側」のsignedData層がないと決めますが、envelopedDataを見つけて、mlExpansionHistory属性は決して見つけません。 以下をもたらして、MLAは新しいsignedData層、S4について計算します。
Hoffman Standards Track [Page 36] RFC 2634 Enhanced Security Services for S/MIME June 1999
ホフマン標準化過程[36ページ]RFC2634は1999年6月にS/MIMEのためのセキュリティー・サービスを機能アップしました。
message sent to the ML recipients:
(S4(S3(S2(S1(Original Content))))). The MLA includes an
mlExpansionHistory attribute in S4.
メッセージはML受取人に発信しました: (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) メッセージ(1E(S1(オリジナルのContent))) (EがenvelopedDataと等しいところ) S1がMLExpansionHistory属性を含んでいないMLAに送ります。 MLAは、外側の層として1Eを見つけるのでオリジナルの、そして、容認された「外側」のsignedData層がないと決めます。 MLAは1EでrecipientInformationを広げます。 ML受取人に送られた以下のメッセージをもたらして、MLAは新しいsignedData層、S2について計算します: (S2(1E(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(1E(S1(オリジナルのContent))))をS2がMLExpansionHistory属性を含んでいるMLAに送ります。 MLAは署名について確かめて、S2でsignedAttributesを完全に処理します。 MLAがS2でmlExpansionHistory属性を見つけるので、S2が「外側」のsignedDataであることは決めます。 MLAは、それがメッセージに適用する新しい外側のsignedDataでの後の包含のためにS2にsignedAttributesを含んでいたのを覚えています。 MLAはS2を全部はぎ取ります。 そして、MLAは1EでrecipientInformationを広げます(これはS2で署名を無効にします(それが剥取られた理由です))。 ML受取人に送られた以下のメッセージをもたらして、nMLAは新しいsignedData層、S3について計算します: (S3(1E(S1(オリジナルコンテンツ)))。) アップデートされたmlExpansionHistory属性を含んでいて、MLAはS3に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(1E(S1(オリジナルのContent)))))をsignedData層のいずれもMLExpansionHistory属性を含んでいないMLAに送ります。 MLAは署名について確かめて、S3とS2でsignedAttributesを完全に処理します。 MLAが1Eに遭遇すると、S2が1Eをカプセル化するのでS2が「外側」のsignedDataであることは決めます。 MLAは、それがメッセージに適用する新しい外側のsignedDataでの後の包含のためにS2にsignedAttributesを含んでいたのを覚えています。 MLAはS3とS2を全部はぎ取ります。 そして、MLAは1EでrecipientInformationを広げます(これはS3とS2で署名を無効にします(それらが剥取られた理由です))。 ML受取人に送られた以下のメッセージをもたらして、MLAは新しいsignedData層、S4について計算します: (S4(1E(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
6) メッセージ(S3(S2(1E(S1(オリジナルのContent)))))をS3がMLExpansionHistory属性を含んでいるMLAに送ります。 この場合、MLAは署名について確かめて、完全に処理します。
Hoffman Standards Track [Page 37] RFC 2634 Enhanced Security Services for S/MIME June 1999
ホフマン標準化過程[37ページ]RFC2634は1999年6月にS/MIMEのためのセキュリティー・サービスを機能アップしました。
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.
S3のsignedAttributes。 MLAがS3でmlExpansionHistoryを見つけるので、S3が「外側」のsignedDataであることは決めます。 MLAは、それがメッセージに適用する新しい外側のsignedDataでの後の包含のためにS3にsignedAttributesを含んでいたのを覚えています。 MLAは何かeSSSecurityLabel属性があるかどうか決定しなければならないので層であるとカプセル化された構文解析のときに中に含まれた状態で保ちます。 MLAは署名について確かめて、S2でsignedAttributesを完全に処理します。 MLAが1Eに遭遇すると、それはS3とS2を全部はぎ取ります。 そして、MLAは1EでrecipientInformationを広げます(これはS3とS2で署名を無効にします(それらが剥取られた理由です))。 ML受取人に送られた以下のメッセージをもたらして、MLAは新しいsignedData層、S4について計算します: (S4(1E(S1(オリジナルコンテンツ)))。) アップデートされたmlExpansionHistory属性を含んでいて、MLAはS4にS3(明確に属性値を取り替えない場合)からの属性を含んでいます。
4.2.3 Processing Choices
4.2.3 処理選択
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--データ
4.2.3.1 Processing for EnvelopedData
4.2.3.1 EnvelopedDataのための処理
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はSignedDataブロックの拡張暗号化メッセージをカプセル化します、拡張を記録するために「メール・リスト拡張」セクションで説明されるようにmlExpansionHistory属性を加えて。
4. The MLA signs the new message and delivers the updated message to
mail list members to complete MLA processing.
4. MLAは、MLA処理を終了するために新しいメッセージに署名して、リストメンバーに郵送するアップデートされたメッセージを提供します。
Hoffman Standards Track [Page 38] RFC 2634 Enhanced Security Services for S/MIME June 1999
ホフマン標準化過程[38ページ]RFC2634は1999年6月にS/MIMEのためのセキュリティー・サービスを機能アップしました。
4.2.3.2 Processing for SignedData
4.2.3.2 SignedDataのための処理
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.
2. MLAは、「メール・リスト拡張を検出するのは輪にする」というセクションで説明されるように伸縮ループがないかどうか一番はずれのSignedData層が署名しているmlExpansionHistory属性を含んでいるならステップ3に行くようにチェックします。 一番はずれのSignedData層が署名しているmlExpansionHistory属性を含んでいないなら、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.1. 署名しているデータがEnvelopedDataであるなら、MLAは以前に説明されるように暗号化メッセージの拡張処理を実行します。 このプロセスがオリジナルの暗号化メッセージに関連している一番はずれのSignedData層の中で署名値を無効にすることに注意してください。 拡張の結果があるセクション3.2に続いてください。
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.1. mlExpansionHistoryの値と他のすべての署名している属性を覚えていた後にMLAはその層の中で既存の一番はずれのSignedData層を剥取ります、存在しているなら。
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
3.2.2. 署名しているデータがEnvelopedData(ステップ3.1からの)であるなら、MLAは新しい一番はずれのSignedData層の中で拡張暗号化メッセージをカプセル化します。 もう片方に関して
Hoffman Standards Track [Page 39] RFC 2634 Enhanced Security Services for S/MIME June 1999
ホフマン標準化過程[39ページ]RFC2634は1999年6月にS/MIMEのためのセキュリティー・サービスを機能アップしました。
hand, if the signed data is SignedData (from step
3.2), the MLA encapsulates the signed data in a new
outermost SignedData layer.
手で、署名しているデータが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 MUSTはオリジナルの一番はずれのsignedData層の中に存在していた状態でそれぞれの署名している属性を含まなければならない新しい一番はずれのsignedData層のための署名している属性リストを作成します、MLAが明らかに1つ以上の特定の属性を新しい値に取り替えない場合。 特別なケースはmlExpansionHistory属性です。 MLA MUSTは以下の外側のsignedData層に属性であると署名されるmlExpansionHistoryを加えます:
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.1. オリジナルの一番はずれのSignedData層がmlExpansionHistory属性を含んでいたなら、「メール・リスト拡張」セクションで説明されるように現在のML拡張情報で属性の値をコピーして、アップデートします。
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. If the signed data is not EnvelopedData or SignedData:
3.3. 署名しているデータはEnvelopedDataでないか、そして、SignedData:
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.
3.3.1. MLAは外側のSignedDataオブジェクトで容認されたsignedDataオブジェクトをカプセルに入れって、「メール・リスト拡張」セクションで説明されるように現在のML拡張情報を含む外側のSignedDataオブジェクトにmlExpansionHistory属性を加えます。
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. 有効な署名を持っていますか? はい、->2。 ->停止がありません。 2. 一番はずれのSignedData層はmlExpansionHistoryを含んでいますか? はい、->Check。そして、それ、->3。 STOP、どんな->Signも通信しないで(mlExpansionHistoryを持っていない一番はずれのSignedDataを含んでいて)、それを提供してください。 3. 一番はずれのSignedDataのすぐ下でデータのタイプをチェックしてください。
Hoffman Standards Track [Page 40] RFC 2634 Enhanced Security Services for S/MIME June 1999
ホフマン標準化過程[40ページ]RFC2634は1999年6月にS/MIMEのためのセキュリティー・サービスを機能アップしました。
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. mlExpansionHistoryと他の署名している属性の値、当時の->3.2.2は、片の一番はずれのSignedDataが層にすることに注意します。 3.2.2. 新しい署名、当時->3.2.3では、要約してください。 3.2.3. 新しいsignedData層を作成してください。 古いmlExpansionHistoryがありましたか? はい->は古いmlExpansionHistory値、当時->4をコピーします。 いいえ->は新しいmlExpansionHistory値、当時->4を作成します。 3.3. SignedData層の中で要約してください、そして、mlExpansionHistory属性、当時->4を加えてください。 4. STOP、メッセージに署名してください、そして、それを提供してください。
4.2.3.3 Processing for data
4.2.3.3 データのための処理
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処理を終了するために新しいメッセージに署名して、リストメンバーに郵送するアップデートされたメッセージを提供します。
4.3 Mail List Agent Signed Receipt Policy Processing
4.3メール・リストエージェントは、領収書が方針処理であると署名しました。
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は、メーリングリスト(B)が別のメーリングリスト(A)のメンバーであるなら、しばしばA.のメーリングリスト領収書方針を前方に伝播する必要があります。究極の受取人がML拡張歴史における最後の項目を処理するだけでよいので、一般的な規則、メーリングリストが伝播するのにおいて保守的であるべきAsはメーリングリスト領収書方針を進めます。 MLAは、この必要条件を満たすために拡張歴史を造ります。
Hoffman Standards Track [Page 41] RFC 2634 Enhanced Security Services for S/MIME June 1999
ホフマン標準化過程[41ページ]RFC2634は1999年6月にS/MIMEのためのセキュリティー・サービスを機能アップしました。
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'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
| ビーズ方針Aの方針| insteadOf inAdditionToなくなっていないなにも----------------------------------------------------------------------- なし| なにも、なにも、なにも、insteadOfのいずれも| なにも、insteadOf(B)*1insteadOf(A) inAdditionTo| insteadOf(B)*2inAdditionTo(A)なくなっていないなにも| insteadOf(B) inAdditionTo(B)なくなっていないなにも
*1 = insteadOf(insteadOf(A) + inAdditionTo(B)) *2 = inAdditionTo(inAdditionTo(A) + inAdditionTo(B))
*1 = insteadOf、(insteadOf(A)+inAdditionTo(B))*2はinAdditionToと等しいです。(inAdditionTo(A)+inAdditionTo(B))
4.4 Mail List Expansion History Syntax
4.4メール・リスト拡張歴史構文
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ミリリットル、拡張歴史、系列のメーリングリスト、受信エージェントは人間のメール・リスト管理者に誤りの通知を提供するべきです。 メール・リスト管理者はオーバーフロー条件を修正するのに責任があります。
MLExpansionHistory ::= SEQUENCE
SIZE (1..ub-ml-expansion-history) OF MLData
MLExpansionHistory:、:= 系列サイズ、(1..ubミリリットル、拡張歴史、)、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}
イド-aa-mlExpandHistoryオブジェクト識別子:、:= iso(1)は(2) 私たち(840)rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)イド-aa(2)3をメンバーと同じくらい具体化させます。
ub-ml-expansion-history INTEGER ::= 64
ubミリリットル、拡張歴史、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 }
MLData:、:= 系列expansionTime GeneralizedTimeの、そして、mlReceiptPolicy MLReceiptPolicy任意のmailListIdentifier EntityIdentifier
EntityIdentifier ::= CHOICE {
issuerAndSerialNumber IssuerAndSerialNumber,
subjectKeyIdentifier SubjectKeyIdentifier }
EntityIdentifier:、:= 選択issuerAndSerialNumber IssuerAndSerialNumber、subjectKeyIdentifier SubjectKeyIdentifier
Hoffman Standards Track [Page 42] RFC 2634 Enhanced Security Services for S/MIME June 1999
ホフマン標準化過程[42ページ]RFC2634は1999年6月にS/MIMEのためのセキュリティー・サービスを機能アップしました。
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 MAYはその事実を創始者に知らせます。
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は署名している領収書を求める創始者の要求に取って代わる領収書方針を指定します。 方針は3つの可能性の1つであるかもしれません: (なにも)を領収書に返してはいけません。 受取人の補欠リスト創始者(insteadOf)の代わりに領収書を返すべきです。 または、創始者(inAdditionTo)に加えて受取人のリストに領収書を返すべきです。
MLReceiptPolicy ::= CHOICE {
none [0] NULL,
insteadOf [1] SEQUENCE SIZE (1..MAX) OF GeneralNames,
inAdditionTo [2] SEQUENCE SIZE (1..MAX) OF GeneralNames }
MLReceiptPolicy:、:= 選択なにも、[0]NULL、insteadOf[1]SEQUENCE SIZE(1..MAX)OF GeneralNames、inAdditionTo[2]SEQUENCE SIZE(1..MAX)OF GeneralNames
5. Signing Certificate Attribute
5. 署名証明書属性
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通の証明書の代替に対処する1セットの可能な攻撃の記述を提示します。 これらの攻撃を防ぐか、または扱うための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オブジェクトにおける署名でカバーされています。 このセクションのメソッドは、承認証明書のセットが署名証明書属性の一部として記載されているのを許容します。
Hoffman Standards Track [Page 43] RFC 2634 Enhanced Security Services for S/MIME June 1999
ホフマン標準化過程[43ページ]RFC2634は1999年6月にS/MIMEのためのセキュリティー・サービスを機能アップしました。
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.
また、署名照合プロセスの一部として明白な証明書方針を使用できます。 署名者が、署名を有効にするとき使用されるべきである明白な証明書方針を述べることを望んでいるなら、その方針は、暗号でサインアップ過程に縛られる必要があります。 このセクションで説明されたメソッドは、1セットの証明書施政方針が署名証明書属性の一部として記載されているのを許容します。
5.1. Attack Descriptions
5.1. 攻撃記述
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.
署名照合プロセスで使用される証明書かcertficatesを置き換えることによって、可能な署名照合プロセスに対して少なくとも3つの異なった攻撃に着手できます。
5.1.1 Substitution Attack Description
5.1.1 代替攻撃記述
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.
最初の攻撃は別の証明書のための1通の証明書の簡単な代替に対処します。 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.
第2バージョンは証明書の公開鍵が合っているオリジナルの有効な証明書のための1つの有効な証明書の代替です。 これは、メッセージの創始者が意図したより署名が潜在的に異なった証明書規制で有効にされるのを許容します。
5.1.2 Reissue of Certificate Description
5.1.2 証明書記述の再発行
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.
2番目の攻撃は、署名証明書を再発行しながら(または、潜在的に証明書の1つ)、認証局(カリフォルニア)に対処します。 この攻撃は、Certificate Authoritiesがそれら自身のルート証明書を再発行するか、または認証局が証明書の方針を変えるのに従ってそれらのルート証明書を再発行している間、より頻繁になり始めるかもしれません。 また、署名について確かめることの途中に交差している証明書(潜在的に異なった制限がある)が使用されるとき、この問題は起こります。
Hoffman Standards Track [Page 44] RFC 2634 Enhanced Security Services for S/MIME June 1999
ホフマン標準化過程[44ページ]RFC2634は1999年6月にS/MIMEのためのセキュリティー・サービスを機能アップしました。
5.1.3 Rogue Duplicate CA Description
5.1.3 写しカリフォルニアの記述をだましてください。
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.
3番目の攻撃は既存のカリフォルニアの構造をコピーするのを試みる認証局をセットアップする凶暴な実体に対処します。 明確に、凶暴な実体は凶暴な実体の秘密鍵によって使用されますが、署名される署名者と同じ公開鍵で新しい証明書を発行します。
5.2 Attack Responses
5.2 攻撃応答
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.
このドキュメントは、上の攻撃のすべてを解決するのを試みません。 しかしながら、このセクションでそれぞれの攻撃への応答の簡単な説明を与えます。
5.2.1 Substitution Attack Response
5.2.1 代替攻撃応答
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.
2回の異なったマナーで有効な証明書の代替に応じることができます。 1番目は2通の異なった証明書における同じ公開鍵の使用が悪い習慣であり、避けられなければならないという毛布声明を出すことです。 実際には、同じ公開鍵でユーザが新しい証明書を手に入れるのを防ぐどんな実用的な方法もありません、そして、これをすると思われるべきです。 セクション5.4は属性であると署名されるSignerInfoに含むことができる新しい属性を提供します。 これは正しい証明書識別子を署名に縛ります。 これは潜在的にうまくいっているものから単にサービス不能攻撃までの攻撃を変換するでしょう。
5.2.2 Reissue of Certificate Response
5.2.2 証明書応答の再発行
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.
カリフォルニアは異なった属性で決して免許状を再交付するべきではありません。 そうする証明書Authoritiesはお粗末な商売に続いていて、当てにすることができません。 証明書の参照として証明書のハッシュを使用すると、終わり実体証明書のためのこの攻撃は防がれます。
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
カリフォルニア証明書の再発行に基づく攻撃を防ぐのはセクション5.4に示されたsigningCertificate属性の用法への大きな変化を必要とするでしょう。 署名者の証明経路に発行人証明書を表すのが、ESSCertIDsが、属性に含まれる必要であるのを必要とするでしょう。 信用パーティーが認証過程の一部として交差している証明書を使用しているとき、これは問題を提示します、そして、この証明書は現れません。
Hoffman Standards Track [Page 45] RFC 2634 Enhanced Security Services for S/MIME June 1999
ホフマン標準化過程[45ページ]RFC2634は1999年6月にS/MIMEのためのセキュリティー・サービスを機能アップしました。
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.
証明書のリストで。 閉じているPKIにおける外の問題でこの情報の追加は誤りに傾向があるようになります、ことによると有効なチェーンの拒絶を引き起こして。
5.2.3 Rogue Duplicate CA Response
5.2.3 写しカリフォルニアの応答をだましてください。
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.
この攻撃を防ぐ最も良いメソッドは凶暴なカリフォルニアを信じるのを避けることです。 証明書を特定するハッシュの使用は凶暴な権威から終わり実体証明書の使用を防ぎます。 しかしながら、この攻撃を防ぐ唯一の真の方法は凶暴なカリフォルニアを決して信じないことです。
5.3 Related Signature Verification Context
5.3 関連署名照合文脈
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で説明された署名証明書属性は署名の一部としてこの文脈情報を縛る能力を提供します。
5.3.1 Authorization Information
5.3.1 承認情報
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オブジェクトに1セットの属性証明書と公開鍵証明書を含む能力があります。 受信機には、ディレクトリサービスからの属性証明書と公開鍵証明書を検索する能力があります。 いくつかの事情が署名者が署名について確かめる際に使用されるかもしれない証明書のセットを制限したがっているかもしれないところにあります。 署名者が、受取人が署名を有効にする際に使用する必要がある証明書のセットを記載できるのは役に立ちます。
5.3.2 Policy Information
5.3.2 方針情報
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.
証明書結合の関連する局面は複数の証明経路の問題です。 ある場合に、メッセージがある使用での証明書の意味論は適用されるCertificate Authoritiesと方針によるかもしれません。 また、この問題を扱うために、署名者は署名でその文脈を縛りたがっているかもしれません。 どちらかの署名による完全な証明経路か方針IDがこれにできましたが、ここで方針IDのための結合だけについて説明します。
Hoffman Standards Track [Page 46] RFC 2634 Enhanced Security Services for S/MIME June 1999
ホフマン標準化過程[46ページ]RFC2634は1999年6月にS/MIMEのためのセキュリティー・サービスを機能アップしました。
5.4 Signing Certificate Attribute Definition
5.4 署名証明書属性定義
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
}
SigningCertificate:、:= 系列本命SEQUENCE OF ESSCertID、方針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 }
イド-aa-signingCertificateオブジェクト識別子:、:= iso(1)は(2) 私たち(840)rsadsi(113549) pkcs(1) pkcs9(9) smime(16)イド-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.
証明書識別子の系列で特定された最初の証明書は署名について確かめるのに使用される証明書であるに違いありません。 この証明書SHOULDのための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.
1通以上の証明書がESSCertIDsの系列で存在しているなら、最初のものの後の証明書は署名合法化の間に使用される承認証明書のセットを制限します。 承認証明書は、属性証明書か正常な証明書のどちらかであるかもしれません。 issuerSerialは(ESSCertID構造の)SHOULDをさばきます。これらの証明書のために存在してください、署名を有効にしているクライアントが合法化のためにrequredされたすべての証明書にたやすく近づく手段を持っていないと予想される場合。 署名証明書だけが系列で存在しているなら、制限が全く署名を有効にする際に使用される承認証明書のセットにありません。
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
存在しているなら、SigningCertificate属性は署名している属性であるに違いありません。 それは未署名の属性であるはずがありません。 CMSはSignedAttributesをSET OF Attributeと定義します。 SignerInfoは含んではいけません。
Hoffman Standards Track [Page 47] RFC 2634 Enhanced Security Services for S/MIME June 1999
ホフマン標準化過程[47ページ]RFC2634は1999年6月にS/MIMEのためのセキュリティー・サービスを機能アップしました。
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属性の複数のインスタンス。 署名している属性がattrValues SET OF AttributeValueを含むように、CMSはASN.1構文を定義します。 SigningCertificate属性はAttributeValueのただ一つのインスタンスだけを含まなければなりません。 attrValues SET OF AttributeValueの現在のAttributeValueのゼロか複数のインスタンスがあるはずがありません。
5.4.1 Certificate Identification
5.4.1 証明書識別
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オブジェクトに含まれていないとき、正しいセットの証明書を証明書のハッシュだけに基づかせているのははるかに難しくなります。 この理由で、これらはSHOULDを証明します。IssuerSerialオブジェクトで、特定されます。
This document defines a certificate identifier as:
このドキュメントは証明書識別子を以下と定義します。
ESSCertID ::= SEQUENCE {
certHash Hash,
issuerSerial IssuerSerial OPTIONAL
}
ESSCertID:、:= 系列certHashハッシュで、issuerSerial IssuerSerial任意です。
Hash ::= OCTET STRING -- SHA1 hash of entire certificate
以下を論じ尽くしてください:= OCTET STRING--全体の証明書のSHA1ハッシュ
IssuerSerial ::= SEQUENCE {
issuer GeneralNames,
serialNumber CertificateSerialNumber
}
IssuerSerial:、:= 系列発行人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は存在しているでしょう。
Hoffman Standards Track [Page 48] RFC 2634 Enhanced Security Services for S/MIME June 1999
ホフマン標準化過程[48ページ]RFC2634は1999年6月にS/MIMEのためのセキュリティー・サービスを機能アップしました。
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選択でコード化された証明書からの発行人名だけを含まなければなりません。 属性証明書に関しては、発行人は属性証明書からの発行人名前欄を含まなければなりません。
6. Security Considerations
6. セキュリティ問題
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は、受け身の攻撃者が領収書による情報を収集するのを防ぐために領収書を暗号化すると考えるべきです。
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.
Sendersは、正しく機密保護ラベルを処理するために受取人の処理ソフトウェアを当てにしてはいけません。 すなわち、送付者は、機密保護ラベルをメッセージに追加するのが、受取人が送付者が、それらに見て欲しくないメッセージを見るのを防ぐと仮定できません。 機密保護ラベルを理解しませんが、それでもラベルされたメッセージを受取人に表示する多くの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.
介入者攻撃で、その攻撃者に受取人が有効にすることができる署名があるなら、受取人は領収書を攻撃者に送ることができます。 オリジナルのメッセージを傍受して、領収書が他の誰でもに加えて攻撃者に送られるべきであると言うmLData属性が領収書を手に入れるつもりであったと言い足すのから攻撃は成ります。
Hoffman Standards Track [Page 49] RFC 2634 Enhanced Security Services for S/MIME June 1999
ホフマン標準化過程[49ページ]RFC2634は1999年6月にS/MIMEのためのセキュリティー・サービスを機能アップしました。
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.
セクション4で説明されたメーリングリスト管理を使用しないなら、それらの内容を暗号化するメーリングリストはサービスの否定攻撃のための目標であるかもしれません。 簡単なRFC822ヘッダースプーフィングを使用して、1つの暗号化されたメーリングリストを別のものに申し込むのはかなり簡単です、その結果、無限ループをセットアップします。
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.
郵送Listエージェントは、適応型の選ばれた暗号文攻撃のための神託が[CMS]で説明したように彼らを使用できるのを意識している必要があります。 多くの非解読可能メッセージが受信されているなら、MLAsは管理者に通知するはずです。
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で説明された攻撃で、受信機は、署名が有効であると思うことができます。
Hoffman Standards Track [Page 50] RFC 2634 Enhanced Security Services for S/MIME June 1999
ホフマン標準化過程[50ページ]RFC2634は1999年6月にS/MIMEのためのセキュリティー・サービスを機能アップしました。
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) }
ExtendedSecurityServicesiso(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)}
-- CryptographicMessageSyntaxからの暗号のメッセージ構文(cm)ContentType、IssuerAndSerialNumber、SubjectKeyIdentifieriso(1)が(2) 私たちをメンバーと同じくらい具体化させる、(840)rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)モジュール(0)cm(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)}
-- A.2がそれとなくモジュールにタグ付けをしたPKIX証明書とCRLプロフィール、秒--PKIX1Implicit88からの1988構文PolicyInformationiso(1)の特定された組織(3)のdod(6)インターネット(1)セキュリティ(5)メカニズム(5)pkix(7)イドモッズ(0)のイドのpkix1の内在している88(2)
-- X.509
GeneralNames, CertificateSerialNumber FROM CertificateExtensions
{joint-iso-ccitt ds(5) module(1) certificateExtensions(26) 0};
-- X.509 GeneralNames、CertificateSerialNumber FROM CertificateExtensions共同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.
-- 構造物が「サイズ(1..MAX)を配列する」、出現、コネ数個のASN.1--このモジュールによる構造物。 または、有効なASN.1SEQUENCEがゼロを持つことができる、--より多くのエントリー。 (1..MAX)構造物がSEQUENCEを抑制するSIZE--少なくとも1つのエントリーを持ってください。 MAXは、上限が不特定であることを示します。 -- 実装が自由に適合する上限を選ぶことができる、それら、--環境。
UTF8String ::= [UNIVERSAL 12] IMPLICIT OCTET STRING
-- The contents are formatted as described in [UTF8]
UTF8String:、:= [UNIVERSAL12]IMPLICIT OCTET STRING--内容は中で説明されるようにフォーマットされます。[UTF8]
-- Section 2.7
-- セクション2.7
ReceiptRequest ::= SEQUENCE {
signedContentIdentifier ContentIdentifier,
receiptsFrom ReceiptsFrom,
receiptsTo SEQUENCE SIZE (1..ub-receiptsTo) OF GeneralNames }
ReceiptRequest:、:= 系列signedContentIdentifier ContentIdentifier、receiptsFrom ReceiptsFrom、GeneralNamesのreceiptsTo系列サイズ(1..ub-receiptsTo)
ub-receiptsTo INTEGER ::= 16
ub-receiptsTo整数:、:= 16
Hoffman Standards Track [Page 51] RFC 2634 Enhanced Security Services for S/MIME June 1999
ホフマン標準化過程[51ページ]RFC2634は1999年6月にS/MIMEのためのセキュリティー・サービスを機能アップしました。
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}
イド-aa-receiptRequestオブジェクト識別子:、:= iso(1)は(2) 私たち(840)rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)イド-aa(2)1をメンバーと同じくらい具体化させます。
ContentIdentifier ::= OCTET STRING
ContentIdentifier:、:= 八重奏ストリング
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}
イド-aa-contentIdentifierオブジェクト識別子:、:= iso(1)は(2) 私たち(840)rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)イド-aa(2)7をメンバーと同じくらい具体化させます。
ReceiptsFrom ::= CHOICE {
allOrFirstTier [0] AllOrFirstTier,
-- formerly "allOrNone [0]AllOrNone"
receiptList [1] SEQUENCE OF GeneralNames }
ReceiptsFrom:、:= 選択allOrFirstTier[0]AllOrFirstTier--、以前「allOrNone[0]AllOrNone」receiptList[1]SEQUENCE OF GeneralNames
AllOrFirstTier ::= INTEGER { -- Formerly AllOrNone
allReceipts (0),
firstTierRecipients (1) }
AllOrFirstTier:、:= 整数--、以前AllOrNone allReceipts(0)、firstTierRecipients(1)
-- Section 2.8
-- セクション2.8
Receipt ::= SEQUENCE {
version ESSVersion,
contentType ContentType,
signedContentIdentifier ContentIdentifier,
originatorSignatureValue OCTET STRING }
以下を領収書を出させてください:= 系列バージョン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}
イドct領収書OBJECT IDENTIFIER:、:= iso(1)は(2) 私たち(840)rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)イドct(1)1をメンバーと同じくらい具体化させます。
ESSVersion ::= INTEGER { v1(1) }
ESSVersion:、:= 整数v1(1)
-- Section 2.9
-- セクション2.9
ContentHints ::= SEQUENCE {
contentDescription UTF8String (SIZE (1..MAX)) OPTIONAL,
contentType ContentType }
ContentHints:、:= 系列contentDescription UTF8String(サイズ(1..MAX))任意である、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}
イド-aa-contentHintオブジェクト識別子:、:= iso(1)は(2) 私たち(840)rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)イド-aa(2)4をメンバーと同じくらい具体化させます。
-- Section 2.10
-- セクション2.10
MsgSigDigest ::= OCTET STRING
MsgSigDigest:、:= 八重奏ストリング
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}
イド-aa-msgSigDigestオブジェクト識別子:、:= iso(1)は(2) 私たち(840)rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)イド-aa(2)5をメンバーと同じくらい具体化させます。
-- Section 2.11
-- セクション2.11
Hoffman Standards Track [Page 52] RFC 2634 Enhanced Security Services for S/MIME June 1999
ホフマン標準化過程[52ページ]RFC2634は1999年6月にS/MIMEのためのセキュリティー・サービスを機能アップしました。
ContentReference ::= SEQUENCE {
contentType ContentType,
signedContentIdentifier ContentIdentifier,
originatorSignatureValue OCTET STRING }
ContentReference:、:= 系列contentType ContentType、signedContentIdentifier ContentIdentifier、originatorSignatureValue八重奏ストリング
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 }
イド-aa-contentReferenceオブジェクト識別子:、:= iso(1)は(2) 私たち(840)rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)イド-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 }
ESSSecurityLabel:、:= セットします。セキュリティ方針識別子SecurityPolicyIdentifier、セキュリティ分類SecurityClassification OPTIONAL、プライバシーマークESSPrivacyMark OPTIONAL、セキュリティカテゴリ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}
イド-aa-securityLabelオブジェクト識別子:、:= iso(1)は(2) 私たち(840)rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)イド-aa(2)2をメンバーと同じくらい具体化させます。
SecurityPolicyIdentifier ::= OBJECT IDENTIFIER
SecurityPolicyIdentifier:、:= オブジェクト識別子
SecurityClassification ::= INTEGER {
unmarked (0),
unclassified (1),
restricted (2),
confidential (3),
secret (4),
top-secret (5) } (0..ub-integer-options)
SecurityClassification:、:= INTEGER、無印の(0)、(1)、部外秘な(2)、秘密の(3)、秘密(4)、トップシークレットの(5)を非分類しました。(0..ub整数オプション)
ub-integer-options INTEGER ::= 256
ub整数オプションINTEGER:、:= 256
ESSPrivacyMark ::= CHOICE {
pString PrintableString (SIZE (1..ub-privacy-mark-length)),
utf8String UTF8String (SIZE (1..MAX))
}
ESSPrivacyMark:、:= 選択pString PrintableString(サイズ(1..ubプライバシーマークの長さ))、utf8String UTF8String(サイズ(1..MAX))
ub-privacy-mark-length INTEGER ::= 128
ubプライバシーマークの長さのINTEGER:、:= 128
SecurityCategories ::= SET SIZE (1..ub-security-categories) OF
SecurityCategory
SecurityCategories:、:= SecurityCategoryのサイズ(1..ubセキュリティカテゴリ)を設定してください。
ub-security-categories INTEGER ::= 64
ubセキュリティカテゴリINTEGER:、:= 64
SecurityCategory ::= SEQUENCE {
type [0] OBJECT IDENTIFIER,
value [1] ANY DEFINED BY type -- defined by type
}
SecurityCategory:、:= 系列値[1]ANY DEFINED BYはタイプします--[0] OBJECT IDENTIFIERをタイプしてください、そして、タイプによって定義されます。
Hoffman Standards Track [Page 53] RFC 2634 Enhanced Security Services for S/MIME June 1999
ホフマン標準化過程[53ページ]RFC2634は1999年6月にS/MIMEのためのセキュリティー・サービスを機能アップしました。
--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
--以下に注意してください。 前述のSecurityCategory構文は同じ状態で作成されます--以下のSecurityCategory構文--X.411仕様に記録されるとしてencodingsに魔法をかけてください: -- --SecurityCategory:、:= SEQUENCE--[0] タイプSECURITY-CATEGORY--値[1]ANY DEFINED BYタイプ----SECURITY-CATEGORY MACRO、:、:= --始まってください--記法をタイプしてください:、:= タイプ| --VALUE NOTATIONを空にしてください:、:= 値(VALUE OBJECT IDENTIFIER)の--END
-- Section 3.4
-- セクション3.4
EquivalentLabels ::= SEQUENCE OF ESSSecurityLabel
EquivalentLabels:、:= 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}
イド-aa-equivalentLabelsオブジェクト識別子:、:= iso(1)は(2) 私たち(840)rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)イド-aa(2)9をメンバーと同じくらい具体化させます。
-- Section 4.4
-- セクション4.4
MLExpansionHistory ::= SEQUENCE
SIZE (1..ub-ml-expansion-history) OF MLData
MLExpansionHistory:、:= 系列サイズ、(1..ubミリリットル、拡張歴史、)、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}
イド-aa-mlExpandHistoryオブジェクト識別子:、:= iso(1)は(2) 私たち(840)rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)イド-aa(2)3をメンバーと同じくらい具体化させます。
ub-ml-expansion-history INTEGER ::= 64
ubミリリットル、拡張歴史、INTEGER:、:= 64
MLData ::= SEQUENCE {
mailListIdentifier EntityIdentifier,
expansionTime GeneralizedTime,
mlReceiptPolicy MLReceiptPolicy OPTIONAL }
MLData:、:= 系列expansionTime GeneralizedTimeの、そして、mlReceiptPolicy MLReceiptPolicy任意のmailListIdentifier EntityIdentifier
EntityIdentifier ::= CHOICE {
issuerAndSerialNumber IssuerAndSerialNumber,
subjectKeyIdentifier SubjectKeyIdentifier }
EntityIdentifier:、:= 選択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 }
MLReceiptPolicy:、:= 選択なにも、[0]NULL、insteadOf[1]SEQUENCE SIZE(1..MAX)OF GeneralNames、inAdditionTo[2]SEQUENCE SIZE(1..MAX)OF GeneralNames
-- Section 5.4
-- セクション5.4
Hoffman Standards Track [Page 54] RFC 2634 Enhanced Security Services for S/MIME June 1999
ホフマン標準化過程[54ページ]RFC2634は1999年6月にS/MIMEのためのセキュリティー・サービスを機能アップしました。
SigningCertificate ::= SEQUENCE {
certs SEQUENCE OF ESSCertID,
policies SEQUENCE OF PolicyInformation OPTIONAL
}
SigningCertificate:、:= 系列本命SEQUENCE OF ESSCertID、方針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 }
イド-aa-signingCertificateオブジェクト識別子:、:= iso(1)は(2) 私たち(840)rsadsi(113549) pkcs(1) pkcs9(9) smime(16)イド-aa(2)12をメンバーと同じくらい具体化させます。
ESSCertID ::= SEQUENCE {
certHash Hash,
issuerSerial IssuerSerial OPTIONAL
}
ESSCertID:、:= 系列certHashハッシュで、issuerSerial IssuerSerial任意です。
Hash ::= OCTET STRING -- SHA1 hash of entire certificate
以下を論じ尽くしてください:= OCTET STRING--全体の証明書のSHA1ハッシュ
IssuerSerial ::= SEQUENCE {
issuer GeneralNames,
serialNumber CertificateSerialNumber
}
IssuerSerial:、:= 系列発行人GeneralNames、serialNumber CertificateSerialNumber
END -- of ExtendedSecurityServices
終わり--ExtendedSecurityServicesについて
Hoffman Standards Track [Page 55] RFC 2634 Enhanced Security Services for S/MIME June 1999
ホフマン標準化過程[55ページ]RFC2634は1999年6月にS/MIMEのためのセキュリティー・サービスを機能アップしました。
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.
[本命]Ramsdell、B.、エディタ、「S/MIMEバージョン3証明書取り扱い」、RFC2632、1999年6月。
[CMS] Housley, R., "Cryptographic Message Syntax", RFC 2630,
June 1999.
[cm] Housley、R.、「暗号のメッセージ構文」、RFC2630、1999年6月。
[MSG] Ramsdell, B., Editor, "S/MIME Version 3 Message
Specification", RFC 2633, June 1999.
[MSG] Ramsdell、B.、エディタ、「S/MIMEバージョン3メッセージ仕様」、RFC2633、1999年6月。
[MUSTSHOULD] Bradner, S., "Key Words for Use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[MUSTSHOULD] ブラドナー、S.、「使用のための要件レベルを示すRFCsのキーワード」、BCP14、RFC2119、1997年3月。
[MSP4] "Secure Data Network System (SDNS) Message Security
Protocol (MSP) 4.0", Specification SDN.701, Revision A,
1997-02-06.
[MSP4]は「データ網システム(SDNS)メッセージセキュリティプロトコル(MSP)に4インチ、仕様SDN.701、改正A、1997年2月6日を確保します」。
[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:」 「暗号のメッセージ構文」、RFC2315、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メッセージ仕様」とRFC2311と1998年3月、DusseとS.とホフマンとP.とB.Ramsdell、「S/MIMEバージョン2証明書取り扱い」、RFC2312、1998年3月。
[UTF8] Yergeau, F., "UTF-8, a transformation format of ISO
10646", RFC 2279, January 1998.
[UTF8]Yergeau、1998年1月のF.、「UTF-8、ISO10646の変換形式」RFC2279。
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.
この仕事の最初の草稿はデヴィッドSoloによって準備されました。 ジョンPawlingはドキュメントの多くの段階の間、膨大な量の非常に詳細な改正仕事をしました。
Hoffman Standards Track [Page 56] RFC 2634 Enhanced Security Services for S/MIME June 1999
ホフマン標準化過程[56ページ]RFC2634は1999年6月にS/MIMEのためのセキュリティー・サービスを機能アップしました。
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カーライルアダムスダーレンHarterデヴィッド死毛デニスピンカスフランソアルソージムSchaadラスHousleyスコットHollenbeckスティーブDusse
Editor's Address
エディタのアドレス
Paul Hoffman Internet Mail Consortium 127 Segre Place Santa Cruz, CA 95060
ポールホフマンインターネットメール共同体127セグレ・Placeサンタクルス、カリフォルニア 95060
EMail: phoffman@imc.org
メール: phoffman@imc.org
Hoffman Standards Track [Page 57] RFC 2634 Enhanced Security Services for S/MIME June 1999
ホフマン標準化過程[57ページ]RFC2634は1999年6月にS/MIMEのためのセキュリティー・サービスを機能アップしました。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright(C)インターネット協会(1999)。 All rights reserved。
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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配された実装を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
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機能のための基金は現在、インターネット協会によって提供されます。
Hoffman Standards Track [Page 58]
ホフマン標準化過程[58ページ]
一覧
スポンサーリンク
