Network Working Group S. Turner
Request for Comments: 5275 IECA
Category: Standards Track June 2008
CMS Symmetric Key Management and Distribution
Status of This Memo
このメモのステータス
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
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).
この文書では（すなわち、設定、配布、及びリキー）対称暗号化アルゴリズムで使用する鍵管理するメカニズムが記載されています。また、本明細書に定義された対称暗号アルゴリズムを使用して暗号化されたコンテンツの配信をサポートするために、ユーザーをグループに編成する機構です。メカニズムは、対称鍵を管理するための暗号メッセージ構文（CMS）CMSを超えるプロトコルおよび証明書の管理（CMC）プロトコルを使用しています。グループのメンバーは、その後、他のCMSは、対称鍵を用いてオブジェクトを暗号化し復号化するために、この分散共有キーを使用することができます。このメカニズムは、多目的インターネットメール拡張（S / MIME）メールリストエージェント（のMLA）/セキュアをサポートするために開発されてきました。
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
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
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）を形成し、対称アルゴリズムを使用して、コンテンツを暗号化します。次に、非対称アルゴリズムと受信者のPKCを使用して、発信者は、（a）は、特定の受信者のためにCEKを暗号化する（ktriのRecipientInfo CHOICE）又は（b）の転送に十分なパラメータが独立に生成する特定の受信者を有効にすることを受信者ごとの情報を生成します同じKEK（がkariのRecipientInfo CHOICE）。グループが大きい場合は、受信者ごとの情報の処理を収集し、各受信者のためのPKCを検証するために必要な時間を言及しないように、かなりの時間がかかることがあります。各受信者はその受信者ごとの情報を識別し、CEKを復号化し、したがって、暗号化されたコンテンツへのアクセスを得るためにその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.
対称アルゴリズムを用いて、発信処理が若干異なります。代わりのPKCを使用しての、発信者は、CEK（kekriのRecipientInfo CHOICE）を暗号化するために、以前に分散秘密鍵の暗号化キー（KEK）を使用しています。すべての受信者がすでに共有KEKは、CEKを復号化し、したがって、暗号化されたコンテンツへのアクセスを得るために必要な必要があるため、暗号化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（この小さいグループでのみ共有される）使用されるべきまたは非対称アルゴリズムが使用されるべきです。
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"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますBCP 14、RFC 2119 [RFC2119]に記載されているように解釈されます。
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.
この配布メカニズムの一つの主な対象読者は、電子メールです。時には、配布リストは、メールリストに加入した受信者へのメッセージの配信をサポートする、メールリストと呼ばれます。メールリストを使用することができる方法のための2つのモデルがあります。発信者がメールリストのメンバーである場合、発信者はメールリスト（例えば、メーリングリストまたはMajordomoの）に共有KEKで暗号化されたメッセージを送信し、メッセージは、メールリストのメンバーに配布されます。発信者がメールリストのメンバー（共有KEKを持っていない）でない場合は、発信者がメールリストエージェント（MLA）へ（MLAのために暗号化された）メッセージを送信し、その後、MLAは、暗号化するために、共有KEKを使用していますメンバーへのメッセージ。いずれの場合においても、メールリストの受信者がメッセージを解読するために以前に分散共有KEKを使用します。
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ディレクトリシステムエージェント（のDSA）、Webベースのサーバー）を介して配布することができます。オブジェクトは共通鍵暗号で暗号化されたリポジトリに格納されている場合は、共有KEKと、そのオブジェクトにアクセスできる者は誰でも、そのオブジェクトを解読することができます。暗号化されたオブジェクトおよび暗号化され、共有KEKは、リポジトリに格納することができます。
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.
2一般的なメッセージ配信のためのメールリストエージェントと1をサポート：この文書は、心の中で3つの特定のシナリオを書かれました。シナリオ1は、リストのメンバーにメッセージを再配布する共有KEK（複数可）を使用するMLAに公開鍵（PK）保護されたメッセージを送信元を示します。シナリオ2は、リストのメンバーにメッセージを再分配MLAに共有KEK保護されたメッセージを送信元を示す（MLAは、追加の受信者を追加します）。創始者によって使用される鍵は、すべての受信者の間で、または単にメンバーとMLAの間のいずれかの共有キーである可能性があります。発信者はMLAでのみ共有キーを使用している場合、その後、MLAはメッセージを復号化し、リストの受信者のメッセージを再暗号化する必要があることに注意してください。シナリオ3は、中間MLAなしで受信者のグループに共有KEK保護されたメッセージを送信元を示します。
+----> +----> +---->
PK +-----+ S | S +-----+ S | S |
----> | MLA | --+----> ----> | MLA | --+----> ----+---->
+-----+ | +-----+ | |
+----> +----> +---->
Scenario 1 Scenario 2 Scenario 3
シナリオ1つのシナリオ2シナリオ3
Figure 1 depicts the architecture to support symmetric key distribution. The Group List Agent (GLA) supports two distinct functions with two different agents:
図1は、対称鍵配布をサポートするためのアーキテクチャを示します。グループリストエージェント（GLA）は、二つの異なる薬剤を持つ2つの異なる機能をサポートしています。
- The Key Management Agent (KMA), which is responsible for generating the shared KEKs.
- 共有のKEKを生成するための責任があるキー管理エージェント（KMA）、。
- The Group Management Agent (GMA), which is responsible for managing the Group List (GL) to which the shared KEKs are distributed.
- グループリスト（GL）を管理する責任があるグループ管理エージェント（GMA）は、その共有のKEKが配布されます。
+----------------------------------------------+
| Group List Agent | +-------+
| +------------+ + -----------------------+ | | Group |
| | Key | | Group Management Agent | |<-->| List |
| | Management |<-->| +------------+ | | | Owner |
| | Agent | | | Group List | | | +-------+
| +------------+ | +------------+ | |
| | / | \ | |
| +------------------------+ |
+----------------------------------------------+
/ | \
/ | \
+----------+ +---------+ +----------+
| Member 1 | | ... | | Member 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は、唯一のGMAをサポートしていますが、GMAは、複数のGLsのをサポートすることができます。 GLASは、複数のKMAsをサポートするように、複数のKMAsは同じやり方でGMAをサポートすることができます。 GLに特定のKMAを割り当てると、このドキュメントの範囲を超えています。
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 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.
実世界のGLの実装をモデル化することは、人間がGLメンバーシップを決定し非常に制限GLsの、およびGLメンバーシップに制限はありません非常にオープンGLsのは、そこにあることを示しています。このスペクトルをサポートするために、本明細書に記載される機構は、両方の（すなわち、アクセス制御が適用される場合）、管理および管理対象外（すなわち、いかなるアクセス制御が適用されない場合）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.
いずれの場合も、GLは最初のエンティティ以下で構成されなければならないグループリストの所有者（GLO）と呼ばれます。自身の "GLと誰がGLのプロパティや会員への変更を許可されている複数のエンティティがあるかもしれません。 GLが管理または管理対象外とGLを削除することが唯一のエンティティであることになる場合GLOが決定します。 GLO（複数可）またはGLメンバーであってもなくてもよいです。 GLO（複数可）も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つのエンティティが使用されている場合、それらは、1つのまたは2つのプラットフォーム上に配置することができます。 KMAとGMA機能間の密接な関係は、しかし、があります。 GLsのとKMAに関連するすべての情報は、単にキーを生成GMA店舗場合は、破損したGMAは大混乱を引き起こす可能性があります。破損したGMAから保護するために、KMAは、GMAがそれらを改ざんしていないことを確認するために、受信した要求を再確認することを余儀なくされるだろう。これらの重複チェックは、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つのエンティティ間の信頼関係を強化することにより、機能を分離するために使用されてもよいです。以後、二つの薬剤の間の区別はさらに説明しません。用語GLAは、両方の機能に対処するために使用されます。破損しているGLAはいつも大混乱を引き起こすことができることに留意すべきです。
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 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.
GLsのを管理するための既存のメカニズム（例えば、メーリングリストとのMajordomo）があります。しかし、この文書は、彼らが標準化されていないとして、これらのメカニズムを確保対応していません。図2に示されるように代わりに、GLsの管理および共有のKEKを配布するGLメンバー、GLA、およびGLO（単数または複数）によって使用される、プロトコル相互作用を定義します。相互作用は、管理メッセージと分配メッセージに分けられています。管理メッセージは、GLを設定GLを削除し、GLにメンバーを追加し、GLのメンバーを削除し、グループの再入力を要求し、GLに所有者を追加し、GLの所有者を削除するために必要な要求メッセージと応答メッセージであることを示しますグループキー妥協は、グループキーを更新GLAを問い合わせ、更新メンバーおよび所有者の公開鍵証明書。配信メッセージは、共有のKEKを配布するメッセージです。次のセクションでは、両方の管理と配布のメッセージのASN.1を説明します。第4節では、管理メッセージを使用する方法について説明し、第5節では、配信メッセージを使用する方法について説明します。
+-----+ +----------+
| GLO | <---+ +----> | Member 1 |
+-----+ | | +----------+
| |
+-----+ <------+ | +----------+
| GLA | <-------------+----> | ... |
+-----+ | +----------+
|
| +----------+
+----> | Member n |
+----------+
Figure 2 - Protocol Interactions
図2 - プロトコルの相互作用
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）プロトコル上の証明書の管理は、このプロトコルの基盤として選ばれました。選択のための主な理由は、要求または所望のアクションに応答するために、一つ以上の制御属性は、メッセージに含まれるCMSで保護されたCMCが提供する階層化局面でした。 CMC PKIData構造が要求に使用され、CMC PKIResponse構造が応答に使用されます。 PKIDataとPKIResponseは、その後、CMSのSignedDataのかEnvelopedDataの中に封入されているコンテンツタイプ、または両者の組み合わせ（3.2節を参照してください）。以下は、このドキュメントで定義された制御属性であります：
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
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：下記適合表に、列見出しは以下の意味を有します。 GLOs、グラス、およびGLメンバー：実装の3種類があります。 GLOは、したがって、すべてのGLO O及びGLO Rメッセージは任意であり、GLA Fメッセージはオプションであり、任意成分です。最初の表には準拠実装がサポートしなければならないメッセージが含まれています。 2番目の表は、実装されてもよいメッセージを含んでいます。次のように2番目の表は解釈されるべきである：制御属性がコンポーネントによって実装されている場合示されるように、それが実現されなければなりません。 GLAはglAddMember制御属性をサポートする実装されている場合たとえば、それは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
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
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 PKIDataコンテンツタイプで運ばれ、CMC PKIResponseコンテンツタイプで運ばれます。例外はPKIDataまたはPKIResponseのいずれかで行うことができるglUpdateCert、です。
Success and failure messages use CMC (see Section 3.2.4).
成功と失敗のメッセージは、CMC（セクション3.2.4を参照）を使用します。
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がGLに割り当てられることを要求するためにglUseKEKを使用しています。 glUseKEKメッセージをGLOによって署名されなければなりません。 glUseKEK制御属性は、構文GLUseKEKがあります。
GLUseKEK ::= SEQUENCE {
glInfo GLInfo,
glOwnerInfo SEQUENCE SIZE (1..MAX) OF GLOwnerInfo,
glAdministration GLAdministration DEFAULT 1,
glKeyAttributes GLKeyAttributes OPTIONAL }
GLInfo ::= SEQUENCE {
glName GeneralName,
glAddress GeneralName }
GLOwnerInfo ::= SEQUENCE {
glOwnerName GeneralName,
glOwnerAddress GeneralName,
certificate 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]
-- CertificateSet and CertificateChoices are included only -- for illustrative purposes as they are imported from [CMS].
- 証明書群とCertificateChoicesのみ含まれてい - 例示の目的のために、それらは[CMS]からインポートされます。
CertificateSet ::= SET SIZE (1..MAX) OF CertificateChoices
-- CertificateChoices supports X.509 public key certificates in -- certificates and v2 attribute certificates in v2AttrCert.
- 証明書とv2AttrCertでv2の属性証明書 - CertificateChoicesがでX.509公開鍵証明書をサポートしています。
GLAdministration ::= INTEGER {
unmanaged (0),
managed (1),
closed (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 } }
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はglNameでGLの名前と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の所有者の名前を示します。 glOwnerNameの名前の1つは、証明書内の名前（被験者識別名またはサブジェクト代替名のいずれかのいずれか）のいずれかと一致GL（すなわち、即時署名者）を作成するこのSignedData.PKIDataに署名するために使用しなければなりません。
-- glOwnerAddress indicates the GL owner's address.
- glOwnerAddressは、GLの所有者のアドレスを示しています。
-- 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.aC MAY be included to convey any attribute
certificate (see [ACPROF]) associated with the
encryption certificate of the GLO included in
certificates.pKC.
--- 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).
-- 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.
--- 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.
--- 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.
-- 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 of the month), and two shared KEKs will be distributed initially. The fields in glKeyAttributes have the following meaning:
- glKeyAttributesはGLOはGLAが共有KEKに割り当てるしたい属性を示します。このフィールドが省略された場合はGLのキー更新がGLAによって制御され、受信者がお互いを知っているさせて、アルゴリズムはAES-128になります（セクション7を参照）、共有KEKは、暦月のために有効になります（つまり、 、）月の最後の日までの月の最初の、そして二つは共有のKEKが最初に配布されます。 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.
--- 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.
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.
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.
--- 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.
--- 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.
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を持っています。 glDeleteメッセージはGLOによって署名されなければなりません。削除するGLの名前がいるGeneralNameに含まれています：
DeleteGL ::= GeneralName
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を使用しています。 glAddMemberメッセージはGLOまたは将来のGLメンバーのいずれかによって署名されなければなりません。 glAddMember制御属性は、構文GLAddMemberがあります。
GLAddMember ::= SEQUENCE {
glName GeneralName,
glMember GLMember }
GLMember ::= SEQUENCE {
glMemberName GeneralName,
glMemberAddress GeneralName OPTIONAL,
certificates 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の名称を示します。
- 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.aC MAY be included to convey any attribute
certificate (see [ACPROF]) associated with the member's
encryption certificate.
--- 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).
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を使用しています。 glDeleteMemberメッセージはGLOまたはGL部材のいずれかによって署名されなければなりません。 glDeleteMember制御属性は、構文GLDeleteMemberがあります。
GLDeleteMember ::= SEQUENCE {
glName GeneralName,
glMemberToDelete GeneralName }
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は、削除するメンバーの名前またはアドレスを示しています。
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の再入力を要求するglRekeyを使用しています。 glRekeyメッセージはGLOによって署名されなければなりません。 glRekey制御属性は、構文GLRekeyがあります。
GLRekey ::= SEQUENCE {
glName GeneralName,
glAdministration GLAdministration OPTIONAL,
glNewKeyAttributes GLNewKeyAttributes OPTIONAL,
glRekeyAllGLKeys BOOLEAN OPTIONAL }
GLNewKeyAttributes ::= SEQUENCE {
rekeyControlledByGLO [0] BOOLEAN OPTIONAL,
recipientsNotMutuallyAware [1] BOOLEAN OPTIONAL,
duration [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.
- GLを投与する方法に変更がある場合glAdministrationを示しています。 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の再入力が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の共有のKEKのすべてを望んでいるかどうかを示します。それがTRUEに設定されている場合は、すべての未のKEKを発行する必要があります。それがFALSEに設定されている場合は、すべての未のKEKを再発行する必要はありません。
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を使用しています。 glAddOwnerメッセージは、登録GLOによって署名されなければなりません。 glAddOwner制御属性は、構文GLOwnerAdministrationがあります。
GLOwnerAdministration ::= SEQUENCE {
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の暗号化証明書を含まなければなりません。
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を使用しています。 glRemoveOwnerメッセージは、登録GLOによって署名されなければなりません。 glRemoveOwner制御属性は、構文GLOwnerAdministrationがあります。
GLOwnerAdministration ::= SEQUENCE {
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の名前とアドレスを示しています。それが無視されるように証明書フィールドは、省略する必要があります。
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 compromised shared KEK. The name of the GL to which the compromised key is associated is placed in GeneralName:
GLメンバーとGLOsが侵害されている共有KEKが所有していることを示すために、glkCompromiseを使用しています。 glKeyCompromise制御属性は、構文のGeneralNameを持っています。このメッセージは、常にさらなる行動のためにGLOにGLAによってリダイレクトされます。 glkCompromiseが損なわ共有KEKで生成EnvelopedDataで含まれるかもしれません。妥協キーが関連付けられているGLの名前はのGeneralNameに配置されます。
GLKCompromise ::= GeneralName
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 }
Date ::= SEQUENCE {
start GeneralizedTime,
end 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メンバーが共有のKEKを望んでいる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メンバーは、現在の日付に指定した開始日からすべてのキーを望んで示すために省略されるかもしれません。手続きのメカニズムは、彼らがアクセスを許可されていないメッセージにアクセスするユーザーを制限するために必要であることに注意してください。
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メンバーが情報を要求するために、セクション3.1.10.1に定義されてglaQueryRequestを使用して、グラスは、要求された情報を返すために、セクション3.1.10.2に定義されてglaQueryResponseを、使用しています。セクション3.1.10.3は、一つの要求と応答のタイプおよび値を含みます。他の人は、追加のドキュメントで定義されることがあります。
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があります。
GLAQueryRequest ::= SEQUENCE {
glaRequestType OBJECT IDENTIFIER,
glaRequestValue ANY DEFINED BY glaRequestType }
GLAs return the glaQueryResponse after receiving a GLAQueryRequest. The glaQueryResponse MUST be signed by a GLA. The glaQueryResponse control attribute has the syntax GLAQueryResponse:
GLASはGLAQueryRequestを受けた後glaQueryResponseを返します。 glaQueryResponseはGLAによって署名されなければなりません。 glaQueryResponse制御属性は、構文GLAQueryResponseがあります。
GLAQueryResponse ::= SEQUENCE {
glaResponseType OBJECT IDENTIFIER,
glaResponseValue ANY DEFINED BY glaResponseType }
Requests and responses are registered as a pair under the following object identifier arc:
要求と応答は、以下のオブジェクト識別子アーク下ペアとして登録されています。
id-cmc-glaRR OBJECT IDENTIFIER ::= { id-cmc 99 }
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:
この文書では、それがサポートするアルゴリズムのリストについては、GLAを照会するGLメンバーとGLOsのために一つのリクエスト/レスポンスのペアを定義します。次のオブジェクト識別子（OID）がglaQueryTypeフィールドに含まれています。
id-cmc-gla-skdAlgRequest OBJECT IDENTIFIER ::={ id-cmc-glaRR 1 }
SKDAlgRequest ::= NULL
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 }
The glaQueryValue has the form of the smimeCapabilities attributes as defined in [MSG].
glaQueryValueは[MSG]で定義されるようにSMIMEケーパビリティの形態属性有します。
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を使用しています。 glProvideCertメッセージがGLAまたはGLOのいずれかによって署名されなければなりません。 GLメンバーのPKCが取り消された場合は、GLOまたはGLAはglProvideCert要求をカプセル化したEnvelopedDataを生成するためにそれを使用してはなりません。 glProvideCert制御属性は、構文GLManageCertがあります。
GLManageCert ::= SEQUENCE {
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.
- 証明書は省略されるべきです。
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を使用しています。 GLメンバーはglProvideCertメッセージを受信した結果として迷惑glUpdateCertを生成または応答glUpdateCertを生成することができます。 GLメンバーはglUpdateCertに署名しなければなりません。 GLメンバーの暗号化証明書が失効している場合は、GLメンバーはglUpdateCert要求や応答をカプセル化したEnvelopedDataを生成するためにそれを使用してはなりません。 glUpdateCert制御属性は、構文GLManageCertがあります。
GLManageCert ::= SEQUENCE {
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:
- GLManageCertメッセージがGLメンバーの証明書を要求するために送られた場合、証明書を省略することができます。そうでない場合は、それを含まなければなりません。これは、次の3つのフィールドが含まれています。
--- certificates.pKC includes the member's encryption
certificate that will be used to encrypt the shared KEK
for that member.
--- certificates.aC MAY be included to convey one or more
attribute certificates associated with the member's
encryption certificate.
--- 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).
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を使用しています。 glKeyメッセージがGLAによって署名されなければなりません。 glKey制御属性は、構文GLKeyがあります。
GLKey ::= SEQUENCE {
glName GeneralName,
glIdentifier KEKIdentifier, -- See [CMS]
glkWrapped RecipientInfos, -- See [CMS]
glkAlgorithm AlgorithmIdentifier,
glkNotBefore GeneralizedTime,
glkNotAfter GeneralizedTime }
-- 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 }
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のキー識別子です。サブフィールドの説明については、[CMS]のセクション6.2.3を参照してください。
- 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です。 [CMS]のセクション6.2で指定されているのrecipientInfosが生成されなければなりません。 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を使用しているアルゴリズムを識別する。全く暗号化されたデータの内容は、この時点で搬送されていないので、アルゴリズムを用いて符号化パラメータがSMIMEケーパビリティではなく、暗号化されたコンテンツのために定義された構造であるべきです。
- 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は、各受信者に対して個別の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は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は、各受信者に対して個別の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はglKeyメッセージの要求された数を発生させなければなりません。 glUseKEK.glKeyAttributes.generationCounterの値は、要求されたglKeyメッセージの数を示します。
- The GLA MUST generate one glKey message for each outstanding shared KEKs for the GL when glRekeyAllGLKeys is set to TRUE.
- GLAはglRekeyAllGLKeysがTRUEに設定されているGL各発行済共有のKEKのための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コントロールはリキー場所）に応答しなかった場合。
- 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は、受信者ごとに個別の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前glKeyメッセージの数がgenerationCounterマイナス1（1）で生成されたKEKが期限切れ共有卓越した最後に期間、へglKeyメッセージを生成してもよいです。その他の配布メカニズムにもこの機能をサポートするためにサポートすることができます。
The following sections outline the use of CMC, CMS, and the PKIX certificate and CRL profile.
次のセクションでは、CMC、CMSの使用、およびPKIX証明書とCRLプロファイルを概説します。
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のをカプセル化するために複数の方法があります。最初は、[MSG]で指定されるように、各ContentInfoの周りMIMEラッパーを使用することです。第二は、[X400TRANS] X.400でS / MIMEオブジェクトの輸送に指定されるように、各ContentInfoの周りMIMEラッパーを使用しないことです。
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
Prior to taking any action on any request or response SignedData(s) MUST be processed according to [CMS].
任意の要求または応答のSignedData（S）上の任意のアクションを取る前には、[CMS]に従って処理されなければなりません。
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
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].
受信メッセージが暗号化されている場合、メッセージの機密性は維持されなければなりません。 [CMS]に指定されているすべてのEnvelopedDataオブジェクトを処理しなければなりません。 SignedDataをEnvelopedDataの上で追加された場合、ContentHints属性を追加する必要があります。 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はGLOにGLメンバー要求を転送する場合は、GLAは、EnvelopedDataのコンテンツを復号化する機密性層を除去し、受信者としてGLOとEnvelopedDataのよう独自の機密性層を適用しなければなりません。
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:
GLに対応する複数の要求と応答は1 PKIData.controlSequenceまたはPKIResponse.controlSequenceに含まれるかもしれません。複数のGLsのための要求と応答はPKIData.cmsSequenceとPKIResponse.cmsSequenceを使用することで、1つまたはPKIData PKIResponseで組み合わせることができます。別cmsSequenceは異なるGLsのために使用しなければなりません。すなわち、2つの異なったGLsのに対応する要求が異なるcmsSequencesに含まれている、です。以下は、1 PKIDataとPKIResponseに組み合わせ、複数の要求と応答を示す図です。
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
When applying confidentiality to multiple requests and responses, all of the requests/responses MAY be included in one EnvelopedData. The following is a depiction:
複数の要求と応答に機密性を適用する場合、リクエスト/レスポンスの全てが1 EnvelopedDataの中に含まれるかもしれません。以下は描写です。
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
Certain combinations of requests in one PKIData.controlSequence and one PKIResponse.controlSequence are not allowed. The invalid combinations listed here MUST NOT be generated:
1 PKIData.controlSequenceと1 PKIResponse.controlSequenceにおける要求の特定の組み合わせは許可されません。ここに記載された無効な組み合わせが生成されてはなりません。
Invalid Combinations
---------------------------
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.
不要なエラーを回避するには、特定の要求と応答は、他の人の前に処理されるべきです。 glUseKEKをglRekey前glAddMember、glRekey glAddMember前、及びglDeleteMember前に次のメッセージの処理の優先順位であり、記載されていない場合には、最初に処理するような実装の決定です。処理の優先順位があることに注意してください、それはコンテンツ内の順序を意味するものではありません。
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は、各受信者に対して生成されなければなりません。しかし、同じ受信者に複数の属性を一つのメッセージを送信するために有効です。
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が要求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のはリダイレクトされたリクエストに適用する必要があります：
GLA Forwarded Requests
----------------------
SignedData
PKIData
cmsSequence
SignedData
PKIData
controlSequence
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]で定義されています。これらの属性のいくつかが必要です。他はオプションです。次のように必要な属性は以下のとおりです。cMCStatusInfoExtのtransactionId、senderNonce、recipientNonce、queryPending、およびsigningTime。他の属性も使用することができます。しかし、それらの使用は、このドキュメントの範囲を超えています。次のセクションでは、すでに[CMC]と[CMS]で指定されたものに加えて、要件を指定します。
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つのクラスが、この文書内で使用されています。 CMCで定義されているCMCのセクション5.1.4に見られるCMCFailInfoリストからエラーは、符号化されます。この文書で定義されたエラーコードはcmcStatusInfoExt構造のExtendedFailInfoフィールドを使用して符号化されます。同じ故障コードが複数のコマンドに適用される場合、単一cmcStatusInfoExt構造はcMCStatusInfoExt.bodyListにおける複数の項目と一緒に使用することができます。 GLAはまた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) }
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) }
- 廃止された（10）、alreadyAMember（11）、notAMember（12）、alreadyAnOwner（13）、notAnOwner（14）}
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メンバーであることを示しています。
- 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によって使用されます。リクエストが成功した場合、GLAはcMCStatus.successとstatusStringで必要に応じて他の関連情報と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は、必要に応じて追加の情報を伝えるために返されます。また、適切なSKDFailInfoはcMCStatusInfoExt.extendedFailInfoに含めることができます。
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、グラス、及びGLメンバーによって使用されます。署名はcMCStatusInfoExt以外の任意の制御属性をオーバー検証に失敗した場合、cMCStatusInfoExt制御属性がcMCStatus.failedとotherInfo.failInfo.badMessageCheckを示す返さなければなりません。最外PKIData上署名が失敗した場合、バディリストの値がゼロ（0）。他PKIDataにわたる署名が失敗した場合、バディリストの値は、要求または応答からbodyPartId値です。署名badMessageCheckメッセージループを回避するための新しい要求を生成する必要が無効であるcMCStatusInfoExtメッセージを受信GLOsとGLメンバー。
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により、すぐに処理できなかった場合は、cMCStatusInfoExt制御属性がcMCStatus.pendingとotherInfo.pendInfoを示す返されなければなりません。要求は（管理リスト用）、承認のためにGLOにリダイレクトされている場合、GLAは、保留中のクエリを示すcMCStatusInfoExtを返してはなりません。
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がサポートされていない場合、cMCStatusInfoExt制御属性がcMCStatus.noSupportを示す返さなければならないと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.
cMCStatusInfoExtもsigningTime（セクション3.2.4.3を参照）をローカルに指定した時間に十分に近接していないことを示すために、GLメンバー、GLOs、およびグラスで使用されています。現地時間はsigningTimeで指定した時間に十分に近接していない場合は、cMCStatus.failedとotherInfo.failInfo.badTimeが返されることがあります。
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、グラス、またはGLメンバーが含まれるかもしれません。元の要求に関連するすべての後続の要求と応答が同じのtransactionIdコントロール属性を含まなければなりません。 GLメンバーがのtransactionIdが含まれており、要求がGLOにリダイレクトされている場合は、GLAは外側PKIDataで追加のtransactionIdを含むかもしれません。 GLAはGLOそれはGLAののtransactionIdを持つGLA用とGLメンバーののtransactionIdを持つGLメンバーのいずれかを生成cMCStatusInfoExt応答を生成外側PKIData、で追加のtransactionIdが含まれていた場合。
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は、必要に応じて新たなノンス値を生成し、含むかもしれラッピングメッセージです。応答がGLOから戻ってくると、GLAは、発信メッセージからノンス値のそれぞれとのメッセージ（S）やお得な情報の発信元（S）への応答を構築します。
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.
これらの属性のために、別の結果を比較するために交流の状態情報を維持する必要があります。この情報が維持される期間は、ローカルポリシーです。
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は、この仕様に準拠考慮されるべき実装のための属性を署名しました。
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
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はcmsSequence項目としてGLメンバー要求（単数または複数）を含む新しいリクエストメッセージを作成してGLO承認のためにGLOにGLメンバー要求を転送します。 GLOが要求を承認した場合、それは、ラッピングの新しいレイヤーを追加し、GLAにそれを送り返すか、新しいメッセージを作成して、GLAにそれを送ることができます。 （この場合には適切な署名層を有するPKIDataメッセージの3層が今あります）。
Signatures, certificates, and CRLs are verified according to the PKIX profile [PROFILE].
署名、証明書、CRLはPKIXプロフィール[PROFILE]に従って検証されます。
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].
すべての識別名の形式はUTF8Stringを規則に従わなければなりませんPKIXプロフィール[PROFILE]で指摘しました。
A certificate per GL would be issued to the GLA.
GLあたりの証明書は、GLAに対して発行されるだろう。
GL policy may mandate that the GL member's address be included in the GL member's certificate.
GL方針は、GLメンバーのアドレスがGLメンバーの証明書に含まれていることを義務付けることがあります。
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を管理するために交換しなければならない管理メッセージの数があります。以下のセクションでは、詳細に各要求および応答メッセージの組み合わせを記載しています。このセクションで定義された手順は、規範的ではありません。
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を割り当てるためのプロトコル相互作用を示します。そのエラーメッセージはまた、任意のtransactionId、senderNonce、及びrecipientNonce CMCコントロール属性の動作は、これらの手順で対処されていない図3に示されていない注意してください。
+-----+ 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（図3における1）GLAにSignedData.PKIData.controlSequence.glUseKEK要求を送信します。 GLOはglName、glAddress、glOwnerName、glOwnerAddress、およびglAdministrationを含まなければなりません。 GLOはまた、GLOは別個glKeyメッセージがrecipientsNotMutuallyAware、requestedAlgorithmに共有KEKで使用される要求されたアルゴリズムでは、各受信者に送信されるべきかどうか、rekeyControlledByGLOでリキーを制御するかどうかを示すことによってglKeyAttributesで共有KEKのために自分の好みを含むかもしれ共有KEKの期間、どのように多くの共有のKEK当初generationCounterに分配されなければなりません。 GLOも、この要求に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要求（複数可）glUseKEK要求（セクション3.2.2を参照）と同じcontrolSequenceに含まれるかもしれません。 GLOはglUseKEK.glInfo.glNameのようにglAddMember要求で同じglNameを示しています。さらにglAddMember手順は、セクション4.3で説明されています。
1.b - The GLO can apply confidentiality to the request by encapsulating the SignedData.PKIData in an EnvelopedData (see Section 3.2.1.2).
1.B - GLO（セクション3.2.1.2参照）EnvelopedDataでSignedData.PKIDataをカプセル化することによって要求に秘密性を適用することができます。
1.c - The GLO can also optionally apply another SignedData over the EnvelopedData (see Section 3.2.1.2).
1.C - GLOはまた、必要に応じてEnvelopedDataの上に別のSignedDataを適用することができる（セクション3.2.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はsigningTimeをチェックして、最も内側のSignedData.PKIData上の署名を検証します。追加のSignedData及び/又はEnvelopedDataのは（セクション3.2.1.2および3.2.2を参照）要求をカプセル化する場合、GLAは外側の署名（S）を検証および/または最も内側の署名を検証する前に外層（複数可）を復号しますSignedData。
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属性値がローカルで受け入れられた時間ウィンドウ内にない場合は、GLAはcMCStatus.failedとotherInfo.failInfo.badTimeと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はcMCStatus.failedとotherInfo.failInfo.badMessageCheckを示すcMCStatusInfoExt応答を返します。さらに、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はnoValidGLACertificateのcMCStatus.failedとotherInfo.extendedFailInfo.SKDFailInfo値でcMCStatusInfoExtを返します。さらに、signingTime属性は応答に含まれています。代わりに、直ちにエラー・コードを返す、GLAは、おそらく[CMC]を使用して、証明書を取得することを試みます。
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が有効な証明書を持っている、GLAが要求に署名するために使用される証明書の名前の1がglUseKEK.glOwnerInfo.glOwnerNameの名前の1つと一致していることを確認します。
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属性は応答に含まれています。
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が既に使用されていないことを確認します。 GLAはまた、任意のglAddMemberこのglUseKEKにcontrolSequence内に含まチェックします。 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はcMCStatus.failedとnameAlreadyInUseの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はcMCStatus.failedとunsupportedDurationの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を開示したくない他の理由のためにサポートすることができない場合はそうでは、GLAは、不特定のcMCStatus.failedとotherInfo.extendedFailInfo.SKDFailInfo値とcMCStatusInfoExtを示す応答を返します。さらに、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はcMCStatus.successとsigningTime属性を示すcMCStatusInfoExtを返さなければなりません。 （図3の2）。 GLAはまたglName、glAddress、glKeyAttributes、glOwnerName、およびglOwnerAddressを保存するために、このドキュメントの範囲を超えての管理アクションをとります。セクション5に記載されているようにGLAもglKeyメッセージを送信します。
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).
2.d.2.e.1 - 要求がEnvelopedDataの（セクション3.2.1.2を参照）内にカプセル化された場合、GLAはEnvelopedDataでSignedData.PKIResponseをカプセル化することによって応答に機密性を適用することができます。
2.d.2.e.2 - The GLA can also optionally apply another SignedData over the EnvelopedData (see Section 3.2.1.2).
2.d.2.e.2 - GLAはまた、必要に応じてEnvelopedDataの上に別のSignedDataを適用することができる（セクション3.2.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署名（S）を検証します。追加のSignedData及び/又はEnvelopedDataの場合の応答を（セクション3.2.1.2または3.2.2を参照）、GLOは外側の署名を検証及び/又は最も内側のSignedDataの署名を検証する前に、外側の層を解読カプセル化します。
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属性値がローカルで受け入れられた時間ウィンドウ内にない場合、GLOはcMCStatus.failedとotherInfo.failInfo.badTimeと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は、応答に署名するために使用される証明書の名前の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節を参照）。
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 |
+-----+ +-----+
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は、（図4に1）GLAへSignedData.PKIData.controlSequence.glDelete要求を送信します。削除するGLの名前がいるGeneralNameに含まれています。 GLOも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).
1.A - GLOは、必要に応じてEnvelopedDataでSignedData.PKIData（セクション3.2.1.2を参照）をカプセル化することによって要求に秘密性を適用することができます。
1.b - The GLO MAY optionally apply another SignedData over the EnvelopedData (see Section 3.2.1.2).
1.B - GLOは、必要に応じてEnvelopedDataの上に別のSignedData（セクション3.2.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はsigningTimeをチェックして、最も内側のSignedData.PKIData上の署名を検証します。追加のSignedDataおよび/またはEnvelopedDataの要求をカプセル化する場合、GLAは外側の署名を検証及び/又は最も内側のSignedDataの署名を検証する前に、外側の層を解読し（セクション3.2.1.2または3.2.2を参照）。
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属性値がローカルで受け入れられた時間ウィンドウ内にない場合は、GLAはcMCStatus.failedとotherInfo.failInfo.badTimeと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 checking the name of the GL matches a glName stored on the GLA.
2.C - 署名が検証した場合にそうでは、GLAはGLAに保存されているglNameと一致することを確認GLは、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要求が登録された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がGLAを開示することを希望していない他の理由で削除することができないそうであれば、GLAはcMCStatus.failedとotherInfo.extendedFailInfoでcMCStatusInfoExtを示す応答を返します。未指定のSKDFailInfo値。さらに、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と（図4の2）signingTime属性を示すcMCStatusInfoExtを返します。 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).
2.c.2.c.1 - 要求がEnvelopedDataの（セクション3.2.1.2を参照）内にカプセル化された場合、GLAはEnvelopedDataでSignedData.PKIResponseをカプセル化することによって応答に機密性を適用することができます。
2.c.2.c.2 - The GLA MAY optionally apply another SignedData over the EnvelopedData (see Section 3.2.1.2).
2.c.2.c.2 - GLAは、必要に応じてEnvelopedDataの上に別のSignedData（セクション3.2.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署名（S）を検証します。追加のSignedData及び/又はEnvelopedDataの場合の応答を（セクション3.2.1.2または3.2.2を参照）、GLOは外側の署名を検証及び/又は最も内側のSignedDataの署名を検証する前に、外側の層を解読カプセル化します。
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属性値がローカルで受け入れられた時間ウィンドウ内にない場合、GLOはcMCStatus.failedとotherInfo.failInfo.badTimeと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 - そうでなければ、署名処理が継続する場合と署名が検証場合、応答に署名するために使用される証明書の名前の1つは、GLの名前と一致していることをGLOチェック。
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 - エルス署名が検証しないとの応答が何らかの理由でcMCStatusInfoExt.cMCStatus.failedれた場合、GLOは、応答で提供された情報を使用して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 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.
GLsのにメンバーを追加するには、GLOまたは会員候補者のいずれかがglAddMember要求を使用します。 GLAは違ったもののGLOと将来のGLメンバー要求を処理します。 GLOsはGLにメンバーを追加するための任意の時点で要求を提出することができ、およびGLAは、それは要求が登録さGLOから来検証した後、それを処理する必要があります。会員候補者が要求を送信した場合、GLAは、GLを投与する方法を決定する必要があります。 GLOが最初にGLを設定すると、それは、GLが管理されていないように設定、管理、または（3.1.1項を参照）を閉じました。管理されていない場合には、GLAは、単にメンバーの要求を処理します。管理する場合には、GLAはレビューのためにGLOに会員候補者からの要求を転送します。要求は、このドキュメントの範囲を超えているために転送されGLO GL、のために複数のGLOsはどこにあります。 GLOは要求をレビューし、どちらかそれを拒絶するか、GLAへの改革要求を送信します。閉じられた場合には、GLAは、会員候補者からの要求を受け付けません。以下のセクションでは、GLOまたは将来のメンバーのいずれかから、glAddMeber要求が発信場所によってGLO（S）、GLA、及び将来のGLメンバーの処理を記載しています。図5は、3つのオプションのためのプロトコル相互作用を示します。エラーメッセージが描かれていないことに注意してください。また、これらの手順で対処されていないオプションのtransactionId、senderNonce、およびrecipientNonce CMCコントロール属性のためのその行動に注意してください。
+-----+ 2,B{A} 3 +----------+
| GLO | <--------+ +-------> | Member 1 |
+-----+ | | +----------+
1 | |
+-----+ <--------+ | 3 +----------+
| GLA | A +-------> | ... |
+-----+ <-------------+ +----------+
|
| 3 +----------+
+-------> | Member 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.
グループ単位で行われる必要がある重要な決定は、グループに新しいメンバーが追加されるたびにキーを再生成するかどうかです。新しいメンバが追加されたときにグループが大きくなるようにグループを再入力に関連するオーバーヘッドは、法外なほど、典型的には、アンマネージGLSが、リキーされるべきではありません。ただし、管理およびクローズドGLsのは、グループのメンバーによって送信されるトラフィックの機密性を維持するために、リキーすることができます。メンバーが追加されたときに、管理または閉じGLsのを再入力するためのオプションは、異なるグループキーで新しいGLを生成することです。グループ再キーイングは、セクション4.5と5で説明されています。
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 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.
1 - GLOを追加する部材（単数または複数）のための適切な情報を収集する（これはアウト・オブ・バンドを介して行うことができることを意味します）。 GLOは次に（図5の1）GLAの各メンバーのための別個glAddMember要求にSignedData.PKIData.controlSequenceを送信します。 GLOはglName、glMember.glMemberName、glMember.glMemberAddress内のメンバーのアドレスでメンバーの名前にGL名、およびglMember.certificates.pKC内のメンバーの暗号化証明書が含まれています。 GLOもglMember.certificates.aC内のメンバーの暗号化証明書に関連するすべての属性証明書、およびメンバーの暗号化に関連付けられた証明書パスを含めるとglMember.certificates.certPathに属性証明書をすることができます。 GLOも、この要求に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).
1.A - GLOは、必要に応じてEnvelopedDataでSignedData.PKIData（セクション3.2.1.2を参照）をカプセル化することによって要求に秘密性を適用することができます。
1.b - The GLO can also optionally apply another SignedData over the EnvelopedData (see Section 3.2.1.2).
1.B - GLOはまた、必要に応じてEnvelopedDataの上に別のSignedData（セクション3.2.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はsigningTimeをチェックして、最も内側のSignedData.PKIData上の署名を検証します。追加のSignedDataおよび/またはEnvelopedDataの要求をカプセル化する場合、GLAは外側の署名を検証及び/又は最も内側のSignedDataの署名を検証する前に、外側の層を解読し（セクション3.2.1.2または3.2.2を参照）。
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属性値がローカルで受け入れられた時間ウィンドウ内にない場合は、GLAはcMCStatus.failedとotherInfo.failInfo.badTimeと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要求が正常に完了しglUseKEK要求にcontrolSequence、およびセクション4.1アイテム2.Dの処理に含まれているが、GLAはcMCStatus.successとsigningTime属性を示すcMCStatusInfoExtを返します（図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).
2.C.1 - GLAが要求がEnvelopedDataの（セクション3.2.1.2を参照）内にカプセル化された場合EnvelopedDataでSignedData.PKIDataをカプセル化することによって応答に機密性を適用することができます。
2.c.2 - The GLA can also optionally apply another SignedData over the EnvelopedData (see Section 3.2.1.2).
2.c.2 - GLAはまた、必要に応じてEnvelopedDataの上に別のSignedDataを適用することができる（セクション3.2.1.2を参照）。
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 - 署名が検証し、GLAddMember要求はGLCreate要求にcontrolSequenceに含まれていない場合はそうでなければ、GLAは、GLがglNameがGLAに格納されているglNameと一致することを確認することでサポートされているを確認します。
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はalreadyAMemberのcMCStatus.failedとotherInfo.extendedFailInfo.SKDFailInfo値とcMCStatusInfoExtを示す応答を返します。さらに、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、GLが投与され、どのようにGLAチェック上に存在しない場合はそうで。
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登録GLOがデジタル署名証明書の名前の1つは、要求が登録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はGLOにinvalidCertのcMCStatus.failedとotherInfo.extendedFailInfo.SKDFailInfo値でcMCStatusInfoExtを示す応答を返すことができます。
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).
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はcMCStatus.successとsigningTime属性（図5の2）を示すcMCStatusInfoExtを返します。 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).
2.d.2.b.1.b.2.a - GLAが要求がEnvelopedDataの（セクション3.2.1.2を参照）内にカプセル化された場合EnvelopedDataでSignedData.PKIDataをカプセル化することによって応答に機密性を適用します。
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).
2.d.2.b.1.b.2.b - GLAはまた、必要に応じてEnvelopedDataの上に別のSignedData（セクション3.2.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のために、要求に署名するために使用される証明書の名前の1は、登録されたGLOと一致する必要があります。会員候補者のために、glMember.glMemberNameの名前が要求に署名するために使用される証明書の名前のいずれかに一致する必要があります。
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属性は応答に含まれています。
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は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はGLO（図5の2）にcMCStatus.successとsigningTime属性を示すcMCStatusInfoExtを返さなければなりません。 GLAはまた、GLAに格納されているGLにメンバーを追加するには、このドキュメントの範囲を超えての管理アクションをとります。 GLAはまた、GLポリシーがGLメンバーのアドレスがGLメンバーの証明書に含まれることを義務付けてもよい項5に記載の機構を介してメンバーに共有KEKを配信します。
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).
2.d.2.b.2.b.2.a - GLAが要求がEnvelopedDataの（セクション3.2.1.2を参照）内にカプセル化された場合EnvelopedDataでSignedData.PKIDataをカプセル化することによって応答に機密性を適用します。
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).
2.d.2.b.2.b.2.b - GLAはまた、必要に応じてEnvelopedDataの上に別のSignedData（セクション3.2.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 document. Further processing of the forwarded request by GLOs is addressed in 3 of Section 4.3.2.
2.d.2.b.2.c - そうで署名者が見込みメンバーである場合、GLAは、登録されたGLO（図5のB {A}）に（セクション3.2.3参照）glAddMember要求を転送します。複数の登録GLOがある場合は、要求が転送されるためにGLOは、このドキュメントの範囲を超えています。 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).
2.d.2.b.2.c.1 - GLAは、元の要求がEnvelopedDataの（セクション3.2.1.2を参照）内にカプセル化された場合EnvelopedDataでSignedData.PKIDataをカプセル化することによって転送された要求への秘密性を適用します。
2.d.2.b.2.c.2 - The GLA can also optionally apply another SignedData over the EnvelopedData (see Section 3.2.1.2).
2.d.2.b.2.c.2 - GLAはまた、必要に応じてEnvelopedDataの上に別のSignedDataを適用することができる（セクション3.2.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のために、要求に署名するために使用される証明書の名前の1は、登録されたGLOの名前と一致する必要があります。会員候補者のために、glMember.glMemberNameの名前が要求に署名するために使用される証明書の名前のいずれかに一致する必要があります。
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値とsigningTime属性でcMCStatusInfoExtを示す応答を返すことができますGLOまたは要求元の場所に応じて将来の部材。 GLAはcMCStatus.failed応答を返さない場合は、GLAは、（参照glProvideCert要求を発行します
Section 4.10) to either the GLO or
prospective member depending on where the
request originated.
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 - それ以外のメンバーの証明書を検証する場合、GLAはGLOが要求に署名した場合GLO（図5の2）にcMCStatus.successとsigningTime属性を示すcMCStatusInfoExtを返しGL部材（図5の3）〜GLメンバーは要求に署名した場合。 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).
2.d.2.b.3.b.2.a - GLAが要求がEnvelopedDataの（セクション3.2.1.2を参照）内にカプセル化された場合EnvelopedDataでSignedData.PKIDataをカプセル化することによって応答に機密性を適用します。
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).
2.d.2.b.3.b.2.b - GLAはまた、必要に応じてEnvelopedDataの上に別のSignedData（セクション3.2.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署名（S）を検証します。追加のSignedData及び/又はEnvelopedDataの場合の応答を（セクション3.2.1.2または3.2.2を参照）、GLOは外側の署名を検証及び/又は最も内側のSignedDataの署名を検証する前に、外側の層を解読カプセル化します。
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属性値がローカルで受け入れられた時間ウィンドウ内にない場合、GLOはcMCStatus.failedとotherInfo.failInfo.badTimeと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 - そうでなければ、署名処理が継続する場合と署名が検証場合、応答に署名するために使用される証明書の名前の1つは、GLの名前と一致していることをGLOチェック。
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はGLメンバーにcMCStatusInfoExt.cMCStatus.successとsigningTime属性を送信します。
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.
4 - cMCStatusInfoExt応答を受信すると、将来のメンバーはsigningTimeをチェックして、GLA署名またはGLO署名を検証します。追加のSignedData及び/又はEnvelopedDataの場合の応答を（セクション3.2.1.2または3.2.2を参照）、GLOは外側の署名を検証及び/又は最も内側のSignedDataの署名を検証する前に、外側の層を解読カプセル化します。
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と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 - そうでなければ、署名処理が継続する場合と署名が検証場合、応答に署名するために使用される証明書の名前の1つは、GLの名前と一致することを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.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に自分自身を追加するために再試行するかもしれません。
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、glMember.glMemberNameで自分の名前、glMember.glMemberAddressで自分のアドレス、およびglMember.certificates.pKCでの暗号化証明書におけるGL名を。将来の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).
1.A - 将来のGLメンバーは、必要に応じてEnvelopedDataでSignedData.PKIData（セクション3.2.1.2を参照）をカプセル化することによって要求に秘密性を適用することができます。
1.b - The prospective GL member MAY optionally apply another SignedData over the EnvelopedData (see Section 3.2.1.2).
1.B - 将来のGLメンバーは、必要に応じてEnvelopedDataの上に別のSignedData（セクション3.2.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はsigningTimeをチェックして、外側の層の上に最内SignedData.PKIDataに将来のGLメンバー署名およびGLAの署名を検証します。 EnvelopedDataの最も内側の層をカプセル化する場合、GLOは最も内側のSignedDataの署名を検証する前に、外側の層を解読し（セクション3.2.1.2または3.2.2を参照）。
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.
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は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バックcMCStatusInfoExt.cMCtatus.failedと将来のメンバーにSignedData.PKIResponse.controlSequenceメッセージを返すことができる理由将来の部材を示しますcMCStatus.statusStringで拒否されました。さらに、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がSignedData.PKIResponse.controlSequenceバックメンバーの暗号化証明書がcMCStatusに検証していなかったことを示すcMCStatusInfoExt.cMCtatus.failedと将来のメンバーに戻ります。 statusString。さらに、signingTime属性は応答に含まれています。 GLOはcMCStatusInfoExt応答を返さない場合は、GLOは、送信します
SignedData.PKIData.controlSequence.glProvideCert
message to the prospective member requesting a
new encryption certificate (see Section 4.10).
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はGLA（図5の1）に（セクション3.2.5参照）glAddMember要求を再送信します。
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.b.2.b.2.a - GLOは、最初の要求が（3.2.1.2項を参照）EnvelopedDataの中にカプセル化された場合のEnvelopedDataでSignedData.PKIDataをカプセル化することによって、新たなGLAddMember要求に機密性が適用されます。
3.b.2.b.2.b - The GLO can also optionally apply another SignedData over the EnvelopedData (see Section 3.2.1.2).
3.b.2.b.2.b - GLOはまた、必要に応じてEnvelopedDataの上に別のSignedData（セクション3.2.1.2を参照）を適用することができます。
4 - Processing continues as in 2 of Section 4.3.1.
4 - 処理は、セクション4.3.1の2のように継続します。
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.
使用glDeleteMember要求を削除するのいずれかGLOまたはメンバー、GLsのからメンバーを削除します。 GLAはGLOを処理し、そして自分自身の削除を要求するメンバーは、異なる要求を行います。 GLOはGLからメンバーを削除するには、いつでもリクエストを送信し、GLA、それは要求が登録さGLOから来検証した後、メンバーを削除する必要がありますすることができます。メンバーがリクエストを送信した場合、GLAは、GLを投与する方法を決定する必要があります。 GLOが最初にGLを設定すると、それは、GLが管理されていないように設定、管理、または（3.1.1項を参照）を閉じました。管理されていない場合には、GLAは、単にメンバーの要求を処理します。管理する場合には、GLAはレビューのためにGLOにメンバーからの要求を転送します。要求は、このドキュメントの範囲を超えているために転送されGLO GL、のために複数のGLOsはどこにあります。 GLOは要求をレビューし、どちらかそれを拒絶するか、GLAへの改革要求を送信します。閉じられた場合には、GLAはメンバーからの要求を受け付けません。以下のセクションでは、GLOまたは除去することを望むメンバーのいずれかから、要求元の場所に応じてGLO（S）、GLA、及びGLメンバーの処理を記載しています。図6は、3つのオプションのためのプロトコル相互作用を示します。エラーメッセージが描かれていないことに注意してください。さらに、オプションのtransactionId、senderNonce、およびrecipientNonce CMCコントロール属性の動作は、これらの手順で対処されていません。
+-----+ 2,B{A} 3 +----------+
| GLO | <--------+ +-------> | Member 1 |
+-----+ | | +----------+
1 | |
+-----+ <--------+ | 3 +----------+
| GLA | A +-------> | ... |
+-----+ <-------------+ +----------+
|
| 3 +----------+
+-------> | Member 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に自分自身を再び追加していないという保証がないため、管理対象外のリストでは、グループリキーにも意味がありません。管理および閉じGLsのために、GLOは削除されるメンバーは二度GL上にないことを保証するための措置をとる必要があります。これを確認した後、管理およびクローズドGLsのは、グループのメンバーによって送信されるトラフィックの機密性を維持するために、リキーすることができます。 GLOはメンバーが削除されたことを確認された場合は、グループキー更新メカニズムは、新しいキーを配布するために使用することができます（セクション4.5および5を参照）。
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はその後GLA（図6の1）に各メンバーの別glDeleteMember要求にSignedData.PKIData.controlSequenceを送信します。 GLOはGLのglNameで名前とglMemberToDeleteでメンバーの名前を含まなければなりません。メンバーが削除されているからGLが閉じまたは管理GLであれば、GLOもglRekey要求を生成し、glDeletemember要求（4.5節を参照）とそれを含まなければなりません。 GLOも、この要求に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).
1.A - GLOは、必要に応じてEnvelopedDataでSignedData.PKIData（セクション3.2.1.2を参照）をカプセル化することによって要求に秘密性を適用することができます。
1.b - The GLO can also optionally apply another SignedData over the EnvelopedData (see Section 3.2.1.2).
1.B - GLOはまた、必要に応じてEnvelopedDataの上に別のSignedData（セクション3.2.1.2を参照）を適用することができます。
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の要求をカプセル化する場合、GLAは外側の署名を検証及び/又は最も内側のSignedDataの署名を検証する前に、外側の層を解読し（セクション3.2.1.2または3.2.2を参照）。
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属性値がローカルで受け入れられた時間ウィンドウ内にない場合は、GLAはcMCStatus.failedとotherInfo.failInfo.badTimeと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 - 署名が検証した場合にそうでは、GLAは、GLがglNameがGLAに格納されているglNameと一致することを確認することで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とnotAMemberのotherInfo.extendedFailInfo.SKDFailInfo値とcMCStatusInfoExtを示す応答を返します。さらに、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登録GLOがデジタル署名証明書の名前の1つは、要求が登録GLO一致署名するために使用されることを確認することによって要求に署名したことをチェックします。
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と（図5の2）signingTime属性を返します。 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).
2.c.2.b.1.b.1 - GLAが要求がEnvelopedDataの（セクション3.2.1.2を参照）内にカプセル化された場合EnvelopedDataでSignedData.PKIDataをカプセル化することによって応答に機密性を適用します。
2.c.2.b.1.b.2 - The GLA can also optionally apply another SignedData over the EnvelopedData (see Section 3.2.1.2).
2.c.2.b.1.b.2 - GLAはまた、必要に応じてEnvelopedDataの上に別のSignedDataを適用することができる（セクション3.2.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のために、要求に署名するために使用される証明書の名前の1は、登録されたGLOと一致する必要があります。会員候補者のために、glMember.glMemberNameの名前が要求に署名するために使用される証明書の名前のいずれかに一致する必要があります。
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 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.
2.c.2.b.2.b - そうでなければ、署名者が登録GLOであれば、GLAはcMCStatusInfoExt.cMCStatus.successとsigningTime属性（図6の2）を返します。 GLAはまた、GLAに格納されているGLを持つメンバーを削除するには、このドキュメントの範囲を超えての管理アクションをとります。第5節で説明したようにGLもリキーされることに注意してください。
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).
2.c.2.b.2.b.1 - GLAが要求がEnvelopedDataの（セクション3.2.1.2を参照）内にカプセル化された場合EnvelopedDataでSignedData.PKIDataをカプセル化することによって応答に機密性を適用します。
2.c.2.b.2.b.2 - The GLA can also optionally apply another SignedData over the EnvelopedData (see Section 3.2.1.2).
2.c.2.b.2.b.2 - GLAはまた、必要に応じてEnvelopedDataの上に別のSignedDataを適用することができる（セクション3.2.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はGLO（図6のB {A}）に（セクション3.2.3参照）glDeleteMember要求を転送します。複数の登録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).
2.c.2.b.2.c.1 - GLA要求が（セクション3.2.1.2参照）EnvelopedDataでカプセル化された場合EnvelopedDataでSignedData.PKIDataをカプセル化することによって転送された要求への秘密性を適用します。
2.c.2.b.2.c.2 - The GLA can also optionally apply another SignedData over the EnvelopedData (see Section 3.2.1.2).
2.c.2.b.2.c.2 - GLAはまた、必要に応じてEnvelopedDataの上に別のSignedDataを適用することができる（セクション3.2.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のために、要求に署名するために使用される証明書の名前の1は、登録されたGLOの名前と一致する必要があります。会員候補者のために、glMember.glMemberNameの名前が要求に署名するために使用される証明書の名前のいずれかに一致する必要があります。
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またはメンバーのいずれかである場合GLO場合、GLAはGLO（図6の2）にcMCStatusInfoExt.cMCStatus.successとsigningTime属性を返しますGLメンバーが要求に署名した場合、要求に署名し、GL部材（図6の3）です。 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).
2.c.2.b.3.b.1 - GLAが要求がEnvelopedDataの（セクション3.2.1.2を参照）内にカプセル化された場合EnvelopedDataでSignedData.PKIDataをカプセル化することによって応答に機密性を適用します。
2.c.2.b.3.b.2 - The GLA can also optionally apply another SignedData over the EnvelopedData (see Section 3.2.1.2).
2.c.2.b.3.b.2 - GLAはまた、必要に応じてEnvelopedDataの上に別のSignedDataを適用することができる（セクション3.2.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を参照）、GLOは外側の署名を検証及び/又は最も内側のSignedDataの署名を検証する前に、外側の層を解読カプセル化します。
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属性値がローカルで受け入れられた時間ウィンドウ内にない場合、GLOはcMCStatus.failedとotherInfo.failInfo.badTimeと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 - そうでなければ、署名処理が継続する場合と署名が検証しなければ、応答に署名するために使用される証明書の名前の1つは、GLの名前と一致していることをGLOチェック。
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はGLメンバーにcMCStatusInfoExt.cMCStatus.successとsigningTime属性を送信します。
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.
4 - cMCStatusInfoExt応答を受信すると、メンバーはsigningTimeをチェックして、GLA署名（S）またはGLO署名（S）を検証します。追加のSignedData及び/又はEnvelopedDataの場合の応答を（セクション3.2.1.2または3.2.2を参照）、GLOは外側の署名を検証及び/又は最も内側のSignedDataの署名を検証する前に、外側の層を解読カプセル化します。
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と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 - そうでなければ、署名処理が継続する場合と署名が検証場合、応答に署名するために使用される証明書の名前の1つは、GLの名前と一致することを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から削除されています。
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からそれ自体を削除するために再試行することができます。
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要求を送信します。メンバーはglNameでGLとglMemberToDeleteでメンバー自身の名前の名前が含まれています。 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).
1.A - メンバーは、必要に応じてEnvelopedDataでSignedData.PKIData（セクション3.2.1.2を参照）をカプセル化することによって要求に秘密性を適用することができます。
1.b - The member can also optionally apply another SignedData over the EnvelopedData (see Section 3.2.1.2).
1.B - メンバーは、任意EnvelopedDataの上に別のSignedData（セクション3.2.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はsigningTimeをチェックして、最も内側のSignedData.PKIDataと外層上GLA署名上のメンバーの署名を検証します。 EnvelopedDataの最も内側の層をカプセル化する場合、GLOは最も内側のSignedDataの署名を検証する前に、外側の層を解読し（セクション3.2.1.2または3.2.2を参照）。
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.
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属性値がローカルで受け入れられた時間ウィンドウ内にない場合、GLOはcMCStatus.failedとotherInfo.failInfo.badTimeとsigningTime属性を示す応答を返してもよいです。
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とsigningTime属性を示すcMCStatusInfoExt応答を返します。
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はGLA（図6の1）に（セクション3.2.5参照）glDeleteMember要求を再送信します。 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.c.2.a - GLOは、最初の要求が（3.2.1.2項を参照）EnvelopedDataの中にカプセル化された場合のEnvelopedDataでSignedData.PKIDataをカプセル化することによって、新たなGLDeleteMember要求に機密性が適用されます。
3.c.2.b - The GLO can also optionally apply another SignedData over the EnvelopedData (see Section 3.2.1.2).
3.c.2.b - GLOはまた、必要に応じてEnvelopedDataの上に別のSignedData（セクション3.2.1.2を参照）を適用することができます。
4 - Further processing is as in 2 of Section 4.4.1.
4 - さらなる処理はセクション4.4.1の2のようになります。
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要求が含まれているはずです。
- 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.
- メンバーは、管理対象外GLから削除されたときに、ポリシーに応じて。ポリシーはGLキーを再生成する場合、glDeleteMemberを含むPKIData.controlSequenceもglRekey要求またはアウトオブバンド手段がGLキーを再生成するためにGLAを伝えるために使用することができ含めることができます。メンバーが削除された管理対象外GLsのの鍵の再生成はお勧めできません。
- 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の再入力を制御している場合、GLAは新しい共有KEKが配布されなければならないことを前提とし、代わりにglRekeyメッセージを待つべきではありません。
-- If the GLA controls the GL rekey, the GLA should initiate a glKey message as specified in Section 5.
- GLAがGLの再入力を制御する場合、セクション5で指定されるように、GLAは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）よりも大きい値に設定され、GLOはGLの再入力を制御する場合、GLOはglRekeyに最後共有KEKが満了する前の任意の時間を生成することができます。安全側になるように、GLOは、最後の共有KEKが期限切れになる前に（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鍵再生成を開始することを許可された唯一のエンティティです。 GLOは、それらがキー更新を制御しようとしているかどうかGLAは、それらが（セクション3.1.1を参照）GLに共有KEKが割り当てられたときにキー更新を制御しようとしているかどうかを示します。 GLOはいつでもGLの再入力を開始します。 GLAは自動的に前共有KEK（満了までの時間の長さは、実装決定である）の満了にGLをリキーするように構成することができます。 GLAはまた、自動的に危険にさらされているGLsのをリキーすることができ、これは図7にGLの再入力を要求するためのプロトコル相互作用を示す図5のセクションで説明されています。エラーメッセージが描かれていないことに注意してください。さらに、オプションのtransactionId、senderNonce、およびrecipientNonce CMCコントロール属性の動作は、これらの手順で対処されていません。
+-----+ 1 2,A +-----+
| GLA | <-------> | GLO |
+-----+ +-----+
Figure 7 - GL Rekey Request
図7 - GLリキー要求
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は、すべての未共有のKEKのため再入力を強制したい場合は、TRUEに設定されglRekeyAllGLKeysが含まれています。 GLOも、この要求に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).
1.A - GLOは、必要に応じてEnvelopedDataでSignedData.PKIData（セクション3.2.1.2を参照）をカプセル化することによって要求に秘密性を適用することができます。
1.b - The GLO can also optionally apply another SignedData over the EnvelopedData (see Section 3.2.1.2).
1.B - GLOはまた、必要に応じてEnvelopedDataの上に別のSignedData（セクション3.2.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はsigningTimeをチェックして、最も内側のSignedData.PKIData上の署名を検証します。追加のSignedDataおよび/またはEnvelopedDataの要求をカプセル化する場合、GLAは外側の署名を検証及び/又は最も内側のSignedDataの署名を検証する前に、外側の層を解読し（セクション3.2.1.2または3.2.2を参照）。
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属性値がローカルで受け入れられた時間ウィンドウ内にない場合は、GLAはcMCStatus.failedとotherInfo.failInfo.badTimeと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はcMCStatus.failedとotherInfo.failInfo.badMessageCheckを示すcMCStatusInfoExt応答を返します。さらに、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 - 署名が検証しない場合はそうでは、GLAは、GLがglNameがGLAに格納されているglNameと一致することを確認することで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に格納されているGLと一致しない場合、GLAはinvalidGLNameのcMCStatus.failedとotherInfo.extendedFailInfo.SKDFailInfo値とcMCStatusInfoExtを示す応答を返します。さらに、signingTime属性は応答に含まれています。
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に格納されているGLと一致しそうであれば、GLA登録GLOは、証明書の名前の1つは、要求が登録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 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はcMCStatus.failedとotherInfo.extendedFailInfo.SKDFailInfo値とcMCStatusInfoExtを示す応答を返しますunsupportedDuration。さらに、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は不特定の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もKEK共有鍵更新を配布するglKeyメッセージを使用する（セクション5を参照）。
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).
2.c.2.b.4.a - GLAが要求がEnvelopedDataの（セクション3.2.1.2を参照）内にカプセル化された場合EnvelopedDataでSignedData.PKIDataをカプセル化することによって応答に機密性を適用します。
2.c.2.b.4.b - The GLA can also optionally apply another SignedData over the EnvelopedData (see Section 3.2.1.2).
2.c.2.b.4.b - GLAはまた、必要に応じてEnvelopedDataの上に別のSignedData（セクション3.2.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署名（S）を検証します。追加のSignedData及び/又はEnvelopedDataの場合転送応答（セクション3.2.1.2または3.2.2を参照）、GLOは外側の署名を検証及び/又は最も内側のSignedDataの署名を検証する前に転送された応答を復号化するカプセル化。
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属性値がローカルで受け入れられた時間ウィンドウ内にない場合は、GLAはcMCStatus.failedとotherInfo.failInfo.badTimeと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 - そうでなければ、署名処理が継続する場合と署名が検証場合、応答に署名するために使用される証明書の名前の1つは、GLの名前と一致していることをGLOチェック。
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は、応答して提供された情報を使用して、GLをリキーを再試行することができます。
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:
GLAは自動的glKeyメッセージを発行しますGL GLAを再入力を担当している場合（第5節参照）。また、GLAは、成功した再入力が発生したGLに示すためにcMCStatusInfoExtを生成します。次のようにGLA開始リキーのためのプロセスは、次のとおりです。
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の成功を生成し（図7のA）signingTime属性を含んでいます。
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).
1.A - GLAは、必要に応じてEnvelopedDataでSignedData.PKIData（セクション3.2.1.2を参照）をカプセル化することによって要求に秘密性を適用することができます。
1.b - The GLA can also optionally apply another SignedData over the EnvelopedData (see Section 3.2.1.2).
1.B - GLAはまた、必要に応じてEnvelopedDataの上に別のSignedData（セクション3.2.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署名（S）を検証します。追加のSignedData及び/又はEnvelopedDataのは、転送応答をカプセル化している場合（セクション3.2.1.2または3.2.2を参照）、GLOは外側の署名を検証及び/又は前最も内側のSignedDataの署名を検証する外側の層を解読しなければなりません。
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属性値がローカルで受け入れられた時間ウィンドウ内にない場合、GLOはcMCStatus.failedとotherInfo.failInfo.badTimeと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 - そうでなければ、署名処理が継続する場合と署名が検証場合、応答に署名するために使用される証明書の名前の1つは、GLの名前と一致していることをGLOチェック。
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.
2.B.2 - GLの名前が証明書に存在する名前と一致しないとの応答がcMCStatusInfoExt.cMCStatus.successあるそうであれば、GLOはGLAが正常にGLをリキーたことを知ります。
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のの管理は、1 GLOのために困難になることができます。作業負荷を分散サポートするために、グラスのサポート持つGLsのは、複数のGLOsによって管理されます。 glAddOwnerとglRemoveOwnerメッセージが登録さGLOsの追加と削除をサポートするように設計されています。図8は、glAddOwnerとglRemoveOwnerメッセージし、得られた応答メッセージを送信するためのプロトコル相互作用を示します。エラーメッセージが表示されていないことに注意してください。さらに、オプションのtransactionId、senderNonce、およびrecipientNonce CMCコントロール属性の動作は、これらの手順で対処されていません。
+-----+ 1 2 +-----+
| GLA | <-------> | GLO |
+-----+ +-----+
Figure 8 - GLO Add and Delete Owners
図8 - 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はglNameにおけるGL名、それぞれglOwnerNameとglOwnerAddress、でGLOの名前と住所を含みます。 GLOも、この要求に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).
1.A - GLOは、必要に応じてEnvelopedDataでSignedData.PKIData（セクション3.2.1.2を参照）をカプセル化することによって要求に秘密性を適用することができます。
1.b - The GLO can also optionally apply another SignedData over the EnvelopedData (see Section 3.2.1.2).
1.B - GLOはまた、必要に応じてEnvelopedDataの上に別のSignedData（セクション3.2.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署名（S）を検証します。追加のSignedDataおよび/またはEnvelopedDataの要求をカプセル化する場合、GLAは外側の署名を検証及び/又は最も内側のSignedDataの署名を検証する前に、外側の層を解読し（セクション3.2.1.2または3.2.2を参照）。
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属性値がローカルで受け入れられた時間ウィンドウ内にない場合は、GLAはcMCStatus.failedとotherInfo.failInfo.badTimeと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 checking that the glName matches a glName stored on the GLA.
2.C - エルス署名は検証場合、GLAは、GLがglNameがGLAに格納されているglNameと一致することを確認することでサポートされているを確認します。
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又はglDeleteOwner要求に署名するために使用されることを確認することによりglAddOwner又はglRemoveOwner要求に署名したことを確実にします登録された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と（図4の2）signingTime属性を返します。 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).
2.c.2.b.1 - GLAが要求がEnvelopedDataの（セクション3.2.1.2を参照）内にカプセル化された場合EnvelopedDataでSignedData.PKIResponseをカプセル化することによって応答に機密性を適用します。
2.c.2.b.2 - The GLA can also optionally apply another SignedData over the EnvelopedData (see Section 3.2.1.2).
2.c.2.b.2 - GLAはまた、必要に応じてEnvelopedDataの上に別のSignedDataを適用することができる（セクション3.2.1.2を参照）。
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の署名（S）を検証します。追加のSignedData及び/又はEnvelopedDataの場合の応答を（セクション3.2.1.2または3.2.2を参照）、GLOは外側の署名を検証及び/又は最も内側のSignedDataの署名を検証する前に、外側の層を解読カプセル化します。
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属性値がローカルで受け入れられた時間ウィンドウ内にない場合、GLOはcMCStatus.failedとotherInfo.failInfo.badTimeと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 - そうでなければ、署名処理が継続する場合と署名が検証場合、応答に署名するために使用される証明書の名前の1つは、GLの名前と一致していることをGLOチェック。
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 - 署名が検証し、応答が何らかの理由でcMCStatusInfoExt.cMCStatus.failedた場合さもなければ、GLOは、応答して提供された情報を使用してGLOを追加または削除するために再試行することができます。
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キー妥協のためのプロトコル相互作用を示します。エラーメッセージが表示されていないことに注意してください。さらに、オプションのtransactionId、senderNonce、およびrecipientNonce CMCコントロール属性の動作は、これらの手順で対処されていません。
+-----+ 2{1} 4 +----------+
| GLO | <----------+ +-------> | Member 1 |
+-----+ 5,3{1} | | +----------+
+-----+ <----------+ | 4 +----------+
| GLA | 1 +-------> | ... |
+-----+ <---------------+ +----------+
| 4 +----------+
+-------> | Member n |
+----------+
Figure 9 - GL Key Compromise
図9 - GL鍵の危殆
The process for GL member initiated glkCompromise messages is as follows:
次のようにglkCompromiseメッセージを開始したGLメンバーのためのプロセスは、次のとおりです。
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.
1.A - GLメンバーは、必要に応じてEnvelopedDataでSignedData.PKIData（セクション3.2.1.2を参照）をカプセル化することによって要求に秘密性を適用することができます。 glkCompromiseが損なわ共有KEKで生成EnvelopedDataで含めることができます。
1.b - The GL member can also optionally apply another SignedData over the EnvelopedData (see Section 3.2.1.2).
1.B - GL部材は、任意EnvelopedDataの上に別のSignedData（セクション3.2.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メンバー署名（S）を検証します。追加のSignedDataおよび/またはEnvelopedDataの要求をカプセル化する場合、GLAは外側の署名を検証及び/又は最も内側のSignedDataの署名を検証する前に、外側の層を解読し（セクション3.2.1.2または3.2.2を参照）。
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属性値がローカルで受け入れられた時間ウィンドウ内にない場合は、GLAはcMCStatus.failedとotherInfo.failInfo.badTimeと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 checking that the indicated GL name matches a glName stored on the GLA.
2.C - エルス署名は検証場合、GLAは、GLが示さGL名はGLAに格納されているglNameと一致することを確認することでサポートされているを確認します。
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のために、要求に署名するために使用される証明書の名前の1は、登録されたGLOと一致する必要があります。メンバーのために、glMember.glMemberNameの名前が要求に署名するために使用される証明書の名前のいずれかに一致する必要があります。
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が要求に署名した場合（図9の4）GLをリキーするセクション5に記載されているように、GLAは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（図9における2 {1}）GLOに（セクション3.2.3参照）glkCompromiseメッセージを転送します。要求が転送されGLOに複数のGLOが、存在する場合は、このドキュメントの範囲を超えています。 GLOによる更なる処理は、セクション4.7.2に記載されています。
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 - （図9に5）GLAへSignedData.PKIData.controlSequence.glkCompromise要求を送信することによってglkCompromiseメッセージ自体を生成します。 GLOはいるGeneralNameでGLの名前が含まれています。 GLOも、この要求にsigningTime属性を含まなければなりません。
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.
1.A.1 - GLOは、必要に応じて（セクション3.2.1.2参照）EnvelopedDataでSignedData.PKIDataをカプセル化することによって要求に秘密性を適用することができます。 glkCompromiseが損なわ共有KEKで生成EnvelopedDataで含めることができます。
1.a.2 - The GLO can also optionally apply another SignedData over the EnvelopedData (see Section 3.2.1.2).
1.A.2 - GLOはまた、必要に応じてEnvelopedDataの上に別のSignedDataを適用することができる（セクション3.2.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を参照）、GLOは外側の署名を検証及び/又は最も内側のSignedDataの署名を検証する前に、外側の層を解読カプセル化します。
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は、値がローカルに受け入れられた時間ウィンドウ内にない属性の場合は、GLOはcMCStatus.failedとotherInfo.failInfo.badTimeと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バックGLA（図9の3 {1}）にglkCompromiseメッセージを転送するか否かを判定する。 GLAによる更なる処理は、セクション4.7.1の2です。 GLOはまたglkCompromiseメッセージが正常に受信されたことを示すcMCStatusInfoExt.cMCtatus.successと将来のメンバーに応答を返すことができます。
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の再入力が不要です。 GLメンバーは、共有KEK（S）はそれらに再分配されることを要求するglkRefreshメッセージを使用します。図10は、GLキー更新のためのプロトコルの相互作用を示しています。エラーメッセージが表示されていないことに注意してください。さらに、オプションのtransactionId、senderNonce、およびrecipientNonce CMCコントロール属性の動作は、これらの手順で対処されていません。
+-----+ 1 2 +----------+
| GLA | <-----------> | Member |
+-----+ +----------+
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).
1.A - GLメンバーは、必要に応じてEnvelopedDataでSignedData.PKIData（セクション3.2.1.2を参照）をカプセル化することによって要求に秘密性を適用することができます。
1.b - The GL member can also optionally apply another SignedData over the EnvelopedData (see Section 3.2.1.2).
1.B - GL部材は、任意EnvelopedDataの上に別のSignedData（セクション3.2.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メンバー署名（S）を検証します。追加のSignedData及び/又はEnvelopedDataの（セクション3.2.1.2または3.2.2を参照）要求をカプセル化する場合、GLAは外側の署名を検証及び/又は前最も内側のSignedDataの署名を検証する外側の層を解読します。
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属性値がローカルで受け入れられた時間ウィンドウ内にない場合は、GLAはcMCStatus.failedとotherInfo.failInfo.badTimeと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 checking that the GLGeneralName matches a glName stored on the GLA.
2.C - エルス署名は検証場合、GLAは、GLがGLGeneralNameがGLAに格納されているglNameと一致することを確認することでサポートされているを確認します。
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はcMCStatus.failedとinvalidGLNameの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とnoSpamのotherInfo.extendedFailInfo.SKDFailInfo値とcMCStatusInfoExtを示す応答を返します。さらに、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に存在するそれ以外の場合は、セクション5で説明したように、GLAはcMCStatusInfoExt.cMCStatus.success、signingTime属性、及び（図10の2）glKeyメッセージを返します。
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.
それはGLAがサポートするアルゴリズム（複数可）または他のいくつかの特性を知らないので、GLOはトラブルGLのセットアップをしているときに、特定の時間があるでしょう。また、将来のGLメンバーやGLメンバーがGLA（これらの要求を文書で定義されていない）について何かを知っている必要が倍が存在する場合があります。 glaQueryRequestとglaQueryResponseメッセージは、この情報を決定するサポートするために定義されています。図11は、glaQueryRequestとglaQueryResponseためのプロトコル相互作用を示します。エラーメッセージが表示されていないことに注意してください。さらに、オプションのtransactionId、senderNonce、およびrecipientNonce CMCコントロール属性の動作は、これらの手順で対処されていません。
+-----+ 1 2 +------------------+
| GLA | <-------> | GLO or GL Member |
+-----+ +------------------+
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).
1.A - GLO、GLメンバー、または将来のGLメンバーは、必要に応じて（セクション3.2.1.2参照）EnvelopedDataでSignedData.PKIDataをカプセル化することによって要求に秘密性を適用することができます。
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).
1.B - GLO、GLメンバー、または将来のGLメンバーは、任意EnvelopedDataの上に別のSignedDataを適用することができる（セクション3.2.1.2を参照）。
2 - Upon receipt of the glaQueryRequest, the GLA determines if it accepts glaQueryRequest messages.
2 - それはglaQueryRequestメッセージを受け入れる場合glaQueryRequestを受け取り次第、GLAを判定する。
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とstatusString内の他の情報を示すcMCStatusInfoExt応答を返します。
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メンバー署名（S）を検証します。追加のSignedDataおよび/またはEnvelopedDataの要求をカプセル化する場合、GLAは外側の署名を検証及び/又は最も内側のSignedDataの署名を検証する前に、外側の層を解読し（セクション3.2.1.2または3.2.2を参照）。
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は、値がローカルに受け入れられた時間ウィンドウ内にない属性の場合は、GLAはcMCStatus.failedとotherInfo.failInfo.badTimeとsigningTime属性を示す応答を返してもよいです。
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は、正しい応答を有する（図11の2）glaQueryResponseを返します。さらに、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).
2.b.3.a - GLAが要求がEnvelopedDataの（セクション3.2.1.2を参照）内にカプセル化された場合EnvelopedDataでSignedData.PKIResponseをカプセル化することによって応答に機密性を適用します。
2.b.3.b - The GLA can also optionally apply another SignedData over the EnvelopedData (see Section 3.2.1.2).
2.b.3.b - GLAはまた、必要に応じてEnvelopedDataの上に別のSignedData（セクション3.2.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.
3 - glaQueryResponseを受信すると、GLO、GLメンバー、または将来のGLメンバーはsigningTimeをチェックして、GLA署名（S）を検証します。追加のSignedData及び/又はEnvelopedDataの（セクション3.2.1.2または3.2.2を参照）応答をカプセル化した場合、GLO、GLメンバー、または将来のGL部材は、外側署名を検証および/または前の署名を検証する外側の層を解読します最も内側のSignedData。
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メンバー、または将来のGLメンバーがcMCStatus.failedとotherInfo.failInfo.badTimeと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の名前と一致しています。
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.
3.c.2 - GLの名称が証明書内に存在する名前と一致し、応答がglaQueryResponse、次いでGLO、GLメンバー、またはその中に含まれる情報を使用することができる将来のGLメンバーであった場合はそうで。
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はGLAがglKeyメッセージを生成、またはGLAがglAddMemberを処理するときGLメンバーの証明書の有効期限が切れ、または無効であるした場合、インスタンスが存在することができるglAddMember要求を生成します。これらの例では、GLOまたはGLAはGLメンバーがGLメンバーのglKeyメッセージを生成することができないことからGLAを避けるために新しい証明書を提供することを要求してもよいです。また、GLメンバーは、その証明書の有効期限が近づいているか、失効していることを知っている、とGLメンバーがGLのキー更新を受け取ることができません回があるかもしれません。オプションのtransactionId、senderNonce、およびrecipientNonce CMCコントロール属性の挙動は、これらの手順で対処されていません。
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はGL部材にSignedData.PKIData.controlSequence.glProvideCert要求を送信します。 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.
1.A - GLOまたはGLAは、必要に応じて（セクション3.2.1.2参照）EnvelopedDataでSignedData.PKIDataをカプセル化することによって要求に秘密性を適用することができます。 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).
1.B - GLOまたはGLAはまた、必要に応じてEnvelopedDataの上に別のSignedData（セクション3.2.1.2を参照）を適用することができます。
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.
2 - glProvideCertメッセージを受信すると、GLメンバーはsigningTimeをチェックして、GLOまたはGLA署名（S）を検証します。追加のSignedDataおよび/またはEnvelopedDataの応答をカプセル化する場合、GL部材は外側の署名を検証及び/又は最も内側のSignedDataの署名を検証する前に、外側の層を解読し（セクション3.2.1.2または3.2.2を参照）。
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属性値がローカルで受け入れられた時間ウィンドウ内にない場合、GLメンバーはcMCStatus.failedとotherInfo.failInfo.badTimeと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.
2.C.1 - GLメンバーは、必要に応じて（セクション3.2.1.2参照）EnvelopedDataでSignedData.PKIResponseをカプセル化することによって要求に秘密性を適用することができます。 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).
2.c.2 - GL部材はまた、任意EnvelopedDataの上に別のSignedDataを適用することができる（セクション3.2.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.
3 - glUpdateCertメッセージを受信すると、GLOまたはGLAはsigningTimeをチェックして、GLメンバー署名（S）を検証します。追加のSignedDataおよび/またはEnvelopedDataの応答をカプセル化する場合、GL部材は外側の署名を検証及び/又は最も内側のSignedDataの署名を検証する前に、外側の層を解読し（セクション3.2.1.2または3.2.2を参照）。
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属性値がローカルで受け入れられた時間ウィンドウ内にない場合は、GLOまたはGLAはcMCStatus.failedとotherInfo.failInfo.badTimeとsigningTime属性を示す応答を返してもよいです。
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.
3.c.1 - メンバーの暗号化証明書が確認できない場合は、GLOは別glProvideCert要求またはcMCStatus.failedとcMCStatusInfoExtと理由cMCStatus.statusString内のいずれかを返します。 glProvideCertはGLメンバーが有効な証明書を持っていない場合、1を返すことができることはありませんので、特定の回数があるだけ返されるべきです。さらに、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.
3.c.2 - メンバーの暗号化証明書を検証できない場合はそうでは、GLAはGLOにcMCStatus.statusStringでGLメンバーやcMCStatus.failedとcMCStatusInfoExtと理由に別のglProvideCert要求を返します。 GLメンバーが有効な証明書を持っていない場合、1を返すことができることはありませんので、glProvideCertは時代の唯一の特定の数を返す必要があります。さらに、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メッセージでそれを使用する場合。
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 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.
1 - GLメンバーはglMember.certificates.pKCで、glMember.glMemberNameでメンバーの名前、メンバーの暗号化証明書をglNameにGL名を含んSigned.PKIData.controlSequence.glUpdateCertを送信します。 GLメンバーは、メンバーのglMember.certificates.aCで暗号化証明書、および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.
1.A - GLメンバーは、必要に応じてEnvelopedDataでSignedData.PKIData（セクション3.2.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).
1.B - GL部材は、任意EnvelopedDataの上に別のSignedData（セクション3.2.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メンバー署名（S）を検証します。追加のSignedDataおよび/またはEnvelopedDataの応答をカプセル化する場合、GLAは外側の署名を検証及び/又は最も内側のSignedDataの署名を検証する前に、外側の層を解読し（セクション3.2.1.2または3.2.2を参照）。
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属性値がローカルで受け入れられた時間ウィンドウ内にない場合は、GLAはcMCStatus.failedとotherInfo.failInfo.badTimeと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は、GLメンバーやcMCStatus.failedとcMCStatusInfoExtとGLOにcMCStatus.statusStringで理由に別のglProvideCert要求を返します。 glProvideCertは無期限に返されるべきではありません。 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は、GLメンバーに関連付けられ、その後glAddMember要求とglKeyメッセージでそれを使用します。 GLAはまた、GLOにglUpdateCertメッセージを転送します。
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メッセージを使用して、（閉鎖および管理GLsのため）glAddMember、glDeleteMember、glRekey、glkCompromise、又はglkRefresh要求を受信し、それぞれの要求に対するcMCStatusInfoExt応答を返した後KEK（単数または複数）を共有しました。図12は、glKeyメッセージを送信するためのプロトコルの相互作用を示しています。管理メッセージのために定義された手順とは異なり、このセクションで定義された手順は、発信用グラスによって、受信にGLメンバーによって実施されなければなりません。エラーメッセージが表示されていないことに注意してください。さらに、オプションのtransactionId、senderNonce、およびrecipientNonce CMCコントロール属性の動作は、これらの手順で対処されていません。
1 +----------+
+-------> | Member 1 |
| +----------+
+-----+ | 1 +----------+
| GLA | ----+-------> | ... |
+-----+ | +----------+
| 1 +----------+
+-------> | Member 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.
GLはGLKeyAttributes.recipientsNotMutuallyAwareで設定した場合にTRUEに設定され、他のGLメンバーに関する情報を漏洩しないように、別個glKeyメッセージは、各GLメンバーに送信されなければなりません。
When the glKey message is generated as a result of a:
glKeyメッセージは、結果として生成された場合：
- glAddMember request,
- glAddMember要求、
- glkComrpomise indication,
- glkComrpomise表示、
- glkRefresh request,
- glkRefresh要求、
- glDeleteMember request with the GL's glAdministration set to managed or closed, and
- GLのglAdministrationとglDeleteMember要求は、管理対象に設定するか、閉じられ、
- glRekey request with generationCounter set to zero (0).
- generationCounterとglRekey要求がゼロ（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は唯一の目的の受信者が共有KEKを受け取ることを保証するために、（[CMS]のセクション12.3.1を参照）glKey.glkWrapped.RecipientInfoでの選択をがkari（[CMS]のセクション12.3.2を参照）またはktriのいずれかを使用しなければなりません。 GLAはktri選択をサポートしなければなりません。
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）がゼロより大きいgenerationCounterとglRekey要求の結果として生成される、またはGLAがキー更新を制御する際に、GLAは（[CMS]のセクション12.3.3を参照）がkari、ktri、又はkekriを使用される場合がglKey.glkWrapped.RecipientInfoにのみ意図された受信者が共有KEKを受け取ることを確実にします。 GLAはRecipientInfo.ktriの選択をサポートしなければなりません。
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はglName、glIdentifier、glkWrapped、glkAlgorithm、glkNotBefore、及びglkNotAfterなどによって各部材にSignedData.PKIData.controlSequence.glKeyを送らなければなりません。 GLメンバーのPKCの期限が切れたり、そうでない場合は無効であるたため、GLAはGLメンバーのglKeyメッセージを生成することができない場合は、GLAは、（4.10節を参照）新しい証明書を提供することを要求GLメンバーにglUpdateCertを送信することができます。 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).
1.A - GLAは、必要に応じて別のEnvelopedDataでSignedData.PKIData（セクション3.2.1.2を参照）をカプセル化することによってメッセージに別の機密性層を適用することができます。
1.b - The GLA MAY also optionally apply another SignedData over the EnvelopedData.SignedData.PKIData (see Section 3.2.1.2).
1.B - GLAは、任意EnvelopedData.SignedData.PKIData（セクション3.2.1.2を参照）を介して別のSignedDataを適用することができます。
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.
2 - glKeyメッセージを受信すると、GLメンバーはsigningTimeをチェックしなければならなくて、最も内側のSignedData.PKIData上の署名を検証します。追加のSignedDataおよび/またはEnvelopedDataのメッセージをカプセル化する場合、GL部材は外側の署名を検証及び/又は前SignedData.PKIData.controlSequenceの署名を検証する外層を解読しなければならない（セクション3.2.1.2または3.2.2を参照） .glKey。
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属性値がローカルで受け入れられた時間ウィンドウ内にない場合は、GLAはcMCStatus.failedとotherInfo.failInfo.badTimeと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属性は応答に含まれています。
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 - 署名が検証する場合にそうでは、GLメンバーは[CMS]に記載のrecipientInfosを処理します。開封後は、GLメンバーは安全な場所に共有KEKを保存する必要があります。保存された場合、glName、glIdentifier、共有KEKは、関連されるべきです。また、GLメンバーはKEKが受信されたGLAを伝えるためにcMCStatus.successを示すcMCStatusInfoExtを返さなければなりません。
This section lists the algorithms that MUST be implemented. Additional algorithms that SHOULD be implemented are also included. Further algorithms MAY also be implemented.
このセクションでは、実装しなければならないアルゴリズムを示します。実装されるべきさらなるアルゴリズムも含まれています。さらに、アルゴリズムが実装されてもよいです。
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.
実装はランダムにコンテンツ暗号化キー、メッセージ認証キー、初期化ベクトル（IV）、およびパディングを生成しなければなりません。また、公開鍵/秘密鍵ペアの生成は、乱数に依存しています。暗号鍵を生成するために不十分な疑似乱数発生器（のPRNG）の使用は、ほとんどまたは全くセキュリティをもたらすことができます。攻撃者はそれをはるかに簡単に全体のキースペースを検索結果として起こる小さい可能性はなく、ブルートフォースを探し、キーを生成PRNG環境を再現するかもしれません。品質の乱数の生成が困難です。 RFC 4086には、[RANDOM]はこの領域で重要な指導を提供し、FIPSパブ186 [FIPS]の付録3つの品質のPRNGの技術を提供します。
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].
[CMSAES] [CMSALG]で指定されるようglkWrappedに含まれるアルゴリズムのオブジェクト識別子です。
The shared KEK distributed and indicated in glkAlgorithm MUST support the symmetric key-encryption algorithms as specified in [CMSALG] and [CMSAES].
共有KEKは、分散および[CMSAES] [CMSALG]で指定されたように、対称鍵暗号化アルゴリズムをサポートしなければならないglkAlgorithmに示します。
SMTP [SMTP] MUST be supported. Other transport mechanisms MAY also be supported.
SMTP [SMTP]はサポートしなければなりません。他のトランスポートメカニズムもサポートされるかもしれません。
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がリキーされていない場合、メンバーはまだグループ鍵を所有して取得することができる任意のメッセージを解読し続けることができるようになります。
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.
KEKを保存するメンバーは、メンバーが、その後のキー更新が同じエンティティから発信されていることを確認できるように、キーを分散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個のキーは、年間の有効期間とそれぞれ生成されます。攻撃者は、最終的なキーを攻撃するには、少なくとも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.
二つ以上の当事者がKEKを共有しており、共有KEKはこれらの当事者に機密分布する第二KEKを暗号化するために使用されているものとします。第KEKが第三KEKを暗号化するために使用されるかもしれない、第三のKEKはそうで第四のKEKを暗号化するために使用されるかもしれません。そのような鎖内のKEKのいずれかが損なわれている場合、チェーン内の後続のKEKのすべても損なわ考慮しなければなりません。
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.
攻撃者は、共有KEKの1人のメンバーのコピーを攻撃または共有KEKの複数のメンバーのコピーを攻撃することで、グループの共有KEKを攻撃することができます。攻撃者のために、共有KEKや攻撃複数のグループのメンバーのコピーを保護する最も弱いセキュリティとグループメンバーを攻撃するためにどちらかの方が簡単かもしれません。
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.
攻撃（S）中に収集された情報の集約は、グループの共有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の間の許容される差を決定します。実装は、彼らが将来的に作成された指示siginingTime属性を持つメッセージを処理する必要があります。
Thanks to Russ Housley and Jim Schaad for providing much of the background and review required to write this document.
この文書を書くために必要な背景とレビューの多くを提供するためのラスHousleyとジムSchaadのおかげ。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[CMS] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3852, July 2004.
[CMS] Housley氏、R.、 "暗号メッセージ構文（CMS）"、RFC 3852、2004年7月。
[CMC] Schaad, J. and M. Myers, "Certificate Management over CMS (CMC)", RFC 5272, June 2008.
[CMC] Schaad、J.とM.マイヤーズ、 "CMSオーバー証明書の管理（CMC）"、RFC 5272、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.
[PROFILE]クーパー、D.、Santesson、S.、ファレル、S.、Boeyen、S.、Housley氏、R.、およびW.ポーク、「インターネットX.509公開鍵暗号基盤証明書と証明書失効リスト（CRL）のプロフィール」、RFC 5280、2008年5月。
[ACPROF] Farrell, S. and R. Housley, "An Internet Attribute Certificate Profile for Authorization", RFC 3281, April 2002.
[ACPROF]ファレル、S.とR. Housley氏、 "認可のためのインターネット属性証明書プロフィール"、RFC 3281、2002年4月。
[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メッセージ仕様"、RFC 3851、2004年7月。
[ESS] Hoffman, P., Ed., "Enhanced Security Services for S/MIME", RFC 2634, June 1999.
[ESS]ホフマン、P.、エド。、 "セキュリティ強化サービスS / MIMEのために"、RFC 2634、1999年6月。
[CMSALG] Housley, R., "Cryptographic Message Syntax (CMS) Algorithms", RFC 3370, August 2002.
[CMSALG] Housley氏、R.、 "暗号メッセージ構文（CMS）アルゴリズム"、RFC 3370、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.、 "暗号メッセージ構文内のAdvanced Encryption Standard（AES）暗号化アルゴリズム（CMS）の使用"、RFC 3565、2003年7月。
[SMTP] Klensin, J., Ed., "Simple Mail Transfer Protocol", RFC 2821, April 2001.
[SMTP] Klensin、J.、エド。、 "簡易メール転送プロトコル"、RFC 2821、2001年4月。
[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、2004年7月、RFC 3855、 "セキュア/多目的インターネットメール拡張（S / MIME）を輸送はX.400内のオブジェクト"。
[RANDOM] Eastlake, D., 3rd, Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
[ランダム]イーストレーク、D.、3、シラー、J.、およびS.クロッカー、 "セキュリティのためのランダム要件"、BCP 106、RFC 4086、2005年6月。
[FIPS] National Institute of Standards and Technology, FIPS Pub 186-2: Digital Signature Standard, January 2000.
[FIPS]米国国立標準技術研究所、FIPSパブ186-2：デジタル署名標準、2000年1月。
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) }
SMIMESymmetricKeyDistribution {ISO（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.
- すべてのエクスポート - - このモジュールで定義されたタイプと値が使用のためにエクスポートされる - 他の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 - 暗黙[PROFILE]のGeneralName PKIX1Implicit88 FROM {ISO（1）同定された組織（3）DOD（6）インターネット（1）セキュリティ（5）メカニズム（5）PKIX（7）ID-MOD（0） ID-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 - 明示[PROFILE]のAlgorithmIdentifier、証明PKIX1Explicit88 FROM {ISO（1）同定された組織（3）DOD（6）インターネット（1）セキュリティ（5）メカニズム（5）PKIX（7）ID-MOD（ 0）ID-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) }
- 暗号メッセージ構文[CMS]のrecipientInfos、KEKIdentifier、証明書群CryptographicMessageSyntax2004 FROM {ISO（1）部材本体（2）米国（840）RSADSI（113549）PKCS（1）PKCS-9（9）SMIME（16）モジュール（ 0）CMS-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] CMSAesRsaesOaepからID-AES128ラップ{ISO（1）部材本体（2）米国（840）RSADSI（113549）PKCS（1）PKCS-9（9）SMIMEとのAdvanced Encryption Standard（AES） （16）モジュール（0）ID-MOD-CMS-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) };
- PKIXAttributeCertificate {ISO（1）同定された組織（3）DOD（6）インターネット（1）セキュリティ（5）メカニズム（5）PKIX（7）ID-MOD（0）ID-から属性証明書プロファイル[ACPROF] AttributeCertificate MOD-属性-CERT（12）}。
-- 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) }
-- This defines the GL Use KEK control attribute.
- これはGL使用KEK制御属性を定義します。
id-skd-glUseKEK OBJECT IDENTIFIER ::= { id-skd 1 }
GLUseKEK ::= SEQUENCE {
glInfo GLInfo,
glOwnerInfo SEQUENCE SIZE (1..MAX) OF GLOwnerInfo,
glAdministration GLAdministration DEFAULT 1,
glKeyAttributes GLKeyAttributes OPTIONAL }
GLInfo ::= SEQUENCE {
glName GeneralName,
glAddress GeneralName }
GLOwnerInfo ::= SEQUENCE {
glOwnerName GeneralName,
glOwnerAddress GeneralName,
certificates Certificates OPTIONAL }
GLAdministration ::= INTEGER {
unmanaged (0),
managed (1),
closed (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 } }
-- This defines the Delete GL control attribute. -- It has the simple type GeneralName.
- これは、削除GL制御属性を定義します。 - それは、単純型のGeneralNameを持っています。
id-skd-glDelete OBJECT IDENTIFIER ::= { id-skd 2 }
DeleteGL ::= GeneralName
-- This defines the Add GL Member control attribute.
- これは、追加GLメンバーコントロール属性を定義します。
id-skd-glAddMember OBJECT IDENTIFIER ::= { id-skd 3 }
GLAddMember ::= SEQUENCE {
glName GeneralName,
glMember GLMember }
GLMember ::= SEQUENCE {
glMemberName GeneralName,
glMemberAddress GeneralName OPTIONAL,
certificates 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]
-- This defines the Delete GL Member control attribute.
- これは、削除GLメンバーコントロール属性を定義します。
id-skd-glDeleteMember OBJECT IDENTIFIER ::= { id-skd 4 }
GLDeleteMember ::= SEQUENCE {
glName GeneralName,
glMemberToDelete GeneralName }
-- This defines the Delete GL Member control attribute.
- これは、削除GLメンバーコントロール属性を定義します。
id-skd-glRekey OBJECT IDENTIFIER ::= { id-skd 5 }
GLRekey ::= SEQUENCE {
glName GeneralName,
glAdministration GLAdministration OPTIONAL,
glNewKeyAttributes GLNewKeyAttributes OPTIONAL,
glRekeyAllGLKeys BOOLEAN OPTIONAL }
GLNewKeyAttributes ::= SEQUENCE {
rekeyControlledByGLO [0] BOOLEAN OPTIONAL,
recipientsNotMutuallyAware [1] BOOLEAN OPTIONAL,
duration [2] INTEGER OPTIONAL,
generationCounter [3] INTEGER OPTIONAL,
requestedAlgorithm [4] AlgorithmIdentifier OPTIONAL }
-- This defines the Add and Delete GL Owner control attributes.
- これは、追加と削除GL所有者の制御属性を定義します。
id-skd-glAddOwner OBJECT IDENTIFIER ::= { id-skd 6 }
id-skd-glRemoveOwner OBJECT IDENTIFIER ::= { id-skd 7 }
GLOwnerAdministration ::= SEQUENCE {
glName GeneralName,
glOwnerInfo GLOwnerInfo }
-- This defines the GL Key Compromise control attribute. -- It has the simple type GeneralName.
- これはGL鍵の危殆制御属性を定義します。 - それは、単純型のGeneralNameを持っています。
id-skd-glKeyCompromise OBJECT IDENTIFIER ::= { id-skd 8 }
GLKCompromise ::= GeneralName
-- This defines the GL Key Refresh control attribute.
- これはGLキーリフレッシュ制御属性を定義します。
id-skd-glkRefresh OBJECT IDENTIFIER ::= { id-skd 9 }
GLKRefresh ::= SEQUENCE {
glName GeneralName,
dates SEQUENCE SIZE (1..MAX) OF Date }
Date ::= SEQUENCE {
start GeneralizedTime,
end GeneralizedTime OPTIONAL }
-- This defines the GLA Query Request control attribute.
- これは、GLAクエリ要求制御属性を定義します。
id-skd-glaQueryRequest OBJECT IDENTIFIER ::= { id-skd 11 }
GLAQueryRequest ::= SEQUENCE {
glaRequestType OBJECT IDENTIFIER,
glaRequestValue ANY DEFINED BY glaRequestType }
-- This defines the GLA Query Response control attribute.
- これは、GLAクエリ応答制御属性を定義します。
id-skd-glaQueryResponse OBJECT IDENTIFIER ::= { id-skd 12 }
GLAQueryResponse ::= SEQUENCE {
glaResponseType OBJECT IDENTIFIER,
glaResponseValue ANY DEFINED BY glaResponseType }
-- This defines the GLA Request/Response (glaRR) arc for -- glaRequestType/glaResponseType.
- GLA RequestType / GLA ResponseType - これがためGLA要求/応答（glaRR）円弧を定義します。
id-cmc-glaRR OBJECT IDENTIFIER ::= { iso(1)
identified-organization(3) dod(6) internet(1) security(5)
mechanisms(5) pkix(7) cmc(7) glaRR(99) }
-- This defines the Algorithm Request.
- これは、アルゴリズムの要求を定義します。
id-cmc-gla-skdAlgRequest OBJECT IDENTIFIER ::= { id-cmc-glaRR 1 }
SKDAlgRequest ::= NULL
-- This defines the Algorithm Response.
- これは、アルゴリズム応答を定義します。
id-cmc-gla-skdAlgResponse OBJECT IDENTIFIER ::= { id-cmc-glaRR 2 }
-- 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.
- MsgSpec [MSG]で定義されるようにSMIMEケーパビリティ属性 - algorithmSupported要求に対する応答であることに留意されたいです。 - GLAに証明書 - これは、更新を要求するために、制御属性を定義します。
id-skd-glProvideCert OBJECT IDENTIFIER ::= { id-skd 13 }
GLManageCert ::= SEQUENCE {
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 }
-- This defines the control attribute to distribute the GL shared -- KEK.
- これは、共有GLを分配するための制御属性を定義する - KEKを。
id-skd-glKey OBJECT IDENTIFIER ::= { id-skd 15 }
GLKey ::= SEQUENCE {
glName GeneralName,
glIdentifier KEKIdentifier, -- See [CMS]
glkWrapped RecipientInfos, -- See [CMS]
glkAlgorithm AlgorithmIdentifier,
glkNotBefore GeneralizedTime,
glkNotAfter GeneralizedTime }
-- 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) }
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) }
END -- SMIMESymmetricKeyDistribution
END - SMIME対称鍵配布
Author's Address
著者のアドレス
Sean Turner IECA, Inc. 3057 Nutley Street, Suite 106 Fairfax, VA 22031 USA
ショーン・ターナーIECA株式会社3057ナトリーストリート、スイート106バージニア州フェアファクス22031 USA
EMail: turners@ieca.com
メールアドレス：turners@ieca.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（C）IETFトラスト（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.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
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は、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
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リポジトリから。
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に情報を記述してください。