Network Working Group S. Turner
Request for Comments: 5275 IECA
Category: Standards Track June 2008
Network Working Group S. Turner
Request for Comments: 5275 IECA
Category: Standards Track June 2008
CMS Symmetric Key Management and Distribution
对称密钥管理和分发
Status of This Memo
关于下段备忘
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Abstract
摘要
This document describes a mechanism to manage (i.e., set up, distribute, and rekey) keys used with symmetric cryptographic algorithms. Also defined herein is a mechanism to organize users into groups to support distribution of encrypted content using symmetric cryptographic algorithms. The mechanism uses the Cryptographic Message Syntax (CMS) protocol and Certificate Management over CMS (CMC) protocol to manage the symmetric keys. Any member of the group can then later use this distributed shared key to decrypt other CMS encrypted objects with the symmetric key. This mechanism has been developed to support Secure/Multipurpose Internet Mail Extensions (S/MIME) Mail List Agents (MLAs).
本文档描述了一种管理（即，设置、分发和重新设置）对称加密算法使用的密钥的机制。本文还定义了一种将用户组织成组的机制，以支持使用对称加密算法分发加密内容。该机制使用加密消息语法（CMS）协议和CMS证书管理（CMC）协议来管理对称密钥。然后，组中的任何成员都可以稍后使用此分布式共享密钥来使用对称密钥解密其他CMS加密对象。开发此机制是为了支持安全/多用途Internet邮件扩展（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
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
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]）的使用不断扩大，用户需要一种机制将加密数据分发给多个接收者（即一组用户）。为收件人加密数据基本上有两种方法：使用带有公钥证书（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）为特定收件人加密CEK（ktri RecipientInfo选项）或（b）传输足够的参数以使特定收件人能够独立生成相同的KEK（kari RecipientInfo选项）。如果组很大，则处理每个收件人的信息可能需要相当长的时间，更不用说收集和验证每个收件人的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.
对于对称算法，发起过程略有不同。发起人不使用PKCs，而是使用以前分发的密钥加密密钥（KEK）加密CEK（kekri RecipientInfo选项）。只需要加密CEK的一个副本，因为所有收件人都已经拥有解密CEK所需的共享KEK，从而获得对加密内容的访问权。
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].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照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.
这种分发机制的一个主要受众是电子邮件。通讯组列表（有时称为邮件列表）支持将邮件分发给订阅邮件列表的收件人。关于如何使用邮件列表，有两种模型。如果发端人是邮件列表的成员，则发端人将使用共享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.
还可以通过存储库分发对象（例如，轻量级目录访问协议（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.
本文档在编写时考虑了三个特定场景：两个支持邮件列表代理，一个用于一般邮件分发。场景1描述了发起者向MLA发送受公钥（PK）保护的消息，然后MLA使用共享KEK将消息重新分发给列表成员。场景2描述了发端人向MLA发送受KEK保护的共享邮件，然后MLA将邮件重新分发给列表中的成员（MLA仅添加其他收件人）。发起人使用的密钥可以是所有接收人之间共享的密钥，也可以是成员与MLA之间共享的密钥。请注意，如果发起者使用仅与MLA共享的密钥，那么MLA将需要解密消息并为列表收件人重新加密消息。场景3显示发端人向一组没有中间MLA的收件人发送共享KEK保护邮件。
+----> +----> +---->
PK +-----+ S | S +-----+ S | S |
----> | MLA | --+----> ----> | MLA | --+----> ----+---->
+-----+ | +-----+ | |
+----> +----> +---->
+----> +----> +---->
PK +-----+ S | S +-----+ S | S |
----> | MLA | --+----> ----> | MLA | --+----> ----+---->
+-----+ | +-----+ | |
+----> +----> +---->
Scenario 1 Scenario 2 Scenario 3
场景1场景2场景3
Figure 1 depicts the architecture to support symmetric key distribution. The Group List Agent (GLA) supports two distinct functions with two different agents:
图1描述了支持对称密钥分发的体系结构。组列表代理（GLA）使用两个不同的代理支持两个不同的功能：
- The Key Management Agent (KMA), which is responsible for generating the shared KEKs.
- 密钥管理代理（KMA），负责生成共享KEK。
- The Group Management Agent (GMA), which is responsible for managing the Group List (GL) to which the shared KEKs are distributed.
- 集团管理代理（GMA），负责管理共享KEK分发到的集团列表（GL）。
+----------------------------------------------+
| Group List Agent | +-------+
| +------------+ + -----------------------+ | | Group |
| | Key | | Group Management Agent | |<-->| List |
| | Management |<-->| +------------+ | | | Owner |
| | Agent | | | Group List | | | +-------+
| +------------+ | +------------+ | |
| | / | \ | |
| +------------------------+ |
+----------------------------------------------+
/ | \
/ | \
+----------+ +---------+ +----------+
| Member 1 | | ... | | Member n |
+----------+ +---------+ +----------+
+----------------------------------------------+
| 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通常只支持一个GMA，但GMA可能支持多个GLs。多个KMA支持一个GMA的方式与GLA支持多个KMA的方式相同。将特定KMA分配给总账超出了本文档的范围。
Modeling real-world GL implementations shows that there are very restrictive GLs, where a human determines GL membership, and very open GLs, where there are no restrictions on GL membership. To support this spectrum, the mechanism described herein supports both
对真实世界的GL实现进行建模表明，存在非常严格的GLs，其中由人确定GL成员资格，以及非常开放的GLs，其中对GL成员资格没有限制。为了支持该频谱，本文描述的机制支持这两种
managed (i.e., where access control is applied) and unmanaged (i.e., where no access control is applied) GLs. The access control mechanism for managed lists is beyond the scope of this document. Note: If the distribution for the list is performed by an entity other than the originator (e.g., an MLA distributing a mail message), this entity can also enforce access control rules.
托管（即应用访问控制的地方）和非托管（即不应用访问控制的地方）GLs。托管列表的访问控制机制超出了本文档的范围。注意：如果列表的分发由发起人以外的实体执行（例如，分发邮件消息的MLA），则该实体也可以强制执行访问控制规则。
In either case, the GL must initially be constructed by an entity hereafter called the Group List Owner (GLO). There may be multiple entities who 'own' the GL and who are allowed to make changes to the GL's properties or membership. The GLO determines if the GL will be managed or unmanaged and is the only entity that may delete the GL. GLO(s) may or may not be GL members. GLO(s) may also set up lists that are closed, where the GLO solely determines GL membership.
在任何一种情况下，总账最初都必须由以下称为集团列表所有者（GLO）的实体构建。可能有多个实体“拥有”总账，并允许其更改总账的属性或成员资格。GLO确定总账是受管理还是非受管理，并且是唯一可以删除总账的实体。GLO可能是也可能不是GL成员。GLO还可以设置关闭的列表，其中GLO仅确定GL成员资格。
Though Figure 1 depicts the GLA as encompassing both the KMA and GMA functions, the two functions could be supported by the same entity or they could be supported by two different entities. If two entities are used, they could be located on one or two platforms. There is however a close relationship between the KMA and GMA functions. If the GMA stores all information pertaining to the GLs and the KMA merely generates keys, a corrupted GMA could cause havoc. To protect against a corrupted GMA, the KMA would be forced to double check the requests it receives to ensure that the GMA did not tamper with them. These duplicative checks blur the functionality of the two components together. For this reason, the interactions between the KMA and GMA are beyond the scope of this document.
尽管图1将GLA描述为包含KMA和GMA功能，但这两个功能可以由同一实体支持，也可以由两个不同的实体支持。如果使用两个实体，它们可能位于一个或两个平台上。然而，KMA和GMA功能之间存在密切关系。如果GMA存储与GLs相关的所有信息，而KMA仅生成密钥，则损坏的GMA可能会造成严重破坏。为了防止损坏的GMA，KMA将被迫对其收到的请求进行双重检查，以确保GMA不会篡改这些请求。这些重复检查模糊了两个组件的功能。因此，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.
专有机制可用于通过加强两个实体之间的信任关系来分离职能。此后，不再进一步讨论这两种制剂之间的区别；术语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
现有机制（如listserv和majordomo）用于管理GLs；然而，本文件并未涉及这些机制的安全问题，因为它们没有标准化。相反，它定义了协议交互，如图2所示，由GL成员、GLA和GLO用于管理GLs和分发共享KEK。交互被分为管理消息和分发消息。管理消息是设置总帐、删除总帐、向总帐添加成员、删除总帐成员、请求组密钥更新、向总帐添加所有者、删除总帐所有者、指示组密钥泄露、刷新组密钥、询问总帐所需的请求和响应消息，并更新成员和所有者的公钥证书。分布
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.
消息是分发共享KEK的消息。以下各节描述了ASN.1的管理和分发消息。第4节描述了如何使用管理消息，第5节描述了如何使用分发消息。
+-----+ +----------+
| GLO | <---+ +----> | Member 1 |
+-----+ | | +----------+
| |
+-----+ <------+ | +----------+
| GLA | <-------------+----> | ... |
+-----+ | +----------+
|
| +----------+
+----> | Member n |
+----------+
+-----+ +----------+
| 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提供的分层功能，其中消息中包含一个或多个控制属性，并受CMS保护，以请求或响应所需的操作。CMC PKI数据结构用于请求，CMC PKI响应结构用于响应。然后将内容类型PKIData和PKIResponse封装在CMS的SignedData或EnvelopedData或两者的组合中（参见第3.2节）。以下是本文档中定义的控件属性：
Control
Attribute OID Syntax
------------------- ----------- -----------------
glUseKEK id-skd 1 GLUseKEK
glDelete id-skd 2 GeneralName
glAddMember id-skd 3 GLAddMember
glDeleteMember id-skd 4 GLDeleteMember
glRekey id-skd 5 GLRekey
glAddOwner id-skd 6 GLOwnerAdministration
glRemoveOwner id-skd 7 GLOwnerAdministration
glkCompromise id-skd 8 GeneralName
glkRefresh id-skd 9 GLKRefresh
glaQueryRequest id-skd 11 GLAQueryRequest
glaQueryResponse id-skd 12 GLAQueryResponse
glProvideCert id-skd 13 GLManageCert
glUpdateCert id-skd 14 GLManageCert
glKey id-skd 15 GLKey
Control
Attribute OID Syntax
------------------- ----------- -----------------
glUseKEK id-skd 1 GLUseKEK
glDelete id-skd 2 GeneralName
glAddMember id-skd 3 GLAddMember
glDeleteMember id-skd 4 GLDeleteMember
glRekey id-skd 5 GLRekey
glAddOwner id-skd 6 GLOwnerAdministration
glRemoveOwner id-skd 7 GLOwnerAdministration
glkCompromise id-skd 8 GeneralName
glkRefresh id-skd 9 GLKRefresh
glaQueryRequest id-skd 11 GLAQueryRequest
glaQueryResponse id-skd 12 GLAQueryResponse
glProvideCert id-skd 13 GLManageCert
glUpdateCert id-skd 14 GLManageCert
glKey id-skd 15 GLKey
In the following conformance tables, the column headings have the following meanings: O for originate, R for receive, and F for forward. There are three types of implementations: GLOs, GLAs, and GL members. The GLO is an optional component, hence all GLO O and GLO R messages are optional, and GLA F messages are optional. The first table includes messages that conformant implementations MUST support. The second table includes messages that MAY be implemented. The second table should be interpreted as follows: if the control attribute is implemented by a component, then it must be implemented as indicated. For example, if a GLA is implemented that supports the glAddMember control attribute, then it MUST support receiving the glAddMember message. Note that "-" means not applicable.
在以下一致性表中，列标题具有以下含义：O表示发起，R表示接收，F表示转发。有三种类型的实现：GLOs、GLAs和GL成员。GLO是可选组件，因此所有GLO O和GLO R消息都是可选的，而GLA F消息都是可选的。第一个表包括一致性实现必须支持的消息。第二个表包括可以实现的消息。第二个表应该解释为：如果控件属性是由组件实现的，那么它必须按照指示实现。例如，如果实现的GLA支持GLADMember控件属性，那么它必须支持接收GLADMember消息。请注意“-”表示不适用。
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
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
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 PKI响应内容类型中携带，所有其他控件属性在CMC PKI数据内容类型中携带。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 }
GLUseKEK ::= SEQUENCE {
glInfo GLInfo,
glOwnerInfo SEQUENCE SIZE (1..MAX) OF GLOwnerInfo,
glAdministration GLAdministration DEFAULT 1,
glKeyAttributes GLKeyAttributes OPTIONAL }
GLInfo ::= SEQUENCE {
glName GeneralName,
glAddress GeneralName }
GLInfo ::= SEQUENCE {
glName GeneralName,
glAddress GeneralName }
GLOwnerInfo ::= SEQUENCE {
glOwnerName GeneralName,
glOwnerAddress GeneralName,
certificate Certificates OPTIONAL }
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]
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 and CertificateChoices are included only
-- for illustrative purposes as they are imported from [CMS].
CertificateSet ::= SET SIZE (1..MAX) OF CertificateChoices
CertificateSet ::= SET SIZE (1..MAX) OF CertificateChoices
-- CertificateChoices supports X.509 public key certificates in
-- certificates and v2 attribute certificates in v2AttrCert.
-- CertificateChoices supports X.509 public key certificates in
-- certificates and v2 attribute certificates in v2AttrCert.
GLAdministration ::= INTEGER {
unmanaged (0),
managed (1),
closed (2) }
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 } }
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中总账的名称和GLADRENT中总账的地址。glName和gladirent可以是相同的，但情况并非总是如此。对于给定的GLA，名称和地址必须是唯一的。
- glOwnerInfo indicates:
- glOwnerInfo指出：
-- glOwnerName indicates the name of the owner of the GL. One of the names in glOwnerName MUST match one of the names in the certificate (either the subject distinguished name or one of the subject alternative names) used to sign this SignedData.PKIData creating the GL (i.e., the immediate signer).
--glOwnerName表示总账所有者的名称。glOwnerName中的一个名称必须与证书中的一个名称（使用者可分辨名称或使用者备选名称之一）匹配，该证书用于签名此SignedData.PKIData创建GL（即直接签名者）。
-- glOwnerAddress indicates the GL owner's address.
--GlownAddress表示总账所有者的地址。
-- certificates MAY be included. It contains the following three fields:
--可能包括证书。它包含以下三个字段：
--- certificates.pKC includes the encryption certificate for
the GLO. It will be used to encrypt responses for the
GLO.
--- certificates.pKC includes the encryption certificate for
the GLO. It will be used to encrypt responses for the
GLO.
--- certificates.aC MAY be included to convey any attribute
certificate (see [ACPROF]) associated with the
encryption certificate of the GLO included in
certificates.pKC.
--- certificates.aC MAY be included to convey any attribute
certificate (see [ACPROF]) associated with the
encryption certificate of the GLO included in
certificates.pKC.
--- certificates.certPath MAY also be included to convey
certificates that might aid the recipient in
constructing valid certification paths for the
certificate provided in certificates.pKC and the
attribute certificates provided in certificates.aC.
Theses certificates are optional because they might
already be included elsewhere in the message (e.g., in
the outer CMS layer).
--- certificates.certPath MAY also be included to convey
certificates that might aid the recipient in
constructing valid certification paths for the
certificate provided in certificates.pKC and the
attribute certificates provided in certificates.aC.
Theses certificates are optional because they might
already be included elsewhere in the message (e.g., in
the outer CMS layer).
-- glAdministration indicates how the GL ought to be administered. The default is for the list to be managed. Three values are supported for glAdministration:
--glAdministration表示应该如何管理GL。默认值是要管理的列表。glAdministration支持三个值：
--- Unmanaged - When the GLO sets glAdministration to
unmanaged, it is allowing prospective members to request
addition and deletion from the GL without GLO
intervention.
--- Unmanaged - When the GLO sets glAdministration to
unmanaged, it is allowing prospective members to request
addition and deletion from the GL without GLO
intervention.
--- Managed - When the GLO sets glAdministration to managed,
it is allowing prospective members to request addition
and deletion from the GL, but the request is redirected
by the GLA to GLO for review. The GLO makes the
determination as to whether to honor the request.
--- Managed - When the GLO sets glAdministration to managed,
it is allowing prospective members to request addition
and deletion from the GL, but the request is redirected
by the GLA to GLO for review. The GLO makes the
determination as to whether to honor the request.
--- Closed - When the GLO sets glAdministration to closed,
it is not allowing prospective members to request
addition or deletion from the GL. The GLA will only
accept glAddMember and glDeleteMember requests from the
GLO.
--- Closed - When the GLO sets glAdministration to closed,
it is not allowing prospective members to request
addition or deletion from the GL. The GLA will only
accept glAddMember and glDeleteMember requests from the
GLO.
-- glKeyAttributes indicates the attributes the GLO wants the GLA to assign to the shared KEK. If this field is omitted, GL rekeys will be controlled by the GLA, the recipients are allowed to know about one another, the algorithm will be AES-128 (see Section 7), the shared KEK will be valid for a calendar month (i.e., first of the month until the last day
--glKeyAttributes表示GLO希望GLA分配给共享KEK的属性。如果省略此字段，GL密钥将由GLA控制，允许接收者相互了解，算法将为AES-128（见第7节），共享KEK将在一个日历月内有效（即，月初至最后一天）
of the month), and two shared KEKs will be distributed initially. The fields in glKeyAttributes have the following meaning:
最初将分发两个共享桶。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 indicates whether the GL rekey
messages will be generated by the GLO or by the GLA.
The default is for the GLA to control rekeys. If GL
rekey is controlled by the GLA, the GL will continue to
be rekeyed until the GLO deletes the GL or changes the
GL rekey to be GLO controlled.
--- recipientsNotMutuallyAware indicates that the GLO wants
the GLA to distribute the shared KEK individually for
each of the GL members (i.e., a separate glKey message
is sent to each recipient). The default is for separate
glKey message not to be required.
--- recipientsNotMutuallyAware indicates that the GLO wants
the GLA to distribute the shared KEK individually for
each of the GL members (i.e., a separate glKey message
is sent to each recipient). The default is for separate
glKey message not to be required.
Note: This supports lists where one member does not know the identities of the other members. For example, a list is configured granting submit permissions to only one member. All other members are 'listening'. The security policy of the list does not allow the members to know who else is on the list. If a glKey is constructed for all of the GL members, information about each of the members may be derived from the information in RecipientInfos.
注意：这支持一个成员不知道其他成员身份的列表。例如，配置的列表仅向一个成员授予提交权限。所有其他成员都在“倾听”。列表的安全策略不允许成员知道列表上还有谁。如果为所有GL成员构造了一个glKey，那么关于每个成员的信息可能来自RecipientInfos中的信息。
To make sure the glkey message does not divulge information about the other recipients, a separate glKey message would be sent to each GL member.
为确保glkey消息不会泄露其他收件人的信息，将向每个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.
--- duration indicates the length of time (in days) during
which the shared KEK is considered valid. The value
zero (0) indicates that the shared KEK is valid for a
calendar month in the UTC Zulu time zone. For example,
if the duration is zero (0), if the GL shared KEK is
requested on July 24, the first key will be valid until
the end of July and the next key will be valid for the
entire month of August. If the value is not zero (0),
the shared KEK will be valid for the number of days
indicated by the value. For example, if the value of
duration is seven (7) and the shared KEK is requested on
Monday but not generated until Tuesday (13 May 2008);
the shared KEKs will be valid from Tuesday (13 May 2008)
to Tuesday (20 May 2008). The exact time of the day is
determined when the key is generated.
--- generationCounter indicates the number of keys the GLO
wants the GLA to distribute. To ensure uninterrupted
function of the GL, two (2) shared KEKs at a minimum
MUST be initially distributed. The second shared KEK is
distributed with the first shared KEK, so that when the
first shared KEK is no longer valid the second key can
be used. If the GLA controls rekey, then it also
indicates the number of shared KEKs the GLO wants
outstanding at any one time. See Sections 4.5 and 5 for
more on rekey.
--- generationCounter indicates the number of keys the GLO
wants the GLA to distribute. To ensure uninterrupted
function of the GL, two (2) shared KEKs at a minimum
MUST be initially distributed. The second shared KEK is
distributed with the first shared KEK, so that when the
first shared KEK is no longer valid the second key can
be used. If the GLA controls rekey, then it also
indicates the number of shared KEKs the GLO wants
outstanding at any one time. See Sections 4.5 and 5 for
more on rekey.
--- requestedAlgorithm indicates the algorithm and any
parameters the GLO wants the GLA to use with the shared
KEK. The parameters are conveyed via the
SMIMECapabilities attribute (see [MSG]). See Section 6
for more on algorithms.
--- requestedAlgorithm indicates the algorithm and any
parameters the GLO wants the GLA to use with the shared
KEK. The parameters are conveyed via the
SMIMECapabilities attribute (see [MSG]). See Section 6
for more on algorithms.
GLOs use glDelete to request that a GL be deleted from the GLA. The glDelete control attribute has the syntax GeneralName. The glDelete message MUST be signed by the GLO. The name of the GL to be deleted is included in GeneralName:
GLO使用glDelete请求从GLA中删除总账。glDelete控件属性具有语法GeneralName。glDelete消息必须由GLO签名。要删除的总账的名称包含在通用名称中：
DeleteGL ::= 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:
GLO使用glAddMember请求添加新成员，潜在GL成员使用GLADDMBER请求自己添加到GL。glAddMember消息必须由GLO或潜在GL成员签名。glAddMember控件属性的语法为glAddMember:
GLAddMember ::= SEQUENCE {
glName GeneralName,
glMember GLMember }
GLAddMember ::= SEQUENCE {
glName GeneralName,
glMember GLMember }
GLMember ::= SEQUENCE {
glMemberName GeneralName,
glMemberAddress GeneralName OPTIONAL,
certificates Certificates OPTIONAL }
GLMember ::= SEQUENCE {
glMemberName GeneralName,
glMemberAddress GeneralName OPTIONAL,
certificates Certificates OPTIONAL }
The fields in GLAddMembers have the following meaning:
GladMembers中的字段具有以下含义：
- glName indicates the name of the GL to which the member should be added.
- glName表示应向其添加成员的总账的名称。
- glMember indicates the particulars for the GL member. Both of the following fields must be unique for a given GL:
- glMember表示总账成员的详细信息。对于给定总账，以下两个字段必须是唯一的：
-- glMemberName indicates the name of the GL member.
--glMemberName表示总账成员的名称。
-- glMemberAddress indicates the GL member's address. It MUST be included.
--glMemberAddress表示总账成员的地址。它必须包括在内。
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:
--必须包括证书。它包含以下三个字段：
--- certificates.pKC includes the member's encryption
certificate. It will be used, at least initially, to
encrypt the shared KEK for that member. If the message
is generated by a prospective GL member, the pKC MUST be
included. If the message is generated by a GLO, the pKC
SHOULD be included.
--- certificates.pKC includes the member's encryption
certificate. It will be used, at least initially, to
encrypt the shared KEK for that member. If the message
is generated by a prospective GL member, the pKC MUST be
included. If the message is generated by a GLO, the pKC
SHOULD be included.
--- certificates.aC MAY be included to convey any attribute
certificate (see [ACPROF]) associated with the member's
encryption certificate.
--- certificates.aC MAY be included to convey any attribute
certificate (see [ACPROF]) associated with the member's
encryption certificate.
--- certificates.certPath MAY also be included to convey
certificates that might aid the recipient in
constructing valid certification paths for the
certificate provided in certificates.pKC and the
attribute certificates provided in certificates.aC.
These certificates are optional because they might
already be included elsewhere in the message (e.g., in
the outer CMS layer).
--- certificates.certPath MAY also be included to convey
certificates that might aid the recipient in
constructing valid certification paths for the
certificate provided in certificates.pKC and the
attribute certificates provided in certificates.aC.
These certificates are optional because they might
already be included elsewhere in the message (e.g., in
the outer CMS layer).
GLOs use the glDeleteMember to request deletion of GL members, and GL members use the glDeleteMember to request their own removal from the GL. The glDeleteMember message MUST be signed by either the GLO or the GL member. The glDeleteMember control attribute has the syntax GLDeleteMember:
GLO使用glDeleteMember请求删除总账成员，而总账成员使用glDeleteMember请求自己从总账中删除。glDeleteMember消息必须由GLO或GL成员签名。glDeleteMember控件属性的语法为glDeleteMember:
GLDeleteMember ::= SEQUENCE {
glName GeneralName,
glMemberToDelete GeneralName }
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表示应从中删除成员的总账的名称。
- 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请求glRekey。glRekey消息必须由GLO签名。glRekey控件属性的语法为glRekey：
GLRekey ::= SEQUENCE {
glName GeneralName,
glAdministration GLAdministration OPTIONAL,
glNewKeyAttributes GLNewKeyAttributes OPTIONAL,
glRekeyAllGLKeys BOOLEAN OPTIONAL }
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 }
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表示要重新键入的总账的名称。
- 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.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是否希望对所有未结总账的共享KEK重新设置密钥。如果设置为TRUE，则必须发布所有未完成的KEK。如果设置为FALSE，则无需重新发布所有未完成的KEK。
GLOs use the glAddOwner to request that a new GLO be allowed to administer the GL. The glAddOwner message MUST be signed by a registered GLO. The glAddOwner control attribute has the syntax GLOwnerAdministration:
GLO使用glAddOwner请求允许新GLO管理GL。glAddOwner消息必须由注册的GLO签名。glAddOwner控件属性具有以下语法：
GLOwnerAdministration ::= SEQUENCE {
glName GeneralName,
glOwnerInfo GLOwnerInfo }
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应关联到的总账的名称。
- 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的名称，因此必须包含certificates.pKC，并且必须包含新GLO的加密证书。
GLOs use the glRemoveOwner to request that a GLO be disassociated with the GL. The glRemoveOwner message MUST be signed by a registered GLO. The glRemoveOwner control attribute has the syntax GLOwnerAdministration:
GLO使用glRemoveOwner请求解除GLO与GL的关联。glRemoveOwner消息必须由注册的GLO签名。glRemoveOwner控件属性具有以下语法：
GLOwnerAdministration ::= SEQUENCE {
glName GeneralName,
glOwnerInfo GLOwnerInfo }
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应解除关联的总账的名称。
- 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
德国劳埃德船级社成员和GLO使用glkCompromise表示拥有的共享KEK已受损。GLKeyConvention控件属性具有语法GeneralName。GLA总是将此消息重定向到GLO，以便采取进一步行动。GLKCommise可以包含在使用
compromised shared KEK. The name of the GL to which the compromised key is associated is placed in GeneralName:
共享桶。与泄露密钥相关联的GL的名称位于GeneralName中：
GLKCompromise ::= GeneralName
GLKCompromise ::= GeneralName
GL members use the glkRefresh to request that the shared KEK be redistributed to them. The glkRefresh control attribute has the syntax GLKRefresh.
GL成员使用glkRefresh请求将共享的KEK重新分配给他们。glkRefresh控件属性的语法为glkRefresh。
GLKRefresh ::= SEQUENCE {
glName GeneralName,
dates SEQUENCE SIZE (1..MAX) OF Date }
GLKRefresh ::= SEQUENCE {
glName GeneralName,
dates SEQUENCE SIZE (1..MAX) OF Date }
Date ::= SEQUENCE {
start GeneralizedTime,
end GeneralizedTime OPTIONAL }
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表示总账成员希望共享KEK的总账的名称。
- 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.
- 日期表示总账成员想要的关键字的日期范围。“开始”字段表示总账成员想要的第一个日期，“结束”字段表示最后一个日期。结束日期可以省略，以指示总账成员需要从指定的开始日期到当前日期的所有密钥。请注意，需要一个过程机制来限制用户访问不允许他们访问的消息。
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成员可能需要从GLA确定有关GL的一些信息。GLOs和GL成员使用第3.1.10.1节中定义的glaQueryRequest请求信息，GLAs使用第3.1.10.2节中定义的glaQueryResponse返回请求信息。第3.1.10.3节包括一个请求和响应类型和值；其他可在其他文件中定义。
GLOs and GL members use the glaQueryRequest to ascertain information about the GLA. The glaQueryRequest control attribute has the syntax GLAQueryRequest:
GLO和GL成员使用glaQueryRequest来确定有关GLA的信息。glaQueryRequest控件属性的语法为glaQueryRequest：
GLAQueryRequest ::= SEQUENCE {
glaRequestType OBJECT IDENTIFIER,
glaRequestValue ANY DEFINED BY glaRequestType }
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 }
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 }
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定义了一个请求/响应对，用于查询GLA支持的算法列表。glaQueryType字段中包括以下对象标识符（OID）：
id-cmc-gla-skdAlgRequest OBJECT IDENTIFIER ::={ id-cmc-glaRR 1 }
id-cmc-gla-skdAlgRequest OBJECT IDENTIFIER ::={ id-cmc-glaRR 1 }
SKDAlgRequest ::= NULL
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 }
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]中定义的smimeCapabilities属性的形式。
GLAs and GLOs use the glProvideCert to request that a GL member provide an updated or new encryption certificate. The glProvideCert message MUST be signed by either GLA or GLO. If the GL member's PKC has been revoked, the GLO or GLA MUST NOT use it to generate the EnvelopedData that encapsulates the glProvideCert request. The glProvideCert control attribute has the syntax GLManageCert:
GLAs和GLOs使用glProvideCert请求GL成员提供更新的或新的加密证书。glProvideCert消息必须由GLA或GLO签名。如果GL成员的PKC已撤销，GLO或GLA不得使用它生成封装glProvideCert请求的信封数据。GLProviderCert控件属性的语法为GLManageCert：
GLManageCert ::= SEQUENCE {
glName GeneralName,
glMember GLMember }
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表示总账成员的新证书要关联到的总账的名称。
- glMember indicates particulars for the GL member:
- glMember表示总账成员的详细信息：
-- glMemberName indicates the GL member's name.
--glMemberName表示总账成员的名称。
-- glMemberAddress indicates the GL member's address. It MAY be omitted.
--glMemberAddress表示总账成员的地址。可以省略。
-- 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。如果德国劳埃德船级社成员的加密证书已被吊销，德国劳埃德船级社成员不得使用该证书生成封装glUpdateCert请求或响应的信封数据。glUpdateCert控件属性的语法为GLManageCert:
GLManageCert ::= SEQUENCE {
glName GeneralName,
glMember GLMember }
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表示总账成员的新证书应关联到的总账的名称。
- glMember indicates the particulars for the GL member:
- glMember表示总账成员的详细信息：
-- glMemberName indicates the GL member's name.
--glMemberName表示总账成员的名称。
-- glMemberAddress indicates the GL member's address. It MAY be omitted.
--glMemberAddress表示总账成员的地址。可以省略。
-- certificates MAY be omitted if the GLManageCert message is sent to request the GL member's certificate; otherwise, it MUST be included. It includes the following three fields:
--如果发送GLManageCert消息以请求GL成员的证书，则可以省略证书；否则，它必须包括在内。它包括以下三个字段：
--- certificates.pKC includes the member's encryption
certificate that will be used to encrypt the shared KEK
for that member.
--- certificates.pKC includes the member's encryption
certificate that will be used to encrypt the shared KEK
for that member.
--- certificates.aC MAY be included to convey one or more
attribute certificates associated with the member's
encryption certificate.
--- certificates.aC MAY be included to convey one or more
attribute certificates associated with the member's
encryption certificate.
--- certificates.certPath MAY also be included to convey
certificates that might aid the recipient in
constructing valid certification paths for the
certificate provided in certificates.pKC and the
attribute certificates provided in certificates.aC.
These certificates are optional because they might
already be included elsewhere in the message (e.g., in
the outer CMS layer).
--- certificates.certPath MAY also be included to convey
certificates that might aid the recipient in
constructing valid certification paths for the
certificate provided in certificates.pKC and the
attribute certificates provided in certificates.aC.
These certificates are optional because they might
already be included elsewhere in the message (e.g., in
the outer CMS layer).
The GLA uses the glKey to distribute the shared KEK. The glKey message MUST be signed by the GLA. The glKey control attribute has the syntax GLKey:
GLA使用glKey分发共享KEK。glKey消息必须由GLA签名。glKey控件属性的语法为glKey：
GLKey ::= SEQUENCE {
glName GeneralName,
glIdentifier KEKIdentifier, -- See [CMS]
glkWrapped RecipientInfos, -- See [CMS]
glkAlgorithm AlgorithmIdentifier,
glkNotBefore GeneralizedTime,
glkNotAfter GeneralizedTime }
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 is included only for illustrative purposes as
-- it is imported from [CMS].
KEKIdentifier ::= SEQUENCE {
keyIdentifier OCTET STRING,
date GeneralizedTime OPTIONAL,
other OtherKeyAttribute OPTIONAL }
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是总账的名称。
- 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的包装共享桶。接收方信息必须按照[CMS]第6.2节的规定生成。必须支持ktri RecipientInfo选项。EncryptedKey字段中的密钥（即分布式共享KEK）必须根据[CMS]安全注意事项中有关随机数生成的部分生成。
- glkAlgorithm identifies the algorithm with which the shared KEK is used. Since no encrypted data content is being conveyed at this point, the parameters encoded with the algorithm should be the structure defined for smimeCapabilities rather than encrypted content.
- glkAlgorithm确定使用共享KEK的算法。由于此时未传输加密数据内容，因此使用算法编码的参数应为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.
- glkNotBefore表示共享KEK被视为有效的日期。泛化时间值必须以UTC（Zulu）表示，并且必须包括秒（即时间为YYYYMMDDHHMMSSZ），即使秒数为零。GeneralizedTime值不能包含小数秒。
- glkNotAfter indicates the date after which the shared KEK is considered invalid. GeneralizedTime values MUST be expressed in UTC (Zulu) and MUST include seconds (i.e., times are YYYYMMDDHHMMSSZ), even where the number of seconds is zero. GeneralizedTime values MUST NOT include fractional seconds.
- glkNotAfter表示共享KEK被视为无效的日期。泛化时间值必须以UTC（Zulu）表示，并且必须包括秒（即时间为YYYYMMDDHHMMSSZ），即使秒数为零。GeneralizedTime值不能包含小数秒。
If the glKey message is in response to a glUseKEK message:
如果glKey消息是对glUseKEK消息的响应：
- The GLA MUST generate separate glKey messages for each recipient if glUseKEK.glKeyAttributes.recipientsNotMutuallyAware is set to TRUE. For each recipient, you want to generate a message that contains that recipient's key (i.e., one message with one attribute).
- 如果glUseKEK.glKeyAttributes.RecipientsNotMutuallyWare设置为TRUE，GLA必须为每个收件人生成单独的glKey消息。对于每个收件人，您希望生成一封包含该收件人密钥的邮件（即一封带有一个属性的邮件）。
- The GLA MUST generate the requested number of glKey messages. The value in glUseKEK.glKeyAttributes.generationCounter indicates the number of glKey messages requested.
- GLA必须生成请求数量的glKey消息。glUseKEK.glKeyAttributes.generationCounter中的值表示请求的glKey消息数。
If the glKey message is in response to a glRekey message:
如果glKey消息响应glRekey消息：
- The GLA MUST generate separate glKey messages for each recipient if glRekey.glNewKeyAttributes.recipientsNotMutuallyAware is set to TRUE.
- 如果glRekey.glNewKeyAttributes.recipientsNotMutuallyAware设置为TRUE，GLA必须为每个收件人生成单独的glKey消息。
- The GLA MUST generate the requested number of glKey messages. The value in glUseKEK.glKeyAttributes.generationCounter indicates the number of glKey messages requested.
- GLA必须生成请求数量的glKey消息。glUseKEK.glKeyAttributes.generationCounter中的值表示请求的glKey消息数。
- The GLA MUST generate one glKey message for each outstanding shared KEKs for the GL when glRekeyAllGLKeys is set to TRUE.
- glRekeyAllGLKeys设置为TRUE时，GLA必须为GL的每个未完成共享KEK生成一条glKey消息。
If the glKey message was not in response to a glRekey or glUseKEK (e.g., where the GLA controls rekey):
如果glKey消息未响应glRekey或glUseKEK（例如，GLA控制rekey）：
- The GLA MUST generate separate glKey messages for each recipient when glUseKEK.glNewKeyAttributes.recipientsNotMutuallyAware that set up the GL was set to TRUE.
- 当设置GL的glUseKEK.glNewKeyAttributes.RecipientsNotMutuallyWare设置为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可以在最后一个未完成的共享KEK到期的持续时间之前生成glKey消息，其中生成的glKey消息数为generationCounter减去一（1）。还可以支持其他分发机制来支持此功能。
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有多种方法。第一种是在每个ContentInfo周围使用MIME包装，如[MSG]中所指定。第二种方法是不在每个ContentInfo周围使用MIME包装，正如在X.400[X400TRANS]中传输S/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:
至少，签名数据必须保护封装在PKIData和PKIResponse中的每个请求和响应。以下是最低包装的说明：
Minimum Protection
------------------
SignedData
PKIData or PKIResponse
controlSequence
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]处理签名数据。
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，以提供封装的EnvelopedData的身份验证和完整性。以下是可选附加包装的说明：
Authentication and Integrity
Confidentiality Protection of Confidentiality Protection
-------------------------- -----------------------------
EnvelopedData SignedData
SignedData EnvelopedData
PKIData or PKIResponse SignedData
controlSequence PKIData or PKIResponse
controlSequence
Authentication and Integrity
Confidentiality Protection of Confidentiality Protection
-------------------------- -----------------------------
EnvelopedData SignedData
SignedData EnvelopedData
PKIData or PKIResponse SignedData
controlSequence PKIData or PKIResponse
controlSequence
If an incoming message is encrypted, the confidentiality of the message MUST be preserved. All EnvelopedData objects MUST be processed as specified in [CMS]. If a SignedData is added over an EnvelopedData, a ContentHints attribute SHOULD be added. See Section 2.9 of Extended Security Services for S/MIME [ESS].
如果传入消息经过加密，则必须保留消息的机密性。必须按照[CMS]中的规定处理所有EnvelopedData对象。如果在EnvelopedData上添加SignedData，则应添加ContentHights属性。有关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成员对请求保密，则信封数据必须包括GLA作为收件人。如果GLA将GL成员请求转发给GLO，则GLA必须解密信封数据内容，剥离保密层，并将其自身的保密层作为信封数据应用，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:
一个PKIData.controlSequence或PKIResponse.controlSequence中可能包含与总账对应的多个请求和响应。通过使用PKIData.cmsSequence和pkisresponse.cmsSequence，可以将多个GLs的请求和响应组合在一个PKIData或PKIResponse中。不同的GLs必须使用单独的CMS序列。也就是说，对应于两个不同GLs的请求包含在不同的CMS序列中。下图描述了组合在一个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
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:
当对多个请求和响应应用机密性时，所有请求/响应都可以包含在一个信封数据中。以下为描述：
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
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:
不允许一个PKIData.controlSequence和一个PKIResponse.controlSequence中的某些请求组合。不得生成此处列出的无效组合：
Invalid Combinations
---------------------------
glUseKEK & glDeleteMember
glUseKEK & glRekey
glUseKEK & glDelete
glDelete & glAddMember
glDelete & glDeleteMember
glDelete & glRekey
glDelete & glAddOwner
glDelete & glRemoveOwner
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.
为避免不必要的错误，某些请求和响应应在其他请求和响应之前进行处理。以下是消息处理的优先级，如果未列出，则将由实现决定首先处理哪一个：GladMember之前的glUseKEK、GladMember之前的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生成成功或失败消息时，它会为每个请求生成一条消息。未支持的持续时间、未支持的送达方式、未支持的送达方式、noGLONameMatch、NameReadyUse、alreadyAnOwner和notAnOwner的SKDFailInfo值不会返回给GL成员。
If GLKeyAttributes.recipientsNotMutuallyAware is set to TRUE, a separate PKIResponse.cMCStatusInfoExt and PKIData.glKey MUST be generated for each recipient. However, it is valid to send one message with multiple attributes to the same recipient.
如果GLKeyAttributes.recipientsNotMutuallyAware设置为TRUE，则必须为每个收件人生成单独的PKIResponse.cMCStatusInfoExt和PKIData.glKey。但是，向同一收件人发送一封具有多个属性的邮件是有效的。
If the GL has multiple GLOs, the GLA MUST send cMCStatusInfoExt messages to the requesting GLO. The mechanism to determine which GLO made the request is beyond the scope of this document.
如果总账有多个GLO，GLA必须向请求GLO发送cMCStatusInfoExt消息。确定由哪个GLO提出请求的机制超出了本文件的范围。
If a GL is managed and the GLA receives a glAddMember, glDeleteMember, or glkCompromise message, the GLA redirects the request to the GLO for review. An additional, SignedData MUST be applied to the redirected request as follows:
如果GL已被管理，且GLA收到glAddMember、GLDETEEMBER或glkCompromise消息，则GLA会将请求重定向至GLO进行审查。必须对重定向请求应用附加的已签名数据，如下所示：
GLA Forwarded Requests
----------------------
SignedData
PKIData
cmsSequence
SignedData
PKIData
controlSequence
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]中定义。其中一些属性是必需的；其他是可选的。所需的属性如下：cMCStatusInfoExt transactionId、SenderOnce、recipientNonce、queryPending和signingTime。也可以使用其他属性；但是，它们的使用超出了本文件的范围。除[CMC]和[CMS]中已规定的要求外，以下章节还规定了其他要求。
cMCStatusInfoExt is used by GLAs to indicate to GLOs and GL members that a request was unsuccessful. Two classes of failure codes are used within this document. Errors from the CMCFailInfo list, found in Section 5.1.4 of CMC, are encoded as defined in CMC. Error codes defined in this document are encoded using the ExtendedFailInfo field of the cmcStatusInfoExt structure. If the same failure code applies to multiple commands, a single cmcStatusInfoExt structure can be used with multiple items in cMCStatusInfoExt.bodyList. The GLA MAY also return other pertinent information in statusString. The SKDFailInfo object identifier and value are:
GLAs使用cMCStatusInfoExt向GLOs和GL成员指示请求未成功。本文件中使用了两类故障代码。CMC第5.1.4节中的CMCFailInfo列表中的错误按照CMC中的定义进行编码。本文档中定义的错误代码使用cmcStatusInfoExt结构的ExtendedFailInfo字段进行编码。如果相同的故障代码适用于多个命令，则单个cmcStatusInfoExt结构可用于cmcStatusInfoExt.bodyList中的多个项目。GLA还可以在statusString中返回其他相关信息。SKDFailInfo对象标识符和值为：
id-cet-skdFailInfo OBJECT IDENTIFIER ::= { iso(1)
identified-organization(3) dod(6) internet(1) security(5)
mechanisms(5) pkix(7) cet(15) skdFailInfo(1) }
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),
SKDFailInfo ::= INTEGER {
unspecified (0),
closedGL (1),
unsupportedDuration (2),
noGLACertificate (3),
invalidCert (4),
unsupportedAlgorithm (5),
noGLONameMatch (6),
invalidGLName (7),
nameAlreadyInUse (8),
noSpam (9),
-- obsolete (10), alreadyAMember (11), notAMember (12), alreadyAnOwner (13), notAnOwner (14) }
--过时（10）、alreadyAMember（11）、NotalMember（12）、alreadyAnOwner（13）、notAnOwner（14）}
The values have the following meaning:
这些值具有以下含义：
- unspecified indicates that the GLA is unable or unwilling to perform the requested action and does not want to indicate the reason.
- 未指定表示GLA无法或不愿意执行请求的操作，并且不想说明原因。
- closedGL indicates that members can only be added or deleted by the GLO.
- closedGL表示只能由GLO添加或删除成员。
- unsupportedDuration indicates that the GLA does not support generating keys that are valid for the requested duration.
- unsupportedDuration表示GLA不支持生成在请求的持续时间内有效的密钥。
- noGLACertificate indicates that the GLA does not have a valid certificate.
- NoGlaceCertificate表示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表示用于签署请求的证书中的一个名称与已注册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表示GLA上已分配glName。
- 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.
- AlreadyMember表示潜在总账会员已经是总账会员。
- notAMember indicates that the prospective GL member to be deleted is not presently a GL member.
- notalmember表示要删除的潜在总账会员当前不是总账会员。
- alreadyAnOwner indicates that the prospective GLO is already a GLO.
- alreadyAnOwner表示潜在的GLO已经是GLO。
- notAnOwner indicates that the prospective GLO to be deleted is not presently a GLO.
- notAnOwner指出，要删除的预期GLO目前不是GLO。
cMCStatusInfoExt is used by GLAs to indicate to GLOs and GL members that a request was successfully completed. If the request was successful, the GLA returns a cMCStatusInfoExt response with cMCStatus.success and optionally other pertinent information in statusString.
GLAs使用cMCStatusInfoExt向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.
当总账得到管理且GLO审查了总账会员发起的glAddMember、GLDELETEEMBER和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.
GLOs、GLAs和GL成员使用cMCStatusInfoExt来指示签名验证失败。如果签名未能通过除cMCStatusInfoExt以外的任何控制属性进行验证，则必须返回一个cMCStatusInfoExt控制属性，指示cMCStatus.failed和otherInfo.failInfo.badMessageCheck。如果最外层PKIData上的签名失败，则bodyList值为零（0）。如果对任何其他PKIData的签名失败，则bodyList值是请求或响应中的bodyPartId值。收到签名无效的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.
GLOs和GLAs也使用cMCStatusInfoExt来表示无法立即执行请求。如果GLA或GLO无法立即处理该请求，则必须返回cMCStatusInfoExt控制属性，指示cMCStatus.pending和otherInfo.pendInfo。当请求被重定向到GLO进行审批（对于托管列表），GLA不得返回指示查询挂起的cMCStatusInfoExt。
cMCStatusInfoExt is also used by GLAs to indicate that a glaQueryRequest is not supported. If the glaQueryRequest is not supported, the cMCStatusInfoExt control attribute MUST be returned indicating cMCStatus.noSupport and statusString is optionally returned to convey additional information.
GLAs还使用cMCStatusInfoExt来表示不支持glaQueryRequest。如果不支持glaQueryRequest，则必须返回cMCStatusInfoExt控件属性，指示cMCStatus.noSupport，并且可以选择返回statusString以传递附加信息。
cMCStatusInfoExt is also used by GL members, GLOs, and GLAs to indicate that the signingTime (see Section 3.2.4.3) is not close enough to the locally specified time. If the local time is not close enough to the time specified in signingTime, a cMCStatus.failed and otherInfo.failInfo.badTime MAY be returned.
德国劳埃德船级社成员、GLO和GLA也使用cMCStatusInfoExt来表示签约时间（见第3.2.4.3节）与当地规定的时间不够接近。如果本地时间与signingTime中指定的时间不够接近，则可能会返回cMCStatus.failed和otherInfo.failInfo.badTime。
transactionId MAY be included by GLOs, GLAs, or GL members to identify a given transaction. All subsequent requests and responses related to the original request MUST include the same transactionId control attribute. If GL members include a transactionId and the request is redirected to the GLO, the GLA MAY include an additional transactionId in the outer PKIData. If the GLA included an additional transactionId in the outer PKIData, when the GLO generates a cMCStatusInfoExt response it generates one for the GLA with the GLA's transactionId and one for the GL member with the GL member's transactionId.
GLO、GLAs或GL成员可以包括transactionId以识别给定的交易。与原始请求相关的所有后续请求和响应必须包含相同的transactionId控制属性。如果GL成员包括transactionId，并且请求被重定向到GLO，则GLA可以在外部PKI数据中包括额外的transactionId。如果GLA在外部PKI数据中包含额外的transactionId，当GLO生成cMCStatusInfoExt响应时，它会为GLA生成一个带有GLA transactionId的响应，为GL成员生成一个带有GL成员transactionId的响应。
The use of nonces (see Section 5.6 of [CMC]) and an indication of when the message was signed (see Section 11.3 of [CMS]) can be used to provide application-level replay prevention.
使用nonce（见[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.
为保护总账，所有消息必须包含signingTime属性。然后，邮件发起人和收件人可以使用此属性中提供的时间来确定他们以前是否收到过邮件。
If the originating message includes a senderNonce, the response to the message MUST include the received senderNonce value as the recipientNonce and a new value as the senderNonce value in the response.
如果原始消息包括SenderOnce，则对该消息的响应必须包括接收到的SenderOnce值作为recipientNonce，以及响应中的新值作为SenderOnce值。
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
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.)
管理总帐时，GLA通过创建一条新的请求消息，将总帐成员请求作为CMS序列项包含在内，将总帐成员请求转发给GLO进行GLO批准。如果GLO批准请求，它可以添加新的包装层并将其发送回GLA，或者创建新消息并将其发送给GLA。（请注意，在这种情况下，现在有3层具有适当签名层的PKIData消息。）
Signatures, certificates, and CRLs are verified according to the PKIX profile [PROFILE].
签名、证书和CRL根据PKIX配置文件[profile]进行验证。
Name matching is performed according to the PKIX profile [PROFILE].
根据PKIX配置文件[profile]执行名称匹配。
All distinguished name forms must follow the UTF8String convention noted in the PKIX profile [PROFILE].
所有可分辨名称表单必须遵循PKIX配置文件[profile]中注明的UTF8String约定。
A certificate per GL would be issued to the GLA.
根据德国劳埃德船级社向GLA颁发证书。
GL policy may mandate that the GL member's address be included in the GL member's certificate.
德国劳埃德船级社政策可能要求德国劳埃德船级社成员的地址包含在德国劳埃德船级社成员的证书中。
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.
管理总账必须交换许多管理消息。以下各节详细描述了每个请求和响应消息组合。本节中定义的程序不是规定性的。
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.
在生成组密钥之前，需要设置总账并将共享KEK分配给总账。图3描述了设置和分配共享KEK的协议交互。请注意，图3中没有描述错误消息。此外，可选transactionId、SenderOnce和recipientNonce CMC控件属性的行为在这些过程中没有解决。
+-----+ 1 2 +-----+
| GLA | <-------> | GLO |
+-----+ +-----+
+-----+ 1 2 +-----+
| GLA | <-------> | GLO |
+-----+ +-----+
Figure 3 - Create Group List
图3-创建组列表
The process is as follows:
程序如下：
1 - The GLO is the entity responsible for requesting the creation of the GL. The GLO sends a SignedData.PKIData.controlSequence.glUseKEK request to the GLA (1 in Figure 3). The GLO MUST include glName, glAddress, glOwnerName, glOwnerAddress, and glAdministration. The GLO MAY also include their preferences for the shared KEK in glKeyAttributes by indicating whether the GLO controls the rekey in rekeyControlledByGLO, whether separate glKey messages should be sent to each recipient in recipientsNotMutuallyAware, the requested algorithm to be used with the shared KEK in requestedAlgorithm, the duration of the shared KEK, and how many shared KEKs should be initially distributed in generationCounter. The GLO MUST also include the signingTime attribute with this request.
1-GLO是负责请求创建总账的实体。GLO向GLA发送SignedData.PKIData.controlSequence.glUseKEK请求（图3中的1）。GLO必须包括glName、glAddress、glOwnerName、glOwnerAddress和glAdministration。GLO还可以通过指示GLO是否在rekeyControlledByGLO中控制rekey，是否应在Recipients NutuallyWare中向每个接收者发送单独的glKey消息，以及将在requestedAlgorithm中与共享KEK一起使用的请求算法，来在glKey属性中包括其对共享KEK的偏好，共享KEK的持续时间，以及最初应在generationCounter中分配多少个共享KEK。GLO还必须在该请求中包含signingTime属性。
1.a - If the GLO knows of members to be added to the GL, the glAddMember request(s) MAY be included in the same controlSequence as the glUseKEK request (see Section 3.2.2). The GLO indicates the same glName in the glAddMember request as in glUseKEK.glInfo.glName. Further glAddMember procedures are covered in Section 4.3.
1.a-如果GLO知道有成员将添加到GL中，则glAddMember请求可包含在与glUseKEK请求相同的控制顺序中（见第3.2.2节）。GLO在glAddMember请求中表示与glUseKEK.glInfo.glName中相同的glName。第4.3节介绍了更多的glAddMember程序。
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.PKI数据封装在信封数据中来为请求保密（参见第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还可以选择在信封数据上应用另一个签名数据（见第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上的签名。如果附加签名数据和/或信封数据封装了请求（见第3.2.1.2节和第3.2.2节），GLA在验证最内层签名数据上的签名之前验证外部签名和/或解密外层。
2.a - If the signingTime attribute value is not within the locally accepted time window, the GLA MAY return a response indicating cMCStatus.failed and otherInfo.failInfo.badTime and a signingTime attribute.
2.a-如果signingTime属性值不在本地接受的时间窗口内，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返回cMCStatusInfoExt响应，指示cMCStatus.failed和otherInfo.failInfo.badMessageCheck。此外，响应中还包含signingTime属性。
2.c - Else if the signatures do verify but the GLA does not have a valid certificate, the GLA returns a cMCStatusInfoExt with cMCStatus.failed and otherInfo.extendedFailInfo.SKDFailInfo value of noValidGLACertificate. Additionally, a signingTime attribute is included with the response. Instead of immediately returning the error code, the GLA attempts to get a certificate, possibly using [CMC].
2.c-否则，如果签名确实验证，但GLA没有有效的证书，GLA将返回一个cMCStatus.failed和otherInfo.extendedFailInfo.SKDFailInfo值为noValidGLACertificate的cMCStatus InfoExt。此外，响应中还包含signingTime属性。GLA不立即返回错误代码，而是尝试获取证书，可能使用[CMC]。
2.d - Else the signatures are valid and the GLA does have a valid certificate, the GLA checks that one of the names in the certificate used to sign the request matches one of the names in glUseKEK.glOwnerInfo.glOwnerName.
2.d-如果签名有效且GLA拥有有效证书，GLA将检查用于签署请求的证书中的一个名称是否与glUseKEK.glOwnerInfo.glOwnerName中的一个名称匹配。
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.extendedFailInfo.SKDFailInfo值为noGLONameMatch的cMCStatus InfoExt。此外，响应中还包含signingTime属性。
2.d.2 - Else if the names all match, the GLA checks that the glName and glAddress are not already in use. The GLA also checks any glAddMember included within the controlSequence with this glUseKEK. Further processing of the glAddMember is covered in Section 4.3.
2.d.2-否则，如果名称都匹配，GLA将检查glName和GladAddress是否尚未使用。GLA还使用此glUseKEK检查控制序列中包含的任何glAddMember。第4.3节介绍了glAddMember的进一步处理。
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和otherInfo.extendedFailInfo.SKDFailInfo值为nameAlreadyInUse的cMCStatus InfoExt。此外，响应中还包含signingTime属性。
2.d.2.b - Else if the requestedAlgorithm is not supported, the GLA returns a response indicating cMCStatusInfoExt with cMCStatus.failed and otherInfo.extendedFailInfo.SKDFailInfo value of unsupportedAlgorithm. Additionally, a signingTime attribute is included with the response.
2.d.2.b-否则，如果请求的算法不受支持，GLA将返回一个响应，指示cMCStatus.failed和otherInfo.extendedFailInfo.SKDFailInfo值为unsupportedAlgorithm的cMCStatus InfoExt。此外，响应中还包含signingTime属性。
2.d.2.c - Else if the duration cannot be supported, determining this is beyond the scope of this document, the GLA returns a response indicating cMCStatusInfoExt with cMCStatus.failed and otherInfo.extendedFailInfo.SKDFailInfo value of unsupportedDuration. Additionally, a signingTime attribute is included with the response.
2.d.2.c-否则，如果无法支持持续时间，则确定这超出了本文档的范围，GLA将返回一个响应，指示cMCStatus.failed和otherInfo.extendedFailInfo.SKDFailInfo值为unsupportedDuration的cMCStatus InfoExt。此外，响应中还包含signingTime属性。
2.d.2.d - Else if the GL cannot be supported for other reasons, which the GLA does not wish to disclose, the GLA returns a response indicating cMCStatusInfoExt with cMCStatus.failed and otherInfo.extendedFailInfo.SKDFailInfo value of unspecified. Additionally, a signingTime attribute is included with the response.
2.d.2.d-否则，如果由于GLA不希望披露的其他原因无法支持GL，GLA将返回一个响应，指示cMCStatus.failed和otherInfo.extendedFailInfo.SKDFailInfo值为未指定的cMCStatus InfoExt。此外，响应中还包含signingTime属性。
2.d.2.e - Else if the glName is not already in use, the duration can be supported, and the requestedAlgorithm is supported, the GLA MUST return a cMCStatusInfoExt indicating cMCStatus.success and a signingTime attribute. (2 in Figure 3). The GLA also takes administrative actions, which are beyond the scope of this document, to store the glName, glAddress, glKeyAttributes, glOwnerName, and glOwnerAddress. The GLA also sends a glKey message as described in section 5.
2.d.2.e-否则，如果glName尚未使用，则可以支持持续时间，并且支持requestedAlgorithm，GLA必须返回指示cMCStatus.success的cMCStatusInfoExt和signingTime属性。（图3中的2）。GLA还采取了超出本文档范围的管理措施来存储glName、glAddress、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.PKI响应封装在信封数据中对响应进行保密（参见第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还可以选择在信封数据上应用另一个签名数据（见第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签名。如果附加签名数据和/或信封数据封装了响应（参见第3.2.1.2或3.2.2节），则GLO在验证最内层签名数据上的签名之前，验证外部签名和/或解密外层。
3.a - If the signingTime attribute value is not within the locally accepted time window, the GLO MAY return a response indicating cMCStatus.failed and otherInfo.failInfo.badTime and a signingTime attribute.
3.a-如果signingTime属性值不在本地接受的时间窗口内，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必须检查用于签名响应的证书中的一个名称是否与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-否则，如果总账名称与证书中的名称不匹配，并且：
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-如果签名确实进行了验证，且响应为cMCStatusInfoExt，指示cMCStatus.success，则GLO已成功创建GL。
3.b.2.b - Else if the signatures are valid and the response is cMCStatusInfoExt.cMCStatus.failed with any reason, the GLO can reattempt to create the GL using the information provided in the response. The GLO can also use the glaQueryRequest to determine the algorithms and other characteristics supported by the GLA (see Section 4.9).
3.b.2.b-否则，如果签名有效且响应为cMCStatusInfoExt.cMCStatus.failed，则GLO可以使用响应中提供的信息重新尝试创建总账。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.
有时会出现不再需要总账的情况。在这种情况下，GLO将删除总账。图4描述了删除总账的协议交互。请注意，可选transactionId、SenderOnce和recipientNonce CMC控件属性的行为在这些过程中没有解决。
+-----+ 1 2 +-----+
| GLA | <-------> | GLO |
+-----+ +-----+
+-----+ 1 2 +-----+
| GLA | <-------> | GLO |
+-----+ +-----+
Figure 4 - Delete Group List
图4-删除组列表
The process is as follows:
程序如下：
1 - The GLO is responsible for requesting the deletion of the GL. The GLO sends a SignedData.PKIData.controlSequence.glDelete request to the GLA (1 in Figure 4). The name of the GL to be deleted is included in GeneralName. The GLO MUST also include the signingTime attribute and can also include a transactionId and senderNonce attributes.
1-GLO负责请求删除总账。GLO向GLA发送SignedData.PKIData.controlSequence.glDelete请求（图4中的1）。要删除的总账的名称包含在General name中。GLO还必须包括signingTime属性，还可以包括transactionId和SenderOnce属性。
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.PKI数据封装在信封数据中（参见第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可以选择在信封数据上应用另一个签名数据（见第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上的签名。如果额外的签名数据和/或信封数据封装了请求（参见第3.2.1.2或3.2.2节），GLA将在验证最内层签名数据上的签名之前验证外部签名和/或解密外层。
2.a - If the signingTime attribute value is not within the locally accepted time window, the GLA MAY return a response indicating cMCStatus.failed and otherInfo.failInfo.badTime and a signingTime attribute.
2.a-如果signingTime属性值不在本地接受的时间窗口内，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将返回一个cMCStatusInfoExt响应，指示cMCStatus.failed和otherInfo.failInfo.badMessageCheck。此外，响应中还包含signingTime属性。
2.c - Else if the signatures verify, the GLA makes sure the GL is supported by checking the name of the GL matches a glName stored on the GLA.
2.c-否则，如果签名验证，GLA通过检查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-如果GLA不支持glName，则GLA返回一个响应，指示cMCStatus.failed和otherInfo.extendedFailInfo.SKDFailInfo值为invalidGLName的cMCStatus InfoExt。此外，响应中还包含signingTime属性。
2.c.2 - Else if the glName is supported by the GLA, the GLA ensures that a registered GLO signed the glDelete request by checking if one of the names present in the digital signature certificate used to sign the glDelete request matches a registered GLO.
2.c.2-否则，如果GLA支持glName，则GLA通过检查用于签署glDelete请求的数字签名证书中的一个名称是否与注册GLO匹配，确保注册GLO签署了glDelete请求。
2.c.2.a - If the names do not match, the GLA returns a response indicating cMCStatusInfoExt with cMCStatus.failed and otherInfo.extendedFailInfo.SKDFailInfo value of noGLONameMatch. Additionally, a signingTime attribute is included with the response.
2.c.2.a-如果名称不匹配，GLA返回一个响应，指示cMCStatus.failed和otherInfo.extendedFailInfo.SKDFailInfo值为noGLONameMatch的cMCStatus InfoExt。此外，响应中还包含signingTime属性。
2.c.2.b - Else if the names do match, but the GL cannot be deleted for other reasons, which the GLA does not wish to disclose, the GLA returns a response indicating cMCStatusInfoExt with cMCStatus.failed and otherInfo.extendedFailInfo.SKDFailInfo value of unspecified. Additionally, a signingTime attribute is included with the response. Actions beyond the scope of this document must then be taken to delete the GL from the GLA.
2.c.2.b-否则，如果名称确实匹配，但由于GLA不希望披露的其他原因，GL无法删除，GLA将返回一个响应，指示cMCStatus.failed和otherInfo.extendedFailInfo.SKDFailInfo值为未指定的cMCStatus InfoExt。此外，响应中还包含signingTime属性。然后必须采取超出本文件范围的行动，从GLA中删除总账。
2.c.2.c - Else if the names do match, the GLA returns a cMCStatusInfoExt indicating cMCStatus.success and a signingTime attribute (2 in Figure 4). The GLA ought not accept further requests for member additions, member deletions, or group rekeys for this GL.
2.c.2.c-否则，如果名称匹配，GLA将返回一个指示cMCStatus.success的cMCStatusInfoExt和一个signingTime属性（图4中的2）。GLA不应接受该GL的成员添加、成员删除或组密钥的进一步请求。
2.c.2.c.1 - The GLA can apply confidentiality to the response by encapsulating the SignedData.PKIResponse in an EnvelopedData if the request was encapsulated in an EnvelopedData (see Section 3.2.1.2).
2.c.2.c.1-如果请求封装在信封数据中，GLA可以通过将SignedData.PKI响应封装在信封数据中对响应进行保密（参见第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可以选择在信封数据上应用另一个签名数据（见第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签名。如果附加签名数据和/或信封数据封装了响应（参见第3.2.1.2或3.2.2节），则GLO在验证最内层签名数据上的签名之前，验证外部签名和/或解密外层。
3.a - If the signingTime attribute value is not within the locally accepted time window, the GLO MAY return a response indicating cMCStatus.failed and otherInfo.failInfo.badTime and a signingTime attribute.
3.a-如果signingTime属性值不在本地接受的时间窗口内，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将检查用于签名响应的证书中的一个名称是否与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-否则，如果总账名称与证书中的名称不匹配，并且：
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 infoext，指示cMCStatus.success，则GLO已成功删除GL。
3.b.2.b - Else if the signatures do verify and the response was cMCStatusInfoExt.cMCStatus.failed with any reason, the GLO can reattempt to delete the GL using the information provided in the response.
3.b.2.b-否则，如果签名确实验证，且响应因任何原因为cMCStatusInfoExt.cMCStatus.failed，则GLO可以使用响应中提供的信息重新尝试删除总账。
To add members to GLs, either the GLO or prospective members use the glAddMember request. The GLA processes GLO and prospective GL member requests differently though. GLOs can submit the request at any time to add members to the GL, and the GLA, once it has verified the request came from a registered GLO, should process it. If a prospective member sends the request, the GLA needs to determine how the GL is administered. When the GLO initially configured the GL, it set the GL to be unmanaged, managed, or closed (see Section 3.1.1). In the unmanaged case, the GLA merely processes the member's request. In the managed case, the GLA forwards the requests from the prospective members to the GLO for review. Where there are multiple GLOs for a GL, which GLO the request is forwarded to is beyond the scope of this document. The GLO reviews the request and either
要将成员添加到GLs，GLO或潜在成员使用glAddMember请求。GLA处理GLO和潜在GL成员请求的方式有所不同。GLO可以在任何时候提交向GL添加成员的请求，GLA在验证来自注册GLO的请求后应进行处理。如果潜在会员发送请求，GLA需要确定GL的管理方式。当GLO最初配置总账时，它将总账设置为非托管、托管或关闭（见第3.1.1节）。在非托管情况下，GLA仅处理成员的请求。在托管案例中，GLA将潜在成员的请求转发给GLO审查。如果一个总账有多个GLO，则请求转发给哪个GLO超出了本文档的范围。GLO审查请求，并且
rejects it or submits a reformed request to the GLA. In the closed case, the GLA will not accept requests from prospective members. The following sections describe the processing for the GLO(s), GLA, and prospective GL members depending on where the glAddMeber request originated, either from a GLO or from prospective members. Figure 5 depicts the protocol interactions for the three options. Note that the error messages are not depicted. Additionally, note that behavior for the optional transactionId, senderNonce, and recipientNonce CMC control attributes is not addressed in these procedures.
拒绝申请或向GLA提交修改后的申请。在已结案的情况下，GLA不会接受潜在会员的请求。以下各节描述了GLO、GLA和潜在GL成员的处理过程，具体取决于GLADMeber请求的来源（来自GLO或潜在成员）。图5描述了三个选项的协议交互。请注意，没有描述错误消息。此外，请注意，可选transactionId、SenderOnce和recipientNonce CMC控件属性的行为在这些过程中没有解决。
+-----+ 2,B{A} 3 +----------+
| GLO | <--------+ +-------> | Member 1 |
+-----+ | | +----------+
1 | |
+-----+ <--------+ | 3 +----------+
| GLA | A +-------> | ... |
+-----+ <-------------+ +----------+
|
| 3 +----------+
+-------> | Member n |
+----------+
+-----+ 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的密钥，以保持组成员发送的流量的机密性。添加成员时重新设置托管或已关闭总账密钥的选项是使用不同的组密钥生成新总账。第4.5节和第5节讨论了组密钥更新。
The process for GLO initiated glAddMember requests is as follows:
GLO发起的GladMember请求的流程如下：
1 - The GLO collects the pertinent information for the member(s) to be added (this may be done through an out-of-bands means). The GLO then sends a SignedData.PKIData.controlSequence with a separate glAddMember request for each member to the GLA (1 in Figure 5). The GLO includes the GL name in glName, the member's name in glMember.glMemberName, the member's address in glMember.glMemberAddress, and the member's encryption certificate in glMember.certificates.pKC. The GLO can also include any attribute certificates associated with the member's encryption
1-GLO为要添加的成员收集相关信息（这可以通过带外方式完成）。然后，GLO向GLA发送SignedData.PKIData.controlSequence，以及每个成员的单独GladMember请求（图5中的1）。GLO包括glName中的GL名称、glMember.glMemberName中的成员名称、glMember.glMemberAddress中的成员地址以及glMember.certificates.pKC中的成员加密证书。GLO还可以包括与成员的加密相关联的任何属性证书
certificate in glMember.certificates.aC, and the certification path associated with the member's encryption and attribute certificates in glMember.certificates.certPath. The GLO MUST also include the signingTime attribute with this request.
glMember.certificates.aC中的证书，以及与glMember.certificates.certPath中成员的加密和属性证书关联的证书路径。GLO还必须在该请求中包含signingTime属性。
1.a - The GLO can optionally apply confidentiality to the request by encapsulating the SignedData.PKIData in an EnvelopedData (see Section 3.2.1.2).
1.a-GLO可以通过将SignedData.PKI数据封装在信封数据中（参见第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还可以选择在信封数据上应用另一个签名数据（见第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上的签名。如果额外的签名数据和/或信封数据封装了请求（参见第3.2.1.2或3.2.2节），GLA将在验证最内层签名数据上的签名之前验证外部签名和/或解密外层。
2.a - If the signingTime attribute value is not within the locally accepted time window, the GLA MAY return a response indicating cMCStatus.failed and otherInfo.failInfo.badTime and a signingTime attribute.
2.a-如果signingTime属性值不在本地接受的时间窗口内，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将返回一个cMCStatusInfoExt响应，指示cMCStatus.failed和otherInfo.failInfo.badMessageCheck。此外，响应中还包含signingTime属性。
2.c - Else if the signatures verify, the glAddMember request is included in a controlSequence with the glUseKEK request, and the processing in Section 4.1 item 2.d is successfully completed, the GLA returns a cMCStatusInfoExt indicating cMCStatus.success and a signingTime attribute (2 in Figure 5).
2.c-否则，如果签名验证，GladMember请求包含在glUseKEK请求的控制序列中，并且第4.1节第2.d项中的处理成功完成，GLA将返回一个指示cMCStatus.success的cMCStatusInfoExt和一个signingTime属性（图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.PKI数据封装在信封数据中为响应保密（参见第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还可以选择在信封数据上应用另一个签名数据（见第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-否则，如果签名验证且GLADMember请求未包含在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-如果GLA不支持glName，则GLA返回一个响应，指示cMCStatus.failed和otherInfo.extendedFailInfo.SKDFailInfo值为invalidGLName的cMCStatus InfoExt。此外，响应中还包含signingTime属性。
2.d.2 - Else if the glName is supported by the GLA, the GLA checks to see if the glMemberName is present on the GL.
2.d.2-否则，如果GLA支持glName，GLA将检查glMemberName是否存在于GL上。
2.d.2.a - If the glMemberName is present on the GL, the GLA returns a response indicating cMCStatusInfoExt with cMCStatus.failed and otherInfo.extendedFailInfo.SKDFailInfo value of alreadyAMember. Additionally, a signingTime attribute is included with the response.
2.d.2.a-如果总账上存在glMemberName，GLA将返回一个响应，指示cMCStatusInfoExt的值为cMCStatus.failed，其他值为AlreadyMember的值为otherInfo.extendedFailInfo.SKDFailInfo。此外，响应中还包含signingTime属性。
2.d.2.b - Else if the glMemberName is not present on the GL, the GLA checks how the GL is administered.
2.d.2.b-否则，如果总账上没有glMemberName，GLA将检查总账的管理方式。
2.d.2.b.1 - If the GL is closed, the GLA checks that a registered GLO signed the request by checking that one of the names in the digital signature certificate used to sign the request matches a registered GLO.
2.d.2.b.1-如果GL关闭，GLA通过检查用于签署请求的数字签名证书中的一个名称是否与注册GLO匹配来检查注册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返回一个响应，指示cMCStatusInfoExt的cMCStatus.failed和otherInfo.extendedFailInfo.SKDFailInfo值为noGLONameMatch。此外，响应中还包含signingTime属性。
2.d.2.b.1.b - Else if the names match, the GLA verifies the member's encryption certificate.
2.d.2.b.1.b-否则，如果名称匹配，GLA将验证成员的加密证书。
2.d.2.b.1.b.1 - If the member's encryption certificate cannot be verified, the GLA can return a response indicating cMCStatusInfoExt with cMCStatus.failed and otherInfo.extendedFailInfo.SKDFailInfo value of invalidCert to the GLO.
2.d.2.b.1.b.1-如果无法验证成员的加密证书，GLA可以向GLO返回一个响应，指示cMCStatus.failed和otherInfo.extendedFailInfo.SKDFailInfo值为invalidCert的cMCStatus InfoExt。
Additionally, a signingTime attribute is included with the response. If the GLA does not return a cMCStatusInfoExt.cMCStatus.failed response, the GLA issues a glProvideCert request (see Section 4.10).
此外，响应中还包含signingTime属性。如果GLA未返回cMCStatusInfoExt.cMCStatus.failed响应，GLA将发出GLProviderCert请求（参见第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的cMCStatusInfoExt和一个signingTime属性（图5中的2）。GLA还采取超出本文件范围的管理措施，将成员添加到GLA上存储的GL中。GLA还通过第5节所述的机制将共享KEK分配给成员。
2.d.2.b.1.b.2.a - The GLA applies confidentiality to the response by encapsulating the SignedData.PKIData in an EnvelopedData if the request was encapsulated in an EnvelopedData (see Section 3.2.1.2).
2.d.2.b.1.b.2.a-如果请求封装在信封数据中，GLA通过将SignedData.PKI数据封装在信封数据中对响应进行保密（参见第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还可以选择在信封数据上应用另一个签名数据（见第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，用于签署请求的证书中的一个名称需要与注册的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.extendedFailInfo.SKDFailInfo值为noSpam的cMCStatus InfoExt。此外，响应中还包含signingTime属性。
2.d.2.b.2.b - Else if the signer is a registered GLO, the GLA verifies the member's encryption certificate.
2.d.2.b.2.b-否则，如果签名者是注册的GLO，GLA将验证成员的加密证书。
2.d.2.b.2.b.1 - If the member's certificate cannot be verified, the GLA can return a response indicating cMCStatusInfoExt with cMCStatus.failed and otherInfo.extendedFailInfo.SKDFailInfo value of invalidCert. Additionally, a signingTime attribute is included with the response. If the GLA does not return a cMCStatus.failed response, the GLA MUST issue a glProvideCert request (see Section 4.10).
2.d.2.b.2.b.1-如果无法验证成员的证书，GLA可以返回一个响应，指示cMCStatusInfoExt的cMCStatus.failed和otherInfo.extendedFailInfo.SKDFailInfo值为invalidCert。此外，响应中还包含signingTime属性。如果GLA未返回cMCStatus.failed响应，则GLA必须发出glProvideCert请求（参见第4.10节）。
2.d.2.b.2.b.2 - Else if the member's certificate verifies, the GLA MUST return a cMCStatusInfoExt indicating cMCStatus.success and a signingTime attribute to the GLO (2 in Figure 5). The GLA also takes administrative actions, which are beyond the scope of this document, to add the member to the GL stored on the GLA. The GLA also distributes the shared KEK to the member via the mechanism described in Section 5. The GL policy may mandate that the GL member's address be included in the GL member's certificate.
2.d.2.b.2.b.2-否则，如果成员的证书经过验证，GLA必须向GLO返回指示cMCStatus.success的cMCStatusInfoExt和signingTime属性（图5中的2）。GLA还采取超出本文件范围的管理措施，将成员添加到GLA上存储的GL中。GLA还通过第5节所述的机制将共享KEK分配给成员。德国劳埃德船级社政策可能要求德国劳埃德船级社成员的地址包含在德国劳埃德船级社成员的证书中。
2.d.2.b.2.b.2.a - The GLA applies confidentiality to the response by encapsulating the SignedData.PKIData in an EnvelopedData if the request was encapsulated in an EnvelopedData (see Section 3.2.1.2).
2.d.2.b.2.b.2.a-如果请求封装在信封数据中，GLA通过将SignedData.PKI数据封装在信封数据中对响应进行保密（参见第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还可以选择在信封数据上应用另一个签名数据（见第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
2.d.2.b.2.c-否则，如果签名者是潜在会员，GLA将glAddMember请求（参见第3.2.3节）转发给注册的GLO（图5中的b{a}）。如果存在多个已注册的GLO，则请求转发到的GLO超出了本协议的范围
document. Further processing of the forwarded request by GLOs is addressed in 3 of Section 4.3.2.
文件GLOs对转发请求的进一步处理见第4.3.2节第3节。
2.d.2.b.2.c.1 - The GLA applies confidentiality to the forwarded request by encapsulating the SignedData.PKIData in an EnvelopedData if the original request was encapsulated in an EnvelopedData (see Section 3.2.1.2).
2.d.2.b.2.c.1-如果原始请求封装在信封数据中，GLA通过将SignedData.PKI数据封装在信封数据中对转发请求进行保密（参见第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还可以选择在信封数据上应用另一个签名数据（见第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-否则，如果总账处于非托管状态，GLA将检查注册GLO或潜在会员是否签署了请求。对于GLO，用于签署请求的证书中的一个名称需要与已注册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值为noSpam的cMCStatus InfoExt。此外，响应中还包含signingTime属性。
2.d.2.b.3.b - Else if the signer is either a registered GLO or the prospective member, the GLA verifies the member's encryption certificate.
2.d.2.b.3.b-否则，如果签名者是注册GLO或潜在会员，GLA将验证该会员的加密证书。
2.d.2.b.3.b.1 - If the member's certificate cannot be verified, the GLA can return a response indicating cMCStatusInfoExt with cMCStatus.failed and otherInfo.extendedFailInfo.SKDFailInfo value of invalidCert and a signingTime attribute to either the GLO or the prospective member depending on where the request originated. If the GLA does not return a cMCStatus.failed response, the GLA issues a glProvideCert request (see
2.d.2.b.3.b.1-如果无法验证成员的证书，GLA可以返回一个响应，指示cMCStatus.failed和otherInfo.extendedFailInfo.SKDFailInfo值为invalidCert的cMCStatus InfoExt以及GLO或潜在成员的signingTime属性，具体取决于请求的发起地。如果GLA未返回cMCStatus.failed响应，GLA将发出glProvideCert请求（请参阅
Section 4.10) to either the GLO or prospective member depending on where the request originated.
第4.10）节）向GLO或潜在成员发送，具体取决于请求的来源。
2.d.2.b.3.b.2 - Else if the member's certificate verifies, the GLA returns a cMCStatusInfoExt indicating cMCStatus.success and a signingTime attribute to the GLO (2 in Figure 5) if the GLO signed the request and to the GL member (3 in Figure 5) if the GL member signed the request. The GLA also takes administrative actions, which are beyond the scope of this document, to add the member to the GL stored on the GLA. The GLA also distributes the shared KEK to the member via the mechanism described in Section 5.
2.d.2.b.3.b.2-否则，如果成员的证书经过验证，GLA将向GLO（图5中的2）返回指示cMCStatus.success的cMCStatusInfoExt，如果GLO签署了请求，则向GL成员（图5中的3）返回signingTime属性。GLA还采取超出本文件范围的管理措施，将成员添加到GLA上存储的GL中。GLA还通过第5节所述的机制将共享KEK分配给成员。
2.d.2.b.3.b.2.a - The GLA applies confidentiality to the response by encapsulating the SignedData.PKIData in an EnvelopedData if the request was encapsulated in an EnvelopedData (see Section 3.2.1.2).
2.d.2.b.3.b.2.a-如果请求封装在信封数据中，GLA通过将SignedData.PKI数据封装在信封数据中对响应进行保密（参见第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还可以选择在信封数据上应用另一个签名数据（见第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签名。如果附加签名数据和/或信封数据封装了响应（参见第3.2.1.2或3.2.2节），则GLO在验证最内层签名数据上的签名之前，验证外部签名和/或解密外层。
3.a - If the signingTime attribute value is not within the locally accepted time window, the GLO MAY return a response indicating cMCStatus.failed and otherInfo.failInfo.badTime and a signingTime attribute.
3.a-如果signingTime属性值不在本地接受的时间窗口内，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将检查用于签名响应的证书中的一个名称是否与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-否则，如果总账名称与证书中的名称匹配，并且：
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 infoext，表示cMCStatus.success，则GLA已将该成员添加到GL中。如果该成员已添加到托管列表，且原始请求已由该成员签名，则GLO将向GL成员发送cMCStatusInfoExt.cMCStatus.success和signingTime属性。
3.b.2.b - Else if the GLO received a cMCStatusInfoExt.cMCStatus.failed with any reason, the GLO can reattempt to add the member to the GL using the information provided in the response.
3.b.2.b-否则，如果GLO因任何原因收到cMCStatusInfoExt.cMCStatus.failed，则GLO可以使用响应中提供的信息重新尝试将成员添加到总账中。
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签名。如果附加签名数据和/或信封数据封装了响应（参见第3.2.1.2或3.2.2节），则GLO在验证最内层签名数据上的签名之前，验证外部签名和/或解密外层。
4.a - If the signingTime attribute value is not within the locally accepted time window, the prospective member MAY return a response indicating cMCStatus.failed and otherInfo.failInfo.badTime and a signingTime attribute.
4.a-如果signingTime属性值不在本地可接受的时间窗口内，潜在成员可能会返回一个响应，指示cMCStatus.failed和otherInfo.failInfo.badTime以及signingTime属性。
4.b - Else if signature processing continues and if the signatures verify, the GL member checks that one of the names in the certificate used to sign the response matches the name of the GL.
4.b-否则，如果签名处理继续进行，并且签名验证，则总账成员将检查用于签名响应的证书中的一个名称是否与总账的名称匹配。
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-如果德国劳埃德船级社的名称与用于签署信息的证书中的名称不匹配，德国劳埃德船级社成员不应相信该响应。
4.b.2 - Else if the name of the GL matches the name present in the certificate and:
4.b.2-否则，如果总账名称与证书中的名称匹配，并且：
4.b.2.a - If the signatures verify, the prospective member has been added to the GL.
4.b.2.a-如果签名验证，则潜在成员已添加到总账中。
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，无论出于何种原因，潜在会员可以使用回复中提供的信息重新尝试将自己添加到总账中。
The process for prospective member initiated glAddMember requests is as follows:
潜在会员发起的格莱德会员请求流程如下：
1 - The prospective GL member sends a SignedData.PKIData.controlSequence.glAddMember request to the GLA (A in Figure 5). The prospective GL member includes: the GL name in glName, their name in glMember.glMemberName, their address in glMember.glMemberAddress, and their encryption certificate in glMember.certificates.pKC. The prospective GL member can also include any attribute certificates associated with their encryption certificate in glMember.certificates.aC, and the certification path associated with their encryption and attribute certificates in glMember.certificates.certPath. The prospective member MUST also include the signingTime attribute with this request.
1-潜在GL成员向GLA发送SignedData.PKIData.controlSequence.GladMember请求（图5中的a）。潜在GL成员包括：glName中的GL名称、glMember.glMemberName中的GL名称、glMember.glMemberAddress中的地址以及glMember.certificates.pKC中的加密证书。潜在GL成员还可以在glMember.certificates.aC中包含与其加密证书关联的任何属性证书，以及在glMember.certificates.certPath中包含与其加密和属性证书关联的证书路径。潜在会员还必须在此请求中包含signingTime属性。
1.a - The prospective GL member can optionally apply confidentiality to the request by encapsulating the SignedData.PKIData in an EnvelopedData (see Section 3.2.1.2).
1.a-潜在德国劳埃德船级社成员可以选择通过将SignedData.PKI数据封装在信封数据中对请求进行保密（见第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-潜在德国劳埃德船级社成员可选择在信封数据上应用另一个签名数据（见第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-如果signingTime属性值不在本地接受的时间窗口内，GLO可能会返回一个响应，指示cMCStatus.failed和otherInfo.failInfo.badTime。
3.b - Else if signature processing continues and if the signatures verify, the GLO checks to make sure one of the names in the certificate used to sign the request matches the name in glMember.glMemberName.
3.b-否则，如果签名处理继续进行并且签名验证，则GLO将检查以确保用于签名请求的证书中的一个名称与glMember.glMemberName中的名称匹配。
3.b.1 - If the names do not match, the GLO sends a SignedData.PKIResponse.controlSequence message back to the prospective member with cMCStatusInfoExt.cMCStatus.failed indicating why the prospective member was denied in cMCStausInfo.statusString. This stops people from adding people to GLs without their permission. Additionally, a signingTime attribute is included with the response.
3.b.1-如果名称不匹配，GLO会将SignedData.PKIResponse.controlSequence消息发送回潜在成员，并使用cMCStatusInfoExt.cMCStatus.failed指示在cMCStausInfo.statusString中拒绝潜在成员的原因。这将阻止用户在未经许可的情况下向GLs添加用户。此外，响应中还包含signingTime属性。
3.b.2 - Else if the names match, the GLO determines whether the prospective member is allowed to be added. The mechanism is beyond the scope of this document; however, the GLO should check to see that the glMember.glMemberName is not already on the GL.
3.b.2-否则，如果名称匹配，GLO将确定是否允许添加潜在成员。该机制超出了本文件的范围；但是，GLO应检查glMember.glMemberName是否不在总账上。
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中拒绝潜在成员的原因。此外，响应中还包含signingTime属性。
3.b.2.b - Else if the GLO determines the prospective member is allowed to join the GL, the GLO verifies the member's encryption certificate.
3.b.2.b-否则，如果GLO确定允许潜在会员加入GL，则GLO将验证该会员的加密证书。
3.b.2.b.1 - If the member's certificate cannot be verified, the GLO returns a SignedData.PKIResponse.controlSequence back to the prospective member with cMCStatusInfoExt.cMCtatus.failed indicating that the member's encryption certificate did not verify in cMCStatus.statusString. Additionally, a signingTime attribute is included with the response. If the GLO does not return a cMCStatusInfoExt response, the GLO sends a
3.b.2.b.1-如果无法验证成员的证书，则GLO将SignedData.PKIResponse.controlSequence返回给潜在成员，其中cMCStatusInfoExt.cMCtatus.failed表示该成员的加密证书未在cMCStatus.statusString中验证。此外，响应中还包含signingTime属性。如果GLO未返回cMCStatusInfoExt响应，则GLO将发送
SignedData.PKIData.controlSequence.glProvideCert message to the prospective member requesting a new encryption certificate (see Section 4.10).
SignedData.PKIData.controlSequence.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将向GLA重新提交glAddMember请求（参见第3.2.5节）（图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.PKI数据封装在信封数据中为新的GladMember请求保密（参见第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还可以选择在信封数据上应用另一个签名数据（见第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中删除成员，请使用glDeleteMember请求删除GLO或要删除的成员。GLA处理GLO，请求其自身免职的成员提出不同的请求。GLO可以在任何时候提交从GL中删除成员的请求，GLA在确认该请求来自注册GLO后，应删除该成员。如果成员发送请求，GLA需要确定GL的管理方式。当GLO最初配置总账时，它将总账设置为非托管、托管或关闭（见第3.1.1节）。在非托管情况下，GLA仅处理成员的请求。在托管情况下，GLA将成员的请求转发给GLO进行审查。如果一个总账有多个GLO，则请求转发给哪个GLO超出了本文档的范围。GLO审查该请求并拒绝该请求或向GLA提交一份修改后的请求。在已结案的情况下，GLA将不接受会员的请求。以下各节描述了GLO、GLA和GL成员的处理过程，具体取决于请求的来源（来自GLO或希望删除的成员）。图6描述了三个选项的协议交互。请注意，没有描述错误消息。此外，可选transactionId、SenderOnce和recipientNonce CMC控件属性的行为在这些过程中没有解决。
+-----+ 2,B{A} 3 +----------+
| GLO | <--------+ +-------> | Member 1 |
+-----+ | | +----------+
1 | |
+-----+ <--------+ | 3 +----------+
| GLA | A +-------> | ... |
+-----+ <-------------+ +----------+
|
| 3 +----------+
+-------> | Member n |
+----------+
+-----+ 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保护的数据，并将继续接收密钥。对于非托管列表，没有必要重新设置组密钥，因为无法保证请求删除的成员尚未以其他名称将自己添加回总账。对于托管和已关闭的总账，GLO需要采取措施确保被删除的成员不在总账上两次。确保这一点后，可以重新设置托管和关闭的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发送SignedData.PKIData.controlSequence，其中包含每个成员的单独glDeleteMember请求（图6中的1）。GLO必须在glName中包含总账名称，在glMemberToDelete中包含会员名称。如果要从中删除成员的总账是已关闭或管理的总账，则GLO还必须生成glRekey请求，并将其包括在glDeletemember请求中（参见第4.5节）。GLO还必须在该请求中包含signingTime属性。
1.a - The GLO can optionally apply confidentiality to the request by encapsulating the SignedData.PKIData in an EnvelopedData (see Section 3.2.1.2).
1.a-GLO可以通过将SignedData.PKI数据封装在信封数据中（参见第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还可以选择在信封数据上应用另一个签名数据（见第3.2.1.2节）。
2 - Upon receipt of the request, the GLA checks the signingTime attribute and verifies the signature on the innermost SignedData.PKIData. If an additional SignedData and/or EnvelopedData encapsulates the request (see Section 3.2.1.2 or 3.2.2), the GLA verifies the outer signature and/or decrypts the outer layer prior to verifying the signature on the innermost SignedData.
2-收到请求后，GLA检查signingTime属性并验证最内层SignedData.PKIData上的签名。如果额外的签名数据和/或信封数据封装了请求（参见第3.2.1.2或3.2.2节），GLA将在验证最内层签名数据上的签名之前验证外部签名和/或解密外层。
2.a - If the signingTime attribute value is not within the locally accepted time window, the GLA MAY return a response indicating cMCStatus.failed and otherInfo.failInfo.badTime and a signingTime attribute.
2.a-如果signingTime属性值不在本地接受的时间窗口内，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将返回一个cMCStatusInfoExt响应，指示cMCStatus.failed和otherInfo.failInfo.badMessageCheck。此外，响应中还包含signingTime属性。
2.c - Else if the signatures verify, the GLA makes sure the GL is supported by the GLA by checking that the glName matches a glName stored on the GLA.
2.c-否则，如果签名验证，GLA通过检查glName是否与GLA上存储的glName匹配，确保GLA支持GL。
2.c.1 - If the glName is not supported by the GLA, the GLA returns a response indicating cMCStatusInfoExt with cMCStatus.failed and otherInfo.extendedFailInfo.SKDFailInfo value of invalidGLName. Additionally, a signingTime attribute is included with the response.
2.c.1-如果GLA不支持glName，则GLA返回一个响应，指示cMCStatus.failed和otherInfo.extendedFailInfo.SKDFailInfo值为invalidGLName的cMCStatus InfoExt。此外，响应中还包含signingTime属性。
2.c.2 - Else if the glName is supported by the GLA, the GLA checks to see if the glMemberName is present on the GL.
2.c.2-否则，如果GLA支持glName，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，GLA将返回一个响应，指示cMCStatusInfoExt，其中cMCStatus.failed和otherInfo.extendedFailInfo.SKDFailInfo的值为notAMember。此外，响应中还包含signingTime属性。
2.c.2.b - Else if the glMemberName is already on the GL, the GLA checks how the GL is administered.
2.c.2.b-否则，如果glMemberName已在总账上，GLA将检查总账的管理方式。
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匹配来检查注册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 infoext的cMCStatus.failed和otherInfo.extendedFailInfo.SKDFailInfo值为closedGL。此外，响应中还包含signingTime属性。
2.c.2.b.1.b - Else if the names do match, the GLA returns a cMCStatusInfoExt.cMCStatus.success and a signingTime attribute (2 in Figure 5). The GLA also takes administrative actions, which are beyond the scope of this document, to delete the member with the GL stored on the GLA. Note that the GL also needs to be rekeyed as described in Section 5.
2.c.2.b.1.b-否则，如果名称匹配，GLA将返回一个cMCStatusInfoExt.cMCStatus.success和一个signingTime属性（图5中的2）。GLA还采取超出本文件范围的管理措施，删除GLA上存储有GL的成员。请注意，总账也需要按照第5节所述重新键入。
2.c.2.b.1.b.1 - The GLA applies confidentiality to the response by encapsulating the SignedData.PKIData in an EnvelopedData if the request was encapsulated in an EnvelopedData (see Section 3.2.1.2).
2.c.2.b.1.b.1-如果请求封装在信封数据中，GLA通过将SignedData.PKI数据封装在信封数据中对响应进行保密（参见第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还可以选择在信封数据上应用另一个签名数据（见第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，用于签署请求的证书中的一个名称需要与注册的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.extendedFailInfo.SKDFailInfo值为noSpam的cMCStatus InfoExt。此外，响应中还包含signingTime属性。
2.c.2.b.2.b - Else if the signer is a registered GLO, the GLA returns a cMCStatusInfoExt.cMCStatus.success and a signingTime attribute(2 in Figure 6). The GLA also takes administrative actions, which
2.c.2.b.2.b-否则，如果签名者是注册的GLO，GLA将返回一个cMCStatusInfoExt.cMCStatus.success和一个signingTime属性（图6中的2）。GLA还采取行政措施
are beyond the scope of this document, to delete the member with the GL stored on the GLA. Note that the GL will also be rekeyed as described in Section 5.
超出本文件范围，删除GLA上存储有总账的会员。请注意，总账也将按照第5节所述重新键入。
2.c.2.b.2.b.1 - The GLA applies confidentiality to the response by encapsulating the SignedData.PKIData in an EnvelopedData if the request was encapsulated in an EnvelopedData (see Section 3.2.1.2).
2.c.2.b.2.b.1-如果请求封装在信封数据中，GLA通过将SignedData.PKI数据封装在信封数据中对响应进行保密（参见第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还可以选择在信封数据上应用另一个签名数据（见第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请求（参见第3.2.3节）转发给GLO（图6中的b{A}）。如果存在多个已注册的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.PKI数据封装在信封数据中对转发的请求进行保密（参见第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还可以选择在信封数据上应用另一个签名数据（见第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-否则，如果总账处于非托管状态，GLA将检查注册GLO或潜在会员是否签署了请求。对于GLO，用于签署请求的证书中的一个名称需要与已注册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的cMCStatus InfoExt。此外，响应中还包含signingTime属性。
2.c.2.b.3.b - Else if the signer is either a registered GLO or the member, the GLA returns a cMCStatusInfoExt.cMCStatus.success and a signingTime attribute to the GLO (2 in Figure 6) if the GLO signed the request and to the GL member (3 in Figure 6) if the GL member signed the request. The GLA also takes administrative actions, which are beyond the scope of this document, to delete the member with the GL stored on the GLA.
2.c.2.b.3.b-否则，如果签名者是注册的GLO或成员，GLA将向GLO（图6中的2）返回cMCStatusInfoExt.cMCStatus.success和signingTime属性（如果GLO签署了请求），如果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.PKI数据封装在信封数据中对响应进行保密（参见第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还可以选择在信封数据上应用另一个签名数据（见第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签名。如果附加签名数据和/或信封数据封装了响应（参见第3.2.1.2或3.2.2节），则GLO在验证最内层签名数据上的签名之前，验证外部签名和/或解密外层。
3.a - If the signingTime attribute value is not within the locally accepted time window, the GLO MAY return a response indicating cMCStatus.failed and otherInfo.failInfo.badTime and a signingTime attribute.
3.a-如果signingTime属性值不在本地接受的时间窗口内，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将检查用于签名响应的证书中的一个名称是否与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-否则，如果总账名称与证书中的名称匹配，并且：
3.b.2.a - If the signatures verify and the response is cMCStatusInfoExt.cMCStatus.success, the GLO has deleted the member from the GL. If member was deleted from a managed list and the original request was signed by the member, the GLO sends a cMCStatusInfoExt.cMCStatus.success and a signingTime attribute to the GL member.
3.b.2.a-如果签名验证且响应为cMCStatusInfoExt.cMCStatus.success，则GLO已从GL中删除该成员。如果成员已从托管列表中删除，且原始请求已由该成员签名，则GLO将向GL成员发送cMCStatusInfoExt.cMCStatus.success和signingTime属性。
3.b.2.b - Else if the GLO received a cMCStatusInfoExt.cMCStatus.failed with any reason, the GLO may reattempt to delete the member from the GL using the information provided in the response.
3.b.2.b-否则，如果GLO因任何原因收到cMCStatusInfoExt.cMCStatus.failed，则GLO可以使用响应中提供的信息重新尝试从总账中删除该成员。
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签名。如果附加签名数据和/或信封数据封装了响应（参见第3.2.1.2或3.2.2节），则GLO在验证最内层签名数据上的签名之前，验证外部签名和/或解密外层。
4.a - If the signingTime attribute value is not within the locally accepted time window, the prospective member MAY return a response indicating cMCStatus.failed and otherInfo.failInfo.badTime and a signingTime attribute.
4.a-如果signingTime属性值不在本地可接受的时间窗口内，潜在成员可能会返回一个响应，指示cMCStatus.failed和otherInfo.failInfo.badTime以及signingTime属性。
4.b - Else if signature processing continues and if the signatures verify, the GL member checks that one of the names in the certificate used to sign the response matches the name of the GL.
4.b-否则，如果签名处理继续进行，并且签名验证，则总账成员将检查用于签名响应的证书中的一个名称是否与总账的名称匹配。
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-如果德国劳埃德船级社的名称与用于签署信息的证书中的名称不匹配，德国劳埃德船级社成员不应相信该响应。
4.b.2 - Else if the name of the GL matches the name present in the certificate and:
4.b.2-否则，如果总账名称与证书中的名称匹配，并且：
4.b.2.a - If the signature(s) verify, the member has been deleted from the GL.
4.b.2.a-如果签名验证，则该成员已从总账中删除。
4.b.2.b - Else if the member received a cMCStatusInfoExt.cMCStatus.failed with any reason, the member can reattempt to delete itself from the GL using the information provided in the response.
4.b.2.b-否则，如果成员收到cMCStatusInfoExt.cMCStatus.failed（由于任何原因），则该成员可以使用响应中提供的信息重新尝试从总账中删除自己。
The process for member initiated deletion of its own membership using the glDeleteMember requests is as follows:
成员使用glDeleteMember请求发起删除其自身成员资格的过程如下：
1 - The member sends a SignedData.PKIData.controlSequence.glDeleteMember request to the GLA (A in Figure 6). The member includes the name of the GL in glName and the member's own name in glMemberToDelete. The GL member MUST also include the signingTime attribute with this request.
1-成员向GLA发送SignedData.PKIData.controlSequence.glDeleteMember请求（图6中的a）。该成员在glName中包含总账的名称，在glMemberToDelete中包含该成员自己的名称。总账成员还必须在此请求中包含signingTime属性。
1.a - The member can optionally apply confidentiality to the request by encapsulating the SignedData.PKIData in an EnvelopedData (see Section 3.2.1.2).
1.a-成员可以选择通过将SignedData.pki数据封装在信封数据中对请求进行保密（参见第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-成员还可以选择在信封数据上应用另一个签名数据（见第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-如果signingTime属性值不在本地接受的时间窗口内，GLO可能会返回一个响应，指示cMCStatus.failed和otherInfo.failInfo.badTime以及signingTime属性。
3.b - Else if signature processing continues if the signatures cannot be verified, the GLO returns a cMCStatusInfoExt response indicating cMCStatus.failed and otherInfo.failInfo.badMessageCheck and a signingTime attribute.
3.b-否则，如果无法验证签名，则如果签名处理继续，GLO将返回一个cMCStatusInfoExt响应，指示cMCStatus.failed和otherInfo.failInfo.badMessageCheck以及signingTime属性。
3.c - Else if the signatures verify, the GLO checks to make sure one of the names in the certificates used to sign the request matches the name in glMemberToDelete.
3.c-否则，如果签名验证，GLO将进行检查，以确保用于签名请求的证书中的一个名称与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，指明在cMCStatusInfoExt.statusString中拒绝潜在成员的原因。这将阻止用户在未经许可的情况下向GLs添加用户。此外，响应中还包含signingTime属性。
3.c.2 - Else if the names match, the GLO resubmits the glDeleteMember request (see Section 3.2.5) to the GLA (1 in Figure 6). The GLO makes sure the glMemberName is already on the GL. The GLO also generates a glRekey request and include it with the GLDeleteMember request (see Section 4.5).
3.c.2-否则，如果名称匹配，GLO将向GLA重新提交glDeleteMember请求（参见第3.2.5节）（图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.PKI数据封装在信封数据中为新的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还可以选择在信封数据上应用另一个签名数据（见第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:
德国劳埃德船级社将不时需要重新键入。有些情况如下：
- 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.
- 从已关闭或托管总账中删除成员时。在这种情况下，包含glDeleteMember的PKIData.controlSequence应该包含glRekey请求。
- Depending on policy, when a member is removed from an unmanaged GL. If the policy is to rekey the GL, the PKIData.controlSequence containing the glDeleteMember could also contain a glRekey request or an out-of-bands means could be used to tell the GLA to rekey the GL. Rekeying of unmanaged GLs when members are deleted is not advised.
- 根据策略，从非托管总账中删除成员时。如果策略是为GL重新设置密钥，则包含glDeleteMember的PKIData.controlSequence也可以包含glRekey请求或带外方式，用于通知GLA为GL重新设置密钥。不建议在删除成员时重新键入非托管GLs。
- When the current shared KEK has been compromised.
- 当当前共享的KEK被破坏时。
- When the current shared KEK is about to expire. Consider two cases:
- 当前共享的KEK即将到期时。考虑两种情况：
-- 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控制glRekey，GLA不应假定应分配新的共享KEK，而是等待glRekey消息。
-- If the GLA controls the GL rekey, the GLA should initiate a glKey message as specified in Section 5.
--如果GLA控制GL重新密钥，则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）的值，且GLO控制GL重新密钥，则GLO可在最后一个共享KEK过期之前的任何时间生成GLRE密钥。为了安全起见，GLO应该在最后一个共享KEK到期之前请求重新输入一（1）个持续时间。
The GLA and GLO are the only entities allowed to initiate a GL rekey. The GLO indicated whether they are going to control rekeys or whether the GLA is going to control rekeys when they assigned the shared KEK to GL (see Section 3.1.1). The GLO initiates a GL rekey at any time. The GLA can be configured to automatically rekey the GL prior to the expiration of the shared KEK (the length of time before the expiration is an implementation decision). The GLA can also automatically rekey GLs that have been compromised, but this is covered in Section 5. Figure 7 depicts the protocol interactions to request a GL rekey. Note that error messages are not depicted. Additionally, behavior for the optional transactionId, senderNonce, and recipientNonce CMC control attributes is not addressed in these procedures.
GLA和GLO是唯一允许启动GL密钥更新的实体。当GLO将共享KEK分配给GL时，GLO指出了他们是否将控制REKEY或GLA是否将控制REKEY（参见第3.1.1节）。GLO随时启动GL重新密钥。GLA可配置为在共享KEK到期之前自动重新键入GL（到期之前的时间长度是一个实施决策）。GLA还可以自动为已受损的GLs重新设置密钥，但这将在第5节中介绍。图7描述了请求GL密钥的协议交互。请注意，没有描述错误消息。此外，可选transactionId、SenderOnce和recipientNonce CMC控件属性的行为在这些过程中没有解决。
+-----+ 1 2,A +-----+
| GLA | <-------> | GLO |
+-----+ +-----+
+-----+ 1 2,A +-----+
| GLA | <-------> | GLO |
+-----+ +-----+
Figure 7 - GL Rekey Request
图7-德国劳埃德船级社重新登记申请
The process for GLO initiated glRekey requests is as follows:
GLO发起的glRekey请求的流程如下：
1 - The GLO sends a SignedData.PKIData.controlSequence.glRekey request to the GLA (1 in Figure 7). The GLO includes the glName. If glAdministration and glKeyNewAttributes are omitted then there is no change from the previously registered GL values for these fields. If the GLO wants to force a rekey for all outstanding shared KEKs, it includes the glRekeyAllGLKeys set to TRUE. The GLO MUST also include a signingTime attribute with this request.
1-GLO向GLA发送SignedData.PKIData.controlSequence.glRekey请求（图7中的1）。GLO包括glName。如果省略glAdministration和glKeyNewAttributes，则这些字段先前注册的GL值没有变化。如果GLO想要强制为所有未完成的共享KEK重新设置密钥，它包括设置为TRUE的glRekeyAllGLKeys。GLO还必须在此请求中包含signingTime属性。
1.a - The GLO can optionally apply confidentiality to the request by encapsulating the SignedData.PKIData in an EnvelopedData (see Section 3.2.1.2).
1.a-GLO可以通过将SignedData.PKI数据封装在信封数据中（参见第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还可以选择在信封数据上应用另一个签名数据（见第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上的签名。如果额外的签名数据和/或信封数据封装了请求（参见第3.2.1.2或3.2.2节），GLA将在验证最内层签名数据上的签名之前验证外部签名和/或解密外层。
2.a - If the signingTime attribute value is not within the locally accepted time window, the GLA MAY return a response indicating cMCStatus.failed and otherInfo.failInfo.badTime and a signingTime attribute.
2.a-如果signingTime属性值不在本地接受的时间窗口内，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返回cMCStatusInfoExt响应，指示cMCStatus.failed和otherInfo.failInfo.badMessageCheck。此外，响应中还包含signingTime属性。
2.c - Else if the signatures do verify, the GLA makes sure the GL is supported by the GLA by checking that the glName matches a glName stored on the GLA.
2.c-否则，如果签名确实验证，GLA将通过检查glName是否与GLA上存储的glName匹配来确保GLA支持GL。
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将返回一个响应，指示cMCStatusInfoExt的cMCStatus.failed和otherInfo.extendedFailInfo.SKDFailInfo值为invalidGLName。此外，响应中还包含signingTime属性。
2.c.2 - Else if the glName present matches a GL stored on the GLA, the GLA checks that a registered GLO signed the request by checking that one of the names in the certificate used to sign the request is a registered GLO.
2.c.2-否则，如果存在的glName与GLA上存储的GL匹配，GLA将通过检查用于签署请求的证书中的一个名称是否为注册GLO来检查注册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的cMCStatus InfoExt。此外，响应中还包含signingTime属性。
2.c.2.b - Else if the names match, the GLA checks the glNewKeyAttribute values.
2.c.2.b-否则，如果名称匹配，GLA将检查glNewKeyAttribute值。
2.c.2.b.1 - If the new value for requestedAlgorithm is not supported, the GLA returns a response indicating cMCStatusInfoExt with cMCStatus.failed and otherInfo.extendedFailInfo.SKDFailInfo value of unsupportedAlgorithm. Additionally, a signingTime attribute is included with the response.
2.c.2.b.1-如果不支持requestedAlgorithm的新值，GLA将返回一个响应，指示cMCStatus.failed的cMCStatus InfoExt和unsupportedAlgorithm的otherInfo.extendedFailInfo.SKDFailInfo值。此外，响应中还包含signingTime属性。
2.c.2.b.2 - Else if the new value duration is not supportable (determining this is beyond the scope of this document), the GLA returns a response indicating cMCStatusInfoExt with cMCStatus.failed and otherInfo.extendedFailInfo.SKDFailInfo value of unsupportedDuration. Additionally, a signingTime attribute is included with the response.
2.c.2.b.2-否则，如果新值持续时间不受支持（确定这超出了本文档的范围），GLA将返回一个响应，指示cMCStatus.failed和otherInfo.extendedFailInfo.SKDFailInfo值为unsupportedDuration的cMCStatus InfoExt。此外，响应中还包含signingTime属性。
2.c.2.b.3 - Else if the GL is not supportable for other reasons that the GLA does not wish to disclose, the GLA returns a response indicating cMCStatusInfoExt with cMCStatus.failed and otherInfo.extendedFailInfo.SKDFailInfo value of unspecified. Additionally, a signingTime attribute is included with the response.
2.c.2.b.3-否则，如果GL因GLA不希望披露的其他原因不可支持，GLA将返回一个响应，指示cMCStatus.failed和otherInfo.extendedFailInfo.SKDFailInfo值为未指定的cMCStatus InfoExt。此外，响应中还包含signingTime属性。
2.c.2.b.4 - Else if the new requestedAlgorithm and duration are supportable or the glNewKeyAttributes was omitted, the GLA returns a cMCStatusInfoExt.cMCStatus.success and a sigingTime attribute (2 in Figure 7). The GLA also uses the glKey message to distribute the rekey shared KEK (see Section 5).
2.c.2.b.4-否则，如果新请求的算法和持续时间是可支持的，或者省略了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.PKI数据封装在信封数据中对响应进行保密（参见第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还可以选择在信封数据上应用另一个签名数据（见第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签名。如果附加的签名数据和/或信封数据封装了转发的响应（参见第3.2.1.2或3.2.2节），则GLO在验证最内层签名数据上的签名之前，验证外部签名和/或解密转发的响应。
3.a - If the signingTime attribute value is not within the locally accepted time window, the GLA MAY return a response indicating cMCStatus.failed and otherInfo.failInfo.badTime and a signingTime attribute.
3.a-如果signingTime属性值不在本地接受的时间窗口内，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将检查用于签名响应的证书中的一个名称是否与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-否则，如果总账名称与证书中的名称匹配，并且：
3.b.2.a - If the signatures verify and the response is cMCStatusInfoExt.cMCStatus.success, the GLO has successfully rekeyed the GL.
3.b.2.a-如果签名验证且响应为cMCStatusInfoExt.cMCStatus.success，则GLO已成功为GL重新键入密钥。
3.b.2.b - Else if the GLO received a cMCStatusInfoExt.cMCStatus.failed with any reason, the GLO can reattempt to rekey the GL using the information provided in the response.
3.b.2.b-否则，如果GLO因任何原因收到cMCStatusInfoExt.cMCStatus.failed，则GLO可以使用响应中提供的信息重新尝试重新输入总账。
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指示已成功进行了重新登录。GLA发起的重新钥匙流程如下：
1 - The GLA generates for all GLOs a SignedData.PKIData.controlSequence.cMCStatusInfoExt.cMCStatus success and includes a signingTime attribute (A in Figure 7).
1-GLA为所有GLO生成SignedData.PKIData.controlSequence.cMCStatusInfoExt.cMCStatus success，并包括signingTime属性（图7中的a）。
1.a - The GLA can optionally apply confidentiality to the request by encapsulating the SignedData.PKIData in an EnvelopedData (see Section 3.2.1.2).
1.a-GLA可以通过将SignedData.PKI数据封装在信封数据中（见第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还可以选择在信封数据上应用另一个签名数据（见第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签名。如果附加的签名数据和/或信封数据封装了转发的响应（参见第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-如果signingTime属性值不在本地接受的时间窗口内，GLO可能会返回一个响应，指示cMCStatus.failed和otherInfo.failInfo.badTime以及signingTime属性。
2.b - Else if signature processing continues and if the signatures verify, the GLO checks that one of the names in the certificate used to sign the response matches the name of the GL.
2.b-否则，如果签名处理继续进行且签名验证，则GLO将检查用于签名响应的证书中的一个名称是否与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-否则，如果总账的名称与证书中的名称不匹配，且响应为cMCStatusInfoExt.cMCStatus.success，则GLO知道GLA已成功为总账重新键入。
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.
如果总账成员人数增加，则对于一个GLO而言，管理和关闭的GLs可能会变得困难。为了支持分配工作负载，GLA支持让GLs由多个GLO管理。glAddOwner和glRemoveOwner消息旨在支持添加和删除已注册的GLO。图8描述了发送glAddOwner和glRemoveOwner消息的协议交互以及结果响应消息。请注意，不会显示错误消息。此外，可选transactionId、SenderOnce和recipientNonce CMC控件属性的行为在这些过程中没有解决。
+-----+ 1 2 +-----+
| GLA | <-------> | GLO |
+-----+ +-----+
+-----+ 1 2 +-----+
| GLA | <-------> | GLO |
+-----+ +-----+
Figure 8 - GLO Add and Delete Owners
图8-GLO添加和删除所有者
The process for glAddOwner and glDeleteOwner is as follows:
glAddOwner和glDeleteOwner的流程如下：
1 - The GLO sends a SignedData.PKIData.controlSequence.glAddOwner or glRemoveOwner request to the GLA (1 in Figure 8). The GLO includes the GL name in glName, and the name and address of the GLO in glOwnerName and glOwnerAddress, respectively. The GLO MUST also include the signingTime attribute with this request.
1-GLO向GLA发送SignedData.PKIData.controlSequence.glAddOwner或glRemoveOwner请求（图8中的1）。GLO包括glName中的GLO名称，以及GLO的名称和地址分别包含在glOwnerName和glOwnerAddress中。GLO还必须在该请求中包含signingTime属性。
1.a - The GLO can optionally apply confidentiality to the request by encapsulating the SignedData.PKIData in an EnvelopedData (see Section 3.2.1.2).
1.a-GLO可以通过将SignedData.PKI数据封装在信封数据中（参见第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还可以选择在信封数据上应用另一个签名数据（见第3.2.1.2节）。
2 - Upon receipt of the glAddOwner or glRemoveOwner request, the GLA checks the signingTime and verifies the GLO signature(s). If an additional SignedData and/or EnvelopedData encapsulates the request (see Section 3.2.1.2 or 3.2.2), the GLA verifies the outer signature and/or decrypts the outer layer prior to verifying the signature on the innermost SignedData.
2-收到glAddOwner或glRemoveOwner请求后，GLA检查签名时间并验证GLO签名。如果额外的签名数据和/或信封数据封装了请求（参见第3.2.1.2或3.2.2节），GLA将在验证最内层签名数据上的签名之前验证外部签名和/或解密外层。
2.a - If the signingTime attribute value is not within the locally accepted time window, the GLA MAY return a response indicating cMCStatus.failed and otherInfo.failInfo.badTime and a signingTime attribute.
2.a-如果signingTime属性值不在本地接受的时间窗口内，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将返回一个cMCStatusInfoExt响应，指示cMCStatus.failed和otherInfo.failInfo.badMessageCheck。此外，响应中还包含signingTime属性。
2.c - Else if the signatures verify, the GLA makes sure the GL is supported by checking that the glName matches a glName stored on the GLA.
2.c-否则，如果签名验证，GLA通过检查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-如果GLA不支持glName，则GLA返回一个响应，指示cMCStatus.failed和otherInfo.extendedFailInfo.SKDFailInfo值为invalidGLName的cMCStatus InfoExt。此外，响应中还包含signingTime属性。
2.c.2 - Else if the glName is supported by the GLA, the GLA ensures that a registered GLO signed the glAddOwner or glRemoveOwner request by checking that one of the names present in the digital signature certificate used to sign the glAddOwner or glDeleteOwner request matches the name of a registered GLO.
2.c.2-否则，如果GLA支持glName，GLA将通过检查用于签署glAddOwner或glDeleteOwner请求的数字签名证书中的一个名称是否与注册GLO的名称匹配，确保注册GLO签署了glAddOwner或glRemoveOwner请求。
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的cMCStatus InfoExt。此外，响应中还包含signingTime属性。
2.c.2.b - Else if the names match, the GLA returns a cMCStatusInfoExt.cMCStatus.success and a signingTime attribute (2 in Figure 4). The GLA also takes administrative actions to associate the new glOwnerName with the GL in the case of glAddOwner or to disassociate the old glOwnerName with the GL in the cased of glRemoveOwner.
2.c.2.b-否则，如果名称匹配，GLA将返回一个cMCStatusInfoExt.cMCStatus.success和一个signingTime属性（图4中的2）。GLA还采取行政措施，在glAddOwner的情况下，将新的glOwnerName与GL关联；在glRemoveOwner的情况下，将旧的glOwnerName与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.PKI响应封装在信封数据中对响应进行保密（参见第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还可以选择在信封数据上应用另一个签名数据（见第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的签名。如果附加签名数据和/或信封数据封装了响应（参见第3.2.1.2或3.2.2节），则GLO在验证最内层签名数据上的签名之前，验证外部签名和/或解密外层。
3.a - If the signingTime attribute value is not within the locally accepted time window, the GLO MAY return a response indicating cMCStatus.failed and otherInfo.failInfo.badTime and a signingTime attribute.
3.a-如果signingTime属性值不在本地接受的时间窗口内，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将检查用于签名响应的证书中的一个名称是否与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-否则，如果总账名称与证书中的名称不匹配，并且：
3.b.2.a - If the signatures verify and the response was cMCStatusInfoExt.cMCStatus.success, the GLO has successfully added or removed the GLO.
3.b.2.a-如果签名验证且响应为cMCStatusInfoExt.cMCStatus.success，则GLO已成功添加或删除GLO。
3.b.2.b - Else if the signatures verify and the response was cMCStatusInfoExt.cMCStatus.failed with any reason, the GLO can reattempt to add or delete the GLO using the information provided in the response.
3.b.2.b-否则，如果签名验证且响应是cMCStatusInfoExt.cMCStatus.failed，则GLO可以使用响应中提供的信息重新尝试添加或删除GLO。
There will be times when the shared KEK is compromised. GL members and GLOs use glkCompromise to tell the GLA that the shared KEK has been compromised. Figure 9 depicts the protocol interactions for GL Key Compromise. Note that error messages are not shown. Additionally, behavior for the optional transactionId, senderNonce, and recipientNonce CMC control attributes is not addressed in these procedures.
有时共享的KEK会被破坏。GL成员和GLO使用glkCompromise告知GLA共享KEK已被破坏。图9描述了GL密钥泄露的协议交互。请注意，不会显示错误消息。此外，可选transactionId、SenderOnce和recipientNonce CMC控件属性的行为在这些过程中没有解决。
+-----+ 2{1} 4 +----------+
| GLO | <----------+ +-------> | Member 1 |
+-----+ 5,3{1} | | +----------+
+-----+ <----------+ | 4 +----------+
| GLA | 1 +-------> | ... |
+-----+ <---------------+ +----------+
| 4 +----------+
+-------> | Member n |
+----------+
+-----+ 2{1} 4 +----------+
| GLO | <----------+ +-------> | Member 1 |
+-----+ 5,3{1} | | +----------+
+-----+ <----------+ | 4 +----------+
| GLA | 1 +-------> | ... |
+-----+ <---------------+ +----------+
| 4 +----------+
+-------> | Member n |
+----------+
Figure 9 - GL Key Compromise
图9-德国劳埃德船级社钥匙折衷方案
The process for GL member initiated glkCompromise messages is as follows:
总账成员发起的glkCompromise消息的流程如下：
1 - The GL member sends a SignedData.PKIData.controlSequence.glkCompromise request to the GLA (1 in Figure 9). The GL member includes the name of the GL in GeneralName. The GL member MUST also include the signingTime attribute with this request.
1-GL成员向GLA发送SignedData.PKIData.controlSequence.glkCompromise请求（图9中的1）。总账成员在“通用名称”中包含总账的名称。总账成员还必须在此请求中包含signingTime属性。
1.a - The GL member can optionally apply confidentiality to the request by encapsulating the SignedData.PKIData in an EnvelopedData (see Section 3.2.1.2). The glkCompromise can be included in an EnvelopedData generated with the compromised shared KEK.
1.a-德国劳埃德船级社成员可以选择通过将SignedData.PKI数据封装在信封数据中对请求进行保密（见第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-德国劳埃德船级社成员还可以选择在信封数据上应用另一个签名数据（见第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-收到GLK妥协请求后，GLA检查签名时间并验证GL会员签名。如果额外的签名数据和/或信封数据封装了请求（参见第3.2.1.2或3.2.2节），GLA将在验证最内层签名数据上的签名之前验证外部签名和/或解密外层。
2.a - If the signingTime attribute value is not within the locally accepted time window, the GLA MAY return a response indicating cMCStatus.failed and otherInfo.failInfo.badTime and a signingTime attribute.
2.a-如果signingTime属性值不在本地接受的时间窗口内，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将返回一个cMCStatusInfoExt响应，指示cMCStatus.failed和otherInfo.failInfo.badMessageCheck。此外，响应中还包含signingTime属性。
2.c - Else if the signatures verify, the GLA makes sure the GL is supported by checking that the indicated GL name matches a glName stored on the GLA.
2.c-否则，如果签名验证，GLA通过检查指示的GL名称是否与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-如果GLA不支持glName，则GLA返回一个响应，指示cMCStatus.failed和otherInfo.extendedFailInfo.SKDFailInfo值为invalidGLName的cMCStatus InfoExt。此外，响应中还包含signingTime属性。
2.c.2 - Else if the glName is supported by the GLA, the GLA checks who signed the request. For GLOs, one of the names in the certificate used to sign the request needs to match a registered GLO. For the member, the name in glMember.glMemberName needs to match one of the names in the certificate used to sign the request.
2.c.2-否则，如果GLA支持glName，GLA将检查谁签署了请求。对于GLO，用于签署请求的证书中的一个名称需要与注册的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将生成第5节所述的glKey消息，以重新输入GL（图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超出了本文档的范围。第4.7.2节讨论了GLO的进一步处理。
The process for GLO initiated glkCompromise messages is as follows:
GLO发起的glkCompromise消息的流程如下：
1 - The GLO either:
1-GLO：
1.a - Generates the glkCompromise message itself by sending a SignedData.PKIData.controlSequence.glkCompromise request to the GLA (5 in Figure 9). The GLO includes the name of the GL in GeneralName. The GLO MUST also include a signingTime attribute with this request.
1.a-通过向GLA发送SignedData.PKIData.controlSequence.glkCompromise请求来生成glkCompromise消息本身（图9中的5）。GLO在通用名称中包括总账的名称。GLO还必须在此请求中包含signingTime属性。
1.a.1 - The GLO can optionally apply confidentiality to the request by encapsulating the SignedData.PKIData in an EnvelopedData (see Section 3.2.1.2). The glkCompromise can be included in an EnvelopedData generated with the compromised shared KEK.
1.a.1-GLO可以通过将SignedData.PKI数据封装在信封数据中（见第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还可以选择在信封数据上应用另一个签名数据（见第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成员签名。如果附加签名数据和/或信封数据封装了请求（参见第3.2.1.2或3.2.2节），则GLO在验证最内层签名数据上的签名之前，验证外部签名和/或解密外层。
1.b.1 - If the signingTime attribute value is not within the locally accepted time window, the GLO MAY return a response indicating cMCStatus.failed and otherInfo.failInfo.badTime and a signingTime attribute.
1.b.1-如果signingTime属性值不在本地接受的时间窗口内，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返回一个cMCStatusInfoExt响应，指示cMCStatus.failed和otherInfo.failInfo.badMessageCheck。此外，响应中还包含signingTime属性。
1.b.2.a - If the signatures verify, the GLO checks that the names in the certificate match the name of the signer (i.e., the name in the certificate used to sign the GL member's request is the GL member).
1.b.2.a-如果签名验证，GLO将检查证书中的名称是否与签名人的名称匹配（即，用于签署GL成员请求的证书中的名称为GL成员）。
1.b.2.a.1 - If either name does not match, the GLO ought not trust the signer and it ought not forward the message to the GLA.
1.b.2.a.1-如果任何一个名称不匹配，GLO不应信任签名者，也不应将消息转发给GLA。
1.b.2.a.2 - Else if the names match and the signatures verify, the GLO determines whether to forward the glkCompromise message back to the GLA (3{1} in Figure 9). Further processing by the GLA is in 2 of Section 4.7.1. The GLO can also return a response to the prospective member with cMCStatusInfoExt.cMCtatus.success indicating that the glkCompromise message was successfully received.
1.b.2.a.2-否则，如果名称匹配且签名验证，GLO将确定是否将glkCompromise消息转发回GLA（图9中的3{1}）。GLA的进一步处理见第4.7.1节第2节。GLO还可以使用CMCStatus infoext.cMCtatus.success向潜在成员返回响应，表明glkCompromise消息已成功接收。
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.
德国劳埃德船级社成员有时会无法挽回地失去其共享的KEK。共享KEK未被泄露，且无需重新加密整个GL。GL成员使用glkRefresh消息请求将共享的KEK重新分配给他们。图10描述了GL密钥刷新的协议交互。请注意，不会显示错误消息。此外，可选transactionId、SenderOnce和recipientNonce CMC控件属性的行为在这些过程中没有解决。
+-----+ 1 2 +----------+
| GLA | <-----------> | Member |
+-----+ +----------+
+-----+ 1 2 +----------+
| GLA | <-----------> | Member |
+-----+ +----------+
Figure 10 - GL KEK Refresh
图10-GL KEK刷新
The process for glkRefresh is as follows:
glkRefresh的流程如下：
1 - The GL member sends a SignedData.PKIData.controlSequence.glkRefresh request to the GLA (1 in Figure 10). The GL member includes name of the GL in GeneralName. The GL member MUST also include a signingTime attribute with this request.
1-GL成员向GLA发送SignedData.PKIData.controlSequence.glkRefresh请求（图10中的1）。总账成员在“通用名称”中包含总账的名称。总账成员还必须在此请求中包含signingTime属性。
1.a - The GL member can optionally apply confidentiality to the request by encapsulating the SignedData.PKIData in an EnvelopedData (see Section 3.2.1.2).
1.a-德国劳埃德船级社成员可以选择通过将SignedData.PKI数据封装在信封数据中对请求进行保密（见第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-德国劳埃德船级社成员还可以选择在信封数据上应用另一个签名数据（见第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和/或EnvelopedData封装了请求（参见第3.2.1.2或3.2.2节），GLA将在验证最内层SignedData上的签名之前验证外部签名和/或解密外层。
2.a - If the signingTime attribute value is not within the locally accepted time window, the GLA MAY return a response indicating cMCStatus.failed and otherInfo.failInfo.badTime and a signingTime attribute.
2.a-如果signingTime属性值不在本地接受的时间窗口内，GLA可能会返回一个响应，指示cMCStatus.failed和otherInfo.failInfo.badTime以及signingTime属性。
2.b - Else if signature processing continues and if the signatures cannot be verified, the GLA returns a cMCStatusInfoExt response indicating cMCStatus.failed and otherInfo.failInfo.badMessageCheck. Additionally, a signingTime attribute is included with the response.
2.b-否则，如果签名处理继续，并且签名无法验证，GLA将返回一个cMCStatusInfoExt响应，指示cMCStatus.failed和otherInfo.failInfo.badMessageCheck。此外，响应中还包含signingTime属性。
2.c - Else if the signatures verify, the GLA makes sure the GL is supported by checking that the GLGeneralName matches a glName stored on the GLA.
2.c-否则，如果签名验证，GLA将通过检查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.extendedFailInfo.SKDFailInfo值为invalidGLName的cMCStatus InfoExt。此外，响应中还包含signingTime属性。
2.c.2 - Else if the glName is supported by the GLA, the GLA ensures that the GL member is on the GL.
2.c.2-否则，如果GLA支持glName，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-如果GL上不存在glMemberName，GLA将返回一个响应，指示cMCStatusInfoExt，其中cMCStatus.failed和otherInfo.extendedFailInfo.SKDFailInfo值为noSpam。此外，响应中还包含signingTime属性。
2.c.2.b - Else if the glMemberName is present on the GL, the GLA returns a cMCStatusInfoExt.cMCStatus.success, a signingTime attribute, and a glKey message (2 in Figure 10) as described in Section 5.
2.c.2.b-否则，如果GL上存在glMemberName，GLA将返回一个cMCStatusInfoExt.cMCStatus.success、一个signingTime属性和一个glKey消息（图10中的2），如第5节所述。
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、SenderOnce和recipientNonce CMC控件属性的行为在这些过程中没有解决。
+-----+ 1 2 +------------------+
| GLA | <-------> | GLO or GL Member |
+-----+ +------------------+
+-----+ 1 2 +------------------+
| GLA | <-------> | GLO or GL Member |
+-----+ +------------------+
Figure 11 - GLA Query Request and Response
图11-GLA查询请求和响应
The process for glaQueryRequest and glaQueryResponse is as follows:
glaQueryRequest和glaQueryResponse的流程如下：
1 - The GLO, GL member, or prospective GL member sends a SignedData.PKIData.controlSequence.glaQueryRequest request to the GLA (1 in Figure 11). The GLO, GL member, or prospective GL member indicates the information it is interested in receiving from the GLA. Additionally, a signingTime attribute is included with this request.
1-GLO、GL成员或潜在GL成员向GLA发送SignedData.PKIData.controlSequence.glaQueryRequest请求（图11中的1）。GLO、德国劳埃德船级社成员或潜在德国劳埃德船级社成员表示其有兴趣从德国劳埃德船级社收到的信息。此外，此请求还包含signingTime属性。
1.a - The GLO, GL member, or prospective GL member can optionally apply confidentiality to the request by encapsulating the SignedData.PKIData in an EnvelopedData (see Section 3.2.1.2).
1.a-GLO、GL成员或潜在GL成员可以选择通过将SignedData.PKI数据封装在信封数据中对请求进行保密（见第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成员也可以选择在信封数据上应用另一个签名数据（见第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将返回一个cMCStatusInfoExt响应，指示cMCStatus.noSupport和statusString中的任何其他信息。
2.b - Else if the GLA does accept GLAQueryRequests, the GLA checks the signingTime and verifies the GLO, GL member, or prospective GL member signature(s). If an additional SignedData and/or EnvelopedData encapsulates the request (see Section 3.2.1.2 or 3.2.2), the GLA verifies the outer signature and/or decrypts the outer layer prior to verifying the signature on the innermost SignedData.
2.b-否则，如果GLA确实接受GLAQUERY请求，GLA将检查签署时间，并验证GLO、GL会员或潜在GL会员的签名。如果额外的签名数据和/或信封数据封装了请求（参见第3.2.1.2或3.2.2节），GLA将在验证最内层签名数据上的签名之前验证外部签名和/或解密外层。
2.b.1 - If the signingTime attribute value is not within the locally accepted time window, the GLA MAY return a response indicating cMCStatus.failed and otherInfo.failInfo.badTime and a signingTime attribute.
2.b.1-如果signingTime属性值不在本地接受的时间窗口内，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返回cMCStatusInfoExt响应，指示cMCStatus.failed和otherInfo.failInfo.badMessageCheck。此外，响应中还包含signingTime属性。
2.b.3 - Else if the signatures verify, the GLA returns a glaQueryResponse (2 in Figure 11) with the correct response if the glaRequestType is supported or returns a cMCStatusInfoExt response indicating cMCStatus.noSupport if the glaRequestType is not supported. Additionally, a signingTime attribute is included with the response.
2.b.3-否则，如果签名验证，GLA返回一个glaQueryResponse（图11中的2），如果GlaQuestType受支持，则返回一个正确响应；如果GlaQuestType不受支持，则返回一个指示cMCStatus.noSupport的cMCStatusInfoExt响应。此外，响应中还包含signingTime属性。
2.b.3.a - The GLA applies confidentiality to the response by encapsulating the SignedData.PKIResponse in an EnvelopedData if the request was encapsulated in an EnvelopedData (see Section 3.2.1.2).
2.b.3.a-如果请求封装在信封数据中，GLA通过将SignedData.PKI响应封装在信封数据中为响应保密（见第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还可以选择在信封数据上应用另一个签名数据（见第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-收到GLAQUERY响应后，GLO、GL会员或潜在GL会员将检查签署时间并验证GLA签名。如果附加签名数据和/或信封数据封装了响应（参见第3.2.1.2或3.2.2节），则GLO、GL成员或潜在GL成员在验证最内层签名数据上的签名之前，验证外部签名和/或解密外层。
3.a - If the signingTime attribute value is not within the locally accepted time window, the GLO, GL member, or prospective GL member MAY return a response indicating cMCStatus.failed and otherInfo.failInfo.badTime and a signingTime attribute.
3.a-如果signingTime属性值不在本地接受的时间窗口内，则GLO、GL成员或潜在GL成员可能会返回一个响应，指示cMCStatus.failed和otherInfo.failInfo.badTime以及signingTime属性。
3.b - Else if signature processing continues and if the signatures do not verify, the GLO, GL member, or prospective GL member returns a cMCStatusInfoExt response indicating cMCStatus.failed and otherInfo.failInfo.badMessageCheck. Additionally, a signingTime attribute is included with the response.
3.b-否则，如果签名处理继续且签名未验证，则GLO、GL成员或潜在GL成员返回cMCStatusInfoExt响应，指示cMCStatus.failed和otherInfo.failInfo.badMessageCheck。此外，响应中还包含signingTime属性。
3.c - Else if the signatures verify, then the GLO, GL member, or prospective GL member checks that one of the names in the certificate used to sign the response matches the name of the GL.
3.c-否则，如果签名验证，则GLO、GL成员或潜在GL成员检查用于签署响应的证书中的一个名称是否与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生成GLADMember请求、GLA生成glKey消息或GLA处理GLADMember时，可能存在GL成员证书过期或无效的情况。在这些情况下，GLO或GLA可要求GL成员提供新证书，以避免GLA无法为GL成员生成glKey消息。有时，总账会员机构可能知道其证书即将到期或已被吊销，并且总账会员机构将无法接收总账密钥。可选transactionId、SenderOnce和recipientNonce CMC控件属性的行为在这些过程中没有解决。
The process for GLO initiated glUpdateCert is as follows:
GLO启动的glUpdateCert流程如下：
1 - The GLO or GLA sends a SignedData.PKIData.controlSequence.glProvideCert request to the GL member. The GLO or GLA indicates the GL name in glName and the GL member name in glMemberName. Additionally, a signingTime attribute is included with this request.
1-GLO或GLA向GL成员发送SignedData.PKIData.controlSequence.GLProviderCert请求。GLO或GLA在glName中表示总账名称，在glMemberName中表示总账成员名称。此外，此请求还包含signingTime属性。
1.a - The GLO or GLA can optionally apply confidentiality to the request by encapsulating the SignedData.PKIData in an EnvelopedData (see Section 3.2.1.2). If the GL member's PKC has been revoked, the GLO or GLA ought not use it to generate the EnvelopedData that encapsulates the glProvideCert request.
1.a-GLO或GLA可以选择通过将SignedData.PKI数据封装在信封数据中对请求保密（见第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还可以选择在信封数据上应用另一个签名数据（见第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签名。如果额外的签名数据和/或信封数据封装了响应（见第3.2.1.2或3.2.2节），则德国劳埃德船级社成员在验证最内层签名数据上的签名之前，验证外部签名和/或解密外层。
2.a - If the signingTime attribute value is not within the locally accepted time window, the GL member MAY return a response indicating cMCStatus.failed and otherInfo.failInfo.badTime and a signingTime attribute.
2.a-如果signingTime属性值不在本地接受的时间窗口内，总账成员可能会返回一个响应，指示cMCStatus.failed和otherInfo.failInfo.badTime以及signingTime属性。
2.b - Else if signature processing continues and if the signatures cannot be verified, the GL member returns a cMCStatusInfoExt response indicating cMCStatus.failed and otherInfo.failInfo.badMessageCheck. Additionally, a signingTime attribute is included with the response.
2.b-否则，如果签名处理继续进行且签名无法验证，则总账成员返回一个cMCStatusInfoExt响应，指示cMCStatus.failed和otherInfo.failInfo.badMessageCheck。此外，响应中还包含signingTime属性。
2.c - Else if the signatures verify, the GL member generates a Signed.PKIResponse.controlSequence.glUpdateCert that includes the GL name in glName, the member's name in glMember.glMemberName, the member's encryption certificate in glMember.certificates.pKC. The GL member can also include any attribute certificates associated with the member's encryption certificate in glMember.certificates.aC, and the certification path associated with the member's encryption and attribute certificates in glMember.certificates.certPath. Additionally, a signingTime attribute is included with the response.
2.c-否则，如果签名验证，GL成员将生成一个Signed.pki响应.controlSequence.glUpdateCert，其中包括glName中的GL名称、glMember.glMemberName中的成员名称、glMember.certificates.pKC中的成员加密证书。GL成员还可以在glMember.certificates.aC中包含与成员的加密证书关联的任何属性证书，以及在glMember.certificates.certPath中包含与成员的加密和属性证书关联的证书路径。此外，响应中还包含signingTime属性。
2.c.1 - The GL member can optionally apply confidentiality to the request by encapsulating the SignedData.PKIResponse in an EnvelopedData (see Section 3.2.1.2). If the GL member's PKC has been revoked, the GL member ought not use it to generate the EnvelopedData that encapsulates the glProvideCert request.
2.c.1-德国劳埃德船级社成员可以选择通过将SignedData.PKI响应封装在信封数据中对请求进行保密（参见第3.2.1.2节）。如果德国劳埃德船级社成员的PKC已被撤销，德国劳埃德船级社成员不应使用该PKC生成封装德国劳埃德船级社请求的信封数据。
2.c.2 - The GL member can also optionally apply another SignedData over the EnvelopedData (see Section 3.2.1.2).
2.c.2-德国劳埃德船级社成员还可以选择在信封数据上应用另一个签名数据（见第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成员签名。如果额外的签名数据和/或信封数据封装了响应（见第3.2.1.2或3.2.2节），则德国劳埃德船级社成员在验证最内层签名数据上的签名之前，验证外部签名和/或解密外层。
3.a - If the signingTime attribute value is not within the locally accepted time window, the GLO or GLA MAY return a response indicating cMCStatus.failed and otherInfo.failInfo.badTime and a signingTime attribute.
3.a-如果signingTime属性值不在本地接受的时间窗口内，GLO或GLA可能会返回一个响应，指示cMCStatus.failed和otherInfo.failInfo.badTime以及signingTime属性。
3.b - Else if signature processing continues and if the signatures cannot be verified, the GLO or GLA returns a cMCStatusInfoExt response indicating cMCStatus.failed and otherInfo.failInfo.badMessageCheck. Additionally, a signingTime attribute is included with the response.
3.b-否则，如果签名处理继续，并且签名无法验证，GLO或GLA将返回一个cMCStatusInfoExt响应，指示cMCStatus.failed和otherInfo.failInfo.badMessageCheck。此外，响应中还包含signingTime属性。
3.c - Else if the signatures verify, the GLO or GLA verifies the member's encryption certificate.
3.c-否则，如果签名验证，GLO或GLA将验证成员的加密证书。
3.c.1 - If the member's encryption certificate cannot be verified, the GLO returns either another glProvideCert request or a cMCStatusInfoExt with cMCStatus.failed and the reason why in cMCStatus.statusString. glProvideCert should be returned only a certain number of times is because if the GL member does not have a valid certificate it will never be able to return one. Additionally, a signingTime attribute is included with either response.
3.c.1-如果无法验证成员的加密证书，GLO将返回另一个GLProviderCert请求或带有cMCStatus.failed的cMCStatusInfoExt以及cMCStatus.statusString中的原因。glProvideCert只应返回一定次数，因为如果GL成员没有有效的证书，它将永远无法返回。此外，两个响应中都包含signingTime属性。
3.c.2 - Else if the member's encryption certificate cannot be verified, the GLA returns another glProvideCert request to the GL member or a cMCStatusInfoExt with cMCStatus.failed and the reason why in cMCStatus.statusString to the GLO. glProvideCert should be returned only a certain number of times because if the GL member does not have a valid certificate it will never be able to return one. Additionally, a signingTime attribute is included with the response.
3.c.2-否则，如果无法验证成员的加密证书，GLA将向GL成员返回另一个GLProviderCert请求，或向GLO返回一个带有cMCStatus.failed的cMCStatusInfoExt，以及cMCStatus.statusString中的原因。glProvideCert只应返回一定次数，因为如果GL成员没有有效的证书，它将永远无法返回。此外，响应中还包含signingTime属性。
3.c.3 - Else if the member's encryption certificate verifies, the GLO or GLA will use it in subsequent glAddMember requests and glKey messages associated with the GL member.
3.c.3-否则，如果成员的加密证书得到验证，GLO或GLA将在随后的GLADMember请求和与GL成员相关的glKey消息中使用该证书。
The process for an unsolicited GL member glUpdateCert is as follows:
未经请求的德国劳埃德船级社成员glUpdateCert的流程如下：
1 - The GL member sends a Signed.PKIData.controlSequence.glUpdateCert that includes the GL name in glName, the member's name in glMember.glMemberName, the member's encryption certificate in glMember.certificates.pKC. The GL member can also include any attribute certificates associated with the member's encryption certificate in glMember.certificates.aC, and the certification
1-GL成员发送已签名的.PKIData.controlSequence.glUpdateCert，其中包括glName中的GL名称、glMember.glMemberName中的成员名称、glMember.certificates.pKC中的成员加密证书。GL成员还可以在glMember.certificates.aC中包含与成员的加密证书关联的任何属性证书，以及证书
path associated with the member's encryption and attribute certificates in glMember.certificates.certPath. The GL member MUST also include a signingTime attribute with this request.
与glMember.certificates.certPath中成员的加密和属性证书关联的路径。总账成员还必须在此请求中包含signingTime属性。
1.a - The GL member can optionally apply confidentiality to the request by encapsulating the SignedData.PKIData in an EnvelopedData (see Section 3.2.1.2). If the GL member's PKC has been revoked, the GLO or GLA ought not use it to generate the EnvelopedData that encapsulates the glProvideCert request.
1.a-德国劳埃德船级社成员可以选择通过将SignedData.PKI数据封装在信封数据中对请求进行保密（见第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-德国劳埃德船级社成员还可以选择在信封数据上应用另一个签名数据（见第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成员签名。如果额外的签名数据和/或信封数据封装了响应（参见第3.2.1.2或3.2.2节），GLA在验证最内层签名数据上的签名之前，验证外部签名和/或解密外层。
2.a - If the signingTime attribute value is not within the locally accepted time window, the GLA MAY return a response indicating cMCStatus.failed and otherInfo.failInfo.badTime and a signingTime attribute.
2.a-如果signingTime属性值不在本地接受的时间窗口内，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将返回一个cMCStatusInfoExt响应，指示cMCStatus.failed和otherInfo.failInfo.badMessageCheck。
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成员返回另一个GLProviderCert请求，或向GLO返回一个带有cMCStatus.failed的cMCStatusInfoExt，以及cMCStatus.statusString中的原因。glProvideCert不应无限期返回；如果德国劳埃德船级社成员没有有效的证书，它将永远无法返回证书。此外，响应中还包含signingTime属性。
2.c.2 - Else if the member's encryption certificate verifies, the GLA will use it in subsequent glAddMember requests and glKey messages associated with the GL member. The GLA also forwards the glUpdateCert message to the GLO.
2.c.2-否则，如果成员的加密证书得到验证，GLA将在随后的GLADMember请求和与GL成员相关的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在收到GladMember、glDeleteMember（对于已关闭和管理的GLs）、glRekey、glkCompromise或glkRefresh请求并返回相应请求的cMCStatusInfoExt响应后，使用glKey消息分发新的共享KEK。图12描述了发送glKey消息的协议交互。与为管理信息定义的程序不同，本节中定义的程序必须由GLA发起，由GL成员接收。请注意，不会显示错误消息。此外，可选transactionId、SenderOnce和recipientNonce CMC控件属性的行为在这些过程中没有解决。
1 +----------+
+-------> | Member 1 |
| +----------+
+-----+ | 1 +----------+
| GLA | ----+-------> | ... |
+-----+ | +----------+
| 1 +----------+
+-------> | Member n |
+----------+
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.
如果总账设置为GLKeyAttributes.recipientsNotMutuallyAware设置为TRUE，则必须向每个总账成员发送单独的glKey消息，以免泄露其他总账成员的信息。
When the glKey message is generated as a result of a:
由于以下原因生成glKey消息时：
- glAddMember request,
- 格莱德会员请求，
- glkComrpomise indication,
- GLKCompomise指示，
- glkRefresh request,
- 格林斯请求，
- glDeleteMember request with the GL's glAdministration set to managed or closed, and
- glDeleteMember请求，GL的GLADAdministration设置为托管或关闭，以及
- 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必须使用glKey.glkWrapped.RecipientInfo中的kari（见[CMS]第12.3.2节）或ktri（见[CMS]第12.3.1节）选项，以确保只有预期接收人收到共享KEK。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.
当生成计数器大于零（0）的glRekey请求生成glKey消息时，或当GLA控制REKEY时，GLA可使用glKey.glkWrapped.RecipientInfo中的kari、ktri或kekri（见[CMS]第12.3.3节），以确保只有预期接收人收到共享KEK。GLA必须支持RecipientInfo.ktri选项。
When a glKey message is generated, the process is as follows:
生成glKey消息时，流程如下：
1 - The GLA MUST send a SignedData.PKIData.controlSequence.glKey to each member by including glName, glIdentifier, glkWrapped, glkAlgorithm, glkNotBefore, and glkNotAfter. If the GLA cannot generate a glKey message for the GL member because the GL member's PKC has expired or is otherwise invalid, the GLA MAY send a glUpdateCert to the GL member requesting a new certificate be provided (see Section 4.10). The number of glKey messages generated for the GL is described in Section 3.1.13. Additionally, a signingTime attribute is included with the distribution message(s).
1-GLA必须向每个成员发送SignedData.PKIData.controlSequence.glKey，包括glName、glIdentifier、glkWrapped、glkAlgorithm、glkNotBefore和glkNotAfter。如果由于GL成员的PKC已过期或无效，GLA无法为GL成员生成glKey消息，则GLA可向GL成员发送glUpdateCert，请求提供新证书（见第4.10节）。第3.1.13节描述了为总账生成的glKey消息的数量。此外，分发消息中还包含signingTime属性。
1.a - The GLA MAY optionally apply another confidentiality layer to the message by encapsulating the SignedData.PKIData in another EnvelopedData (see Section 3.2.1.2).
1.a-GLA可通过将SignedData.PKI数据封装在另一个信封数据中，选择性地对消息应用另一个保密层（见第3.2.1.2节）。
1.b - The GLA MAY also optionally apply another SignedData over the EnvelopedData.SignedData.PKIData (see Section 3.2.1.2).
1.b-GLA还可以选择在EnvelopedData.SignedData.PKI数据上应用另一个SignedData（参见第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和/或EnvelopedData封装了消息（参见第3.2.1.2节或第3.2.2节），则GL成员必须在验证SignedData.PKIData.controlSequence.glKey上的签名之前验证外部签名和/或解密外层。
2.a - If the signingTime attribute value is not within the locally accepted time window, the GLA MAY return a response indicating cMCStatus.failed and otherInfo.failInfo.badTime and a signingTime attribute.
2.a-如果signingTime属性值不在本地接受的时间窗口内，GLA可能会返回一个响应，指示cMCStatus.failed和otherInfo.failInfo.badTime以及signingTime属性。
2.b - Else if signature processing continues and if the signatures cannot be verified, the GL member MUST return a cMCStatusInfoExt response indicating cMCStatus.failed and otherInfo.failInfo.badMessageCheck. Additionally, a signingTime attribute is included with the response.
2.b-否则，如果签名处理继续进行且签名无法验证，总账成员必须返回一个cMCStatusInfoExt响应，指示cMCStatus.failed和otherInfo.failInfo.badMessageCheck。此外，响应中还包含signingTime属性。
2.c - Else if the signatures verify, the GL member processes the RecipientInfos according to [CMS]. Once unwrapped, the GL member should store the shared KEK in a safe place. When stored, the glName, glIdentifier, and shared KEK should be associated. Additionally, the GL member MUST return a cMCStatusInfoExt indicating cMCStatus.success to tell the GLA the KEK was received.
2.c-否则，如果签名验证，GL成员将根据[CMS]处理接收方信息。打开包装后，德国劳埃德船级社成员应将共享的桶存放在安全的地方。存储时，应关联glName、glIdentifier和shared KEK。此外，GL成员必须返回指示cMCStatus.success的cMCStatus信息文本，以告知GLA已收到KEK。
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.
实现必须随机生成内容加密密钥、消息身份验证密钥、初始化向量（IVs）和填充。此外，公钥/私钥对的生成依赖于随机数。使用不充分的伪随机数生成器（PRNG）生成加密密钥可能导致很少或没有安全性。攻击者可能会发现，复制生成密钥的PRNG环境、搜索生成的一小部分可能性比暴力搜索整个密钥空间要容易得多。生成高质量的随机数是困难的。RFC 4086[RANDOM]在这方面提供了重要的指导，FIPS Pub 186[FIPS]的附录3提供了一种高质量的PRNG技术。
In the mechanisms described in Section 5, the shared KEK being distributed in glkWrapped MUST be protected by a key of equal or greater length (e.g., if an AES 128-bit key is being distributed, a key of 128 bits or greater must be used to protect the key).
在第5节所述的机制中，glkWrapped中分发的共享KEK必须由长度相等或更大的密钥保护（例如，如果分发的是AES 128位密钥，则必须使用128位或更大的密钥来保护密钥）。
The algorithm object identifiers included in glkWrapped are as specified in [CMSALG] and [CMSAES].
glkWrapped中包含的算法对象标识符如[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.
由于GLO控制总账的设置和拆卸以及总账的重新键入，并且可以控制成员的添加和删除，因此GLO在总账的管理中发挥着重要作用，并且只能使用“受信任的”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未重新设置密钥，则该成员仍然拥有组密钥，并且能够继续解密可以获得的任何消息。
Members who store KEKs MUST associate the name of the GLA that distributed the key so that the members can make sure subsequent rekeys are originated from the same entity.
存储KEK的成员必须关联分发密钥的GLA的名称，以便成员可以确保后续密钥来自同一实体。
When generating keys, care should be taken to ensure that the key size is not too small and duration too long because attackers will have more time to attack the key. Key size should be selected to adequately protect sensitive business communications.
生成密钥时，应注意确保密钥大小不太小，持续时间不太长，因为攻击者有更多的时间攻击密钥。应选择密钥大小，以充分保护敏感的业务通信。
GLOs and GLAs need to make sure that the generationCounter and duration are not too large. For example, if the GLO indicates that the generationCounter is 14 and the duration is one year, then 14 keys are generated each with a validity period of a year. An attacker will have at least 13 years to attack the final key.
GLO和GLA需要确保generationCounter和持续时间不太大。例如，如果GLO指示generationCounter为14且持续时间为一年，则将生成14个密钥，每个密钥的有效期为一年。攻击者至少有13年时间攻击最终密钥。
Assume that two or more parties have a shared KEK, and the shared KEK is used to encrypt a second KEK for confidential distribution to those parties. The second KEK might be used to encrypt a third KEK, the third KEK might be used to encrypt a fourth KEK, and so on. If any of the KEKs in such a chain is compromised, all of the subsequent KEKs in the chain MUST also be considered compromised.
假设两个或多个参与方有一个共享的KEK，共享的KEK用于加密第二个KEK，以便机密地分发给这些参与方。第二个KEK可用于加密第三个KEK，第三个KEK可用于加密第四个KEK，依此类推。如果此类链中的任何KEK受损，则链中所有后续KEK也必须视为受损。
An attacker can attack the group's shared KEK by attacking one member's copy of the shared KEK or attacking multiple members' copies of the shared KEK. For the attacker, it may be easier to either attack the group member with the weakest security protecting its copy of the shared KEK or attack multiple group members.
攻击者可以通过攻击一个成员的共享KEK副本或多个成员的共享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.
nonce和signingTime属性用于防止重播攻击。然而，这些规定只有在各实体保留关于其发送或接收的信息的国家信息以供比较时才有用。如果没有在每次交换上保存足够的信息，则nonce和signingTime没有帮助。本地策略确定所维护的状态信息的数量和持续时间。此外，如果没有统一的时间源，时钟可能会漂移。本地策略确定本地时间和签名时间之间可接受的差异，这必须补偿不同步的时钟。实现必须处理具有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 38522004年7月。
[CMC] Schaad, J. and M. Myers, "Certificate Management over CMS (CMC)", RFC 5272, June 2008.
[CMC]Schaad，J.和M.Myers，“CMS证书管理（CMC）”，RFC 52722008年6月。
[PROFILE] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008.
[PROFILE]Cooper，D.，Santesson，S.，Farrell，S.，Boeyen，S.，Housley，R.，和W.Polk，“互联网X.509公钥基础设施证书和证书撤销列表（CRL）简介”，RFC 52802008年5月。
[ACPROF] Farrell, S. and R. Housley, "An Internet Attribute Certificate Profile for Authorization", RFC 3281, April 2002.
[ACPROF]Farrell，S.和R.Housley，“用于授权的Internet属性证书配置文件”，RFC 3281，2002年4月。
[MSG] Ramsdell, B., Ed., "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification", RFC 3851, July 2004.
[MSG]Ramsdell，B.，编辑，“安全/多用途互联网邮件扩展（S/MIME）版本3.1消息规范”，RFC 3851，2004年7月。
[ESS] Hoffman, P., Ed., "Enhanced Security Services for S/MIME", RFC 2634, June 1999.
[ESS]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）算法”，RFC3370，2002年8月。
[CMSAES] Schaad, J., "Use of the Advanced Encryption Standard (AES) Encryption Algorithm in Cryptographic Message Syntax (CMS)", RFC 3565, July 2003.
[CMSAES]Schaad，J.“在加密消息语法（CMS）中使用高级加密标准（AES）加密算法”，RFC 3565，2003年7月。
[SMTP] Klensin, J., Ed., "Simple Mail Transfer Protocol", RFC 2821, April 2001.
[SMTP]Klensin，J.，Ed.，“简单邮件传输协议”，RFC 28212001年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.和C.Bonatti，“在X.400中传输安全/多用途Internet邮件扩展（S/MIME）对象”，RFC 38552004年7月。
[RANDOM] Eastlake, D., 3rd, Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
[RANDOM]Eastlake，D.，3rd，Schiller，J.和S.Crocker，“安全的随机性要求”，BCP 106，RFC 40862005年6月。
[FIPS] National Institute of Standards and Technology, FIPS Pub 186-2: Digital Signature Standard, January 2000.
[FIPS]国家标准与技术研究所，FIPS Pub 186-2：数字签名标准，2000年1月。
SMIMESymmetricKeyDistribution
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
pkcs-9(9) smime(16) modules(0) symkeydist(12) }
SMIMESymmetricKeyDistribution
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
pkcs-9(9) smime(16) modules(0) symkeydist(12) }
DEFINITIONS IMPLICIT TAGS ::=
BEGIN
DEFINITIONS IMPLICIT TAGS ::=
BEGIN
-- EXPORTS All --
-- The types and values defined in this module are exported for use
-- in the other ASN.1 modules. Other applications may use them for
-- their own purposes.
-- EXPORTS All --
-- 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 - 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) }
-- 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) }
-- 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) }
-- 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) };
-- 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.
-- 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) }
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 Use KEK control属性。
id-skd-glUseKEK OBJECT IDENTIFIER ::= { id-skd 1 }
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 }
GLUseKEK ::= SEQUENCE {
glInfo GLInfo,
glOwnerInfo SEQUENCE SIZE (1..MAX) OF GLOwnerInfo,
glAdministration GLAdministration DEFAULT 1,
glKeyAttributes GLKeyAttributes OPTIONAL }
GLInfo ::= SEQUENCE {
glName GeneralName,
glAddress GeneralName }
GLInfo ::= SEQUENCE {
glName GeneralName,
glAddress GeneralName }
GLOwnerInfo ::= SEQUENCE {
glOwnerName GeneralName,
glOwnerAddress GeneralName,
certificates Certificates OPTIONAL }
GLOwnerInfo ::= SEQUENCE {
glOwnerName GeneralName,
glOwnerAddress GeneralName,
certificates Certificates OPTIONAL }
GLAdministration ::= INTEGER {
unmanaged (0),
managed (1),
closed (2) }
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 } }
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.
-- This defines the Delete GL control attribute.
-- It has the simple type GeneralName.
id-skd-glDelete OBJECT IDENTIFIER ::= { id-skd 2 }
id-skd-glDelete OBJECT IDENTIFIER ::= { id-skd 2 }
DeleteGL ::= GeneralName
DeleteGL ::= GeneralName
-- This defines the Add GL Member control attribute.
--这定义了“添加总账成员控制”属性。
id-skd-glAddMember OBJECT IDENTIFIER ::= { id-skd 3 }
id-skd-glAddMember OBJECT IDENTIFIER ::= { id-skd 3 }
GLAddMember ::= SEQUENCE {
glName GeneralName,
glMember GLMember }
GLAddMember ::= SEQUENCE {
glName GeneralName,
glMember GLMember }
GLMember ::= SEQUENCE {
glMemberName GeneralName,
glMemberAddress GeneralName OPTIONAL,
certificates Certificates OPTIONAL }
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]
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.
--这定义了“删除总账成员”控件属性。
id-skd-glDeleteMember OBJECT IDENTIFIER ::= { id-skd 4 }
id-skd-glDeleteMember OBJECT IDENTIFIER ::= { id-skd 4 }
GLDeleteMember ::= SEQUENCE {
glName GeneralName,
glMemberToDelete GeneralName }
GLDeleteMember ::= SEQUENCE {
glName GeneralName,
glMemberToDelete GeneralName }
-- This defines the Delete GL Member control attribute.
--这定义了“删除总账成员”控件属性。
id-skd-glRekey OBJECT IDENTIFIER ::= { id-skd 5 }
id-skd-glRekey OBJECT IDENTIFIER ::= { id-skd 5 }
GLRekey ::= SEQUENCE {
glName GeneralName,
glAdministration GLAdministration OPTIONAL,
glNewKeyAttributes GLNewKeyAttributes OPTIONAL,
glRekeyAllGLKeys BOOLEAN OPTIONAL }
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 }
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.
--这定义了添加和删除总账所有者控制属性。
id-skd-glAddOwner OBJECT IDENTIFIER ::= { id-skd 6 }
id-skd-glRemoveOwner OBJECT IDENTIFIER ::= { id-skd 7 }
id-skd-glAddOwner OBJECT IDENTIFIER ::= { id-skd 6 }
id-skd-glRemoveOwner OBJECT IDENTIFIER ::= { id-skd 7 }
GLOwnerAdministration ::= SEQUENCE {
glName GeneralName,
glOwnerInfo GLOwnerInfo }
GLOwnerAdministration ::= SEQUENCE {
glName GeneralName,
glOwnerInfo GLOwnerInfo }
-- This defines the GL Key Compromise control attribute.
-- It has the simple type GeneralName.
-- This defines the GL Key Compromise control attribute.
-- It has the simple type GeneralName.
id-skd-glKeyCompromise OBJECT IDENTIFIER ::= { id-skd 8 }
id-skd-glKeyCompromise OBJECT IDENTIFIER ::= { id-skd 8 }
GLKCompromise ::= GeneralName
GLKCompromise ::= GeneralName
-- This defines the GL Key Refresh control attribute.
--这定义了GL键刷新控制属性。
id-skd-glkRefresh OBJECT IDENTIFIER ::= { id-skd 9 }
id-skd-glkRefresh OBJECT IDENTIFIER ::= { id-skd 9 }
GLKRefresh ::= SEQUENCE {
glName GeneralName,
dates SEQUENCE SIZE (1..MAX) OF Date }
GLKRefresh ::= SEQUENCE {
glName GeneralName,
dates SEQUENCE SIZE (1..MAX) OF Date }
Date ::= SEQUENCE {
start GeneralizedTime,
end GeneralizedTime OPTIONAL }
Date ::= SEQUENCE {
start GeneralizedTime,
end GeneralizedTime OPTIONAL }
-- This defines the GLA Query Request control attribute.
--这定义了GLA查询请求控制属性。
id-skd-glaQueryRequest OBJECT IDENTIFIER ::= { id-skd 11 }
id-skd-glaQueryRequest OBJECT IDENTIFIER ::= { id-skd 11 }
GLAQueryRequest ::= SEQUENCE {
glaRequestType OBJECT IDENTIFIER,
glaRequestValue ANY DEFINED BY glaRequestType }
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 }
id-skd-glaQueryResponse OBJECT IDENTIFIER ::= { id-skd 12 }
GLAQueryResponse ::= SEQUENCE {
glaResponseType OBJECT IDENTIFIER,
glaResponseValue ANY DEFINED BY glaResponseType }
GLAQueryResponse ::= SEQUENCE {
glaResponseType OBJECT IDENTIFIER,
glaResponseValue ANY DEFINED BY glaResponseType }
-- This defines the GLA Request/Response (glaRR) arc for
-- glaRequestType/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) }
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 }
id-cmc-gla-skdAlgRequest OBJECT IDENTIFIER ::= { id-cmc-glaRR 1 }
SKDAlgRequest ::= NULL
SKDAlgRequest ::= NULL
-- This defines the Algorithm Response.
--这定义了算法响应。
id-cmc-gla-skdAlgResponse OBJECT IDENTIFIER ::= { id-cmc-glaRR 2 }
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.
-- 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 }
id-skd-glProvideCert OBJECT IDENTIFIER ::= { id-skd 13 }
GLManageCert ::= SEQUENCE {
glName GeneralName,
glMember GLMember }
GLManageCert ::= SEQUENCE {
glName GeneralName,
glMember GLMember }
-- This defines the control attribute to return an updated
-- certificate to the GLA. It has the type GLManageCert.
-- 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 }
id-skd-glManageCert OBJECT IDENTIFIER ::= { id-skd 14 }
-- This defines the control attribute to distribute the GL shared
-- KEK.
-- This defines the control attribute to distribute the GL shared
-- KEK.
id-skd-glKey OBJECT IDENTIFIER ::= { id-skd 15 }
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 }
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) }
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) }
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
结束—Smimes分布
Author's Address
作者地址
Sean Turner IECA, Inc. 3057 Nutley Street, Suite 106 Fairfax, VA 22031 USA
Sean Turner IECA，Inc.美国弗吉尼亚州费尔法克斯市努特利街3057号106室，邮编22031
EMail: turners@ieca.com
EMail: turners@ieca.com
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2008).
版权所有（C）IETF信托基金（2008年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、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秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/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的IETF-ipr@ietf.org.