[要約] RFC 5275は、CMS（Cryptographic Message Syntax）の対称鍵管理と配布に関する標準仕様です。その目的は、セキュアな鍵の共有と管理を実現することです。
Network Working Group S. Turner
Request for Comments: 5275 IECA
Category: Standards Track June 2008
CMS Symmetric Key Management and Distribution
CMS対称キー管理と分布
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）プロトコルとCMS（CMC）プロトコルを介した証明書管理を暗号化メッセージ（CMS）プロトコル（CMC）プロトコルを使用して、対称キーを管理します。その後、グループのメンバーは、後でこの分散共有キーを使用して、対称キーを持つ他のCMS暗号化されたオブジェクトを復号化できます。このメカニズムは、Secure/Multipurpose Internet Mail Extensions（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つの方法があります。公開キー証明書（PKC）を使用して非対称アルゴリズムを使用するか、対称キーを持つ対称アルゴリズムです。
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）特定のレシピエント（ktri ReciontientInfo選択）または（b）のCEKを暗号化するか、特定のレシピエントが独立して生成できるように十分なパラメーターを送信するか、レシピエントごとの情報を生成します。同じKek（Kari ReciontientInfo選択）。グループが大きい場合、レシピエントごとの情報の処理にはかなりの時間がかかる場合がありますが、各受信者のPKCを収集および検証するのに必要な時間は言うまでもありません。各受信者は、そのレシピエントごとの情報を識別し、PKCの公開鍵に関連付けられた秘密鍵を使用してCEKを復号化し、暗号化されたコンテンツにアクセスできます。
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を使用する代わりに、オリジネーターは以前に分散した秘密のキー暗号化キー（KEK）を使用してCEK（Kekri ReciontientInfo Choice）を暗号化します。暗号化されたCEKのコピーは、すべての受信者がCEKを復号化するために必要な共有Kekをすでに持っているため、暗号化されたコンテンツにアクセスできるため、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].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「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.
この分布メカニズムの主要なオーディエンスの1つは電子メールです。メールリストと呼ばれることもある配布リストは、メールリストに登録されている受信者へのメッセージの配布をサポートします。メールリストの使用方法には2つのモデルがあります。オリジネーターがメールリストのメンバーである場合、Originatorは共有Kekで暗号化されたメッセージをメールリスト（ListServやMajordomoなど）に送信し、メッセージはメールリストメンバーに配布されます。オリジネーターがメールリストのメンバーではない場合（共有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.
オブジェクトは、リポジトリ（Lightweight Directory Access Protocol（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.
このドキュメントは、3つの特定のシナリオを念頭に置いて記述されています。2つのサポートメールリストエージェントと、一般的なメッセージ配布のための1つのシナリオです。シナリオ1では、オリジネーターが公開キー（PK）保護されたメッセージをMLAに送信することを示しています。MLAは、共有Kek（S）を使用してメッセージをリストのメンバーに再配布します。シナリオ2は、オリジネーターが共有Kek保護されたメッセージをMLAに送信することを示しています。MLAは、リストのメンバーにメッセージを再配置します（MLAは追加の受信者のみを追加します）。オリジネーターが使用するキーは、すべての受信者の間で、またはメンバーとMLAの間だけで共有される可能性があります。オリジネーターがMLAとのみ共有されたキーを使用する場合、MLAはメッセージを復号化し、リストの受信者のメッセージを再クリップする必要があることに注意してください。シナリオ3は、中間のMLAなしでレシピエントのグループに共有Kek保護されたメッセージを送信する発信元を示しています。
+----> +----> +---->
PK +-----+ S | S +-----+ S | S |
----> | MLA | --+----> ----> | MLA | --+----> ----+---->
+-----+ | +-----+ | |
+----> +----> +---->
Scenario 1 Scenario 2 Scenario 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つの異なるエージェントを持つ2つの異なる関数をサポートしています。
- The Key Management Agent (KMA), which is responsible for generating the shared KEKs.
- 共有KEKSの生成を担当するキー管理エージェント（KMA）。
- The Group Management Agent (GMA), which is responsible for managing the Group List (GL) to which the shared KEKs are distributed.
- 共有KEKが分布するグループリスト（GL）の管理を担当するグループ管理エージェント（GMA）。
+----------------------------------------------+
| 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は複数のKMAをサポートする場合があります。GLAは一般に1つのGMAのみをサポートしますが、GMAは複数のGLSをサポートする場合があります。複数のKMAは、GLASが複数のKMAをサポートするのと同じ方法でGMAをサポートする場合があります。特定のKMAをGLに割り当てることは、このドキュメントの範囲を超えています。
Modeling real-world GL implementations shows that there are very restrictive GLs, where a human determines GL membership, and very open GLs, where there are no restrictions on GL membership. To support this spectrum, the mechanism described herein supports both 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のプロパティまたはメンバーシップを変更することを許可されている複数のエンティティが存在する場合があります。GLOは、GLが管理されるか無管理されているかを判断し、GLを削除できる唯一のエンティティです。GLO（s）はGLメンバーである場合とそうでない場合があります。GLO（S）は、GLOがGLメンバーシップのみを決定する閉じられているリストを設定することもできます。
Though Figure 1 depicts the GLA as encompassing both the KMA and GMA functions, the two functions could be supported by the same entity or they could be supported by two different entities. If two entities are used, they could be located on one or two platforms. There is however a close relationship between the KMA and GMA functions. If the GMA stores all information pertaining to the GLs and the KMA merely generates keys, a corrupted GMA could cause havoc. To protect against a corrupted GMA, the KMA would be forced to double check the requests it receives to ensure that the GMA did not tamper with them. These duplicative checks blur the functionality of the two components together. For this reason, the interactions between the KMA and GMA are beyond the scope of this document.
図1は、KMA関数とGMA関数の両方を含むGLAを示していますが、2つの機能は同じエンティティによってサポートされるか、2つの異なるエンティティによってサポートされる可能性があります。2つのエンティティを使用すると、1つまたは2つのプラットフォームに配置できます。ただし、KMA関数とGMA関数の間には密接な関係があります。GMAがGLSに関連するすべての情報を保存し、KMAがキーを生成するだけである場合、破損したGMAは大混乱を引き起こす可能性があります。破損したGMAから保護するために、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つのエンティティ間の信頼関係を強化することにより、機能を分離することができます。今後、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を管理するための既存のメカニズム（ListservやMajordomoなど）があります。ただし、このドキュメントは、標準化されていないため、これらのメカニズムの保護に対応していません。代わりに、GLメンバー、GLA、およびGLOがGLSを管理し、共有KEKSを分布させるために使用される図2に示すように、プロトコルの相互作用を定義します。相互作用は、管理メッセージと配布メッセージに分割されています。管理メッセージは、GLのセットアップ、GLの削除、GLにメンバーを追加し、GLのメンバーを削除し、グループレキーをリクエストし、所有者をGLに追加し、GLの所有者を削除するために必要なリクエストと応答メッセージです。グループキーの妥協、グループキーの更新、GLAの尋問、およびメンバーと所有者の公開証明書を更新します。配布メッセージは、共有Keksを配布するメッセージです。次のセクションでは、投与メッセージと配布メッセージの両方の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）プロトコルを介した証明書管理がこのプロトコルの基礎として選択されました。選択の主な理由は、CMCが提供するレイヤー化の側面であり、1つ以上の制御属性がCMSで保護されたメッセージに含まれ、目的のアクションを要求または応答します。CMC Pkidata構造はリクエストに使用され、CMC PKiresponse構造は応答に使用されます。コンテンツタイプのpkidataとpkiresponseは、CMSのSignedDataまたはEnvelopedData、または2つの組み合わせにカプセル化されます（セクション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出身のo、受信のr、fのf。実装には、GLO、GLA、GLメンバーの3つのタイプがあります。GLOはオプションのコンポーネントであるため、すべてのGlo OおよびGlo Rメッセージはオプションであり、GLA Fメッセージはオプションです。最初の表には、コンフォーマントの実装がサポートする必要があるメッセージが含まれています。2番目の表には、実装される可能性のあるメッセージが含まれています。2番目の表は次のように解釈する必要があります。コントロール属性がコンポーネントによって実装されている場合、指定されているように実装する必要があります。たとえば、GladdMember Control属性をサポートするGLAが実装されている場合、GladdMemberメッセージの受信をサポートする必要があります。「 - 」は該当しないことを意味することに注意してください。
Required
Implementation Requirement | Control
GLO | GLA | GL Member | Attribute
O R | O R F | O R |
------- | ----------------- | --------- | ----------
MAY - | MUST - MAY | - MUST | glProvideCert
MAY MAY | - MUST MAY | MUST - | glUpdateCert
- - | MUST - - | - MUST | glKey
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 PKiresponseコンテンツタイプで運ばれ、他のすべての制御属性はCMC PKidataコンテンツタイプで運ばれます。例外はGlupdateCertで、PkidataまたはPkiresponseのいずれかで運ぶことができます。
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はGlusekekを使用して、共有KekをGLに割り当てることを要求します。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].
CertificateSet ::= SET SIZE (1..MAX) OF CertificateChoices
-- CertificateChoices supports X.509 public key certificates in
-- certificates and v2 attribute certificates in v2AttrCert.
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とGraddressは同じである可能性がありますが、これは必ずしもそうではありません。名前とアドレスの両方が、特定の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).
-Lownername GLの所有者の名前を示します。Glownernameの名前の1つは、証明書の名前の1つ（主題の区別名または対象の代替名のいずれか）と一致する必要があります。
-- 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.
---証明書.pkcには、GLOの暗号化証明書が含まれています。GLOの応答を暗号化するために使用されます。
--- certificates.aC MAY be included to convey any attribute certificate (see [ACPROF]) associated with the encryption certificate of the GLO included in certificates.pKC.
---証明書。ACは、証明書に含まれるGLOの暗号化証明書に関連付けられた属性証明書（[ACPROF]を参照）を伝えるために含めることができます。
--- certificates.certPath MAY also be included to convey certificates that might aid the recipient in constructing valid certification paths for the certificate provided in certificates.pKC and the attribute certificates provided in certificates.aC. Theses certificates are optional because they might already be included elsewhere in the message (e.g., in the outer CMS layer).
---証明書。CERTPATHは、証明書に記載されている証明書の有効な認証パスの構築を支援する可能性のある証明書を伝えるために含めることもできます。これらの証明書は、メッセージの他の場所に既に含まれている可能性があるため、オプションです（例：外側のCMS層）。
-- glAdministration indicates how the GL ought to be administered. The default is for the list to be managed. Three values are supported for glAdministration:
-MazMinistrationは、GLがどのように管理されるべきかを示します。デフォルトは、リストを管理することです。喜びのために3つの値がサポートされています。
--- Unmanaged - When the GLO sets glAdministration to unmanaged, it is allowing prospective members to request addition and deletion from the GL without GLO intervention.
---管理されていない - GLOがgladministrationを管理していない場合、将来のメンバーがGLO介入なしでGLからの追加と削除を要求することを可能にします。
--- Managed - When the GLO sets glAdministration to managed, it is allowing prospective members to request addition and deletion from the GL, but the request is redirected by the GLA to GLO for review. The GLO makes the determination as to whether to honor the request.
---マネージド - GLOが管理するためにgladMinistrationを設定すると、将来のメンバーがGLから追加と削除を要求することができますが、リクエストはGLAによってGLOにリダイレクトされ、レビューのためにリダイレクトされます。GLOは、リクエストを尊重するかどうかを決定します。
--- Closed - When the GLO sets glAdministration to closed, it is not allowing prospective members to request addition or deletion from the GL. The GLA will only accept glAddMember and glDeleteMember requests from the GLO.
---閉じ - GLOがgladministrationを閉じるように設定すると、将来のメンバーがGLからの追加または削除を要求することを許可していません。GLAは、GLOからのGladdMemberおよびGldeleTememberのリクエストのみを受け入れます。
-- glKeyAttributes indicates the attributes the GLO wants the GLA to assign to the shared KEK. If this field is omitted, GL rekeys will be controlled by the GLA, the recipients are allowed to know about one another, the algorithm will be AES-128 (see Section 7), the shared KEK will be valid for a calendar month (i.e., first of the month until the last day of the month), and two shared KEKs will be distributed initially. The fields in glKeyAttributes have the following meaning:
-Glkeyattributesは、GLOがGLAに共有Kekに割り当てることを望んでいる属性を示します。このフィールドが省略されている場合、GL RekeysはGLAによって制御され、レシピエントは互いに知ることができます、アルゴリズムはAES-128（セクション7を参照）になります（セクション7を参照）、共有Kekは暦月に有効になります（つまり、、最初の月の最終日まで）、そして最初に2つの共有Keksが配布されます。Glkeyattributesのフィールドには次の意味があります。
--- rekeyControlledByGLO indicates whether the GL rekey messages will be generated by the GLO or by the GLA. The default is for the GLA to control rekeys. If GL rekey is controlled by the GLA, the GL will continue to be rekeyed until the GLO deletes the GL or changes the GL rekey to be GLO controlled.
--- RekeycontrolledBygloは、GL RekeメッセージがGLOまたはGLAによって生成されるかどうかを示します。デフォルトは、GLAがRekeysを制御することです。GL RekeがGLAによって制御されている場合、GLOがGLを削除したり、GL RekeをGLO制御してGL Rekeを変更するまでGLは再キーになり続けます。
--- 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.
--- ReciintesNotMutialAwareは、GLOがGLAにGLメンバーごとに共有KEKを個別に配布することを望んでいることを示します（つまり、個別のGLKEYメッセージが各受信者に送信されます）。デフォルトは、個別のglkeyメッセージが不要になることです。
Note: This supports lists where one member does not know the identities of the other members. For example, a list is configured granting submit permissions to only one member. All other members are 'listening'. The security policy of the list does not allow the members to know who else is on the list. If a glKey is constructed for all of the GL members, information about each of the members may be derived from the information in RecipientInfos.
注：これは、あるメンバーが他のメンバーの身元を知らないリストをサポートしています。たとえば、リストは1人のメンバーのみに送信権限を付与する構成されています。他のすべてのメンバーは「リスニング」です。リストのセキュリティポリシーでは、メンバーが他の人がリストに載っていることを知ることはできません。GLKEYがすべてのGLメンバーに対して構築されている場合、各メンバーに関する情報は、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メッセージが他の受信者に関する情報を明かしないことを確認するために、各GLメンバーに個別のGLKEYメッセージが送信されます。
--- duration indicates the length of time (in days) during which the shared KEK is considered valid. The value zero (0) indicates that the shared KEK is valid for a calendar month in the UTC Zulu time zone. For example, if the duration is zero (0), if the GL shared KEK is requested on July 24, the first key will be valid until the end of July and the next key will be valid for the entire month of August. If the value is not zero (0), the shared KEK will be valid for the number of days indicated by the value. For example, if the value of duration is seven (7) and the shared KEK is requested on Monday but not generated until Tuesday (13 May 2008); the shared KEKs will be valid from Tuesday (13 May 2008) to Tuesday (20 May 2008). The exact time of the day is determined when the key is generated.
---期間は、共有Kekが有効と見なされる時間（日数）を示します。値ゼロ（0）は、共有KekがUTC Zuluタイムゾーンの暦月に有効であることを示します。たとえば、期間がゼロ（0）の場合、7月24日にGL共有Kekが要求された場合、最初のキーは7月末まで有効になり、次のキーは8月全体で有効になります。値がゼロ（0）でない場合、共有Kekは値で示される日数に対して有効になります。たとえば、期間の値が7（7）であり、共有Kekが月曜日に要求されますが、火曜日（2008年5月13日）まで生成されません。共有KEKSは、火曜日（2008年5月13日）から火曜日（2008年5月20日）まで有効です。一日の正確な時間は、キーが生成されるときに決定されます。
--- generationCounter indicates the number of keys the GLO wants the GLA to distribute. To ensure uninterrupted function of the GL, two (2) shared KEKs at a minimum MUST be initially distributed. The second shared KEK is distributed with the first shared KEK, so that when the first shared KEK is no longer valid the second key can be used. If the GLA controls rekey, then it also indicates the number of shared KEKs the GLO wants outstanding at any one time. See Sections 4.5 and 5 for more on rekey.
--- GenerationCounterは、GLOがGLAに分布させたいキーの数を示します。GLの途切れない機能を確保するには、最低2つの共有KEKを最初に分布させる必要があります。2番目の共有Kekは、最初の共有Kekで配布されるため、最初の共有Kekが有効になった場合、2番目のキーを使用できます。GLAがRekeyを制御する場合、GLOが一度に傑出したものを望んでいる共有Keksの数も示します。Rekeyの詳細については、セクション4.5および5を参照してください。
--- requestedAlgorithm indicates the algorithm and any parameters the GLO wants the GLA to use with the shared KEK. The parameters are conveyed via the SMIMECapabilities attribute (see [MSG]). See Section 6 for more on algorithms.
--- RequestEdalGorithmは、GLOがGLAに共有Kekで使用することを望んでいるアルゴリズムとパラメーターを示します。パラメーターは、SmimeCapabilities属性を介して伝達されます（[MSG]を参照）。アルゴリズムの詳細については、セクション6を参照してください。
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はGldeleteを使用して、GLをGLAから削除することを要求します。Gldelete Control属性には、構文一般名があります。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を使用して新しいメンバーの追加をリクエストし、GLAGLメンバー将来のメンバーはGladdMemberを使用してGLへの独自の追加をリクエストします。GladdMemberメッセージは、GLOまたは将来のGLメンバーのいずれかによって署名されなければなりません。GladdMember Control属性には、構文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:
- GLメンバーは、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.
---証明書.pkcには、メンバーの暗号化証明書が含まれています。少なくとも最初は、そのメンバーの共有Kekを暗号化するために使用されます。メッセージが将来のGLメンバーによって生成される場合、PKCを含める必要があります。メッセージがGLOによって生成される場合、PKCを含める必要があります。
--- certificates.aC MAY be included to convey any attribute certificate (see [ACPROF]) associated with the member's encryption certificate.
---証明書。ACは、メンバーの暗号化証明書に関連付けられている属性証明書（[ACPROF]を参照）を伝えるために含めることができます。
--- certificates.certPath MAY also be included to convey certificates that might aid the recipient in constructing valid certification paths for the certificate provided in certificates.pKC and the attribute certificates provided in certificates.aC. These certificates are optional because they might already be included elsewhere in the message (e.g., in the outer CMS layer).
---証明書。CERTPATHは、証明書に記載されている証明書の有効な認証パスの構築を支援する可能性のある証明書を伝えるために含めることもできます。これらの証明書は、メッセージの他の場所に既に含まれている可能性があるため、オプションです（例：外側のCMS層）。
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はGldeleTememberを使用してGLメンバーの削除を要求し、GLメンバーはGldeleTememberを使用してGLから独自の除去を要求します。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はGlrekeyを使用してGL Rekeyをリクエストします。GlrekeyメッセージはGLOによって署名する必要があります。Glrekey Control属性にはSyntax 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.
- gladministrationは、GLの管理方法に変更があるかどうかを示します。3つのオプションについては、セクション3.1.1を参照してください。このフィールドは、以前に登録されたgladministrationから変更がある場合にのみ含まれています。
- glNewKeyAttributes indicates whether the rekey of the GLO is controlled by the GLA or GL, what algorithm and parameters the GLO wishes to use, the duration of the key, and how many keys will be issued. The field is only included if there is a change from the previously registered glKeyAttributes.
- GlnewKeyattributesは、GLOの再キーがGLAまたはGLによって制御されるかどうか、GLOが使用したいアルゴリズムとパラメーター、キーの持続時間、および発行されるキーの数を示します。このフィールドは、以前に登録されたGlkeyattributesから変更がある場合にのみ含まれています。
- glRekeyAllGLKeys indicates whether the GLO wants all of the outstanding GL's shared KEKs rekeyed. If it is set to TRUE then all outstanding KEKs MUST be issued. If it is set to FALSE then all outstanding KEKs need not be reissued.
- Glrekeyallglkeysは、GLOがすべての傑出したGLの共有Keksを再キーにしたいかどうかを示します。それが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はGladdowderを使用して、新しいGLOをGLの管理を許可するように要求します。GladDownerメッセージは、登録されたGLOによって署名する必要があります。GladDowner Control属性には、構文の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の名前、住所、証明書を示します。このメッセージには新しいGLOの名前が含まれているため、証明書を含める必要があり、新しい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はGlremoveownerを使用して、GLOをGLと分離するように要求します。GlremoveOwnerメッセージは、登録されたGLOによって署名する必要があります。GlremoveOwner Control属性には、構文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メンバーとGLOは、GlkCompromiseを使用して、共有Kekが所有していることを示しています。glkeycompromiseコントロール属性には、構文一般名があります。このメッセージは、GLAによって常にGLOにリダイレクトされ、さらなるアクションが得られます。GlkCompromiseは、侵害された共有Kekで生成された封筒に含まれる場合があります。妥協したキーが関連付けられているGLの名前は、一般名に配置されます。
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メンバーはGlkRefreshを使用して、共有Kekをそれらに再配布するように要求します。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メンバーが共有KEKSを必要とするGLの名前を示します。
- dates indicates a date range for keys the GL member wants. The start field indicates the first date the GL member wants and the end field indicates the last date. The end date MAY be omitted to indicate the GL member wants all keys from the specified start date to the current date. Note that a procedural mechanism is needed to restrict users from accessing messages that they are not allowed to access.
- 日付は、GLメンバーが望むキーの日付範囲を示します。開始フィールドは、GLメンバーが望む最初の日付を示し、エンドフィールドは最後の日付を示します。終了日は、GLメンバーが指定された開始日から現在の日付まですべてのキーを必要とすることを示すために省略できます。ユーザーがアクセスが許可されていないメッセージへのアクセスを制限するには、手続き上のメカニズムが必要であることに注意してください。
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.
GLOとGLメンバーがGLについてGLAからいくつかの情報を決定する必要がある場合があります。GLOSおよびGLメンバーは、セクション3.1.10.1で定義されているGlaqueryRequestを使用して、情報を要求し、GLAはセクション3.1.10.2で定義されているGlaqueryResponseを使用して要求された情報を返します。セクション3.1.10.3には、1つのリクエストと応答の種類と値が含まれています。その他は追加のドキュメントで定義される場合があります。
GLOs and GL members use the glaQueryRequest to ascertain information
about the GLA. The glaQueryRequest control attribute has the syntax
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:
このドキュメントでは、GLメンバーとGLOの1つの要求/応答ペアを定義して、サポートするアルゴリズムのリストをGLAに照会します。次のオブジェクト識別子（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]で定義されているSmimeCapability属性の形式があります。
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:
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:
- GLメンバーは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メンバーとGLOは、GlupdateCertを使用してGLの新しい証明書を提供します。GLメンバーは、GLProvideCertメッセージを受信した結果、未承諾のGlupDateCertを生成したり、glupdatecertを生成したりできます。GLメンバーはGlupDateCertに署名する必要があります。GLメンバーの暗号化証明書が取り消された場合、GLメンバーはそれを使用して、GlupDateCertのリクエストまたは応答をカプセル化する封筒を生成してはなりません。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:
- GLメンバーは、GLメンバーの詳細を示します。
-- glMemberName indicates the GL member's name.
-GLMemberNameはGLメンバーの名前を示します。
-- glMemberAddress indicates the GL member's address. It MAY be omitted.
-GLMEMBERADDRESSはGLメンバーのアドレスを示します。省略される場合があります。
-- certificates MAY be omitted if the GLManageCert message is sent to request the GL member's certificate; otherwise, it MUST be included. It includes the following three fields:
-GLメンバーの証明書を要求するためにGlmanageCertメッセージが送信された場合、証明書は省略できます。それ以外の場合は、含める必要があります。次の3つのフィールドが含まれます。
--- certificates.pKC includes the member's encryption certificate that will be used to encrypt the shared KEK for that member.
---証明書.pkcには、そのメンバーの共有Kekを暗号化するために使用されるメンバーの暗号化証明書が含まれています。
--- certificates.aC MAY be included to convey one or more attribute certificates associated with the member's encryption certificate.
---証明書。ACを含めると、メンバーの暗号化証明書に関連付けられた1つ以上の属性証明書を伝えることができます。
--- certificates.certPath MAY also be included to convey certificates that might aid the recipient in constructing valid certification paths for the certificate provided in certificates.pKC and the attribute certificates provided in certificates.aC. These certificates are optional because they might already be included elsewhere in the message (e.g., in the outer CMS layer).
---証明書。CERTPATHは、証明書に記載されている証明書の有効な認証パスの構築を支援する可能性のある証明書を伝えるために含めることもできます。これらの証明書は、メッセージの他の場所に既に含まれている可能性があるため、オプションです（例：外側のCMS層）。
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はGlkeyを使用して共有Kekを配布します。GLKEYメッセージはGLAによって署名する必要があります。Glkey Control属性にはSyntax 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 ::= 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で指定されているように、ReciintientInfosを生成する必要があります。Ktri RecipientInfoの選択をサポートする必要があります。暗号化されたキーフィールド（つまり、分散共有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が使用されるアルゴリズムを識別します。この時点で暗号化されたデータコンテンツが伝達されていないため、アルゴリズムでエンコードされたパラメーターは、暗号化されたコンテンツではなく、SmimeCapabilityの構造である必要があります。
- 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.
- glknotbeは、共有Kekが有効と見なされる日付を示します。一般化された時間の値はUTC（Zulu）で表現する必要があり、秒数がゼロであっても、秒（つまり、時間はyyyymmdhhmmssz）を含める必要があります。一般化された時間値は、分数秒を含めてはなりません。
- 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が無効と見なされる日付を示します。一般化された時間の値はUTC（Zulu）で表現する必要があり、秒数がゼロであっても、秒（つまり、時間はyyyymmdhhmmssz）を含める必要があります。一般化された時間値は、分数秒を含めてはなりません。
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.RECIPIENTSNOTMUTELAWAREがtrueに設定されている場合、GLAは各受信者に個別のGLKEYメッセージを生成する必要があります。各受信者について、その受信者のキー（つまり、1つの属性を持つ1つのメッセージ）を含むメッセージを生成する必要があります。
- The GLA MUST generate the requested number of glKey messages. The value in glUseKEK.glKeyAttributes.generationCounter indicates the number of glKey messages requested.
- GLAは、要求された数の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.
- GLAは、glrekey.glnewkeyattributes.RecipientsNotMutialAwareがtrueに設定されている場合、各受信者に個別の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の優れた共有KEKSごとに1つのGLKEYメッセージを生成する必要があります。
If the glKey message was not in response to a glRekey or glUseKEK (e.g., where the GLA controls rekey):
GlkeyメッセージがGlrekeyまたはGlusekek（例えば、GLAがRekeyを制御する場所）に応じていない場合：
- The GLA MUST generate separate glKey messages for each recipient when glUseKEK.glNewKeyAttributes.recipientsNotMutuallyAware that set up the GL was set to TRUE.
- glusekek.glnewkeyattributes.RecipientsNotMutiLAWARE AWAREがGLを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メッセージの数が1つ（1）から生成されたGlkeyメッセージの数が有効期限を切る最後の傑出した共有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をカプセル化する方法は複数あります。1つ目は、[MSG]で指定されているように、各contentinfoの周りにmimeラッパーを使用することです。2つ目は、x.400 [x400trans]の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].
リクエストまたは応答でアクションを実行する前に、[CMS]に従って署名された署名data（s）は処理する必要があります。
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:
追加の封筒を使用して、リクエストと応答の機密性を提供することもできます。また、カプセル化された封筒の認証と整合性を提供するために、追加のSignedDataを追加することもできます。以下は、オプションの追加のラッピングの描写です。
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]で指定されているように処理する必要があります。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がGLメンバーのリクエストをGLOに転送する場合、GLAは封筒コンテンツを復号化し、機密性レイヤーを剥ぎ取り、GLOを受信者としてGLOで封筒として独自の機密性レイヤーを適用する必要があります。
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.control sequenceまたはpkiresponse.control sequenceに含まれる場合があります。複数のGLSのリクエストと応答は、pkidata.cms sequenceとpkiresponse.cms sequenceを使用して、1つのpkidataまたはpkiresponseで結合することができます。異なるGLSには別のCMSシーケンスを使用する必要があります。つまり、2つの異なるGLSに対応するリクエストは、異なるCMSシーケンスに含まれます。以下は、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.control sequenceと1つのpkiresponse.control sequenceでのリクエストの特定の組み合わせは許可されていません。ここにリストされている無効な組み合わせを生成してはなりません。
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.
不必要なエラーを回避するには、特定のリクエストと応答を他のリクエストよりも処理する必要があります。以下はメッセージ処理の優先順位です。リストされていない場合、最初に処理するかについての実装決定です。GlusekekGladdMemberの前、GladdMemberの前のGlrekey、Glrekeyの前の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つを生成します。skdfailinfo skdfailinfo unsupportedduration、unsupporteddeliverymethod、unsupportedalgorithm、noglonamematch、namealreadyinuse、既に解釈者、およびnotanownerの値は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.RecipientsNotMutialAwareがtrueに設定されている場合、個別のpkiresponse.cmcstatusinfoextとpkidata.glkeyを各受信者に対して生成する必要があります。ただし、同じ受信者に複数の属性を持つ1つのメッセージを送信することは有効です。
If the GL has multiple GLOs, the GLA MUST send cMCStatusInfoExt messages to the requesting GLO. The mechanism to determine which GLO made the request is beyond the scope of this document.
GLに複数のGLOSがある場合、GLAは要求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:
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].
CMCは、CMS署名属性として制御属性を運びます。これらの属性は、[CMC]および[CMS]で定義されています。これらの属性のいくつかが必要です。その他はオプションです。必要な属性は次のとおりです。CMCSTATUSINFOEXTTransactionID、SenderNonce、ReciontNonce、QueryPending、およびSignimeTime。他の属性も使用できます。ただし、それらの使用はこのドキュメントの範囲を超えています。次のセクションでは、[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は、GLASによってGLOSおよびGLメンバーにリクエストが失敗したことを示すために使用されます。このドキュメント内では、2つのクラスの障害コードが使用されています。CMCのセクション5.1.4にあるCMCFailInfoリストからのエラーは、CMCで定義されているようにエンコードされています。このドキュメントで定義されているエラーコードは、CMCSTATUSINFOEXT構造のExtendedFailInfoフィールドを使用してエンコードされます。同じ障害コードが複数のコマンドに適用される場合、CMCSTATUSINFOEXT.BODYLISTで複数のアイテムで単一のCMCSTATATUSINFOEXT構造を使用できます。GLAはまた、スタッストリングの他の関連情報を返すことがあります。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）、すでにメンバー（11）、Notamember（12）、既に発言者（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.
- サポートされていない硬化は、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の名前が名前のいずれか（主題の区別名または主題の代替名のいずれか）が署名に使用されていた場合に署名しなかったことを示しています。リクエスト）。
- alreadyAMember indicates that the prospective GL member is already a GL member.
- 既に、Amemberは、将来の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.
- 既にアナナーは、将来の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は、GLASによってGLOSおよびGLメンバーにリクエストが正常に完了したことを示すために使用されます。リクエストが成功した場合、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は、GLO、GLA、およびGLメンバーによって使用され、署名検証が失敗したことを示します。署名がCMCSTATUSINFOEXTを除く任意の制御属性を検証できなかった場合、CMCSTATUS.FAILEDおよびOTHERINFO.FAILINFO.BADMESSAGECHECKを示すCMCSTATUSINFOEXTコントロール属性を返す必要があります。最も外側のpkidata上の署名が失敗した場合、ボディリスト値はゼロ（0）です。他のpkidata上の署名が失敗した場合、ボディリスト値はリクエストまたは応答からのボディパルティッド値です。署名が無効であるCMCSTATUSINFOEXTメッセージを受け取るGLOおよびGLメンバーは、Badmessagecheckメッセージループを避けるための新しいリクエストを生成するはずです。
cMCStatusInfoExt is also used by GLOs and GLAs to indicate that a request could not be performed immediately. If the request could not be processed immediately by the GLA or GLO, the cMCStatusInfoExt control attribute MUST be returned indicating cMCStatus.pending and otherInfo.pendInfo. When requests are redirected to the GLO for approval (for managed lists), the GLA MUST NOT return a cMCStatusInfoExt indicating query pending.
CMCSTATUSINFOEXTは、GLOとGLAによっても使用されて、リクエストをすぐに実行できないことを示します。リクエストをGLAまたはGLOによってすぐに処理できなかった場合、CMCSTATUS.PENDINGおよびその他のInfo.Pendinfoを示すCMCSTATUSINFOEXTコントロール属性を返す必要があります。リクエストが承認のために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は、GLASによってもGlaqueryRequestがサポートされていないことを示すために使用されます。GlaqueryRequestがサポートされていない場合、CMCSTATUS.NOSUPPORTおよびSTATUSSTRINGを示すCMCSTATUSINFOEXTコントロール属性を返す必要があります。
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は、GLメンバー、GLO、およびGLAによっても使用され、署名時間（セクション3.2.4.3を参照）がローカルで指定された時間に十分に近いことを示しています。現地時間が署名時間で指定された時間に十分に近い場合、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は、GLO、GLA、またはGLメンバーに含まれて、特定のトランザクションを特定できます。元のリクエストに関連するすべての後続の要求と応答には、同じTransactionIDコントロール属性を含める必要があります。GLメンバーにTransactionIDが含まれ、リクエストがGLOにリダイレクトされている場合、GLAには外側のPkidataに追加のトランザクションIDが含まれる場合があります。GLAに外側のPkidataに追加のトランザクションIDが含まれている場合、GLOがCMCStatusInfoext応答を生成すると、GLAのTransactionIDでGLA用の1つ、GLメンバーのTransactionIDを使用してGLメンバーが1つ生成されます。
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.
Noncesの使用（[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を保護するには、すべてのメッセージに署名時間属性を含める必要があります。メッセージのオリジネーターと受信者は、この属性で提供される時間を使用して、以前にメッセージを受信したかどうかを判断できます。
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値を受信者として、および応答の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はオプションで新しいNonCE値を生成し、ラッピングメッセージに含める場合があります。応答がGLOから戻ってくると、GLAはメッセージのオリジネーターへの応答を構築し、発信元のメッセージの各nonCE値を扱います。
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はGLメンバーのリクエストをGLO承認のためにGLO承認に転送し、CMSシーケンスアイテムとしてGLメンバーリクエストを含む新しいリクエストメッセージを作成します。GLOがリクエストを承認する場合、ラッピングの新しいレイヤーを追加してGLAに送り返すか、新しいメッセージを作成してGLAに送信できます。（この場合、適切な署名レイヤーを備えた3層のpkidataメッセージがあります。）
Signatures, certificates, and CRLs are verified according to the PKIX profile [PROFILE].
署名、証明書、およびCRLは、PKIXプロファイル[プロファイル]に従って検証されます。
Name matching is performed according to the PKIX profile [PROFILE].
名前マッチングは、PKIXプロファイル[プロファイル]に従って実行されます。
All distinguished name forms must follow the UTF8String convention noted in the PKIX profile [PROFILE].
すべての著名な名前フォームは、PKIXプロファイル[プロファイル]に記載されているUTF8STRING規則に従う必要があります。
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をセットアップし、GLに割り当てられた共有KEKをセットアップする必要があります。図3は、プロトコルの相互作用を示して、共有Kekをセットアップして割り当てます。エラーメッセージは図3に示されていないことに注意してください。さらに、オプションのTransactionID、Sendernonce、およびReciintNonce CMC制御属性の動作は、これらの手順では対処されていません。
+-----+ 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は、signeddata.pkidata.control sequence.glusekekリクエストをGLAに送信します（図3の1）。GLOには、Glname、Gladdress、Glownername、GlownerAddress、GladMinistrationが含まれている必要があります。GLOには、GLOがRekeycontrolledBygloのRekeyを制御するかどうかを示すことにより、Glkeyattributesの共有Kekの好みを含めることもできます。共有Kekの持続時間と、GenerationCounterで最初に分布する共有Kekの数。GLOには、このリクエストに署名時間属性も含める必要があります。
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を参照）。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は、封筒のsignedData.pkidataを封筒にカプセル化することにより、要求に機密性を適用できます（セクション3.2.1.2を参照）。
1.c - The GLO can also optionally apply another SignedData over the EnvelopedData (see Section 3.2.1.2).
1.C- GLOは、オプションでエンベロープドタに別の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は署名時間をチェックし、最も内側のsigneddata.pkidataの署名を検証します。追加のsignedDataおよび/または封筒がリクエストをカプセル化する場合（セクション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-署名時間属性値がローカルで受け入れられた時間枠内にない場合、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およびその他のInfo.failinfo.badmessagecheckを示すCMCSTATUSINFOEXT応答を返します。さらに、署名時間属性が応答に含まれています。
2.c - Else if the signatures do verify but the GLA does not have a valid certificate, the GLA returns a cMCStatusInfoExt with cMCStatus.failed and otherInfo.extendedFailInfo.SKDFailInfo value of noValidGLACertificate. Additionally, a signingTime attribute is included with the response. Instead of immediately returning the error code, the GLA attempts to get a certificate, possibly using [CMC].
2.C-署名が検証しているが、GLAに有効な証明書がない場合、GLAはcmcStatus.failedおよびotherinfo.extendedfailinfo.skdfailinfoを使用してcmcstatusinfoextを返します。さらに、署名時間属性が応答に含まれています。エラーコードをすぐに返す代わりに、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はcmcStatus.failedおよびotherinfo.extedendedfailinfo.skdfailinfo noglonamematchのcmcstatusinfoextを示す応答を返します。さらに、署名時間属性が応答に含まれています。
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とGraddressがまだ使用されていないことをチェックします。GLAは、このGlusekekの制御シーケンス内に含まれるGladdMemberもチェックします。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の値を使用してcmcstatusinfoextを示す応答を返します。さらに、署名時間属性が応答に含まれています。
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はcmcstatus.failedおよびotherinfo.extedendedfailinfo.skdfailinfo unsupportedalgorithmのcmcstatusinfoextを示す応答を返します。さらに、署名時間属性が応答に含まれています。
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およびEXTEDEDEDEDEDEDEDFAILINFO.SKDFAILINFO UNOPPORTEDDURERSのcmcStatusinfoextを示す応答を返します。さらに、署名時間属性が応答に含まれています。
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およびEXTEDEDEDEDEDFAILINFO.SKDFAILINFOを使用してCMCSTATUS.FAILEDおよびEXTEDEDEDEDFAILINFO.SKDFAILINFOを使用してCMCSTATUSINFOEXTを示す応答を返します。さらに、署名時間属性が応答に含まれています。
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がまだ使用されていない場合、期間をサポートし、要求済み型溝がサポートされている場合、GLAはCMCSTATUS.SUCCESSとSINGIBETIME属性を示すCMCSTATUSINFOEXTを返す必要があります。（図3の2）。GLAはまた、このドキュメントの範囲を超えた管理措置を講じて、Glname、Graddress、Glkeyattributes、Glownername、GlownerAddressを保存します。GLAは、セクション5で説明されているように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-GLAは、リクエストが封筒にカプセル化されている場合、封筒のSignedData.pkiresponseをカプセル化することにより、応答に機密性を適用できます（セクション3.2.1.2を参照）。
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は、オプションでエンベロープドタに別の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は署名時間をチェックし、GLA署名を検証します。追加のsignedDataおよび/または封筒が応答をカプセル化する場合（セクション3.2.1.2または3.2.2を参照）、GLOは外側の署名を検証し、/または最も内側の署名dataの署名を検証する前に外側の層を復号化します。
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-署名時間属性値がローカルで受け入れられた時間枠内にない場合、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.CMCSTATUS.CMCSTATATUS.CMCSTATUSINFOEXT.CMCSTATUS.CMCSTATATUSINFOEXT.CMCSTATUS。GLOは、GlaqueryRequestを使用して、GLAでサポートされているアルゴリズムとその他の特性を決定することもできます（セクション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、およびReciintNonce CMC Control属性の動作は対処されていないことに注意してください。
+-----+ 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は、signeddata.pkidata.control sequence.gldeleteリクエストをGLAに送信します（図4の1）。削除されるGLの名前はgenerationalNameに含まれています。GLOには、署名時間属性も含める必要があり、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は、封筒の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は、オプションでエンベロープドタに別の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は署名時間をチェックし、最も内側のsigneddata.pkidataの署名を検証します。追加のsignedDataおよび/または封筒が要求をカプセル化する場合（セクション3.2.1.2または3.2.2を参照）、GLAは外側の署名を検証し、/または最も内側の署名dataの署名を検証する前に外側の層を復号化します。
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-署名時間属性値がローカルで受け入れられた時間枠内にない場合、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およびその他のInfo.failinfo.badmessagecheckを示すCMCSTATUSINFOEXT応答を返します。さらに、署名時間属性が応答に含まれています。
2.c - Else if the signatures verify, the GLA makes sure the GL is supported by checking the name of the GL matches a glName stored on the GLA.
2.C-署名が確認された場合、GLAはGLの名前がGLAに保存されているGLNAMEと一致することにより、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はcmcStatus.failedおよびotherinfo.extendedfailinfo.skdfailinfoを使用してcmcstatusinfoextを示す応答を返します。さらに、署名時間属性が応答に含まれています。
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は登録GLOがGldelete Certificateに存在する名前の1つがGldeleteリクエストに署名するために使用される名前の1つが登録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はcmcStatus.failedおよびotherinfo.extendedfailinfo.skdfailinfo noglonamematchの値を使用してcmcstatusinfoextを示す応答を返します。さらに、署名時間属性が応答に含まれています。
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-名前が一致している場合は、GLAが開示したくない他の理由でGLを削除できない場合、GLAはCMCSTATUS.Failedおよびその他のho.extedendededfailinfoでcmcstatusinfoextを示す応答を返します。不特定のskdfailinfo値。さらに、署名時間属性が応答に含まれています。このドキュメントの範囲を超えたアクションを使用して、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とSINGINGTIME属性を示すCMCSTATUSINFOEXTを返します（図4の2）。GLAは、メンバーの追加、メンバーの削除、またはこのGLのグループレイクのさらなる要求を受け入れるべきではありません。
2.c.2.c.1 - The GLA can apply confidentiality to the response by encapsulating the SignedData.PKIResponse in an EnvelopedData if the request was encapsulated in an EnvelopedData (see Section 3.2.1.2).
2.C.2.C.1-GLAは、リクエストがEnvelopedDataにカプセル化されている場合、EnvelopedDataでSignedData.pkiresponseをカプセル化することにより、応答に機密性を適用できます（セクション3.2.1.2を参照）。
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は、オプションで封筒に別の署名dataを適用する場合があります（セクション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は署名時間をチェックし、GLA署名を検証します。追加のsignedDataおよび/または封筒が応答をカプセル化する場合（セクション3.2.1.2または3.2.2を参照）、GLOは外側の署名を検証し、/または最も内側の署名dataの署名を検証する前に外側の層を復号化します。
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-署名時間属性値がローカルで受け入れられた時間枠内にない場合、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-署名処理が継続され、署名が確認された場合、GLOは、応答に署名するために使用される証明書の名前の1つがGLの名前と一致することをチェックします。
3.b.1 - If the name of the GL does not match the name present in the certificate used to sign the message, the GLO should not believe the response.
3.B.1 -GLの名前がメッセージの署名に使用される証明書に存在する名前と一致しない場合、GLOは応答を信じるべきではありません。
3.b.2 - Else if the name of the GL does match the name present in the certificate and:
3.B.2-その他のGLの名前が証明書に存在する名前と一致する場合、
3.b.2.a - If the signatures verify and the response was cMCStatusInfoExt indicating cMCStatus.success, the GLO has successfully deleted the GL.
3.B.2.A-署名が検証され、応答がCMCSTATUS.SUCCESSを示すCMCSTATUSINFOEXTである場合、GLOはGLを正常に削除しました。
3.b.2.b - Else if the signatures do verify and the response was cMCStatusInfoExt.cMCStatus.failed with any reason, the GLO can reattempt to delete the GL using the information provided in the response.
3.B.2.B-署名が検証し、応答がCMCSTATUSINFOEXT.CMCSTATUS.CMCSTATUS.CMCSTATUSINFOEXT.CMCSTATUSであった場合、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にリクエストを転送します。GLに複数のGLOがある場合、リクエストが転送されるGLOは、このドキュメントの範囲を超えています。GLOはリクエストをレビューし、それを拒否するか、改革されたリクエストをGLAに提出します。閉じた場合、GLAは見込み客からのリクエストを受け入れません。次のセクションでは、Glo（S）、GLA、および将来のGLメンバーの処理について、Glo（GLOまたはGLOまたは将来のメンバーからのGladdmeberリクエストがどこから生じたかに応じて説明します。図5は、3つのオプションのプロトコル相互作用を示しています。エラーメッセージは描かれていないことに注意してください。さらに、オプションのTransactionID、Sendernonce、およびReciintNonce 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を再キーに戻すことができます。メンバーが追加されたときに管理されたGLSまたは閉じたGLSを再キーするオプションは、別のグループキーを持つ新しいGLを生成することです。グループの再キーイングについては、セクション4.5および5で説明します。
The process for GLO initiated glAddMember requests is as follows:
GLOのグラッドメンバーのリクエストを開始するプロセスは次のとおりです。
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は、各メンバーのGLAへの別のGladdMemberリクエストを使用して、SignedData.pkidata.Controlのシーケンスをsigneddata.pkidata.control sequenceを送信します（図5の1）。GLOには、glnameのGL名、glmember.glmembernameのメンバーの名前、glmember.glmemberaddressのメンバーのアドレス、およびglmember.certificates.pkcのメンバーの暗号化証明書が含まれています。GLOには、glmember.certificates.acのメンバーの暗号化証明書に関連付けられた属性証明書、およびメンバーの暗号化と属性証明書に関連付けられた認証パスを含めることもできます。GLOには、このリクエストに署名時間属性も含める必要があります。
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は、封筒の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は、オプションで封筒に別の署名dataを適用することもできます（セクション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は署名時間をチェックし、最も内側のsigneddata.pkidataの署名を検証します。追加のsignedDataおよび/または封筒が要求をカプセル化する場合（セクション3.2.1.2または3.2.2を参照）、GLAは外側の署名を検証し、/または最も内側の署名dataの署名を検証する前に外側の層を復号化します。
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-署名時間属性値がローカルで受け入れられた時間枠内にない場合、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およびその他のInfo.failinfo.badmessagecheckを示すCMCSTATUSINFOEXT応答を返します。さらに、署名時間属性が応答に含まれています。
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要求の制御シーケンスに含まれ、セクション4.1アイテム2.Dの処理が正常に完了すると、GLAはCMCSTATUS.SUCCESSおよびSINGINGTIME属性を示す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は、リクエストが封筒にカプセル化されている場合、封筒のsigneddata.pkidataを封筒にカプセル化することにより、応答に機密性を適用できます（セクション3.2.1.2を参照）。
2.c.2 - The GLA can also optionally apply another SignedData over the EnvelopedData (see Section 3.2.1.2).
2.C.2-GLAは、オプションでエンベロープドタに別の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リクエストの制御シーケンスに含まれていない場合、GLAはGLNAMEがGLAに保存されているGLNAMEと一致することを確認することによりGLがサポートされていることを確認します。
2.d.1 - If the glName is not supported by the GLA, the GLA returns a response indicating cMCStatusInfoExt with cMCStatus.failed and otherInfo.extendedFailInfo.SKDFailInfo value of invalidGLName. Additionally, a signingTime attribute is included with the response.
2.D.1 -GLNAMEがGLAによってサポートされていない場合、GLAはcmcstatus.failedおよびotherinfo.extedendedfailinfo.skdfailinfo invalidglnameのcmcstatusinfoextを示す応答を返します。さらに、署名時間属性が応答に含まれています。
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はGLにGLに存在するかどうかを確認します。
2.d.2.a - If the glMemberName is present on the GL, the GLA returns a response indicating cMCStatusInfoExt with cMCStatus.failed and otherInfo.extendedFailInfo.SKDFailInfo value of alreadyAMember. Additionally, a signingTime attribute is included with the response.
2.D.2.A-GLMEMBERNAMEがGLに存在する場合、GLAはcmcStatus.failedおよびotherinfo.extendedfailinfo.skdfailinfoのcmcstatusinfoextを示す応答を返します。さらに、署名時間属性が応答に含まれています。
2.d.2.b - Else if the glMemberName is not present on the GL, the GLA checks how the GL is administered.
2.D.2.B-その他のGLMEMBERNAMEがGLに存在しない場合、GLAはGLの管理方法をチェックします。
2.d.2.b.1 - If the GL is closed, the GLA checks that a registered GLO signed the request by checking that one of the names in the digital signature certificate used to sign the request matches a registered GLO.
2.D.2.B.1-GLが閉じている場合、GLAは、リクエストに署名するために使用されるデジタル署名証明書の名前の1つが登録GLOと一致することを確認して、登録GLOがリクエストに署名したことをチェックします。
2.d.2.b.1.a - If the names do not match, the GLA returns a response indicating cMCStatusInfoExt with cMCStatus.failed and otherInfo.extendedFailInfo.SKDFailInfo value of noGLONameMatch. Additionally, a signingTime attribute is included with the response.
2.D.2.B.1.A-名前が一致しない場合、GLAはcmcStatus.failedおよびotherinfo.extendedfailinfo.skdfailinfo noglonamematchのcmcstatusinfoextを示す応答を返します。さらに、署名時間属性が応答に含まれています。
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はcmcstatus.failedおよびotherinfo.extendedfailinfo.skdfailinfoのgloへの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).
さらに、署名時間属性が応答に含まれています。GLAがCMCSTATUSINFOEXT.CMCSTATUS.FAILED応答を返さない場合、GLAはGLProvideCert要求を発行します（セクション4.10を参照）。
2.d.2.b.1.b.2 - Else if the member's certificate verifies, the GLA returns a cMCStatusInfoExt indicating cMCStatus.success and a signingTime attribute (2 in Figure 5). The GLA also takes administrative actions, which are beyond the scope of this document, to add the member to the GL stored on the GLA. The GLA also distributes the shared KEK to the member via the mechanism described in Section 5.
2.D.2.B.1.B.2-メンバーの証明書が検証された場合、GLAはCMCSTATUS.SUCCESSとSINGINGTIME属性を示すCMCSTATUSINFOEXTを返します（図5の2）。GLAはまた、このドキュメントの範囲を超えた管理措置を講じて、GLAに保存されているGLにメンバーを追加します。GLAは、セクション5で説明したメカニズムを介して、共有Kekをメンバーに配布します。
2.d.2.b.1.b.2.a - The GLA applies confidentiality to the response by encapsulating the SignedData.PKIData in an EnvelopedData if the request was encapsulated in an EnvelopedData (see Section 3.2.1.2).
2.D.2.B.1.B.2.A-GLAは、リクエストが封筒にカプセル化されている場合、封筒のSignedData.pkidataを封筒にカプセル化することにより、応答に機密性を適用します（セクション3.2.1.2を参照）。
2.d.2.b.1.b.2.b - The GLA can also optionally apply another SignedData over the EnvelopedData (see Section 3.2.1.2).
2.D.2.B.1.B.2.B-GLAは、オプションでエンベロープドタに別の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または将来のメンバーがリクエストに署名したことをチェックします。GLOの場合、リクエストに署名するために使用される証明書の名前の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はcmcStatus.failedおよびotherinfo.skdfailinfo value of nospamのcmcstatusinfoextを示す応答を返します。さらに、署名時間属性が応答に含まれています。
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.2.2.B.1-メンバーの証明書を検証できない場合、GLAはcmcstatus.failedおよびotherinfo.extedendedfailinfo.skdfailinfo value of invalidcertのcmcstatusinfoextを示す応答を返すことができます。さらに、署名時間属性が応答に含まれています。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はCMCSTATUS.SUCCESSとGLOへの署名時間属性を示すCMCSTATUSINFOEXTを返す必要があります（図5の2）。GLAはまた、このドキュメントの範囲を超えた管理措置を講じて、GLAに保存されているGLにメンバーを追加します。GLAはまた、セクション5で説明したメカニズムを介して共有Kekをメンバーに配布します。GLポリシーは、GLメンバーのアドレスがGLメンバーの証明書に含まれることを義務付けている場合があります。
2.d.2.b.2.b.2.a - The GLA applies confidentiality to the response by encapsulating the SignedData.PKIData in an EnvelopedData if the request was encapsulated in an EnvelopedData (see Section 3.2.1.2).
2.D.2.2.2.B.2.A- GLAは、リクエストが封筒にカプセル化されている場合、封筒のsigneddata.pkidataを封筒にカプセル化することにより、応答に機密性を適用します（セクション3.2.1.2を参照）。
2.d.2.b.2.b.2.b - The GLA can also optionally apply another SignedData over the EnvelopedData (see Section 3.2.1.2).
2.D.2.B.2.B.2.B-GLAは、オプションで封筒に別の署名Dataを適用することもできます（セクション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はGladdMemberリクエスト（セクション3.2.3を参照）を登録GLO（B {a}を図5のB {a}）に転送します。複数の登録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は、元のリクエストが封筒にカプセル化されている場合、SignedData.pkidataを封筒にカプセル化することにより、転送要求に機密性を適用します（セクション3.2.1.2を参照）。
2.d.2.b.2.c.2 - The GLA can also optionally apply another SignedData over the EnvelopedData (see Section 3.2.1.2).
2.D.2.B.2.C.2-GLAは、オプションで封筒に別の署名Dataを適用することもできます（セクション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または見込みメンバーのいずれかがリクエストに署名したことをチェックします。GLOの場合、リクエストに署名するために使用される証明書の名前の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はcmcStatus.failedおよびotherinfo.extendedfailinfo.skdfailinfo valuation with cmcstatus.failedを含むcmcstatusinfoextを示す応答を返します。さらに、署名時間属性が応答に含まれています。
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 Section 4.10) to either the GLO or prospective member depending on where the request originated.
2.D.2.B.3.B.1-メンバーの証明書を検証できない場合、GLAはcmcStatus.failedおよびotherinfo.extendedfailinfo.skdfailinfoのinvalidcertの値と署名時の属性のいずれかのcmcstatusinfoextを示す応答を返すことができます。リクエストが発生した場所に応じて、GLOまたは見込みメンバー。GLAがCMCSTATUS.FAILED応答を返さない場合、GLAはGLProvideCert要求（セクション4.10を参照）を発行します（リクエストが発生した場所に応じてGLOまたは将来のメンバーのいずれかになります。
2.d.2.b.3.b.2 - Else if the member's certificate verifies, the GLA returns a cMCStatusInfoExt indicating cMCStatus.success and a signingTime attribute to the GLO (2 in Figure 5) if the GLO signed the request and to the GL member (3 in Figure 5) if the GL member signed the request. The GLA also takes administrative actions, which are beyond the scope of this document, to add the member to the GL stored on the GLA. The GLA also distributes the shared KEK to the member via the mechanism described in Section 5.
GLメンバーがリクエストに署名した場合、GLメンバー（図5の3）に。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は、リクエストが封筒にカプセル化されている場合、封筒のSignedData.pkidataを封筒にカプセル化することにより、応答に機密性を適用します（セクション3.2.1.2を参照）。
2.d.2.b.3.b.2.b - The GLA can also optionally apply another SignedData over the EnvelopedData (see Section 3.2.1.2).
2.D.2.B.3.B.2.B-GLAは、オプションで封筒に別の署名Dataを適用することもできます（セクション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は署名時間をチェックし、GLA署名を検証します。追加のsignedDataおよび/または封筒が応答をカプセル化する場合（セクション3.2.1.2または3.2.2を参照）、GLOは外側の署名を検証し、/または最も内側の署名dataの署名を検証する前に外側の層を復号化します。
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-署名時間属性値がローカルで受け入れられた時間枠内にない場合、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-署名処理が継続され、署名が確認された場合、GLOは、応答に署名するために使用される証明書の名前の1つがGLの名前と一致することをチェックします。
3.b.1 - If the name of the GL does not match the name present in the certificate used to sign the message, the GLO should not believe the response.
3.B.1 -GLの名前がメッセージの署名に使用される証明書に存在する名前と一致しない場合、GLOは応答を信じるべきではありません。
3.b.2 - Else if the name of the GL matches the name present in the certificate and:
3.B.2-その他のGLの名前が証明書に存在する名前と一致する場合、
3.b.2.a - If the signatures verify and the response is cMCStatusInfoExt indicating cMCStatus.success, the GLA has added the member to the GL. If the member was added to a managed list and the original request was signed by the member, the GLO sends a cMCStatusInfoExt.cMCStatus.success and a signingTime attribute to the GL member.
3.b.2.a-署名が検証され、応答がcmcstatus.successを示すcmcstatusinfoextである場合、GLAはメンバーをGLに追加しました。メンバーがマネージドリストに追加され、元のリクエストがメンバーによって署名された場合、GLOはCMCSTATUSINFOEXT.CMCSTATUS.SUCCESSとGLメンバーへの署名時間属性を送信します。
3.b.2.b - Else if the GLO received a cMCStatusInfoExt.cMCStatus.failed with any reason, the GLO can reattempt to add the member to the GL using the information provided in the response.
3.B.2.B-それ以外の場合、GLOがCMCSTATUSINFOEXT.CMCSTATUSを受け取った場合、何らかの理由でフェイルした場合、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応答を受け取ると、将来のメンバーは署名時間をチェックし、GLA署名またはGLO署名を検証します。追加のsignedDataおよび/または封筒が応答をカプセル化する場合（セクション3.2.1.2または3.2.2を参照）、GLOは外側の署名を検証し、/または最も内側の署名dataの署名を検証する前に外側の層を復号化します。
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-署名時間属性値がローカルに受け入れられた時間枠内にない場合、将来のメンバーは、cmcstatus.failedおよびotherinfo.failinfo.badtimeを示す応答を返すことができます。
4.b - Else if signature processing continues and if the signatures verify, the GL member checks that one of the names in the certificate used to sign the response matches the name of the GL.
4.B-署名処理が継続され、署名が確認された場合、GLメンバーは、応答に署名するために使用される証明書の名前の1つがGLの名前と一致することをチェックします。
4.b.1 - If the name of the GL does not match the name present in the certificate used to sign the message, the GL member should not believe the response.
4.B.1 -GLの名前がメッセージの署名に使用される証明書に存在する名前と一致しない場合、GLメンバーは応答を信じるべきではありません。
4.b.2 - Else if the name of the GL matches the name present in the certificate and:
4.B.2-その他のGLの名前が証明書に存在する名前と一致する場合、
4.b.2.a - If the signatures verify, the prospective member has been added to the GL.
4.B.2.A-署名が検証された場合、将来のメンバーがGLに追加されています。
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メンバーは、signeddata.pkidata.control sequence.gladddmemberリクエストをGLAに送信します（図5のA）。将来のGLメンバーには、GLNameのGL名、glmember.glmembernameの名前、glmember.glmemberaddressのアドレス、およびglmember.certificates.pkcの暗号化証明書が含まれます。将来のGLメンバーには、glmember.certificates.acの暗号化証明書に関連付けられた属性証明書と、glmember.certificates.certpathの暗号化と属性証明書に関連付けられた認証パスを含めることもできます。将来のメンバーは、このリクエストに署名時間属性も含める必要があります。
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メンバーは、封筒の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メンバーは、オプションでエンベロープドタに別の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は署名時間をチェックし、最も内側のsigneddata.pkidataの将来のGLメンバー署名と外層のGLA署名を検証します。封筒が最も内側のレイヤーをカプセル化する場合（セクション3.2.1.2または3.2.2を参照）、GLOは、最も内側のシグネダタの署名を確認する前に外側の層を復号化します。
Note: For cases where the GL is closed and either a) a prospective member sends directly to the GLO or b) the GLA has mistakenly forwarded the request to the GLO, the GLO should first determine whether to honor the request.
注：GLが閉じていて、a）見込み客がGLOに直接送信するか、b）GLAがGLOに誤って転送した場合、GLOは最初にリクエストを尊重するかどうかを決定する必要があります。
3.a - If the signingTime attribute value is not within the locally accepted time window, the GLO MAY return a response indicating cMCStatus.failed and otherInfo.failInfo.badTime.
3.a-署名時間属性値がローカルに受け入れられた時間枠内にない場合、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が確認するためにGLOがチェックして、リクエストに署名するために使用される名前の1つが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はsignedData.pkiresponse.ControlSequenceメッセージをcmcstatusinfoext.cmcstatus.failedで将来のメンバーに送り返します。これにより、人々が許可なしに人々をGLSに追加することを妨げます。さらに、署名時間属性が応答に含まれています。
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はsignedData.pkireSponse.ControlSequenceメッセージをCMCSTATUSINFOEXT.CMCTATUS.FAILEDで将来のメンバーに戻すことができます。cmcstatus.statusstringで拒否されました。さらに、署名時間属性が応答に含まれています。
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 SignedData.PKIData.controlSequence.glProvideCert message to the prospective member requesting a new encryption certificate (see Section 4.10).
3.B.2.B.1-メンバーの証明書を検証できない場合、GLOはsignedData.pkiresponse.Controlの順序をcmcstatusinfoext.cmctatus.failedを使用して将来のメンバーに戻します。統一。さらに、署名時間属性が応答に含まれています。GLOがCMCSTATUSINFOEXT応答を返さない場合、GLOはsignedData.pkidata.control sequence.glprovidecertメッセージを、新しい暗号化証明書を要求する見込みメンバーに送信します（セクション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はGladDMemberリクエスト（セクション3.2.5を参照）をGLA（図5の1）に再サビットします。
3.b.2.b.2.a - The GLO applies confidentiality to the new GLAddMember request by encapsulating the SignedData.PKIData in an EnvelopedData if the initial request was encapsulated in an EnvelopedData (see Section 3.2.1.2).
3.B.2.B.2.A- GLOは、初期リクエストが封筒にカプセル化されている場合、SignedData.pkidataを封筒にカプセル化することにより、新しいGladdMemberリクエストに機密性を適用します（セクション3.2.1.2を参照）。
3.b.2.b.2.b - The GLO can also optionally apply another SignedData over the EnvelopedData (see Section 3.2.1.2).
3.B.2.B.2.B- GLOは、オプションでエンベロープドタに別の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.
GLSからメンバーを削除するには、GLOまたは削除されるメンバーのいずれかを使用します。GLAはGLOを処理し、メンバーが独自の削除を要求するメンバーはリクエストを異なります。GLOはいつでもリクエストを送信してGLからメンバーを削除することができ、GLAは登録GLOからのリクエストが確認されることを確認したら、メンバーを削除する必要があります。メンバーがリクエストを送信する場合、GLAはGLの管理方法を決定する必要があります。GLOが最初にGLを構成したとき、GLを管理、管理、または閉じているように設定しました（セクション3.1.1を参照）。管理されていない場合、GLAは単にメンバーの要求を処理するだけです。管理されたケースでは、GLAはレビューのためにメンバーからGLOにリクエストを転送します。GLに複数のGLOがある場合、リクエストが転送されるGLOは、このドキュメントの範囲を超えています。GLOはリクエストをレビューし、それを拒否するか、改革されたリクエストをGLAに提出します。閉じた場合、GLAはメンバーからのリクエストを受け入れません。次のセクションでは、GLO（S）、GLA、およびGLメンバーの処理について、GLOまたは削除を希望するメンバーからのリクエストがどこに発生したかに応じて説明します。図6は、3つのオプションのプロトコル相互作用を示しています。エラーメッセージは描かれていないことに注意してください。さらに、オプションのTransactionID、Sendernonce、およびReciintNonce 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で保護されたデータを復号化することができ、引き続きRekeysを受け取ります。管理されていないリストの場合、削除することを要求するメンバーが別の名前でGLにそれ自体を追加していないという保証がないため、グループRekeに意味がありません。管理されたGLSおよび閉じたGLSの場合、GLOは削除されているメンバーがGLに2回ないことを確認するための措置を講じる必要があります。これを確保した後、グループメンバーから送信されたトラフィックの機密性を維持するために、管理および閉じた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に別のGldeleTememberリクエストを使用して、signeddata.pkidata.control sequenceをGLAに送信します（図6の1）。GLOには、GLNAMEにGL名とGLMEMBERTODELETEにメンバーの名前を含める必要があります。メンバーが削除されているGLが閉じたまたは管理されているGLである場合、GLOはGlrekeyリクエストを生成し、GldeleTememberリクエストに含める必要があります（セクション4.5を参照）。GLOには、このリクエストに署名時間属性も含める必要があります。
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は、封筒の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は、オプションで封筒に別の署名dataを適用することもできます（セクション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は署名時間属性をチェックし、最も内側のsigneddata.pkidataの署名を検証します。追加のsignedDataおよび/または封筒が要求をカプセル化する場合（セクション3.2.1.2または3.2.2を参照）、GLAは外側の署名を検証し、/または最も内側の署名dataの署名を検証する前に外側の層を復号化します。
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-署名時間属性値がローカルで受け入れられた時間枠内にない場合、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およびその他のInfo.failinfo.badmessagecheckを示すCMCSTATUSINFOEXT応答を返します。さらに、署名時間属性が応答に含まれています。
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はGLAにGLAに保存されているGLNAMEと一致することを確認することにより、GLがGLAによってサポートされていることを確認します。
2.c.1 - If the glName is not supported by the GLA, the GLA returns a response indicating cMCStatusInfoExt with cMCStatus.failed and otherInfo.extendedFailInfo.SKDFailInfo value of invalidGLName. Additionally, a signingTime attribute is included with the response.
2.C.1-GLNAMEがGLAによってサポートされていない場合、GLAはcmcStatus.failedおよびotherinfo.extendedfailinfo.skdfailinfoを使用してcmcstatusinfoextを示す応答を返します。さらに、署名時間属性が応答に含まれています。
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およびotherinfo.extendedfailinfo.skdfailinfoのcmcstatusinfoextを示す応答を返します。さらに、署名時間属性が応答に含まれています。
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はcmcStatus.failedおよびその他のcmcstatusinfoextを示す応答を返します。さらに、署名時間属性が応答に含まれています。
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とSINGINGTIME属性を返します（図5の2）。GLAはまた、このドキュメントの範囲を超えた管理措置を取得し、GLAに保存されたGLでメンバーを削除します。セクション5に記載されているように、GLも再キーにする必要があることに注意してください。
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は、リクエストが封筒にカプセル化されている場合、封筒のSignedData.pkidataをカプセル化することにより、応答に機密性を適用します（セクション3.2.1.2を参照）。
2.c.2.b.1.b.2 - The GLA can also optionally apply another SignedData over the EnvelopedData (see Section 3.2.1.2).
2.C.2.B.1.B.2-GLAは、オプションで封筒に別の署名Dataを適用することもできます（セクション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または将来のメンバーがリクエストに署名したことをチェックします。GLOの場合、リクエストに署名するために使用される証明書の名前の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はcmcstatus.failedおよびotherinfo.skdfailinfo value of nospamのcmcstatusinfoextを示す応答を返します。さらに、署名時間属性が応答に含まれています。
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とSINGINGTIME属性を返します（図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は、リクエストが封筒にカプセル化されている場合、SignedData.pkidataを封筒にカプセル化することにより、応答に機密性を適用します（セクション3.2.1.2を参照）。
2.c.2.b.2.b.2 - The GLA can also optionally apply another SignedData over the EnvelopedData (see Section 3.2.1.2).
2.C.2.B.2.B.2-GLAは、オプションで封筒に別の署名Dataを適用することもできます（セクション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はGldeleTememberの要求（図6のB {a}）にGldeleTememberの要求（セクション3.2.3を参照）を転送します。複数の登録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は、リクエストが封筒にカプセル化されている場合、SignedData.pkidataを封筒にカプセル化することにより、転送要求に機密性を適用します（セクション3.2.1.2を参照）。
2.c.2.b.2.c.2 - The GLA can also optionally apply another SignedData over the EnvelopedData (see Section 3.2.1.2).
2.C.2.B.2.C.2-GLAは、オプションで封筒に別の署名Dataを適用することもできます（セクション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または見込みメンバーのいずれかがリクエストに署名したことをチェックします。GLOの場合、リクエストに署名するために使用される証明書の名前の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はcmcStatus.failedおよびotherinfo.extendedfailinfo.skdfailinfo nospamのcmcstatusinfoextを示す応答を返します。さらに、署名時間属性が応答に含まれています。
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またはメンバーのいずれかである場合、GLAはGLOの場合、GLO（図6の2）へのcmcstatusinfoext.cmcstatus.success.success.success.success.cmcstatusinfoext.cmcstatusを返します。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は、リクエストが封筒にカプセル化されている場合、封筒のSignedData.pkidataを封筒にカプセル化することにより、応答に機密性を適用します（セクション3.2.1.2を参照）。
2.c.2.b.3.b.2 - The GLA can also optionally apply another SignedData over the EnvelopedData (see Section 3.2.1.2).
2.C.2.B.3.B.2-GLAは、オプションでエンベロープドタに別の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は署名時間をチェックし、GLA署名を検証します。追加のsignedDataおよび/または封筒が応答をカプセル化する場合（セクション3.2.1.2または3.2.2を参照）、GLOは外側の署名を検証し、/または最も内側の署名dataの署名を検証する前に外側の層を復号化します。
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-署名時間属性値がローカルで受け入れられた時間枠内にない場合、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-署名処理が継続され、署名が検証した場合、GLOは、応答に署名するために使用される証明書の名前の1つがGLの名前と一致することをチェックします。
3.b.1 - If the name of the GL does not match the name present in the certificate used to sign the message, the GLO should not believe the response.
3.B.1 -GLの名前がメッセージの署名に使用される証明書に存在する名前と一致しない場合、GLOは応答を信じるべきではありません。
3.b.2 - Else if the name of the GL matches the name present in the certificate and:
3.B.2-その他のGLの名前が証明書に存在する名前と一致する場合、
3.b.2.a - If the signatures verify and the response is cMCStatusInfoExt.cMCStatus.success, the GLO has deleted the member from the GL. If member was deleted from a managed list and the original request was signed by the member, the GLO sends a cMCStatusInfoExt.cMCStatus.success and a signingTime attribute to the GL member.
3.B.2.A-署名が検証され、応答がCMCSTATUSINFOEXT.CMCSTATUS.SUCCESSの場合、GLOはGLからメンバーを削除しました。メンバーがマネージドリストから削除され、元のリクエストがメンバーによって署名された場合、GLOはCMCSTATUSINFOEXT.CMCSTATUS.SUCCESSとGLメンバーへの署名時間属性を送信します。
3.b.2.b - Else if the GLO received a cMCStatusInfoExt.cMCStatus.failed with any reason, the GLO may reattempt to delete the member from the GL using the information provided in the response.
3.B.2.B-それ以外の場合、GLOがCMCSTATUSINFOEXT.CMCSTATUSを受け取った場合、何らかの理由で偽造された場合、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応答を受信すると、メンバーは署名時間をチェックし、GLA署名またはGLOの署名を検証します。追加のsignedDataおよび/または封筒が応答をカプセル化する場合（セクション3.2.1.2または3.2.2を参照）、GLOは外側の署名を検証し、/または最も内側の署名dataの署名を検証する前に外側の層を復号化します。
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-署名時間属性値がローカルに受け入れられた時間枠内にない場合、将来のメンバーは、cmcstatus.failedおよびotherinfo.failinfo.badtimeを示す応答を返すことができます。
4.b - Else if signature processing continues and if the signatures verify, the GL member checks that one of the names in the certificate used to sign the response matches the name of the GL.
4.B-署名処理が継続され、署名が確認された場合、GLメンバーは、応答に署名するために使用される証明書の名前の1つがGLの名前と一致することをチェックします。
4.b.1 - If the name of the GL does not match the name present in the certificate used to sign the message, the GL member should not believe the response.
4.B.1 -GLの名前がメッセージの署名に使用される証明書に存在する名前と一致しない場合、GLメンバーは応答を信じるべきではありません。
4.b.2 - Else if the name of the GL matches the name present in the certificate and:
4.B.2-その他のGLの名前が証明書に存在する名前と一致する場合、
4.b.2.a - If the signature(s) verify, the member has been deleted from the GL.
4.B.2.A-署名が確認された場合、メンバーは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を受け取った場合、何らかの理由でフェイルした場合、メンバーは応答に記載されている情報を使用して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-メンバーは、signeddata.pkidata.control sequence.gldeletememberのリクエストをGLAに送信します（図6のA）。メンバーには、GLNAMEのGLの名前とGLMEMBERTODELETEのメンバー自身の名前が含まれています。GLメンバーには、このリクエストに署名時間属性も含める必要があります。
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-メンバーは、封筒の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-メンバーは、オプションで封筒に別の署名dataを適用することもできます（セクション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は署名時間をチェックし、最も内側のsigneddata.pkidataのメンバー署名と外側の層のGLA署名を検証します。封筒が最も内側のレイヤーをカプセル化する場合（セクション3.2.1.2または3.2.2を参照）、GLOは、最も内側のシグネダタの署名を確認する前に外側の層を復号化します。
Note: For cases where the GL is closed and either (a) a prospective member sends directly to the GLO or (b) the GLA has mistakenly forwarded the request to the GLO, the GLO should first determine whether to honor the request.
注：GLが閉じており、（a）将来のメンバーがGLOに直接送信する場合、または（b）GLAがリクエストをGLOに誤って転送した場合、GLOは最初にリクエストを尊重するかどうかを決定する必要があります。
3.a - If the signingTime attribute value is not within the locally accepted time window, the GLO MAY return a response indicating cMCStatus.failed and otherInfo.failInfo.badTime and a signingTime attribute.
3.a-署名時間属性値がローカルで受け入れられた時間枠内にない場合、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およびその他のInfo.failinfo.badmessagecheckを示す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はSignedData.pkiresponse.ControlSequenceメッセージをcmcstatusinfoext.cmctatus.failedで将来のメンバーに送り返します。これにより、人々が許可なしに人々をGLSに追加することを妨げます。さらに、署名時間属性が応答に含まれています。
3.c.2 - Else if the names match, the GLO resubmits the glDeleteMember request (see Section 3.2.5) to the GLA (1 in Figure 6). The GLO makes sure the glMemberName is already on the GL. The GLO also generates a glRekey request and include it with the GLDeleteMember request (see Section 4.5).
3.C.2-その他の名前が一致する場合、GLOはGLDELETEMEMBERリクエスト（セクション3.2.5を参照）をGLA（図6の1）に再サビングします。GLOは、GLMemberNameがすでにGL上にあることを確認します。GLOはまた、Glrekeyリクエストを生成し、GldeleTememberリクエストに含めます（セクション4.5を参照）。
3.c.2.a - The GLO applies confidentiality to the new GLDeleteMember request by encapsulating the SignedData.PKIData in an EnvelopedData if the initial request was encapsulated in an EnvelopedData (see Section 3.2.1.2).
3.C.2.A- GLOは、初期リクエストが封筒にカプセル化されている場合、SignedData.pkidataを封筒にカプセル化することにより、新しいGldeleTememberリクエストに機密性を適用します（セクション3.2.1.2を参照）。
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は、オプションで封筒に別の署名dataを適用することもできます（セクション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または管理されたGLからメンバーが削除されたとき。この場合、GldeleTememberを含むpkidata.control sequenceは、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.Control sequenceには、GLAのリクエストが含まれているか、GLAに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 Rekeyを制御する場合、GLAは新しい共有Kekを配布する必要があると仮定するのではなく、代わりにGlrekeyメッセージを待ちます。
-- If the GLA controls the GL rekey, the GLA should initiate a glKey message as specified in Section 5.
--GLAがGL Rekeを制御する場合、GLAはセクション5で指定されているようにGLKEYメッセージを開始する必要があります。
If the generationCounter (see Section 3.1.1) is set to a value greater than one (1) and the GLO controls the GL rekey, the GLO may generate a glRekey any time before the last shared KEK has expired. To be on the safe side, the GLO ought to request a rekey one (1) duration before the last shared KEK expires.
GenerationCounter（セクション3.1.1を参照）が1より大きい値に設定されている場合（1）、GLOがGL Rekeyを制御する場合、GLOは最後の共有Kekの有効期限が切れる前にいつでもGlrekeyを生成する可能性があります。安全な側にいるために、GLOは、最後に共有されたKekが期限切れになる前のReke（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 Rekeを開始できる唯一のエンティティです。GLOは、Rekeysを制御するかどうか、GLAがGLに共有Kekを割り当てたときにRekeysを制御するかどうかを示しました（セクション3.1.1を参照）。GLOはいつでもGL Rekeyを開始します。GLAは、共有Kekの有効期限（有効期限が実装決定である）の有効期限の前にGLを自動的に再キーするように構成できます。GLAは、侵害されたGLSを自動的に再キーに再キーすることもできますが、これはセクション5で説明されています。図7は、GL Rekeを要求するプロトコルの相互作用を示しています。エラーメッセージは描かれていないことに注意してください。さらに、オプションのTransactionID、Sendernonce、およびReciintNonce CMC制御属性の動作は、これらの手順では対処されていません。
+-----+ 1 2,A +-----+
| GLA | <-------> | GLO |
+-----+ +-----+
Figure 7 - GL Rekey Request
図7 -GL Rekeyリクエスト
The process for GLO initiated glRekey requests is as follows:
GLOを開始したGlrekeyリクエストのプロセスは次のとおりです。
1 - The GLO sends a SignedData.PKIData.controlSequence.glRekey request to the GLA (1 in Figure 7). The GLO includes the glName. If glAdministration and glKeyNewAttributes are omitted then there is no change from the previously registered GL values for these fields. If the GLO wants to force a rekey for all outstanding shared KEKs, it includes the glRekeyAllGLKeys set to TRUE. The GLO MUST also include a signingTime attribute with this request.
1-GLOは、signeddata.pkidata.control sequence.glrekeyリクエストをGLAに送信します（図7の1）。GLOにはGlnameが含まれます。gladministrationとglkeynewattributesが省略されている場合、これらのフィールドの以前に登録されたGL値から変更はありません。GLOがすべての未解決の共有KeksにRekeyを強制したい場合、GlrekeyallglkeysがTrueに設定されています。GLOには、このリクエストに署名時間属性も含める必要があります。
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は、封筒の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は、オプションで封筒に別の署名dataを適用することもできます（セクション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は署名時間をチェックし、最も内側のsigneddata.pkidataの署名を検証します。追加のsignedDataおよび/または封筒が要求をカプセル化する場合（セクション3.2.1.2または3.2.2を参照）、GLAは外側の署名を検証し、/または最も内側の署名dataの署名を検証する前に外側の層を復号化します。
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-署名時間属性値がローカルで受け入れられた時間枠内にない場合、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およびその他のInfo.failinfo.badmessagecheckを示すCMCSTATUSINFOEXT応答を返します。さらに、署名時間属性が応答に含まれています。
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はGLAにGLAに保存されているGLNAMEと一致することを確認することにより、GLが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はcmcStatus.failedおよびotherinfo.extendedfailinfo.skdfailinfo値のcmcstatusinfoextを示す応答を返します。さらに、署名時間属性が応答に含まれています。
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はcmcStatus.failedおよびotherinfo.extendedfailinfo.skdfailinfo noglonamematchの値を使用してcmcstatusinfoextを示す応答を返します。さらに、署名時間属性が応答に含まれています。
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-リクエストエダルゴリズムの新しい値がサポートされていない場合、GLAはcmcstatus.failedおよびotherinfo.extendedfailinfo.skdfailinfo unsupportedalgorithmのcmcstatusinfoextを示す応答を返します。さらに、署名時間属性が応答に含まれています。
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.extedendedfailinfo.skdfailinfo値のcmcstatusinfoextを示す応答を返します。サポートされていない。さらに、署名時間属性が応答に含まれています。
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-それ以外の場合は、GLAが開示を望まない他の理由でGLがサポートできない場合、GLAはCMCSTATUS.FAILEDおよびEXTENDEDEDFAILINFO.SKDFAILINFOを使用してCMCSTATUS.FAILEDおよびotherInfo.skdfailInfoを使用してcmcstatusinfoextを示す応答を返します。さらに、署名時間属性が応答に含まれています。
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-それ以外の場合は、新しい要求の要求糖と持続時間がサポート可能である場合、またはGlnewKeyattributesが省略されている場合、GLAはCMCSTATUSINFOEXT.CMCSTATUS.SUCCESSおよびSIGINGTIME属性を返します（図7の2）。GLAはまた、GLKEYメッセージを使用して、Rekey共有Kekを配布します（セクション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は、リクエストが封筒にカプセル化されている場合、封筒のsignedData.pkidataを封筒にカプセル化することにより、応答に機密性を適用します（セクション3.2.1.2を参照）。
2.c.2.b.4.b - The GLA can also optionally apply another SignedData over the EnvelopedData (see Section 3.2.1.2).
2.C.2.B.4.B-GLAは、オプションでエンベロープドタに別の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は署名時間をチェックし、GLA署名を検証します。追加のsignedDataおよび/または封筒が転送された応答をカプセル化する場合（セクション3.2.1.2または3.2.2を参照）、GLOは外側の署名を検証し、/または最も内側の署名Dataの署名を検証する前に転送された応答を復号化します。
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-署名時間属性値がローカルに受け入れられた時間枠内にない場合、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-署名処理が継続され、署名が確認された場合、GLOは、応答に署名するために使用される証明書の名前の1つがGLの名前と一致することをチェックします。
3.b.1 - If the name of the GL does not match the name present in the certificate used to sign the message, the GLO should not believe the response.
3.B.1 -GLの名前がメッセージの署名に使用される証明書に存在する名前と一致しない場合、GLOは応答を信じるべきではありません。
3.b.2 - Else if the name of the GL matches the name present in the certificate and:
3.B.2-その他のGLの名前が証明書に存在する名前と一致する場合、
3.b.2.a - If the signatures verify and the response is cMCStatusInfoExt.cMCStatus.success, the GLO has successfully rekeyed the GL.
3.B.2.A-署名が検証され、応答がCMCSTATUSINFOEXT.CMCSTATUS.SUCCESSである場合、GLOはGLを正常に再誘発しました。
3.b.2.b - Else if the GLO received a cMCStatusInfoExt.cMCStatus.failed with any reason, the GLO can reattempt to rekey the GL using the information provided in the response.
3.B.2.B-それ以外の場合、GLOがCMCSTATUSINFOEXT.CMCSTATUSを受け取った場合、何らかの理由で偽造された場合、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がGLの再キーリングを担当している場合、GLAはGLKEYメッセージを自動的に発行します（セクション5を参照）。さらに、GLAはCMCSTATUSINFOEXTを生成してGLに成功したRekeyが発生したことを示します。GLAを開始したRekeyのプロセスは次のとおりです。
1 - The GLA generates for all GLOs a SignedData.PKIData.controlSequence.cMCStatusInfoExt.cMCStatus success and includes a signingTime attribute (A in Figure 7).
1-GLAは、すべてのGLOに対してSignedData.pkidata.ControlSequence.cmcstatusinfoext.cmcstatusの成功を生成し、署名時間属性（図7のA）を含みます。
1.a - The GLA can optionally apply confidentiality to the request by encapsulating the SignedData.PKIData in an EnvelopedData (see Section 3.2.1.2).
1.a- GLAは、封筒の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は、オプションでエンベロープドタに別の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は署名時間をチェックし、GLA署名を検証します。追加のsignedDataおよび/または封筒が転送された応答をカプセル化する場合（セクション3.2.1.2または3.2.2を参照）、GLOは外側の署名を検証する必要があります。
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-署名時間属性値がローカルで受け入れられた時間枠内にない場合、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-署名処理が継続し、署名が確認された場合、GLOが応答に署名するために使用される証明書の名前の1つがGLの名前と一致することを確認します。
2.b.1 - If the name of the GL does not match the name present in the certificate used to sign the message, the GLO ought not believe the response.
2.B.1 -GLの名前がメッセージの署名に使用される証明書に存在する名前と一致しない場合、GLOは応答を信じてはなりません。
2.b.2 - Else if the name of the GL does match the name present in the certificate and the response is cMCStatusInfoExt.cMCStatus.success, the GLO knows the GLA has successfully rekeyed the GL.
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メンバーシップが大きくなると、1つのGLOで管理されたGLSおよび閉じたGLSの管理が困難になる可能性があります。ワークロードの分散をサポートするために、GLASはGLSを複数のGLOで管理することをサポートします。GladDownerおよびGlremoveOwnerメッセージは、登録GLOの追加と削除をサポートするように設計されています。図8は、GladDownerおよびGlremoveOwnerメッセージと結果の応答メッセージを送信するためのプロトコルの相互作用を示しています。エラーメッセージが表示されないことに注意してください。さらに、オプションのTransactionID、Sendernonce、およびReciintNonce CMC制御属性の動作は、これらの手順では対処されていません。
+-----+ 1 2 +-----+
| GLA | <-------> | GLO |
+-----+ +-----+
Figure 8 - GLO Add and Delete Owners
図8-所有者を追加および削除します
The process for glAddOwner and glDeleteOwner is as follows:
GladDodererと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は、signeddata.pkidata.control sequence.gladdownerまたはglremoveownerリクエストをGLAに送信します（図8の1）。GLOには、GLNAMEのGL名と、GLOの名前とアドレスがそれぞれGlowonnameとGlownerAddressが含まれています。GLOには、このリクエストに署名時間属性も含める必要があります。
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は、封筒の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は、オプションで封筒に別の署名dataを適用することもできます（セクション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 -GladDodererまたはGlremoveOwnerのリクエストを受け取ると、GLAは署名時間をチェックし、GLO署名を検証します。追加のsignedDataおよび/または封筒が要求をカプセル化する場合（セクション3.2.1.2または3.2.2を参照）、GLAは外側の署名を検証し、/または最も内側の署名dataの署名を検証する前に外側の層を復号化します。
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-署名時間属性値がローカルで受け入れられた時間枠内にない場合、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およびその他のInfo.failinfo.badmessagecheckを示すCMCSTATUSINFOEXT応答を返します。さらに、署名時間属性が応答に含まれています。
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はGLNAMEがGLAに保存されているGLNAMEと一致することを確認することにより、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はcmcStatus.failedおよびotherinfo.extendedfailinfo.skdfailinfoを使用してcmcstatusinfoextを示す応答を返します。さらに、署名時間属性が応答に含まれています。
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または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はcmcStatus.failedおよびotherinfo.extendedfailinfo.skdfailinfo noglonamematchの値を使用してcmcstatusinfoextを示す応答を返します。さらに、署名時間属性が応答に含まれています。
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とSINGINGTIME属性を返します（図4の2）。GLAはまた、GladDownerの場合に新しいグラスermeNameをGLに関連付けるか、GLRemoveOwnerのケースでGLで古いグラス名を分離するための管理措置を講じます。
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は、リクエストがエンベロープドダタにカプセル化されている場合、封筒のSignedData.pkiresponseをカプセル化することにより、応答に機密性を適用します（セクション3.2.1.2を参照）。
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は、オプションでエンベロープドタに別の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は署名時間をチェックし、GLAの署名を検証します。追加のsignedDataおよび/または封筒が応答をカプセル化する場合（セクション3.2.1.2または3.2.2を参照）、GLOは外側の署名を検証し、/または最も内側の署名dataの署名を検証する前に外側の層を復号化します。
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-署名時間属性値がローカルで受け入れられた時間枠内にない場合、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-署名処理が継続され、署名が確認された場合、GLOは、応答に署名するために使用される証明書の名前の1つがGLの名前と一致することをチェックします。
3.b.1 - If the name of the GL does not match the name present in the certificate used to sign the message, the GLO should not believe the response.
3.B.1 -GLの名前がメッセージの署名に使用される証明書に存在する名前と一致しない場合、GLOは応答を信じるべきではありません。
3.b.2 - Else if the name of the GL does match the name present in the certificate and:
3.B.2-その他のGLの名前が証明書に存在する名前と一致する場合、
3.b.2.a - If the signatures verify and the response was cMCStatusInfoExt.cMCStatus.success, the GLO has successfully added or removed the GLO.
3.B.2.A-署名が検証され、応答がCMCSTATUSINFOEXT.CMCSTATUS.SUCCESSである場合、GLOはGLOを正常に追加または削除しました。
3.b.2.b - Else if the signatures verify and the response was cMCStatusInfoExt.cMCStatus.failed with any reason, the GLO can reattempt to add or delete the GLO using the information provided in the response.
3.B.2.B-署名が検証され、応答がCMCSTATUSINFOEXT.CMCSTATUS.CMCSTATUS.CMCSTATUS.CMCSTATUSINFOEXT.CMCSTATUSである場合、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メンバーとGLOはGLKCompromiseを使用して、共有Kekが妥協したことをGLAに伝えます。図9は、GLキーの妥協のプロトコル相互作用を示しています。エラーメッセージが表示されないことに注意してください。さらに、オプションのTransactionID、Sendernonce、およびReciintNonce 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:
GLメンバーのプロセスは、GLKCompromiseメッセージを開始しました。
1 - The GL member sends a SignedData.PKIData.controlSequence.glkCompromise request to the GLA (1 in Figure 9). The GL member includes the name of the GL in GeneralName. The GL member MUST also include the signingTime attribute with this request.
1 -GLメンバーは、signeddata.pkidata.controlsequence.glkcompromiseリクエストをGLAに送信します（図9の1）。GLメンバーには、一般名のGLの名前が含まれています。GLメンバーには、このリクエストに署名時間属性も含める必要があります。
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メンバーは、封筒のsigneddata.pkidataを封筒にカプセル化することにより、オプションでリクエストに機密性を適用できます（セクション3.2.1.2を参照）。GlkCompromiseは、侵害された共有Kekで生成された封筒に含めることができます。
1.b - The GL member can also optionally apply another SignedData over the EnvelopedData (see Section 3.2.1.2).
1.B- GLメンバーは、オプションで封筒に別の署名dataを適用することもできます（セクション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は署名時間をチェックし、GLメンバーの署名を検証します。追加のsignedDataおよび/または封筒が要求をカプセル化する場合（セクション3.2.1.2または3.2.2を参照）、GLAは外側の署名を検証し、/または最も内側の署名dataの署名を検証する前に外側の層を復号化します。
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-署名時間属性値がローカルで受け入れられた時間枠内にない場合、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およびその他のInfo.failinfo.badmessagecheckを示すCMCSTATUSINFOEXT応答を返します。さらに、署名時間属性が応答に含まれています。
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名がGLAに保存されているGLNAMEと一致することを確認することにより、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はcmcStatus.failedおよびotherinfo.extendedfailinfo.skdfailinfoを使用してcmcstatusinfoextを示す応答を返します。さらに、署名時間属性が応答に含まれています。
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はリクエストに署名した人をチェックします。GLOの場合、リクエストに署名するために使用される証明書の名前の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がリクエストに署名した場合、GLAはGLを再キーするためにセクション5で説明されているようにGLKEYメッセージを生成します（図9の4）。
2.c.2.b - Else if someone other than the GLO signed the request, the GLA forwards the glkCompromise message (see Section 3.2.3) to the GLO (2{1} in Figure 9). If there is more than one GLO, to which GLO the request is forwarded is beyond the scope of this document. Further processing by the GLO is discussed in Section 4.7.2.
2.C.2.B -GLO以外の誰かがリクエストに署名した場合、GLAはGLKCompromiseメッセージ（セクション3.2.3を参照）をGLO（図9の2 {1}を参照）に転送します。複数のGLOがある場合、リクエストが転送されるGLOがこのドキュメントの範囲を超えています。GLOによるさらなる処理については、セクション4.7.2で説明します。
The process for GLO initiated glkCompromise messages is as follows:
GLOを開始したGlkCompromiseメッセージのプロセスは次のとおりです。
1 - The GLO either:
1-グロのどちらか：
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- signeddata.pkidata.control sequence.glkcompromiseリクエストをGLAに送信して、GlkCompromiseメッセージ自体を生成します（図9の5）。GLOには、一般名のGLの名前が含まれています。GLOには、このリクエストに署名時間属性も含める必要があります。
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は、封筒のsigneddata.pkidataを封筒にカプセル化することにより、オプションでリクエストに機密性を適用できます（セクション3.2.1.2を参照）。GlkCompromiseは、侵害された共有Kekで生成された封筒に含めることができます。
1.a.2 - The GLO can also optionally apply another SignedData over the EnvelopedData (see Section 3.2.1.2).
1.A.2-GLOは、オプションでエンベロープドタに別の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-それ以外の場合は、署名時間をチェックし、転送されたGLKCompromiseメッセージのGLAおよびGLメンバーの署名を検証します。追加のsignedDataおよび/または封筒が要求をカプセル化する場合（セクション3.2.1.2または3.2.2を参照）、Gloは外側の署名を検証し、/または最も内側の署名dataの署名を検証する前に外側の層を復号化します。
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-署名時間属性値がローカルに受け入れられた時間ウィンドウ内にない場合、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およびその他のInfo.failinfo.badmessagecheckを示すCMCSTATUSINFOEXT応答を返します。さらに、署名時間属性が応答に含まれています。
1.b.2.a - If the signatures verify, the GLO checks that the names in the certificate match the name of the signer (i.e., the name in the certificate used to sign the GL member's request is the GL member).
1.B.2.A-署名が検証された場合、GLOは証明書の名前が署名者の名前と一致することをチェックします（つまり、GLメンバーの要求に署名するために使用される証明書の名前はGLメンバーです）。
1.b.2.a.1 - If either name does not match, the GLO ought not trust the signer and it ought not forward the message to the GLA.
1.B.2.A.1-いずれかの名前が一致しない場合、GLOは署名者を信頼するべきではなく、メッセージをGLAに転送するべきではありません。
1.b.2.a.2 - Else if the names match and the signatures verify, the GLO determines whether to forward the glkCompromise message back to the GLA (3{1} in Figure 9). Further processing by the GLA is in 2 of Section 4.7.1. The GLO can also return a response to the prospective member with cMCStatusInfoExt.cMCtatus.success indicating that the glkCompromise message was successfully received.
1.B.2.A.2-その他の名前が一致し、署名が検証された場合、GLOはGLKCompromiseメッセージをGLA（図9の3 {1}）に戻すかどうかを決定します。GLAによるさらなる処理は、セクション4.7.1の2にあります。GLOは、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メンバーはGlkRefreshメッセージを使用して、共有Kekをそれらに再配布することを要求します。図10は、GLキーリフレッシュのプロトコル相互作用を示しています。エラーメッセージが表示されないことに注意してください。さらに、オプションのTransactionID、Sendernonce、およびReciintNonce 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メンバーは、signeddata.pkidata.control sequence.glkrefreshリクエストをGLAに送信します（図10の1）。GLメンバーには、一般名のGLの名前が含まれています。GLメンバーには、このリクエストに署名時間属性も含める必要があります。
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メンバーは、封筒の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メンバーは、オプションで封筒に別の署名dataを適用することもできます（セクション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は署名時間をチェックし、GLメンバーの署名を検証します。追加のsignedDataおよび/または封筒が要求をカプセル化する場合（セクション3.2.1.2または3.2.2を参照）、GLAは外側の署名を検証し、/または最も内側の署名dataの署名を確認する前に外側の層を復号化します。
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-署名時間属性値がローカルで受け入れられた時間枠内にない場合、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およびその他のInfo.failinfo.badmessagecheckを示すCMCSTATUSINFOEXT応答を返します。さらに、署名時間属性が応答に含まれています。
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はGLGENERALNAMEがGLAに保存されているGLNAMEと一致することを確認することにより、GLがサポートされていることを確認します。
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およびotherinfo.extedendedfailinfo.skdfailinfoを使用してcmcstatusinfoextを示す応答を返します。さらに、署名時間属性が応答に含まれています。
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およびotherinfo.extendedfailinfo.skdfailinfo nospamのcmcstatusinfoextを示す応答を返します。さらに、署名時間属性が応答に含まれています。
2.c.2.b - Else if the glMemberName is present on the GL, the GLA returns a cMCStatusInfoExt.cMCStatus.success, a signingTime attribute, and a glKey message (2 in Figure 10) as described in Section 5.
2.C.2.B -GLMEMBERNAMEがGLに存在する場合、GLAはセクション5で説明されているように、CMCSTATUSINFOEXT.CMCSTATUS.SUCCESS、SINGINGTIME属性、およびGLKEYメッセージ（図10の2）を返します。
There will be certain times when a GLO is having trouble setting up a GL because it does not know the algorithm(s) or some other characteristic that the GLA supports. There can also be times when prospective GL members or GL members need to know something about the GLA (these requests are not defined in the document). The glaQueryRequest and glaQueryResponse messages have been defined to support determining this information. Figure 11 depicts the protocol interactions for glaQueryRequest and glaQueryResponse. Note that error messages are not shown. Additionally, behavior for the optional transactionId, senderNonce, and recipientNonce CMC control attributes is not addressed in these procedures.
GLOがGLのセットアップに苦労している場合、GLAがサポートするアルゴリズムやその他の特性がわからないため、特定の時間があります。また、将来のGLメンバーまたはGLメンバーがGLAについて何かを知る必要がある場合もあります（これらの要求はドキュメントで定義されていません）。GlaqueryRequestおよびGlaqueryResponseメッセージは、この情報の決定をサポートするために定義されています。図11は、GlaqueryRequestとGlaqueryResponseのプロトコル相互作用を示しています。エラーメッセージが表示されないことに注意してください。さらに、オプションのTransactionID、Sendernonce、およびReciintNonce 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メンバーは、signeddata.pkidata.control sequence.glaqueryRequestリクエストをGLAに送信します（図11の1）。GLO、GLメンバー、または将来のGLメンバーは、GLAから受信することに関心のある情報を示します。さらに、このリクエストには署名時間属性が含まれています。
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メンバーは、封筒のsigneddata.pkidataを封筒にカプセル化することにより、オプションでリクエストに機密性を適用できます（セクション3.2.1.2を参照）。
1.b - The GLO, GL member, or prospective GL member can also optionally apply another SignedData over the EnvelopedData (see Section 3.2.1.2).
1.B- GLO、GLメンバー、または将来のGLメンバーは、オプションでエンベロープドタに別のSignedDataを適用することもできます（セクション3.2.1.2を参照）。
2 - Upon receipt of the glaQueryRequest, the GLA determines if it accepts glaQueryRequest messages.
2- GlaqueryRequestを受け取ると、GLAはGlaqueryRequestメッセージを受け入れるかどうかを判断します。
2.a - If the GLA does not accept glaQueryRequest messages, the GLA returns a cMCStatusInfoExt response indicating cMCStatus.noSupport and any other information in statusString.
2.A-GLAがGlaqueryRequestメッセージを受け入れない場合、GLAはCMCSTATUS.NOSUPPORTおよび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は署名時間をチェックし、GLO、GLメンバー、または将来のGLメンバーの署名を検証します。追加のsignedDataおよび/または封筒が要求をカプセル化する場合（セクション3.2.1.2または3.2.2を参照）、GLAは外側の署名を検証し、/または最も内側の署名dataの署名を検証する前に外側の層を復号化します。
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-署名時間属性値がローカルに受け入れられた時間ウィンドウ内にない場合、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応答を返します。さらに、署名時間属性が応答に含まれています。
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がサポートされている場合、GlareQuesttatus.NoSupportがGlareQuesttypeを示すCMCSTatusInfoext応答を返す場合、GLAはGlareQuestTypeがサポートされている場合、GlareQuestTypeが正しい応答でGlaqueryResponse（図11の2）を返します。さらに、署名時間属性が応答に含まれています。
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は、リクエストが封筒にカプセル化されている場合、封筒のSignedData.pkiresponseを封筒にカプセル化することにより、応答に機密性を適用します（セクション3.2.1.2を参照）。
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は、オプションでエンベロープドタに別の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メンバーが署名時間をチェックし、GLAの署名を検証します。追加のsignedDataおよび/または封筒が応答をカプセル化する場合（セクション3.2.1.2または3.2.2を参照）、GLO、GLメンバー、または将来のGLメンバーが外側の署名を検証し、署名を確認する前に外層を解読します。最も内側の署名data。
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-署名時間属性値がローカルに受け入れられた時間枠内にない場合、GLO、GLメンバー、または将来のGLメンバーは、CMCSTATUS.FAILEDおよびその他のInfo.failinfo.BadtimeおよびSINGINGTIME属性を示す応答を返すことができます。
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応答を返します。さらに、署名時間属性が応答に含まれています。
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がGladdMemberリクエストを生成すると、GLAがGLKEYメッセージを生成するとき、またはGLAがGladdMemberを処理するとき、GLメンバーの証明書が期限切れになっているか無効になっている場合があります。これらの例では、GLOまたはGLAは、GLメンバーがGLメンバーのGLKEYメッセージを生成できないのを防ぐために、GLメンバーが新しい証明書を提供することを要求する場合があります。また、GLメンバーがその証明書が期限切れになっているか、取り消されていることを知っている場合もあり、GLメンバーはGL Rekeysを受け取ることができない場合もあります。これらの手順では、オプションのTransactionID、Sendernonce、およびReciintNonce 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は、signeddata.pkidata.control sequence.glprovidecertリクエストをGLメンバーに送信します。GLOまたはGLAは、GLNAMEのGL名とGLMEMBERNAMEのGLメンバー名を示します。さらに、このリクエストには署名時間属性が含まれています。
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は、封筒のsigneddata.pkidataを封筒にカプセル化することにより、オプションでリクエストに機密性を適用できます（セクション3.2.1.2を参照）。GLメンバーのPKCが取り消された場合、GLOまたはGLAは、GLProvideCertリクエストをカプセル化する封筒を生成するために使用してはなりません。
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は、オプションでエンベロープドタに別の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メンバーは署名時間をチェックし、GLOまたはGLAの署名を検証します。追加のsignedDataおよび/または封筒が応答をカプセル化する場合（セクション3.2.1.2または3.2.2を参照）、GLメンバーは外側の署名を検証し、/または最も内側の署名dataの署名を検証する前に外層を飾ります。
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-署名時間属性値がローカルに受け入れられた時間枠内にない場合、GLメンバーはcmcstatus.failedおよびotherinfo.failinfo.badtimeを示す応答を返すことができます。
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およびその他のInfo.failinfo.badmessagecheckを示すCMCSTATUSINFOEXT応答を返します。さらに、署名時間属性が応答に含まれています。
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メンバーはsigned.pkiresponse.control sequence.glmembernameのメンバーの名前を含むsigned.pkiresponse.control sequence.glupdatecertを生成します。GLメンバーには、glmember.certificates.acのメンバーの暗号化証明書に関連付けられた属性証明書、およびglmember.certificates.certpathのメンバーの暗号化と属性証明書に関連付けられた認証パスを含めることもできます。さらに、署名時間属性が応答に含まれています。
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メンバーは、封筒のsignedData.pkiresponseをカプセル化することにより、オプションでリクエストに機密性を適用できます（セクション3.2.1.2を参照）。GLメンバーのPKCが取り消された場合、GLメンバーはGLProvideCertリクエストをカプセル化する封筒を生成するためにそれを使用してはなりません。
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メンバーは、オプションで封筒に別の署名dataを適用することもできます（セクション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は署名時間をチェックし、GLメンバーの署名を検証します。追加のsignedDataおよび/または封筒が応答をカプセル化する場合（セクション3.2.1.2または3.2.2を参照）、GLメンバーは外側の署名を検証し、/または最も内側の署名dataの署名を検証する前に外層を飾ります。
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-署名時間属性値がローカルに受け入れられた時間枠内にない場合、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応答を返します。さらに、署名時間属性が応答に含まれています。
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を返します。GLProvideCertは、GLメンバーが有効な証明書を持っていない場合、それがそれを返すことができないためです。さらに、どちらの応答でも署名時間属性が含まれています。
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はGLメンバーまたはCMCStatus.Failedを使用してGLメンバーまたはCMCStatusInfoextに別のGLProvideCert要求を返します。glprovidecertは、GLメンバーに有効な証明書がない場合、それはそれを返すことができないため、一定数の回数のみを返却する必要があります。さらに、署名時間属性が応答に含まれています。
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メンバーは、signed.pkidata.controlsequence.glupdatecertを送信します。これには、glmember.glmembernameのメンバーの名前であるGlnameのGL名が含まれています。GLメンバーには、glmember.certificates.acのメンバーの暗号化証明書に関連付けられた属性証明書、およびglmember.certificates.certpathのメンバーの暗号化と属性証明書に関連付けられた認証パスを含めることもできます。GLメンバーには、このリクエストに署名時間属性も含める必要があります。
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メンバーは、封筒のsigneddata.pkidataを封筒にカプセル化することにより、オプションでリクエストに機密性を適用できます（セクション3.2.1.2を参照）。GLメンバーのPKCが取り消された場合、GLOまたはGLAは、GLProvideCertリクエストをカプセル化する封筒を生成するために使用してはなりません。
1.b - The GL member can also optionally apply another SignedData over the EnvelopedData (see Section 3.2.1.2).
1.B- GLメンバーは、オプションで封筒に別の署名dataを適用することもできます（セクション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は署名時間をチェックし、GLメンバーの署名を検証します。追加のSignedDataおよび/またはEnvelopedDataが応答をカプセル化する場合（セクション3.2.1.2または3.2.2を参照）、GLAは外側の署名を検証し、/または最も内側の署名Dataの署名を検証する前に外側の層を飾ります。
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-署名時間属性値がローカルで受け入れられた時間枠内にない場合、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およびその他のInfo.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を使用してGLメンバーまたはCMCStatusInfoextに別のGLProvideCert要求を返します。glprovidecertは無期限に返されるべきではありません。GLメンバーが有効な証明書を持っていない場合、それはそれを返すことができません。さらに、署名時間属性が応答に含まれています。
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はまた、GlupdateCertメッセージをGLOに転送します。
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は、GladdMember、GldeleTemember（閉じたGLSおよびManaged GLS用）、Glrekey、GlkCompromise、またはGlkrefreshリクエストを受け取り、それぞれのリクエストのCMCStatusInfoext応答を返した後、GLAKEの共有Kek（s）を配布するためにGlkeyメッセージを使用します。図12は、GLKEYメッセージを送信するためのプロトコルの相互作用を示しています。管理メッセージに対して定義された手順とは異なり、このセクションで定義されている手順は、GLASのOriginingおよび受信時のGLメンバーによって実装されなければなりません。エラーメッセージが表示されないことに注意してください。さらに、オプションのTransactionID、Sendernonce、およびReciintNonce 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.RecipientsNotMutiLAWARE AWARE SET TRUEに設定された場合、他のGLメンバーに関する情報を漏らさないように、個別のGLKEYメッセージを各GLメンバーに送信する必要があります。
When the glKey message is generated as a result of a:
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がゼロ（0）に設定されたGlrekeyリクエスト。
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は、Kari（[CMS]のセクション12.3.2を参照）またはKTRI（[CMS]のセクション12.3.1を参照）のいずれかを使用する必要があります。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.
Glrekey Counterがゼロ（0）を超えたGlrekeyリクエストの結果としてGlkeyメッセージが生成される場合、またはGLAがRekeysを制御する場合、GLAはKari、Ktri、またはKekriを使用する場合があります（[CMS]のセクション12.3.3を参照）glkey.glkwrapped.recipientinfoで、意図した受信者のみが共有Kekを受け取るようにします。GLAは、Reciontientinfo.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はGLメンバーに新しい証明書を要求するGLメンバーに送信する場合があります（セクション4.10を参照）。GLに対して生成されたGLKEYメッセージの数は、セクション3.1.13で説明されています。さらに、SINGINGTIME属性は配布メッセージに含まれています。
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は、別の封筒に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は、オプションでemvelopedData.signedData.pkidataに別の署名dataを適用することもできます（セクション3.2.1.2を参照）。
2 - Upon receipt of the glKey message, the GL members MUST check the signingTime and verify the signature over the innermost SignedData.PKIData. If an additional SignedData and/or EnvelopedData encapsulates the message (see Section 3.2.1.2 or 3.2.2), the GL member MUST verify the outer signature and/or decrypt the outer layer prior to verifying the signature on the SignedData.PKIData.controlSequence.glKey.
2-GLKEYメッセージを受信すると、GLメンバーは署名時間をチェックし、最も内側のsignedData.pkidata上の署名を確認する必要があります。追加のsignedDataおよび/または封筒がメッセージをカプセル化する場合（セクション3.2.1.2または3.2.2を参照）、GLメンバーは、signedData.pkidata.controlol seaveenceenceの署名を確認する前に、外側の署名を検証するか、外側の層を復号化する必要があります。.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-署名時間属性値がローカルで受け入れられた時間枠内にない場合、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およびその他のInfo.failinfo.badmessagecheckを示すCMCSTATUSINFOEXT応答を返す必要があります。さらに、署名時間属性が応答に含まれています。
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]に従ってレシピエンティインフォスを処理します。包装されていないと、GLメンバーは共有Kekを安全な場所に保存する必要があります。保存すると、Glname、Glidentifier、および共有Kekを関連付ける必要があります。さらに、GLメンバーは、cmcstatus.successを示すcmcstatusinfoextを返して、kekを受信したことをglaに伝える必要があります。
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）、およびパディングをランダムに生成する必要があります。また、パブリック/秘密鍵のペアの生成は、乱数に依存しています。不十分な擬似ランダム数ジェネレーター（PRNGS）を使用して暗号化キーを生成すると、セキュリティがほとんどまたはまったくなりません。攻撃者は、キーを生成するキーを生成するPRNG環境を再現する方がはるかに簡単になる場合があります。品質の乱数の生成は困難です。RFC 4086 [ランダム]はこの分野で重要なガイダンスを提供し、FIPS Pub 186の付録3 [FIPS]は1つの高品質の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].
GLKWrappに含まれるアルゴリズムオブジェクト識別子は、[cmsalg]および[cmsaes]で指定されているとおりです。
The shared KEK distributed and indicated in glkAlgorithm MUST support the symmetric key-encryption algorithms as specified in [CMSALG] and [CMSAES].
Glkalgorithmで分布し、示されている共有Kekは、[cmsalg]および[cmsaes]で指定されているように、対称キー暗号化アルゴリズムをサポートする必要があります。
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を再起動し、メンバーの追加と削除を制御できるため、GLOはGLの管理に重要な役割を果たし、「信頼できる」GLOのみを使用する必要があります。
If a member is deleted or removed from a closed or a managed GL, the GL needs to be rekeyed. If the GL is not rekeyed after a member is removed or deleted, the member still possesses the group key and will be able to continue to decrypt any messages that can be obtained.
閉じたGLまたはマネージドGLからメンバーが削除または削除された場合、GLを再キーにする必要があります。メンバーが削除または削除された後にGLが再キーにされていない場合、メンバーは依然としてグループキーを所有しており、取得できるメッセージを復号化し続けることができます。
Members who store KEKs MUST associate the name of the GLA that distributed the key so that the members can make sure subsequent rekeys are originated from the same entity.
Keksを保存するメンバーは、キーを配布したGLAの名前を関連付けなければなりません。これにより、メンバーは後続のRekeが同じエンティティから生まれていることを確認できます。
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とGLAは、GenerationCounterと期間がそれほど大きくないことを確認する必要があります。たとえば、GLOがGenerationCounterが14であり、期間が1年であることを示している場合、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.
2つ以上の当事者が共有Kekを持っていると仮定し、共有Kekはそれらの当事者への機密配布のために2番目のKekを暗号化するために使用されます。2番目のKekは、3番目のKekを暗号化するために使用される場合があります。3番目のKekは、4番目の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.
攻撃中に収集された情報の集約は、グループの共有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.
非CEおよび署名時間属性は、リプレイ攻撃から保護するために使用されます。ただし、これらの規定は、エンティが比較のために送信または受け取ったメッセージに関する州の情報を維持している場合にのみ役立ちます。各交換で十分な情報が維持されていない場合、NoncesとSingimeTimeは役に立ちません。ローカルポリシーは、維持されている州情報の量と期間を決定します。さらに、統一された時間源がなければ、時計が漂う可能性があります。ローカルポリシーは、現地時間と署名時間の間に許容可能な違いを決定します。実装は、将来作成されたことを示すSiginingTime属性を使用してメッセージを処理する必要があります。
Thanks to Russ Housley and Jim Schaad for providing much of the background and review required to write this document.
この文書を書くのに必要な背景とレビューの多くを提供してくれたRuss HousleyとJim Schaadに感謝します。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、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. Myers、「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.
[プロファイル] Cooper、D.、Santesson、S.、Farrell、S.、Boeyen、S.、Housley、R.、およびW. Polk、 "Internet 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] Farrell、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.、ed。、「Secure/Multipurpose Internet Mail Extensions（S/MIME）バージョン3.1メッセージ仕様」、RFC 3851、2004年7月。
[ESS] Hoffman, P., Ed., "Enhanced Security Services for S/MIME", RFC 2634, June 1999.
[ESS] Hoffman、P.、ed。、「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。、「暗号化メッセージ構文（CMS）の高度な暗号化標準（AES）暗号化アルゴリズムの使用」、RFC 3565、2003年7月。
[SMTP] Klensin, J., Ed., "Simple Mail Transfer Protocol", RFC 2821, April 2001.
[SMTP] Klensin、J.、ed。、「Simple Mail Transfer Protocol」、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] Hoffman、P。and C. Bonatti、「Secure/Multipurpose Internet Mail Extensions（S/MIME）オブジェクトのX.400」、RFC 3855、2004年7月。
[RANDOM] Eastlake, D., 3rd, Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
[ランダム] Eastlake、D.、3rd、Schiller、J。、およびS. Crocker、「セキュリティのランダム性要件」、BCP 106、RFC 4086、2005年6月。
[FIPS] National Institute of Standards and Technology, FIPS Pub 186-2: Digital Signature Standard, January 2000.
[FIPS]国立標準技術研究所、FIPS Pub 186-2：Digital Signature Standard、2000年1月。
SMIMESymmetricKeyDistribution
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
pkcs-9(9) smime(16) modules(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.
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 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) }
-- 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) }
-- 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) }
-- 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) };
-- This defines the GL symmetric key distribution object identifier
-- arc.
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.
id-skd-glDelete OBJECT IDENTIFIER ::= { id-skd 2 }
DeleteGL ::= GeneralName
-- This defines the Add GL Member control attribute.
- これは、ADD 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.
- これにより、ADDおよび削除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.
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.
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.
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.
id-skd-glManageCert OBJECT IDENTIFIER ::= { id-skd 14 }
-- This defines the control attribute to distribute the GL shared
-- 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 -smimeSymmetrickeydistribution
Author's Address
著者の連絡先
Sean Turner IECA, Inc. 3057 Nutley Street, Suite 106 Fairfax, VA 22031 USA
Sean Turner IECA、Inc。3057 Nutley Street、Suite 106 Fairfax、VA 22031 USA
EMail: turners@ieca.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（c）The IETF Trust（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。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への情報をお問い合わせください。