RFC5275 日本語訳
5275 CMS Symmetric Key Management and Distribution. S. Turner. June 2008. (Format: TXT=207920 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group S. Turner Request for Comments: 5275 IECA Category: Standards Track June 2008
コメントを求めるワーキンググループS.ターナー要求をネットワークでつないでください: 5275年のIECAカテゴリ: 標準化過程2008年6月
CMS Symmetric Key Management and Distribution
cm左右対称のKey Managementと分配
Status of This Memo
このメモの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Abstract
要約
This document describes a mechanism to manage (i.e., set up, distribute, and rekey) keys used with symmetric cryptographic algorithms. Also defined herein is a mechanism to organize users into groups to support distribution of encrypted content using symmetric cryptographic algorithms. The mechanism uses the Cryptographic Message Syntax (CMS) protocol and Certificate Management over CMS (CMC) protocol to manage the symmetric keys. Any member of the group can then later use this distributed shared key to decrypt other CMS encrypted objects with the symmetric key. This mechanism has been developed to support Secure/Multipurpose Internet Mail Extensions (S/MIME) Mail List Agents (MLAs).
また、ここに定義された左右対称の暗号アルゴリズムで中古のキーはグループへのユーザが暗号化された内容の分配をサポートするのを左右対称の暗号アルゴリズムを使用することで組織化するメカニズムです。このドキュメントが管理するためにメカニズムについて説明する、(すなわち、セットアップしてください、分配、rekey) メカニズムはCryptographic Message Syntax(CMS)プロトコルを使用して、CMS(CMC)の上のCertificate Managementは、対称鍵を管理するために議定書を作ります。 そして、グループのどんなメンバーも、後で対称鍵で他のCMSに暗号化されたオブジェクトを解読するのにこの分配された共有されたキーを使用できます。 Secure/マルチパーパスインターネットメールエクステンション(S/MIME)がメールListエージェント(MLAs)であるとサポートするためにこのメカニズムを開発してあります。
Turner Standards Track [Page 1] RFC 5275 CMS SymKeyDist June 2008
5275cmのターナー標準化過程[1ページ]RFC SymKeyDist2008年6月
Table of Contents
目次
1. Introduction ....................................................4
1.1. Conventions Used in This Document ..........................4
1.2. Applicability to E-mail ....................................5
1.3. Applicability to Repositories ..............................5
1.4. Using the Group Key ........................................5
2. Architecture ....................................................6
3. Protocol Interactions ...........................................7
3.1. Control Attributes .........................................8
3.1.1. GL Use KEK .........................................10
3.1.2. Delete GL ..........................................14
3.1.3. Add GL Member ......................................14
3.1.4. Delete GL Member ...................................15
3.1.5. Rekey GL ...........................................16
3.1.6. Add GL Owner .......................................16
3.1.7. Remove GL Owner ....................................17
3.1.8. GL Key Compromise ..................................17
3.1.9. GL Key Refresh .....................................18
3.1.10. GLA Query Request and Response ....................18
3.1.10.1. GLA Query Request ........................18
3.1.10.2. GLA Query Response .......................19
3.1.10.3. Request and Response Types ...............19
3.1.11. Provide Cert ......................................19
3.1.12. Update Cert .......................................20
3.1.13. GL Key ............................................21
3.2. Use of CMC, CMS, and PKIX .................................23
3.2.1. Protection Layers ..................................23
3.2.1.1. Minimum Protection ........................23
3.2.1.2. Additional Protection .....................24
3.2.2. Combining Requests and Responses ...................24
3.2.3. GLA Generated Messages .............................26
3.2.4. CMC Control Attributes and CMS Signed Attributes ...27
3.2.4.1. Using cMCStatusInfoExt ....................27
3.2.4.2. Using transactionId .......................30
3.2.4.3. Using Nonces and signingTime ..............30
3.2.4.4. CMC and CMS Attribute Support
Requirements ..............................31
3.2.5. Resubmitted GL Member Messages .....................31
3.2.6. PKIX Certificate and CRL Profile ...................31
4. Administrative Messages ........................................32
4.1. Assign KEK to GL ..........................................32
4.2. Delete GL from GLA ........................................36
4.3. Add Members to GL .........................................38
4.3.1. GLO Initiated Additions ............................39
4.3.2. Prospective Member Initiated Additions .............47
4.4. Delete Members from GL ....................................49
4.4.1. GLO Initiated Deletions ............................50
1. 序論…4 1.1. このドキュメントで中古のコンベンション…4 1.2. メールする適用性…5 1.3. 倉庫への適用性…5 1.4. グループキーを使用します…5 2. アーキテクチャ…6 3. 相互作用について議定書の中で述べてください…7 3.1. 属性を制御してください…8 3.1.1. GLはKEKを使用します…10 3.1.2. GLを削除してください…14 3.1.3. GLメンバーを加えてください…14 3.1.4. GLメンバーを削除してください…15 3.1.5. Rekey GL…16 3.1.6. GL所有者を加えてください…16 3.1.7. GL所有者を免職してください…17 3.1.8. GLの主要な感染…17 3.1.9. GLキーはリフレッシュします…18 3.1.10. GLAは要求と応答について質問します…18 3.1.10.1. GLAは要求について質問します…18 3.1.10.2. GLAは応答について質問します…19 3.1.10.3. 要求と応答タイプ…19 3.1.11. 本命を提供してください…19 3.1.12. 本命をアップデートしてください…20 3.1.13. GLキー…21 3.2. CMC、cm、およびPKIXの使用…23 3.2.1. 保護は層にされます…23 3.2.1.1. 最小の保護…23 3.2.1.2. 追加保護…24 3.2.2. 要求と応答を結合します…24 3.2.3. GLAはメッセージを生成しました…26 3.2.4. CMCコントロール属性とcmは属性に署名しました…27 3.2.4.1. cMCStatusInfoExtを使用します…27 3.2.4.2. transactionIdを使用します…30 3.2.4.3. 一回だけとsigningTimeを使用します…30 3.2.4.4. CMCとcm属性は要件をサポートします…31 3.2.5. GLメンバーメッセージを再提出します…31 3.2.6. PKIX証明書とCRLプロフィール…31 4. 管理メッセージ…32 4.1. KEKをGLに割り当ててください…32 4.2. GLAからGLを削除してください…36 4.3. GLにメンバーを加えてください…38 4.3.1. GLOは追加を開始しました…39 4.3.2. 将来のメンバーは追加を開始しました…47 4.4. GLからメンバーを削除してください…49 4.4.1. GLOは削除を開始しました…50
Turner Standards Track [Page 2] RFC 5275 CMS SymKeyDist June 2008
5275cmのターナー標準化過程[2ページ]RFC SymKeyDist2008年6月
4.4.2. Member Initiated Deletions .........................56
4.5. Request Rekey of GL .......................................57
4.5.1. GLO Initiated Rekey Requests .......................59
4.5.2. GLA Initiated Rekey Requests .......................62
4.6. Change GLO ................................................63
4.7. Indicate KEK Compromise ...................................65
4.7.1. GL Member Initiated KEK Compromise Message .........66
4.7.2. GLO Initiated KEK Compromise Message ...............67
4.8. Request KEK Refresh .......................................69
4.9. GLA Query Request and Response ............................70
4.10. Update Member Certificate ................................73
4.10.1. GLO and GLA Initiated Update Member Certificate ...73
4.10.2. GL Member Initiated Update Member Certificate .....75
5. Distribution Message ...........................................77
5.1. Distribution Process ......................................78
6. Algorithms .....................................................79
6.1. KEK Generation Algorithm ..................................79
6.2. Shared KEK Wrap Algorithm .................................79
6.3. Shared KEK Algorithm ......................................79
7. Message Transport ..............................................80
8. Security Considerations ........................................80
9. Acknowledgements ...............................................81
10. References ....................................................81
10.1. Normative References .....................................81
10.2. Informative References ...................................82
Appendix A. ASN.1 Module ..........................................83
4.4.2. メンバーは削除を開始しました…56 4.5. GLのRekeyを要求してください…57 4.5.1. GLOはRekey要求を開始しました…59 4.5.2. GLAはRekey要求を開始しました…62 4.6. GLOを変えてください…63 4.7. KEKが妥協するのを示してください…65 4.7.1. GLメンバーはKEK感染メッセージを開始しました…66 4.7.2. GLOはKEK感染メッセージを開始しました…67 4.8. KEKがリフレッシュするよう要求してください…69 4.9. GLAは要求と応答について質問します…70 4.10. メンバー証明書をアップデートしてください…73 4.10.1. GLOとGLAはアップデートメンバー証明書を開始しました…73 4.10.2. GLメンバーはアップデートメンバー証明書を開始しました…75 5. 分配メッセージ…77 5.1. 分配プロセス…78 6. アルゴリズム…79 6.1. KEK世代アルゴリズム…79 6.2. 共有されたKEKはアルゴリズムを包装します…79 6.3. KEKアルゴリズムを共有します…79 7. メッセージ輸送…80 8. セキュリティ問題…80 9. 承認…81 10. 参照…81 10.1. 標準の参照…81 10.2. 有益な参照…82 付録A.ASN.1モジュール…83
Turner Standards Track [Page 3] RFC 5275 CMS SymKeyDist June 2008
5275cmのターナー標準化過程[3ページ]RFC SymKeyDist2008年6月
1. Introduction
1. 序論
With the ever-expanding use of secure electronic communications (e.g., S/MIME [MSG]), users require a mechanism to distribute encrypted data to multiple recipients (i.e., a group of users). There are essentially two ways to encrypt the data for recipients: using asymmetric algorithms with public key certificates (PKCs) or symmetric algorithms with symmetric keys.
安全な電子通信(例えば、S/MIME[MSG])の絶えず拡張している使用で、ユーザは、複数の受取人(すなわち、ユーザー層)に暗号化されたデータを分配するためにメカニズムを必要とします。 本質的には、受取人のためにデータを暗号化する2つの方法があります: 公開鍵証明書(PKCs)がある非対称のアルゴリズムか対称鍵がある左右対称のアルゴリズムを使用します。
With asymmetric algorithms, the originator forms an originator- determined content-encryption key (CEK) and encrypts the content, using a symmetric algorithm. Then, using an asymmetric algorithm and the recipient's PKCs, the originator generates per-recipient information that either (a) encrypts the CEK for a particular recipient (ktri RecipientInfo CHOICE) or (b) transfers sufficient parameters to enable a particular recipient to independently generate the same KEK (kari RecipientInfo CHOICE). If the group is large, processing of the per-recipient information may take quite some time, not to mention the time required to collect and validate the PKCs for each of the recipients. Each recipient identifies its per-recipient information and uses the private key associated with the public key of its PKC to decrypt the CEK and hence gain access to the encrypted content.
非対称のアルゴリズムで、左右対称のアルゴリズムを使用して、創始者は、創始者断固とした満足している暗号化キー(CEK)を形成して、内容を暗号化します。 そして、非対称のアルゴリズムと受取人のPKCsを使用して、創始者は(a)が特定の受取人(ktri RecipientInfo CHOICE)のためにCEKを暗号化するか、または(b)が特定の受取人が独自に、同じKEK(kari RecipientInfo CHOICE)を生成するのを可能にすることができるくらいのパラメタを移すという1受取人あたりの情報を生成します。 グループが大きいなら、1受取人あたりの情報の処理はかなりの時間がかかるかもしれません、受取人各人のためにPKCsを集めて、有効にするのに必要である時間は言うまでもなく。 各受取人は、CEKを解読して、したがって、暗号化された内容へのアクセスを得るのに1受取人あたりの情報を特定して、PKCの公開鍵に関連している秘密鍵を使用します。
With symmetric algorithms, the origination process is slightly different. Instead of using PKCs, the originator uses a previously distributed secret key-encryption key (KEK) to encrypt the CEK (kekri RecipientInfo CHOICE). Only one copy of the encrypted CEK is required because all the recipients already have the shared KEK needed to decrypt the CEK and hence gain access to the encrypted content.
左右対称のアルゴリズムについて、創作プロセスはわずかに異なっています。 PKCsを使用することの代わりに、創始者は、CEK(kekri RecipientInfo CHOICE)を暗号化するのに以前に分配された秘密の主要な暗号化キー(KEK)を使用します。 すべての受取人が既にCEKを解読するのが必要である共有されたKEKを持って、したがって、暗号化された内容へのアクセスを得るので、暗号化されたCEKのコピー1部だけが必要です。
The techniques to protect the shared KEK are beyond the scope of this document. Only the members of the list and the key manager should have the KEK in order to maintain confidentiality. Access control to the information protected by the KEK is determined by the entity that encrypts the information, as all members of the group have access. If the entity performing the encryption wants to ensure that some subset of the group does not gain access to the information, either a different KEK should be used (shared only with this smaller group) or asymmetric algorithms should be used.
共有されたKEKを保護するテクニックはこのドキュメントの範囲を超えています。 リストのメンバーと主要なマネージャだけが、秘密性を維持するためにKEKを持つべきです。 KEKによって保護された情報へのアクセスコントロールは情報を暗号化する実体で決定します、グループのすべてのメンバーがアクセサリーを持っているとき 実体がグループの何らかの部分集合が情報へのアクセスを得ないのを保証するために暗号化必需品を実行する場合、異なったKEKが使用されるべきであるか、そして、(このより小さいグループだけを分けます)非対称のアルゴリズムが使用されるべきです。
1.1. Conventions Used in This Document
1.1. 本書では使用されるコンベンション
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 BCP 14, RFC 2119 [RFC2119].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはBCP14RFC2119[RFC2119]で説明されるように本書では解釈されることであるべきです。
Turner Standards Track [Page 4] RFC 5275 CMS SymKeyDist June 2008
5275cmのターナー標準化過程[4ページ]RFC SymKeyDist2008年6月
1.2. Applicability to E-mail
1.2. メールする適用性
One primary audience for this distribution mechanism is e-mail. Distribution lists, sometimes referred to as mail lists, support the distribution of messages to recipients subscribed to the mail list. There are two models for how the mail list can be used. If the originator is a member of the mail list, the originator sends messages encrypted with the shared KEK to the mail list (e.g., listserv or majordomo) and the message is distributed to the mail list members. If the originator is not a member of the mail list (does not have the shared KEK), the originator sends the message (encrypted for the MLA) to the Mail List Agent (MLA), and then the MLA uses the shared KEK to encrypt the message for the members. In either case, the recipients of the mail list use the previously distributed-shared KEK to decrypt the message.
この分配メカニズムのための1人のプライマリーオーディエンスはメールです。 時々メール・リストと呼ばれた発送先リストはメール・リストに申し込まれた受取人にメッセージの分配をサポートします。 どうメール・リストを使用できるように2つのモデルがあるか。 創始者がメール・リストのメンバーであるなら、創始者は共有されたKEKと共にメール・リスト(例えば、listservか家令)に暗号化されたメッセージを送ります、そして、メッセージはメール・リストメンバーに分配されます。 創始者がメール・リスト(共有されたKEKを持っていない)のメンバーでないなら、創始者はメールListエージェント(MLA)にメッセージ(MLAのために、暗号化される)を送ります、そして、次に、MLAはメンバーへのメッセージを暗号化するのに共有されたKEKを使用します。 どちらの場合ではも、メール・リストの受取人は、メッセージを解読するのに以前に分配されて共有されたKEKを使用します。
1.3. Applicability to Repositories
1.3. 倉庫への適用性
Objects can also be distributed via a repository (e.g., Lightweight Directory Access Protocol (LDAP) servers, X.500 Directory System Agents (DSAs), Web-based servers). If an object is stored in a repository encrypted with a symmetric key algorithm, anyone with the shared KEK and access to that object can then decrypt that object. The encrypted object and the encrypted, shared KEK can be stored in the repository.
また、倉庫(例えば、ライトウェイト・ディレクトリ・アクセス・プロトコル(LDAP)サーバ、X.500ディレクトリSystemエージェント(DSAs)、ウェブベースのサーバ)を通してオブジェクトを分配できます。 オブジェクトが対称鍵アルゴリズムで暗号化された倉庫に保存されるなら、そのオブジェクトへの共有されたKEKとアクセスのだれでもそのオブジェクトを解読することができます。 倉庫に暗号化されたオブジェクト、および暗号化されて、共有されたKEKを保存できます。
1.4. Using the Group Key
1.4. グループキーを使用します。
This document was written with three specific scenarios in mind: two supporting Mail List Agents and one for general message distribution. Scenario 1 depicts the originator sending a public key (PK) protected message to an MLA who then uses the shared KEK(s) to redistribute the message to the members of the list. Scenario 2 depicts the originator sending a shared KEK protected message to an MLA who then redistributes the message to the members of the list (the MLA only adds additional recipients). The key used by the originator could be a key shared either amongst all recipients or just between the member and the MLA. Note that if the originator uses a key shared only with the MLA, then the MLA will need to decrypt the message and reencrypt the message for the list recipients. Scenario 3 shows an originator sending a shared KEK protected message to a group of recipients without an intermediate MLA.
このドキュメントは念頭に3つの特定のシナリオで書かれました: 一般的なメッセージの振分けのためのメールListエージェントをサポートする2ともの。 シナリオ1は次にリストのメンバーにメッセージを再配付するのに共有されたKEK(s)を使用するMLAに公開鍵(PK)の保護されたメッセージを送る創始者について表現します。 シナリオ2は保護されたメッセージを共有されたKEKに送る創始者を次にリストのメンバーにメッセージを再配付するMLAに説明します(MLAは追加受取人を加えるだけです)。 創始者によって使用されたキーはすべての受取人の中、または、メンバーとMLAのすぐ間で共有されたキーであるかもしれません。 創始者がMLAだけと共有されたキーを使用するとMLAが、リスト受取人のためにメッセージとreencryptがメッセージであると解読する必要に注意してください。 シナリオ3は、共有されたKEKが中間的MLAなしで受取人のグループにメッセージを保護したのを創始者送付に示します。
Turner Standards Track [Page 5] RFC 5275 CMS SymKeyDist June 2008
5275cmのターナー標準化過程[5ページ]RFC SymKeyDist2008年6月
+----> +----> +---->
PK +-----+ S | S +-----+ S | S |
----> | MLA | --+----> ----> | MLA | --+----> ----+---->
+-----+ | +-----+ | |
+----> +----> +---->
+---->+---->+---->PK+-----+ S| S+-----+ S| S| ---->| MLA| --+---->。---->| MLA| --+---->。----+---->+-----+ | +-----+ | | +---->+---->+---->。
Scenario 1 Scenario 2 Scenario 3
シナリオ1シナリオ2シナリオ3
2. Architecture
2. アーキテクチャ
Figure 1 depicts the architecture to support symmetric key distribution. The Group List Agent (GLA) supports two distinct functions with two different agents:
図1は、対称鍵分配をサポートするためにアーキテクチャについて表現します。 Group Listエージェント(GLA)は2人の異なったエージェントと共に2つの別個の機能をサポートします:
- The Key Management Agent (KMA), which is responsible for
generating the shared KEKs.
- Key Managementエージェント(KMA)。(そのエージェントは共有されたKEKsを生成するのに責任があります)。
- The Group Management Agent (GMA), which is responsible for
managing the Group List (GL) to which the shared KEKs are
distributed.
- Group Managementエージェント(GMA)。(そのエージェントは共有されたKEKsが分配されているGroup List(GL)を管理するのに責任があります)。
+----------------------------------------------+
| Group List Agent | +-------+
| +------------+ + -----------------------+ | | Group |
| | Key | | Group Management Agent | |<-->| List |
| | Management |<-->| +------------+ | | | Owner |
| | Agent | | | Group List | | | +-------+
| +------------+ | +------------+ | |
| | / | \ | |
| +------------------------+ |
+----------------------------------------------+
/ | \
/ | \
+----------+ +---------+ +----------+
| Member 1 | | ... | | Member n |
+----------+ +---------+ +----------+
+----------------------------------------------+ | グループのリストエージェント| +-------+ | +------------+ + -----------------------+ | | グループ| | | キー| | 集団経営のエージェント| | <-->、| リスト| | | 管理| <-->、| +------------+ | | | 所有者| | | エージェント| | | グループリスト| | | +-------+ | +------------+ | +------------+ | | | | / | \ | | | +------------------------+ | +----------------------------------------------+ / | \ / | \ +----------+ +---------+ +----------+ | メンバー1| | ... | | メンバーn| +----------+ +---------+ +----------+
Figure 1 - Key Distribution Architecture
図1--主要な分配アーキテクチャ
A GLA may support multiple KMAs. A GLA in general supports only one GMA, but the GMA may support multiple GLs. Multiple KMAs may support a GMA in the same fashion as GLAs support multiple KMAs. Assigning a particular KMA to a GL is beyond the scope of this document.
GLAは複数のKMAsをサポートするかもしれません。 GLAは一般に1GMAだけをサポートしますが、GMAは複数のGLsをサポートするかもしれません。 GLAsが複数のKMAsをサポートするとき、複数のKMAsが同じくらいのGMAにファッションをサポートするかもしれません。 特定のKMAをGLに割り当てるのはこのドキュメントの範囲を超えています。
Modeling real-world GL implementations shows that there are very restrictive GLs, where a human determines GL membership, and very open GLs, where there are no restrictions on GL membership. To support this spectrum, the mechanism described herein supports both
本当の世界GL実装をモデル化するのは、非常に制限しているGLs、および非常に開いているGLsがあるのを示します。そこでは、人間がGL会員資格を決定します。(そこには、制限が全くGL会員資格にありません)。 このスペクトルをサポートするために、ここに説明されたメカニズムは両方をサポートします。
Turner Standards Track [Page 6] RFC 5275 CMS SymKeyDist June 2008
5275cmのターナー標準化過程[6ページ]RFC SymKeyDist2008年6月
managed (i.e., where access control is applied) and unmanaged (i.e., where no access control is applied) GLs. The access control mechanism for managed lists is beyond the scope of this document. Note: If the distribution for the list is performed by an entity other than the originator (e.g., an MLA distributing a mail message), this entity can also enforce access control rules.
管理して(すなわち、アクセスコントロールはどこに適用されていますか)、GLsを非管理しました(すなわち、どんなアクセス制御もどこに適用されていませんか)。 管理されたリストのためのアクセス管理機構はこのドキュメントの範囲を超えています。 以下に注意してください。 また、リストのための分配が創始者(例えば、メール・メッセージを分配するMLA)以外の実体によって実行されるなら、この実体はアクセス制御規則を実施できます。
In either case, the GL must initially be constructed by an entity hereafter called the Group List Owner (GLO). There may be multiple entities who 'own' the GL and who are allowed to make changes to the GL's properties or membership. The GLO determines if the GL will be managed or unmanaged and is the only entity that may delete the GL. GLO(s) may or may not be GL members. GLO(s) may also set up lists that are closed, where the GLO solely determines GL membership.
どちらの場合ではも、初めは、今後Group List Owner(GLO)と呼ばれる実体でGLを組み立てなければなりません。 そこでは、複数の実体がだれがGLを'所有しているか'、そして、だれがGLのものへの変更を特性にすることができるか、そして、会員資格であったならそうするかもしれません。 GLOはGLが管理されるか、非管理して、GLを削除するかもしれない唯一の実体であるかを決定します。 GLO(s)はGLメンバーであるかもしれません。 また、GLO(s)はGLOが唯一GL会員資格を決定するところで閉じているリストをセットアップするかもしれません。
Though Figure 1 depicts the GLA as encompassing both the KMA and GMA functions, the two functions could be supported by the same entity or they could be supported by two different entities. If two entities are used, they could be located on one or two platforms. There is however a close relationship between the KMA and GMA functions. If the GMA stores all information pertaining to the GLs and the KMA merely generates keys, a corrupted GMA could cause havoc. To protect against a corrupted GMA, the KMA would be forced to double check the requests it receives to ensure that the GMA did not tamper with them. These duplicative checks blur the functionality of the two components together. For this reason, the interactions between the KMA and GMA are beyond the scope of this document.
図1はKMAとGMA機能の両方を取り囲むとしてGLAについて表現しますが、同じ実体で2つの機能をサポートしたかもしれませんか、または2つの異なった実体でそれらをサポートすることができました。 2つの実体が使用されているなら、それらは1か2個のプラットホームに位置するかもしれません。しかしながら、KMAとGMA機能との密接な関係があります。 GMAがGLsに関係するすべての情報を保存して、KMAが単にキーを生成するなら、崩壊したGMAは大破壊を引き起こす場合がありました。 崩壊したGMAから守るなら、GMAがそれらをいじらなかったのを保証するためにはKMAによる強制されて、倍増するのがそれが受け取る要求をチェックするということでしょう。 これらの重複したチェックは2つのコンポーネントの機能性を一緒にぼかします。 この理由で、KMAとGMAとの相互作用はこのドキュメントの範囲を超えています。
Proprietary mechanisms may be used to separate the functions by strengthening the trust relationship between the two entities. Henceforth, the distinction between the two agents is not discussed further; the term GLA will be used to address both functions. It should be noted that a corrupt GLA can always cause havoc.
独占メカニズムは、2つの実体の間の信頼関係を強化することによって機能を切り離すのに使用されるかもしれません。 今後は、さらに2人のエージェントの区別について議論しません。 GLAという用語は、両方の機能を扱うのに使用されるでしょう。 不正なGLAがいつも大破壊を引き起こす場合があることに注意されるべきです。
3. Protocol Interactions
3. プロトコル相互作用
There are existing mechanisms (e.g., listserv and majordomo) to manage GLs; however, this document does not address securing these mechanisms, as they are not standardized. Instead, it defines protocol interactions, as depicted in Figure 2, used by the GL members, GLA, and GLO(s) to manage GLs and distribute shared KEKs. The interactions have been divided into administration messages and distribution messages. The administrative messages are the request and response messages needed to set up the GL, delete the GL, add members to the GL, delete members of the GL, request a group rekey, add owners to the GL, remove owners of the GL, indicate a group key compromise, refresh a group key, interrogate the GLA, and update members' and owners' public key certificates. The distribution
GLsを管理するために、既存のメカニズム(例えば、listservと家令)があります。 しかしながら、それらが標準化されないとき、このドキュメントは、機密保護するのがこれらのメカニズムであると扱いません。 代わりに、プロトコル相互作用を定義します、GLsを管理して、共有されたKEKsを分配するためにGLメンバー(GLA)によって使用された図2とGLO(s)に表現されるように。 相互作用は管理メッセージと分配メッセージに分割されました。 管理メッセージは、要求と、GLをセットアップして、GLを削除して、GLにメンバーを加えて、GLのメンバーを削除して、グループrekeyを要求して、GLに所有者を加えて、GLの所有者を免職して、グループキー感染を示して、グループキーをリフレッシュして、GLAについて査問して、メンバーのものをアップデートするのに必要である応答メッセージと所有者の公開鍵証明書です。 分配
Turner Standards Track [Page 7] RFC 5275 CMS SymKeyDist June 2008
5275cmのターナー標準化過程[7ページ]RFC SymKeyDist2008年6月
messages are the messages that distribute the shared KEKs. The following sections describe the ASN.1 for both the administration and distribution messages. Section 4 describes how to use the administration messages, and Section 5 describes how to use the distribution messages.
メッセージは共有されたKEKsを分配するメッセージです。 以下のセクションは管理と分配メッセージの両方のためにASN.1について説明します。 セクション4は管理メッセージを使用する方法を説明します、そして、セクション5は分配メッセージを使用する方法を説明します。
+-----+ +----------+
| GLO | <---+ +----> | Member 1 |
+-----+ | | +----------+
| |
+-----+ <------+ | +----------+
| GLA | <-------------+----> | ... |
+-----+ | +----------+
|
| +----------+
+----> | Member n |
+----------+
+-----+ +----------+ | GLO| <--+ +---->| メンバー1| +-----+ | | +----------+ | | +-----+ <。------+ | +----------+ | GLA| <、-、-、-、-、-、-、-、-、-、-、-、--+---->| ... | +-----+ | +----------+ | | +----------+ +---->| メンバーn| +----------+
Figure 2 - Protocol Interactions
図2--プロトコル相互作用
3.1. Control Attributes
3.1. コントロール属性
To avoid creating an entirely new protocol, the Certificate Management over CMS (CMC) protocol was chosen as the foundation of this protocol. The main reason for the choice was the layering aspect provided by CMC where one or more control attributes are included in message, protected with CMS, to request or respond to a desired action. The CMC PKIData structure is used for requests, and the CMC PKIResponse structure is used for responses. The content- types PKIData and PKIResponse are then encapsulated in CMS's SignedData or EnvelopedData, or a combination of the two (see Section 3.2). The following are the control attributes defined in this document:
完全に新しいプロトコルを作成するのを避けるために、CMS(CMC)プロトコルの上のCertificate Managementはこのプロトコルの基礎として選ばれました。 選択の主な理由は1つ以上のコントロール属性が必要な動作に要求するか、または応じるためにCMSと共に保護されたメッセージに含まれているCMCによって提供されたレイヤリング局面でした。 CMC PKIData構造は要求に使用されます、そして、CMC PKIResponse構造は応答に使用されます。 PKIResponseは内容がPKIDataをタイプして、次に、CMSのSignedDataかEnvelopedDataでカプセル化されて2つのものの組み合わせです(セクション3.2を見てください)。 ↓これは本書では定義されたコントロール属性です:
Turner Standards Track [Page 8] RFC 5275 CMS SymKeyDist June 2008
5275cmのターナー標準化過程[8ページ]RFC SymKeyDist2008年6月
Control
Attribute OID Syntax
------------------- ----------- -----------------
glUseKEK id-skd 1 GLUseKEK
glDelete id-skd 2 GeneralName
glAddMember id-skd 3 GLAddMember
glDeleteMember id-skd 4 GLDeleteMember
glRekey id-skd 5 GLRekey
glAddOwner id-skd 6 GLOwnerAdministration
glRemoveOwner id-skd 7 GLOwnerAdministration
glkCompromise id-skd 8 GeneralName
glkRefresh id-skd 9 GLKRefresh
glaQueryRequest id-skd 11 GLAQueryRequest
glaQueryResponse id-skd 12 GLAQueryResponse
glProvideCert id-skd 13 GLManageCert
glUpdateCert id-skd 14 GLManageCert
glKey id-skd 15 GLKey
規制属性OID構文------------------- ----------- ----------------- 1GLUseKEK glDeleteのglUseKEKイド-skdイド-skd2GeneralName glAddMemberイド-skd3GLAddMember glDeleteMemberイド-skd4GLDeleteMember glRekeyイド-skd5GLRekey glAddOwnerイド-skd6GLOwnerAdministration glRemoveOwnerイド-skd7GLOwnerAdministration glkCompromiseイド-skd8GeneralName glkRefreshイド-skd9GLKRefresh glaQueryRequestイド-skd11GLAQueryRequest glaQueryResponseイド-skd12GLAQueryResponse glProvideCertイド-skd13GLManageCert glUpdateCertイド-skd14GLManageCert glKeyイド-skd15GLKey
In the following conformance tables, the column headings have the following meanings: O for originate, R for receive, and F for forward. There are three types of implementations: GLOs, GLAs, and GL members. The GLO is an optional component, hence all GLO O and GLO R messages are optional, and GLA F messages are optional. The first table includes messages that conformant implementations MUST support. The second table includes messages that MAY be implemented. The second table should be interpreted as follows: if the control attribute is implemented by a component, then it must be implemented as indicated. For example, if a GLA is implemented that supports the glAddMember control attribute, then it MUST support receiving the glAddMember message. Note that "-" means not applicable.
以下の順応テーブルでは、コラム見出しは以下の意味を持っています: O、R、起因してください、受信してください、そして、フォワードへのF。 3つのタイプの実装があります: GLOs、GLAs、およびGLメンバー。 GLO Rメッセージは任意です、そして、GLOは任意のコンポーネントです、したがって、すべてのGLO O、GLA Fメッセージは任意です。 最初のテーブルはconformant実装がサポートしなければならないメッセージを含んでいます。 第2テーブルは実装されるかもしれないメッセージを含んでいます。 第2テーブルは以下の通り解釈されるべきです: コントロール属性がコンポーネントによって実装されるなら、示されるようにそれを実装しなければなりません。 例えば、glAddMemberコントロール属性をサポートするGLAが実装されるなら、それは、受信がglAddMemberメッセージであるとサポートしなければなりません。 「-」が適切でないことを意味することに注意してください。
Required
Implementation Requirement | Control
GLO | GLA | GL Member | Attribute
O R | O R F | O R |
------- | ----------------- | --------- | ----------
MAY - | MUST - MAY | - MUST | glProvideCert
MAY MAY | - MUST MAY | MUST - | glUpdateCert
- - | MUST - - | - MUST | glKey
必要な実装要件| コントロールGLO| GLA| GLメンバー| O Rを結果と考えてください。| ○ R F| ○ R| ------- | ----------------- | --------- | ---------- -であるかもしれない| 必須--5月| - 必須| glProvideCert5月の5月| - 必須はそうするかもしれません。| -でなければならない| glUpdateCert--、-| 必須--、-| - 必須| glKey
Turner Standards Track [Page 9] RFC 5275 CMS SymKeyDist June 2008
5275cmのターナー標準化過程[9ページ]RFC SymKeyDist2008年6月
Optional
Implementation Requirement | Control
GLO | GLA | GL Member | Attribute
O R | O R F | O R |
------- | ----------------- | --------- | ----------
MAY - | - MAY - | - - | glUseKEK
MAY - | - MAY - | - - | glDelete
MAY MAY | - MUST MAY | MUST - | glAddMember
MAY MAY | - MUST MAY | MUST - | glDeleteMember
MAY - | - MAY - | - - | glRekey
MAY - | - MAY - | - - | glAddOwner
MAY - | - MAY - | - - | glRemoveOwner
MAY MAY | - MUST MAY | MUST - | glkCompromise
MAY - | - MUST - | MUST - | glkRefresh
MAY - | - SHOULD - | MAY - | glaQueryRequest
- MAY | SHOULD - - | - MAY | glaQueryResponse
任意の実装要件| コントロールGLO| GLA| GLメンバー| O Rを結果と考えてください。| ○ R F| ○ R| ------- | ----------------- | --------- | ---------- -であるかもしれない| - -であるかもしれない| - - | glUseKEK5月、-| - -であるかもしれない| - - | glDelete5月の5月| - 必須はそうするかもしれません。| -でなければならない| glAddMember5月の5月| - 必須はそうするかもしれません。| -でなければならない| glDeleteMember5月、-| - -であるかもしれない| - - | glRekey5月、-| - -であるかもしれない| - - | glAddOwner5月、-| - -であるかもしれない| - - | glRemoveOwner5月の5月| - 必須はそうするかもしれません。| -でなければならない| 5月をglkCompromiseする、-| - -でなければならない| -でなければならない| glkRefresh5月、-| - -であるべきです| -であるかもしれない| glaQueryRequest--5月| --、-であるべきです| - 5月| glaQueryResponse
glaQueryResponse is carried in the CMC PKIResponse content-type, all other control attributes are carried in the CMC PKIData content-type. The exception is glUpdateCert, which can be carried in either PKIData or PKIResponse.
glaQueryResponseはCMC PKIResponse content typeで運ばれて、他のすべてのコントロール属性がCMC PKIData content typeで運ばれます。 例外はglUpdateCertです。(PKIDataかPKIResponseのどちらかでそのglUpdateCertを運ぶことができます)。
Success and failure messages use CMC (see Section 3.2.4).
成功と失敗メッセージはCMCを使用します(セクション3.2.4を見てください)。
3.1.1. GL Use KEK
3.1.1. GLはKEKを使用します。
The GLO uses glUseKEK to request that a shared KEK be assigned to a GL. glUseKEK messages MUST be signed by the GLO. The glUseKEK control attribute has the syntax GLUseKEK:
GLOは、共有されたKEKがGLOがメッセージに署名しなければならないGL. glUseKEKに割り当てられるよう要求するのにglUseKEKを使用します。 glUseKEKコントロール属性に、構文GLUseKEKがあります:
GLUseKEK ::= SEQUENCE {
glInfo GLInfo,
glOwnerInfo SEQUENCE SIZE (1..MAX) OF GLOwnerInfo,
glAdministration GLAdministration DEFAULT 1,
glKeyAttributes GLKeyAttributes OPTIONAL }
GLUseKEK:、:= 系列glInfo GLInfo、glAdministration GLAdministrationデフォルト1の、そして、glKeyAttributes GLKeyAttributes任意のGLOwnerInfoのglOwnerInfo系列サイズ(1..MAX)
GLInfo ::= SEQUENCE {
glName GeneralName,
glAddress GeneralName }
GLInfo:、:= 系列glName GeneralName、glAddress GeneralName
GLOwnerInfo ::= SEQUENCE {
glOwnerName GeneralName,
glOwnerAddress GeneralName,
certificate Certificates OPTIONAL }
GLOwnerInfo:、:= 系列glOwnerName GeneralName(glOwnerAddress GeneralName)はCertificates OPTIONALを証明します。
Turner Standards Track [Page 10] RFC 5275 CMS SymKeyDist June 2008
5275cmのターナー標準化過程[10ページ]RFC SymKeyDist2008年6月
Certificates ::= SEQUENCE {
pKC [0] Certificate OPTIONAL,
-- See [PROFILE]
aC [1] SEQUENCE SIZE (1.. MAX) OF
AttributeCertificate OPTIONAL,
-- See [ACPROF]
certPath [2] CertificateSet OPTIONAL }
-- From [CMS]
証明書:、:= 系列、pKC[0]証明書任意である、--、AttributeCertificateの[プロフィール]aC[1]系列サイズ(1つの最大)が任意であることを見てください--[ACPROF]certPath[2]CertificateSetが任意であることを見てください--[cm]
-- CertificateSet and CertificateChoices are included only -- for illustrative purposes as they are imported from [CMS].
-- それらが説明に役立った目的のための含まれていたCertificateSetとCertificateChoices専用である、[CMS]から、インポートされます。
CertificateSet ::= SET SIZE (1..MAX) OF CertificateChoices
CertificateSet:、:= CertificateChoicesのサイズ(1..MAX)を設定してください。
-- CertificateChoices supports X.509 public key certificates in -- certificates and v2 attribute certificates in v2AttrCert.
-- CertificateChoicesは中で公開鍵証明書をX.509に支えます--v2AttrCertの証明書とv2属性証明書。
GLAdministration ::= INTEGER {
unmanaged (0),
managed (1),
closed (2) }
GLAdministration:、:= 整数(0)を非管理して、(1)、閉じた(2)を管理します。
GLKeyAttributes ::= SEQUENCE {
rekeyControlledByGLO [0] BOOLEAN DEFAULT FALSE,
recipientsNotMutuallyAware [1] BOOLEAN DEFAULT TRUE,
duration [2] INTEGER DEFAULT 0,
generationCounter [3] INTEGER DEFAULT 2,
requestedAlgorithm [4] AlgorithmIdentifier
DEFAULT { id-aes128-wrap } }
GLKeyAttributes:、:= 系列rekeyControlledByGLO[0]BOOLEAN DEFAULT FALSE、recipientsNotMutuallyAware[1]BOOLEAN DEFAULT TRUE、持続時間[2]INTEGER DEFAULT0、generationCounter[3]INTEGER DEFAULT2、requestedAlgorithm[4]AlgorithmIdentifier DEFAULTイドaes128包装
The fields in GLUseKEK have the following meaning:
GLUseKEKの分野には、以下の意味があります:
- glInfo indicates the name of the GL in glName and the address of
the GL in glAddress. The glName and glAddress can be the same,
but this is not always the case. Both the name and address MUST
be unique for a given GLA.
- glInfoはGLというglNameの名前とglAddressのGLのアドレスを示します。 glNameとglAddressは同じである場合がありますが、これはいつもそうであるというわけではありません。 与えられたGLAに、名前とアドレスの両方がユニークであるに違いありません。
- glOwnerInfo indicates:
- glOwnerInfoは以下を示します。
-- glOwnerName indicates the name of the owner of the GL. One
of the names in glOwnerName MUST match one of the names in
the certificate (either the subject distinguished name or one
of the subject alternative names) used to sign this
SignedData.PKIData creating the GL (i.e., the immediate
signer).
-- glOwnerNameはGLの所有者の名前を示します。 GL(すなわち、即座の署名者)を作成して、glOwnerNameの名前の1つは(対象の分類名か対象の代替名の1つのどちらか)がこのSignedData.PKIDataにサインするのに使用した証明書の名前の1つに合わなければなりません。
-- glOwnerAddress indicates the GL owner's address.
-- glOwnerAddressはGL所有者のアドレスを示します。
Turner Standards Track [Page 11] RFC 5275 CMS SymKeyDist June 2008
5275cmのターナー標準化過程[11ページ]RFC SymKeyDist2008年6月
-- certificates MAY be included. It contains the following
three fields:
-- 証明書は含まれるかもしれません。 それは以下の3つの分野を含んでいます:
--- certificates.pKC includes the encryption certificate for
the GLO. It will be used to encrypt responses for the
GLO.
--- certificates.pKCはGLOのための暗号化証明書を含んでいます。 それは、GLOのために応答をコード化するのに使用されるでしょう。
--- certificates.aC MAY be included to convey any attribute
certificate (see [ACPROF]) associated with the
encryption certificate of the GLO included in
certificates.pKC.
--- certificates.aCは、certificates.pKCに含まれているGLOの暗号化証明書に関連しているどんな属性証明書([ACPROF]を見る)も伝えるために含まれるかもしれません。
--- certificates.certPath MAY also be included to convey
certificates that might aid the recipient in
constructing valid certification paths for the
certificate provided in certificates.pKC and the
attribute certificates provided in certificates.aC.
Theses certificates are optional because they might
already be included elsewhere in the message (e.g., in
the outer CMS layer).
--- また、certificates.certPathは、certificates.pKCに提供された証明書とcertificates.aCに提供された属性証明書のために有効な証明経路を構成する際に受取人を支援するかもしれない証明書を伝えるために含まれるかもしれません。 それらがメッセージ(例えば、外側のCMS層の)のほかの場所に既に含まれるかもしれないので、論文証明書は任意です。
-- glAdministration indicates how the GL ought to be
administered. The default is for the list to be managed.
Three values are supported for glAdministration:
-- glAdministrationはGLがどう管理されるべきであるかを示します。 デフォルトはリストが管理されることです。 3つの値がglAdministrationのために支持されます:
--- Unmanaged - When the GLO sets glAdministration to
unmanaged, it is allowing prospective members to request
addition and deletion from the GL without GLO
intervention.
--- GLOが非管理されるのにglAdministrationを設定するとき、Unmanagedされて、将来のメンバーはそれからGLからGLO介入なしで添加と削除を要求できます。
--- Managed - When the GLO sets glAdministration to managed,
it is allowing prospective members to request addition
and deletion from the GL, but the request is redirected
by the GLA to GLO for review. The GLO makes the
determination as to whether to honor the request.
--- GLOが管理されるのにglAdministrationを設定しますが、将来のメンバーがそれからGLから添加と削除を要求できますが、要求がレビューのためにGLAによってGLOに向け直されるとき、管理されます。 GLOは要求を光栄に思うかどうかに関して決定を下します。
--- Closed - When the GLO sets glAdministration to closed,
it is not allowing prospective members to request
addition or deletion from the GL. The GLA will only
accept glAddMember and glDeleteMember requests from the
GLO.
--- GLOが閉じられるのにglAdministrationを設定するとき、閉じられて、将来のメンバーはそれからGLから添加か削除を要求できません。 GLAはGLOからglAddMemberとglDeleteMember要求を受け入れるだけでしょう。
-- glKeyAttributes indicates the attributes the GLO wants the
GLA to assign to the shared KEK. If this field is omitted,
GL rekeys will be controlled by the GLA, the recipients are
allowed to know about one another, the algorithm will be
AES-128 (see Section 7), the shared KEK will be valid for a
calendar month (i.e., first of the month until the last day
-- glKeyAttributesはGLAが割り当てるGLOが共有されたKEKに欲しい属性を示します。 アルゴリズムがAES-128(セクション7を見る)である、受取人が、お互いに関してこの分野が省略されると、GL rekeysがGLAによって制御されるのを知ることができて、共有されたKEKが暦月の間、有効になる、(すなわち、最後の日までの月の1日
Turner Standards Track [Page 12] RFC 5275 CMS SymKeyDist June 2008
5275cmのターナー標準化過程[12ページ]RFC SymKeyDist2008年6月
of the month), and two shared KEKs will be distributed
initially. The fields in glKeyAttributes have the following
meaning:
月)、そして、初めは分配されていて、共有されたKEKsが望んでいる2。 glKeyAttributesの分野には、以下の意味があります:
--- rekeyControlledByGLO indicates whether the GL rekey
messages will be generated by the GLO or by the GLA.
The default is for the GLA to control rekeys. If GL
rekey is controlled by the GLA, the GL will continue to
be rekeyed until the GLO deletes the GL or changes the
GL rekey to be GLO controlled.
--- rekeyControlledByGLOは、GL rekeyメッセージがGLOかGLAによって発生するかどうかを示します。 デフォルトはGLAが「再-キー」を制御することです。 GL rekeyがGLAによって制御されるなら、GLは、GLOがGLを削除するまで「再-合わせ」られ続けるか、または制御されたGLOになるようにGL rekeyを変えます。
--- recipientsNotMutuallyAware indicates that the GLO wants
the GLA to distribute the shared KEK individually for
each of the GL members (i.e., a separate glKey message
is sent to each recipient). The default is for separate
glKey message not to be required.
--- recipientsNotMutuallyAwareは、GLOが、GLAにGLメンバー各人のために個別に共有されたKEKを分配して欲しいのを示します(すなわち、別々のglKeyメッセージを各受取人に送ります)。 デフォルトは必要であるべきでない別々のglKeyメッセージのためのものです。
Note: This supports lists where one member does not know
the identities of the other members. For example, a
list is configured granting submit permissions to only
one member. All other members are 'listening'. The
security policy of the list does not allow the members
to know who else is on the list. If a glKey is
constructed for all of the GL members, information about
each of the members may be derived from the information
in RecipientInfos.
以下に注意してください。 これは1人のメンバーが他のメンバーのアイデンティティを知らないリストを支持します。 例えば、リストは構成された与えるのが1人のメンバーだけに許容を提出するということです。 他のすべてのメンバーが'聴いています'。 リストの安全保障政策で、メンバーは、他のだれがリストにいるかを知ることができません。 GLメンバーのすべてのためにglKeyを組み立てるなら、RecipientInfosの情報からおよそそれぞれメンバーの情報を得るかもしれません。
To make sure the glkey message does not divulge
information about the other recipients, a separate glKey
message would be sent to each GL member.
念のためglkeyメッセージは他の受取人の情報を明かさないで、別々のglKeyメッセージをそれぞれのGLメンバーに送るでしょう。
--- duration indicates the length of time (in days) during
which the shared KEK is considered valid. The value
zero (0) indicates that the shared KEK is valid for a
calendar month in the UTC Zulu time zone. For example,
if the duration is zero (0), if the GL shared KEK is
requested on July 24, the first key will be valid until
the end of July and the next key will be valid for the
entire month of August. If the value is not zero (0),
the shared KEK will be valid for the number of days
indicated by the value. For example, if the value of
duration is seven (7) and the shared KEK is requested on
Monday but not generated until Tuesday (13 May 2008);
the shared KEKs will be valid from Tuesday (13 May 2008)
to Tuesday (20 May 2008). The exact time of the day is
determined when the key is generated.
--- 持続時間は共有されたKEKが有効であると考えられる時間(何日もの)の長さを示します。 値ゼロの(0)は、暦月の間、共有されたKEKがUTCのズールー族の時間帯で有効であることを示します。 例えば、KEKはGLが共有して、持続時間が(0)でないなら、7月24日に要求されて、7月の終わりと次のキーが有効になるまで、最初のキーは8月の全体の月に有効になるでしょう。 値が(0)であるなら、共有されたKEKは値によって示された何日もの数に有効になるでしょう。 例えば、持続時間の値が7(7)と共有であったなら、KEKは月曜日に要求されますが、火曜日(2008年5月13日)まで発生しません。 共有されたKEKsは火曜日(2008年5月13日)から火曜日(2008年5月20日)まで有効になるでしょう。 キーが発生するとき、1日の正確な時間は決定しています。
Turner Standards Track [Page 13] RFC 5275 CMS SymKeyDist June 2008
5275cmのターナー標準化過程[13ページ]RFC SymKeyDist2008年6月
--- generationCounter indicates the number of keys the GLO
wants the GLA to distribute. To ensure uninterrupted
function of the GL, two (2) shared KEKs at a minimum
MUST be initially distributed. The second shared KEK is
distributed with the first shared KEK, so that when the
first shared KEK is no longer valid the second key can
be used. If the GLA controls rekey, then it also
indicates the number of shared KEKs the GLO wants
outstanding at any one time. See Sections 4.5 and 5 for
more on rekey.
--- generationCounterはGLOが、GLAに分配して欲しいキーの数を示します。 (2) GL、2のとぎれない機能を確実にするために、初めは、最小限における共有されたKEKsを分配しなければなりません。 第2共有されたKEKは最初の共有されたKEKと共に分配されます、最初の共有されたKEKがもう有効でないときに、2番目のキーを使用できるように。 また、GLAがrekeyを制御するなら、それはいかなる時も、傑出していた状態でGLOが欲しい共有されたKEKsの数を示します。 詳しい情報については、rekeyでセクション4.5と5を見てください。
--- requestedAlgorithm indicates the algorithm and any
parameters the GLO wants the GLA to use with the shared
KEK. The parameters are conveyed via the
SMIMECapabilities attribute (see [MSG]). See Section 6
for more on algorithms.
--- requestedAlgorithmはアルゴリズムとGLOが、GLAに共有されたKEKと共に使用して欲しいどんなパラメタも示します。 パラメタはSMIMECapabilities属性で伝えられます([MSG]を見てください)。 詳しい情報については、アルゴリズムでセクション6を見てください。
3.1.2. Delete GL
3.1.2. GLを削除してください。
GLOs use glDelete to request that a GL be deleted from the GLA. The glDelete control attribute has the syntax GeneralName. The glDelete message MUST be signed by the GLO. The name of the GL to be deleted is included in GeneralName:
GLOsは、GLがGLAから削除されるよう要求するのにglDeleteを使用します。 glDeleteコントロール属性に、構文GeneralNameがあります。 GLOはglDeleteメッセージにサインしなければなりません。 削除されるべきGLという名前はGeneralNameに含まれています:
DeleteGL ::= GeneralName
DeleteGL:、:= GeneralName
3.1.3. Add GL Member
3.1.3. GLメンバーを加えてください。
GLOs use the glAddMember to request addition of new members, and prospective GL members use the glAddMember to request their own addition to the GL. The glAddMember message MUST be signed by either the GLO or the prospective GL member. The glAddMember control attribute has the syntax GLAddMember:
GLOsは新しいメンバーの追加を要求するのにglAddMemberを使用します、そして、将来のGLメンバーはGLへのそれら自身の添加を要求するのにglAddMemberを使用します。 GLOか将来のGLメンバーのどちらかがglAddMemberメッセージにサインしなければなりません。 glAddMemberコントロール属性に、構文GLAddMemberがあります:
GLAddMember ::= SEQUENCE {
glName GeneralName,
glMember GLMember }
GLAddMember:、:= 系列glName GeneralName、glMember GLMember
GLMember ::= SEQUENCE {
glMemberName GeneralName,
glMemberAddress GeneralName OPTIONAL,
certificates Certificates OPTIONAL }
GLMember:、:= 系列glMemberName GeneralName、glMemberAddress GeneralName OPTIONAL、証明書Certificates OPTIONAL
The fields in GLAddMembers have the following meaning:
GLAddMembersの分野には、以下の意味があります:
- glName indicates the name of the GL to which the member should be
added.
- glNameはメンバーが加えられるべきであるGLという名前を示します。
Turner Standards Track [Page 14] RFC 5275 CMS SymKeyDist June 2008
5275cmのターナー標準化過程[14ページ]RFC SymKeyDist2008年6月
- glMember indicates the particulars for the GL member. Both of
the following fields must be unique for a given GL:
- glMemberはGLメンバーのために子細を示します。 与えられたGLに、以下の分野の両方がユニークであるに違いありません:
-- glMemberName indicates the name of the GL member.
-- glMemberNameはGLメンバーの名前を示します。
-- glMemberAddress indicates the GL member's address. It MUST
be included.
-- glMemberAddressはGLメンバーのアドレスを示します。 それを含まなければなりません。
Note: In some instances, the glMemberName and glMemberAddress
may be the same, but this is not always the case.
以下に注意してください。 ある場合に、glMemberNameとglMemberAddressは同じであるかもしれませんが、これはいつもそうであるというわけではありません。
-- certificates MUST be included. It contains the following
three fields:
-- 証明書を含まなければなりません。 それは以下の3つの分野を含んでいます:
--- certificates.pKC includes the member's encryption
certificate. It will be used, at least initially, to
encrypt the shared KEK for that member. If the message
is generated by a prospective GL member, the pKC MUST be
included. If the message is generated by a GLO, the pKC
SHOULD be included.
--- certificates.pKCはメンバーの暗号化証明書を含んでいます。 それは、少なくとも初めは、そのメンバーのために共有されたKEKをコード化するのに使用されるでしょう。 メッセージが将来のGLメンバーによって発生するなら、pKCを含まなければなりません。 メッセージはGLO、pKC SHOULDによって発生します。含まれています。
--- certificates.aC MAY be included to convey any attribute
certificate (see [ACPROF]) associated with the member's
encryption certificate.
--- certificates.aCは、メンバーの暗号化証明書に関連しているどんな属性証明書([ACPROF]を見る)も伝えるために含まれるかもしれません。
--- certificates.certPath MAY also be included to convey
certificates that might aid the recipient in
constructing valid certification paths for the
certificate provided in certificates.pKC and the
attribute certificates provided in certificates.aC.
These certificates are optional because they might
already be included elsewhere in the message (e.g., in
the outer CMS layer).
--- また、certificates.certPathは、certificates.pKCに提供された証明書とcertificates.aCに提供された属性証明書のために有効な証明経路を構成する際に受取人を支援するかもしれない証明書を伝えるために含まれるかもしれません。 それらがメッセージ(例えば、外側のCMS層の)のほかの場所に既に含まれるかもしれないので、これらの証明書は任意です。
3.1.4. Delete GL Member
3.1.4. GLメンバーを削除してください。
GLOs use the glDeleteMember to request deletion of GL members, and GL members use the glDeleteMember to request their own removal from the GL. The glDeleteMember message MUST be signed by either the GLO or the GL member. The glDeleteMember control attribute has the syntax GLDeleteMember:
GLOsはGLメンバーの削除を要求するのにglDeleteMemberを使用します、そして、GLメンバーはGLからそれら自身の取り外しを要求するのにglDeleteMemberを使用します。 GLOかGLメンバーのどちらかがglDeleteMemberメッセージにサインしなければなりません。 glDeleteMemberコントロール属性に、構文GLDeleteMemberがあります:
GLDeleteMember ::= SEQUENCE {
glName GeneralName,
glMemberToDelete GeneralName }
GLDeleteMember:、:= 系列glName GeneralName、glMemberToDelete GeneralName
Turner Standards Track [Page 15] RFC 5275 CMS SymKeyDist June 2008
5275cmのターナー標準化過程[15ページ]RFC SymKeyDist2008年6月
The fields in GLDeleteMembers have the following meaning:
GLDeleteMembersの分野には、以下の意味があります:
- glName indicates the name of the GL from which the member should
be removed.
- glNameはメンバーが免職されるべきであるGLという名前を示します。
- glMemberToDelete indicates the name or address of the member to
be deleted.
- glMemberToDeleteは、削除されるためにメンバーの名前かアドレスを示します。
3.1.5. Rekey GL
3.1.5. Rekey GL
GLOs use the glRekey to request a GL rekey. The glRekey message MUST be signed by the GLO. The glRekey control attribute has the syntax GLRekey:
GLOsは、GL rekeyを要求するのにglRekeyを使用します。 GLOはglRekeyメッセージにサインしなければなりません。 glRekeyコントロール属性に、構文GLRekeyがあります:
GLRekey ::= SEQUENCE {
glName GeneralName,
glAdministration GLAdministration OPTIONAL,
glNewKeyAttributes GLNewKeyAttributes OPTIONAL,
glRekeyAllGLKeys BOOLEAN OPTIONAL }
GLRekey:、:= 系列glAdministration GLAdministration任意の、そして、任意のglNewKeyAttributes GLNewKeyAttributes glRekeyAllGLKeys論理演算子任意のglName GeneralName
GLNewKeyAttributes ::= SEQUENCE {
rekeyControlledByGLO [0] BOOLEAN OPTIONAL,
recipientsNotMutuallyAware [1] BOOLEAN OPTIONAL,
duration [2] INTEGER OPTIONAL,
generationCounter [3] INTEGER OPTIONAL,
requestedAlgorithm [4] AlgorithmIdentifier OPTIONAL }
GLNewKeyAttributes:、:= 系列rekeyControlledByGLO[0]BOOLEAN OPTIONAL、recipientsNotMutuallyAware[1]BOOLEAN OPTIONAL、持続時間[2]INTEGER OPTIONAL、generationCounter[3]INTEGER OPTIONAL、requestedAlgorithm[4]AlgorithmIdentifier OPTIONAL
The fields in GLRekey have the following meaning:
GLRekeyの分野には、以下の意味があります:
- glName indicates the name of the GL to be rekeyed.
- glNameは、「再-合わせ」られるために、GLという名前を示します。
- glAdministration indicates if there is any change to how the GL
should be administered. See Section 3.1.1 for the three options.
This field is only included if there is a change from the
previously registered glAdministration.
- glAdministrationは、何かGLがどう管理されるべきであるかへの変化があるかどうかを示します。 3つのオプションに関してセクション3.1.1を見てください。 以前に登録されたglAdministrationからの変化がある場合にだけ、この分野は含まれています。
- glNewKeyAttributes indicates whether the rekey of the GLO is
controlled by the GLA or GL, what algorithm and parameters the
GLO wishes to use, the duration of the key, and how many keys
will be issued. The field is only included if there is a change
from the previously registered glKeyAttributes.
- glNewKeyAttributesは、GLOのrekeyがGLAかGLによって制御されるかどうかと、GLOがどんなアルゴリズムとパラメタを使用したがっているか、そして、キーの継続といくつのキーが支給されるかを示します。 以前に登録されたglKeyAttributesからの変化がある場合にだけ、分野は含まれています。
- glRekeyAllGLKeys indicates whether the GLO wants all of the
outstanding GL's shared KEKs rekeyed. If it is set to TRUE then
all outstanding KEKs MUST be issued. If it is set to FALSE then
all outstanding KEKs need not be reissued.
- glRekeyAllGLKeysは、GLOが傑出しているGLの共有されたKEKs rekeyedのすべてが欲しいかどうかを示します。 それがTRUEに設定されるなら、すべての傑出しているKEKsを発行しなければなりません。 それがFALSEに設定されるなら、すべての傑出しているKEKsが再発行されなければならないというわけではありません。
Turner Standards Track [Page 16] RFC 5275 CMS SymKeyDist June 2008
5275cmのターナー標準化過程[16ページ]RFC SymKeyDist2008年6月
3.1.6. Add GL Owner
3.1.6. GL所有者を加えてください。
GLOs use the glAddOwner to request that a new GLO be allowed to administer the GL. The glAddOwner message MUST be signed by a registered GLO. The glAddOwner control attribute has the syntax GLOwnerAdministration:
GLOsは、新しいGLOがGLを管理できるよう要求するのにglAddOwnerを使用します。 登録されたGLOはglAddOwnerメッセージにサインしなければなりません。 glAddOwnerコントロール属性に、構文GLOwnerAdministrationがあります:
GLOwnerAdministration ::= SEQUENCE {
glName GeneralName,
glOwnerInfo GLOwnerInfo }
GLOwnerAdministration:、:= 系列glName GeneralName、glOwnerInfo GLOwnerInfo
The fields in GLAddOwners have the following meaning:
GLAddOwnersの分野には、以下の意味があります:
- glName indicates the name of the GL to which the new GLO should
be associated.
- glNameは新しいGLOが関連しているべきであるGLという名前を示します。
- glOwnerInfo indicates the name, address, and certificates of the
new GLO. As this message includes names of new GLOs, the
certificates.pKC MUST be included, and it MUST include the
encryption certificate of the new GLO.
- glOwnerInfoは新しいGLOの名前、アドレス、および証明書を示します。 このメッセージが新しいGLOsという名前を含んでいて、certificates.pKCを含まなければならなくて、新しいGLOの暗号化証明書を含まなければならないとき。
3.1.7. Remove GL Owner
3.1.7. GL所有者を免職してください。
GLOs use the glRemoveOwner to request that a GLO be disassociated with the GL. The glRemoveOwner message MUST be signed by a registered GLO. The glRemoveOwner control attribute has the syntax GLOwnerAdministration:
GLOsは、GLOがGLと共に分離されるよう要求するのにglRemoveOwnerを使用します。 登録されたGLOはglRemoveOwnerメッセージにサインしなければなりません。 glRemoveOwnerコントロール属性に、構文GLOwnerAdministrationがあります:
GLOwnerAdministration ::= SEQUENCE {
glName GeneralName,
glOwnerInfo GLOwnerInfo }
GLOwnerAdministration:、:= 系列glName GeneralName、glOwnerInfo GLOwnerInfo
The fields in GLRemoveOwners have the following meaning:
GLRemoveOwnersの分野には、以下の意味があります:
- glName indicates the name of the GL to which the GLO should be
disassociated.
- glNameはGLOが分離されるべきであるGLという名前を示します。
- glOwnerInfo indicates the name and address of the GLO to be
removed. The certificates field SHOULD be omitted, as it will be
ignored.
- glOwnerInfoは、取り除くためにGLOの名前とアドレスを示します。 証明書分野SHOULDが省略されて、無視するように無視されてください。
3.1.8. GL Key Compromise
3.1.8. GLの主要な妥協
GL members and GLOs use glkCompromise to indicate that the shared KEK possessed has been compromised. The glKeyCompromise control attribute has the syntax GeneralName. This message is always redirected by the GLA to the GLO for further action. The glkCompromise MAY be included in an EnvelopedData generated with the
GLメンバーとGLOsは、所有されていた共有されたKEKが妥協したのを示すのにglkCompromiseを使用します。 glKeyCompromiseコントロール属性に、構文GeneralNameがあります。 このメッセージはさらなる動作のためにいつもGLAによってGLOに向け直されます。 glkCompromiseはEnvelopedDataに発生していた状態で含まれるかもしれません。
Turner Standards Track [Page 17] RFC 5275 CMS SymKeyDist June 2008
5275cmのターナー標準化過程[17ページ]RFC SymKeyDist2008年6月
compromised shared KEK. The name of the GL to which the compromised key is associated is placed in GeneralName:
共有されたKEKで妥協しました。 妥協しているキーが関連しているGLという名前はGeneralNameに置かれます:
GLKCompromise ::= GeneralName
GLKCompromise:、:= GeneralName
3.1.9. GL Key Refresh
3.1.9. GLキーはリフレッシュします。
GL members use the glkRefresh to request that the shared KEK be redistributed to them. The glkRefresh control attribute has the syntax GLKRefresh.
GLメンバーは、共有されたKEKが彼らに再配付されるよう要求するのにglkRefreshを使用します。 glkRefreshコントロール属性に、構文GLKRefreshがあります。
GLKRefresh ::= SEQUENCE {
glName GeneralName,
dates SEQUENCE SIZE (1..MAX) OF Date }
GLKRefresh:、:= 系列glName GeneralName、日付SEQUENCE SIZE(1..MAX)OF Date
Date ::= SEQUENCE {
start GeneralizedTime,
end GeneralizedTime OPTIONAL }
以下とデートしてください:= 系列GeneralizedTime、終わりのGeneralizedTime OPTIONALを始動してください。
The fields in GLKRefresh have the following meaning:
GLKRefreshの分野には、以下の意味があります:
- glName indicates the name of the GL for which the GL member wants
shared KEKs.
- glNameはGLメンバーが共有されたKEKsが欲しいGLという名前を示します。
- dates indicates a date range for keys the GL member wants. The
start field indicates the first date the GL member wants and the
end field indicates the last date. The end date MAY be omitted
to indicate the GL member wants all keys from the specified start
date to the current date. Note that a procedural mechanism is
needed to restrict users from accessing messages that they are
not allowed to access.
- 日付はGLメンバーが欲しいキーのために日付の範囲を示します。 スタート分野はGLメンバーが欲しい初デートを示します、そして、端の分野は終日を示します。 終了日は、GLメンバーがすべての指定されたスタート日から現在の期日までのキーが欲しいのを示すために省略されるかもしれません。 手続き上のメカニズムがそれらが許容されていないというメッセージにアクセスするのからのアクセサリーへのユーザを制限するのに必要であることに注意してください。
3.1.10. GLA Query Request and Response
3.1.10. GLAは要求と応答について質問します。
There are situations where GLOs and GL members may need to determine some information from the GLA about the GL. GLOs and GL members use the glaQueryRequest, defined in Section 3.1.10.1, to request information and GLAs use the glaQueryResponse, defined in Section 3.1.10.2, to return the requested information. Section 3.1.10.3 includes one request and response type and value; others may be defined in additional documents.
状況がGLOsとGLメンバーがGLに関してGLAからの何らかの情報を決定する必要があるかもしれないところにあります。 GLOsとGLメンバーはglaQueryRequestを使用して、セクション3.1.10で定義されて、.1は、求められた情報を返すためにセクション3.1.10で情報とGLAsがglaQueryResponseを使用するという要求と.2を定義しました。 セクション3.1 .10 .3 1つの要求、応答タイプ、および値を含んでいます。 他のものは追加ドキュメントで定義されるかもしれません。
3.1.10.1. GLA Query Request
3.1.10.1. GLA質問要求
GLOs and GL members use the glaQueryRequest to ascertain information about the GLA. The glaQueryRequest control attribute has the syntax GLAQueryRequest:
GLOsとGLメンバーは、GLAの情報を確かめるのにglaQueryRequestを使用します。 glaQueryRequestコントロール属性に、構文GLAQueryRequestがあります:
Turner Standards Track [Page 18] RFC 5275 CMS SymKeyDist June 2008
5275cmのターナー標準化過程[18ページ]RFC SymKeyDist2008年6月
GLAQueryRequest ::= SEQUENCE {
glaRequestType OBJECT IDENTIFIER,
glaRequestValue ANY DEFINED BY glaRequestType }
GLAQueryRequest:、:= 系列glaRequestType物の識別子、glaRequestTypeによって少しも定義されたglaRequestValue
3.1.10.2. GLA Query Response
3.1.10.2. GLA質問応答
GLAs return the glaQueryResponse after receiving a GLAQueryRequest. The glaQueryResponse MUST be signed by a GLA. The glaQueryResponse control attribute has the syntax GLAQueryResponse:
GLAQueryRequestを受けた後に、GLAsはglaQueryResponseを返します。 GLAはglaQueryResponseにサインしなければなりません。 glaQueryResponseコントロール属性に、構文GLAQueryResponseがあります:
GLAQueryResponse ::= SEQUENCE {
glaResponseType OBJECT IDENTIFIER,
glaResponseValue ANY DEFINED BY glaResponseType }
GLAQueryResponse:、:= 系列glaResponseType物の識別子、glaResponseTypeによって少しも定義されたglaResponseValue
3.1.10.3. Request and Response Types
3.1.10.3. 要求と応答タイプ
Requests and responses are registered as a pair under the following object identifier arc:
要求と応答は以下の物の識別子アークの下で対にし登録されます:
id-cmc-glaRR OBJECT IDENTIFIER ::= { id-cmc 99 }
イド-cmc-glaRR物の識別子:、:= イド-cmc99
This document defines one request/response pair for GL members and GLOs to query the GLA for the list of algorithm it supports. The following Object Identifier (OID) is included in the glaQueryType field:
GLメンバーとGLOsがそれが支持するアルゴリズムのリストのためにGLAについて質問するように、このドキュメントは1要求/応答組を定義します。 以下のObject Identifier(OID)はglaQueryType分野に含まれています:
id-cmc-gla-skdAlgRequest OBJECT IDENTIFIER ::={ id-cmc-glaRR 1 }
イド-cmc-gla-skdAlgRequest物の識別子:、:=イド-cmc-glaRR1
SKDAlgRequest ::= NULL
SKDAlgRequest:、:= ヌル
If the GLA supports GLAQueryRequest and GLAQueryResponse messages, the GLA may return the following OID in the glaQueryType field:
GLAがGLAQueryRequestとGLAQueryResponseメッセージを支持するなら、GLAはglaQueryType分野で以下のOIDを返すかもしれません:
id-cmc-gla-skdAlgResponse OBJECT IDENTIFIER ::= { id-cmc-glaRR 2 }
イド-cmc-gla-skdAlgResponse物の識別子:、:= イド-cmc-glaRR2
The glaQueryValue has the form of the smimeCapabilities attributes as defined in [MSG].
glaQueryValueには、smimeCapabilities属性のフォームが[MSG]で定義されるようにあります。
3.1.11. Provide Cert
3.1.11. 本命を提供してください。
GLAs and GLOs use the glProvideCert to request that a GL member provide an updated or new encryption certificate. The glProvideCert message MUST be signed by either GLA or GLO. If the GL member's PKC has been revoked, the GLO or GLA MUST NOT use it to generate the EnvelopedData that encapsulates the glProvideCert request. The glProvideCert control attribute has the syntax GLManageCert:
GLAsとGLOsは、GLメンバーがアップデートされたか新しい暗号化証明書を提供するよう要求するのにglProvideCertを使用します。 GLAかGLOのどちらかがglProvideCertメッセージにサインしなければなりません。 GLメンバーのPKCが取り消されたなら、GLOかGLA MUST NOTが、glProvideCert要求を要約するEnvelopedDataを発生させるのにそれを使用します。 glProvideCertコントロール属性に、構文GLManageCertがあります:
Turner Standards Track [Page 19] RFC 5275 CMS SymKeyDist June 2008
5275cmのターナー標準化過程[19ページ]RFC SymKeyDist2008年6月
GLManageCert ::= SEQUENCE {
glName GeneralName,
glMember GLMember }
GLManageCert:、:= 系列glName GeneralName、glMember GLMember
The fields in GLManageCert have the following meaning:
GLManageCertの分野には、以下の意味があります:
- glName indicates the name of the GL to which the GL member's new
certificate is to be associated.
- glNameは関連しているGLメンバーの新しい証明書がことであるGLという名前を示します。
- glMember indicates particulars for the GL member:
- glMemberはGLメンバーのために子細を示します:
-- glMemberName indicates the GL member's name.
-- glMemberNameはGLメンバーの名前を示します。
-- glMemberAddress indicates the GL member's address. It MAY be
omitted.
-- glMemberAddressはGLメンバーのアドレスを示します。 それは省略されるかもしれません。
-- certificates SHOULD be omitted.
-- 証明書SHOULD、省略されてください。
3.1.12 Update Cert
3.1.12 アップデート本命
GL members and GLOs use the glUpdateCert to provide a new certificate for the GL. GL members can generate an unsolicited glUpdateCert or generate a response glUpdateCert as a result of receiving a glProvideCert message. GL members MUST sign the glUpdateCert. If the GL member's encryption certificate has been revoked, the GL member MUST NOT use it to generate the EnvelopedData that encapsulates the glUpdateCert request or response. The glUpdateCert control attribute has the syntax GLManageCert:
GLメンバーとGLOsは、GLのための新しい証明書を提供するのにglUpdateCertを使用します。 glProvideCertメッセージを受け取ることの結果、GLメンバーは、求められていないglUpdateCertを発生させるか、または応答glUpdateCertを発生させることができます。 GLメンバーはglUpdateCertにサインしなければなりません。 GLメンバーの暗号化証明書が取り消されたなら、GLメンバーは、glUpdateCert要求か応答を要約するEnvelopedDataを発生させるのにそれを使用してはいけません。 glUpdateCertコントロール属性に、構文GLManageCertがあります:
GLManageCert ::= SEQUENCE {
glName GeneralName,
glMember GLMember }
GLManageCert:、:= 系列glName GeneralName、glMember GLMember
The fields in GLManageCert have the following meaning:
GLManageCertの分野には、以下の意味があります:
- glName indicates the name of the GL to which the GL member's new
certificate should be associated.
- glNameはGLメンバーの新しい証明書が関連しているべきであるGLという名前を示します。
- glMember indicates the particulars for the GL member:
- glMemberはGLメンバーのために子細を示します:
-- glMemberName indicates the GL member's name.
-- glMemberNameはGLメンバーの名前を示します。
-- glMemberAddress indicates the GL member's address. It MAY be
omitted.
-- glMemberAddressはGLメンバーのアドレスを示します。 それは省略されるかもしれません。
-- certificates MAY be omitted if the GLManageCert message is
sent to request the GL member's certificate; otherwise, it
MUST be included. It includes the following three fields:
-- GLメンバーの証明書を要求するためにGLManageCertメッセージを送るなら、証明書を省略するかもしれません。 さもなければ、それを含まなければなりません。 それは以下の3つの分野を含んでいます:
Turner Standards Track [Page 20] RFC 5275 CMS SymKeyDist June 2008
5275cmのターナー標準化過程[20ページ]RFC SymKeyDist2008年6月
--- certificates.pKC includes the member's encryption
certificate that will be used to encrypt the shared KEK
for that member.
--- certificates.pKCはそのメンバーのために共有されたKEKをコード化するのに使用されるメンバーの暗号化証明書を含んでいます。
--- certificates.aC MAY be included to convey one or more
attribute certificates associated with the member's
encryption certificate.
--- certificates.aCは、メンバーの暗号化証明書に関連している1通以上の属性証明書を伝えるために含まれるかもしれません。
--- certificates.certPath MAY also be included to convey
certificates that might aid the recipient in
constructing valid certification paths for the
certificate provided in certificates.pKC and the
attribute certificates provided in certificates.aC.
These certificates are optional because they might
already be included elsewhere in the message (e.g., in
the outer CMS layer).
--- また、certificates.certPathは、certificates.pKCに提供された証明書とcertificates.aCに提供された属性証明書のために有効な証明経路を構成する際に受取人を支援するかもしれない証明書を伝えるために含まれるかもしれません。 それらがメッセージ(例えば、外側のCMS層の)のほかの場所に既に含まれるかもしれないので、これらの証明書は任意です。
3.1.13. GL Key
3.1.13. GLキー
The GLA uses the glKey to distribute the shared KEK. The glKey message MUST be signed by the GLA. The glKey control attribute has the syntax GLKey:
GLAは、共有されたKEKを分配するのにglKeyを使用します。 GLAはglKeyメッセージにサインしなければなりません。 glKeyコントロール属性に、構文GLKeyがあります:
GLKey ::= SEQUENCE {
glName GeneralName,
glIdentifier KEKIdentifier, -- See [CMS]
glkWrapped RecipientInfos, -- See [CMS]
glkAlgorithm AlgorithmIdentifier,
glkNotBefore GeneralizedTime,
glkNotAfter GeneralizedTime }
GLKey:、:= 系列glName GeneralName、glIdentifier KEKIdentifier--[cm]glkWrapped RecipientInfosを見てください--glkAlgorithm AlgorithmIdentifier、glkNotBefore GeneralizedTime、glkNotAfter GeneralizedTimeを見てください[cm]。
-- KEKIdentifier is included only for illustrative purposes as -- it is imported from [CMS].
-- KEKIdentifierが説明に役立った目的のためだけに含まれている、--[CMS]からそれを輸入します。
KEKIdentifier ::= SEQUENCE {
keyIdentifier OCTET STRING,
date GeneralizedTime OPTIONAL,
other OtherKeyAttribute OPTIONAL }
KEKIdentifier:、:= 系列keyIdentifier OCTET STRING、日付GeneralizedTime OPTIONAL、他のOtherKeyAttribute OPTIONAL
The fields in GLKey have the following meaning:
GLKeyの分野には、以下の意味があります:
- glName is the name of the GL.
- glNameはGLという名前です。
- glIdentifier is the key identifier of the shared KEK. See
Section 6.2.3 of [CMS] for a description of the subfields.
- glIdentifierは共有されたKEKの主要な識別子です。 部分体の記述に関して.3セクション6.2[CMS]を見てください。
Turner Standards Track [Page 21] RFC 5275 CMS SymKeyDist June 2008
5275cmのターナー標準化過程[21ページ]RFC SymKeyDist2008年6月
- glkWrapped is the wrapped shared KEK for the GL for a particular
duration. The RecipientInfos MUST be generated as specified in
Section 6.2 of [CMS]. The ktri RecipientInfo choice MUST be
supported. The key in the EncryptedKey field (i.e., the
distributed shared KEK) MUST be generated according to the
section concerning random number generation in the security
considerations of [CMS].
- glkWrappedされているのは、特定の持続時間のためのGLのための包装された共有されたKEKです。 RecipientInfosは[CMS]のセクション6.2で指定されるように発生しているに違いありません。 ktri RecipientInfo選択を支持しなければなりません。 セクションに応じて、EncryptedKey分野(すなわち、分配された共有されたKEK)のキーは[CMS]のセキュリティ問題における乱数発生に関して発生しなければなりません。
- glkAlgorithm identifies the algorithm with which the shared KEK
is used. Since no encrypted data content is being conveyed at
this point, the parameters encoded with the algorithm should be
the structure defined for smimeCapabilities rather than encrypted
content.
- glkAlgorithmは共有されたKEKが使用されているアルゴリズムを特定します。 コード化されたデータ内容が全くここに伝えられていないので、アルゴリズムでコード化されたパラメタはsmimeCapabilitiesのために内容をコード化するよりむしろ定義された構造であるべきです。
- glkNotBefore indicates the date at which the shared KEK is
considered valid. GeneralizedTime values MUST be expressed in
UTC (Zulu) and MUST include seconds (i.e., times are
YYYYMMDDHHMMSSZ), even where the number of seconds is zero.
GeneralizedTime values MUST NOT include fractional seconds.
- glkNotBeforeは共有されたKEKが有効であると考えられる日付を示します。 GeneralizedTime値は、UTC(ズールー族)に表さなければならなくて、秒を含まなければなりません(すなわち、回はYYYYMMDDHHMMSSZです)、秒数がゼロでさえあるところで。 GeneralizedTime値は断片的な秒を含んではいけません。
- glkNotAfter indicates the date after which the shared KEK is
considered invalid. GeneralizedTime values MUST be expressed in
UTC (Zulu) and MUST include seconds (i.e., times are
YYYYMMDDHHMMSSZ), even where the number of seconds is zero.
GeneralizedTime values MUST NOT include fractional seconds.
- glkNotAfterは共有されたKEKが無効であると考えられる日付を示します。 GeneralizedTime値は、UTC(ズールー族)に表さなければならなくて、秒を含まなければなりません(すなわち、回はYYYYMMDDHHMMSSZです)、秒数がゼロでさえあるところで。 GeneralizedTime値は断片的な秒を含んではいけません。
If the glKey message is in response to a glUseKEK message:
glKeyメッセージがglUseKEKメッセージに対応しているなら:
- The GLA MUST generate separate glKey messages for each recipient
if glUseKEK.glKeyAttributes.recipientsNotMutuallyAware is set to
TRUE. For each recipient, you want to generate a message that
contains that recipient's key (i.e., one message with one
attribute).
- glUseKEK.glKeyAttributes.recipientsNotMutuallyAwareがTRUEに用意ができているなら、GLA MUSTは各受取人のために別々のglKeyメッセージを発生させます。 各受取人に関しては、あなたはその受取人のキー(すなわち、1つの属性がある1つのメッセージ)を含むメッセージを発生させたがっています。
- The GLA MUST generate the requested number of glKey messages.
The value in glUseKEK.glKeyAttributes.generationCounter indicates
the number of glKey messages requested.
- GLA MUSTはglKeyメッセージの要求された数を発生させます。 glUseKEK.glKeyAttributes.generationCounterの値はメッセージが要求したglKeyの数を示します。
If the glKey message is in response to a glRekey message:
glKeyメッセージがglRekeyメッセージに対応しているなら:
- The GLA MUST generate separate glKey messages for each recipient
if glRekey.glNewKeyAttributes.recipientsNotMutuallyAware is set
to TRUE.
- glRekey.glNewKeyAttributes.recipientsNotMutuallyAwareがTRUEに用意ができているなら、GLA MUSTは各受取人のために別々のglKeyメッセージを発生させます。
- The GLA MUST generate the requested number of glKey messages.
The value in glUseKEK.glKeyAttributes.generationCounter indicates
the number of glKey messages requested.
- GLA MUSTはglKeyメッセージの要求された数を発生させます。 glUseKEK.glKeyAttributes.generationCounterの値はメッセージが要求したglKeyの数を示します。
Turner Standards Track [Page 22] RFC 5275 CMS SymKeyDist June 2008
5275cmのターナー標準化過程[22ページ]RFC SymKeyDist2008年6月
- The GLA MUST generate one glKey message for each outstanding
shared KEKs for the GL when glRekeyAllGLKeys is set to TRUE.
- glRekeyAllGLKeysがTRUEに用意ができているとき、GLA MUSTはGLのためにそれぞれの傑出している共有されたKEKsへの1つのglKeyメッセージを発生させます。
If the glKey message was not in response to a glRekey or glUseKEK (e.g., where the GLA controls rekey):
glKeyメッセージはglRekeyに対応していなかったか、そして、glUseKEK(例えばGLAはそこでrekeyを制御します):
- The GLA MUST generate separate glKey messages for each recipient
when glUseKEK.glNewKeyAttributes.recipientsNotMutuallyAware that
set up the GL was set to TRUE.
- GLをセットアップするglUseKEK.glNewKeyAttributes.recipientsNotMutuallyAwareがTRUEに用意ができていたとき、GLA MUSTは各受取人のために別々のglKeyメッセージを発生させます。
- The GLA MAY generate glKey messages prior to the duration on the
last outstanding shared KEK expiring, where the number of glKey
messages generated is generationCounter minus one (1). Other
distribution mechanisms can also be supported to support this
functionality.
- GLA MAYは最後の傑出している共有されたKEKの期限が切れるところの持続時間の前のglKeyメッセージを発生させます。そこでは、メッセージが発生させたglKeyの数が1つ(1)を引いたgenerationCounterです。 また、この機能性を支持するために他の分配メカニズムをサポートできます。
3.2. Use of CMC, CMS, and PKIX
3.2. CMC、cm、およびPKIXの使用
The following sections outline the use of CMC, CMS, and the PKIX certificate and CRL profile.
以下のセクションはCMC、CMS、PKIX証明書、およびCRLプロフィールの使用について概説します。
3.2.1. Protection Layers
3.2.1. 保護層
The following sections outline the protection required for the control attributes defined in this document.
以下のセクションは本書では定義されたコントロール属性に必要である保護について概説します。
Note: There are multiple ways to encapsulate SignedData and EnvelopedData. The first is to use a MIME wrapper around each ContentInfo, as specified in [MSG]. The second is not to use a MIME wrapper around each ContentInfo, as specified in Transporting S/MIME Objects in X.400 [X400TRANS].
以下に注意してください。 SignedDataとEnvelopedDataを要約する複数の方法があります。 1番目は[MSG]で指定されるように各ContentInfoの周りでMIME包装紙を使用することです。 2番目は各ContentInfoの周りでMIME包装紙を使用しないことです、X.400[X400TRANS]のTransporting S/MIME Objectsで指定されるように。
3.2.1.1. Minimum Protection
3.2.1.1. 最小の保護
At a minimum, a SignedData MUST protect each request and response encapsulated in PKIData and PKIResponse. The following is a depiction of the minimum wrappings:
最小限では、SignedDataはPKIDataとPKIResponseで要約された各要求と応答を保護しなければなりません。 ↓これは最小のラッピングの描写です:
Minimum Protection
------------------
SignedData
PKIData or PKIResponse
controlSequence
最小の保護------------------ SignedData PKIDataかPKIResponse controlSequence
Prior to taking any action on any request or response SignedData(s) MUST be processed according to [CMS].
どんな要求や応答も少しも実行する前に、[CMS]に従って、SignedData(s)を処理しなければなりません。
Turner Standards Track [Page 23] RFC 5275 CMS SymKeyDist June 2008
5275cmのターナー標準化過程[23ページ]RFC SymKeyDist2008年6月
3.2.1.2. Additional Protection
3.2.1.2. 追加保護
An additional EnvelopedData MAY also be used to provide confidentiality of the request and response. An additional SignedData MAY also be added to provide authentication and integrity of the encapsulated EnvelopedData. The following is a depiction of the optional additional wrappings:
また、追加EnvelopedDataは、要求と応答の秘密性を提供するのに使用されるかもしれません。 また、追加SignedDataは、要約のEnvelopedDataの認証と保全を提供するために加えられるかもしれません。 ↓これは任意の追加ラッピングの描写です:
Authentication and Integrity
Confidentiality Protection of Confidentiality Protection
-------------------------- -----------------------------
EnvelopedData SignedData
SignedData EnvelopedData
PKIData or PKIResponse SignedData
controlSequence PKIData or PKIResponse
controlSequence
秘密性保護の認証と保全秘密性保護-------------------------- ----------------------------- EnvelopedData SignedData SignedData EnvelopedData PKIData、PKIResponse SignedData controlSequence PKIDataまたはPKIResponse controlSequence
If an incoming message is encrypted, the confidentiality of the message MUST be preserved. All EnvelopedData objects MUST be processed as specified in [CMS]. If a SignedData is added over an EnvelopedData, a ContentHints attribute SHOULD be added. See Section 2.9 of Extended Security Services for S/MIME [ESS].
入力メッセージがコード化されているなら、メッセージの秘密性を保存しなければなりません。 すべてのEnvelopedData物として、[CMS]で指定されていた状態で処理しなければなりません。 SignedDataがEnvelopedDataの上で加えられるなら、ContentHintsはSHOULDを結果と考えます。加えられます。 S/MIME[ESS]に関して拡張セキュリティー・サービスのセクション2.9を見てください。
If the GLO or GL member applies confidentiality to a request, the EnvelopedData MUST include the GLA as a recipient. If the GLA forwards the GL member request to the GLO, then the GLA MUST decrypt the EnvelopedData content, strip the confidentiality layer, and apply its own confidentiality layer as an EnvelopedData with the GLO as a recipient.
GLOかGLメンバーが秘密性を要求に適用するなら、EnvelopedDataは受取人としてGLAを含まなければなりません。 GLAがGLメンバー要求をGLOに転送するなら、GLA MUSTは受取人としてのGLOと共にEnvelopedDataとしてEnvelopedDataが内容であると解読して、秘密性層を剥取って、それ自身の秘密性層を申し込みます。
3.2.2. Combining Requests and Responses
3.2.2. 要求と応答を結合します。
Multiple requests and responses corresponding to a GL MAY be included in one PKIData.controlSequence or PKIResponse.controlSequence. Requests and responses for multiple GLs MAY be combined in one PKIData or PKIResponse by using PKIData.cmsSequence and PKIResponse.cmsSequence. A separate cmsSequence MUST be used for different GLs. That is, requests corresponding to two different GLs are included in different cmsSequences. The following is a diagram depicting multiple requests and responses combined in one PKIData and PKIResponse:
含まれていて、1PKIData.controlSequenceかPKIResponse.controlSequenceでGL MAYに対応する複数の要求と応答。 複数のGLsのための要求と応答は、1PKIDataかPKIResponseでPKIData.cmsSequenceとPKIResponse.cmsSequenceを使用することによって、結合されるかもしれません。 異なったGLsに別々のcmsSequenceを使用しなければなりません。 すなわち、2異なったGLsに対応する要求は異なったcmsSequencesに含まれています。 ↓これは1PKIDataとPKIResponseで結合された複数の要求と応答について表現するダイヤグラムです:
Turner Standards Track [Page 24] RFC 5275 CMS SymKeyDist June 2008
5275cmのターナー標準化過程[24ページ]RFC SymKeyDist2008年6月
Multiple Requests and Responses
Request Response
------- --------
SignedData SignedData
PKIData PKIResponse
cmsSequence cmsSequence
SignedData SignedData
PKIData PKIResponse
controlSequence controlSequence
One or more requests One or more responses
corresponding to one GL corresponding to one GL
SignedData SignedData
PKIData PKIResponse
controlSequence controlSequence
One or more requests One or more responses
corresponding to another GL corresponding to another GL
複数の要求と応答は応答を要求します。------- -------- 別のGLに対応する別のGLに対応するSignedData SignedData PKIData PKIResponse cmsSequence cmsSequence SignedData SignedData PKIData PKIResponse controlSequence controlSequence One、より多くの要求One、1GL SignedData SignedData PKIData PKIResponse controlSequence controlSequence Oneに対応する1GLに対応するより多くの応答、より多くの要求Oneまたは、より多くの応答
When applying confidentiality to multiple requests and responses, all of the requests/responses MAY be included in one EnvelopedData. The following is a depiction:
複数の要求と応答に秘密性を適用するとき、要求/応答のすべてが1EnvelopedDataに含まれるかもしれません。 ↓これは描写です:
Confidentiality of Multiple Requests and Responses
Wrapped Together
----------------
EnvelopedData
SignedData
PKIData
cmsSequence
SignedData
PKIResponse
controlSequence
One or more requests
corresponding to one GL
SignedData
PKIData
controlSequence
One or more requests
corresponding to one GL
複数の要求と一緒に包装された応答の秘密性---------------- 1GLに対応する1GL SignedData PKIData controlSequence Oneの要求に対応するEnvelopedData SignedData PKIData cmsSequence SignedData PKIResponse controlSequence Oneか、より多くの要求
Turner Standards Track [Page 25] RFC 5275 CMS SymKeyDist June 2008
5275cmのターナー標準化過程[25ページ]RFC SymKeyDist2008年6月
Certain combinations of requests in one PKIData.controlSequence and one PKIResponse.controlSequence are not allowed. The invalid combinations listed here MUST NOT be generated:
1PKIData.controlSequenceと1PKIResponse.controlSequenceの要求のある組み合わせは許されていません。 ここに記載された無効の組み合わせは発生してはいけません:
Invalid Combinations
---------------------------
glUseKEK & glDeleteMember
glUseKEK & glRekey
glUseKEK & glDelete
glDelete & glAddMember
glDelete & glDeleteMember
glDelete & glRekey
glDelete & glAddOwner
glDelete & glRemoveOwner
無効の組み合わせ--------------------------- glUseKEK&glDeleteMember glUseKEK&glRekey glUseKEK&glDelete glDelete&glAddMember glDelete&glDeleteMember glDelete&glRekey glDelete&glAddOwner glDelete&glRemoveOwner
To avoid unnecessary errors, certain requests and responses SHOULD be processed prior to others. The following is the priority of message processing, if not listed it is an implementation decision as to which to process first: glUseKEK before glAddMember, glRekey before glAddMember, and glDeleteMember before glRekey. Note that there is a processing priority, but it does not imply an ordering within the content.
不要な誤り、ある要求、および応答SHOULDを避けるには、他のものの前で処理されてください。 ↓これがメッセージ処理の優先権である、記載されないなら、それは最初に処理する実現決定です: glAddMemberの前のglUseKEK、glAddMemberの前のglRekey、およびglRekeyの前のglDeleteMember。 処理優先がありますが、内容の中で注文を含意しないことに注意してください。
3.2.3. GLA Generated Messages
3.2.3. GLAはメッセージを発生させました。
When the GLA generates a success or fail message, it generates one for each request. SKDFailInfo values of unsupportedDuration, unsupportedDeliveryMethod, unsupportedAlgorithm, noGLONameMatch, nameAlreadyInUse, alreadyAnOwner, and notAnOwner are not returned to GL members.
GLAが成功を発生させるか、メッセージに失敗してください、または各要求あたり1つを発生させると。 unsupportedDuration、unsupportedDeliveryMethod、unsupportedAlgorithm、noGLONameMatch、nameAlreadyInUse、alreadyAnOwner、およびnotAnOwnerのSKDFailInfo値はGLメンバーに返されません。
If GLKeyAttributes.recipientsNotMutuallyAware is set to TRUE, a separate PKIResponse.cMCStatusInfoExt and PKIData.glKey MUST be generated for each recipient. However, it is valid to send one message with multiple attributes to the same recipient.
GLKeyAttributes.recipientsNotMutuallyAwareがTRUEに用意ができているなら、別々のPKIResponse.cMCStatusInfoExtとPKIData.glKeyは各受取人のために発生しなければなりません。 しかしながら、複数の属性がある1つのメッセージを同じ受取人に送るのは有効です。
If the GL has multiple GLOs, the GLA MUST send cMCStatusInfoExt messages to the requesting GLO. The mechanism to determine which GLO made the request is beyond the scope of this document.
GLに複数のGLOsがあるなら、GLA MUSTは要求しているGLOへのメッセージをcMCStatusInfoExtに送ります。 GLOが要求をした決定するメカニズムはこのドキュメントの範囲を超えています。
If a GL is managed and the GLA receives a glAddMember, glDeleteMember, or glkCompromise message, the GLA redirects the request to the GLO for review. An additional, SignedData MUST be applied to the redirected request as follows:
GLが管理されて、GLAがglAddMember、glDeleteMember、またはglkCompromiseメッセージを受け取るなら、GLAはレビューのためにGLOに要求を向け直します。 追加していて、以下の向け直された要求にSignedDataを適用しなければなりません:
Turner Standards Track [Page 26] RFC 5275 CMS SymKeyDist June 2008
5275cmのターナー標準化過程[26ページ]RFC SymKeyDist2008年6月
GLA Forwarded Requests
----------------------
SignedData
PKIData
cmsSequence
SignedData
PKIData
controlSequence
GLAは要求を転送しました。---------------------- SignedData PKIData cmsSequence SignedData PKIData controlSequence
3.2.4. CMC Control Attributes and CMS Signed Attributes
3.2.4. CMCコントロール属性とcmのサインされた属性
CMC carries control attributes as CMS signed attributes. These attributes are defined in [CMC] and [CMS]. Some of these attributes are REQUIRED; others are OPTIONAL. The required attributes are as follows: cMCStatusInfoExt transactionId, senderNonce, recipientNonce, queryPending, and signingTime. Other attributes can also be used; however, their use is beyond the scope of this document. The following sections specify requirements in addition to those already specified in [CMC] and [CMS].
CMSが属性にサインしたので、CMCはコントロール属性を運びます。 これらの属性は[CMC]と[CMS]で定義されます。 これらの属性のいくつかがREQUIREDです。 他のものはOPTIONALです。 必要な属性は以下の通りです: cMCStatusInfoExt transactionId、senderNonce、recipientNonce、queryPending、およびsigningTime。 また、他の属性を使用できます。 しかしながら、彼らの使用はこのドキュメントの範囲を超えています。 以下のセクションは[CMC]と[CMS]で既に指定されたものに加えて要件を指定します。
3.2.4.1. Using cMCStatusInfoExt
3.2.4.1. cMCStatusInfoExtを使用します。
cMCStatusInfoExt is used by GLAs to indicate to GLOs and GL members that a request was unsuccessful. Two classes of failure codes are used within this document. Errors from the CMCFailInfo list, found in Section 5.1.4 of CMC, are encoded as defined in CMC. Error codes defined in this document are encoded using the ExtendedFailInfo field of the cmcStatusInfoExt structure. If the same failure code applies to multiple commands, a single cmcStatusInfoExt structure can be used with multiple items in cMCStatusInfoExt.bodyList. The GLA MAY also return other pertinent information in statusString. The SKDFailInfo object identifier and value are:
cMCStatusInfoExtは、要求が失敗していたのをGLOsとGLメンバーに示すのにGLAsによって使用されます。 2つのクラスの失敗コードはこのドキュメントの中に使用されます。 .4セクション5.1CMCで見つけられたCMCFailInfoリストからの誤りはCMCで定義されるようにコード化されます。 本書では定義されたエラーコードは、cmcStatusInfoExt構造のExtendedFailInfo分野を使用することでコード化されます。 同じ失敗コードが複数のコマンドに適用されるなら、cMCStatusInfoExt.bodyListの複数の項目と共にただ一つのcmcStatusInfoExt構造を使用できます。 また、GLA MAYはstatusStringの他の適切な情報を返します。 SKDFailInfo物の識別子と値は以下の通りです。
id-cet-skdFailInfo OBJECT IDENTIFIER ::= { iso(1)
identified-organization(3) dod(6) internet(1) security(5)
mechanisms(5) pkix(7) cet(15) skdFailInfo(1) }
イド-cet-skdFailInfo物の識別子:、:= iso(1)の特定された組織(3)dod(6)インターネット(1)セキュリティ(5)メカニズム(5)pkix(7) cet(15) skdFailInfo(1)
SKDFailInfo ::= INTEGER {
unspecified (0),
closedGL (1),
unsupportedDuration (2),
noGLACertificate (3),
invalidCert (4),
unsupportedAlgorithm (5),
noGLONameMatch (6),
invalidGLName (7),
nameAlreadyInUse (8),
noSpam (9),
SKDFailInfo:、:= INTEGER、不特定の(0)、closedGL(1)、unsupportedDuration(2)、noGLACertificate(3)、invalidCert(4)、unsupportedAlgorithm(5)、noGLONameMatch(6)、invalidGLName(7)、nameAlreadyInUse(8)、noSpam(9)
Turner Standards Track [Page 27] RFC 5275 CMS SymKeyDist June 2008
5275cmのターナー標準化過程[27ページ]RFC SymKeyDist2008年6月
-- obsolete (10),
alreadyAMember (11),
notAMember (12),
alreadyAnOwner (13),
notAnOwner (14) }
-- notAnOwner(14)、(10)、alreadyAMember(11)、notAMember(12)、alreadyAnOwner(13)を時代遅れにしてください。
The values have the following meaning:
値には、以下の意味があります:
- unspecified indicates that the GLA is unable or unwilling to
perform the requested action and does not want to indicate the
reason.
- 不特定である、要求された動作を実行するためにGLAが不本意であることを示して、理由は示したくはありません。
- closedGL indicates that members can only be added or deleted by
the GLO.
- closedGLは、GLOがメンバーを加えるか、または削除できるだけであるのを示します。
- unsupportedDuration indicates that the GLA does not support
generating keys that are valid for the requested duration.
- unsupportedDurationは、GLAが、要求された持続時間に、有効なキーを発生させるのを支持しないのを示します。
- noGLACertificate indicates that the GLA does not have a valid
certificate.
- noGLACertificateは、GLAには有効な証明書がないのを示します。
- invalidCert indicates that the member's encryption certificate
was not verifiable (i.e., signature did not validate,
certificate's serial number present on a CRL, the certificate
expired, etc.).
- invalidCertは、メンバーの暗号化証明書が証明可能でなかったのを示します。(すなわち、署名が有効にしなかった、証明書のCRLの現在の通し番号、吐き出されたなど証明書)
- unsupportedAlgorithm indicates the GLA does not support the
requested algorithm.
- unsupportedAlgorithmは、GLAが要求されたアルゴリズムを支持しないのを示します。
- noGLONameMatch indicates that one of the names in the certificate
used to sign a request does not match the name of a registered
GLO.
- noGLONameMatchは、要求にサインするのに使用される証明書の名前の1つが登録されたGLOという名前に合っていないのを示します。
- invalidGLName indicates that the GLA does not support the glName
present in the request.
- invalidGLNameは、GLAが要求の現在のglNameを支持しないのを示します。
- nameAlreadyInUse indicates that the glName is already assigned on
the GLA.
- nameAlreadyInUseは、glNameが既にGLAに割り当てられるのを示します。
- noSpam indicates that the prospective GL member did not sign the
request (i.e., if the name in glMember.glMemberName does not
match one of the names (either the subject distinguished name or
one of the subject alternative names) in the certificate used to
sign the request).
- noSpamは、将来のGLメンバーが要求にサインしなかったのを示します(すなわち、glMember.glMemberNameの名前が要求にサインするのに使用される証明書で名前の1つに合っていないなら(対象の分類名か対象の代替名の1つのどちらか))。
- alreadyAMember indicates that the prospective GL member is
already a GL member.
- alreadyAMemberは、将来のGLメンバーが既にGLメンバーであることを示します。
Turner Standards Track [Page 28] RFC 5275 CMS SymKeyDist June 2008
5275cmのターナー標準化過程[28ページ]RFC SymKeyDist2008年6月
- notAMember indicates that the prospective GL member to be deleted
is not presently a GL member.
- notAMemberは、削除されるべき将来のGLメンバーが現在GLメンバーでないことを示します。
- alreadyAnOwner indicates that the prospective GLO is already a
GLO.
- alreadyAnOwnerは、将来のGLOが既にGLOであることを示します。
- notAnOwner indicates that the prospective GLO to be deleted is
not presently a GLO.
- notAnOwnerは、削除されるべき将来のGLOが現在GLOでないことを示します。
cMCStatusInfoExt is used by GLAs to indicate to GLOs and GL members that a request was successfully completed. If the request was successful, the GLA returns a cMCStatusInfoExt response with cMCStatus.success and optionally other pertinent information in statusString.
cMCStatusInfoExtは、要求が首尾よく終了したのをGLOsとGLメンバーに示すのにGLAsによって使用されます。 要求がうまくいったなら、cMCStatus.successと任意に他の適切な情報がstatusStringにある状態で、GLAはcMCStatusInfoExt応答を返します。
When the GL is managed and the GLO has reviewed GL member initiated glAddMember, glDeleteMember, and glkComrpomise requests, the GLO uses cMCStatusInfoExt to indicate the success or failure of the request. If the request is allowed, cMCStatus.success is returned and statusString is optionally returned to convey additional information. If the request is denied, cMCStatus.failed is returned and statusString is optionally returned to convey additional information. Additionally, the appropriate SKDFailInfo can be included in cMCStatusInfoExt.extendedFailInfo.
GLが管理されて、GLOがGLメンバーの開始しているglAddMember(glDeleteMember)とglkComrpomise要求を再検討したとき、GLOは、要求の成否を示すのにcMCStatusInfoExtを使用します。 要求を許すなら、cMCStatus.successを返します、そして、追加情報を伝えるために任意にstatusStringを返します。 要求を否定するなら、cMCStatus.failedを返します、そして、追加情報を伝えるために任意にstatusStringを返します。 さらに、cMCStatusInfoExt.extendedFailInfoに適切なSKDFailInfoを含むことができます。
cMCStatusInfoExt is used by GLOs, GLAs, and GL members to indicate that signature verification failed. If the signature failed to verify over any control attribute except a cMCStatusInfoExt, a cMCStatusInfoExt control attribute MUST be returned indicating cMCStatus.failed and otherInfo.failInfo.badMessageCheck. If the signature over the outermost PKIData failed, the bodyList value is zero (0). If the signature over any other PKIData failed, the bodyList value is the bodyPartId value from the request or response. GLOs and GL members who receive cMCStatusInfoExt messages whose signatures are invalid SHOULD generate a new request to avoid badMessageCheck message loops.
cMCStatusInfoExtは、署名照合が失敗したのを示すのにGLOs、GLAs、およびGLメンバーによって使用されます。 cMCStatusInfoExt以外に、署名がいずれか上でコントロール属性について確かめなかったなら、cMCStatus.failedとotherInfo.failInfo.badMessageCheckを示して、cMCStatusInfoExtコントロール属性を返さなければなりません。 一番はずれのPKIDataの上の署名が失敗したなら、bodyList値は(0)ではありません。 いかなる他のPKIDataの上の署名が失敗したなら、bodyList値は要求か応答からのbodyPartId値です。 署名が無効のSHOULDであるcMCStatusInfoExtメッセージを受け取るGLOsとGLメンバーがbadMessageCheckメッセージ輪を避けるという新しい要求を発生させます。
cMCStatusInfoExt is also used by GLOs and GLAs to indicate that a request could not be performed immediately. If the request could not be processed immediately by the GLA or GLO, the cMCStatusInfoExt control attribute MUST be returned indicating cMCStatus.pending and otherInfo.pendInfo. When requests are redirected to the GLO for approval (for managed lists), the GLA MUST NOT return a cMCStatusInfoExt indicating query pending.
また、cMCStatusInfoExtは、すぐに要求を実行できなかったのを示すのにGLOsとGLAsによって使用されます。 すぐGLAかGLOが要求を処理できないなら、cMCStatus.pendingとotherInfo.pendInfoを示して、cMCStatusInfoExtコントロール属性を返さなければなりません。 要求が承認(管理されたリストのための)のためにGLOに向け直されるとき、GLA MUST NOTは未定のcMCStatusInfoExt表示質問を返します。
Turner Standards Track [Page 29] RFC 5275 CMS SymKeyDist June 2008
5275cmのターナー標準化過程[29ページ]RFC SymKeyDist2008年6月
cMCStatusInfoExt is also used by GLAs to indicate that a glaQueryRequest is not supported. If the glaQueryRequest is not supported, the cMCStatusInfoExt control attribute MUST be returned indicating cMCStatus.noSupport and statusString is optionally returned to convey additional information.
また、cMCStatusInfoExtは、glaQueryRequestが支持されないのを示すのにGLAsによって使用されます。 glaQueryRequestを支持しないなら、cMCStatus.noSupportを示して、cMCStatusInfoExtコントロール属性を返さなければなりません、そして、追加情報を伝えるために任意にstatusStringを返します。
cMCStatusInfoExt is also used by GL members, GLOs, and GLAs to indicate that the signingTime (see Section 3.2.4.3) is not close enough to the locally specified time. If the local time is not close enough to the time specified in signingTime, a cMCStatus.failed and otherInfo.failInfo.badTime MAY be returned.
.3が)十分近くにないセクション3.2.4を見てください。また、cMCStatusInfoExtがそれを示すのにGLメンバー(GLOs)とGLAsが使用される、signingTime、(局所的に指定された時間。 現地時間がsigningTimeで指定された時間に十分近くないか、そして、cMCStatus.failedとotherInfo.failInfo.badTimeを返すかもしれません。
3.2.4.2. Using transactionId
3.2.4.2. transactionIdを使用します。
transactionId MAY be included by GLOs, GLAs, or GL members to identify a given transaction. All subsequent requests and responses related to the original request MUST include the same transactionId control attribute. If GL members include a transactionId and the request is redirected to the GLO, the GLA MAY include an additional transactionId in the outer PKIData. If the GLA included an additional transactionId in the outer PKIData, when the GLO generates a cMCStatusInfoExt response it generates one for the GLA with the GLA's transactionId and one for the GL member with the GL member's transactionId.
transactionIdは、与えられた取引を特定するためにGLOs、GLAs、またはGLメンバーによって入れられるかもしれません。 すべてのその後の要求とオリジナルの要求に関連する応答は同じtransactionIdコントロール属性を含まなければなりません。 GLメンバーがtransactionIdを入れて、要求がGLOに向け直されるなら、GLA MAYは外側のPKIDataに追加transactionIdを含んでいます。 GLAが外側のPKIDataに追加transactionIdを含んでいたなら、GLOがcMCStatusInfoExt応答を発生させると、それはGLAのためのGLAのtransactionIdがあるものとGLメンバーのためのGLメンバーのtransactionIdがある1つを発生させます。
3.2.4.3. Using Nonces and signingTime
3.2.4.3. 一回だけとsigningTimeを使用します。
The use of nonces (see Section 5.6 of [CMC]) and an indication of when the message was signed (see Section 11.3 of [CMS]) can be used to provide application-level replay prevention.
アプリケーションレベル再生防止を提供するのに一回だけ([CMC]のセクション5.6を見る)の使用とメッセージがサインされた([CMS]のセクション11.3を見てください)時のしるしを使用できます。
To protect the GL, all messages MUST include the signingTime attribute. Message originators and recipients can then use the time provided in this attribute to determine whether they have previously received the message.
GLを保護するために、すべてのメッセージがsigningTime属性を含まなければなりません。 そして、メッセージ創始者と受取人は彼らが以前にメッセージを受け取ったかどうか決定するためにこの属性に提供された時間を費やすことができます。
If the originating message includes a senderNonce, the response to the message MUST include the received senderNonce value as the recipientNonce and a new value as the senderNonce value in the response.
由来しているメッセージがsenderNonceを含んでいるなら、senderNonceが応答で評価するようにメッセージへの応答はrecipientNonceとしての容認されたsenderNonce値と新しい値を含まなければなりません。
If a GLA aggregates multiple messages together or forwards a message to a GLO, the GLA MAY optionally generate a new nonce value and include that in the wrapping message. When the response comes back from the GLO, the GLA builds a response to the originator(s) of the message(s) and deals with each of the nonce values from the originating messages.
GLAが複数のメッセージに一緒に集めるか、またはメッセージをGLOに転送するなら、GLA MAYは新しい一回だけの値を任意に発生させて、ラッピングメッセージにそれを含んでいます。 応答がGLOから戻るとき、GLAはメッセージの創始者への応答を組み込んで、由来しているメッセージからそれぞれの一回だけの値に対処します。
Turner Standards Track [Page 30] RFC 5275 CMS SymKeyDist June 2008
5275cmのターナー標準化過程[30ページ]RFC SymKeyDist2008年6月
For these attributes, it is necessary to maintain state information on exchanges to compare one result to another. The time period for which this information is maintained is a local policy.
これらの属性に、1つの結果を別のものと比較するために交換の州の情報を保守するのが必要です。 この情報が保守される期間はローカルの方針です。
3.2.4.4. CMC and CMS Attribute Support Requirements
3.2.4.4. CMCとcm属性サポート要件
The following are the implementation requirements for CMC control attributes and CMS signed attributes for an implementation to be considered conformant to this specification:
↓これはCMCコントロール属性のための実現要件です、そして、CMSはconformantであると考えられるべき実現のためにこの仕様に属性にサインしました:
Implementation Requirement |
GLO | GLA | GL Member | Attribute
O R | O R F | O R |
--------- | ------------- | --------- | ----------
MUST MUST | MUST MUST - | MUST MUST | cMCStatusInfoExt
MAY MAY | MUST MUST - | MAY MAY | transactionId
MAY MAY | MUST MUST - | MAY MAY | senderNonce
MAY MAY | MUST MUST - | MAY MAY | recepientNonce
MUST MUST | MUST MUST - | MUST MUST | SKDFailInfo
MUST MUST | MUST MUST - | MUST MUST | signingTime
実現要件| GLO| GLA| GLメンバー| O Rを結果と考えてください。| ○ R F| ○ R| --------- | ------------- | --------- | ---------- 必須必須| 必須必須である、-| 必須必須| cMCStatusInfoExt5月の5月| 必須必須である、-| 5月の5月| transactionId5月の5月| 必須必須である、-| 5月の5月| senderNonce5月の5月| 必須必須である、-| 5月の5月| recepientNonce必須必須| 必須必須である、-| 必須必須| SKDFailInfo必須必須| 必須必須である、-| 必須必須| signingTime
3.2.5. Resubmitted GL Member Messages
3.2.5. 再提出されたGLメンバーメッセージ
When the GL is managed, the GLA forwards the GL member requests to the GLO for GLO approval by creating a new request message containing the GL member request(s) as a cmsSequence item. If the GLO approves the request, it can either add a new layer of wrapping and send it back to the GLA or create a new message and send it to the GLA. (Note in this case there are now 3 layers of PKIData messages with appropriate signing layers.)
GLが管理されるとき、GLAは、GLO承認のためにcmsSequenceの品目としてGLメンバー要求を含む新しい要求メッセージを作成することによって、GLメンバー要求をGLOに転送します。 GLOが要求を承認するなら、それは、GLAに新しい層のラッピングを加えて、それをGLAに送り返すか、新しいメッセージを作成して、またはそれを送ることができます。 (適切な調印層がある3つの層に関するPKIDataメッセージが現在この場合あることに注意してください。)
3.2.6. PKIX Certificate and CRL Profile
3.2.6. PKIX証明書とCRLプロフィール
Signatures, certificates, and CRLs are verified according to the PKIX profile [PROFILE].
PKIXプロフィール[PROFILE]によると、署名、証明書、およびCRLsは確かめられます。
Name matching is performed according to the PKIX profile [PROFILE].
PKIXプロフィール[PROFILE]によると、名前マッチングは実行されます。
All distinguished name forms must follow the UTF8String convention noted in the PKIX profile [PROFILE].
すべての分類名フォームがPKIXプロフィール[PROFILE]に述べられたUTF8Stringコンベンションに続かなければなりません。
A certificate per GL would be issued to the GLA.
1GLあたり1通の証明書をGLAに発行するでしょう。
GL policy may mandate that the GL member's address be included in the GL member's certificate.
GL方針は、GLメンバーのアドレスがGLメンバーの証明書に含まれているのを強制するかもしれません。
Turner Standards Track [Page 31] RFC 5275 CMS SymKeyDist June 2008
5275cmのターナー標準化過程[31ページ]RFC SymKeyDist2008年6月
4. Administrative Messages
4. 管理メッセージ
There are a number of administrative messages that must be exchanged to manage a GL. The following sections describe each request and response message combination in detail. The procedures defined in this section are not prescriptive.
GLを管理するために交換しなければならない多くの管理メッセージがあります。 以下のセクションは詳細に各要求と応答メッセージ組み合わせについて説明します。 このセクションで定義された手順は規範的ではありません。
4.1. Assign KEK to GL
4.1. KEKをGLに割り当ててください。
Prior to generating a group key, a GL needs to be set up and a shared KEK assigned to the GL. Figure 3 depicts the protocol interactions to set up and assign a shared KEK. Note that error messages are not depicted in Figure 3. Additionally, behavior for the optional transactionId, senderNonce, and recipientNonce CMC control attributes is not addressed in these procedures.
グループキー、GLが、セットアップされる必要があって、共有されたKEKがGLに割り当てた発生の前に。 図3は、共有されたKEKをセットアップして、割り当てるためにプロトコル相互作用について表現します。 エラーメッセージが図3に表現されないことに注意してください。 さらに、任意のtransactionId、senderNonce、およびrecipientNonce CMCコントロール属性のための振舞いはこれらの手順で記述されません。
+-----+ 1 2 +-----+
| GLA | <-------> | GLO |
+-----+ +-----+
+-----+ 1 2 +-----+ | GLA| <、-、-、-、-、-、--、>| GLO| +-----+ +-----+
Figure 3 - Create Group List
図3--グループリストを作成してください。
The process is as follows:
過程は以下の通りです:
1 - The GLO is the entity responsible for requesting the creation of
the GL. The GLO sends a
SignedData.PKIData.controlSequence.glUseKEK request to the GLA (1
in Figure 3). The GLO MUST include glName, glAddress,
glOwnerName, glOwnerAddress, and glAdministration. The GLO MAY
also include their preferences for the shared KEK in
glKeyAttributes by indicating whether the GLO controls the rekey
in rekeyControlledByGLO, whether separate glKey messages should
be sent to each recipient in recipientsNotMutuallyAware, the
requested algorithm to be used with the shared KEK in
requestedAlgorithm, the duration of the shared KEK, and how many
shared KEKs should be initially distributed in generationCounter.
The GLO MUST also include the signingTime attribute with this
request.
1--GLOはGLの創造を要求するのに原因となる実体です。 GLOはGLA(図3の1)にSignedData.PKIData.controlSequence.glUseKEK要求を送ります。 GLO MUSTはglName、glAddress、glOwnerName、glOwnerAddress、およびglAdministrationを含んでいます。 また、GLOがrekeyControlledByGLOでrekeyを制御するかどうかを示すことによって、GLO MAYはglKeyAttributesの共有されたKEKのための彼らの好みを含んでいます、別々のglKeyメッセージをrecipientsNotMutuallyAwareの各受取人に送るべきであるか否かに関係なく、requestedAlgorithm、共有されたKEKの持続時間、およびいくつの共有されたKEKsが初めはgenerationCounterで分配されるべきであるかで共有されたKEKと共に使用されるべき要求されたアルゴリズム。 また、GLO MUSTはこの要求があるsigningTime属性を含んでいます。
1.a - If the GLO knows of members to be added to the GL, the
glAddMember request(s) MAY be included in the same
controlSequence as the glUseKEK request (see Section 3.2.2).
The GLO indicates the same glName in the glAddMember request
as in glUseKEK.glInfo.glName. Further glAddMember procedures
are covered in Section 4.3.
1. a--GLOがメンバーを知っているなら、GL、glAddMember要求5月に加えられるには、glUseKEK要求と同じcontrolSequenceで含められてください(セクション3.2.2を見てください)。 GLOはglUseKEK.glInfo.glNameのようにglAddMember要求で同じglNameを示します。 さらなるglAddMember手順はセクション4.3でカバーされています。
Turner Standards Track [Page 32] RFC 5275 CMS SymKeyDist June 2008
5275cmのターナー標準化過程[32ページ]RFC SymKeyDist2008年6月
1.b - The GLO can apply confidentiality to the request by
encapsulating the SignedData.PKIData in an EnvelopedData (see
Section 3.2.1.2).
セクション3.2を見てください。1. b--缶がEnvelopedDataでSignedData.PKIDataを要約しながら要求への秘密性を適用するGLO、(.1 .2)。
1.c - The GLO can also optionally apply another SignedData over the
EnvelopedData (see Section 3.2.1.2).
セクション3.2を見てください。1. c、--、また、GLOが任意に別のSignedDataをEnvelopedDataの上に適用できる(.1 .2)。
2 - Upon receipt of the request, the GLA checks the signingTime and
verifies the signature on the innermost SignedData.PKIData. If
an additional SignedData and/or EnvelopedData encapsulates the
request (see Sections 3.2.1.2 and 3.2.2), the GLA verifies the
outer signature(s) and/or decrypts the outer layer(s) prior to
verifying the signature on the innermost SignedData.
2--要求を受け取り次第、GLAは最も奥深いSignedData.PKIDataでsigningTimeをチェックして、署名について確かめます。 そして、追加SignedData、そして/または、EnvelopedDataが要求を要約する、(セクション3.2.1を見てください、.2、3.2 .2) 最も奥深いSignedDataで署名について確かめる前に、GLAは、外側の署名について確かめる、そして/または、外側の層が(s)であると解読します。
2.a - If the signingTime attribute value is not within the locally
accepted time window, the GLA MAY return a response
indicating cMCStatus.failed and otherInfo.failInfo.badTime
and a signingTime attribute.
2. a--signingTimeであるなら値を結果と考えてください。局所的に受け入れられたタイムウィンドウ、cMCStatus.failedとotherInfo.failInfo.badTimeを示すGLA MAYリターンa応答、およびsigningTime属性の中にありません。
2.b - Else if signature processing continues and if the signatures
do not verify, the GLA returns a cMCStatusInfoExt response
indicating cMCStatus.failed and
otherInfo.failInfo.badMessageCheck. Additionally, a
signingTime attribute is included with the response.
2. b--ほかに、署名処理が続いて、署名であるならしてください。GLAリターンa cMCStatusInfoExt応答がcMCStatus.failedとotherInfo.failInfo.badMessageCheckを示して、確かめません。 さらに、signingTime属性は応答で含まれています。
2.c - Else if the signatures do verify but the GLA does not have a
valid certificate, the GLA returns a cMCStatusInfoExt with
cMCStatus.failed and otherInfo.extendedFailInfo.SKDFailInfo
value of noValidGLACertificate. Additionally, a signingTime
attribute is included with the response. Instead of
immediately returning the error code, the GLA attempts to get
a certificate, possibly using [CMC].
2. c--ほかに、署名であるならGLAだけについて確かめてください。GLAリターンの有効な証明書、cMCStatus.failedとcMCStatusInfoExt、およびotherInfo.extendedFailInfo.SKDFailInfoには、noValidGLACertificateの値がありません。 さらに、signingTime属性は応答で含まれています。 すぐにエラーコードを返すことの代わりに、ことによると[CMC]を使用して、GLAは、証明書を手に入れるのを試みます。
2.d - Else the signatures are valid and the GLA does have a valid
certificate, the GLA checks that one of the names in the
certificate used to sign the request matches one of the names
in glUseKEK.glOwnerInfo.glOwnerName.
2.、d--GLAには、ほかに、署名は有効であり、有効な証明書(証明書の名前の1つがglUseKEK.glOwnerInfo.glOwnerNameの名前の要求マッチ1にサインするのに使用したGLAチェック)があります。
2.d.1 - If the names do not match, the GLA returns a response
indicating cMCStatusInfoExt with cMCStatus.failed and
otherInfo.extendedFailInfo.SKDFailInfo value of
noGLONameMatch. Additionally, a signingTime attribute is
included with the response.
2. d.1--名前であるなら合わないでください、そして、GLAはnoGLONameMatchのcMCStatus.failedとotherInfo.extendedFailInfo.SKDFailInfo値でcMCStatusInfoExtを示す応答を返します。 さらに、signingTime属性は応答で含まれています。
Turner Standards Track [Page 33] RFC 5275 CMS SymKeyDist June 2008
5275cmのターナー標準化過程[33ページ]RFC SymKeyDist2008年6月
2.d.2 - Else if the names all match, the GLA checks that the
glName and glAddress are not already in use. The GLA
also checks any glAddMember included within the
controlSequence with this glUseKEK. Further processing
of the glAddMember is covered in Section 4.3.
2.、d.2--ほかに、名前がすべて合っているなら、GLAは、glNameとglAddressが既に使用中でないことをチェックします。 また、このglUseKEKと共にcontrolSequenceの中にどんなglAddMemberも含んでいて、GLAはチェックします。 glAddMemberのさらなる処理はセクション4.3でカバーされています。
2.d.2.a - If the glName is already in use, the GLA returns a
response indicating cMCStatusInfoExt with
cMCStatus.failed and
otherInfo.extendedFailInfo.SKDFailInfo value of
nameAlreadyInUse. Additionally, a signingTime
attribute is included with the response.
2.、d.2.a--glNameが既に使用中であるなら、GLAはnameAlreadyInUseのcMCStatus.failedとotherInfo.extendedFailInfo.SKDFailInfo値でcMCStatusInfoExtを示す応答を返します。 さらに、signingTime属性は応答で含まれています。
2.d.2.b - Else if the requestedAlgorithm is not supported, the
GLA returns a response indicating cMCStatusInfoExt
with cMCStatus.failed and
otherInfo.extendedFailInfo.SKDFailInfo value of
unsupportedAlgorithm. Additionally, a signingTime
attribute is included with the response.
2.、d.2.b--ほかに、requestedAlgorithmが支持されないなら、GLAはunsupportedAlgorithmのcMCStatus.failedとotherInfo.extendedFailInfo.SKDFailInfo値でcMCStatusInfoExtを示す応答を返します。 さらに、signingTime属性は応答で含まれています。
2.d.2.c - Else if the duration cannot be supported, determining
this is beyond the scope of this document, the GLA
returns a response indicating cMCStatusInfoExt with
cMCStatus.failed and
otherInfo.extendedFailInfo.SKDFailInfo value of
unsupportedDuration. Additionally, a signingTime
attribute is included with the response.
2. d.2.c--持続時間がそうすることができないなら、ほかに、支持されてください、これがこのドキュメントの範囲を超えていることを決定してGLAはunsupportedDurationのcMCStatus.failedとotherInfo.extendedFailInfo.SKDFailInfo値でcMCStatusInfoExtを示す応答を返します。 さらに、signingTime属性は応答で含まれています。
2.d.2.d - Else if the GL cannot be supported for other reasons,
which the GLA does not wish to disclose, the GLA
returns a response indicating cMCStatusInfoExt with
cMCStatus.failed and
otherInfo.extendedFailInfo.SKDFailInfo value of
unspecified. Additionally, a signingTime attribute
is included with the response.
2. d.2.d--GLがそうすることができないなら、ほかに、他の理由で支持されてください、そして、GLAは不特定のcMCStatus.failedとotherInfo.extendedFailInfo.SKDFailInfo値でcMCStatusInfoExtを示す応答を返します。(GLAは理由を明らかにしたがっていません)。 さらに、signingTime属性は応答で含まれています。
2.d.2.e - Else if the glName is not already in use, the
duration can be supported, and the requestedAlgorithm
is supported, the GLA MUST return a cMCStatusInfoExt
indicating cMCStatus.success and a signingTime
attribute. (2 in Figure 3). The GLA also takes
administrative actions, which are beyond the scope of
this document, to store the glName, glAddress,
glKeyAttributes, glOwnerName, and glOwnerAddress.
The GLA also sends a glKey message as described in
section 5.
2.、d.2.e--ほかに、glNameが既に使用中でなく、持続時間を支持できて、requestedAlgorithmが支持されるなら、GLA MUSTはcMCStatus.successを示すcMCStatusInfoExtとsigningTime属性を返します。 (図3の2。) また、GLAは管理行動を取ります。(glName、glAddress、glKeyAttributes、glOwnerName、およびglOwnerAddressを格納するために、行動はこのドキュメントの範囲にあります)。 また、GLAはセクション5で説明されるようにglKeyメッセージを送ります。
Turner Standards Track [Page 34] RFC 5275 CMS SymKeyDist June 2008
5275cmのターナー標準化過程[34ページ]RFC SymKeyDist2008年6月
2.d.2.e.1 - The GLA can apply confidentiality to the response
by encapsulating the SignedData.PKIResponse in an
EnvelopedData if the request was encapsulated in
an EnvelopedData (see Section 3.2.1.2).
セクション3.2を見てください。2. d.2.e.1--缶が要求がEnvelopedDataで要約されたならEnvelopedDataでSignedData.PKIResponseを要約しながら応答への秘密性を適用するGLA、(.1 .2)。
2.d.2.e.2 - The GLA can also optionally apply another
SignedData over the EnvelopedData (see Section
3.2.1.2).
セクション3.2を見てください。2. d.2.e.2、--、また、GLAが任意に別のSignedDataをEnvelopedDataの上に適用できる(.1 .2)。
3 - Upon receipt of the cMCStatusInfoExt responses, the GLO checks
the signingTime and verifies the GLA signature(s). If an
additional SignedData and/or EnvelopedData encapsulates the
response (see Section 3.2.1.2 or 3.2.2), the GLO verifies the
outer signature and/or decrypts the outer layer prior to
verifying the signature on the innermost SignedData.
3--cMCStatusInfoExt応答を受け取り次第、GLOはsigningTimeをチェックして、GLA署名について確かめます。 または、追加SignedData、そして/または、EnvelopedDataが応答を要約する、(セクション3.2.1を見てください、.2、3.2 .2) 最も奥深いSignedDataで署名について確かめる前に、GLOは外側の署名について確かめる、そして/または、外側の層を解読します。
3.a - If the signingTime attribute value is not within the locally
accepted time window, the GLO MAY return a response
indicating cMCStatus.failed and otherInfo.failInfo.badTime
and a signingTime attribute.
3. a--signingTimeであるなら値を結果と考えてください。局所的に受け入れられたタイムウィンドウ、cMCStatus.failedとotherInfo.failInfo.badTimeを示すGLO MAYリターンa応答、およびsigningTime属性の中にありません。
3.b - Else if signature processing continues and if the signatures
do verify, the GLO MUST check that one of the names in the
certificate used to sign the response matches the name of the
GL.
3. b--ほかに、署名処理が続いて、署名であるならしてください、検証、GLO MUSTは、応答にサインするのに使用される証明書の名前の1つがGLという名前に合っているのをチェックします。
3.b.1 - If the name of the GL does not match the name present in
the certificate used to sign the message, the GLO should
not believe the response.
3. b.1--GLという名前がそうしないなら、現在という名前を合わせてください。証明書には、メッセージは以前はよくサインしていました、とGLOが応答を信じているはずがありません。
3.b.2 - Else if the name of the GL does match the name present in
the certificate and:
そして、3. b.2--GLという名前がそうするならほかに、証明書の現在の名前を合わせてください、:
3.b.2.a - If the signatures do verify and the response was
cMCStatusInfoExt indicating cMCStatus.success, the
GLO has successfully created the GL.
そして、3. b.2.a--署名であるならしてください、確かめ、応答がcMCStatus.successを示すcMCStatusInfoExtであった、GLOは首尾よくGLを作成しました。
3.b.2.b - Else if the signatures are valid and the response is
cMCStatusInfoExt.cMCStatus.failed with any reason,
the GLO can reattempt to create the GL using the
information provided in the response. The GLO can
also use the glaQueryRequest to determine the
algorithms and other characteristics supported by the
GLA (see Section 4.9).
3. b.2.b--ほかに、署名が有効であり、応答がcMCStatusInfoExt.cMCStatus.failedであるならいずれをもっても推論してください、そして、GLOは、応答に提供された情報を使用することでGLを作成するために「再-試み」ることができます。 また、GLOは、GLAによって支持されたアルゴリズムと他の特性を決定するのにglaQueryRequestを使用できます(セクション4.9を見てください)。
Turner Standards Track [Page 35] RFC 5275 CMS SymKeyDist June 2008
5275cmのターナー標準化過程[35ページ]RFC SymKeyDist2008年6月
4.2. Delete GL from GLA
4.2. GLAからGLを削除してください。
From time to time, there are instances when a GL is no longer needed. In this case, the GLO deletes the GL. Figure 4 depicts the protocol interactions to delete a GL. Note that behavior for the optional transactionId, senderNonce, and recipientNonce CMC control attributes is not addressed in these procedures.
GLはもう必要でないときに、時々、例があります。 この場合、GLOはGLを削除します。 図4は、GLを削除するためにプロトコル相互作用について表現します。 任意のtransactionId、senderNonce、およびrecipientNonce CMCコントロール属性のための振舞いがこれらの手順で記述されないことに注意してください。
+-----+ 1 2 +-----+
| GLA | <-------> | GLO |
+-----+ +-----+
+-----+ 1 2 +-----+ | GLA| <、-、-、-、-、-、--、>| GLO| +-----+ +-----+
Figure 4 - Delete Group List
図4--グループリストを削除してください。
The process is as follows:
過程は以下の通りです:
1 - The GLO is responsible for requesting the deletion of the GL.
The GLO sends a SignedData.PKIData.controlSequence.glDelete
request to the GLA (1 in Figure 4). The name of the GL to be
deleted is included in GeneralName. The GLO MUST also include
the signingTime attribute and can also include a transactionId
and senderNonce attributes.
1--GLOはGLの削除を要求するのに責任があります。 GLOはGLA(図4の1)にSignedData.PKIData.controlSequence.glDelete要求を送ります。 削除されるべきGLという名前はGeneralNameに含まれています。 また、GLO MUSTはsigningTime属性を含んでいます、そして、また、transactionIdとsenderNonce属性を含むことができます。
1.a - The GLO can optionally apply confidentiality to the request
by encapsulating the SignedData.PKIData in an EnvelopedData
(see Section 3.2.1.2).
セクション3.2を見てください。1. a--缶がEnvelopedDataでSignedData.PKIDataを要約しながら任意に要求への秘密性を適用するGLO、(.1 .2)。
1.b - The GLO MAY optionally apply another SignedData over the
EnvelopedData (see Section 3.2.1.2).
セクション3.2を見てください。1. b、--、GLO MAYが任意に別のSignedDataをEnvelopedDataの上に適用する(.1 .2)。
2 - Upon receipt of the request, the GLA checks the signingTime and
verifies the signature on the innermost SignedData.PKIData. If
an additional SignedData and/or EnvelopedData encapsulates the
request (see Section 3.2.1.2 or 3.2.2), the GLA verifies the
outer signature and/or decrypts the outer layer prior to
verifying the signature on the innermost SignedData.
2--要求を受け取り次第、GLAは最も奥深いSignedData.PKIDataでsigningTimeをチェックして、署名について確かめます。 または、追加SignedData、そして/または、EnvelopedDataが要求を要約する、(セクション3.2.1を見てください、.2、3.2 .2) 最も奥深いSignedDataで署名について確かめる前に、GLAは外側の署名について確かめる、そして/または、外側の層を解読します。
2.a - If the signingTime attribute value is not within the locally
accepted time window, the GLA MAY return a response
indicating cMCStatus.failed and otherInfo.failInfo.badTime
and a signingTime attribute.
2. a--signingTimeであるなら値を結果と考えてください。局所的に受け入れられたタイムウィンドウ、cMCStatus.failedとotherInfo.failInfo.badTimeを示すGLA MAYリターンa応答、およびsigningTime属性の中にありません。
2.b - Else if signature processing continues and if the signatures
cannot be verified, the GLA returns a cMCStatusInfoExt
response indicating cMCStatus.failed and
otherInfo.failInfo.badMessageCheck. Additionally, a
signingTime attribute is included with the response.
2. b--署名処理が続いて、署名がそうすることができないなら、ほかに、確かめられてください、そして、GLAはcMCStatus.failedとotherInfo.failInfo.badMessageCheckを示すcMCStatusInfoExt応答を返します。 さらに、signingTime属性は応答で含まれています。
Turner Standards Track [Page 36] RFC 5275 CMS SymKeyDist June 2008
5275cmのターナー標準化過程[36ページ]RFC SymKeyDist2008年6月
2.c - Else if the signatures verify, the GLA makes sure the GL is
supported by checking the name of the GL matches a glName
stored on the GLA.
2. c--、ほか、署名が確かめる、GLAは、GLがglNameがGLAに収納したGLマッチの名前をチェックすることによって支持されるのを確実にします。
2.c.1 - If the glName is not supported by the GLA, the GLA
returns a response indicating cMCStatusInfoExt with
cMCStatus.failed and
otherInfo.extendedFailInfo.SKDFailInfo value of
invalidGLName. Additionally, a signingTime attribute is
included with the response.
2.、c.1--glNameがGLAによって支持されないなら、GLAはinvalidGLNameのcMCStatus.failedとotherInfo.extendedFailInfo.SKDFailInfo値でcMCStatusInfoExtを示す応答を返します。 さらに、signingTime属性は応答で含まれています。
2.c.2 - Else if the glName is supported by the GLA, the GLA
ensures that a registered GLO signed the glDelete request
by checking if one of the names present in the digital
signature certificate used to sign the glDelete request
matches a registered GLO.
2.、c.2--ほかに、glNameがGLAによって支持されるなら、GLAは、glDelete要求にサインするのに使用されるデジタル署名証明書の現在の名前の1つが登録されたGLOに合っているかどうかチェックすることによって登録されたGLOがglDelete要求にサインしたのを確実にします。
2.c.2.a - If the names do not match, the GLA returns a response
indicating cMCStatusInfoExt with cMCStatus.failed and
otherInfo.extendedFailInfo.SKDFailInfo value of
noGLONameMatch. Additionally, a signingTime
attribute is included with the response.
2. c.2.a--名前であるなら合わないでください、そして、GLAはnoGLONameMatchのcMCStatus.failedとotherInfo.extendedFailInfo.SKDFailInfo値でcMCStatusInfoExtを示す応答を返します。 さらに、signingTime属性は応答で含まれています。
2.c.2.b - Else if the names do match, but the GL cannot be
deleted for other reasons, which the GLA does not
wish to disclose, the GLA returns a response
indicating cMCStatusInfoExt with cMCStatus.failed and
otherInfo.extendedFailInfo.SKDFailInfo value of
unspecified. Additionally, a signingTime attribute
is included with the response. Actions beyond the
scope of this document must then be taken to delete
the GL from the GLA.
2. c.2.b--ほかに、名前であるなら合ってくださいが、他の理由でGLを削除できません、cMCStatus.failedと共にcMCStatusInfoExtを示す応答とotherInfo.extendedFailInfo.SKDFailInfoが評価する不特定のGLA復帰。(GLAは理由を明らかにしたがっていません)。 さらに、signingTime属性は応答で含まれています。 そして、GLAからGLを削除するためにこのドキュメントの範囲を超えた行動を取らなければなりません。
2.c.2.c - Else if the names do match, the GLA returns a
cMCStatusInfoExt indicating cMCStatus.success and a
signingTime attribute (2 in Figure 4). The GLA ought
not accept further requests for member additions,
member deletions, or group rekeys for this GL.
2. c.2.c--ほかに、名前であるなら合ってください、そして、GLAはcMCStatus.successを示すcMCStatusInfoExtとsigningTime属性(図4の2)を返します。 GLAはこのGLのためにメンバー追加、メンバー削除、またはグループ「再-キー」を求めるさらなる要求を受け入れません。
2.c.2.c.1 - The GLA can apply confidentiality to the response
by encapsulating the SignedData.PKIResponse in an
EnvelopedData if the request was encapsulated in
an EnvelopedData (see Section 3.2.1.2).
セクション3.2を見てください。2. c.2.c.1--缶が要求がEnvelopedDataで要約されたならEnvelopedDataでSignedData.PKIResponseを要約しながら応答への秘密性を適用するGLA、(.1 .2)。
2.c.2.c.2 - The GLA MAY optionally apply another SignedData
over the EnvelopedData (see Section 3.2.1.2).
セクション3.2を見てください。2. c.2.c.2、--、GLA MAYが任意に別のSignedDataをEnvelopedDataの上に適用する(.1 .2)。
Turner Standards Track [Page 37] RFC 5275 CMS SymKeyDist June 2008
5275cmのターナー標準化過程[37ページ]RFC SymKeyDist2008年6月
3 - Upon receipt of the cMCStatusInfoExt response, the GLO checks the
signingTime and verifies the GLA signature(s). If an additional
SignedData and/or EnvelopedData encapsulates the response (see
Section 3.2.1.2 or 3.2.2), the GLO verifies the outer signature
and/or decrypts the outer layer prior to verifying the signature
on the innermost SignedData.
3--cMCStatusInfoExt応答を受け取り次第、GLOはsigningTimeをチェックして、GLA署名について確かめます。 または、追加SignedData、そして/または、EnvelopedDataが応答を要約する、(セクション3.2.1を見てください、.2、3.2 .2) 最も奥深いSignedDataで署名について確かめる前に、GLOは外側の署名について確かめる、そして/または、外側の層を解読します。
3.a - If the signingTime attribute value is not within the locally
accepted time window, the GLO MAY return a response
indicating cMCStatus.failed and otherInfo.failInfo.badTime
and a signingTime attribute.
3. a--signingTimeであるなら値を結果と考えてください。局所的に受け入れられたタイムウィンドウ、cMCStatus.failedとotherInfo.failInfo.badTimeを示すGLO MAYリターンa応答、およびsigningTime属性の中にありません。
3.b - Else if signature processing continues and if the signatures
verify, the GLO checks that one of the names in the
certificate used to sign the response matches the name of the
GL.
3. b--、ほか、署名処理が続いて、署名である、検証、GLOは、応答にサインするのに使用される証明書の名前の1つがGLという名前に合っているのをチェックします。
3.b.1 - If the name of the GL does not match the name present in
the certificate used to sign the message, the GLO should
not believe the response.
3. b.1--GLという名前がそうしないなら、現在という名前を合わせてください。証明書には、メッセージは以前はよくサインしていました、とGLOが応答を信じているはずがありません。
3.b.2 - Else if the name of the GL does match the name present in
the certificate and:
そして、3. b.2--GLという名前がそうするならほかに、証明書の現在の名前を合わせてください、:
3.b.2.a - If the signatures verify and the response was
cMCStatusInfoExt indicating cMCStatus.success, the
GLO has successfully deleted the GL.
そして、3. b.2.a、署名である、確かめ、応答がcMCStatus.successを示すcMCStatusInfoExtであった、GLOは首尾よくGLを削除しました。
3.b.2.b - Else if the signatures do verify and the response was
cMCStatusInfoExt.cMCStatus.failed with any reason,
the GLO can reattempt to delete the GL using the
information provided in the response.
3. b.2.b--ほかに、署名であるならしてください、検証、応答はどんな理由(応答に提供された情報を使用することでGLを削除するGLO缶の「再-試み」)があるcMCStatusInfoExt.cMCStatus.failedでした。
4.3. Add Members to GL
4.3. GLにメンバーを加えてください。
To add members to GLs, either the GLO or prospective members use the glAddMember request. The GLA processes GLO and prospective GL member requests differently though. GLOs can submit the request at any time to add members to the GL, and the GLA, once it has verified the request came from a registered GLO, should process it. If a prospective member sends the request, the GLA needs to determine how the GL is administered. When the GLO initially configured the GL, it set the GL to be unmanaged, managed, or closed (see Section 3.1.1). In the unmanaged case, the GLA merely processes the member's request. In the managed case, the GLA forwards the requests from the prospective members to the GLO for review. Where there are multiple GLOs for a GL, which GLO the request is forwarded to is beyond the scope of this document. The GLO reviews the request and either
GLs、GLOまたは将来のメンバーにメンバーを加えるには、glAddMember要求を使用してください。 もっとも、GLAはGLOと将来のGLメンバー要求を異なって処理します。 GLOsはいつでもGL、およびGLAにメンバーを加えるために要求を提出できて、いったんそうすると、要求は登録されたGLOから確かめられる状態で来て、それを処理するべきです。 将来のメンバーが要求を送るなら、GLAは、GLがどのように管理されるかを決定する必要があります。 GLOが初めはGLを構成したとき、それは、GLに非管理されるか、管理されるか、または閉じられるように設定しました(セクション3.1.1を見てください)。 非管理された場合では、GLAは単にメンバーの要求を処理します。 管理された場合では、GLAはレビューのために将来のメンバーからGLOまでの要求を転送します。 GLのための複数のGLOsがあるところでは、どのGLOに要求を転送するかはこのドキュメントの範囲を超えています。 GLOは要求とどちらかを再検討します。
Turner Standards Track [Page 38] RFC 5275 CMS SymKeyDist June 2008
5275cmのターナー標準化過程[38ページ]RFC SymKeyDist2008年6月
rejects it or submits a reformed request to the GLA. In the closed case, the GLA will not accept requests from prospective members. The following sections describe the processing for the GLO(s), GLA, and prospective GL members depending on where the glAddMeber request originated, either from a GLO or from prospective members. Figure 5 depicts the protocol interactions for the three options. Note that the error messages are not depicted. Additionally, note that behavior for the optional transactionId, senderNonce, and recipientNonce CMC control attributes is not addressed in these procedures.
GLAにそれを拒絶するか、または改革された要求を提出します。 閉じている場合では、GLAは将来のメンバーから要求を受け入れないでしょう。 以下のセクションはGLO(s)、GLA、およびglAddMeber要求がGLO、または、将来のメンバーから由来したところを当てにする将来のGLメンバーのための処理について説明します。 図5は3つのオプションのためにプロトコル相互作用について表現します。 エラーメッセージが表現されないことに注意してください。 さらに、任意のtransactionId、senderNonce、およびrecipientNonce CMCコントロール属性のための振舞いがこれらの手順で記述されないことに注意してください。
+-----+ 2,B{A} 3 +----------+
| GLO | <--------+ +-------> | Member 1 |
+-----+ | | +----------+
1 | |
+-----+ <--------+ | 3 +----------+
| GLA | A +-------> | ... |
+-----+ <-------------+ +----------+
|
| 3 +----------+
+-------> | Member n |
+----------+
+-----+ 2、Bは3+です。----------+ | GLO| <、-、-、-、-、-、-、--+ +------->| メンバー1| +-----+ | | +----------+ 1 | | +-----+ <。--------+ | 3 +----------+ | GLA| +------->| ... | +-----+ <。-------------+ +----------+ | | 3 +----------+ +------->| メンバーn| +----------+
Figure 5 - Member Addition
図5--メンバー添加
An important decision that needs to be made on a group-by-group basis is whether to rekey the group every time a new member is added. Typically, unmanaged GLs should not be rekeyed when a new member is added, as the overhead associated with rekeying the group becomes prohibitive, as the group becomes large. However, managed and closed GLs can be rekeyed to maintain the confidentiality of the traffic sent by group members. An option to rekeying managed or closed GLs when a member is added is to generate a new GL with a different group key. Group rekeying is discussed in Sections 4.5 and 5.
新しいメンバーが加えられるときはいつも、作られていて、rekeyにか否かに関係なく、グループがグループごとのベースでは、あるということである必要がある重要な決定。 新しいメンバーを加えるとき、通常、unmanaged GLsを「再-合わせ」るべきではありません、グループを「再-合わせ」ると関連しているオーバーヘッドが禁止になるとき、グループが大きくなるとき。 しかしながら、グループのメンバーによって送られた交通の秘密性を維持するために管理されて閉じているGLsを「再-合わせ」ることができます。 メンバーが加えられるとき、「再-合わせ」ることへのオプションが管理されたか、または閉じているGLsは異なったグループキーで新しいGLを発生させることになっています。 セクション4.5と5でグループの「再-合わせ」ることについて議論します。
4.3.1. GLO Initiated Additions
4.3.1. GLOは追加を開始しました。
The process for GLO initiated glAddMember requests is as follows:
GLOがglAddMember要求を開始したので、過程は以下の通りです:
1 - The GLO collects the pertinent information for the member(s) to
be added (this may be done through an out-of-bands means). The
GLO then sends a SignedData.PKIData.controlSequence with a
separate glAddMember request for each member to the GLA (1 in
Figure 5). The GLO includes the GL name in glName, the member's
name in glMember.glMemberName, the member's address in
glMember.glMemberAddress, and the member's encryption certificate
in glMember.certificates.pKC. The GLO can also include any
attribute certificates associated with the member's encryption
1--GLOは、メンバーが加えられるために適切な情報を集めます(バンドで出ている手段でこれをするかもしれません)。 そしてGLOは各メンバーを求める別々のglAddMember要求と共にGLA(図5の1)にSignedData.PKIData.controlSequenceを送ります。 GLOはglName、glMember.glMemberNameのメンバーの名前、glMember.glMemberAddressのメンバーのアドレス、およびglMember.certificates.pKCのメンバーの暗号化証明書にGL名を含んでいます。 また、GLOはメンバーの暗号化に関連しているどんな属性証明書も含むことができます。
Turner Standards Track [Page 39] RFC 5275 CMS SymKeyDist June 2008
5275cmのターナー標準化過程[39ページ]RFC SymKeyDist2008年6月
certificate in glMember.certificates.aC, and the certification
path associated with the member's encryption and attribute
certificates in glMember.certificates.certPath. The GLO MUST
also include the signingTime attribute with this request.
glMember.certificates.aC、およびメンバーの暗号化と属性に関連している証明経路でglMember.certificates.certPathの証明書を証明してください。 また、GLO MUSTはこの要求があるsigningTime属性を含んでいます。
1.a - The GLO can optionally apply confidentiality to the request
by encapsulating the SignedData.PKIData in an EnvelopedData
(see Section 3.2.1.2).
セクション3.2を見てください。1. a--缶がEnvelopedDataでSignedData.PKIDataを要約しながら任意に要求への秘密性を適用するGLO、(.1 .2)。
1.b - The GLO can also optionally apply another SignedData over the
EnvelopedData (see Section 3.2.1.2).
セクション3.2を見てください。1. b、--、また、GLOが任意に別のSignedDataをEnvelopedDataの上に適用できる(.1 .2)。
2 - Upon receipt of the request, the GLA checks the signingTime and
verifies the signature on the innermost SignedData.PKIData. If
an additional SignedData and/or EnvelopedData encapsulates the
request (see Section 3.2.1.2 or 3.2.2), the GLA verifies the
outer signature and/or decrypts the outer layer prior to
verifying the signature on the innermost SignedData.
2--要求を受け取り次第、GLAは最も奥深いSignedData.PKIDataでsigningTimeをチェックして、署名について確かめます。 または、追加SignedData、そして/または、EnvelopedDataが要求を要約する、(セクション3.2.1を見てください、.2、3.2 .2) 最も奥深いSignedDataで署名について確かめる前に、GLAは外側の署名について確かめる、そして/または、外側の層を解読します。
2.a - If the signingTime attribute value is not within the locally
accepted time window, the GLA MAY return a response
indicating cMCStatus.failed and otherInfo.failInfo.badTime
and a signingTime attribute.
2. a--signingTimeであるなら値を結果と考えてください。局所的に受け入れられたタイムウィンドウ、cMCStatus.failedとotherInfo.failInfo.badTimeを示すGLA MAYリターンa応答、およびsigningTime属性の中にありません。
2.b - Else if signature processing continues and if the signatures
cannot be verified, the GLA returns a cMCStatusInfoExt
response indicating cMCStatus.failed and
otherInfo.failInfo.badMessageCheck. Additionally, a
signingTime attribute is included with the response.
2. b--署名処理が続いて、署名がそうすることができないなら、ほかに、確かめられてください、そして、GLAはcMCStatus.failedとotherInfo.failInfo.badMessageCheckを示すcMCStatusInfoExt応答を返します。 さらに、signingTime属性は応答で含まれています。
2.c - Else if the signatures verify, the glAddMember request is
included in a controlSequence with the glUseKEK request, and
the processing in Section 4.1 item 2.d is successfully
completed, the GLA returns a cMCStatusInfoExt indicating
cMCStatus.success and a signingTime attribute (2 in Figure
5).
2. c--、ほか、署名が確かめる、glAddMember要求はcontrolSequenceにglUseKEK要求で含まれています、そして、セクション4.1項目2.dにおける処理は首尾よく終了しています、cMCStatus.successを示すcMCStatusInfoExtとsigningTimeが結果と考えるGLAリターン(図5の2)。
2.c.1 - The GLA can apply confidentiality to the response by
encapsulating the SignedData.PKIData in an EnvelopedData
if the request was encapsulated in an EnvelopedData (see
Section 3.2.1.2).
セクション3.2を見てください。2. c.1--缶が要求がEnvelopedDataで要約されたならEnvelopedDataでSignedData.PKIDataを要約しながら応答への秘密性を適用するGLA、(.1 .2)。
2.c.2 - The GLA can also optionally apply another SignedData over
the EnvelopedData (see Section 3.2.1.2).
セクション3.2を見てください。2. c.2、--、また、GLAが任意に別のSignedDataをEnvelopedDataの上に適用できる(.1 .2)。
Turner Standards Track [Page 40] RFC 5275 CMS SymKeyDist June 2008
5275cmのターナー標準化過程[40ページ]RFC SymKeyDist2008年6月
2.d - Else if the signatures verify and the GLAddMember request is
not included in a controlSequence with the GLCreate request,
the GLA makes sure the GL is supported by checking that the
glName matches a glName stored on the GLA.
2.、d--ほかに、署名がGLCreate要求があるa controlSequenceに確かめて、含まれていないなら、GLAddMemberが、要求するGLAは、glNameがGLAに格納されたglNameに合っているのをチェックすることによってGLが支持されるのを確実にします。
2.d.1 - If the glName is not supported by the GLA, the GLA
returns a response indicating cMCStatusInfoExt with
cMCStatus.failed and
otherInfo.extendedFailInfo.SKDFailInfo value of
invalidGLName. Additionally, a signingTime attribute is
included with the response.
2.、d.1--glNameがGLAによって支持されないなら、GLAはinvalidGLNameのcMCStatus.failedとotherInfo.extendedFailInfo.SKDFailInfo値でcMCStatusInfoExtを示す応答を返します。 さらに、signingTime属性は応答で含まれています。
2.d.2 - Else if the glName is supported by the GLA, the GLA
checks to see if the glMemberName is present on the GL.
2.、d.2--ほかに、glNameがGLAによって支持されるなら、GLAは、glMemberNameがGLに存在しているかどうか確認するためにチェックします。
2.d.2.a - If the glMemberName is present on the GL, the GLA
returns a response indicating cMCStatusInfoExt with
cMCStatus.failed and
otherInfo.extendedFailInfo.SKDFailInfo value of
alreadyAMember. Additionally, a signingTime
attribute is included with the response.
2. d.2.a--glMemberNameがそうならGL、GLAにリターンを提示してください。cMCStatus.failedと共にcMCStatusInfoExtを示す応答とalreadyAMemberのotherInfo.extendedFailInfo.SKDFailInfo値。 さらに、signingTime属性は応答で含まれています。
2.d.2.b - Else if the glMemberName is not present on the GL,
the GLA checks how the GL is administered.
2. d.2.b--glMemberNameがそうでないなら、ほかに、GL、GLAチェックのときにGLがどう管理されるかを提示してください。
2.d.2.b.1 - If the GL is closed, the GLA checks that a
registered GLO signed the request by checking
that one of the names in the digital signature
certificate used to sign the request matches a
registered GLO.
2.、d.2.b.1--GLが閉じられるなら、GLAは、要求にサインするのに使用されるデジタル署名証明書の名前の1つが登録されたGLOに合っているのをチェックすることによって登録されたGLOが要求にサインしたのをチェックします。
2.d.2.b.1.a - If the names do not match, the GLA returns a
response indicating cMCStatusInfoExt with
cMCStatus.failed and
otherInfo.extendedFailInfo.SKDFailInfo value
of noGLONameMatch. Additionally, a
signingTime attribute is included with the
response.
2. d.2.b.1.a--名前であるなら合わないでください、そして、GLAはnoGLONameMatchのcMCStatus.failedとotherInfo.extendedFailInfo.SKDFailInfo値でcMCStatusInfoExtを示す応答を返します。 さらに、signingTime属性は応答で含まれています。
2.d.2.b.1.b - Else if the names match, the GLA verifies the
member's encryption certificate.
2. d.2.b.1.b--ほかに、名前であるなら合ってください、そして、GLAはメンバーの暗号化証明書について確かめます。
2.d.2.b.1.b.1 - If the member's encryption certificate
cannot be verified, the GLA can return a
response indicating cMCStatusInfoExt with
cMCStatus.failed and
otherInfo.extendedFailInfo.SKDFailInfo
value of invalidCert to the GLO.
2. d.2.b.1.b.1--メンバーの暗号化証明書がそうすることができないなら、確かめられてください、そして、GLAはinvalidCertのcMCStatus.failedとotherInfo.extendedFailInfo.SKDFailInfo値でcMCStatusInfoExtをGLOに示す応答を返すことができます。
Turner Standards Track [Page 41] RFC 5275 CMS SymKeyDist June 2008
5275cmのターナー標準化過程[41ページ]RFC SymKeyDist2008年6月
Additionally, a signingTime attribute is
included with the response. If the GLA
does not return a
cMCStatusInfoExt.cMCStatus.failed
response, the GLA issues a glProvideCert
request (see Section 4.10).
さらに、signingTime属性は応答で含まれています。 GLAがcMCStatusInfoExt.cMCStatus.failed応答を返さないなら、GLAはglProvideCert要求を出します(セクション4.10を見てください)。
2.d.2.b.1.b.2 - Else if the member's certificate
verifies, the GLA returns a
cMCStatusInfoExt indicating
cMCStatus.success and a signingTime
attribute (2 in Figure 5). The GLA also
takes administrative actions, which are
beyond the scope of this document, to add
the member to the GL stored on the GLA.
The GLA also distributes the shared KEK
to the member via the mechanism described
in Section 5.
2. d.2.b.1.b.2--、ほか、GLAリターンa cMCStatusInfoExtがcMCStatus.successとsigningTime属性(図5の2)を示して、メンバーの証明書は確かめます。 また、GLAは管理行動を取ります。(GLAに格納されたGLにメンバーを加えるために、行動はこのドキュメントの範囲にあります)。 また、GLAはセクション5で説明されたメカニズムで共有されたKEKをメンバーに分配します。
2.d.2.b.1.b.2.a - The GLA applies confidentiality to
the response by encapsulating the
SignedData.PKIData in an
EnvelopedData if the request was
encapsulated in an EnvelopedData (see
Section 3.2.1.2).
セクション3.2を見てください。2. d.2.b.1.b.2.a、--、GLAが要求がEnvelopedDataで要約されたならEnvelopedDataでSignedData.PKIDataを要約することによって秘密性を応答に適用する(.1 .2)。
2.d.2.b.1.b.2.b - The GLA can also optionally apply
another SignedData over the
EnvelopedData (see Section 3.2.1.2).
セクション3.2を見てください。2. d.2.b.1.b.2.b、--、また、GLAが任意に別のSignedDataをEnvelopedDataの上に適用できる(.1 .2)。
2.d.2.b.2 - Else if the GL is managed, the GLA checks that
either a registered GLO or the prospective member
signed the request. For GLOs, one of the names
in the certificate used to sign the request needs
to match a registered GLO. For the prospective
member, the name in glMember.glMemberName needs
to match one of the names in the certificate used
to sign the request.
2.、d.2.b.2--ほかに、GLが管理されるなら、GLAは、登録されたGLOか将来のメンバーのどちらかが要求にサインしたのをチェックします。 GLOsのために、要求にサインするのに使用される証明書の名前のひとりは、登録されたGLOを合わせる必要があります。 将来のメンバーのために、glMember.glMemberNameの名前は、要求にサインするのに使用される証明書の名前の1つを合わせる必要があります。
2.d.2.b.2.a - If the signer is neither a registered GLO nor
the prospective GL member, the GLA returns a
response indicating cMCStatusInfoExt with
cMCStatus.failed and
otherInfo.extendedFailInfo.SKDFailInfo value
of noSpam. Additionally, a signingTime
attribute is included with the response.
2.、d.2.b.2.a--署名者が登録されたGLOでなくてまた将来のGLメンバーでないなら、GLAはnoSpamのcMCStatus.failedとotherInfo.extendedFailInfo.SKDFailInfo値でcMCStatusInfoExtを示す応答を返します。 さらに、signingTime属性は応答で含まれています。
Turner Standards Track [Page 42] RFC 5275 CMS SymKeyDist June 2008
5275cmのターナー標準化過程[42ページ]RFC SymKeyDist2008年6月
2.d.2.b.2.b - Else if the signer is a registered GLO, the
GLA verifies the member's encryption
certificate.
2.、d.2.b.2.b--ほかに、署名者が登録されたGLOであるなら、GLAはメンバーの暗号化証明書について確かめます。
2.d.2.b.2.b.1 - If the member's certificate cannot be
verified, the GLA can return a response
indicating cMCStatusInfoExt with
cMCStatus.failed and
otherInfo.extendedFailInfo.SKDFailInfo
value of invalidCert. Additionally, a
signingTime attribute is included with
the response. If the GLA does not return
a cMCStatus.failed response, the GLA MUST
issue a glProvideCert request (see
Section 4.10).
2. d.2.b.2.b.1--メンバーの証明書がそうすることができないなら、確かめられてください、そして、GLAはinvalidCertのcMCStatus.failedとotherInfo.extendedFailInfo.SKDFailInfo値でcMCStatusInfoExtを示す応答を返すことができます。 さらに、signingTime属性は応答で含まれています。 GLAがcMCStatus.failed応答を返さないなら、GLA MUSTはglProvideCert要求を出します(セクション4.10を見てください)。
2.d.2.b.2.b.2 - Else if the member's certificate
verifies, the GLA MUST return a
cMCStatusInfoExt indicating
cMCStatus.success and a signingTime
attribute to the GLO (2 in Figure 5).
The GLA also takes administrative
actions, which are beyond the scope of
this document, to add the member to the
GL stored on the GLA. The GLA also
distributes the shared KEK to the member
via the mechanism described in Section 5.
The GL policy may mandate that the GL
member's address be included in the GL
member's certificate.
2. d.2.b.2.b.2--、ほか、GLA MUSTリターンa cMCStatusInfoExtがGLO(図5の2)にcMCStatus.successとsigningTime属性を示して、メンバーの証明書は確かめます。 また、GLAは管理行動を取ります。(GLAに格納されたGLにメンバーを加えるために、行動はこのドキュメントの範囲にあります)。 また、GLAはセクション5で説明されたメカニズムで共有されたKEKをメンバーに分配します。 GL方針は、GLメンバーのアドレスがGLメンバーの証明書に含まれているのを強制するかもしれません。
2.d.2.b.2.b.2.a - The GLA applies confidentiality to
the response by encapsulating the
SignedData.PKIData in an
EnvelopedData if the request was
encapsulated in an EnvelopedData (see
Section 3.2.1.2).
セクション3.2を見てください。2. d.2.b.2.b.2.a、--、GLAが要求がEnvelopedDataで要約されたならEnvelopedDataでSignedData.PKIDataを要約することによって秘密性を応答に適用する(.1 .2)。
2.d.2.b.2.b.2.b - The GLA can also optionally apply
another SignedData over the
EnvelopedData (see Section 3.2.1.2).
セクション3.2を見てください。2. d.2.b.2.b.2.b、--、また、GLAが任意に別のSignedDataをEnvelopedDataの上に適用できる(.1 .2)。
2.d.2.b.2.c - Else if the signer is the prospective member,
the GLA forwards the glAddMember request (see
Section 3.2.3) to a registered GLO (B{A} in
Figure 5). If there is more than one
registered GLO, the GLO to which the request
is forwarded is beyond the scope of this
2.、d.2.b.2.c--ほかに、署名者が将来のメンバーであるなら、GLAはglAddMember要求(セクション3.2.3を見る)を登録されたGLO(図5のB A)に転送します。 1登録されたGLOがあれば、要求が転送されるGLOはこの範囲を超えています。
Turner Standards Track [Page 43] RFC 5275 CMS SymKeyDist June 2008
5275cmのターナー標準化過程[43ページ]RFC SymKeyDist2008年6月
document. Further processing of the
forwarded request by GLOs is addressed in 3
of Section 4.3.2.
記録します。 GLOsによる転送された要求のさらなる処理はセクション4.3.2の3で記述されます。
2.d.2.b.2.c.1 - The GLA applies confidentiality to the
forwarded request by encapsulating the
SignedData.PKIData in an EnvelopedData if
the original request was encapsulated in
an EnvelopedData (see Section 3.2.1.2).
セクション3.2を見てください。2. d.2.b.2.c.1、--、GLAがオリジナルの要求がEnvelopedDataで要約されたならEnvelopedDataでSignedData.PKIDataを要約することによって転送された要求に秘密性を適用する(.1 .2)。
2.d.2.b.2.c.2 - The GLA can also optionally apply another
SignedData over the EnvelopedData (see
Section 3.2.1.2).
セクション3.2を見てください。2. d.2.b.2.c.2、--、また、GLAが任意に別のSignedDataをEnvelopedDataの上に適用できる(.1 .2)。
2.d.2.b.3 - Else if the GL is unmanaged, the GLA checks that
either a registered GLO or the prospective member
signed the request. For GLOs, one of the names
in the certificate used to sign the request needs
to match the name of a registered GLO. For the
prospective member, the name in
glMember.glMemberName needs to match one of the
names in the certificate used to sign the
request.
2.、d.2.b.3--ほかに、GLが非管理されるなら、GLAは、登録されたGLOか将来のメンバーのどちらかが要求にサインしたのをチェックします。 GLOsのために、要求にサインするのに使用される証明書の名前のひとりは、登録されたGLOという名前を合わせる必要があります。 将来のメンバーのために、glMember.glMemberNameの名前は、要求にサインするのに使用される証明書の名前の1つを合わせる必要があります。
2.d.2.b.3.a - If the signer is neither a registered GLO nor
the prospective member, the GLA returns a
response indicating cMCStatusInfoExt with
cMCStatus.failed and
otherInfo.extendedFailInfo.SKDFailInfo value
of noSpam. Additionally, a signingTime
attribute is included with the response.
2.、d.2.b.3.a--署名者が登録されたGLOでなくてまた将来のメンバーでないなら、GLAはnoSpamのcMCStatus.failedとotherInfo.extendedFailInfo.SKDFailInfo値でcMCStatusInfoExtを示す応答を返します。 さらに、signingTime属性は応答で含まれています。
2.d.2.b.3.b - Else if the signer is either a registered GLO
or the prospective member, the GLA verifies
the member's encryption certificate.
2.、d.2.b.3.b--ほかに、署名者が登録されたGLOか将来のメンバーのどちらかであるなら、GLAはメンバーの暗号化証明書について確かめます。
2.d.2.b.3.b.1 - If the member's certificate cannot be
verified, the GLA can return a response
indicating cMCStatusInfoExt with
cMCStatus.failed and
otherInfo.extendedFailInfo.SKDFailInfo
value of invalidCert and a signingTime
attribute to either the GLO or the
prospective member depending on where the
request originated. If the GLA does not
return a cMCStatus.failed response, the
GLA issues a glProvideCert request (see
2. d.2.b.3.b.1--メンバーの証明書がそうすることができないなら、確かめられてください、そして、GLAはinvalidCertのcMCStatus.failedとotherInfo.extendedFailInfo.SKDFailInfo値とGLOか将来のメンバーのどちらかへのsigningTime属性を要求が由来したところに依存している状態でcMCStatusInfoExtを示す応答を返すことができます。 GLAがcMCStatus.failed応答を返さないなら、GLAがglProvideCert要求を出す、(見る。
Turner Standards Track [Page 44] RFC 5275 CMS SymKeyDist June 2008
5275cmのターナー標準化過程[44ページ]RFC SymKeyDist2008年6月
Section 4.10) to either the GLO or
prospective member depending on where the
request originated.
セクション4.10) GLOかどこを当てにする将来のメンバーのどちらかに、要求は由来しました。
2.d.2.b.3.b.2 - Else if the member's certificate
verifies, the GLA returns a
cMCStatusInfoExt indicating
cMCStatus.success and a signingTime
attribute to the GLO (2 in Figure 5) if
the GLO signed the request and to the GL
member (3 in Figure 5) if the GL member
signed the request. The GLA also takes
administrative actions, which are beyond
the scope of this document, to add the
member to the GL stored on the GLA. The
GLA also distributes the shared KEK to
the member via the mechanism described in
Section 5.
2. d.2.b.3.b.2--、ほか、GLメンバーが要求にサインしたならGLOが要求とGLメンバー(図5の3)にサインしたならGLAリターンa cMCStatusInfoExtがGLO(図5の2)にcMCStatus.successとsigningTime属性を示して、メンバーの証明書は確かめます。 また、GLAは管理行動を取ります。(GLAに格納されたGLにメンバーを加えるために、行動はこのドキュメントの範囲にあります)。 また、GLAはセクション5で説明されたメカニズムで共有されたKEKをメンバーに分配します。
2.d.2.b.3.b.2.a - The GLA applies confidentiality to
the response by encapsulating the
SignedData.PKIData in an
EnvelopedData if the request was
encapsulated in an EnvelopedData (see
Section 3.2.1.2).
セクション3.2を見てください。2. d.2.b.3.b.2.a、--、GLAが要求がEnvelopedDataで要約されたならEnvelopedDataでSignedData.PKIDataを要約することによって秘密性を応答に適用する(.1 .2)。
2.d.2.b.3.b.2.b - The GLA can also optionally apply
another SignedData over the
EnvelopedData (see Section 3.2.1.2).
セクション3.2を見てください。2. d.2.b.3.b.2.b、--、また、GLAが任意に別のSignedDataをEnvelopedDataの上に適用できる(.1 .2)。
3 - Upon receipt of the cMCStatusInfoExt response, the GLO checks the
signingTime and verifies the GLA signature(s). If an additional
SignedData and/or EnvelopedData encapsulates the response (see
Section 3.2.1.2 or 3.2.2), the GLO verifies the outer signature
and/or decrypts the outer layer prior to verifying the signature
on the innermost SignedData.
3--cMCStatusInfoExt応答を受け取り次第、GLOはsigningTimeをチェックして、GLA署名について確かめます。 または、追加SignedData、そして/または、EnvelopedDataが応答を要約する、(セクション3.2.1を見てください、.2、3.2 .2) 最も奥深いSignedDataで署名について確かめる前に、GLOは外側の署名について確かめる、そして/または、外側の層を解読します。
3.a - If the signingTime attribute value is not within the locally
accepted time window, the GLO MAY return a response
indicating cMCStatus.failed and otherInfo.failInfo.badTime
and a signingTime attribute.
3. a--signingTimeであるなら値を結果と考えてください。局所的に受け入れられたタイムウィンドウ、cMCStatus.failedとotherInfo.failInfo.badTimeを示すGLO MAYリターンa応答、およびsigningTime属性の中にありません。
3.b - Else if signature processing continues and if the signatures
verify, the GLO checks that one of the names in the
certificate used to sign the response matches the name of the
GL.
3. b--、ほか、署名処理が続いて、署名である、検証、GLOは、応答にサインするのに使用される証明書の名前の1つがGLという名前に合っているのをチェックします。
Turner Standards Track [Page 45] RFC 5275 CMS SymKeyDist June 2008
5275cmのターナー標準化過程[45ページ]RFC SymKeyDist2008年6月
3.b.1 - If the name of the GL does not match the name present in
the certificate used to sign the message, the GLO should
not believe the response.
3. b.1--GLという名前がそうしないなら、現在という名前を合わせてください。証明書には、メッセージは以前はよくサインしていました、とGLOが応答を信じているはずがありません。
3.b.2 - Else if the name of the GL matches the name present in
the certificate and:
そして、3. b.2--GLという名前が名前に合っているならほかに、中に証明書を提示してください、:
3.b.2.a - If the signatures verify and the response is
cMCStatusInfoExt indicating cMCStatus.success, the
GLA has added the member to the GL. If the member
was added to a managed list and the original request
was signed by the member, the GLO sends a
cMCStatusInfoExt.cMCStatus.success and a signingTime
attribute to the GL member.
そして、3. b.2.a、署名である、確かめ、応答がcMCStatus.successを示すcMCStatusInfoExtである、GLAはGLにメンバーを加えました。 メンバーが管理されたリストに追加されて、オリジナルの要求がメンバーによってサインされたなら、GLOはcMCStatusInfoExt.cMCStatus.successとsigningTime属性をGLメンバーに送ります。
3.b.2.b - Else if the GLO received a
cMCStatusInfoExt.cMCStatus.failed with any reason,
the GLO can reattempt to add the member to the GL
using the information provided in the response.
3. b.2.b--GLOがいずれかでcMCStatusInfoExt.cMCStatus.failedを受けたなら、ほかに、推論してください、そして、GLOは、応答に提供された情報を使用することでGLにメンバーを加えるために「再-試み」ることができます。
4 - Upon receipt of the cMCStatusInfoExt response, the prospective
member checks the signingTime and verifies the GLA signatures or
GLO signatures. If an additional SignedData and/or EnvelopedData
encapsulates the response (see Section 3.2.1.2 or 3.2.2), the GLO
verifies the outer signature and/or decrypts the outer layer
prior to verifying the signature on the innermost SignedData.
cMCStatusInfoExt応答を受け取り次第4、将来のメンバーはsigningTimeをチェックして、GLA署名かGLO署名について確かめます。 または、追加SignedData、そして/または、EnvelopedDataが応答を要約する、(セクション3.2.1を見てください、.2、3.2 .2) 最も奥深いSignedDataで署名について確かめる前に、GLOは外側の署名について確かめる、そして/または、外側の層を解読します。
4.a - If the signingTime attribute value is not within the locally
accepted time window, the prospective member MAY return a
response indicating cMCStatus.failed and
otherInfo.failInfo.badTime and a signingTime attribute.
4. a--signingTimeであるなら値を結果と考えてください。局所的に受け入れられたタイムウィンドウ、cMCStatus.failedとotherInfo.failInfo.badTimeを示す将来のメンバー5月のリターンa応答、およびsigningTime属性の中にありません。
4.b - Else if signature processing continues and if the signatures
verify, the GL member checks that one of the names in the
certificate used to sign the response matches the name of the
GL.
4. b--、ほか、署名処理が続いて、署名である、検証、GLメンバーは、応答にサインするのに使用される証明書の名前の1つがGLという名前に合っているのをチェックします。
4.b.1 - If the name of the GL does not match the name present in
the certificate used to sign the message, the GL member
should not believe the response.
4. b.1--GLという名前がそうしないなら、名前を合わせてください。メッセージにサインするのに使用される証明書に存在しています、GLメンバーは応答を信じるべきではありません。
4.b.2 - Else if the name of the GL matches the name present in the
certificate and:
そして、4. b.2--GLという名前が名前に合っているならほかに、中に証明書を提示してください、:
4.b.2.a - If the signatures verify, the prospective member has
been added to the GL.
4. b.2.a--、署名が確かめる、将来のメンバーはGLに加えられます。
Turner Standards Track [Page 46] RFC 5275 CMS SymKeyDist June 2008
5275cmのターナー標準化過程[46ページ]RFC SymKeyDist2008年6月
4.b.2.b - Else if the prospective member received a
cMCStatusInfoExt.cMCStatus.failed, for any reason,
the prospective member MAY reattempt to add itself to
the GL using the information provided in the
response.
4. b.2.b--将来のメンバーがcMCStatusInfoExt.cMCStatus.failedを受け取ったなら、ほかに、いずれに関しても、推論してください、そして、情報を使用することでGLにそれ自体を加える将来のメンバー5月の「再-試み」は応答に提供しました。
4.3.2. Prospective Member Initiated Additions
4.3.2. 将来のメンバー開始している追加
The process for prospective member initiated glAddMember requests is as follows:
将来のメンバー開始しているglAddMember要求のための過程は以下の通りです:
1 - The prospective GL member sends a
SignedData.PKIData.controlSequence.glAddMember request to the GLA
(A in Figure 5). The prospective GL member includes: the GL name
in glName, their name in glMember.glMemberName, their address in
glMember.glMemberAddress, and their encryption certificate in
glMember.certificates.pKC. The prospective GL member can also
include any attribute certificates associated with their
encryption certificate in glMember.certificates.aC, and the
certification path associated with their encryption and attribute
certificates in glMember.certificates.certPath. The prospective
member MUST also include the signingTime attribute with this
request.
1--将来のGLメンバーはGLA(図5のA)にSignedData.PKIData.controlSequence.glAddMember要求を送ります。 将来のGLメンバーは: glNameのGL名、glMember.glMemberNameのそれらの名前、glMember.glMemberAddressのそれらのアドレス、およびglMember.certificates.pKCの彼らの暗号化証明書。 また、将来のGLメンバーはglMember.certificates.aCのそれらの暗号化証明書と彼らの暗号化に関連している証明経路とglMember.certificates.certPathの属性証明書に関連しているどんな属性証明書も入れることができます。 また、将来のメンバーはこの要求があるsigningTime属性を入れなければなりません。
1.a - The prospective GL member can optionally apply
confidentiality to the request by encapsulating the
SignedData.PKIData in an EnvelopedData (see Section 3.2.1.2).
セクション3.2を見てください。1. a--メンバーがEnvelopedDataでSignedData.PKIDataを要約しながら任意に要求への秘密性を適用できる将来のGL、(.1 .2)。
1.b - The prospective GL member MAY optionally apply another
SignedData over the EnvelopedData (see Section 3.2.1.2).
セクション3.2を見てください。1. b、--、将来のGLメンバーが任意に別のSignedDataをEnvelopedDataの上に適用するかもしれない(.1 .2)。
2 - Upon receipt of the request, the GLA verifies the request as per
2 in Section 4.3.1.
2--要求を受け取り次第、GLAはセクション4.3.1における2に従って要求について確かめます。
3 - Upon receipt of the forwarded request, the GLO checks the
signingTime and verifies the prospective GL member signature on
the innermost SignedData.PKIData and the GLA signature on the
outer layer. If an EnvelopedData encapsulates the innermost
layer (see Section 3.2.1.2 or 3.2.2), the GLO decrypts the outer
layer prior to verifying the signature on the innermost
SignedData.
転送された要求を受け取り次第3、GLOは最も奥深いSignedData.PKIDataとGLA署名のときに外側の層でsigningTimeをチェックして、将来のGLメンバー署名について確かめます。 または、EnvelopedDataが最内の層をカプセルに入れる、(セクション3.2.1を見てください、.2、3.2 .2) 最も奥深いSignedDataで署名について確かめる前に、GLOは外側の層を解読します。
Note: For cases where the GL is closed and either a) a
prospective member sends directly to the GLO or b) the GLA has
mistakenly forwarded the request to the GLO, the GLO should first
determine whether to honor the request.
以下に注意してください。 GLが終えられて、将来のメンバーが直接GLOに送るa)かbのどちらか) GLAが要求をGLOに誤って転送したケースのために、GLOは、最初に、要求を光栄に思うかどうか決定するはずです。
Turner Standards Track [Page 47] RFC 5275 CMS SymKeyDist June 2008
5275cmのターナー標準化過程[47ページ]RFC SymKeyDist2008年6月
3.a - If the signingTime attribute value is not within the locally
accepted time window, the GLO MAY return a response
indicating cMCStatus.failed and otherInfo.failInfo.badTime.
3. a--signingTimeであるなら値を結果と考えてください。GLO MAYリターンの局所的に受け入れられたタイムウィンドウ、cMCStatus.failedを示す応答、およびotherInfo.failInfo.badTimeの中にありません。
3.b - Else if signature processing continues and if the signatures
verify, the GLO checks to make sure one of the names in the
certificate used to sign the request matches the name in
glMember.glMemberName.
3. b--、ほか、署名処理が続いて、署名である、検証、GLOは、要求にサインするのに使用される証明書の名前の1つがglMember.glMemberNameの名前に合っているのを確実にするためにチェックします。
3.b.1 - If the names do not match, the GLO sends a
SignedData.PKIResponse.controlSequence message back to
the prospective member with
cMCStatusInfoExt.cMCStatus.failed indicating why the
prospective member was denied in
cMCStausInfo.statusString. This stops people from adding
people to GLs without their permission. Additionally, a
signingTime attribute is included with the response.
3. b.1--名前であるなら合わないでください、そして、GLOは将来のメンバーがなぜcMCStausInfo.statusStringで否定されたかを示すcMCStatusInfoExt.cMCStatus.failedの将来のメンバーにSignedData.PKIResponse.controlSequenceメッセージを送り返します。 これによって、人々は彼らの許可なしでGLsに人々を加えることができません。 さらに、signingTime属性は応答で含まれています。
3.b.2 - Else if the names match, the GLO determines whether the
prospective member is allowed to be added. The mechanism
is beyond the scope of this document; however, the GLO
should check to see that the glMember.glMemberName is not
already on the GL.
3. b.2--ほかに、名前であるなら合ってください、そして、GLOは、将来のメンバーが加えることができるかどうか決定します。 メカニズムはこのドキュメントの範囲を超えています。 しかしながら、GLOは、glMember.glMemberNameがGLに既にないことを確認するためにチェックするはずです。
3.b.2.a - If the GLO determines the prospective member is not
allowed to join the GL, the GLO can return a
SignedData.PKIResponse.controlSequence message back
to the prospective member with
cMCStatusInfoExt.cMCtatus.failed indicating why the
prospective member was denied in
cMCStatus.statusString. Additionally, a signingTime
attribute is included with the response.
3. b.2.a--GLOが、将来のメンバーが許容されていないことを決定するなら、GLに加わってください、そして、GLOは将来のメンバーがなぜcMCStatus.statusStringで否定されたかを示すcMCStatusInfoExt.cMCtatus.failedの将来のメンバーにSignedData.PKIResponse.controlSequenceメッセージを返して戻すことができます。 さらに、signingTime属性は応答で含まれています。
3.b.2.b - Else if the GLO determines the prospective member is
allowed to join the GL, the GLO verifies the member's
encryption certificate.
3. b.2.b--GLOが、将来のメンバーが許容されていることを決定するなら、ほかに、GLを接合してください、そして、GLOはメンバーの暗号化証明書について確かめます。
3.b.2.b.1 - If the member's certificate cannot be verified,
the GLO returns a
SignedData.PKIResponse.controlSequence back to
the prospective member with
cMCStatusInfoExt.cMCtatus.failed indicating that
the member's encryption certificate did not
verify in cMCStatus.statusString. Additionally,
a signingTime attribute is included with the
response. If the GLO does not return a
cMCStatusInfoExt response, the GLO sends a
3. b.2.b.1--メンバーの証明書がそうすることができないなら、確かめられてください、そして、GLOはメンバーの暗号化証明書がcMCStatus.statusStringで確かめなかったcMCStatusInfoExt.cMCtatus.failed表示と共に将来のメンバーにSignedData.PKIResponse.controlSequenceを返して戻します。 さらに、signingTime属性は応答で含まれています。 GLOがcMCStatusInfoExt応答を返さないなら、GLOはaを送ります。
Turner Standards Track [Page 48] RFC 5275 CMS SymKeyDist June 2008
5275cmのターナー標準化過程[48ページ]RFC SymKeyDist2008年6月
SignedData.PKIData.controlSequence.glProvideCert
message to the prospective member requesting a
new encryption certificate (see Section 4.10).
新しい暗号化証明書(セクション4.10を見る)を要求する将来のメンバーへのSignedData.PKIData.controlSequence.glProvideCertメッセージ。
3.b.2.b.2 - Else if the member's certificate verifies, the
GLO resubmits the glAddMember request (see
Section 3.2.5) to the GLA (1 in Figure 5).
3. b.2.b.2--、ほか、メンバーの証明書が確かめる、GLOはglAddMember要求(セクション3.2.5を見る)をGLA(図5の1)に再提出します。
3.b.2.b.2.a - The GLO applies confidentiality to the new
GLAddMember request by encapsulating the
SignedData.PKIData in an EnvelopedData if the
initial request was encapsulated in an
EnvelopedData (see Section 3.2.1.2).
セクション3.2を見てください。3. b.2.b.2.a、--、GLOが初期の要求がEnvelopedDataで要約されたならEnvelopedDataでSignedData.PKIDataを要約することによって新しいGLAddMember要求に秘密性を適用する(.1 .2)。
3.b.2.b.2.b - The GLO can also optionally apply another
SignedData over the EnvelopedData (see
Section 3.2.1.2).
セクション3.2を見てください。3. b.2.b.2.b、--、また、GLOが任意に別のSignedDataをEnvelopedDataの上に適用できる(.1 .2)。
4 - Processing continues as in 2 of Section 4.3.1.
4--処理はセクション4.3.1の2のように続きます。
4.4. Delete Members from GL
4.4. GLからメンバーを削除してください。
To delete members from GLs, either the GLO or members to be removed use the glDeleteMember request. The GLA processes the GLO, and members requesting their own removal make requests differently. The GLO can submit the request at any time to delete members from the GL, and the GLA, once it has verified the request came from a registered GLO, should delete the member. If a member sends the request, the GLA needs to determine how the GL is administered. When the GLO initially configured the GL, it set the GL to be unmanaged, managed, or closed (see Section 3.1.1). In the unmanaged case, the GLA merely processes the member's request. In the managed case, the GLA forwards the requests from the member to the GLO for review. Where there are multiple GLOs for a GL, which GLO the request is forwarded to is beyond the scope of this document. The GLO reviews the request and either rejects it or submits a reformed request to the GLA. In the closed case, the GLA will not accept requests from members. The following sections describe the processing for the GLO(s), GLA, and GL members depending on where the request originated, either from a GLO or from members wanting to be removed. Figure 6 depicts the protocol interactions for the three options. Note that the error messages are not depicted. Additionally, behavior for the optional transactionId, senderNonce, and recipientNonce CMC control attributes is not addressed in these procedures.
GLsからメンバーを削除するために、GLOか取り除かれるべきメンバーのどちらかがglDeleteMember要求を使用します。 GLAはGLOを処理します、そして、それら自身の取り外しを要求するメンバーが異なって要求をします。 GLOはいつでもGL、およびGLAからメンバーを削除するために要求を提出できて、いったんそうすると、要求は登録されたGLOから確かめられる状態で来て、メンバーを削除するべきです。 メンバーが要求を送るなら、GLAは、GLがどのように管理されるかを決定する必要があります。 GLOが初めはGLを構成したとき、それは、GLに非管理されるか、管理されるか、または閉じられるように設定しました(セクション3.1.1を見てください)。 非管理された場合では、GLAは単にメンバーの要求を処理します。 管理された場合では、GLAはレビューのためにメンバーからGLOまでの要求を転送します。 GLのための複数のGLOsがあるところでは、どのGLOに要求を転送するかはこのドキュメントの範囲を超えています。 GLOはGLAに要求を再検討して、それを拒絶するか、または改革された要求を提出します。 閉じている場合では、GLAはメンバーから要求を受け入れないでしょう。 以下のセクションは要求がGLO、または、取り除かれたいメンバーから由来したところを当てにするGLO(s)、GLA、およびGLメンバーのための処理について説明します。 図6は3つのオプションのためにプロトコル相互作用について表現します。 エラーメッセージが表現されないことに注意してください。 さらに、任意のtransactionId、senderNonce、およびrecipientNonce CMCコントロール属性のための振舞いはこれらの手順で記述されません。
Turner Standards Track [Page 49] RFC 5275 CMS SymKeyDist June 2008
5275cmのターナー標準化過程[49ページ]RFC SymKeyDist2008年6月
+-----+ 2,B{A} 3 +----------+
| GLO | <--------+ +-------> | Member 1 |
+-----+ | | +----------+
1 | |
+-----+ <--------+ | 3 +----------+
| GLA | A +-------> | ... |
+-----+ <-------------+ +----------+
|
| 3 +----------+
+-------> | Member n |
+----------+
+-----+ 2、Bは3+です。----------+ | GLO| <、-、-、-、-、-、-、--+ +------->| メンバー1| +-----+ | | +----------+ 1 | | +-----+ <。--------+ | 3 +----------+ | GLA| +------->| ... | +-----+ <。-------------+ +----------+ | | 3 +----------+ +------->| メンバーn| +----------+
Figure 6 - Member Deletion
図6--メンバー削除
If the member is not removed from the GL, it will continue to receive and be able to decrypt data protected with the shared KEK and will continue to receive rekeys. For unmanaged lists, there is no point to a group rekey because there is no guarantee that the member requesting to be removed has not already added itself back on the GL under a different name. For managed and closed GLs, the GLO needs to take steps to ensure that the member being deleted is not on the GL twice. After ensuring this, managed and closed GLs can be rekeyed to maintain the confidentiality of the traffic sent by group members. If the GLO is sure the member has been deleted, the group rekey mechanism can be used to distribute the new key (see Sections 4.5 and 5).
メンバーがGLから免職されないと、それは、受信して、共有されたKEKと共に保護されたデータは解読することができ続けて、「再-キー」を受け取り続けるでしょう。 非管理されたリストのために、取り除かれるべきメンバー要求がGLで異なった名前の下で既にそれ自体を加えていないという保証が全くないので、グループrekeyへのポイントは全くありません。 管理されて閉じているGLsのために、GLOは、削除されるメンバーがGLに二度いないのを保証するために手を打つ必要があります。 これを確実にした後に、グループのメンバーによって送られた交通の秘密性を維持するために管理されて閉じているGLsを「再-合わせ」ることができます。 GLOがメンバーが削除されたのを確信しているなら、新しいキーを分配するのにグループrekeyメカニズムを使用できます(セクション4.5と5を見てください)。
4.4.1. GLO Initiated Deletions
4.4.1. GLOは削除を開始しました。
The process for GLO initiated glDeleteMember requests is as follows:
GLOがglDeleteMember要求を開始したので、過程は以下の通りです:
1 - The GLO collects the pertinent information for the member(s) to
be deleted (this can be done through an out-of-band means). The
GLO then sends a SignedData.PKIData.controlSequence with a
separate glDeleteMember request for each member to the GLA (1 in
Figure 6). The GLO MUST include the GL name in glName and the
member's name in glMemberToDelete. If the GL from which the
member is being deleted is a closed or managed GL, the GLO MUST
also generate a glRekey request and include it with the
glDeletemember request (see Section 4.5). The GLO MUST also
include the signingTime attribute with this request.
1--GLOは、メンバーが削除されるために適切な情報を集めます(バンドで出ている手段でこれができます)。 そしてGLOは各メンバーを求める別々のglDeleteMember要求と共にGLA(図6の1)にSignedData.PKIData.controlSequenceを送ります。 GLO MUSTはglMemberToDeleteのglNameとメンバーの名前にGL名を含んでいます。 メンバーが削除されているGLが閉じているか管理されたGLであるなら、GLO MUSTはまた、glRekey要求を発生させて、glDeletemember要求でそれを含んでいます(セクション4.5を見てください)。 また、GLO MUSTはこの要求があるsigningTime属性を含んでいます。
1.a - The GLO can optionally apply confidentiality to the request
by encapsulating the SignedData.PKIData in an EnvelopedData
(see Section 3.2.1.2).
セクション3.2を見てください。1. a--缶がEnvelopedDataでSignedData.PKIDataを要約しながら任意に要求への秘密性を適用するGLO、(.1 .2)。
1.b - The GLO can also optionally apply another SignedData over the
EnvelopedData (see Section 3.2.1.2).
セクション3.2を見てください。1. b、--、また、GLOが任意に別のSignedDataをEnvelopedDataの上に適用できる(.1 .2)。
Turner Standards Track [Page 50] RFC 5275 CMS SymKeyDist June 2008
5275cmのターナー標準化過程[50ページ]RFC SymKeyDist2008年6月
2 - Upon receipt of the request, the GLA checks the signingTime
attribute and verifies the signature on the innermost
SignedData.PKIData. If an additional SignedData and/or
EnvelopedData encapsulates the request (see Section 3.2.1.2 or
3.2.2), the GLA verifies the outer signature and/or decrypts the
outer layer prior to verifying the signature on the innermost
SignedData.
要求を受け取り次第2、GLAはsigningTime属性をチェックして、最も奥深いSignedData.PKIDataで署名について確かめます。 または、追加SignedData、そして/または、EnvelopedDataが要求を要約する、(セクション3.2.1を見てください、.2、3.2 .2) 最も奥深いSignedDataで署名について確かめる前に、GLAは外側の署名について確かめる、そして/または、外側の層を解読します。
2.a - If the signingTime attribute value is not within the locally
accepted time window, the GLA MAY return a response
indicating cMCStatus.failed and otherInfo.failInfo.badTime
and a signingTime attribute.
2. a--signingTimeであるなら値を結果と考えてください。局所的に受け入れられたタイムウィンドウ、cMCStatus.failedとotherInfo.failInfo.badTimeを示すGLA MAYリターンa応答、およびsigningTime属性の中にありません。
2.b - Else if signature processing continues and if the signatures
cannot be verified, the GLA returns a cMCStatusInfoExt
response indicating cMCStatus.failed and
otherInfo.failInfo.badMessageCheck. Additionally, a
signingTime attribute is included with the response.
2. b--署名処理が続いて、署名がそうすることができないなら、ほかに、確かめられてください、そして、GLAはcMCStatus.failedとotherInfo.failInfo.badMessageCheckを示すcMCStatusInfoExt応答を返します。 さらに、signingTime属性は応答で含まれています。
2.c - Else if the signatures verify, the GLA makes sure the GL is
supported by the GLA by checking that the glName matches a
glName stored on the GLA.
2. c--、ほか、glNameマッチa glNameがGLAに格納したGLがGLAによって支持されるのを確信しているGLA造がチェックして、署名は確かめます。
2.c.1 - If the glName is not supported by the GLA, the GLA
returns a response indicating cMCStatusInfoExt with
cMCStatus.failed and
otherInfo.extendedFailInfo.SKDFailInfo value of
invalidGLName. Additionally, a signingTime attribute is
included with the response.
2.、c.1--glNameがGLAによって支持されないなら、GLAはinvalidGLNameのcMCStatus.failedとotherInfo.extendedFailInfo.SKDFailInfo値でcMCStatusInfoExtを示す応答を返します。 さらに、signingTime属性は応答で含まれています。
2.c.2 - Else if the glName is supported by the GLA, the GLA
checks to see if the glMemberName is present on the GL.
2.、c.2--ほかに、glNameがGLAによって支持されるなら、GLAは、glMemberNameがGLに存在しているかどうか確認するためにチェックします。
2.c.2.a - If the glMemberName is not present on the GL, the GLA
returns a response indicating cMCStatusInfoExt with
cMCStatus.failed and
otherInfo.extendedFailInfo.SKDFailInfo value of
notAMember. Additionally, a signingTime attribute is
included with the response.
2. c.2.a--glMemberNameがそうでないならGL、GLAにリターンを提示してください。cMCStatus.failedと共にcMCStatusInfoExtを示す応答とnotAMemberのotherInfo.extendedFailInfo.SKDFailInfo値。 さらに、signingTime属性は応答で含まれています。
2.c.2.b - Else if the glMemberName is already on the GL, the
GLA checks how the GL is administered.
2.、c.2.b--ほかに、glMemberNameがGLに既にあるなら、GLAはGLがどう管理されるかをチェックします。
2.c.2.b.1 - If the GL is closed, the GLA checks that the
registered GLO signed the request by checking
that one of the names in the digital signature
certificate used to sign the request matches the
registered GLO.
2.、c.2.b.1--GLが閉じられるなら、GLAは、要求にサインするのに使用されるデジタル署名証明書の名前の1つが登録されたGLOに合っているのをチェックすることによって登録されたGLOが要求にサインしたのをチェックします。
Turner Standards Track [Page 51] RFC 5275 CMS SymKeyDist June 2008
5275cmのターナー標準化過程[51ページ]RFC SymKeyDist2008年6月
2.c.2.b.1.a - If the names do not match, the GLA returns a
response indicating cMCStatusInfoExt with
cMCStatus.failed and
otherInfo.extendedFailInfo.SKDFailInfo value
of closedGL. Additionally, a signingTime
attribute is included with the response.
2. c.2.b.1.a--名前であるなら合わないでください、そして、GLAはclosedGLのcMCStatus.failedとotherInfo.extendedFailInfo.SKDFailInfo値でcMCStatusInfoExtを示す応答を返します。 さらに、signingTime属性は応答で含まれています。
2.c.2.b.1.b - Else if the names do match, the GLA returns a
cMCStatusInfoExt.cMCStatus.success and a
signingTime attribute (2 in Figure 5). The
GLA also takes administrative actions, which
are beyond the scope of this document, to
delete the member with the GL stored on the
GLA. Note that the GL also needs to be
rekeyed as described in Section 5.
2. c.2.b.1.b--ほかに、名前であるならマッチ、GLAリターンにcMCStatusInfoExt.cMCStatus.successとsigningTime属性をしてください(図5の2)。 また、GLAは管理行動を取ります。(GLAに格納されるGLのメンバーを削除するために、行動はこのドキュメントの範囲にあります)。 また、GLが、セクション5で説明されるように「再-合わせ」られる必要に注意してください。
2.c.2.b.1.b.1 - The GLA applies confidentiality to the
response by encapsulating the
SignedData.PKIData in an EnvelopedData if
the request was encapsulated in an
EnvelopedData (see Section 3.2.1.2).
セクション3.2を見てください。2. c.2.b.1.b.1、--、GLAが要求がEnvelopedDataで要約されたならEnvelopedDataでSignedData.PKIDataを要約することによって秘密性を応答に適用する(.1 .2)。
2.c.2.b.1.b.2 - The GLA can also optionally apply another
SignedData over the EnvelopedData (see
Section 3.2.1.2).
セクション3.2を見てください。2. c.2.b.1.b.2、--、また、GLAが任意に別のSignedDataをEnvelopedDataの上に適用できる(.1 .2)。
2.c.2.b.2 - Else if the GL is managed, the GLA checks that
either a registered GLO or the prospective member
signed the request. For GLOs, one of the names
in the certificate used to sign the request needs
to match a registered GLO. For the prospective
member, the name in glMember.glMemberName needs
to match one of the names in the certificate used
to sign the request.
2.、c.2.b.2--ほかに、GLが管理されるなら、GLAは、登録されたGLOか将来のメンバーのどちらかが要求にサインしたのをチェックします。 GLOsのために、要求にサインするのに使用される証明書の名前のひとりは、登録されたGLOを合わせる必要があります。 将来のメンバーのために、glMember.glMemberNameの名前は、要求にサインするのに使用される証明書の名前の1つを合わせる必要があります。
2.c.2.b.2.a - If the signer is neither a registered GLO nor
the prospective GL member, the GLA returns a
response indicating cMCStatusInfoExt with
cMCStatus.failed and
otherInfo.extendedFailInfo.SKDFailInfo value
of noSpam. Additionally, a signingTime
attribute is included with the response.
2.、c.2.b.2.a--署名者が登録されたGLOでなくてまた将来のGLメンバーでないなら、GLAはnoSpamのcMCStatus.failedとotherInfo.extendedFailInfo.SKDFailInfo値でcMCStatusInfoExtを示す応答を返します。 さらに、signingTime属性は応答で含まれています。
2.c.2.b.2.b - Else if the signer is a registered GLO, the
GLA returns a
cMCStatusInfoExt.cMCStatus.success and a
signingTime attribute(2 in Figure 6). The
GLA also takes administrative actions, which
2.、c.2.b.2.b--ほかに、署名者が登録されたGLOであるなら、GLAはcMCStatusInfoExt.cMCStatus.successとsigningTime属性(図6の2)を返します。 また、GLAが管理行動を取る、どれ
Turner Standards Track [Page 52] RFC 5275 CMS SymKeyDist June 2008
5275cmのターナー標準化過程[52ページ]RFC SymKeyDist2008年6月
are beyond the scope of this document, to
delete the member with the GL stored on the
GLA. Note that the GL will also be rekeyed
as described in Section 5.
GLAに格納されるGLのメンバーを削除するためにこのドキュメントの範囲を超えています。 また、GLがセクション5で説明されるように「再-合わせ」られることに注意してください。
2.c.2.b.2.b.1 - The GLA applies confidentiality to the
response by encapsulating the
SignedData.PKIData in an EnvelopedData if
the request was encapsulated in an
EnvelopedData (see Section 3.2.1.2).
セクション3.2を見てください。2. c.2.b.2.b.1、--、GLAが要求がEnvelopedDataで要約されたならEnvelopedDataでSignedData.PKIDataを要約することによって秘密性を応答に適用する(.1 .2)。
2.c.2.b.2.b.2 - The GLA can also optionally apply another
SignedData over the EnvelopedData (see
Section 3.2.1.2).
セクション3.2を見てください。2. c.2.b.2.b.2、--、また、GLAが任意に別のSignedDataをEnvelopedDataの上に適用できる(.1 .2)。
2.c.2.b.2.c - Else if the signer is the prospective member,
the GLA forwards the glDeleteMember request
(see Section 3.2.3) to the GLO (B{A} in
Figure 6). If there is more than one
registered GLO, the GLO to which the request
is forwarded to is beyond the scope of this
document. Further processing of the
forwarded request by GLOs is addressed in 3
of Section 4.4.2.
2.、c.2.b.2.c--ほかに、署名者が将来のメンバーであるなら、GLAはglDeleteMember要求(セクション3.2.3を見る)をGLO(図6のB A)に転送します。 以上が1登録されたGLO、GLOよりあれば、要求をどれに転送するかに、このドキュメントの範囲が向こうにあります。 GLOsによる転送された要求のさらなる処理はセクション4.4.2の3で記述されます。
2.c.2.b.2.c.1 - The GLA applies confidentiality to the
forwarded request by encapsulating the
SignedData.PKIData in an EnvelopedData if
the request was encapsulated in an
EnvelopedData (see Section 3.2.1.2).
セクション3.2を見てください。2. c.2.b.2.c.1、--、GLAが要求がEnvelopedDataで要約されたならEnvelopedDataでSignedData.PKIDataを要約することによって転送された要求に秘密性を適用する(.1 .2)。
2.c.2.b.2.c.2 - The GLA can also optionally apply another
SignedData over the EnvelopedData (see
Section 3.2.1.2).
セクション3.2を見てください。2. c.2.b.2.c.2、--、また、GLAが任意に別のSignedDataをEnvelopedDataの上に適用できる(.1 .2)。
2.c.2.b.3 - Else if the GL is unmanaged, the GLA checks that
either a registered GLO or the prospective member
signed the request. For GLOs, one of the names
in the certificate used to sign the request needs
to match the name of a registered GLO. For the
prospective member, the name in
glMember.glMemberName needs to match one of the
names in the certificate used to sign the
request.
2.、c.2.b.3--ほかに、GLが非管理されるなら、GLAは、登録されたGLOか将来のメンバーのどちらかが要求にサインしたのをチェックします。 GLOsのために、要求にサインするのに使用される証明書の名前のひとりは、登録されたGLOという名前を合わせる必要があります。 将来のメンバーのために、glMember.glMemberNameの名前は、要求にサインするのに使用される証明書の名前の1つを合わせる必要があります。
Turner Standards Track [Page 53] RFC 5275 CMS SymKeyDist June 2008
5275cmのターナー標準化過程[53ページ]RFC SymKeyDist2008年6月
2.c.2.b.3.a - If the signer is neither the GLO nor the
prospective member, the GLA returns a
response indicating cMCStatusInfoExt with
cMCStatus.failed and
otherInfo.extendedFailInfo.SKDFailInfo value
of noSpam. Additionally, a signingTime
attribute is included with the response.
2.、c.2.b.3.a--署名者がGLOでなくてまた将来のメンバーでないなら、GLAはnoSpamのcMCStatus.failedとotherInfo.extendedFailInfo.SKDFailInfo値でcMCStatusInfoExtを示す応答を返します。 さらに、signingTime属性は応答で含まれています。
2.c.2.b.3.b - Else if the signer is either a registered GLO
or the member, the GLA returns a
cMCStatusInfoExt.cMCStatus.success and a
signingTime attribute to the GLO (2 in Figure
6) if the GLO signed the request and to the
GL member (3 in Figure 6) if the GL member
signed the request. The GLA also takes
administrative actions, which are beyond the
scope of this document, to delete the member
with the GL stored on the GLA.
2.、c.2.b.3.b--ほかに、署名者が登録されたGLOかメンバーのどちらかであるなら、GLメンバーが要求にサインしたならGLOが要求とGLメンバー(図6の3)にサインしたなら、GLAはGLO(図6の2)にcMCStatusInfoExt.cMCStatus.successとsigningTime属性を返します。 また、GLAは管理行動を取ります。(GLAに格納されるGLのメンバーを削除するために、行動はこのドキュメントの範囲にあります)。
2.c.2.b.3.b.1 - The GLA applies confidentiality to the
response by encapsulating the
SignedData.PKIData in an EnvelopedData if
the request was encapsulated in an
EnvelopedData (see Section 3.2.1.2).
セクション3.2を見てください。2. c.2.b.3.b.1、--、GLAが要求がEnvelopedDataで要約されたならEnvelopedDataでSignedData.PKIDataを要約することによって秘密性を応答に適用する(.1 .2)。
2.c.2.b.3.b.2 - The GLA can also optionally apply another
SignedData over the EnvelopedData (see
Section 3.2.1.2).
セクション3.2を見てください。2. c.2.b.3.b.2、--、また、GLAが任意に別のSignedDataをEnvelopedDataの上に適用できる(.1 .2)。
3 - Upon receipt of the cMCStatusInfoExt response, the GLO checks the
signingTime and verifies the GLA signatures. If an additional
SignedData and/or EnvelopedData encapsulates the response (see
Section 3.2.1.2 or 3.2.2), the GLO verifies the outer signature
and/or decrypts the outer layer prior to verifying the signature
on the innermost SignedData.
3--cMCStatusInfoExt応答を受け取り次第、GLOはsigningTimeをチェックして、GLA署名について確かめます。 または、追加SignedData、そして/または、EnvelopedDataが応答を要約する、(セクション3.2.1を見てください、.2、3.2 .2) 最も奥深いSignedDataで署名について確かめる前に、GLOは外側の署名について確かめる、そして/または、外側の層を解読します。
3.a - If the signingTime attribute value is not within the locally
accepted time window, the GLO MAY return a response
indicating cMCStatus.failed and otherInfo.failInfo.badTime
and a signingTime attribute.
3. a--signingTimeであるなら値を結果と考えてください。局所的に受け入れられたタイムウィンドウ、cMCStatus.failedとotherInfo.failInfo.badTimeを示すGLO MAYリターンa応答、およびsigningTime属性の中にありません。
3.b - Else if signature processing continues and if the signatures
do verify, the GLO checks that one of the names in the
certificate used to sign the response matches the name of the
GL.
3. b--ほかに、署名処理が続いて、署名であるならしてください、検証、GLOは、応答にサインするのに使用される証明書の名前の1つがGLという名前に合っているのをチェックします。
Turner Standards Track [Page 54] RFC 5275 CMS SymKeyDist June 2008
5275cmのターナー標準化過程[54ページ]RFC SymKeyDist2008年6月
3.b.1 - If the name of the GL does not match the name present in
the certificate used to sign the message, the GLO should
not believe the response.
3. b.1--GLという名前がそうしないなら、現在という名前を合わせてください。証明書には、メッセージは以前はよくサインしていました、とGLOが応答を信じているはずがありません。
3.b.2 - Else if the name of the GL matches the name present in
the certificate and:
そして、3. b.2--GLという名前が名前に合っているならほかに、中に証明書を提示してください、:
3.b.2.a - If the signatures verify and the response is
cMCStatusInfoExt.cMCStatus.success, the GLO has
deleted the member from the GL. If member was
deleted from a managed list and the original request
was signed by the member, the GLO sends a
cMCStatusInfoExt.cMCStatus.success and a signingTime
attribute to the GL member.
そして、3. b.2.a、署名である、確かめ、応答がcMCStatusInfoExt.cMCStatus.successである、GLOはGLからメンバーを削除しました。 メンバーが管理されたリストから削除されて、オリジナルの要求がメンバーによってサインされたなら、GLOはcMCStatusInfoExt.cMCStatus.successとsigningTime属性をGLメンバーに送ります。
3.b.2.b - Else if the GLO received a
cMCStatusInfoExt.cMCStatus.failed with any reason,
the GLO may reattempt to delete the member from the
GL using the information provided in the response.
3. b.2.b--GLOがいずれかでcMCStatusInfoExt.cMCStatus.failedを受けたなら、ほかに、推論してください、そして、GLOは、GLから応答に提供された情報を使用することでメンバーを削除するために「再-試み」てもよいです。
4 - Upon receipt of the cMCStatusInfoExt response, the member checks
the signingTime and verifies the GLA signature(s) or GLO
signature(s). If an additional SignedData and/or EnvelopedData
encapsulates the response (see Section 3.2.1.2 or 3.2.2), the GLO
verifies the outer signature and/or decrypts the outer layer
prior to verifying the signature on the innermost SignedData.
cMCStatusInfoExt応答を受け取り次第4、メンバーはsigningTimeをチェックして、GLA署名かGLO署名について確かめます。 または、追加SignedData、そして/または、EnvelopedDataが応答を要約する、(セクション3.2.1を見てください、.2、3.2 .2) 最も奥深いSignedDataで署名について確かめる前に、GLOは外側の署名について確かめる、そして/または、外側の層を解読します。
4.a - If the signingTime attribute value is not within the locally
accepted time window, the prospective member MAY return a
response indicating cMCStatus.failed and
otherInfo.failInfo.badTime and a signingTime attribute.
4. a--signingTimeであるなら値を結果と考えてください。局所的に受け入れられたタイムウィンドウ、cMCStatus.failedとotherInfo.failInfo.badTimeを示す将来のメンバー5月のリターンa応答、およびsigningTime属性の中にありません。
4.b - Else if signature processing continues and if the signatures
verify, the GL member checks that one of the names in the
certificate used to sign the response matches the name of the
GL.
4. b--、ほか、署名処理が続いて、署名である、検証、GLメンバーは、応答にサインするのに使用される証明書の名前の1つがGLという名前に合っているのをチェックします。
4.b.1 - If the name of the GL does not match the name present in
the certificate used to sign the message, the GL member
should not believe the response.
4. b.1--GLという名前がそうしないなら、名前を合わせてください。メッセージにサインするのに使用される証明書に存在しています、GLメンバーは応答を信じるべきではありません。
4.b.2 - Else if the name of the GL matches the name present in
the certificate and:
そして、4. b.2--GLという名前が名前に合っているならほかに、中に証明書を提示してください、:
4.b.2.a - If the signature(s) verify, the member has been
deleted from the GL.
4.、b.2.a--(s)が確かめる署名、メンバーがGLから削除されたなら。
Turner Standards Track [Page 55] RFC 5275 CMS SymKeyDist June 2008
5275cmのターナー標準化過程[55ページ]RFC SymKeyDist2008年6月
4.b.2.b - Else if the member received a
cMCStatusInfoExt.cMCStatus.failed with any reason,
the member can reattempt to delete itself from the GL
using the information provided in the response.
4. b.2.b--メンバーがいずれかでcMCStatusInfoExt.cMCStatus.failedを受け取ったなら、ほかに、推論してください、そして、メンバーは、GLから応答に提供された情報を使用することでそれ自体を削除するために「再-試み」ることができます。
4.4.2. Member Initiated Deletions
4.4.2. メンバーの開始している削除
The process for member initiated deletion of its own membership using the glDeleteMember requests is as follows:
glDeleteMember要求を使用するそれ自身の会員資格のメンバーの開始している削除のための過程は以下の通りです:
1 - The member sends a
SignedData.PKIData.controlSequence.glDeleteMember request to the
GLA (A in Figure 6). The member includes the name of the GL in
glName and the member's own name in glMemberToDelete. The GL
member MUST also include the signingTime attribute with this
request.
1--メンバーはGLA(図6のA)にSignedData.PKIData.controlSequence.glDeleteMember要求を送ります。 メンバーはglMemberToDeleteのglNameとメンバーの自己の名前でGLという名前を入れます。 また、GLメンバーはこの要求があるsigningTime属性を入れなければなりません。
1.a - The member can optionally apply confidentiality to the
request by encapsulating the SignedData.PKIData in an
EnvelopedData (see Section 3.2.1.2).
セクション3.2を見てください。1. a--缶がEnvelopedDataでSignedData.PKIDataを要約しながら任意に要求への秘密性を適用するメンバー、(.1 .2)。
1.b - The member can also optionally apply another SignedData over
the EnvelopedData (see Section 3.2.1.2).
セクション3.2を見てください。1. b、--、また、メンバーが任意に別のSignedDataをEnvelopedDataの上に適用できる(.1 .2)。
2 - Upon receipt of the request, the GLA verifies the request as per
2 in Section 4.4.1.
2--要求を受け取り次第、GLAはセクション4.4.1における2に従って要求について確かめます。
3 - Upon receipt of the forwarded request, the GLO checks the
signingTime and verifies the member signature on the innermost
SignedData.PKIData and the GLA signature on the outer layer. If
an EnvelopedData encapsulates the innermost layer (see Section
3.2.1.2 or 3.2.2), the GLO decrypts the outer layer prior to
verifying the signature on the innermost SignedData.
転送された要求を受け取り次第3、GLOは最も奥深いSignedData.PKIDataとGLA署名のときに外側の層でsigningTimeをチェックして、メンバー署名について確かめます。 または、EnvelopedDataが最内の層をカプセルに入れる、(セクション3.2.1を見てください、.2、3.2 .2) 最も奥深いSignedDataで署名について確かめる前に、GLOは外側の層を解読します。
Note: For cases where the GL is closed and either (a) a
prospective member sends directly to the GLO or (b) the GLA has
mistakenly forwarded the request to the GLO, the GLO should first
determine whether to honor the request.
以下に注意してください。 GLが終えられて、(a) 将来のメンバーがGLOに直送するか、または(b) GLAが要求をGLOに誤って転送したケースのために、GLOは、最初に、要求を光栄に思うかどうか決定するはずです。
3.a - If the signingTime attribute value is not within the locally
accepted time window, the GLO MAY return a response
indicating cMCStatus.failed and otherInfo.failInfo.badTime
and a signingTime attribute.
3. a--signingTimeであるなら値を結果と考えてください。局所的に受け入れられたタイムウィンドウ、cMCStatus.failedとotherInfo.failInfo.badTimeを示すGLO MAYリターンa応答、およびsigningTime属性の中にありません。
Turner Standards Track [Page 56] RFC 5275 CMS SymKeyDist June 2008
5275cmのターナー標準化過程[56ページ]RFC SymKeyDist2008年6月
3.b - Else if signature processing continues if the signatures
cannot be verified, the GLO returns a cMCStatusInfoExt
response indicating cMCStatus.failed and
otherInfo.failInfo.badMessageCheck and a signingTime
attribute.
3. b--署名が続くことができないなら署名処理が続くなら、ほかに、確かめられてください、そして、GLOはcMCStatus.failedとotherInfo.failInfo.badMessageCheckを示すcMCStatusInfoExt応答とsigningTime属性を返します。
3.c - Else if the signatures verify, the GLO checks to make sure
one of the names in the certificates used to sign the request
matches the name in glMemberToDelete.
3. c--、ほか、署名が確かめる、GLOは、要求にサインするのに使用される証明書の名前の1つがglMemberToDeleteの名前に合っているのを確実にするためにチェックします。
3.c.1 - If the names do not match, the GLO sends a
SignedData.PKIResponse.controlSequence message back to
the prospective member with
cMCStatusInfoExt.cMCtatus.failed indicating why the
prospective member was denied in
cMCStatusInfoExt.statusString. This stops people from
adding people to GLs without their permission.
Additionally, a signingTime attribute is included with
the response.
3. c.1--名前であるなら合わないでください、そして、GLOは将来のメンバーがなぜcMCStatusInfoExt.statusStringで否定されたかを示すcMCStatusInfoExt.cMCtatus.failedの将来のメンバーにSignedData.PKIResponse.controlSequenceメッセージを送り返します。 これによって、人々は彼らの許可なしでGLsに人々を加えることができません。 さらに、signingTime属性は応答で含まれています。
3.c.2 - Else if the names match, the GLO resubmits the
glDeleteMember request (see Section 3.2.5) to the GLA (1
in Figure 6). The GLO makes sure the glMemberName is
already on the GL. The GLO also generates a glRekey
request and include it with the GLDeleteMember request
(see Section 4.5).
3. c.2--ほかに、名前であるなら合ってください、そして、GLOはglDeleteMember要求(セクション3.2.5を見る)をGLA(図6の1)に再提出します。 GLOは、glMemberNameがGLに既にあるのを確実にします。 GLOはまた、glRekey要求を発生させて、GLDeleteMember要求でそれを含んでいます(セクション4.5を見てください)。
3.c.2.a - The GLO applies confidentiality to the new
GLDeleteMember request by encapsulating the
SignedData.PKIData in an EnvelopedData if the initial
request was encapsulated in an EnvelopedData (see
Section 3.2.1.2).
セクション3.2を見てください。3. c.2.a、--、GLOが初期の要求がEnvelopedDataで要約されたならEnvelopedDataでSignedData.PKIDataを要約することによって新しいGLDeleteMember要求に秘密性を適用する(.1 .2)。
3.c.2.b - The GLO can also optionally apply another SignedData
over the EnvelopedData (see Section 3.2.1.2).
セクション3.2を見てください。3. c.2.b、--、また、GLOが任意に別のSignedDataをEnvelopedDataの上に適用できる(.1 .2)。
4 - Further processing is as in 2 of Section 4.4.1.
4--セクション4.4.1のコネ2としてさらなる処理はあります。
4.5. Request Rekey of GL
4.5. GLのRekeyを要求してください。
From time to time, the GL will need to be rekeyed. Some situations follow:
時々、GLは、「再-合わせ」られる必要があるでしょう。 いくつかの状況が続きます:
- When a member is removed from a closed or managed GL. In this
case, the PKIData.controlSequence containing the glDeleteMember
ought to contain a glRekey request.
- 閉じているか管理されたGLからメンバーを免職するとき。 この場合、glDeleteMemberを含むPKIData.controlSequenceはglRekey要求を含むべきです。
Turner Standards Track [Page 57] RFC 5275 CMS SymKeyDist June 2008
5275cmのターナー標準化過程[57ページ]RFC SymKeyDist2008年6月
- Depending on policy, when a member is removed from an unmanaged
GL. If the policy is to rekey the GL, the
PKIData.controlSequence containing the glDeleteMember could also
contain a glRekey request or an out-of-bands means could be used
to tell the GLA to rekey the GL. Rekeying of unmanaged GLs when
members are deleted is not advised.
- unmanaged GLからメンバーを免職するとき、方針によります。 また、方針がGLをrekeyすることであるなら、glDeleteMemberを含むPKIData.controlSequenceがglRekey要求を含むかもしれませんか、またはGLをrekeyするようにGLAに言うのにバンドで出ている手段は使用できました。 メンバーが削除されるときunmanaged GLsをRekeyingするのはアドバイスされません。
- When the current shared KEK has been compromised.
- 電流が共有されたとき、KEKは妥協しました。
- When the current shared KEK is about to expire. Consider two
cases:
- 電流が共有されたとき、KEKは期限が切れようとしています。 2つのケースを考えてください:
-- If the GLO controls the GL rekey, the GLA should not assume
that a new shared KEK should be distributed, but instead wait
for the glRekey message.
-- GLOがGL rekeyを制御するなら、GLAは、新しい共有されたKEKが分配されるべきであると仮定するはずがありませんが、代わりにglRekeyメッセージを待ってください。
-- If the GLA controls the GL rekey, the GLA should initiate a
glKey message as specified in Section 5.
-- GLAがGL rekeyを制御するなら、GLAはセクション5で指定されているとしてglKeyメッセージを開始するはずです。
If the generationCounter (see Section 3.1.1) is set to a value greater than one (1) and the GLO controls the GL rekey, the GLO may generate a glRekey any time before the last shared KEK has expired. To be on the safe side, the GLO ought to request a rekey one (1) duration before the last shared KEK expires.
generationCounter(セクション3.1.1を見る)が1つ(1)より大きい値に用意ができて、GLOがGL rekeyを制御するなら、最後に共有されたKEKが期限が切れる前にGLOはglRekeyをいつでも発生させるかもしれません。 安全策を取って、最後に共有されたKEKが期限が切れる前にGLOはrekey1(1)持続時間を要求するべきです。
The GLA and GLO are the only entities allowed to initiate a GL rekey. The GLO indicated whether they are going to control rekeys or whether the GLA is going to control rekeys when they assigned the shared KEK to GL (see Section 3.1.1). The GLO initiates a GL rekey at any time. The GLA can be configured to automatically rekey the GL prior to the expiration of the shared KEK (the length of time before the expiration is an implementation decision). The GLA can also automatically rekey GLs that have been compromised, but this is covered in Section 5. Figure 7 depicts the protocol interactions to request a GL rekey. Note that error messages are not depicted. Additionally, behavior for the optional transactionId, senderNonce, and recipientNonce CMC control attributes is not addressed in these procedures.
GLAとGLOはGL rekeyを開始できた唯一の実体です。 GLOは、彼らが共有されたKEKをGLに割り当てたとき(セクション3.1.1を見てください)、彼らが「再-キー」を制御するだろうかどうか、またはGLAが「再-キー」を制御するだろうかどうかを示しました。 GLOはいつでも、GL rekeyを開始します。 共有されたKEK(満了が実現決定であることの前の時間の長さ)の満了の前に自動的にGLをrekeyするようにGLAを構成できます。 GLAは覆うことができます、自動的に妥協したrekey GLs、また、これだけがセクション5で覆われています。 図7は、GL rekeyを要求するためにプロトコル相互作用について表現します。 エラーメッセージが表現されないことに注意してください。 さらに、任意のtransactionId、senderNonce、およびrecipientNonce CMCコントロール属性のための振舞いはこれらの手順で記述されません。
+-----+ 1 2,A +-----+ | GLA | <-------> | GLO | +-----+ +-----+
+-----+ 1 2、+-----+ | GLA| <、-、-、-、-、-、--、>| GLO| +-----+ +-----+
Figure 7 - GL Rekey Request
図7--GL Rekey要求
Turner Standards Track [Page 58] RFC 5275 CMS SymKeyDist June 2008
5275cmのターナー標準化過程[58ページ]RFC SymKeyDist2008年6月
4.5.1. GLO Initiated Rekey Requests
4.5.1. GLOはRekey要求を開始しました。
The process for GLO initiated glRekey requests is as follows:
GLOがglRekey要求を開始したので、過程は以下の通りです:
1 - The GLO sends a SignedData.PKIData.controlSequence.glRekey
request to the GLA (1 in Figure 7). The GLO includes the glName.
If glAdministration and glKeyNewAttributes are omitted then there
is no change from the previously registered GL values for these
fields. If the GLO wants to force a rekey for all outstanding
shared KEKs, it includes the glRekeyAllGLKeys set to TRUE. The
GLO MUST also include a signingTime attribute with this request.
1--GLOはGLA(図7の1)にSignedData.PKIData.controlSequence.glRekey要求を送ります。 GLOはglNameを含んでいます。 glAdministrationとglKeyNewAttributesが省略されるなら、これらの分野への以前に登録されたGL値からの変化が全くありません。 GLOがすべての傑出している共有されたKEKsのためにrekeyを強制したいなら、それはglRekeyAllGLKeysセットをTRUEに含めます。 また、GLO MUSTはこの要求があるsigningTime属性を含んでいます。
1.a - The GLO can optionally apply confidentiality to the request
by encapsulating the SignedData.PKIData in an EnvelopedData
(see Section 3.2.1.2).
セクション3.2を見てください。1. a--缶がEnvelopedDataでSignedData.PKIDataを要約しながら任意に要求への秘密性を適用するGLO、(.1 .2)。
1.b - The GLO can also optionally apply another SignedData over the
EnvelopedData (see Section 3.2.1.2).
セクション3.2を見てください。1. b、--、また、GLOが任意に別のSignedDataをEnvelopedDataの上に適用できる(.1 .2)。
2 - Upon receipt of the request, the GLA checks the signingTime and
verifies the signature on the innermost SignedData.PKIData. If
an additional SignedData and/or EnvelopedData encapsulates the
request (see Section 3.2.1.2 or 3.2.2), the GLA verifies the
outer signature and/or decrypts the outer layer prior to
verifying the signature on the innermost SignedData.
2--要求を受け取り次第、GLAは最も奥深いSignedData.PKIDataでsigningTimeをチェックして、署名について確かめます。 または、追加SignedData、そして/または、EnvelopedDataが要求を要約する、(セクション3.2.1を見てください、.2、3.2 .2) 最も奥深いSignedDataで署名について確かめる前に、GLAは外側の署名について確かめる、そして/または、外側の層を解読します。
2.a - If the signingTime attribute value is not within the locally
accepted time window, the GLA MAY return a response
indicating cMCStatus.failed and otherInfo.failInfo.badTime
and a signingTime attribute.
2. a--signingTimeであるなら値を結果と考えてください。局所的に受け入れられたタイムウィンドウ、cMCStatus.failedとotherInfo.failInfo.badTimeを示すGLA MAYリターンa応答、およびsigningTime属性の中にありません。
2.b - Else if signature processing continues and if the signatures
do not verify, the GLA returns a cMCStatusInfoExt response
indicating cMCStatus.failed and
otherInfo.failInfo.badMessageCheck. Additionally, a
signingTime attribute is included with the response.
2. b--ほかに、署名処理が続いて、署名であるならしてください。GLAリターンa cMCStatusInfoExt応答がcMCStatus.failedとotherInfo.failInfo.badMessageCheckを示して、確かめません。 さらに、signingTime属性は応答で含まれています。
2.c - Else if the signatures do verify, the GLA makes sure the GL
is supported by the GLA by checking that the glName matches a
glName stored on the GLA.
2. c--ほかに、署名であるならしてください。glNameマッチa glNameがGLAに格納したGLがGLAによって支持されるのを確信しているGLA造がチェックして、確かめます。
2.c.1 - If the glName present does not match a GL stored on the
GLA, the GLA returns a response indicating
cMCStatusInfoExt with cMCStatus.failed and
otherInfo.extendedFailInfo.SKDFailInfo value of
invalidGLName. Additionally, a signingTime attribute is
included with the response.
2. c.1--glNameプレゼントがそうしないなら、GLA(cMCStatus.failedと共にcMCStatusInfoExtを示す応答とotherInfo.extendedFailInfo.SKDFailInfoが評価するinvalidGLNameのGLA復帰)に格納されていた状態でGLを合わせてください。 さらに、signingTime属性は応答で含まれています。
Turner Standards Track [Page 59] RFC 5275 CMS SymKeyDist June 2008
5275cmのターナー標準化過程[59ページ]RFC SymKeyDist2008年6月
2.c.2 - Else if the glName present matches a GL stored on the
GLA, the GLA checks that a registered GLO signed the
request by checking that one of the names in the
certificate used to sign the request is a registered GLO.
2. c.2--ほかに、glNameであるならGLA(要求にサインするのに使用される証明書の名前の1つが登録されたGLOであることをチェックしながら登録されたGLOが要求にサインしたGLAチェック)に格納されたGLをマッチに寄贈してください。
2.c.2.a - If the names do not match, the GLA returns a response
indicating cMCStatusInfoExt with cMCStatus.failed and
otherInfo.extendedFailInfo.SKDFailInfo value of
noGLONameMatch. Additionally, a signingTime
attribute is included with the response.
2. c.2.a--名前であるなら合わないでください、そして、GLAはnoGLONameMatchのcMCStatus.failedとotherInfo.extendedFailInfo.SKDFailInfo値でcMCStatusInfoExtを示す応答を返します。 さらに、signingTime属性は応答で含まれています。
2.c.2.b - Else if the names match, the GLA checks the
glNewKeyAttribute values.
2. c.2.b--ほかに、名前であるなら合ってください、そして、GLAはglNewKeyAttribute値をチェックします。
2.c.2.b.1 - If the new value for requestedAlgorithm is not
supported, the GLA returns a response indicating
cMCStatusInfoExt with cMCStatus.failed and
otherInfo.extendedFailInfo.SKDFailInfo value of
unsupportedAlgorithm. Additionally, a
signingTime attribute is included with the
response.
2.、c.2.b.1--requestedAlgorithmのための新しい値が支持されないなら、GLAはunsupportedAlgorithmのcMCStatus.failedとotherInfo.extendedFailInfo.SKDFailInfo値でcMCStatusInfoExtを示す応答を返します。 さらに、signingTime属性は応答で含まれています。
2.c.2.b.2 - Else if the new value duration is not supportable
(determining this is beyond the scope of this
document), the GLA returns a response indicating
cMCStatusInfoExt with cMCStatus.failed and
otherInfo.extendedFailInfo.SKDFailInfo value of
unsupportedDuration. Additionally, a signingTime
attribute is included with the response.
2.、c.2.b.2--ほかに、新しい値の持続時間が我慢できないなら(これを決定するのはこのドキュメントの範囲を超えています)、GLAはunsupportedDurationのcMCStatus.failedとotherInfo.extendedFailInfo.SKDFailInfo値でcMCStatusInfoExtを示す応答を返します。 さらに、signingTime属性は応答で含まれています。
2.c.2.b.3 - Else if the GL is not supportable for other
reasons that the GLA does not wish to disclose,
the GLA returns a response indicating
cMCStatusInfoExt with cMCStatus.failed and
otherInfo.extendedFailInfo.SKDFailInfo value of
unspecified. Additionally, a signingTime
attribute is included with the response.
2. c.2.b.3--GLがGLAがそうしない他の理由で我慢できないなら、ほかに、願ってください。GLAリターンa応答が不特定のcMCStatus.failedとotherInfo.extendedFailInfo.SKDFailInfo値でcMCStatusInfoExtを示して、明らかにします。 さらに、signingTime属性は応答で含まれています。
2.c.2.b.4 - Else if the new requestedAlgorithm and duration
are supportable or the glNewKeyAttributes was
omitted, the GLA returns a
cMCStatusInfoExt.cMCStatus.success and a
sigingTime attribute (2 in Figure 7). The GLA
also uses the glKey message to distribute the
rekey shared KEK (see Section 5).
2.、c.2.b.4--ほかに、新しいrequestedAlgorithmと持続時間が我慢できるか、またはglNewKeyAttributesが省略されたなら、GLAはcMCStatusInfoExt.cMCStatus.successとsigingTime属性(図7の2)を返します。 また、GLAはrekeyを分配するのがKEKを共有したという(セクション5を見てください)glKeyメッセージを使用します。
Turner Standards Track [Page 60] RFC 5275 CMS SymKeyDist June 2008
5275cmのターナー標準化過程[60ページ]RFC SymKeyDist2008年6月
2.c.2.b.4.a - The GLA applies confidentiality to response
by encapsulating the SignedData.PKIData in an
EnvelopedData if the request was encapsulated
in an EnvelopedData (see Section 3.2.1.2).
セクション3.2を見てください。2. c.2.b.4.a、--、GLAが要求がEnvelopedDataで要約されたならEnvelopedDataでSignedData.PKIDataを要約することによって秘密性を応答に適用する(.1 .2)。
2.c.2.b.4.b - The GLA can also optionally apply another
SignedData over the EnvelopedData (see
Section 3.2.1.2).
セクション3.2を見てください。2. c.2.b.4.b、--、また、GLAが任意に別のSignedDataをEnvelopedDataの上に適用できる(.1 .2)。
3 - Upon receipt of the cMCStatusInfoExt response, the GLO checks the
signingTime and verifies the GLA signature(s). If an additional
SignedData and/or EnvelopedData encapsulates the forwarded
response (see Section 3.2.1.2 or 3.2.2), the GLO verifies the
outer signature and/or decrypts the forwarded response prior to
verifying the signature on the innermost SignedData.
3--cMCStatusInfoExt応答を受け取り次第、GLOはsigningTimeをチェックして、GLA署名について確かめます。 または、追加SignedData、そして/または、EnvelopedDataが進められた応答を要約する、(セクション3.2.1を見てください、.2、3.2 .2) 最も奥深いSignedDataで署名について確かめる前に、GLOは外側の署名について確かめる、そして/または、進められた応答を解読します。
3.a - If the signingTime attribute value is not within the locally
accepted time window, the GLA MAY return a response
indicating cMCStatus.failed and otherInfo.failInfo.badTime
and a signingTime attribute.
3. a--signingTimeであるなら値を結果と考えてください。局所的に受け入れられたタイムウィンドウ、cMCStatus.failedとotherInfo.failInfo.badTimeを示すGLA MAYリターンa応答、およびsigningTime属性の中にありません。
3.b - Else if signature processing continues and if the signatures
verify, the GLO checks that one of the names in the
certificate used to sign the response matches the name of the
GL.
3. b--、ほか、署名処理が続いて、署名である、検証、GLOは、応答にサインするのに使用される証明書の名前の1つがGLという名前に合っているのをチェックします。
3.b.1 - If the name of the GL does not match the name present in
the certificate used to sign the message, the GLO should
not believe the response.
3. b.1--GLという名前がそうしないなら、現在という名前を合わせてください。証明書には、メッセージは以前はよくサインしていました、とGLOが応答を信じているはずがありません。
3.b.2 - Else if the name of the GL matches the name present in
the certificate and:
そして、3. b.2--GLという名前が名前に合っているならほかに、中に証明書を提示してください、:
3.b.2.a - If the signatures verify and the response is
cMCStatusInfoExt.cMCStatus.success, the GLO has
successfully rekeyed the GL.
そして、3. b.2.a、署名である、確かめ、応答がcMCStatusInfoExt.cMCStatus.successである、GLOは首尾よくGLを「再-合わせ」ました。
3.b.2.b - Else if the GLO received a
cMCStatusInfoExt.cMCStatus.failed with any reason,
the GLO can reattempt to rekey the GL using the
information provided in the response.
3. b.2.b--GLOがいずれかでcMCStatusInfoExt.cMCStatus.failedを受けたなら、ほかに、推論してください、そして、GLOは、応答に提供された情報を使用することでrekeyにGLを「再-試み」ることができます。
Turner Standards Track [Page 61] RFC 5275 CMS SymKeyDist June 2008
5275cmのターナー標準化過程[61ページ]RFC SymKeyDist2008年6月
4.5.2. GLA Initiated Rekey Requests
4.5.2. GLAはRekey要求を開始しました。
If the GLA is in charge of rekeying the GL the GLA will automatically issue a glKey message (see Section 5). In addition the GLA will generate a cMCStatusInfoExt to indicate to the GL that a successful rekey has occurred. The process for GLA initiated rekey is as follows:
GLを「再-合わせ」ることを担当してGLAがあると、GLAは自動的にglKeyメッセージを発行するでしょう(セクション5を見てください)。 さらに、GLAは、うまくいっているrekeyが現れたのをGLに示すためにcMCStatusInfoExtを発生させるでしょう。 GLAがrekeyを開始したので、過程は以下の通りです:
1 - The GLA generates for all GLOs a
SignedData.PKIData.controlSequence.cMCStatusInfoExt.cMCStatus
success and includes a signingTime attribute (A in Figure 7).
1--GLAはすべてのGLOsのためにSignedData.PKIData.controlSequence.cMCStatusInfoExt.cMCStatus成功を発生させて、signingTime属性(図7のA)を含んでいます。
1.a - The GLA can optionally apply confidentiality to the request
by encapsulating the SignedData.PKIData in an EnvelopedData
(see Section 3.2.1.2).
セクション3.2を見てください。1. a--缶がEnvelopedDataでSignedData.PKIDataを要約しながら任意に要求への秘密性を適用するGLA、(.1 .2)。
1.b - The GLA can also optionally apply another SignedData over the
EnvelopedData (see Section 3.2.1.2).
セクション3.2を見てください。1. b、--、また、GLAが任意に別のSignedDataをEnvelopedDataの上に適用できる(.1 .2)。
2 - Upon receipt of the cMCStatusInfoExt.cMCStatus.success response,
the GLO checks the signingTime and verifies the GLA signature(s).
If an additional SignedData and/or EnvelopedData encapsulates the
forwarded response (see Section 3.2.1.2 or 3.2.2), the GLO MUST
verify the outer signature and/or decrypt the outer layer prior
to verifying the signature on the innermost SignedData.
2--cMCStatusInfoExt.cMCStatus.success応答を受け取り次第、GLOはsigningTimeをチェックして、GLA署名について確かめます。 または、追加SignedData、そして/または、EnvelopedDataが進められた応答を要約する、(セクション3.2.1を見てください、.2、3.2 .2) 最も奥深いSignedDataで署名について確かめる前に、GLO MUSTは外側の署名について確かめる、そして/または、外側の層を解読します。
2.a - If the signingTime attribute value is not within the locally
accepted time window, the GLO MAY return a response
indicating cMCStatus.failed and otherInfo.failInfo.badTime
and a signingTime attribute.
2. a--signingTimeであるなら値を結果と考えてください。局所的に受け入れられたタイムウィンドウ、cMCStatus.failedとotherInfo.failInfo.badTimeを示すGLO MAYリターンa応答、およびsigningTime属性の中にありません。
2.b - Else if signature processing continues and if the signatures
verify, the GLO checks that one of the names in the
certificate used to sign the response matches the name of the
GL.
2. b--、ほか、署名処理が続いて、署名である、検証、GLOは、応答にサインするのに使用される証明書の名前の1つがGLという名前に合っているのをチェックします。
2.b.1 - If the name of the GL does not match the name present in
the certificate used to sign the message, the GLO ought
not believe the response.
2. b.1--GLという名前がそうしないなら、現在という名前を合わせてください。証明書には、メッセージは以前はよくサインしていました、とGLOが応答を信じていません。
2.b.2 - Else if the name of the GL does match the name present in
the certificate and the response is
cMCStatusInfoExt.cMCStatus.success, the GLO knows the GLA
has successfully rekeyed the GL.
応答がcMCStatusInfoExt.cMCStatus.successである、2. b.2--GLという名前がそうするなら、ほかに、証明書の現在の名前を合わせてください。そうすれば、GLOはGLAが首尾よくGLを「再-合わせ」たのを知っています。
Turner Standards Track [Page 62] RFC 5275 CMS SymKeyDist June 2008
5275cmのターナー標準化過程[62ページ]RFC SymKeyDist2008年6月
4.6. Change GLO
4.6. 変化GLO
Management of managed and closed GLs can become difficult for one GLO if the GL membership grows large. To support distributing the workload, GLAs support having GLs be managed by multiple GLOs. The glAddOwner and glRemoveOwner messages are designed to support adding and removing registered GLOs. Figure 8 depicts the protocol interactions to send glAddOwner and glRemoveOwner messages and the resulting response messages. Note that error messages are not shown. Additionally, behavior for the optional transactionId, senderNonce, and recipientNonce CMC control attributes is not addressed in these procedures.
GL会員資格が大きくなるなら、管理されて閉じているGLsの管理は1GLOに難しくなることができます。 ワークロードを分配するのを支持するために、GLAsは、複数のGLOsにGLsを管理させるのを支持します。 glAddOwnerとglRemoveOwnerメッセージは、登録されたGLOsを加えて、取り外すのを支持するように設計されています。 エイト環は、メッセージと結果として起こる応答メッセージをglAddOwnerとglRemoveOwnerに送るためにプロトコル相互作用について表現します。 エラーメッセージが示されないことに注意してください。 さらに、任意のtransactionId、senderNonce、およびrecipientNonce CMCコントロール属性のための振舞いはこれらの手順で記述されません。
+-----+ 1 2 +-----+
| GLA | <-------> | GLO |
+-----+ +-----+
+-----+ 1 2 +-----+ | GLA| <、-、-、-、-、-、--、>| GLO| +-----+ +-----+
Figure 8 - GLO Add and Delete Owners
エイト環--GLOは所有者を加えて、削除します。
The process for glAddOwner and glDeleteOwner is as follows:
glAddOwnerとglDeleteOwnerのための過程は以下の通りです:
1 - The GLO sends a SignedData.PKIData.controlSequence.glAddOwner or
glRemoveOwner request to the GLA (1 in Figure 8). The GLO
includes the GL name in glName, and the name and address of the
GLO in glOwnerName and glOwnerAddress, respectively. The GLO
MUST also include the signingTime attribute with this request.
1--GLOはGLA(図8の1)にSignedData.PKIData.controlSequence.glAddOwnerかglRemoveOwner要求を送ります。 GLOはglOwnerNameとglOwnerAddressにそれぞれGLOのglNameのGL名、名前、およびアドレスを含んでいます。 また、GLO MUSTはこの要求があるsigningTime属性を含んでいます。
1.a - The GLO can optionally apply confidentiality to the request
by encapsulating the SignedData.PKIData in an EnvelopedData
(see Section 3.2.1.2).
セクション3.2を見てください。1. a--缶がEnvelopedDataでSignedData.PKIDataを要約しながら任意に要求への秘密性を適用するGLO、(.1 .2)。
1.b - The GLO can also optionally apply another SignedData over the
EnvelopedData (see Section 3.2.1.2).
セクション3.2を見てください。1. b、--、また、GLOが任意に別のSignedDataをEnvelopedDataの上に適用できる(.1 .2)。
2 - Upon receipt of the glAddOwner or glRemoveOwner request, the GLA
checks the signingTime and verifies the GLO signature(s). If an
additional SignedData and/or EnvelopedData encapsulates the
request (see Section 3.2.1.2 or 3.2.2), the GLA verifies the
outer signature and/or decrypts the outer layer prior to
verifying the signature on the innermost SignedData.
2--glAddOwnerかglRemoveOwner要求を受け取り次第、GLAはsigningTimeをチェックして、GLO署名について確かめます。 または、追加SignedData、そして/または、EnvelopedDataが要求を要約する、(セクション3.2.1を見てください、.2、3.2 .2) 最も奥深いSignedDataで署名について確かめる前に、GLAは外側の署名について確かめる、そして/または、外側の層を解読します。
2.a - If the signingTime attribute value is not within the locally
accepted time window, the GLA MAY return a response
indicating cMCStatus.failed and otherInfo.failInfo.badTime
and a signingTime attribute.
2. a--signingTimeであるなら値を結果と考えてください。局所的に受け入れられたタイムウィンドウ、cMCStatus.failedとotherInfo.failInfo.badTimeを示すGLA MAYリターンa応答、およびsigningTime属性の中にありません。
Turner Standards Track [Page 63] RFC 5275 CMS SymKeyDist June 2008
5275cmのターナー標準化過程[63ページ]RFC SymKeyDist2008年6月
2.b - Else if signature processing continues and if the signatures
cannot be verified, the GLA returns a cMCStatusInfoExt
response indicating cMCStatus.failed and
otherInfo.failInfo.badMessageCheck. Additionally, a
signingTime attribute is included with the response.
2. b--署名処理が続いて、署名がそうすることができないなら、ほかに、確かめられてください、そして、GLAはcMCStatus.failedとotherInfo.failInfo.badMessageCheckを示すcMCStatusInfoExt応答を返します。 さらに、signingTime属性は応答で含まれています。
2.c - Else if the signatures verify, the GLA makes sure the GL is
supported by checking that the glName matches a glName stored
on the GLA.
2. c--、ほか、glNameマッチa glNameがGLAに格納したGLが支持されるのを確信しているGLA造がチェックして、署名は確かめます。
2.c.1 - If the glName is not supported by the GLA, the GLA
returns a response indicating cMCStatusInfoExt with
cMCStatus.failed and
otherInfo.extendedFailInfo.SKDFailInfo value of
invalidGLName. Additionally, a signingTime attribute is
included with the response.
2.、c.1--glNameがGLAによって支持されないなら、GLAはinvalidGLNameのcMCStatus.failedとotherInfo.extendedFailInfo.SKDFailInfo値でcMCStatusInfoExtを示す応答を返します。 さらに、signingTime属性は応答で含まれています。
2.c.2 - Else if the glName is supported by the GLA, the GLA
ensures that a registered GLO signed the glAddOwner or
glRemoveOwner request by checking that one of the names
present in the digital signature certificate used to sign
the glAddOwner or glDeleteOwner request matches the name
of a registered GLO.
2.、c.2--ほかに、glNameがGLAによって支持されるなら、GLAは、登録されたGLOがglAddOwnerにサインしたか、またはデジタル署名証明書の現在の名前の1つが以前はよくサインしていたのをチェックすることによってglRemoveOwnerが、glAddOwnerかglDeleteOwner要求が登録されたGLOという名前に合っているよう要求するのを確実にします。
2.c.2.a - If the names do not match, the GLA returns a response
indicating cMCStatusInfoExt with cMCStatus.failed and
otherInfo.extendedFailInfo.SKDFailInfo value of
noGLONameMatch. Additionally, a signingTime
attribute is included with the response.
2. c.2.a--名前であるなら合わないでください、そして、GLAはnoGLONameMatchのcMCStatus.failedとotherInfo.extendedFailInfo.SKDFailInfo値でcMCStatusInfoExtを示す応答を返します。 さらに、signingTime属性は応答で含まれています。
2.c.2.b - Else if the names match, the GLA returns a
cMCStatusInfoExt.cMCStatus.success and a signingTime
attribute (2 in Figure 4). The GLA also takes
administrative actions to associate the new
glOwnerName with the GL in the case of glAddOwner or
to disassociate the old glOwnerName with the GL in
the cased of glRemoveOwner.
2. c.2.b--ほかに、名前であるなら合ってください、そして、GLAはcMCStatusInfoExt.cMCStatus.successとsigningTime属性(図4の2)を返します。 また、GLAは、glAddOwnerの場合におけるGLに新しいglOwnerNameを関連づけるか、またはglRemoveOwnerのケースに入れのGLと共に古いglOwnerNameを分離するために管理行動を取ります。
2.c.2.b.1 - The GLA applies confidentiality to the response
by encapsulating the SignedData.PKIResponse in an
EnvelopedData if the request was encapsulated in
an EnvelopedData (see Section 3.2.1.2).
セクション3.2を見てください。2. c.2.b.1、--、GLAが要求がEnvelopedDataで要約されたならEnvelopedDataでSignedData.PKIResponseを要約することによって秘密性を応答に適用する(.1 .2)。
2.c.2.b.2 - The GLA can also optionally apply another
SignedData over the EnvelopedData (see Section
3.2.1.2).
セクション3.2を見てください。2. c.2.b.2、--、また、GLAが任意に別のSignedDataをEnvelopedDataの上に適用できる(.1 .2)。
Turner Standards Track [Page 64] RFC 5275 CMS SymKeyDist June 2008
5275cmのターナー標準化過程[64ページ]RFC SymKeyDist2008年6月
3 - Upon receipt of the cMCStatusInfoExt response, the GLO checks the
signingTime and verifies the GLA's signature(s). If an
additional SignedData and/or EnvelopedData encapsulates the
response (see Section 3.2.1.2 or 3.2.2), the GLO verifies the
outer signature and/or decrypts the outer layer prior to
verifying the signature on the innermost SignedData.
3--cMCStatusInfoExt応答を受け取り次第、GLOはsigningTimeをチェックして、GLAの署名について確かめます。 または、追加SignedData、そして/または、EnvelopedDataが応答を要約する、(セクション3.2.1を見てください、.2、3.2 .2) 最も奥深いSignedDataで署名について確かめる前に、GLOは外側の署名について確かめる、そして/または、外側の層を解読します。
3.a - If the signingTime attribute value is not within the locally
accepted time window, the GLO MAY return a response
indicating cMCStatus.failed and otherInfo.failInfo.badTime
and a signingTime attribute.
3. a--signingTimeであるなら値を結果と考えてください。局所的に受け入れられたタイムウィンドウ、cMCStatus.failedとotherInfo.failInfo.badTimeを示すGLO MAYリターンa応答、およびsigningTime属性の中にありません。
3.b - Else if signature processing continues and if the signatures
verify, the GLO checks that one of the names in the
certificate used to sign the response matches the name of the
GL.
3. b--、ほか、署名処理が続いて、署名である、検証、GLOは、応答にサインするのに使用される証明書の名前の1つがGLという名前に合っているのをチェックします。
3.b.1 - If the name of the GL does not match the name present in
the certificate used to sign the message, the GLO should
not believe the response.
3. b.1--GLという名前がそうしないなら、現在という名前を合わせてください。証明書には、メッセージは以前はよくサインしていました、とGLOが応答を信じているはずがありません。
3.b.2 - Else if the name of the GL does match the name present in
the certificate and:
そして、3. b.2--GLという名前がそうするならほかに、証明書の現在の名前を合わせてください、:
3.b.2.a - If the signatures verify and the response was
cMCStatusInfoExt.cMCStatus.success, the GLO has
successfully added or removed the GLO.
そして、3. b.2.a、署名である、確かめ、応答がcMCStatusInfoExt.cMCStatus.successであった、GLOは首尾よくGLOを加えるか、または取り外しました。
3.b.2.b - Else if the signatures verify and the response was
cMCStatusInfoExt.cMCStatus.failed with any reason,
the GLO can reattempt to add or delete the GLO using
the information provided in the response.
3. b.2.b--、ほか、署名が確かめる、応答はどんな理由(応答に提供された情報を使用することでGLOを加えるか、または削除するGLO缶の「再-試み」)があるcMCStatusInfoExt.cMCStatus.failedでした。
4.7. Indicate KEK Compromise
4.7. KEK妥協を示してください。
There will be times when the shared KEK is compromised. GL members and GLOs use glkCompromise to tell the GLA that the shared KEK has been compromised. Figure 9 depicts the protocol interactions for GL Key Compromise. Note that error messages are not shown. Additionally, behavior for the optional transactionId, senderNonce, and recipientNonce CMC control attributes is not addressed in these procedures.
共有されたKEKが妥協する回があるでしょう。 GLメンバーとGLOsは、共有されたKEKが妥協したとGLAに言うのにglkCompromiseを使用します。 図9はGL Key Compromiseのためにプロトコル相互作用について表現します。 エラーメッセージが示されないことに注意してください。 さらに、任意のtransactionId、senderNonce、およびrecipientNonce CMCコントロール属性のための振舞いはこれらの手順で記述されません。
Turner Standards Track [Page 65] RFC 5275 CMS SymKeyDist June 2008
5275cmのターナー標準化過程[65ページ]RFC SymKeyDist2008年6月
+-----+ 2{1} 4 +----------+
| GLO | <----------+ +-------> | Member 1 |
+-----+ 5,3{1} | | +----------+
+-----+ <----------+ | 4 +----------+
| GLA | 1 +-------> | ... |
+-----+ <---------------+ +----------+
| 4 +----------+
+-------> | Member n |
+----------+
+-----+ 2{1} 4 +----------+ | GLO| <、-、-、-、-、-、-、-、-、--+ +------->| メンバー1| +-----+ 5,3{1} | | +----------+ +-----+ <。----------+ | 4 +----------+ | GLA| 1 +------->| ... | +-----+ <。---------------+ +----------+ | 4 +----------+ +------->| メンバーn| +----------+
Figure 9 - GL Key Compromise
図9--GLの主要な妥協
4.7.1. GL Member Initiated KEK Compromise Message
4.7.1. GLメンバーはKEK妥協メッセージを開始しました。
The process for GL member initiated glkCompromise messages is as follows:
GLメンバーがglkCompromiseメッセージを開始したので、過程は以下の通りです:
1 - The GL member sends a
SignedData.PKIData.controlSequence.glkCompromise request to the
GLA (1 in Figure 9). The GL member includes the name of the GL
in GeneralName. The GL member MUST also include the signingTime
attribute with this request.
1--GLメンバーはGLA(図9の1)にSignedData.PKIData.controlSequence.glkCompromise要求を送ります。 GLメンバーはGeneralNameでGLという名前を入れます。 また、GLメンバーはこの要求があるsigningTime属性を入れなければなりません。
1.a - The GL member can optionally apply confidentiality to the
request by encapsulating the SignedData.PKIData in an
EnvelopedData (see Section 3.2.1.2). The glkCompromise can
be included in an EnvelopedData generated with the
compromised shared KEK.
セクション3.2を見てください。1. a--メンバーがEnvelopedDataでSignedData.PKIDataを要約しながら任意に要求への秘密性を適用できるGL、(.1 .2)。 妥協している共有されたKEKと共に発生するEnvelopedDataにglkCompromiseを含むことができます。
1.b - The GL member can also optionally apply another SignedData
over the EnvelopedData (see Section 3.2.1.2).
セクション3.2を見てください。1. b、--、また、GLメンバーが任意に別のSignedDataをEnvelopedDataの上に適用できる(.1 .2)。
2 - Upon receipt of the glkCompromise request, the GLA checks the
signingTime and verifies the GL member signature(s). If an
additional SignedData and/or EnvelopedData encapsulates the
request (see Section 3.2.1.2 or 3.2.2), the GLA verifies the
outer signature and/or decrypts the outer layer prior to
verifying the signature on the innermost SignedData.
2--glkCompromise要求を受け取り次第、GLAはsigningTimeをチェックして、GLメンバー署名について確かめます。 または、追加SignedData、そして/または、EnvelopedDataが要求を要約する、(セクション3.2.1を見てください、.2、3.2 .2) 最も奥深いSignedDataで署名について確かめる前に、GLAは外側の署名について確かめる、そして/または、外側の層を解読します。
2.a - If the signingTime attribute value is not within the locally
accepted time window, the GLA MAY return a response
indicating cMCStatus.failed and otherInfo.failInfo.badTime
and a signingTime attribute.
2. a--signingTimeであるなら値を結果と考えてください。局所的に受け入れられたタイムウィンドウ、cMCStatus.failedとotherInfo.failInfo.badTimeを示すGLA MAYリターンa応答、およびsigningTime属性の中にありません。
Turner Standards Track [Page 66] RFC 5275 CMS SymKeyDist June 2008
5275cmのターナー標準化過程[66ページ]RFC SymKeyDist2008年6月
2.b - Else if signature processing continues and if the signatures
cannot be verified, the GLA returns a cMCStatusInfoExt
response indicating cMCStatus.failed and
otherInfo.failInfo.badMessageCheck. Additionally, a
signingTime attribute is included with the response.
2. b--署名処理が続いて、署名がそうすることができないなら、ほかに、確かめられてください、そして、GLAはcMCStatus.failedとotherInfo.failInfo.badMessageCheckを示すcMCStatusInfoExt応答を返します。 さらに、signingTime属性は応答で含まれています。
2.c - Else if the signatures verify, the GLA makes sure the GL is
supported by checking that the indicated GL name matches a
glName stored on the GLA.
2. c--、ほか、マッチという示されたGL名のa glNameがGLAに格納したGLが支持されるのを確信しているGLA造がチェックして、署名は確かめます。
2.c.1 - If the glName is not supported by the GLA, the GLA
returns a response indicating cMCStatusInfoExt with
cMCStatus.failed and
otherInfo.extendedFailInfo.SKDFailInfo value of
invalidGLName. Additionally, a signingTime attribute is
included with the response.
2.、c.1--glNameがGLAによって支持されないなら、GLAはinvalidGLNameのcMCStatus.failedとotherInfo.extendedFailInfo.SKDFailInfo値でcMCStatusInfoExtを示す応答を返します。 さらに、signingTime属性は応答で含まれています。
2.c.2 - Else if the glName is supported by the GLA, the GLA
checks who signed the request. For GLOs, one of the
names in the certificate used to sign the request needs
to match a registered GLO. For the member, the name in
glMember.glMemberName needs to match one of the names in
the certificate used to sign the request.
2.、c.2--ほかに、glNameがGLAによって支持されるなら、GLAは、だれが要求にサインしたかをチェックします。 GLOsのために、要求にサインするのに使用される証明書の名前のひとりは、登録されたGLOを合わせる必要があります。 メンバーのために、glMember.glMemberNameの名前は、要求にサインするのに使用される証明書の名前の1つを合わせる必要があります。
2.c.2.a - If the GLO signed the request, the GLA generates a
glKey message as described in Section 5 to rekey the
GL (4 in Figure 9).
2.、c.2.a--GLOが要求にサインしたなら、GLAはセクション5 rekeyへのGL(図9の4)で説明されるようにglKeyメッセージを発生させます。
2.c.2.b - Else if someone other than the GLO signed the
request, the GLA forwards the glkCompromise message
(see Section 3.2.3) to the GLO (2{1} in Figure 9).
If there is more than one GLO, to which GLO the
request is forwarded is beyond the scope of this
document. Further processing by the GLO is discussed
in Section 4.7.2.
2. c.2.b、--、GLO以外のだれかが要求にサインしたなら、ほかに、GLAがglkCompromiseメッセージ(セクション3.2.3を見る)をGLOに転送する(2 1 図9)で。 1GLOがあれば、どのGLOに要求を転送するかはこのドキュメントの範囲を超えています。 セクション4.7.2でGLOによるさらなる処理について議論します。
4.7.2. GLO Initiated KEK Compromise Message
4.7.2. GLOはKEK妥協メッセージを開始しました。
The process for GLO initiated glkCompromise messages is as follows:
GLOがglkCompromiseメッセージを開始したので、過程は以下の通りです:
1 - The GLO either:
1 --GLO、どちらか:
1.a - Generates the glkCompromise message itself by sending a
SignedData.PKIData.controlSequence.glkCompromise request to
the GLA (5 in Figure 9). The GLO includes the name of the GL
in GeneralName. The GLO MUST also include a signingTime
attribute with this request.
1.、a--GLA(図9の5)にSignedData.PKIData.controlSequence.glkCompromise要求を送ることによって、glkCompromiseメッセージ自体を発生させます。 GLOはGeneralNameにGLという名前を含んでいます。 また、GLO MUSTはこの要求があるsigningTime属性を含んでいます。
Turner Standards Track [Page 67] RFC 5275 CMS SymKeyDist June 2008
5275cmのターナー標準化過程[67ページ]RFC SymKeyDist2008年6月
1.a.1 - The GLO can optionally apply confidentiality to the
request by encapsulating the SignedData.PKIData in an
EnvelopedData (see Section 3.2.1.2). The glkCompromise
can be included in an EnvelopedData generated with the
compromised shared KEK.
セクション3.2を見てください。1. a.1--缶がEnvelopedDataでSignedData.PKIDataを要約しながら任意に要求への秘密性を適用するGLO、(.1 .2)。 妥協している共有されたKEKと共に発生するEnvelopedDataにglkCompromiseを含むことができます。
1.a.2 - The GLO can also optionally apply another SignedData over
the EnvelopedData (see Section 3.2.1.2).
セクション3.2を見てください。1. a.2、--、また、GLOが任意に別のSignedDataをEnvelopedDataの上に適用できる(.1 .2)。
1.b - Otherwise, checks the signingTime and verifies the GLA and GL
member signatures on the forwarded glkCompromise message. If
an additional SignedData and/or EnvelopedData encapsulates
the request (see Section 3.2.1.2 or 3.2.2), the GLO verifies
the outer signature and/or decrypts the outer layer prior to
verifying the signature on the innermost SignedData.
1.、b--そうでなければ、signingTimeをチェックして、転送されたglkCompromiseメッセージでGLAとGLメンバー署名について確かめます。 または、追加SignedData、そして/または、EnvelopedDataが要求を要約する、(セクション3.2.1を見てください、.2、3.2 .2) 最も奥深いSignedDataで署名について確かめる前に、GLOは外側の署名について確かめる、そして/または、外側の層を解読します。
1.b.1 - If the signingTime attribute value is not within the
locally accepted time window, the GLO MAY return a
response indicating cMCStatus.failed and
otherInfo.failInfo.badTime and a signingTime attribute.
1. b.1--signingTimeであるなら値を結果と考えてください。局所的に受け入れられたタイムウィンドウ、cMCStatus.failedとotherInfo.failInfo.badTimeを示すGLO MAYリターンa応答、およびsigningTime属性の中にありません。
1.b.2 - Else if signature processing continues and if the
signatures cannot be verified, the GLO returns a
cMCStatusInfoExt response indicating cMCStatus.failed and
otherInfo.failInfo.badMessageCheck. Additionally, a
signingTime attribute is included with the response.
1. b.2--署名処理が続いて、署名がそうすることができないなら、ほかに、確かめられてください、そして、GLOはcMCStatus.failedとotherInfo.failInfo.badMessageCheckを示すcMCStatusInfoExt応答を返します。 さらに、signingTime属性は応答で含まれています。
1.b.2.a - If the signatures verify, the GLO checks that the
names in the certificate match the name of the signer
(i.e., the name in the certificate used to sign the
GL member's request is the GL member).
1. b.2.a--、署名が確かめる、GLOは、証明書の名前が署名者の名前に合っているのをチェックします(すなわち、GLメンバーの要求にサインするのに使用される証明書の名前はGLメンバーです)。
1.b.2.a.1 - If either name does not match, the GLO ought not
trust the signer and it ought not forward the
message to the GLA.
1. b.2.a.1--どちらかの名前がそうしないなら、合ってください、そして、GLOは、メッセージをGLAに転送しないと信じません。
1.b.2.a.2 - Else if the names match and the signatures
verify, the GLO determines whether to forward the
glkCompromise message back to the GLA (3{1} in
Figure 9). Further processing by the GLA is in 2
of Section 4.7.1. The GLO can also return a
response to the prospective member with
cMCStatusInfoExt.cMCtatus.success indicating that
the glkCompromise message was successfully
received.
1. b.2.a.2--マッチと署名が確かめる名前、GLOが、glkCompromiseを進めるかどうか決定するならほかに、GLAへ通信して戻ってください、(3 1 図9)で。 セクション4.7.1の2にはGLAによるさらなる処理があります。 また、GLOはglkCompromiseメッセージが首尾よく受け取られたのを示すcMCStatusInfoExt.cMCtatus.successの将来のメンバーへの応答を返すことができます。
Turner Standards Track [Page 68] RFC 5275 CMS SymKeyDist June 2008
5275cmのターナー標準化過程[68ページ]RFC SymKeyDist2008年6月
4.8. Request KEK Refresh
4.8. KEKがリフレッシュするよう要求してください。
There will be times when GL members have irrecoverably lost their shared KEK. The shared KEK is not compromised and a rekey of the entire GL is not necessary. GL members use the glkRefresh message to request that the shared KEK(s) be redistributed to them. Figure 10 depicts the protocol interactions for GL Key Refresh. Note that error messages are not shown. Additionally, behavior for the optional transactionId, senderNonce, and recipientNonce CMC control attributes is not addressed in these procedures.
GLメンバーが回復不可能なほど彼らの共有されたKEKをなくした回があるでしょう。 共有されたKEKは妥協しません、そして、全体のGLのrekeyは必要ではありません。 GLメンバーは共有されたKEK(s)が彼らに再配付されるよう要求するglkRefreshメッセージを使用します。 図10はGL Key Refreshのためにプロトコル相互作用について表現します。 エラーメッセージが示されないことに注意してください。 さらに、任意のtransactionId、senderNonce、およびrecipientNonce CMCコントロール属性のための振舞いはこれらの手順で記述されません。
+-----+ 1 2 +----------+ | GLA | <-----------> | Member | +-----+ +----------+
+-----+ 1 2 +----------+ | GLA| <、-、-、-、-、-、-、-、-、-、--、>| メンバー| +-----+ +----------+
Figure 10 - GL KEK Refresh
図10--GL KEKはリフレッシュします。
The process for glkRefresh is as follows:
glkRefreshのための過程は以下の通りです:
1 - The GL member sends a
SignedData.PKIData.controlSequence.glkRefresh request to the GLA
(1 in Figure 10). The GL member includes name of the GL in
GeneralName. The GL member MUST also include a signingTime
attribute with this request.
1--GLメンバーはGLA(図10の1)にSignedData.PKIData.controlSequence.glkRefresh要求を送ります。 GLメンバーはGeneralNameでGLという名前を入れます。 また、GLメンバーはこの要求があるsigningTime属性を入れなければなりません。
1.a - The GL member can optionally apply confidentiality to the
request by encapsulating the SignedData.PKIData in an
EnvelopedData (see Section 3.2.1.2).
セクション3.2を見てください。1. a--メンバーがEnvelopedDataでSignedData.PKIDataを要約しながら任意に要求への秘密性を適用できるGL、(.1 .2)。
1.b - The GL member can also optionally apply another SignedData
over the EnvelopedData (see Section 3.2.1.2).
セクション3.2を見てください。1. b、--、また、GLメンバーが任意に別のSignedDataをEnvelopedDataの上に適用できる(.1 .2)。
2 - Upon receipt of the glkRefresh request, the GLA checks the
signingTime and verifies the GL member signature(s). If an
additional SignedData and/or EnvelopedData encapsulates the
request (see Section 3.2.1.2 or 3.2.2), the GLA verifies the
outer signature and/or decrypt the outer layer prior to verifying
the signature on the innermost SignedData.
2--glkRefresh要求を受け取り次第、GLAはsigningTimeをチェックして、GLメンバー署名について確かめます。 または、追加SignedData、そして/または、EnvelopedDataが要求を要約する、(セクション3.2.1を見てください、.2、3.2 .2) 最も奥深いSignedDataで署名について確かめる前に、GLAは外側の署名について確かめる、そして/または、外側の層を解読します。
2.a - If the signingTime attribute value is not within the locally
accepted time window, the GLA MAY return a response
indicating cMCStatus.failed and otherInfo.failInfo.badTime
and a signingTime attribute.
2. a--signingTimeであるなら値を結果と考えてください。局所的に受け入れられたタイムウィンドウ、cMCStatus.failedとotherInfo.failInfo.badTimeを示すGLA MAYリターンa応答、およびsigningTime属性の中にありません。
Turner Standards Track [Page 69] RFC 5275 CMS SymKeyDist June 2008
5275cmのターナー標準化過程[69ページ]RFC SymKeyDist2008年6月
2.b - Else if signature processing continues and if the signatures
cannot be verified, the GLA returns a cMCStatusInfoExt
response indicating cMCStatus.failed and
otherInfo.failInfo.badMessageCheck. Additionally, a
signingTime attribute is included with the response.
2. b--署名処理が続いて、署名がそうすることができないなら、ほかに、確かめられてください、そして、GLAはcMCStatus.failedとotherInfo.failInfo.badMessageCheckを示すcMCStatusInfoExt応答を返します。 さらに、signingTime属性は応答で含まれています。
2.c - Else if the signatures verify, the GLA makes sure the GL is
supported by checking that the GLGeneralName matches a glName
stored on the GLA.
2. c--、ほか、GLGeneralNameマッチa glNameがGLAに格納したGLが支持されるのを確信しているGLA造がチェックして、署名は確かめます。
2.c.1 - If the name of the GL is not supported by the GLA, the
GLA returns a response indicating cMCStatusInfoExt with
cMCStatus.failed and
otherInfo.extendedFailInfo.SKDFailInfo value of
invalidGLName. Additionally, a signingTime attribute is
included with the response.
2.、c.1--GLという名前がGLAによってサポートされないなら、GLAはinvalidGLNameのcMCStatus.failedとotherInfo.extendedFailInfo.SKDFailInfo値でcMCStatusInfoExtを示す応答を返します。 さらに、signingTime属性は応答で含まれています。
2.c.2 - Else if the glName is supported by the GLA, the GLA
ensures that the GL member is on the GL.
2.、c.2--ほかに、glNameがGLAによって支持されるなら、GLAは、GLメンバーがGLにいるのを確実にします。
2.c.2.a - If the glMemberName is not present on the GL, the GLA
returns a response indicating cMCStatusInfoExt with
cMCStatus.failed and
otherInfo.extendedFailInfo.SKDFailInfo value of
noSpam. Additionally, a signingTime attribute is
included with the response.
2. c.2.a--glMemberNameがそうでないならGL、GLAにリターンを提示してください。cMCStatus.failedと共にcMCStatusInfoExtを示す応答とnoSpamのotherInfo.extendedFailInfo.SKDFailInfo値。 さらに、signingTime属性は応答で含まれています。
2.c.2.b - Else if the glMemberName is present on the GL, the
GLA returns a cMCStatusInfoExt.cMCStatus.success, a
signingTime attribute, and a glKey message (2 in
Figure 10) as described in Section 5.
2. c.2.b--ほかに、glMemberNameがそうならGL、GLAリターンのときにcMCStatusInfoExt.cMCStatus.successを寄贈してください、signingTime属性、そして、a glKeyはセクション5で説明されるように(図10の2)を通信させます。
4.9. GLA Query Request and Response
4.9. GLAは要求と応答について質問します。
There will be certain times when a GLO is having trouble setting up a GL because it does not know the algorithm(s) or some other characteristic that the GLA supports. There can also be times when prospective GL members or GL members need to know something about the GLA (these requests are not defined in the document). The glaQueryRequest and glaQueryResponse messages have been defined to support determining this information. Figure 11 depicts the protocol interactions for glaQueryRequest and glaQueryResponse. Note that error messages are not shown. Additionally, behavior for the optional transactionId, senderNonce, and recipientNonce CMC control attributes is not addressed in these procedures.
GLOがアルゴリズムかGLAが支持するある他の特性を知らないのでGLをセットアップすることにおける苦労をするある回があるでしょう。 また、将来のGLメンバーかGLメンバーがGLAに関して何かを知る必要がある(これらの要求はドキュメントで定義されません)回があることができます。 glaQueryRequestとglaQueryResponseメッセージは、この情報を決定するのを支持するために定義されました。 図11はglaQueryRequestとglaQueryResponseのためにプロトコル相互作用について表現します。 エラーメッセージが示されないことに注意してください。 さらに、任意のtransactionId、senderNonce、およびrecipientNonce CMCコントロール属性のための振舞いはこれらの手順で記述されません。
Turner Standards Track [Page 70] RFC 5275 CMS SymKeyDist June 2008
5275cmのターナー標準化過程[70ページ]RFC SymKeyDist2008年6月
+-----+ 1 2 +------------------+
| GLA | <-------> | GLO or GL Member |
+-----+ +------------------+
+-----+ 1 2 +------------------+ | GLA| <、-、-、-、-、-、--、>| GLOかGLメンバー| +-----+ +------------------+
Figure 11 - GLA Query Request and Response
図11--GLAは要求と応答について質問します。
The process for glaQueryRequest and glaQueryResponse is as follows:
glaQueryRequestとglaQueryResponseのための過程は以下の通りです:
1 - The GLO, GL member, or prospective GL member sends a
SignedData.PKIData.controlSequence.glaQueryRequest request to the
GLA (1 in Figure 11). The GLO, GL member, or prospective GL
member indicates the information it is interested in receiving
from the GLA. Additionally, a signingTime attribute is included
with this request.
1--GLO、GLメンバー、または将来のGLメンバーがGLA(図11の1)にSignedData.PKIData.controlSequence.glaQueryRequest要求を送ります。 GLO、GLメンバー、または将来のGLメンバーが受け取るそれはGLAから関心がある情報を示します。 さらに、signingTime属性はこの要求で含まれています。
1.a - The GLO, GL member, or prospective GL member can optionally
apply confidentiality to the request by encapsulating the
SignedData.PKIData in an EnvelopedData (see Section 3.2.1.2).
セクション3.2を見てください。1. a--缶がEnvelopedDataでSignedData.PKIDataを要約しながら任意に要求への秘密性を適用するGLO、GLメンバー、または将来のGLメンバー、(.1 .2)。
1.b - The GLO, GL member, or prospective GL member can also
optionally apply another SignedData over the EnvelopedData
(see Section 3.2.1.2).
セクション3.2を見てください。1. b、--、また、GLO、GLメンバー、または将来のGLメンバーが任意に別のSignedDataをEnvelopedDataの上に適用できる(.1 .2)。
2 - Upon receipt of the glaQueryRequest, the GLA determines if it
accepts glaQueryRequest messages.
2--glaQueryRequestを受け取り次第、GLAは、それがglaQueryRequestメッセージを受け入れるかどうか決定します。
2.a - If the GLA does not accept glaQueryRequest messages, the GLA
returns a cMCStatusInfoExt response indicating
cMCStatus.noSupport and any other information in
statusString.
2. a--GLAがそうしないなら、glaQueryRequestメッセージを受け入れてください、そして、GLAはcMCStatus.noSupportを示すcMCStatusInfoExt応答とstatusStringのいかなる他の情報も返します。
2.b - Else if the GLA does accept GLAQueryRequests, the GLA checks
the signingTime and verifies the GLO, GL member, or
prospective GL member signature(s). If an additional
SignedData and/or EnvelopedData encapsulates the request (see
Section 3.2.1.2 or 3.2.2), the GLA verifies the outer
signature and/or decrypts the outer layer prior to verifying
the signature on the innermost SignedData.
2. b--GLAがそうするならほかに、GLAQueryRequestsを受け入れてください、GLAはsigningTimeをチェックして、GLO、GLメンバー、または将来のGLメンバー署名について確かめます。 または、追加SignedData、そして/または、EnvelopedDataが要求を要約する、(セクション3.2.1を見てください、.2、3.2 .2) 最も奥深いSignedDataで署名について確かめる前に、GLAは外側の署名について確かめる、そして/または、外側の層を解読します。
2.b.1 - If the signingTime attribute value is not within the
locally accepted time window, the GLA MAY return a
response indicating cMCStatus.failed and
otherInfo.failInfo.badTime and a signingTime attribute.
2. b.1--signingTimeであるなら値を結果と考えてください。局所的に受け入れられたタイムウィンドウ、cMCStatus.failedとotherInfo.failInfo.badTimeを示すGLA MAYリターンa応答、およびsigningTime属性の中にありません。
Turner Standards Track [Page 71] RFC 5275 CMS SymKeyDist June 2008
5275cmのターナー標準化過程[71ページ]RFC SymKeyDist2008年6月
2.b.2 - Else if the signature processing continues and if the
signatures cannot be verified, the GLA returns a
cMCStatusInfoExt response indicating cMCStatus.failed and
otherInfo.failInfo.badMessageCheck. Additionally, a
signingTime attribute is included with the response.
2. b.2--署名処理が続いて、署名がそうすることができないなら、ほかに、確かめられてください、そして、GLAはcMCStatus.failedとotherInfo.failInfo.badMessageCheckを示すcMCStatusInfoExt応答を返します。 さらに、signingTime属性は応答で含まれています。
2.b.3 - Else if the signatures verify, the GLA returns a
glaQueryResponse (2 in Figure 11) with the correct
response if the glaRequestType is supported or returns a
cMCStatusInfoExt response indicating cMCStatus.noSupport
if the glaRequestType is not supported. Additionally, a
signingTime attribute is included with the response.
2. b.3--、ほか、署名が確かめる、glaRequestTypeが支持されるか、またはglaRequestTypeが支持されないならcMCStatus.noSupportを示すcMCStatusInfoExt応答を返すなら、GLAは正しい応答と共にglaQueryResponse(図11の2)を返します。 さらに、signingTime属性は応答で含まれています。
2.b.3.a - The GLA applies confidentiality to the response by
encapsulating the SignedData.PKIResponse in an
EnvelopedData if the request was encapsulated in an
EnvelopedData (see Section 3.2.1.2).
セクション3.2を見てください。2. b.3.a、--、GLAが要求がEnvelopedDataで要約されたならEnvelopedDataでSignedData.PKIResponseを要約することによって秘密性を応答に適用する(.1 .2)。
2.b.3.b - The GLA can also optionally apply another SignedData
over the EnvelopedData (see Section 3.2.1.2).
セクション3.2を見てください。2. b.3.b、--、また、GLAが任意に別のSignedDataをEnvelopedDataの上に適用できる(.1 .2)。
3 - Upon receipt of the glaQueryResponse, the GLO, GL member, or
prospective GL member checks the signingTime and verifies the GLA
signature(s). If an additional SignedData and/or EnvelopedData
encapsulates the response (see Section 3.2.1.2 or 3.2.2), the
GLO, GL member, or prospective GL member verifies the outer
signature and/or decrypts the outer layer prior to verifying the
signature on the innermost SignedData.
glaQueryResponse、GLO、GLメンバー、または将来のGLメンバーを受け取り次第3は、signingTimeをチェックして、GLA署名について確かめます。 セクション3.2を見てください。追加SignedData、そして/または、EnvelopedDataが応答を要約する、(.1 .2)、GLO、GLメンバー、または将来のGLメンバーが最も奥深いSignedDataで署名について確かめながら外側の署名について確かめる、そして/または、外側の層を解読する.2か3.2。
3.a - If the signingTime attribute value is not within the locally
accepted time window, the GLO, GL member, or prospective GL
member MAY return a response indicating cMCStatus.failed and
otherInfo.failInfo.badTime and a signingTime attribute.
3. a--signingTimeであるなら値を結果と考えてください。局所的に受け入れられたタイムウィンドウか、GLOか、GLメンバーか、cMCStatus.failedとotherInfo.failInfo.badTimeを示す将来のGLメンバー5月のリターンa応答とsigningTime属性の中にありません。
3.b - Else if signature processing continues and if the signatures
do not verify, the GLO, GL member, or prospective GL member
returns a cMCStatusInfoExt response indicating
cMCStatus.failed and otherInfo.failInfo.badMessageCheck.
Additionally, a signingTime attribute is included with the
response.
3. b--ほかに、署名処理が続いて、署名であるならしてください、確かめない、GLO、GLメンバー、または将来のGLメンバーがcMCStatus.failedとotherInfo.failInfo.badMessageCheckを示すcMCStatusInfoExt応答を返します。 さらに、signingTime属性は応答で含まれています。
3.c - Else if the signatures verify, then the GLO, GL member, or
prospective GL member checks that one of the names in the
certificate used to sign the response matches the name of the
GL.
3. c--、ほか、署名が確かめる、そして、GLO、GLメンバー、または将来のGLメンバーが、応答にサインするのに使用される証明書の名前の1つがGLという名前に合っているのをチェックします。
Turner Standards Track [Page 72] RFC 5275 CMS SymKeyDist June 2008
5275cmのターナー標準化過程[72ページ]RFC SymKeyDist2008年6月
3.c.1 - If the name of the GL does not match the name present in
the certificate used to sign the message, the GLO ought
not believe the response.
3. c.1--GLという名前がそうしないなら、現在という名前を合わせてください。証明書には、メッセージは以前はよくサインしていました、とGLOが応答を信じていません。
3.c.2 - Else if the name of the GL matches the name present in
the certificate and the response was glaQueryResponse,
then the GLO, GL member, or prospective GL member may use
the information contained therein.
応答がglaQueryResponseであった、3. c.2--GLという名前が名前に合っているなら、ほかに、中に証明書を提示してください。そうすれば、次に、GLO、GLメンバー、または将来のGLメンバーがそこに含まれた情報を使用してもよいです。
4.10. Update Member Certificate
4.10. アップデートメンバー証明書
When the GLO generates a glAddMember request, when the GLA generates a glKey message, or when the GLA processes a glAddMember, there can be instances when the GL member's certificate has expired or is invalid. In these instances, the GLO or GLA may request that the GL member provide a new certificate to avoid the GLA from being unable to generate a glKey message for the GL member. There might also be times when the GL member knows that its certificate is about to expire or has been revoked, and GL member will not be able to receive GL rekeys. Behavior for the optional transactionId, senderNonce, and recipientNonce CMC control attributes is not addressed in these procedures.
GLOがいつ、glAddMember要求を発生させるか、そして、GLAがいつglKeyメッセージを発生させるか、そして、またはGLAがいつそこのglAddMemberを処理するかが、GLメンバーの証明書が期限が切れたときの例であることができるか無効です。 これらの例では、GLOかGLAが、GLメンバーがGLメンバーへのglKeyメッセージを発生させることができないのでGLAを避けるために新しい証明書を提供するよう要求するかもしれません。 また、GLメンバーが、証明書が期限が切れようとしているか、または取り消されたのを知っている回があるかもしれません、そして、GLメンバーはGL rekeysを受け取ることができないでしょう。 任意のtransactionId、senderNonce、およびrecipientNonce CMCコントロール属性のための振舞いはこれらの手順で記述されません。
4.10.1. GLO and GLA Initiated Update Member Certificate
4.10.1. GLOとGLAはアップデートメンバー証明書を開始しました。
The process for GLO initiated glUpdateCert is as follows:
GLOがglUpdateCertを開始したので、過程は以下の通りです:
1 - The GLO or GLA sends a
SignedData.PKIData.controlSequence.glProvideCert request to the
GL member. The GLO or GLA indicates the GL name in glName and
the GL member name in glMemberName. Additionally, a signingTime
attribute is included with this request.
1--GLOかGLAがSignedData.PKIData.controlSequence.glProvideCert要求をGLメンバーに送ります。 GLOかGLAがglNameのGL名とglMemberNameのGLメンバ名を示します。 さらに、signingTime属性はこの要求で含まれています。
1.a - The GLO or GLA can optionally apply confidentiality to the
request by encapsulating the SignedData.PKIData in an
EnvelopedData (see Section 3.2.1.2). If the GL member's PKC
has been revoked, the GLO or GLA ought not use it to generate
the EnvelopedData that encapsulates the glProvideCert
request.
セクション3.2を見てください。1. a--缶がEnvelopedDataでSignedData.PKIDataを要約しながら任意に要求への秘密性を適用するGLOかGLA、(.1 .2)。 GLメンバーのPKCが取り消されたなら、GLOかGLAが、glProvideCert要求を要約するEnvelopedDataを発生させるのにそれを使用しません。
1.b - The GLO or GLA can also optionally apply another SignedData
over the EnvelopedData (see Section 3.2.1.2).
セクション3.2を見てください。1. b、--、また、GLOかGLAが任意に別のSignedDataをEnvelopedDataの上に適用できる(.1 .2)。
Turner Standards Track [Page 73] RFC 5275 CMS SymKeyDist June 2008
5275cmのターナー標準化過程[73ページ]RFC SymKeyDist2008年6月
2 - Upon receipt of the glProvideCert message, the GL member checks
the signingTime and verifies the GLO or GLA signature(s). If an
additional SignedData and/or EnvelopedData encapsulates the
response (see Section 3.2.1.2 or 3.2.2), the GL member verifies
the outer signature and/or decrypts the outer layer prior to
verifying the signature on the innermost SignedData.
glProvideCertメッセージを受け取り次第2、GLメンバーはsigningTimeをチェックして、GLOかGLA署名について確かめます。 または、追加SignedData、そして/または、EnvelopedDataが応答を要約する、(セクション3.2.1を見てください、.2、3.2 .2) 最も奥深いSignedDataで署名について確かめる前に、GLメンバーは、外側の署名について確かめる、そして/または、外側の層を解読します。
2.a - If the signingTime attribute value is not within the locally
accepted time window, the GL member MAY return a response
indicating cMCStatus.failed and otherInfo.failInfo.badTime
and a signingTime attribute.
2. a--signingTimeであるなら値を結果と考えてください。局所的に受け入れられたタイムウィンドウ、cMCStatus.failedとotherInfo.failInfo.badTimeを示すGLメンバー5月のリターンa応答、およびsigningTime属性の中にありません。
2.b - Else if signature processing continues and if the signatures
cannot be verified, the GL member returns a cMCStatusInfoExt
response indicating cMCStatus.failed and
otherInfo.failInfo.badMessageCheck. Additionally, a
signingTime attribute is included with the response.
2. b--署名処理が続いて、署名がそうすることができないなら、ほかに、確かめられてください、そして、GLメンバーはcMCStatus.failedとotherInfo.failInfo.badMessageCheckを示すcMCStatusInfoExt応答を返します。 さらに、signingTime属性は応答で含まれています。
2.c - Else if the signatures verify, the GL member generates a
Signed.PKIResponse.controlSequence.glUpdateCert that includes
the GL name in glName, the member's name in
glMember.glMemberName, the member's encryption certificate in
glMember.certificates.pKC. The GL member can also include
any attribute certificates associated with the member's
encryption certificate in glMember.certificates.aC, and the
certification path associated with the member's encryption
and attribute certificates in glMember.certificates.certPath.
Additionally, a signingTime attribute is included with the
response.
2. c--、ほか、署名が確かめる、GLメンバーはglName、glMember.glMemberName(glMember.certificates.pKCのメンバーの暗号化証明書)のメンバーの名前にGL名を含んでいるSigned.PKIResponse.controlSequence.glUpdateCertを発生させます。 また、GLメンバーはglMember.certificates.aCのメンバーの暗号化証明書とメンバーの暗号化に関連している証明経路とglMember.certificates.certPathの属性証明書に関連しているどんな属性証明書も入れることができます。 さらに、signingTime属性は応答で含まれています。
2.c.1 - The GL member can optionally apply confidentiality to the
request by encapsulating the SignedData.PKIResponse in an
EnvelopedData (see Section 3.2.1.2). If the GL member's
PKC has been revoked, the GL member ought not use it to
generate the EnvelopedData that encapsulates the
glProvideCert request.
セクション3.2を見てください。2. c.1--メンバーがEnvelopedDataでSignedData.PKIResponseを要約しながら任意に要求への秘密性を適用できるGL、(.1 .2)。 GLメンバーのPKCが取り消されたなら、GLメンバーは、glProvideCert要求を要約するEnvelopedDataを発生させるのにそれを使用しません。
2.c.2 - The GL member can also optionally apply another
SignedData over the EnvelopedData (see Section 3.2.1.2).
セクション3.2を見てください。2. c.2、--、また、GLメンバーが任意に別のSignedDataをEnvelopedDataの上に適用できる(.1 .2)。
3 - Upon receipt of the glUpdateCert message, the GLO or GLA checks
the signingTime and verifies the GL member signature(s). If an
additional SignedData and/or EnvelopedData encapsulates the
response (see Section 3.2.1.2 or 3.2.2), the GL member verifies
the outer signature and/or decrypts the outer layer prior to
verifying the signature on the innermost SignedData.
glUpdateCertメッセージを受け取り次第3、GLOかGLAがsigningTimeをチェックして、GLメンバー署名について確かめます。 または、追加SignedData、そして/または、EnvelopedDataが応答を要約する、(セクション3.2.1を見てください、.2、3.2 .2) 最も奥深いSignedDataで署名について確かめる前に、GLメンバーは、外側の署名について確かめる、そして/または、外側の層を解読します。
Turner Standards Track [Page 74] RFC 5275 CMS SymKeyDist June 2008
5275cmのターナー標準化過程[74ページ]RFC SymKeyDist2008年6月
3.a - If the signingTime attribute value is not within the locally
accepted time window, the GLO or GLA MAY return a response
indicating cMCStatus.failed and otherInfo.failInfo.badTime
and a signingTime attribute.
3. a--signingTimeであるなら値を結果と考えてください。cMCStatus.failed、otherInfo.failInfo.badTime、およびsigningTime属性を示す局所的に受け入れられたタイムウィンドウ、GLOまたはGLA MAYリターンa応答の中にありません。
3.b - Else if signature processing continues and if the signatures
cannot be verified, the GLO or GLA returns a cMCStatusInfoExt
response indicating cMCStatus.failed and
otherInfo.failInfo.badMessageCheck. Additionally, a
signingTime attribute is included with the response.
3. b--署名処理が続いて、署名がそうすることができないなら、ほかに、確かめられてください、そして、GLOかGLAがcMCStatus.failedとotherInfo.failInfo.badMessageCheckを示すcMCStatusInfoExt応答を返します。 さらに、signingTime属性は応答で含まれています。
3.c - Else if the signatures verify, the GLO or GLA verifies the
member's encryption certificate.
3. c--、ほか、署名が確かめる、GLOかGLAがメンバーの暗号化証明書について確かめます。
3.c.1 - If the member's encryption certificate cannot be
verified, the GLO returns either another glProvideCert
request or a cMCStatusInfoExt with cMCStatus.failed and
the reason why in cMCStatus.statusString. glProvideCert
should be returned only a certain number of times is
because if the GL member does not have a valid
certificate it will never be able to return one.
Additionally, a signingTime attribute is included with
either response.
GLOはcMCStatus.failedと別のglProvideCert要求かcMCStatusInfoExtのどちらかを返します、そして、c.1--メンバーの暗号化証明書がそうすることができないなら、確かめてください、そして、GLメンバーに有効な証明書がないと1つを決して返すことができないので、3. ある数の回だけをcMCStatus.statusString. glProvideCertのなぜに返すべきであるか理由は返します。 さらに、signingTime属性は応答で含まれています。
3.c.2 - Else if the member's encryption certificate cannot be
verified, the GLA returns another glProvideCert request
to the GL member or a cMCStatusInfoExt with
cMCStatus.failed and the reason why in
cMCStatus.statusString to the GLO. glProvideCert should
be returned only a certain number of times because if the
GL member does not have a valid certificate it will never
be able to return one. Additionally, a signingTime
attribute is included with the response.
GLAはGLメンバーかcMCStatus.failedとcMCStatusInfoExtに別のglProvideCert要求を返します、そして、3. c.2--メンバーの暗号化証明書がそうすることができないなら、ほかに、確かめてください、そして、GLメンバーに有効な証明書がないと1つを決して返すことができないので、ある数の回だけをGLO. glProvideCertへのcMCStatus.statusStringの理由に返すべきです。 さらに、signingTime属性は応答で含まれています。
3.c.3 - Else if the member's encryption certificate verifies, the
GLO or GLA will use it in subsequent glAddMember requests
and glKey messages associated with the GL member.
3. c.3--証明書が確かめるメンバーの暗号化、GLOまたはGLAがそうするなら、ほかに、GLメンバーに関連しているその後のglAddMember要求とglKeyメッセージでそれを使用してください。
4.10.2. GL Member Initiated Update Member Certificate
4.10.2. GLメンバーはアップデートメンバー証明書を開始しました。
The process for an unsolicited GL member glUpdateCert is as follows:
求められていないGLメンバーglUpdateCertのための過程は以下の通りです:
1 - The GL member sends a Signed.PKIData.controlSequence.glUpdateCert
that includes the GL name in glName, the member's name in
glMember.glMemberName, the member's encryption certificate in
glMember.certificates.pKC. The GL member can also include any
attribute certificates associated with the member's encryption
certificate in glMember.certificates.aC, and the certification
1--GLメンバーはglNameのGL名を含んでいるSigned.PKIData.controlSequence.glUpdateCertを送ります、glMember.glMemberNameのメンバーの名前、glMember.certificates.pKCのメンバーの暗号化証明書。 また、GLメンバーはglMember.certificates.aC、および証明でメンバーの暗号化証明書に関連しているどんな属性証明書も入れることができます。
Turner Standards Track [Page 75] RFC 5275 CMS SymKeyDist June 2008
5275cmのターナー標準化過程[75ページ]RFC SymKeyDist2008年6月
path associated with the member's encryption and attribute
certificates in glMember.certificates.certPath. The GL member
MUST also include a signingTime attribute with this request.
glMember.certificates.certPathのメンバーの暗号化と属性証明書に関連している経路。 また、GLメンバーはこの要求があるsigningTime属性を入れなければなりません。
1.a - The GL member can optionally apply confidentiality to the
request by encapsulating the SignedData.PKIData in an
EnvelopedData (see Section 3.2.1.2). If the GL member's PKC
has been revoked, the GLO or GLA ought not use it to generate
the EnvelopedData that encapsulates the glProvideCert
request.
セクション3.2を見てください。1. a--メンバーがEnvelopedDataでSignedData.PKIDataを要約しながら任意に要求への秘密性を適用できるGL、(.1 .2)。 GLメンバーのPKCが取り消されたなら、GLOかGLAが、glProvideCert要求を要約するEnvelopedDataを発生させるのにそれを使用しません。
1.b - The GL member can also optionally apply another SignedData
over the EnvelopedData (see Section 3.2.1.2).
セクション3.2を見てください。1. b、--、また、GLメンバーが任意に別のSignedDataをEnvelopedDataの上に適用できる(.1 .2)。
2 - Upon receipt of the glUpdateCert message, the GLA checks the
signingTime and verifies the GL member signature(s). If an
additional SignedData and/or EnvelopedData encapsulates the
response (see Section 3.2.1.2 or 3.2.2), the GLA verifies the
outer signature and/or decrypts the outer layer prior to
verifying the signature on the innermost SignedData.
2--glUpdateCertメッセージを受け取り次第、GLAはsigningTimeをチェックして、GLメンバー署名について確かめます。 または、追加SignedData、そして/または、EnvelopedDataが応答を要約する、(セクション3.2.1を見てください、.2、3.2 .2) 最も奥深いSignedDataで署名について確かめる前に、GLAは外側の署名について確かめる、そして/または、外側の層を解読します。
2.a - If the signingTime attribute value is not within the locally
accepted time window, the GLA MAY return a response
indicating cMCStatus.failed and otherInfo.failInfo.badTime
and a signingTime attribute.
2. a--signingTimeであるなら値を結果と考えてください。局所的に受け入れられたタイムウィンドウ、cMCStatus.failedとotherInfo.failInfo.badTimeを示すGLA MAYリターンa応答、およびsigningTime属性の中にありません。
2.b - Else if signature processing continues and if the signatures
cannot be verified, the GLA returns a cMCStatusInfoExt
response indicating cMCStatus.failed and
otherInfo.failInfo.badMessageCheck.
2. b--署名処理が続いて、署名がそうすることができないなら、ほかに、確かめられてください、そして、GLAはcMCStatus.failedとotherInfo.failInfo.badMessageCheckを示すcMCStatusInfoExt応答を返します。
2.c - Else if the signatures verify, the GLA verifies the member's
encryption certificate.
2. c--、ほか、署名が確かめる、GLAはメンバーの暗号化証明書について確かめます。
2.c.1 - If the member's encryption certificate cannot be
verified, the GLA returns another glProvideCert request
to the GL member or a cMCStatusInfoExt with
cMCStatus.failed and the reason why in
cMCStatus.statusString to the GLO. glProvideCert ought
not be returned indefinitely; if the GL member does not
have a valid certificate it will never be able to return
one. Additionally, a signingTime attribute is included
with the response.
2. c.1メンバーの暗号化証明書について確かめることができないか、GLAが別のglProvideCert要求をGLメンバーに返すか、またはcMCStatus.failedとcMCStatusInfoExtとGLO. glProvideCertへのcMCStatus.statusStringの理由が無期限に返されないなら GLメンバーに有効な証明書がないと、1つを決して返すことができないでしょう。 さらに、signingTime属性は応答で含まれています。
2.c.2 - Else if the member's encryption certificate verifies, the
GLA will use it in subsequent glAddMember requests and
glKey messages associated with the GL member. The GLA
also forwards the glUpdateCert message to the GLO.
2.、c.2--ほかに、証明書が確かめる暗号化、GLAはメンバーのものであるならその後のglAddMember要求でそれを使用して、glKeyはGLメンバーに関連していた状態で通信します。 また、GLAはglUpdateCertメッセージをGLOに転送します。
Turner Standards Track [Page 76] RFC 5275 CMS SymKeyDist June 2008
5275cmのターナー標準化過程[76ページ]RFC SymKeyDist2008年6月
5. Distribution Message
5. 分配メッセージ
The GLA uses the glKey message to distribute new, shared KEK(s) after receiving glAddMember, glDeleteMember (for closed and managed GLs), glRekey, glkCompromise, or glkRefresh requests and returning a cMCStatusInfoExt response for the respective request. Figure 12 depicts the protocol interactions to send out glKey messages. Unlike the procedures defined for the administrative messages, the procedures defined in this section MUST be implemented by GLAs for origination and by GL members on reception. Note that error messages are not shown. Additionally, behavior for the optional transactionId, senderNonce, and recipientNonce CMC control attributes is not addressed in these procedures.
GLAは新しい状態で分配するglKeyメッセージを使用します、とglAddMember、glDeleteMember(閉じていて管理されたGLsのための)、glRekey、glkCompromise、またはglkRefresh要求を受け取って、それぞれの要求のためのcMCStatusInfoExt応答を返した後に、KEK(s)は共有しました。 図12は、glKeyメッセージを出すためにプロトコル相互作用について表現します。 管理メッセージのために定義された手順と異なって、創作のためのGLAsとレセプションのGLメンバーはこのセクションで定義された手順を実行しなければなりません。 エラーメッセージが示されないことに注意してください。 さらに、任意のtransactionId、senderNonce、およびrecipientNonce CMCコントロール属性のための振舞いはこれらの手順で記述されません。
1 +----------+
+-------> | Member 1 |
| +----------+
+-----+ | 1 +----------+
| GLA | ----+-------> | ... |
+-----+ | +----------+
| 1 +----------+
+-------> | Member n |
+----------+
1 +----------+ +------->| メンバー1| | +----------+ +-----+ | 1 +----------+ | GLA| ----+------->| ... | +-----+ | +----------+ | 1 +----------+ +------->| メンバーn| +----------+
Figure 12 - GL Key Distribution
図12--GLの主要な分配
If the GL was set up with GLKeyAttributes.recipientsNotMutuallyAware set to TRUE, a separate glKey message MUST be sent to each GL member so as not to divulge information about the other GL members.
TRUEに用意ができているGLKeyAttributes.recipientsNotMutuallyAwareと共にGLをセットアップしたなら、他のGLメンバーの情報を明かさないように別々のglKeyメッセージをそれぞれのGLメンバーに送らなければなりません。
When the glKey message is generated as a result of a:
glKeyがいつ通信するかはaの結果、発生します:
- glAddMember request,
- glAddMember要求
- glkComrpomise indication,
- glkComrpomiseする、指示
- glkRefresh request,
- glkRefresh要求
- glDeleteMember request with the GL's glAdministration set to
managed or closed, and
- そしてglDeleteMemberが、GLのglAdministrationと共に管理されるか閉じられるのにセットするよう要求する。
- glRekey request with generationCounter set to zero (0).
- glRekeyは、generationCounterと共に(0)のゼロを合わせるようセットに要求します。
The GLA MUST use either the kari (see Section 12.3.2 of [CMS]) or ktri (see Section 12.3.1 of [CMS]) choice in glKey.glkWrapped.RecipientInfo to ensure that only the intended recipients receive the shared KEK. The GLA MUST support the ktri choice.
GLA MUSTは、意図している受取人だけが共有されたKEKを受け取るのを保証するのにglKey.glkWrapped.RecipientInfoでのkari(.2セクション12.3[CMS]を見る)かktri(.1セクション12.3[CMS]を見る)選択を使用します。 GLA MUSTはktri選択を支持します。
Turner Standards Track [Page 77] RFC 5275 CMS SymKeyDist June 2008
5275cmのターナー標準化過程[77ページ]RFC SymKeyDist2008年6月
When the glKey message is generated as a result of a glRekey request with generationCounter greater than zero (0) or when the GLA controls rekeys, the GLA MAY use the kari, ktri, or kekri (see Section 12.3.3 of [CMS]) in glKey.glkWrapped.RecipientInfo to ensure that only the intended recipients receive the shared KEK. The GLA MUST support the RecipientInfo.ktri choice.
glKeyメッセージが(0)のゼロを合わせるか、またはGLAが「再-キー」を制御するという場合にgenerationCounterが、よりすばらしいglRekey要求の結果、発生するとき、GLA MAYは、意図している受取人だけが共有されたKEKを受け取るのを保証するのに、glKey.glkWrapped.RecipientInfoでkari、ktri、またはkekri(.3セクション12.3[CMS]を見る)を使用します。 GLA MUSTはRecipientInfo.ktri選択を支持します。
5.1. Distribution Process
5.1. 分配の過程
When a glKey message is generated, the process is as follows:
glKeyメッセージが発生するとき、過程は以下の通りです:
1 - The GLA MUST send a SignedData.PKIData.controlSequence.glKey to
each member by including glName, glIdentifier, glkWrapped,
glkAlgorithm, glkNotBefore, and glkNotAfter. If the GLA cannot
generate a glKey message for the GL member because the GL
member's PKC has expired or is otherwise invalid, the GLA MAY
send a glUpdateCert to the GL member requesting a new certificate
be provided (see Section 4.10). The number of glKey messages
generated for the GL is described in Section 3.1.13.
Additionally, a signingTime attribute is included with the
distribution message(s).
1--GLA MUSTは、glName、glIdentifier、glkWrapped、glkAlgorithm、glkNotBefore、およびglkNotAfterを含んでいることによって、各メンバーにSignedData.PKIData.controlSequence.glKeyを送ります。 GLAがGLメンバーのPKCが期限が切れたのでGLメンバーへのglKeyメッセージを発生させることができませんし、そうでなければ、無効でもあるなら、GLA MAYは新しい証明書が提供されるよう要求するGLメンバーにglUpdateCertを送ります(セクション4.10を見てください)。 GLのために発生するglKeyメッセージの数はセクション3.1.13で説明されます。 さらに、signingTime属性は分配メッセージで含まれています。
1.a - The GLA MAY optionally apply another confidentiality layer to
the message by encapsulating the SignedData.PKIData in
another EnvelopedData (see Section 3.2.1.2).
セクション3.2を見てください。1. a、--、GLA MAYが別のEnvelopedDataでSignedData.PKIDataを要約することによって別の秘密性層をメッセージに任意に適用する(.1 .2)。
1.b - The GLA MAY also optionally apply another SignedData over the
EnvelopedData.SignedData.PKIData (see Section 3.2.1.2).
セクション3.2を見てください。1. b、--、また、GLA MAYが任意に別のSignedDataをEnvelopedData.SignedData.PKIDataの上に適用する(.1 .2)。
2 - Upon receipt of the glKey message, the GL members MUST check the
signingTime and verify the signature over the innermost
SignedData.PKIData. If an additional SignedData and/or
EnvelopedData encapsulates the message (see Section 3.2.1.2 or
3.2.2), the GL member MUST verify the outer signature and/or
decrypt the outer layer prior to verifying the signature on the
SignedData.PKIData.controlSequence.glKey.
glKeyメッセージを受け取り次第2、GLメンバーは最も奥深いSignedData.PKIDataの上でsigningTimeをチェックして、署名について確かめなければなりません。 または、追加SignedData、そして/または、EnvelopedDataがメッセージを要約する、(セクション3.2.1を見てください、.2、3.2 .2) SignedData.PKIData.controlSequence.glKeyで署名について確かめる前に、GLメンバーは、外側の署名について確かめる、そして/または、外側の層を解読しなければなりません。
2.a - If the signingTime attribute value is not within the locally
accepted time window, the GLA MAY return a response
indicating cMCStatus.failed and otherInfo.failInfo.badTime
and a signingTime attribute.
2. a--signingTimeであるなら値を結果と考えてください。局所的に受け入れられたタイムウィンドウ、cMCStatus.failedとotherInfo.failInfo.badTimeを示すGLA MAYリターンa応答、およびsigningTime属性の中にありません。
2.b - Else if signature processing continues and if the signatures
cannot be verified, the GL member MUST return a
cMCStatusInfoExt response indicating cMCStatus.failed and
otherInfo.failInfo.badMessageCheck. Additionally, a
signingTime attribute is included with the response.
2. b--署名処理が続いて、署名がそうすることができないなら、ほかに、確かめられてください、そして、GLメンバーはcMCStatus.failedとotherInfo.failInfo.badMessageCheckを示すcMCStatusInfoExt応答を返さなければなりません。 さらに、signingTime属性は応答で含まれています。
Turner Standards Track [Page 78] RFC 5275 CMS SymKeyDist June 2008
5275cmのターナー標準化過程[78ページ]RFC SymKeyDist2008年6月
2.c - Else if the signatures verify, the GL member processes the
RecipientInfos according to [CMS]. Once unwrapped, the GL
member should store the shared KEK in a safe place. When
stored, the glName, glIdentifier, and shared KEK should be
associated. Additionally, the GL member MUST return a
cMCStatusInfoExt indicating cMCStatus.success to tell the GLA
the KEK was received.
2. c--、ほか、署名が確かめる、[CMS]に従って、GLメンバーはRecipientInfosを処理します。 いったん開けられると、GLメンバーは安全な場所に共有されたKEKを格納するべきです。 格納されると、glName、glIdentifier、および共有されたKEKは関連しているべきです。 さらに、GLメンバーはKEKが受け取られたとGLAに言うためにcMCStatus.successを示すcMCStatusInfoExtを返さなければなりません。
6. Algorithms
6. アルゴリズム
This section lists the algorithms that MUST be implemented. Additional algorithms that SHOULD be implemented are also included. Further algorithms MAY also be implemented.
このセクションは実行しなければならないアルゴリズムを記載します。 追加アルゴリズム、また、SHOULDが実行されるのは含まれています。 また、さらなるアルゴリズムは実行されるかもしれません。
6.1. KEK Generation Algorithm
6.1. KEK世代アルゴリズム
Implementations MUST randomly generate content-encryption keys, message-authentication keys, initialization vectors (IVs), and padding. Also, the generation of public/private key pairs relies on a random numbers. The use of inadequate pseudo-random number generators (PRNGs) to generate cryptographic keys can result in little or no security. An attacker may find it much easier to reproduce the PRNG environment that produced the keys, searching the resulting small set of possibilities, rather than brute force searching the whole key space. The generation of quality random numbers is difficult. RFC 4086 [RANDOM] offers important guidance in this area, and Appendix 3 of FIPS Pub 186 [FIPS] provides one quality PRNG technique.
実現は満足している暗号化キー、通報認証キー、初期化ベクトル(IVs)、および詰め物を手当たりしだいに発生させなければなりません。 また、公衆/秘密鍵組の世代は乱数を当てにします。 暗号化キーを発生させる不十分な疑似乱数生成器(PRNGs)の使用はまずセキュリティをもたらすことができません。 攻撃者は、キーを生産したPRNG環境を再生させるのがはるかに簡単であることがわかるかもしれません、全体の主要なスペースを捜す馬鹿力よりむしろ結果として起こる小さい可能性を捜して。 上質の乱数の世代は難しいです。 RFC4086[RANDOM]はこの領域で重要な指導を提供します、そして、FIPS Pub186[FIPS]のAppendix3は1つの上質のPRNGのテクニックを提供します。
6.2. Shared KEK Wrap Algorithm
6.2. 共有されたKEKはアルゴリズムを包装します。
In the mechanisms described in Section 5, the shared KEK being distributed in glkWrapped MUST be protected by a key of equal or greater length (e.g., if an AES 128-bit key is being distributed, a key of 128 bits or greater must be used to protect the key).
セクション5で説明されたメカニズムでは、等しいか、より大きい長さのキーでglkWrappedで分配される共有されたKEKを保護しなければなりません(例えば、AESの128ビットのキーが分配されているなら、キーを保護するのに128ビット以上のキーを使用しなければなりません)。
The algorithm object identifiers included in glkWrapped are as specified in [CMSALG] and [CMSAES].
glkWrappedに含まれていたアルゴリズム物の識別子が[CMSALG]と[CMSAES]で指定されるようにあります。
6.3. Shared KEK Algorithm
6.3. 共有されたKEKアルゴリズム
The shared KEK distributed and indicated in glkAlgorithm MUST support the symmetric key-encryption algorithms as specified in [CMSALG] and [CMSAES].
glkAlgorithmで分配されて、示された共有されたKEKは[CMSALG]と[CMSAES]の指定されるとしての左右対称の主要な暗号化アルゴリズムを支持しなければなりません。
Turner Standards Track [Page 79] RFC 5275 CMS SymKeyDist June 2008
5275cmのターナー標準化過程[79ページ]RFC SymKeyDist2008年6月
7. Message Transport
7. メッセージ転送
SMTP [SMTP] MUST be supported. Other transport mechanisms MAY also be supported.
SMTP[SMTP]を支持しなければなりません。 また、他の移送機構はサポートされるかもしれません。
8. Security Considerations
8. セキュリティ問題
As GLOs control setting up and tearing down the GL and rekeying the GL, and can control member additions and deletions, GLOs play an important role in the management of the GL, and only "trusted" GLOs should be used.
GLOsがセットアップして、GLを取りこわして、GLを「再-合わせ」ながら制御して、メンバー追加と削除を制御できるように、GLOsはGLの管理で重要な役割を果たします、そして、「信じられた」GLOsだけが使用されるべきです。
If a member is deleted or removed from a closed or a managed GL, the GL needs to be rekeyed. If the GL is not rekeyed after a member is removed or deleted, the member still possesses the group key and will be able to continue to decrypt any messages that can be obtained.
閉じたGLか管理されたGLからメンバーを削除するか、または免職するなら、GLは、「再-合わせ」られる必要があります。 メンバーを免職するか、または削除した後にGLを「再-合わせ」ないと、メンバーは、まだグループキーを所有していて、得ることができるどんなメッセージも解読し続けることができるでしょう。
Members who store KEKs MUST associate the name of the GLA that distributed the key so that the members can make sure subsequent rekeys are originated from the same entity.
KEKsを格納するメンバーはメンバーが、その後の「再-キー」が同じ実体から溯源されるのを確実にすることができるようにキーを分配したGLAという名前を関連づけなければなりません。
When generating keys, care should be taken to ensure that the key size is not too small and duration too long because attackers will have more time to attack the key. Key size should be selected to adequately protect sensitive business communications.
キーを発生させるとき、攻撃者にはキーを攻撃するより多くの時間があるので持続時間が確実に主要なサイズがそれほど小さくなく、長くなり過ぎるようにするために注意するべきです。 主要なサイズが適切に機密の商用通信を保護するのが選択されるべきです。
GLOs and GLAs need to make sure that the generationCounter and duration are not too large. For example, if the GLO indicates that the generationCounter is 14 and the duration is one year, then 14 keys are generated each with a validity period of a year. An attacker will have at least 13 years to attack the final key.
GLOsとGLAsは、generationCounterと持続時間が確実にそれほど大きくならないようにする必要があります。 例えば、GLOが、generationCounterが14歳であることを示して、持続時間が1年であるなら、当時の14個のキーが1年の有効期間でそれぞれ発生します。 攻撃者には、最終的なキーを攻撃するために、少なくとも13年があるでしょう。
Assume that two or more parties have a shared KEK, and the shared KEK is used to encrypt a second KEK for confidential distribution to those parties. The second KEK might be used to encrypt a third KEK, the third KEK might be used to encrypt a fourth KEK, and so on. If any of the KEKs in such a chain is compromised, all of the subsequent KEKs in the chain MUST also be considered compromised.
2回以上のパーティーが共有されたKEKを持って、共有されたKEKが秘密の分配のために第2のKEKをそれらのパーティーにコード化するのに使用されると仮定してください。 第2KEKは第3のKEKをコード化するのに使用されるかもしれなくて、第3KEKは、第4のKEKなどをコード化するのに使用されるかもしれません。 また、そのようなチェーンにおけるKEKsのどれかが妥協するなら、妥協しているとチェーンにおけるその後のKEKsのすべてを考えなければなりません。
An attacker can attack the group's shared KEK by attacking one member's copy of the shared KEK or attacking multiple members' copies of the shared KEK. For the attacker, it may be easier to either attack the group member with the weakest security protecting its copy of the shared KEK or attack multiple group members.
攻撃者は、1人のメンバーの共有されたKEKのコピーを攻撃するか、または複数のメンバーの共有されたKEKのコピーを攻撃することによって、グループの共有されたKEKを攻撃できます。 攻撃者には、最も弱いセキュリティが共有されたKEKのコピーを保護しているグループのメンバーを攻撃するか、または複数のグループのメンバーを攻撃するのが、より簡単であるかもしれません。
Turner Standards Track [Page 80] RFC 5275 CMS SymKeyDist June 2008
5275cmのターナー標準化過程[80ページ]RFC SymKeyDist2008年6月
An aggregation of the information gathered during the attack(s) may lead to the compromise of the group's shared KEK. Mechanisms to protect the shared KEK should be commensurate with value of the data being protected.
攻撃の間に集められた情報の集合はグループの共有されたKEKの妥協につながるかもしれません。 データの値が保護されている状態で、共有されたKEKを保護するメカニズムは等しいはずです。
The nonce and signingTime attributes are used to protect against replay attacks. However, these provisions are only helpful if entities maintain state information about the messages they have sent or received for comparison. If sufficient information is not maintained on each exchange, nonces and signingTime are not helpful. Local policy determines the amount and duration of state information that is maintained. Additionally, without a unified time source, there is the possibility of clocks drifting. Local policy determines the acceptable difference between the local time and signingTime, which must compensate for unsynchronized clocks. Implementations MUST handle messages with siginingTime attributes that indicate they were created in the future.
一回だけとsigningTime属性は、反射攻撃から守るのに使用されます。 しかしながら、実体が彼らが比較のために送るか、または受け取ったメッセージの州の情報を保守する場合にだけ、これらの条項は有用です。 十分な情報が各交換のときに維持されないなら、一回だけとsigningTimeは役立っていません。 ローカルの方針は保守される州の情報の量と持続時間を測定します。 さらに、時計が漂流する可能性が統一された時間ソースなしであります。 ローカルの方針は現地時間、signingTimeの許容違いを決定します。(signingTimeは非連動している時計を補わなければなりません)。 実現はそれらが将来作成されたのを示すsiginingTime属性でメッセージを扱わなければなりません。
9. Acknowledgements
9. 承認
Thanks to Russ Housley and Jim Schaad for providing much of the background and review required to write this document.
おかげに、バックグラウンドとレビューの多くを提供するためのラスHousleyとジムSchaadがこのドキュメントを書くのが必要です。
10. References
10. 参照
10.1. Normative References
10.1. 引用規格
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[CMS] Housley, R., "Cryptographic Message Syntax (CMS)", RFC
3852, July 2004.
[cm] Housley、R.、「暗号のメッセージ構文(cm)」、RFC3852、2004年7月。
[CMC] Schaad, J. and M. Myers, "Certificate Management over
CMS (CMC)", RFC 5272, June 2008.
[CMC] SchaadとJ.とM.マイアーズ、「cm(CMC)の上の証明書管理」、RFC5272、2008年6月。
[PROFILE] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation
List (CRL) Profile", RFC 5280, May 2008.
ポーク、「インターネットX.509公開鍵暗号基盤証明書と証明書失効リスト(CRL)プロフィール」という[プロフィール]クーパー、D.、Santesson、S.、ファレル、S.、Boeyen、S.、Housley、R.、およびW.(RFC5280)は2008がそうするかもしれません。
[ACPROF] Farrell, S. and R. Housley, "An Internet Attribute
Certificate Profile for Authorization", RFC 3281, April
2002.
[ACPROF]ファレルとS.とR.Housley、「認可のためのインターネット属性証明書プロフィール」、RFC3281、2002年4月。
Turner Standards Track [Page 81] RFC 5275 CMS SymKeyDist June 2008
5275cmのターナー標準化過程[81ページ]RFC SymKeyDist2008年6月
[MSG] Ramsdell, B., Ed., "Secure/Multipurpose Internet Mail
Extensions (S/MIME) Version 3.1 Message Specification",
RFC 3851, July 2004.
[MSG] Ramsdell、B.、エド、「安全な/マルチパーパスインターネットメールエクステンション(S/MIME)バージョン3.1は仕様を通信する」RFC3851、7月2004日
[ESS] Hoffman, P., Ed., "Enhanced Security Services for
S/MIME", RFC 2634, June 1999.
[ESS]ホフマン、P.、エド、「S/MIMEのための警備の強化サービス」、RFC2634、6月1999日
[CMSALG] Housley, R., "Cryptographic Message Syntax (CMS)
Algorithms", RFC 3370, August 2002.
[CMSALG] Housley、R.、「暗号のメッセージ構文(cm)アルゴリズム」、RFC3370、2002年8月。
[CMSAES] Schaad, J., "Use of the Advanced Encryption Standard
(AES) Encryption Algorithm in Cryptographic Message
Syntax (CMS)", RFC 3565, July 2003.
[CMSAES]Schaad、J.、「暗号のメッセージ構文(cm)におけるエー・イー・エス(AES)暗号化アルゴリズムの使用」、RFC3565(2003年7月)。
[SMTP] Klensin, J., Ed., "Simple Mail Transfer Protocol", RFC
2821, April 2001.
[SMTP] Klensin、J.、エド、「簡単なメール転送プロトコル」、RFC2821、4月2001日
10.2. Informative References
10.2. 有益な参照
[X400TRANS] Hoffman, P. and C. Bonatti, "Transporting
Secure/Multipurpose Internet Mail Extensions (S/MIME)
Objects in X.400", RFC 3855, July 2004.
[X400TRANS] ホフマンとP.とC.Bonatti、「X.400の安全な/マルチパーパスインターネットメールエクステンション(S/MIME)物を輸送します」、RFC3855、2004年7月。
[RANDOM] Eastlake, D., 3rd, Schiller, J., and S. Crocker,
"Randomness Requirements for Security", BCP 106, RFC
4086, June 2005.
イーストレークとD.と3番目、シラー、J.とS.クロッカー、「セキュリティのための偶発性要件」[無作為]のBCP106、2005年6月のRFC4086。
[FIPS] National Institute of Standards and Technology, FIPS Pub
186-2: Digital Signature Standard, January 2000.
[FIPS]米国商務省標準技術局、FIPSパブ186-2: 2000年1月のデジタル署名基準。
Turner Standards Track [Page 82] RFC 5275 CMS SymKeyDist June 2008
5275cmのターナー標準化過程[82ページ]RFC SymKeyDist2008年6月
Appendix A. ASN.1 Module
付録A.ASN.1モジュール
SMIMESymmetricKeyDistribution
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
pkcs-9(9) smime(16) modules(0) symkeydist(12) }
SMIMESymmetricKeyDistributioniso(1)が(2) 私たちをメンバーと同じくらい具体化させる、(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)モジュール(0)symkeydist(12)
DEFINITIONS IMPLICIT TAGS ::= BEGIN
定義、内在しているタグ:、:= 始まってください。
-- EXPORTS All -- -- The types and values defined in this module are exported for use -- in the other ASN.1 modules. Other applications may use them for -- their own purposes.
-- EXPORTS All----他のASN.1モジュールにおける使用のためにこのモジュールで定義されたタイプと値を輸出します。 アプリケーションがそれらを使用するかもしれないもう一方--それら自身の目的。
IMPORTS
輸入
-- PKIX Part 1 - Implicit [PROFILE]
GeneralName
FROM PKIX1Implicit88 { iso(1) identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
id-pkix1-implicit(19) }
-- PKIX第1部--PKIX1Implicit88からの内在している[プロフィール]GeneralNameiso(1)の特定されて組織(3)dod(6)インターネット(1)セキュリティ(5)メカニズム(5)pkix(7)イドモッズ(0)イド-pkix1暗黙の(19)
-- PKIX Part 1 - Explicit [PROFILE]
AlgorithmIdentifier, Certificate
FROM PKIX1Explicit88 { iso(1) identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
id-pkix1-explicit(18) }
-- PKIX第1部--PKIX1Explicit88からの明白な[プロフィール]AlgorithmIdentifier、証明書iso(1)の特定されて組織(3)dod(6)インターネット(1)セキュリティ(5)メカニズム(5)pkix(7)イドモッズ(0)イド-pkix1明白な(18)
-- Cryptographic Message Syntax [CMS]
RecipientInfos, KEKIdentifier, CertificateSet
FROM CryptographicMessageSyntax2004 {iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) modules(0)
cms-2004(24) }
-- CryptographicMessageSyntax2004からの暗号のメッセージ構文[cm]RecipientInfos、KEKIdentifier、CertificateSetiso(1)が(2) 私たちをメンバーと同じくらい具体化させる、(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)モジュール(0)cm-2004(24)
-- Advanced Encryption Standard (AES) with CMS [CMSAES]
id-aes128-wrap
FROM CMSAesRsaesOaep { iso(1) member-body(2) us(840)
rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) modules(0)
id-mod-cms-aes(19) }
-- CMS[CMSAES]イドaes128包装FROM CMSAesRsaesOaepがあるエー・イー・エス(AES)iso(1)が(2) 私たちをメンバーと同じくらい具体化させる、(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)モジュール(0)、イドモッズcm aes(19)
-- Attribute Certificate Profile [ACPROF]
AttributeCertificate FROM
PKIXAttributeCertificate { iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7)
id-mod(0) id-mod-attribute-cert(12) };
-- Certificate Profile[ACPROF]AttributeCertificate FROM PKIXAttributeCertificate iso(1)の特定された組織(3)dod(6)のインターネット(1)セキュリティ(5)メカニズム(5)pkix(7)イドモッズ(0)イドモッズ属性本命(12)を結果と考えてください。
Turner Standards Track [Page 83] RFC 5275 CMS SymKeyDist June 2008
5275cmのターナー標準化過程[83ページ]RFC SymKeyDist2008年6月
-- This defines the GL symmetric key distribution object identifier -- arc.
-- これはGL対称鍵分配物の識別子を定義します--アーク。
id-skd OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) skd(8) }
イド-skd OBJECT IDENTIFIER:、:= iso(1)が(2) 私たちをメンバーと同じくらい具体化させる、(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) skd(8)
-- This defines the GL Use KEK control attribute.
-- これはGL Use KEKコントロール属性を定義します。
id-skd-glUseKEK OBJECT IDENTIFIER ::= { id-skd 1 }
イド-skd-glUseKEK物の識別子:、:= イド-skd1
GLUseKEK ::= SEQUENCE {
glInfo GLInfo,
glOwnerInfo SEQUENCE SIZE (1..MAX) OF GLOwnerInfo,
glAdministration GLAdministration DEFAULT 1,
glKeyAttributes GLKeyAttributes OPTIONAL }
GLUseKEK:、:= 系列glInfo GLInfo、glAdministration GLAdministrationデフォルト1の、そして、glKeyAttributes GLKeyAttributes任意のGLOwnerInfoのglOwnerInfo系列サイズ(1..MAX)
GLInfo ::= SEQUENCE {
glName GeneralName,
glAddress GeneralName }
GLInfo:、:= 系列glName GeneralName、glAddress GeneralName
GLOwnerInfo ::= SEQUENCE {
glOwnerName GeneralName,
glOwnerAddress GeneralName,
certificates Certificates OPTIONAL }
GLOwnerInfo:、:= 系列glOwnerName GeneralName、glOwnerAddress GeneralName、証明書Certificates OPTIONAL
GLAdministration ::= INTEGER {
unmanaged (0),
managed (1),
closed (2) }
GLAdministration:、:= 整数(0)を非管理して、(1)、閉じた(2)を管理します。
GLKeyAttributes ::= SEQUENCE {
rekeyControlledByGLO [0] BOOLEAN DEFAULT FALSE,
recipientsNotMutuallyAware [1] BOOLEAN DEFAULT TRUE,
duration [2] INTEGER DEFAULT 0,
generationCounter [3] INTEGER DEFAULT 2,
requestedAlgorithm [4] AlgorithmIdentifier
DEFAULT { id-aes128-wrap } }
GLKeyAttributes:、:= 系列rekeyControlledByGLO[0]BOOLEAN DEFAULT FALSE、recipientsNotMutuallyAware[1]BOOLEAN DEFAULT TRUE、持続時間[2]INTEGER DEFAULT0、generationCounter[3]INTEGER DEFAULT2、requestedAlgorithm[4]AlgorithmIdentifier DEFAULTイドaes128包装
-- This defines the Delete GL control attribute. -- It has the simple type GeneralName.
-- これはDelete GLコントロール属性を定義します。 -- それは簡単なタイプGeneralNameを持っています。
id-skd-glDelete OBJECT IDENTIFIER ::= { id-skd 2 }
イド-skd-glDelete物の識別子:、:= イド-skd2
DeleteGL ::= GeneralName
DeleteGL:、:= GeneralName
-- This defines the Add GL Member control attribute.
-- これはAdd GLメンバーコントロール属性を定義します。
id-skd-glAddMember OBJECT IDENTIFIER ::= { id-skd 3 }
イド-skd-glAddMember物の識別子:、:= イド-skd3
Turner Standards Track [Page 84] RFC 5275 CMS SymKeyDist June 2008
5275cmのターナー標準化過程[84ページ]RFC SymKeyDist2008年6月
GLAddMember ::= SEQUENCE {
glName GeneralName,
glMember GLMember }
GLAddMember:、:= 系列glName GeneralName、glMember GLMember
GLMember ::= SEQUENCE {
glMemberName GeneralName,
glMemberAddress GeneralName OPTIONAL,
certificates Certificates OPTIONAL }
GLMember:、:= 系列glMemberName GeneralName、glMemberAddress GeneralName OPTIONAL、証明書Certificates OPTIONAL
Certificates ::= SEQUENCE {
pKC [0] Certificate OPTIONAL,
-- See [PROFILE]
aC [1] SEQUENCE SIZE (1.. MAX) OF
AttributeCertificate OPTIONAL,
-- See [ACPROF]
certPath [2] CertificateSet OPTIONAL }
-- From [CMS]
証明書:、:= 系列、pKC[0]証明書任意である、--、AttributeCertificateの[プロフィール]aC[1]系列サイズ(1つの最大)が任意であることを見てください--[ACPROF]certPath[2]CertificateSetが任意であることを見てください--[cm]
-- This defines the Delete GL Member control attribute.
-- これはDelete GLメンバーコントロール属性を定義します。
id-skd-glDeleteMember OBJECT IDENTIFIER ::= { id-skd 4 }
イド-skd-glDeleteMember物の識別子:、:= イド-skd4
GLDeleteMember ::= SEQUENCE {
glName GeneralName,
glMemberToDelete GeneralName }
GLDeleteMember:、:= 系列glName GeneralName、glMemberToDelete GeneralName
-- This defines the Delete GL Member control attribute.
-- これはDelete GLメンバーコントロール属性を定義します。
id-skd-glRekey OBJECT IDENTIFIER ::= { id-skd 5 }
イド-skd-glRekey物の識別子:、:= イド-skd5
GLRekey ::= SEQUENCE {
glName GeneralName,
glAdministration GLAdministration OPTIONAL,
glNewKeyAttributes GLNewKeyAttributes OPTIONAL,
glRekeyAllGLKeys BOOLEAN OPTIONAL }
GLRekey:、:= 系列glAdministration GLAdministration任意の、そして、任意のglNewKeyAttributes GLNewKeyAttributes glRekeyAllGLKeys論理演算子任意のglName GeneralName
GLNewKeyAttributes ::= SEQUENCE {
rekeyControlledByGLO [0] BOOLEAN OPTIONAL,
recipientsNotMutuallyAware [1] BOOLEAN OPTIONAL,
duration [2] INTEGER OPTIONAL,
generationCounter [3] INTEGER OPTIONAL,
requestedAlgorithm [4] AlgorithmIdentifier OPTIONAL }
GLNewKeyAttributes:、:= 系列rekeyControlledByGLO[0]BOOLEAN OPTIONAL、recipientsNotMutuallyAware[1]BOOLEAN OPTIONAL、持続時間[2]INTEGER OPTIONAL、generationCounter[3]INTEGER OPTIONAL、requestedAlgorithm[4]AlgorithmIdentifier OPTIONAL
-- This defines the Add and Delete GL Owner control attributes.
-- これはAddとDelete GL Ownerコントロール属性を定義します。
id-skd-glAddOwner OBJECT IDENTIFIER ::= { id-skd 6 }
id-skd-glRemoveOwner OBJECT IDENTIFIER ::= { id-skd 7 }
イド-skd-glAddOwner物の識別子:、:= イド-skd6、イド-skd-glRemoveOwner OBJECT IDENTIFIER:、:= イド-skd7
Turner Standards Track [Page 85] RFC 5275 CMS SymKeyDist June 2008
5275cmのターナー標準化過程[85ページ]RFC SymKeyDist2008年6月
GLOwnerAdministration ::= SEQUENCE {
glName GeneralName,
glOwnerInfo GLOwnerInfo }
GLOwnerAdministration:、:= 系列glName GeneralName、glOwnerInfo GLOwnerInfo
-- This defines the GL Key Compromise control attribute. -- It has the simple type GeneralName.
-- これはGL Key Compromiseコントロール属性を定義します。 -- それは簡単なタイプGeneralNameを持っています。
id-skd-glKeyCompromise OBJECT IDENTIFIER ::= { id-skd 8 }
イド-skd-glKeyCompromise物の識別子:、:= イド-skd8
GLKCompromise ::= GeneralName
GLKCompromise:、:= GeneralName
-- This defines the GL Key Refresh control attribute.
-- これはGL Key Refreshコントロール属性を定義します。
id-skd-glkRefresh OBJECT IDENTIFIER ::= { id-skd 9 }
イド-skd-glkRefresh物の識別子:、:= イド-skd9
GLKRefresh ::= SEQUENCE {
glName GeneralName,
dates SEQUENCE SIZE (1..MAX) OF Date }
GLKRefresh:、:= 系列glName GeneralName、日付SEQUENCE SIZE(1..MAX)OF Date
Date ::= SEQUENCE {
start GeneralizedTime,
end GeneralizedTime OPTIONAL }
以下とデートしてください:= 系列GeneralizedTime、終わりのGeneralizedTime OPTIONALを始動してください。
-- This defines the GLA Query Request control attribute.
-- これはGLA Query Requestコントロール属性を定義します。
id-skd-glaQueryRequest OBJECT IDENTIFIER ::= { id-skd 11 }
イド-skd-glaQueryRequest物の識別子:、:= イド-skd11
GLAQueryRequest ::= SEQUENCE {
glaRequestType OBJECT IDENTIFIER,
glaRequestValue ANY DEFINED BY glaRequestType }
GLAQueryRequest:、:= 系列glaRequestType物の識別子、glaRequestTypeによって少しも定義されたglaRequestValue
-- This defines the GLA Query Response control attribute.
-- これはGLA Query Responseコントロール属性を定義します。
id-skd-glaQueryResponse OBJECT IDENTIFIER ::= { id-skd 12 }
イド-skd-glaQueryResponse物の識別子:、:= イド-skd12
GLAQueryResponse ::= SEQUENCE {
glaResponseType OBJECT IDENTIFIER,
glaResponseValue ANY DEFINED BY glaResponseType }
GLAQueryResponse:、:= 系列glaResponseType物の識別子、glaResponseTypeによって少しも定義されたglaResponseValue
-- This defines the GLA Request/Response (glaRR) arc for -- glaRequestType/glaResponseType.
-- これがGLA Request/応答(glaRR)アークを定義する、--glaRequestType/glaResponseType。
id-cmc-glaRR OBJECT IDENTIFIER ::= { iso(1)
identified-organization(3) dod(6) internet(1) security(5)
mechanisms(5) pkix(7) cmc(7) glaRR(99) }
イド-cmc-glaRR物の識別子:、:= iso(1)の特定された組織(3)dod(6)インターネット(1)セキュリティ(5)メカニズム(5)pkix(7) cmc(7) glaRR(99)
Turner Standards Track [Page 86] RFC 5275 CMS SymKeyDist June 2008
5275cmのターナー標準化過程[86ページ]RFC SymKeyDist2008年6月
-- This defines the Algorithm Request.
-- これはAlgorithm Requestを定義します。
id-cmc-gla-skdAlgRequest OBJECT IDENTIFIER ::= { id-cmc-glaRR 1 }
イド-cmc-gla-skdAlgRequest物の識別子:、:= イド-cmc-glaRR1
SKDAlgRequest ::= NULL
SKDAlgRequest:、:= ヌル
-- This defines the Algorithm Response.
-- これはAlgorithm Responseを定義します。
id-cmc-gla-skdAlgResponse OBJECT IDENTIFIER ::= { id-cmc-glaRR 2 }
イド-cmc-gla-skdAlgResponse物の識別子:、:= イド-cmc-glaRR2
-- Note that the response for algorithmSupported request is the -- smimeCapabilities attribute as defined in MsgSpec [MSG]. -- This defines the control attribute to request an updated -- certificate to the GLA.
-- algorithmSupported要求のための応答がそうであることに注意してください、--MsgSpec[MSG]で定義されるsmimeCapabilities属性。 -- これが要求するコントロール属性を定義する、アップデート、--GLAに、証明します。
id-skd-glProvideCert OBJECT IDENTIFIER ::= { id-skd 13 }
イド-skd-glProvideCert物の識別子:、:= イド-skd13
GLManageCert ::= SEQUENCE {
glName GeneralName,
glMember GLMember }
GLManageCert:、:= 系列glName GeneralName、glMember GLMember
-- This defines the control attribute to return an updated -- certificate to the GLA. It has the type GLManageCert.
-- これが戻るためにコントロール属性を定義する、アップデート、--GLAに、証明します。 それはタイプGLManageCertを持っています。
id-skd-glManageCert OBJECT IDENTIFIER ::= { id-skd 14 }
イド-skd-glManageCert物の識別子:、:= イド-skd14
-- This defines the control attribute to distribute the GL shared -- KEK.
-- これは共有されたGLを分配するためにコントロール属性を定義します--KEK。
id-skd-glKey OBJECT IDENTIFIER ::= { id-skd 15 }
イド-skd-glKey物の識別子:、:= イド-skd15
GLKey ::= SEQUENCE {
glName GeneralName,
glIdentifier KEKIdentifier, -- See [CMS]
glkWrapped RecipientInfos, -- See [CMS]
glkAlgorithm AlgorithmIdentifier,
glkNotBefore GeneralizedTime,
glkNotAfter GeneralizedTime }
GLKey:、:= 系列glName GeneralName、glIdentifier KEKIdentifier--[cm]glkWrapped RecipientInfosを見てください--glkAlgorithm AlgorithmIdentifier、glkNotBefore GeneralizedTime、glkNotAfter GeneralizedTimeを見てください[cm]。
-- This defines the CMC error types.
-- これはCMC誤りタイプを定義します。
id-cet-skdFailInfo OBJECT IDENTIFIER ::= { iso(1)
identified-organization(3) dod(6) internet(1) security(5)
mechanisms(5) pkix(7) cet(15) skdFailInfo(1) }
イド-cet-skdFailInfo物の識別子:、:= iso(1)の特定された組織(3)dod(6)インターネット(1)セキュリティ(5)メカニズム(5)pkix(7) cet(15) skdFailInfo(1)
Turner Standards Track [Page 87] RFC 5275 CMS SymKeyDist June 2008
5275cmのターナー標準化過程[87ページ]RFC SymKeyDist2008年6月
SKDFailInfo ::= INTEGER {
unspecified (0),
closedGL (1),
unsupportedDuration (2),
noGLACertificate (3),
invalidCert (4),
unsupportedAlgorithm (5),
noGLONameMatch (6),
invalidGLName (7),
nameAlreadyInUse (8),
noSpam (9),
-- obsolete (10),
alreadyAMember (11),
notAMember (12),
alreadyAnOwner (13),
notAnOwner (14) }
SKDFailInfo:、:= 整数不特定の(0)、closedGL(1)、unsupportedDuration(2)、noGLACertificate(3)、invalidCert(4)、unsupportedAlgorithm(5)、noGLONameMatch(6)、invalidGLName(7)、nameAlreadyInUse(8)、noSpam(9)--(10)を時代遅れにしてください、alreadyAMember(11)、notAMember(12)、alreadyAnOwner(13)、notAnOwner(14)
END -- SMIMESymmetricKeyDistribution
終わり--SMIMESymmetricKeyDistribution
Author's Address
作者のアドレス
Sean Turner IECA, Inc. 3057 Nutley Street, Suite 106 Fairfax, VA 22031 USA
ショーンターナーIECA, Inc.3057ナットリー通り、Suite106フェアファクス、ヴァージニア22031米国
EMail: turners@ieca.com
メール: turners@ieca.com
Turner Standards Track [Page 88] RFC 5275 CMS SymKeyDist June 2008
5275cmのターナー標準化過程[88ページ]RFC SymKeyDist2008年6月
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2008).
IETFが信じる著作権(C)(2008)。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
このドキュメントとここに含まれた情報はその人が代理をするか、または(もしあれば)後援される組織、インターネットの振興発展を目的とする組織、「そのままで」という基礎と貢献者の上で提供していて、IETFはそして、インターネット・エンジニアリング・タスク・フォースがすべての保証を放棄すると信じます、急行である、または暗示していて、他を含んでいて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるということであるかいずれが市場性か特定目的への適合性の黙示的な保証です。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFはこの規格を実行するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf-ipr@ietf.org のIETFに情報を記述してください。
Turner Standards Track [Page 89]
ターナー標準化過程[89ページ]
一覧
スポンサーリンク
