RFC 5275

CMS Symmetric Key Management and Distribution

📅 published June 2008, from ietf

RFC 5275: CMS Symmetric Key Management and Distribution 🎀

Network Working Group, Request for Comments 5275. Author: S. Turner, IECA. Category: Standards Track. Date: June 2008. The header doesn't list any RFC this one obsoletes or updates 🦋

Status of This Memo 📜

Okay so this document is an Internet standards track protocol for the Internet community, and it literally asks for discussion and suggestions for improvements 💅 For the current standardization state and status of this protocol, check the "Internet Official Protocol Standards" (STD 1), since that's the source of truth. Distribution of this memo is unlimited 🌸

Abstract 🔮

So this doc describes a way to manage keys for symmetric cryptographic algorithms: setting them up, distributing them, and rekeying them 🔑 It also defines how to sort users into groups, so encrypted content can be shared with everyone in the group using symmetric algorithms. ✨

The mechanism runs on the Cryptographic Message Syntax (CMS) protocol and the Certificate Management over CMS (CMC) protocol to handle those symmetric keys 🧚 Then any group member can use the shared key they were given to decrypt other CMS encrypted objects. It's giving teamwork 🫶 This whole thing was built to support Secure/Multipurpose Internet Mail Extensions (S/MIME) Mail List Agents (MLAs) 💌

Table of Contents 📑

   1. Introduction ....................................................4
      1.1. Conventions Used in This Document ..........................4
      1.2. Applicability to E-mail ....................................5
      1.3. Applicability to Repositories ..............................5
      1.4. Using the Group Key ........................................5
   2. Architecture ....................................................6
   3. Protocol Interactions ...........................................7
      3.1. Control Attributes .........................................8
           3.1.1. GL Use KEK .........................................10
           3.1.2. Delete GL ..........................................14
           3.1.3. Add GL Member ......................................14
           3.1.4. Delete GL Member ...................................15
           3.1.5. Rekey GL ...........................................16
           3.1.6. Add GL Owner .......................................16
           3.1.7. Remove GL Owner ....................................17
           3.1.8. GL Key Compromise ..................................17
           3.1.9. GL Key Refresh .....................................18
           3.1.10. GLA Query Request and Response ....................18
                  3.1.10.1. GLA Query Request ........................18
                  3.1.10.2. GLA Query Response .......................19
                  3.1.10.3. Request and Response Types ...............19
           3.1.11. Provide Cert ......................................19
           3.1.12. Update Cert .......................................20
           3.1.13. GL Key ............................................21
      3.2. Use of CMC, CMS, and PKIX .................................23
           3.2.1. Protection Layers ..................................23
                  3.2.1.1. Minimum Protection ........................23
                  3.2.1.2. Additional Protection .....................24
           3.2.2. Combining Requests and Responses ...................24
           3.2.3. GLA Generated Messages .............................26
           3.2.4. CMC Control Attributes and CMS Signed Attributes ...27
                  3.2.4.1. Using cMCStatusInfoExt ....................27
                  3.2.4.2. Using transactionId .......................30
                  3.2.4.3. Using Nonces and signingTime ..............30
                  3.2.4.4. CMC and CMS Attribute Support
                           Requirements ..............................31
           3.2.5. Resubmitted GL Member Messages .....................31
           3.2.6. PKIX Certificate and CRL Profile ...................31
   4. Administrative Messages ........................................32
      4.1. Assign KEK to GL ..........................................32
      4.2. Delete GL from GLA ........................................36
      4.3. Add Members to GL .........................................38
           4.3.1. GLO Initiated Additions ............................39
           4.3.2. Prospective Member Initiated Additions .............47
      4.4. Delete Members from GL ....................................49
           4.4.1. GLO Initiated Deletions ............................50
           4.4.2. Member Initiated Deletions .........................56
      4.5. Request Rekey of GL .......................................57
           4.5.1. GLO Initiated Rekey Requests .......................59
           4.5.2. GLA Initiated Rekey Requests .......................62
      4.6. Change GLO ................................................63
      4.7. Indicate KEK Compromise ...................................65
           4.7.1. GL Member Initiated KEK Compromise Message .........66
           4.7.2. GLO Initiated KEK Compromise Message ...............67
      4.8. Request KEK Refresh .......................................69
      4.9. GLA Query Request and Response ............................70
      4.10. Update Member Certificate ................................73
           4.10.1. GLO and GLA Initiated Update Member Certificate ...73
           4.10.2. GL Member Initiated Update Member Certificate .....75
   5. Distribution Message ...........................................77
      5.1. Distribution Process ......................................78
   6. Algorithms .....................................................79
      6.1. KEK Generation Algorithm ..................................79
      6.2. Shared KEK Wrap Algorithm .................................79
      6.3. Shared KEK Algorithm ......................................79
   7. Message Transport ..............................................80
   8. Security Considerations ........................................80
   9. Acknowledgements ...............................................81
   10. References ....................................................81
      10.1. Normative References .....................................81
      10.2. Informative References ...................................82
   Appendix A. ASN.1 Module ..........................................83

1. Introduction ✨

Secure electronic communications are everywhere now, like S/MIME [MSG] 💌 So people need a way to send encrypted data to multiple recipients at once, aka a whole group of users 👯‍♀️ There are basically two ways to encrypt for recipients: asymmetric algorithms with public key certificates (PKCs), or symmetric algorithms with symmetric keys 🗝️

With asymmetric algorithms, the originator makes an originator-determined content-encryption key (CEK) and uses a symmetric algorithm to encrypt the content 🔐 Then, using an asymmetric algorithm and each recipient's PKCs, the originator generates per-recipient information. That info either (a) encrypts the CEK for one particular recipient (ktri RecipientInfo CHOICE), or (b) transfers enough parameters for a particular recipient to independently generate the same KEK (kari RecipientInfo CHOICE). If the group is big, processing all that per-recipient info can take forever 😭 Not to mention collecting and validating the PKCs for every single recipient. Each recipient finds their own per-recipient info, uses the private key tied to their PKC to decrypt the CEK, and gets into the encrypted content 🎉

With symmetric algorithms, the process is a little different. Instead of PKCs, the originator uses a secret key-encryption key (KEK) that was distributed earlier to encrypt the CEK (kekri RecipientInfo CHOICE) 🗝️ Only one copy of the encrypted CEK is needed, because all the recipients already have the shared KEK they need to decrypt the CEK and access the content 🧚

The techniques for protecting the shared KEK are out of scope for this doc 🙈 Only the members of the list and the key manager should have the KEK to keep things confidential. Access control for the info protected by the KEK is decided by whoever encrypts it, since all group members get access 👑 If the encryptor wants some subset of the group to be locked out, then a different KEK should be used (shared only with that smaller group), or asymmetric algorithms should be used instead 💅

1.1. Conventions Used in This Document 📖

Okay, this is the important bit. 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] 🎀

1.2. Applicability to E-mail 📧

E-mail is one of the main audiences for this distribution mechanism 💜 Distribution lists, sometimes called mail lists, send messages to everyone subscribed to them 📬 There are two models for how a mail list can be used.

If the originator is a member of the mail list, they send messages encrypted with the shared KEK to the mail list (e.g., listserv or majordomo), and the message gets distributed to the list members 🌈 If the originator is not a member of the mail list (so they don't have the shared KEK), they send the message encrypted for the MLA to the Mail List Agent (MLA). Then the MLA uses the shared KEK to encrypt the message for the members 🦋 Either way, the mail list recipients use the previously distributed shared KEK to decrypt the message ✨

1.3. Applicability to Repositories 🗄️

Objects can also be shared through a repository, like Lightweight Directory Access Protocol (LDAP) servers, X.500 Directory System Agents (DSAs), or web-based servers 🌸 If an object is stored in a repository encrypted with a symmetric key algorithm, anyone who has the shared KEK and access to that object can decrypt it 🔓 The encrypted object and the encrypted shared KEK can both be stored in the repository 🍓

1.4. Using the Group Key ✨

Okay bestie, this doc was written with three scenarios in mind 👑. Two of them are about Mail List Agents (MLAs), and one is about general message distribution 💌.

Scenario 1 is the originator sending a public key (PK) protected message to an MLA. The MLA then uses the shared KEK(s) to pass it along to everyone on the list 🦋. Scenario 2 is the originator sending a shared KEK protected message to an MLA, which redistributes it to the members. The MLA only adds additional recipients here, so it's giving simple 💅. The originator's key could be shared among all recipients, or just between the member and the MLA. Note!! If the originator uses a key that's shared only with the MLA, then the MLA has to decrypt the message and re-encrypt it for the list recipients 🙈. Scenario 3 is an originator sending a shared KEK protected message to a group of recipients with no middle-person MLA involved 🧚.

                   +---->                   +---->       +---->
    PK   +-----+ S |         S    +-----+ S |         S  |
   ----> | MLA | --+---->   ----> | MLA | --+---->   ----+---->
         +-----+   |              +-----+   |            |
                   +---->                   +---->       +---->

       Scenario 1               Scenario 2           Scenario 3

2. Architecture 🏗️

Okay so Figure 1 shows the architecture for supporting symmetric key distribution 🔑. The Group List Agent (GLA) has two distinct jobs, and each one is handled by a different agent:

The Key Management Agent (KMA), which is responsible for generating the shared KEKs.
The Group Management Agent (GMA), which is responsible for managing the Group List (GL) that the shared KEKs get distributed to.

   +----------------------------------------------+
   |              Group List Agent                |    +-------+
   | +------------+    + -----------------------+ |    | Group |
   | |    Key     |    | Group Management Agent | |<-->| List  |
   | | Management |<-->|     +------------+     | |    | Owner |
   | |   Agent    |    |     | Group List |     | |    +-------+
   | +------------+    |     +------------+     | |
   |                   |       /  |  \          | |
   |                   +------------------------+ |
   +----------------------------------------------+
                            /     |      \
                           /      |       \
               +----------+ +---------+ +----------+
               | Member 1 | |   ...   | | Member n |
               +----------+ +---------+ +----------+

        Figure 1 - Key Distribution Architecture

A GLA can support multiple KMAs 🌸. A GLA in general supports only one GMA, but that GMA can support multiple GLs. Multiple KMAs can support a GMA in the same way that GLAs support multiple KMAs. Assigning a particular KMA to a GL is beyond the scope of this document, so we're leaving that one alone 🙈.

Now, modeling real-world GL implementations shows there are two extremes 💀. There are very restrictive GLs, where a human decides who's a member, and very open GLs, where there are no restrictions on membership at all. To cover that whole spectrum, the mechanism supports both managed (meaning access control is applied) and unmanaged (meaning 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 (for example, an MLA distributing a mail message), then that entity can also enforce access control rules 🫶.

Either way, the GL must initially be constructed by an entity called the Group List Owner (GLO) 👑. There may be multiple entities who 'own' the GL and are allowed to make changes to the GL's properties or membership. The GLO decides 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, and they can also set up closed lists, where the GLO solely determines the GL membership 🔒.

Even though Figure 1 shows the GLA as encompassing both the KMA and GMA functions, the two functions could be supported by the same entity, or by two different entities 🎀. If two entities are used, they could be located on one or two platforms. There's however a close relationship between the KMA and GMA functions 💅. If the GMA stores all the information about the GLs and the KMA merely generates keys, then 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 make sure the GMA didn't 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 🙅‍♀️.

Proprietary mechanisms may be used to separate the functions by strengthening the trust relationship between the two entities 🔐. From here on, the distinction between the two agents isn't discussed any further, and the term GLA is used to address both functions. It should be noted that a corrupt GLA can always cause havoc 💀.

3. Protocol Interactions ⚡

Okay so there are existing mechanisms (like listserv and majordomo) to manage GLs 📮. However, this document does not address securing these mechanisms, because they are not standardized. Instead, it defines the protocol interactions shown in Figure 2 🦋. Those are used by the GL members, the GLA, and the GLO(s) to manage GLs and distribute shared KEKs.

The interactions are split into administration messages and distribution messages 💖. The administrative messages are the request and response messages needed to set up the GL, delete the GL, add members to the GL, delete members of the GL, request a group rekey, add owners to the GL, remove owners of the GL, indicate a group key compromise, refresh a group key, interrogate the GLA, and update members' and owners' public key certificates 📜. The distribution messages are the ones that distribute the shared KEKs. The following sections describe the ASN.1 for both the administration and distribution messages. Section 4 explains how to use the administration messages, and Section 5 explains how to use the distribution messages 🌈.

      +-----+                   +----------+
      | GLO | <---+      +----> | Member 1 |
      +-----+     |      |      +----------+
                  |      |
   +-----+ <------+      |      +----------+
   | GLA | <-------------+----> |   ...    |
   +-----+               |      +----------+
                         |
                         |      +----------+
                         +----> | Member n |
                                +----------+

        Figure 2 - Protocol Interactions

3.1. Control Attributes 🧁

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 picking it was the layering it provides, where one or more control attributes are included in a message and 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 then get encapsulated in CMS's SignedData or EnvelopedData, or a combination of the two (see Section 3.2). Here are the control attributes defined in this document 👇:

      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

Now for the conformance tables 🔍. In them, the column headings mean: 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, so all GLO O and GLO R messages are optional, and GLA F messages are optional too 🤷‍♀️.

The first table includes the messages that conformant implementations MUST support 💪. The second table includes messages that MAY be implemented 🌸. The second table should be read like this: 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 ✨.

                         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

Heads up 📣: glaQueryResponse is carried in the CMC PKIResponse content-type, and all the other control attributes are carried in the CMC PKIData content-type. The exception is glUpdateCert, which can be carried in either PKIData or PKIResponse 🧡.

Success and failure messages use CMC (see Section 3.2.4) 💌.

3.1.1. GL Use KEK ✨

okay so the GLO uses glUseKEK to ask for a shared KEK to be assigned to a GL 🎀 glUseKEK messages MUST be signed by the GLO. the glUseKEK control attribute has the syntax GLUseKEK:

GLUseKEK ::= SEQUENCE {
  glInfo                GLInfo,
  glOwnerInfo           SEQUENCE SIZE (1..MAX) OF GLOwnerInfo,
  glAdministration      GLAdministration DEFAULT 1,
  glKeyAttributes       GLKeyAttributes OPTIONAL }

GLInfo ::= SEQUENCE {
  glName     GeneralName,
  glAddress  GeneralName }

GLOwnerInfo ::= SEQUENCE {
  glOwnerName     GeneralName,
  glOwnerAddress  GeneralName,
  certificate     Certificates OPTIONAL }

Certificates ::= SEQUENCE {
   pKC                [0] Certificate OPTIONAL,
                               -- See [PROFILE]
   aC                 [1] SEQUENCE SIZE (1.. MAX) OF
                          AttributeCertificate OPTIONAL,
                               -- See [ACPROF]
   certPath           [2] CertificateSet OPTIONAL }
                               -- From [CMS]

-- CertificateSet and CertificateChoices are included only
-- for illustrative purposes as they are imported from [CMS].

CertificateSet ::= SET SIZE (1..MAX) OF CertificateChoices

-- CertificateChoices supports X.509 public key certificates in
-- certificates and v2 attribute certificates in v2AttrCert.

GLAdministration ::= INTEGER {
  unmanaged  (0),
  managed    (1),
  closed     (2) }

GLKeyAttributes ::= SEQUENCE {
  rekeyControlledByGLO       [0] BOOLEAN DEFAULT FALSE,
  recipientsNotMutuallyAware [1] BOOLEAN DEFAULT TRUE,
  duration                   [2] INTEGER DEFAULT 0,
  generationCounter          [3] INTEGER DEFAULT 2,
  requestedAlgorithm         [4] AlgorithmIdentifier
                              DEFAULT { id-aes128-wrap } }

the fields in GLUseKEK have the following meaning:

glInfo tells us the name of the GL in glName and the address of the GL in glAddress. the glName and glAddress can be the same, but that's not always the case. Both the name and address MUST be unique for a given GLA.
glOwnerInfo tells us a few things:
- glOwnerName is 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). 💅
- glOwnerAddress is the GL owner's address. 🌸
- certificates MAY be included. it has three fields:
  - certificates.pKC holds the encryption certificate for the GLO. it gets used to encrypt responses for the GLO. 🔐
  - certificates.aC MAY be included to carry any attribute certificate (see [ACPROF]) linked to the encryption certificate of the GLO in certificates.pKC.
  - certificates.certPath MAY also be included to carry certificates that could help the recipient build valid certification paths for the certificate in certificates.pKC and the attribute certificates in certificates.aC. These are optional because they might already be somewhere else in the message (e.g., in the outer CMS layer). 🧚
- glAdministration says how the GL ought to be administered. the default is for the list to be managed. three values are supported:
  - Unmanaged: when the GLO sets glAdministration to unmanaged, prospective members can request addition and deletion from the GL without the GLO getting involved. 🦋
  - Managed: when the GLO sets glAdministration to managed, prospective members can request addition and deletion from the GL, but the GLA redirects the request to the GLO for review. the GLO decides whether to honor it. 👑
  - Closed: when the GLO sets glAdministration to closed, prospective members can't request addition or deletion from the GL. the GLA only accepts glAddMember and glDeleteMember requests from the GLO. 🔒
- glKeyAttributes tells the GLA which attributes the GLO wants for the shared KEK. if this field is left out, here's the tea: GL rekeys are controlled by the GLA, the recipients are allowed to know about one another, the algorithm is AES-128 (see Section 7), the shared KEK is valid for a calendar month (first of the month until the last day of the month), and two shared KEKs get distributed up front. the fields in glKeyAttributes mean this:
  - rekeyControlledByGLO says whether the GL rekey messages are generated by the GLO or by the GLA. the default is for the GLA to control rekeys. if the GLA controls rekey, the GL keeps getting rekeyed until the GLO deletes the GL or switches the GL rekey to GLO control. 🔁
  - recipientsNotMutuallyAware says the GLO wants the GLA to distribute the shared KEK individually for each GL member (i.e., a separate glKey message is sent to each recipient). the default is for a separate glKey message not to be required.

Note: this supports lists where one member doesn't know who the other members are. for example, a list is set up so only one member has submit permissions. everyone else is just "listening." the security policy of the list doesn't let the members know who else is on it. if a glKey is built for all of the GL members, info about each member could be derived from the information in RecipientInfos.

to make sure the glKey message doesn't leak info about the other recipients, a separate glKey message would be sent to each GL member. 🤫

duration is how long (in days) the shared KEK is considered valid. the value zero (0) means the shared KEK is valid for a calendar month in the UTC Zulu time zone. for example, if the duration is zero (0) and the GL shared KEK is requested on July 24, the first key is valid until the end of July, and the next key is valid for the entire month of August. if the value isn't zero (0), the shared KEK is valid for that many days. for example, if the duration is seven (7) and the shared KEK is requested on Monday but not generated until Tuesday (13 May 2008), the shared KEKs are valid from Tuesday (13 May 2008) to Tuesday (20 May 2008). the exact time of day gets decided when the key is generated. ⏰
generationCounter is the number of keys the GLO wants the GLA to distribute. to keep the GL running without interruption, two (2) shared KEKs at a minimum MUST be initially distributed. the second shared KEK gets distributed along with the first, so when the first one stops being valid, the second one can be used. if the GLA controls rekey, this field also says how many shared KEKs the GLO wants outstanding at any one time. see Sections 4.5 and 5 for more on rekey. 🔑
requestedAlgorithm is 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. 🧁

3.1.2. Delete GL 🗑️

GLOs use glDelete to ask for a GL to 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 goes in GeneralName:

DeleteGL ::= GeneralName

3.1.3. Add GL Member 🎉

GLOs use the glAddMember to ask for new members to be added, and prospective GL members use the glAddMember to ask to add themselves 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:

GLAddMember ::= SEQUENCE {
  glName    GeneralName,
  glMember  GLMember }

GLMember ::= SEQUENCE {
  glMemberName     GeneralName,
  glMemberAddress  GeneralName OPTIONAL,
  certificates     Certificates OPTIONAL }

the fields in GLAddMember mean the following:

glName tells us the name of the GL the member should be added to.
glMember gives the particulars for the GL member. both of the following fields must be unique for a given GL:
- glMemberName is the name of the GL member.
- glMemberAddress is the GL member's address. it MUST be included.

Note: sometimes glMemberName and glMemberAddress are the same, but that's not always the case.

certificates MUST be included. it has three fields:
- certificates.pKC holds the member's encryption certificate. it gets used, at least at first, 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 carry any attribute certificate (see [ACPROF]) linked to the member's encryption certificate.
- certificates.certPath MAY also be included to carry certificates that could help the recipient build valid certification paths for the certificate in certificates.pKC and the attribute certificates in certificates.aC. These are optional because they might already be somewhere else in the message (e.g., in the outer CMS layer). 🦋

3.1.4. Delete GL Member ✨

okay so GLOs use the glDeleteMember to ask for GL members to be deleted, and GL members use the glDeleteMember to ask to remove themselves 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:

GLDeleteMember ::= SEQUENCE {
  glName            GeneralName,
  glMemberToDelete  GeneralName }

the fields in GLDeleteMembers have these meanings:

glName says which GL the member should be removed from. 💖
glMemberToDelete says the name or address of the member who's getting deleted. 💀

3.1.5. Rekey GL 🔑

GLOs use the glRekey to request a GL rekey. the glRekey message MUST be signed by the GLO. the glRekey control attribute has the syntax GLRekey:

GLRekey ::= SEQUENCE {
  glName              GeneralName,
  glAdministration    GLAdministration OPTIONAL,
  glNewKeyAttributes  GLNewKeyAttributes OPTIONAL,
  glRekeyAllGLKeys    BOOLEAN OPTIONAL }

GLNewKeyAttributes ::= SEQUENCE {
  rekeyControlledByGLO       [0] BOOLEAN OPTIONAL,
  recipientsNotMutuallyAware [1] BOOLEAN OPTIONAL,
  duration                   [2] INTEGER OPTIONAL,
  generationCounter          [3] INTEGER OPTIONAL,
  requestedAlgorithm         [4] AlgorithmIdentifier OPTIONAL }

the fields in GLRekey have these meanings:

glName says which GL is getting rekeyed. 🌸
glAdministration says if the way the GL is administered is changing. see Section 3.1.1 for the three options. this field only shows up if it's different from the glAdministration that was registered before. 🎀
glNewKeyAttributes covers whether the rekey is controlled by the GLA or the GL, which algorithm and parameters the GLO wants, how long the key lasts, and how many keys will get issued. it's only included if it's different from the glKeyAttributes that was registered before. 🧚
glRekeyAllGLKeys says whether the GLO wants every outstanding GL shared KEK rekeyed. if it's TRUE, then all outstanding KEKs MUST be issued. if it's FALSE, then all outstanding KEKs need not be reissued. 👑

3.1.6. Add GL Owner 🦋

GLOs use the glAddOwner to ask that a brand new GLO be allowed to run the GL. the glAddOwner message MUST be signed by a registered GLO. the glAddOwner control attribute has the syntax GLOwnerAdministration:

GLOwnerAdministration ::= SEQUENCE {
  glName       GeneralName,
  glOwnerInfo  GLOwnerInfo }

the fields in GLAddOwners have these meanings:

glName says which GL the new GLO should be linked to. 💜
glOwnerInfo covers the name, address, and certificates of the new GLO. since this message has the names of new GLOs in it, the certificates.pKC MUST be included, and it MUST include the encryption certificate of the new GLO. this part is non-negotiable bestie 😭🫶

3.1.7. Remove GL Owner 🚪

GLOs use the glRemoveOwner to ask that a GLO get disassociated from the GL. the glRemoveOwner message MUST be signed by a registered GLO. the glRemoveOwner control attribute has the syntax GLOwnerAdministration:

GLOwnerAdministration ::= SEQUENCE {
  glName       GeneralName,
  glOwnerInfo  GLOwnerInfo }

the fields in GLRemoveOwners have these meanings:

glName says which GL the GLO should be disassociated from. 🌈
glOwnerInfo says the name and address of the GLO getting removed. the certificates field SHOULD be omitted, since it'll be ignored anyway. 🍓

3.1.8. GL Key Compromise 🚨

GL members and GLOs use glkCompromise to say that the shared KEK they have 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 that was generated with the compromised shared KEK. the name of the GL that the compromised key belongs to goes in GeneralName:

GLKCompromise ::= GeneralName

this one is a whole emergency vibe. the GLA always passes it along to the GLO, so it's not just sitting there ✨

3.1.9. GL Key Refresh 🔄

GL members use the glkRefresh to ask that the shared KEK be sent out to them again. the glkRefresh control attribute has the syntax GLKRefresh.

GLKRefresh ::= SEQUENCE {
  glName  GeneralName,
  dates   SEQUENCE SIZE (1..MAX) OF Date }

Date ::= SEQUENCE {
  start GeneralizedTime,
  end   GeneralizedTime OPTIONAL }

the fields in GLKRefresh have these meanings:

glName says which GL the member wants shared KEKs for. 🌷
dates is a date range for the keys the member wants. the start field is the first date they want, and the end field is the last one. the end date MAY be omitted, which means the member wants every key from the start date up until the current date. 🗓️ also, a procedural mechanism is needed to stop users from getting into messages they aren't allowed to read. it's giving security check 🔒

3.1.10. GLA Query Request and Response 🔍

sometimes GLOs and GL members need to figure out some info from the GLA about the GL. GLOs and GL members use the glaQueryRequest, which is defined in Section 3.1.10.1, to ask for info. GLAs use the glaQueryResponse, which is defined in Section 3.1.10.2, to send back what was asked for. Section 3.1.10.3 has one request and response type and value, but others might get defined in other documents too. 🧩

3.1.10.1. GLA Query Request 📩

GLOs and GL members use the glaQueryRequest to find out info about the GLA. the glaQueryRequest control attribute has the syntax GLAQueryRequest:

GLAQueryRequest ::= SEQUENCE {
  glaRequestType   OBJECT IDENTIFIER,
  glaRequestValue  ANY DEFINED BY glaRequestType }

3.1.10.2. GLA Query Response 📬

GLAs send back the glaQueryResponse after they get a GLAQueryRequest. the glaQueryResponse MUST be signed by a GLA. the glaQueryResponse control attribute has the syntax GLAQueryResponse:

GLAQueryResponse ::= SEQUENCE {
  glaResponseType   OBJECT IDENTIFIER,
  glaResponseValue  ANY DEFINED BY glaResponseType }

3.1.10.3. Request and Response Types 🏷️

requests and responses get registered as a pair under this object identifier arc:

id-cmc-glaRR OBJECT IDENTIFIER ::= { id-cmc 99 }

this document defines one request/response pair so GL members and GLOs can ask the GLA for the list of algorithms it supports. the following Object Identifier (OID) goes in the glaQueryType field:

id-cmc-gla-skdAlgRequest OBJECT IDENTIFIER ::={ id-cmc-glaRR 1 }

SKDAlgRequest ::= NULL

if the GLA supports GLAQueryRequest and GLAQueryResponse messages, the GLA may return the following OID in the glaQueryType field:

id-cmc-gla-skdAlgResponse OBJECT IDENTIFIER ::= { id-cmc-glaRR 2 }

the glaQueryValue has the form of the smimeCapabilities attributes as defined in [MSG]. 🎁

3.1.11. Provide Cert 📜

GLAs and GLOs use the glProvideCert to ask a GL member for an updated or brand 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 wraps up the glProvideCert request. the glProvideCert control attribute has the syntax GLManageCert:

GLManageCert ::= SEQUENCE {
  glName    GeneralName,
  glMember  GLMember }

the fields in GLManageCert have these meanings:

glName says which GL the member's new certificate should be linked to. 💌
glMember covers the particulars for the GL member:
- glMemberName is the GL member's name. 🫧
- glMemberAddress is the GL member's address. it MAY be omitted. 🌙
- certificates SHOULD be omitted. ✨

3.1.12 Update Cert 💅

GL members and GLOs use the glUpdateCert to send a new certificate for the GL. GL members can send an unsolicited glUpdateCert, or send a response glUpdateCert after getting 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 wraps up the glUpdateCert request or response. the glUpdateCert control attribute has the syntax GLManageCert:

GLManageCert ::= SEQUENCE {
  glName    GeneralName,
  glMember  GLMember }

the fields in GLManageCert have these meanings:

glName says which GL the member's new certificate should be linked to. 🦄
glMember covers the particulars for the GL member:
- glMemberName is the GL member's name. 🌺
- glMemberAddress is the GL member's address. it MAY be omitted. 🎀
- certificates MAY be omitted if the GLManageCert message is sent to request the GL member's certificate. otherwise, it MUST be included. it has these three fields:
  - certificates.pKC is the member's encryption certificate, which is used to encrypt the shared KEK for that member. 🔐
  - certificates.aC MAY be included to carry one or more attribute certificates tied to the member's encryption certificate. 🏅
  - certificates.certPath MAY also be included to carry certificates that might help the recipient build valid certification paths for the certificate in certificates.pKC and the attribute certificates in certificates.aC. these are optional because they might already be included somewhere else in the message, like in the outer CMS layer. 🛤️

3.1.13. GL Key 🔑✨

Okay bestie, the GLA uses the glKey message to pass the shared KEK around 🗝️ and the glKey message MUST be signed by the GLA 🖊️. No skipping that step. The glKey control attribute has the syntax GLKey:

GLKey ::= SEQUENCE {
  glName        GeneralName,
  glIdentifier  KEKIdentifier,      -- See [CMS]
  glkWrapped    RecipientInfos,     -- See [CMS]
  glkAlgorithm  AlgorithmIdentifier,
  glkNotBefore  GeneralizedTime,
  glkNotAfter   GeneralizedTime }

-- KEKIdentifier is included only for illustrative purposes as
-- it is imported from [CMS].

KEKIdentifier ::= SEQUENCE {
  keyIdentifier OCTET STRING,
  date GeneralizedTime OPTIONAL,
  other OtherKeyAttribute OPTIONAL }

Here's what each field means 💅

glName is the name of the GL 🏷️.
glIdentifier is the key identifier of the shared KEK. Check out Section 6.2.3 of [CMS] for the subfield breakdown 🔍.
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 about random number generation in the security considerations of [CMS]. Very serious, very important 🫶.
glkAlgorithm tells you which algorithm the shared KEK is used with 🧁. Since no encrypted data content is being carried at this point, the parameters encoded with the algorithm should be the structure defined for smimeCapabilities rather than encrypted content.
glkNotBefore is the date when 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. Time is not a vibe to be fuzzy about ⏰.
glkNotAfter is 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. Same rules, same energy 💜.

If the glKey message is in response to a glUseKEK message 🌷:

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) 💌.
The GLA MUST generate the requested number of glKey messages. The value in glUseKEK.glKeyAttributes.generationCounter indicates the number of glKey messages requested 🔢.

If the glKey message is in response to a glRekey message 🔄:

The GLA MUST generate separate glKey messages for each recipient if glRekey.glNewKeyAttributes.recipientsNotMutuallyAware is set to TRUE 🙅‍♀️.
The GLA MUST generate the requested number of glKey messages. The value in glUseKEK.glKeyAttributes.generationCounter indicates the number of glKey messages requested 🔢.
The GLA MUST generate one glKey message for each outstanding shared KEK for the GL when glRekeyAllGLKeys is set to TRUE 🫧.

If the glKey message was not in response to a glRekey or glUseKEK (e.g., where the GLA controls rekey) 🎀:

The GLA MUST generate separate glKey messages for each recipient when glUseKEK.glNewKeyAttributes.recipientsNotMutuallyAware that set up the GL was set to TRUE 💁‍♀️.
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 🦋.

3.2. Use of CMC, CMS, and PKIX 🎀

This section is all about how CMC, CMS, and the PKIX certificate and CRL profile fit together. Very cozy combo 🧚.

3.2.1. Protection Layers 🛡️

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]. Two paths, same destination 🌈.

3.2.1.1. Minimum Protection 🧱

At a minimum, a SignedData MUST protect each request and response encapsulated in PKIData and PKIResponse. This is the minimum wrapping, so it's non-negotiable 🙅‍♀️. Here's what it looks like:

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]. Check the signature first, then do the thing 🧐.

3.2.1.2. Additional Protection 🌹

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 optional extra wrappings look like this:

                              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] for the details 🍓.

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. It's like passing a note in class, but everybody has to be able to read it at the right moment 📝✨.

3.2.2. Combining Requests and Responses 📦

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 🙅‍♀️. Here's the diagram:

    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 🎁. Like this:

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 💀:

   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 something isn't listed, it's 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 🗂️.

3.2.3. GLA Generated Messages 📣

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 🙈.

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 🌸.

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 🤷‍♀️.

If a GL is managed and the GLA receives a glAddMember, glDeleteMember, or glkCompromise message, the GLA redirects the request to the GLO for review 👀. An additional SignedData MUST be applied to the redirected request as follows:

GLA Forwarded Requests
----------------------
SignedData
 PKIData
  cmsSequence
   SignedData
    PKIData
     controlSequence

3.2.4. CMC Control Attributes and CMS Signed Attributes 🏷️

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]. Keep scrolling, it gets even better ✨.

3.2.4.1. Using cMCStatusInfoExt ✨

okay bestie, so cMCStatusInfoExt is how GLAs tell GLOs and GL members "hey, that didn't work" 💅. There are two families of failure codes in this doc. Errors from the CMCFailInfo list (Section 5.1.4 of CMC) get encoded the way CMC defines them 🎀. Error codes defined here go in the ExtendedFailInfo field of the cmcStatusInfoExt structure 🦋. If the same failure code applies to a bunch of commands, you can use one cmcStatusInfoExt with multiple items in cMCStatusInfoExt.bodyList 💖. The GLA MAY also drop extra info in statusString 🌸. Here's the SKDFailInfo object identifier and value:

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) }

Here's what each value means 👑:

unspecified means the GLA can't or won't do the action and doesn't want to say why 🙈.
closedGL means only the GLO can add or delete members 🔒.
unsupportedDuration means the GLA doesn't support generating keys that last for the duration you asked for ⏳.
noGLACertificate means the GLA doesn't have a valid certificate 📜.
invalidCert means the member's encryption certificate couldn't be verified (so the signature didn't validate, the serial number is on a CRL, the cert expired, etc.) 💀.
unsupportedAlgorithm means the GLA doesn't support the algorithm you requested 🧪.
noGLONameMatch means none of the names in the cert used to sign a request match a registered GLO 🪪.
invalidGLName means the GLA doesn't support the glName in the request 🏷️.
nameAlreadyInUse means that glName is already taken on the GLA 🙅‍♀️.
noSpam means the prospective GL member didn't sign the request. Like, if the name in glMember.glMemberName doesn't match either the subject distinguished name or one of the subject alternative names in the cert used to sign it 🚫.
alreadyAMember means the prospective GL member is already a member 🫶.
notAMember means the prospective member you want to delete isn't a member right now 🤷‍♀️.
alreadyAnOwner means the prospective GLO is already a GLO 👑.
notAnOwner means the prospective GLO you want to delete isn't a GLO right now 🥀.

cMCStatusInfoExt is also how GLAs say a request worked 🎉. If it did, the GLA sends back a cMCStatusInfoExt response with cMCStatus.success, and optionally some other useful info in statusString ✨.

When the GL is managed and the GLO has reviewed GL member initiated glAddMember, glDeleteMember, and glkComrpomise requests, the GLO uses cMCStatusInfoExt to say whether each one succeeded or failed 🧐. If the request is allowed, cMCStatus.success comes back, and statusString can optionally carry extra info 💅. If it's denied, cMCStatus.failed comes back, and statusString can optionally carry extra info too 😭. The appropriate SKDFailInfo can also be included in cMCStatusInfoExt.extendedFailInfo 🎀.

cMCStatusInfoExt is used by GLOs, GLAs, and GL members to flag 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 get cMCStatusInfoExt messages with invalid signatures SHOULD generate a new request, so you don't end up in a badMessageCheck message loop 🔁🙅‍♀️.

cMCStatusInfoExt is also used by GLOs and GLAs when a request can't be done right away ⏸️. If the GLA or GLO can't process the request immediately, the cMCStatusInfoExt control attribute MUST be returned indicating cMCStatus.pending and otherInfo.pendInfo 🕐. When requests get redirected to the GLO for approval (for managed lists), the GLA MUST NOT return a cMCStatusInfoExt indicating query pending 🙅‍♀️.

cMCStatusInfoExt is also used by GLAs to say a glaQueryRequest isn't supported 📵. If it's not supported, the cMCStatusInfoExt control attribute MUST be returned indicating cMCStatus.noSupport, and statusString is optionally returned for extra info 💅.

Last one: cMCStatusInfoExt is used by GL members, GLOs, and GLAs to say the signingTime (see Section 3.2.4.3) isn't close enough to the local time ⏰. If the local time isn't close enough to the time in signingTime, a cMCStatus.failed and otherInfo.failInfo.badTime MAY be returned 🕰️.

3.2.4.2. Using transactionId 🦋

transactionId MAY be included by GLOs, GLAs, or GL members to identify a given transaction 🪪. Every later request and response tied to the original request MUST include that same transactionId control attribute, no exceptions bestie 🔗. If a GL member includes a transactionId and the request gets redirected to the GLO, the GLA MAY include an additional transactionId in the outer PKIData 🎀. If the GLA did that, then when the GLO generates a cMCStatusInfoExt response, it makes one for the GLA with the GLA's transactionId and one for the GL member with the GL member's transactionId 👯‍♀️.

3.2.4.3. Using Nonces and signingTime 🌸

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 together to give you application-level replay prevention 🛡️.

To protect the GL, all messages MUST include the signingTime attribute 💜. Message originators and recipients can then use the time in this attribute to figure out whether they've already received the message ⏳.

If the originating message includes a senderNonce, the response MUST include the received senderNonce value as the recipientNonce, plus a brand new value as the senderNonce in the response 🎀.

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 it in the wrapping message 🧁. When the response comes back from the GLO, the GLA builds a response for the originator(s) of the message(s) and handles each of the nonce values from the originating messages 💅.

For all of this, you have to keep state info on exchanges so you can compare one result to another 🗂️. How long you keep that info is a local policy thing 🕰️.

3.2.4.4. CMC and CMS Attribute Support Requirements 📋

These are the implementation requirements for CMC control attributes and CMS signed attributes if you want your implementation to count as conformant to this spec 🏆:

       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

3.2.5. Resubmitted GL Member Messages 🔄

When the GL is managed, the GLA forwards the GL member requests to the GLO for approval by making a new request message that holds the GL member request(s) as a cmsSequence item 📨. If the GLO approves, it can either add a new layer of wrapping and send it back to the GLA, or make a brand new message and send that to the GLA 💌. (Heads up: in this case there are now 3 layers of PKIData messages, each with its own signing layer 🧅.)

3.2.6. PKIX Certificate and CRL Profile 📜

Signatures, certificates, and CRLs get verified according to the PKIX profile [PROFILE] 🔍.

Name matching is done according to the PKIX profile [PROFILE] 🪞.

All distinguished name forms must follow the UTF8String convention noted in the PKIX profile [PROFILE] 🔤.

A certificate per GL would be issued to the GLA 🎟️.

GL policy may mandate that the GL member's address be included in the GL member's certificate 🏡.

4. Administrative Messages 💅

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 ✨.

4.1. Assign KEK to GL 💖

okay bestie, before anyone can make a group key, we need a GL set up with a shared KEK assigned to it 🎀. Figure 3 shows the back-and-forth for setting that up. heads up: error messages are NOT drawn in Figure 3 🙈, and the way this section handles the optional transactionId, senderNonce, and recipientNonce CMC control attributes isn't covered here either 💅.

    +-----+  1     2  +-----+
    | GLA | <-------> | GLO |
    +-----+           +-----+

Figure 3 - Create Group List

here's how it goes 🧚

1 - The GLO is the one in charge of asking for the GL to be created ✨. The GLO sends a SignedData.PKIData.controlSequence.glUseKEK request to the GLA (that's step 1 in Figure 3). The GLO MUST include glName, glAddress, glOwnerName, glOwnerAddress, and glAdministration. The GLO MAY also include their shared KEK preferences in glKeyAttributes by saying whether the GLO controls the rekey in rekeyControlledByGLO, whether separate glKey messages should go to each recipient in recipientsNotMutuallyAware, the algorithm they want for the shared KEK in requestedAlgorithm, how long the shared KEK lasts, and how many shared KEKs should be handed out at first in generationCounter. The GLO MUST also include the signingTime attribute with this request ⏰.
- 1.a - If the GLO knows of members to add 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 uses the same glName in the glAddMember request as in glUseKEK.glInfo.glName. More on glAddMember procedures in Section 4.3 🫶.
- 1.b - The GLO can add confidentiality to the request by wrapping the SignedData.PKIData in an EnvelopedData (see Section 3.2.1.2) 🔐.
- 1.c - The GLO can also optionally put another SignedData over the EnvelopedData (see Section 3.2.1.2).
2 - Once the GLA gets the request, it checks the signingTime and verifies the signature on the innermost SignedData.PKIData. If an extra SignedData and/or EnvelopedData wraps 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) BEFORE checking the innermost signature 👀.
- 2.a - If the signingTime value is outside the locally accepted time window, the GLA MAY return a response indicating cMCStatus.failed and otherInfo.failInfo.badTime along with a signingTime attribute 😬.
- 2.b - Else if signature processing continues and the signatures don't verify, the GLA returns a cMCStatusInfoExt response indicating cMCStatus.failed and otherInfo.failInfo.badMessageCheck. A signingTime attribute is included with the response too.
- 2.c - Else if the signatures DO verify but the GLA doesn't have a valid certificate, the GLA returns a cMCStatusInfoExt with cMCStatus.failed and otherInfo.extendedFailInfo.SKDFailInfo set to noValidGLACertificate. A signingTime attribute is included with the response. Instead of just bouncing the request right away, the GLA tries to get a certificate, possibly using [CMC] 🪄.
- 2.d - Else the signatures are valid and the GLA does have a valid certificate, so 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.1 - If the names don't match, the GLA returns a response indicating cMCStatusInfoExt with cMCStatus.failed and otherInfo.extendedFailInfo.SKDFailInfo set to noGLONameMatch. A signingTime attribute is included with the response.
  - 2.d.2 - Else if the names all match, the GLA checks that the glName and glAddress aren't already in use. The GLA also checks any glAddMember included in the controlSequence with this glUseKEK. Further glAddMember processing is covered in Section 4.3.
    - 2.d.2.a - If the glName is already in use, the GLA returns a response indicating cMCStatusInfoExt with cMCStatus.failed and otherInfo.extendedFailInfo.SKDFailInfo set to nameAlreadyInUse. A signingTime attribute is included with the response.
    - 2.d.2.b - Else if the requestedAlgorithm isn't supported, the GLA returns a response indicating cMCStatusInfoExt with cMCStatus.failed and otherInfo.extendedFailInfo.SKDFailInfo set to unsupportedAlgorithm. A signingTime attribute is included with the response.
    - 2.d.2.c - Else if the duration can't be supported (figuring that out is beyond the scope of this document), the GLA returns a response indicating cMCStatusInfoExt with cMCStatus.failed and otherInfo.extendedFailInfo.SKDFailInfo set to unsupportedDuration. A signingTime attribute is included with the response.
    - 2.d.2.d - Else if the GL can't be supported for other reasons that the GLA doesn't want to share, the GLA returns a response indicating cMCStatusInfoExt with cMCStatus.failed and otherInfo.extendedFailInfo.SKDFailInfo set to unspecified. A signingTime attribute is included with the response.
    - 2.d.2.e - Else if the glName isn't 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 (that's step 2 in Figure 3) ✅. The GLA also takes administrative actions (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.1 - The GLA can add confidentiality to the response by wrapping the SignedData.PKIResponse in an EnvelopedData if the request was wrapped in an EnvelopedData (see Section 3.2.1.2).
      - 2.d.2.e.2 - The GLA can also optionally put another SignedData over the EnvelopedData (see Section 3.2.1.2).
3 - Once the GLO gets the cMCStatusInfoExt responses, it checks the signingTime and verifies the GLA signature(s). If an extra SignedData and/or EnvelopedData wraps the response (see Section 3.2.1.2 or 3.2.2), the GLO verifies the outer signature and/or decrypts the outer layer BEFORE checking the innermost SignedData signature 🧐.
- 3.a - If the signingTime value is outside the locally accepted time window, the GLO MAY return a response indicating cMCStatus.failed and otherInfo.failInfo.badTime along with a signingTime attribute.
- 3.b - Else if signature processing continues and 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.1 - If the GL's name doesn't match the name in the certificate used to sign the message, the GLO should not believe the response 🚩.
  - 3.b.2 - Else if the GL's name DOES match the name in the certificate, and:
    - 3.b.2.a - If the signatures verify and the response was cMCStatusInfoExt indicating cMCStatus.success, the GLO has successfully created the GL 🎉👑.
    - 3.b.2.b - Else if the signatures are valid and the response is cMCStatusInfoExt.cMCStatus.failed for any reason, the GLO can try creating the GL again using the information in the response. The GLO can also use the glaQueryRequest to find out the algorithms and other characteristics the GLA supports (see Section 4.9) 🔍.

4.2. Delete GL from GLA 🥀

okay so sometimes a GL just isn't needed anymore, and when that happens the GLO deletes it 🗑️ Figure 4 shows the protocol interactions for deleting a GL. ngl, the behavior for the optional transactionId, senderNonce, and recipientNonce CMC control attributes is not addressed in these procedures 🙈

       +-----+   1    2  +-----+
       | GLA | <-------> | GLO |
       +-----+           +-----+

      Figure 4 - Delete Group List

Here's how it goes 💖

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 goes in GeneralName. The GLO MUST also include the signingTime attribute, and it can also include transactionId and senderNonce attributes ✨

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.b - The GLO MAY optionally apply another SignedData over the EnvelopedData (see Section 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. so the GLA peels the layers first, then checks the core 🧅

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.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. nope, bad signature 💀

2.c - Else if the signatures verify, the GLA makes sure the GL is supported by checking that the name of the GL matches a glName stored on the GLA 🔍

2.c.1 - If the glName is not supported by the GLA, the GLA returns a response indicating cMCStatusInfoExt with cMCStatus.failed and otherInfo.extendedFailInfo.SKDFailInfo value of invalidGLName. Additionally, a signingTime attribute is included with the response. not a GL it knows, bye 👋

2.c.2 - Else if the glName is supported by the GLA, the GLA makes sure 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.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. wrong GLO, sis 🙅‍♀️

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. the GLA keeps its reasons private, and that part is out of scope here 🤐

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. the GL is officially retired 🪦✨

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.2 - The GLA MAY optionally apply another SignedData over the EnvelopedData (see Section 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. the GLO does the same layer-peeling glow-up on the way back 🧚

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.b - Else if signature processing continues and if the signatures verify, the GLO checks that one of the names in the certificate used to sign the response matches the name of the GL 🧐

3.b.1 - 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. sus response, don't trust it 🚩

3.b.2 - Else if the name of the GL does match the name present in the certificate and:

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.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. try again, bestie 🔁

4.3. Add Members to GL 🌸

okay so adding members is where the drama starts 🍿 Both the GLO and prospective members use the glAddMember request to do it. Here's the tea: the GLA treats GLO requests and prospective member requests differently. 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 figure out how the GL is administered. When the GLO first configured the GL, it set the GL to be unmanaged, managed, or closed (see Section 3.1.1). In the unmanaged case, the GLA just processes the member's request. In the managed case, the GLA forwards the requests from the prospective members to the GLO for review. Where there are multiple GLOs for a GL, which GLO the request is forwarded to is beyond the scope of this document. The GLO reviews the request and either rejects it or submits a reformed request to the GLA. In the closed case, the GLA will not accept requests from prospective members. 🚪🔒

The following sections describe the processing for the GLO(s), GLA, and prospective GL members, depending on where the glAddMeber request originated, either from a GLO or from prospective members 🧩 Figure 5 shows the protocol interactions for the three options. Note that the error messages are not depicted. Also, the behavior for the optional transactionId, senderNonce, and recipientNonce CMC control attributes is not addressed in these procedures, so no peeking 🙈

      +-----+  2,B{A}              3  +----------+
      | GLO | <--------+    +-------> | Member 1 |
      +-----+          |    |         +----------+
               1       |    |
      +-----+ <--------+    |      3  +----------+
      | GLA |  A            +-------> |   ...    |
      +-----+ <-------------+         +----------+
                            |
                            |      3  +----------+
                            +-------> | Member n |
                                      +----------+

         Figure 5 - Member Addition

Now for the big question every GL owner faces 🤔 An important decision, made group by group, 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, because the overhead of rekeying becomes prohibitive as the group gets 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. 💅

4.3.1. GLO Initiated Additions 👑

Here's how a GLO-initiated glAddMember request goes 🪄

1 - The GLO collects the pertinent information for the member(s) to be added. This may be done through out-of-band means 📬 The GLO then sends a SignedData.PKIData.controlSequence with a separate glAddMember request for each member to the GLA (1 in Figure 5). The GLO includes the GL name in glName, the member's name in glMember.glMemberName, the member's address in glMember.glMemberAddress, and the member's encryption certificate in glMember.certificates.pKC. The GLO can also include any attribute certificates associated with the member's encryption certificate in glMember.certificates.aC, and the certification path associated with the member's encryption and attribute certificates in glMember.certificates.certPath. The GLO MUST also include the signingTime attribute with this request ⏰✨

1.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.b - The GLO can also optionally apply another SignedData over the EnvelopedData (see Section 3.2.1.2) 🎀

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). ✅ new member officially in the group, slay 💖

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.2 ✨ Okay so the GLA can also optionally slap another SignedData over the EnvelopedData, see Section 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 double-checks the GL is supported by making sure the glName matches a glName stored on the GLA 🔍
- 2.d.1 🙅‍♀️ If the glName isn't supported by the GLA, it returns a response indicating cMCStatusInfoExt with cMCStatus.failed and otherInfo.extendedFailInfo.SKDFailInfo value of invalidGLName. A signingTime attribute gets included with the response too 🕰️
- 2.d.2 💜 Else if the glName IS supported by the GLA, the GLA checks to see if the glMemberName is already on the GL 👀
  - 2.d.2.a 😭 If the glMemberName is already on the GL, the GLA returns a response indicating cMCStatusInfoExt with cMCStatus.failed and otherInfo.extendedFailInfo.SKDFailInfo value of alreadyAMember. A signingTime attribute is included with the response as well 🕰️
  - 2.d.2.b 🌸 Else if the glMemberName is NOT on the GL, the GLA checks how the GL is administered 🧐
    - 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.a 🙅‍♀️ If the names don't match, the GLA returns a response indicating cMCStatusInfoExt with cMCStatus.failed and otherInfo.extendedFailInfo.SKDFailInfo value of noGLONameMatch. A signingTime attribute is included with the response, obviously 🕰️
      - 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.1 💀 If the member's encryption certificate can't be verified, the GLA can return a response indicating cMCStatusInfoExt with cMCStatus.failed and otherInfo.extendedFailInfo.SKDFailInfo value of invalidCert to the GLO. A signingTime attribute is included with the response. If the GLA does not return a cMCStatusInfoExt.cMCStatus.failed response, the GLA issues a glProvideCert request (see Section 4.10) 📨
        
        2.d.2.b.1.b.2 👑 Else if the member's certificate verifies, the GLA returns a cMCStatusInfoExt indicating cMCStatus.success and a signingTime attribute (2 in Figure 5) 🥳 The GLA also takes administrative actions, which are beyond the scope of this document, to add the member to the GL stored on the GLA. It also distributes the shared KEK to the member via the mechanism described in Section 5 🗝️
        
        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.b ✨ The GLA can also optionally apply another SignedData over the EnvelopedData (see Section 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.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. A signingTime attribute is included with the response 🕰️
      - 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.1 💀 If the member's certificate can't be verified, the GLA can return a response indicating cMCStatusInfoExt with cMCStatus.failed and otherInfo.extendedFailInfo.SKDFailInfo value of invalidCert. 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.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. It 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.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.b ✨ The GLA can also optionally apply another SignedData over the EnvelopedData (see Section 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, which GLO the request gets forwarded to is beyond the scope of this document. Further processing of the forwarded request by GLOs is addressed in 3 of Section 4.3.2 📬
        
        2.d.2.b.2.c.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.2 ✨ The GLA can also optionally apply another SignedData over the EnvelopedData (see Section 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.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. A signingTime attribute is included with the response 🕰️
      - 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.1 💀 If the member's certificate can't 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 came from. If the GLA does not return a cMCStatus.failed response, the GLA issues a glProvideCert request (see Section 4.10) to either the GLO or the prospective member, depending on where the request came from 📨
2.d.2.b.3.b.2 - okay so if the member's certificate verifies ✨ the GLA sends back a cMCStatusInfoExt with cMCStatus.success plus a signingTime attribute. It goes to the GLO (2 in Figure 5) if the GLO signed the request, or to the GL member (3 in Figure 5) if the GL member signed it. The GLA also does its admin stuff to actually add the member to the GL it stores (that part is out of scope for this doc, so not our problem 💅). And it hands the shared KEK to the member using the mechanism in Section 5 🔐
- 2.d.2.b.3.b.2.a - the GLA adds confidentiality to the response by wrapping the SignedData.PKIData in an EnvelopedData if the request came in as an EnvelopedData (see Section 3.2.1.2) 🎀
- 2.d.2.b.3.b.2.b - the GLA can also optionally slap another SignedData over the EnvelopedData (see Section 3.2.1.2) 🦋
3 - bestie, when the cMCStatusInfoExt response lands, the GLO checks the signingTime and verifies the GLA signature(s) 🧐 If an extra SignedData and/or EnvelopedData is wrapped around the response (see Section 3.2.1.2 or 3.2.2), the GLO verifies the outer signature and/or decrypts the outer layer first, and only then verifies the signature on the innermost SignedData 🌸
- 3.a - if the signingTime attribute value is not within the locally accepted time window, the GLO MAY return a response indicating cMCStatus.failed and otherInfo.failInfo.badTime and a signingTime attribute 🙈
- 3.b - else if signature processing continues and the signatures verify, the GLO checks that one of the names in the certificate used to sign the response matches the name of the GL 👀
  - 3.b.1 - 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.2 - else if the name of the GL matches the name present in the certificate and:
    - 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.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 🔁
4 - the prospective member, when they get the cMCStatusInfoExt response, checks the signingTime and verifies the GLA signatures or GLO signatures 🫶 If an extra SignedData and/or EnvelopedData is wrapped around the response (see Section 3.2.1.2 or 3.2.2), the GLO verifies the outer signature and/or decrypts the outer layer first, and only then verifies the signature on the innermost SignedData ✨
- 4.a - if the signingTime attribute value is not within the locally accepted time window, the prospective member MAY return a response indicating cMCStatus.failed and otherInfo.failInfo.badTime and a signingTime attribute 🥺
- 4.b - else if signature processing continues and the signatures verify, the GL member checks that one of the names in the certificate used to sign the response matches the name of the GL 🔍
  - 4.b.1 - 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.2 - else if the name of the GL matches the name present in the certificate and:
    - 4.b.2.a - if the signatures verify, the prospective member has been added to the GL 🎀👑
    - 4.b.2.b - else if the prospective member received a cMCStatusInfoExt.cMCStatus.failed, for any reason, the prospective member MAY reattempt to add itself to the GL using the information provided in the response 🌈

4.3.2. Prospective Member Initiated Additions 🦋

Okay, this is the glow-up version, where the prospective member starts the whole thing. Here's how it goes for prospective member initiated glAddMember requests 💅

1 - the prospective GL member sends a SignedData.PKIData.controlSequence.glAddMember request to the GLA (A in Figure 5) 📨 They include the GL name in glName, their name in glMember.glMemberName, their address in glMember.glMemberAddress, and their encryption certificate in glMember.certificates.pKC. They can also include any attribute certificates tied to that encryption certificate in glMember.certificates.aC, plus the certification path for their encryption and attribute certificates in glMember.certificates.certPath. The prospective member MUST also include the signingTime attribute with this request ⏰
- 1.a - the prospective GL member can optionally add confidentiality to the request by wrapping the SignedData.PKIData in an EnvelopedData (see Section 3.2.1.2) 🔒
- 1.b - the prospective GL member MAY optionally apply another SignedData over the EnvelopedData (see Section 3.2.1.2) 💜
2 - when the request arrives, the GLA verifies it as per 2 in Section 4.3.1 🛡️
3 - when the forwarded request reaches the GLO, 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 is wrapped around the innermost layer (see Section 3.2.1.2 or 3.2.2), the GLO decrypts the outer layer first, and then verifies the signature on the innermost SignedData 🔓

Note: For cases where the GL is closed and either a) a prospective member sends directly to the GLO or b) the GLA has mistakenly forwarded the request to the GLO, the GLO should first determine whether to honor the request. 🚨

3.a - if the signingTime attribute value is not within the locally accepted time window, the GLO MAY return a response indicating cMCStatus.failed and otherInfo.failInfo.badTime 🙈
3.b - else if signature processing continues and 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.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.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.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.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.1 - if the member's certificate cannot be verified, the GLO returns a SignedData.PKIResponse.controlSequence back to the prospective member with cMCStatusInfoExt.cMCtatus.failed indicating that the member's encryption certificate did not verify in cMCStatus.statusString. Additionally, a signingTime attribute is included with the response. If the GLO does not return a cMCStatusInfoExt response, the GLO sends a SignedData.PKIData.controlSequence.glProvideCert message to the prospective member requesting a new encryption certificate (see Section 4.10) 🔑
    - 3.b.2.b.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.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.b - the GLO can also optionally apply another SignedData over the EnvelopedData (see Section 3.2.1.2) 🌸

4 - processing continues as in 2 of Section 4.3.1 🔁 💖

4.4. Delete Members from GL 🧹

Okay bestie, deleting members from a GL is giving main character drama 💅. The glDeleteMember request can come from two places: the GLO, or a member who wants to be removed. The GLA handles those two differently, and the member version has all the twists 🌀. The GLO can send the request whenever it wants. Once the GLA has checked that the request really came from a registered GLO, the GLA should delete the member.

If a member is the one asking, the GLA has to figure out how the GL is administered. When the GLO first set up the GL, it picked one of three vibes: unmanaged, managed, or closed (see Section 3.1.1) 🧚. In the unmanaged case, the GLA just processes the member's request. In the managed case, the GLA forwards the request to the GLO for review 👀. If there are multiple GLOs for a GL, which one gets the request is beyond the scope of this document. That GLO either rejects the request or sends a reformed request to the GLA. In the closed case, the GLA will not accept requests from members 🚫.

The next sections walk through what the GLO(s), the GLA, and the GL members each do, depending on whether the request started with a GLO or with a member who wants out. Figure 6 shows the three options. The error messages aren't drawn in there, so don't be confused 🙈. Also, the optional transactionId, senderNonce, and recipientNonce CMC control attributes aren't addressed in these procedures.

   +-----+  2,B{A}              3  +----------+
   | GLO | <--------+    +-------> | Member 1 |
   +-----+          |    |         +----------+
            1       |    |
   +-----+ <--------+    |      3  +----------+
   | GLA |  A            +-------> |   ...    |
   +-----+ <-------------+         +----------+
                         |
                         |      3  +----------+
                         +-------> | Member n |
                                   +----------+

Figure 6 - Member Deletion

If the member doesn't get removed from the GL, they keep receiving and being able to decrypt data protected with the shared KEK, and they keep getting rekeys 😬. For unmanaged lists there's no point in a group rekey, because there's no guarantee that the member asking to be removed hasn't already added themselves back under a different name 🎭. For managed and closed GLs, the GLO needs to take steps to make sure the member being deleted isn't on the GL twice. After that's sorted, managed and closed GLs can be rekeyed to keep the traffic sent by group members confidential 🔐. 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).

4.4.1. GLO Initiated Deletions

Here's the play-by-play for GLO initiated glDeleteMember requests 📝:

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.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.b - The GLO can also optionally apply another SignedData over the EnvelopedData (see Section 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.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.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.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.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.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.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.b - Else if the glMemberName is already on the GL, the GLA checks how the GL is administered.
      - 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.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.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.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.2 - The GLA can also optionally apply another SignedData over the EnvelopedData (see Section 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.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.b - Else if the signer is a registered GLO, the GLA returns a cMCStatusInfoExt.cMCStatus.success and a signingTime attribute(2 in Figure 6). The GLA also takes administrative actions, which are beyond the scope of this document, to delete the member with the GL stored on the GLA. Note that the GL will also be rekeyed as described in Section 5.
        
        2.c.2.b.2.b.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.2 - The GLA can also optionally apply another SignedData over the EnvelopedData (see Section 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 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.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.2 - The GLA can also optionally apply another SignedData over the EnvelopedData (see Section 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.a - Okay so if the signer is neither the GLO nor the prospective member, the GLA sends back a cMCStatusInfoExt with cMCStatus.failed and otherInfo.extendedFailInfo.SKDFailInfo set to noSpam 🙈. A signingTime attribute gets tucked in with the response too.
2.c.2.b.3.b - Else if the signer is either a registered GLO or the member, the GLA sends a cMCStatusInfoExt.cMCStatus.success and a signingTime attribute 🎀. It goes 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 it. The GLA also handles some administrative stuff, which is beyond the scope of this document, to delete the member from the GL stored on the GLA ✨.
- 2.c.2.b.3.b.1 - The GLA adds confidentiality to the response by wrapping 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.2 - The GLA can also optionally slap another SignedData over the EnvelopedData (see Section 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 wraps the response (see Section 3.2.1.2 or 3.2.2), the GLO verifies the outer signature and/or decrypts the outer layer before verifying the signature on the innermost SignedData.

3.a - If the signingTime attribute value is not within the locally accepted time window, the GLO MAY return a response indicating cMCStatus.failed and otherInfo.failInfo.badTime and a signingTime attribute ⏰.
3.b - Else if signature processing continues and the signatures do verify, the GLO checks that one of the names in the certificate used to sign the response matches the name of the GL 👀.
- 3.b.1 - 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.2 - Else if the name of the GL matches the name present in the certificate, and:
  - 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 the 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.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 🔁.

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 wraps the response (see Section 3.2.1.2 or 3.2.2), the GLO verifies the outer signature and/or decrypts the outer layer before verifying the signature on the innermost SignedData.

4.a - If the signingTime attribute value is not within the locally accepted time window, the prospective member MAY return a response indicating cMCStatus.failed and otherInfo.failInfo.badTime and a signingTime attribute ⌛.
4.b - Else if signature processing continues and the signatures verify, the GL member checks that one of the names in the certificate used to sign the response matches the name of the GL 🔍.
- 4.b.1 - 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.2 - Else if the name of the GL matches the name present in the certificate, and:
  - 4.b.2.a - If the signature(s) verify, the member has been deleted from the GL 🎉.
  - 4.b.2.b - Else if the member received a cMCStatusInfoExt.cMCStatus.failed with any reason, the member can reattempt to delete itself from the GL using the information provided in the response 💪.

4.4.2. Member Initiated Deletions 🦋

The process for member initiated deletion of its own membership using the glDeleteMember requests goes like this:

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.a - The member can optionally add confidentiality to the request by wrapping the SignedData.PKIData in an EnvelopedData (see Section 3.2.1.2) 🤫.
1.b - The member can also optionally apply another SignedData over the EnvelopedData (see Section 3.2.1.2) 🌸.

2 - Upon receipt of the request, the GLA verifies the request as per 2 in Section 4.4.1 ✅.

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 before verifying the signature on the innermost SignedData.

Note: For cases where the GL is closed and either (a) a prospective member sends directly to the GLO or (b) the GLA has mistakenly forwarded the request to the GLO, the GLO should first determine whether to honor the request 🚨.

3.a - If the signingTime attribute value is not within the locally accepted time window, the GLO MAY return a response indicating cMCStatus.failed and otherInfo.failInfo.badTime and a signingTime attribute ⏰.
3.b - Else if signature processing continues and the signatures cannot be verified, the GLO returns a cMCStatusInfoExt response indicating cMCStatus.failed and otherInfo.failInfo.badMessageCheck and a signingTime attribute 💔.
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.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 🙅‍♀️. A signingTime attribute is also included with the response.
- 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 includes it with the GLDeleteMember request (see Section 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.b - The GLO can also optionally apply another SignedData over the EnvelopedData (see Section 3.2.1.2) 🌈.

4 - Further processing is as in 2 of Section 4.4.1 💫.

4.5. Request Rekey of GL 🗝️

From time to time, the GL will need to be rekeyed, so here are some situations where that happens 🌟:

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.
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 🙃.
When the current shared KEK has been compromised 🚨.
When the current shared KEK is about to expire. Consider two cases:
- 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.
- If the GLA controls the GL rekey, the GLA should initiate a glKey message as specified in Section 5.

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 ⏳.

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 🧩.

   +-----+  1   2,A  +-----+
   | GLA | <-------> | GLO |
   +-----+           +-----+

   Figure 7 - GL Rekey Request

4.5.1. GLO Initiated Rekey Requests 💖

okay so, here's how the GLO kicks off a rekey 🔑✨

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 left out, nothing changes from the GL values already registered for those fields. If the GLO wants to force a rekey for all outstanding shared KEKs, it includes glRekeyAllGLKeys set to TRUE 🔥 The GLO MUST also include a signingTime attribute with this request ⏰

1.a - The GLO can optionally apply confidentiality to the request by wrapping the SignedData.PKIData in an EnvelopedData (see Section 3.2.1.2) 🎀
1.b - The GLO can also optionally apply another SignedData over the EnvelopedData (see Section 3.2.1.2) 🌸

2 - When the GLA gets the request, it checks the signingTime and verifies the signature on the innermost SignedData.PKIData 👀 If there's an extra SignedData and/or EnvelopedData wrapping the request (see Section 3.2.1.2 or 3.2.2), the GLA verifies the outer signature and/or decrypts the outer layer before it verifies the innermost signature. Layers, bestie 🧅

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.b - Else if signature processing continues and the signatures do not verify, the GLA returns a cMCStatusInfoExt response indicating cMCStatus.failed and otherInfo.failInfo.badMessageCheck. A signingTime attribute is included with the response too 🙅‍♀️
2.c - Else if the signatures do verify, the GLA makes sure it actually supports the GL by checking that the glName matches a glName stored on the GLA 🔍
- 2.c.1 - If the glName present does not match a GL stored on the GLA, the GLA returns a response indicating cMCStatusInfoExt with cMCStatus.failed and an otherInfo.extendedFailInfo.SKDFailInfo value of invalidGLName. A signingTime attribute is included with the response 💀
- 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.a - If the names do not match, the GLA returns a response indicating cMCStatusInfoExt with cMCStatus.failed and an otherInfo.extendedFailInfo.SKDFailInfo value of noGLONameMatch. A signingTime attribute is included with the response 🚫
  - 2.c.2.b - Else if the names match, the GLA checks the glNewKeyAttribute values 🧐
    - 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 an otherInfo.extendedFailInfo.SKDFailInfo value of unsupportedAlgorithm. A signingTime attribute is included with the response 🥲
    - 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 an otherInfo.extendedFailInfo.SKDFailInfo value of unsupportedDuration. A signingTime attribute is included with the response ⌛
    - 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 an otherInfo.extendedFailInfo.SKDFailInfo value of unspecified. A signingTime attribute is included with the response 🤐
    - 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.a - The GLA applies confidentiality to the response by wrapping the SignedData.PKIData in an EnvelopedData if the request was wrapped in an EnvelopedData (see Section 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) 🌈

3 - When the GLO gets the cMCStatusInfoExt response, it checks the signingTime and verifies the GLA signature(s) 🧾 If there's an extra SignedData and/or EnvelopedData wrapping 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 before verifying the signature on the innermost SignedData 🔐

3.a - If the signingTime attribute value is not within the locally accepted time window, the GLA MAY return a response indicating cMCStatus.failed and otherInfo.failInfo.badTime and a signingTime attribute ⏳
3.b - Else if signature processing continues and the signatures verify, the GLO checks that one of the names in the certificate used to sign the response matches the name of the GL 👯‍♀️
- 3.b.1 - 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.2 - Else if the name of the GL matches the name present in the certificate, and:
  - 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.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 🔁

4.5.2. GLA Initiated Rekey Requests 🌷

if the GLA is the one in charge of rekeying the GL, the GLA will automatically issue a glKey message (see Section 5) 🤖 On top of that, the GLA will generate a cMCStatusInfoExt to tell the GL that a successful rekey happened. The process for GLA initiated rekey goes like this:

1 - The GLA generates, for all GLOs, a SignedData.PKIData.controlSequence.cMCStatusInfoExt.cMCStatus success and includes a signingTime attribute (A in Figure 7) ✍️

1.a - The GLA can optionally apply confidentiality to the request by wrapping the SignedData.PKIData in an EnvelopedData (see Section 3.2.1.2) 🎀
1.b - The GLA can also optionally apply another SignedData over the EnvelopedData (see Section 3.2.1.2) 🌸

2 - When the GLO gets the cMCStatusInfoExt.cMCStatus.success response, it checks the signingTime and verifies the GLA signature(s). If there's an extra SignedData and/or EnvelopedData wrapping 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 before verifying the signature on the innermost SignedData 🫶

2.a - If the signingTime attribute value is not within the locally accepted time window, the GLO MAY return a response indicating cMCStatus.failed and otherInfo.failInfo.badTime and a signingTime attribute ⏳
2.b - Else if signature processing continues and the signatures verify, the GLO checks that one of the names in the certificate used to sign the response matches the name of the GL 👀
- 2.b.1 - 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.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 💅✨

4.6. Change GLO 👑

Okay bestie, managing a managed or closed GL can get seriously overwhelming for one GLO once the membership gets big 😭. So GLAs support having GLs be managed by multiple GLOs 🫶. The glAddOwner and glRemoveOwner messages are how you add and remove registered GLOs. Figure 8 shows the protocol interactions for sending glAddOwner and glRemoveOwner messages and the responses that come back. Error messages aren't shown, and behavior for the optional transactionId, senderNonce, and recipientNonce CMC control attributes isn't covered in these procedures, so don't go looking for it here 🙈

        +-----+   1    2  +-----+
        | GLA | <-------> | GLO |
        +-----+           +-----+

Figure 8 - GLO Add and Delete Owners

The process for glAddOwner and glDeleteOwner goes like this 💅

1 - The GLO sends a SignedData.PKIData.controlSequence.glAddOwner or glRemoveOwner request to the GLA (1 in Figure 8). The GLO puts 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.a - The GLO can optionally apply confidentiality to the request by wrapping the SignedData.PKIData in an EnvelopedData (see Section 3.2.1.2) 🔐
- 1.b - The GLO can also optionally apply another SignedData over the EnvelopedData (see Section 3.2.1.2) ✨
2 - When the GLA gets the glAddOwner or glRemoveOwner request, it checks the signingTime and verifies the GLO signature(s). If an additional SignedData and/or EnvelopedData wraps the request (see Section 3.2.1.2 or 3.2.2), the GLA verifies the outer signature and/or decrypts the outer layer before verifying the signature on the innermost SignedData 🧐
- 2.a - If the signingTime attribute value isn't 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 - Else if signature processing continues and the signatures can't be verified, the GLA returns a cMCStatusInfoExt response indicating cMCStatus.failed and otherInfo.failInfo.badMessageCheck. A signingTime attribute is included with the response too 🚫
- 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.1 - If the glName isn't supported by the GLA, the GLA returns a response indicating cMCStatusInfoExt with cMCStatus.failed and otherInfo.extendedFailInfo.SKDFailInfo value of invalidGLName. A signingTime attribute is included with the response 🙅‍♀️
  - 2.c.2 - Else if the glName is supported by the GLA, the GLA makes sure a registered GLO signed the glAddOwner or glRemoveOwner request. It does this by checking that one of the names in the digital signature certificate used to sign the glAddOwner or glDeleteOwner request matches the name of a registered GLO 👑
    - 2.c.2.a - If the names don't match, the GLA returns a response indicating cMCStatusInfoExt with cMCStatus.failed and otherInfo.extendedFailInfo.SKDFailInfo value of noGLONameMatch. A signingTime attribute is included with the response 💀
    - 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 does the admin work to associate the new glOwnerName with the GL in the case of glAddOwner, or to disassociate the old glOwnerName from the GL in the case of glRemoveOwner 🎉
      - 2.c.2.b.1 - The GLA applies confidentiality to the response by wrapping the SignedData.PKIResponse in an EnvelopedData if the request was wrapped in an EnvelopedData (see Section 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) 💜
3 - When the GLO gets the cMCStatusInfoExt response, it checks the signingTime and verifies the GLA's signature(s). If an additional SignedData and/or EnvelopedData wraps the response (see Section 3.2.1.2 or 3.2.2), the GLO verifies the outer signature and/or decrypts the outer layer before verifying the signature on the innermost SignedData 🔁
- 3.a - If the signingTime attribute value isn't within the locally accepted time window, the GLO MAY return a response indicating cMCStatus.failed and otherInfo.failInfo.badTime and a signingTime attribute ⌛
- 3.b - Else if signature processing continues and the signatures verify, the GLO checks that one of the names in the certificate used to sign the response matches the name of the GL 🕵️‍♀️
  - 3.b.1 - If the name of the GL doesn't match the name in the certificate used to sign the message, the GLO should not believe the response 🚩
  - 3.b.2 - Else if the name of the GL does match the name in the certificate, and:
    - 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.b - Else if the signatures verify and the response was cMCStatusInfoExt.cMCStatus.failed with any reason, the GLO can try again to add or delete the GLO using the information in the response 🔄

4.7. Indicate KEK Compromise 🚨

Sometimes the shared KEK gets compromised, and that's a whole emergency 😱. GL members and GLOs use glkCompromise to tell the GLA that the shared KEK has been compromised. Figure 9 shows the protocol interactions for GL Key Compromise. Error messages aren't shown, and the optional transactionId, senderNonce, and recipientNonce CMC control attributes aren't addressed in these procedures.

   +-----+  2{1}                  4  +----------+
   | GLO | <----------+    +-------> | Member 1 |
   +-----+  5,3{1}    |    |         +----------+
   +-----+ <----------+    |      4  +----------+
   | GLA |  1              +-------> |   ...    |
   +-----+ <---------------+         +----------+
                           |      4  +----------+
                           +-------> | Member n |
                                     +----------+

Figure 9 - GL Key Compromise

4.7.1. GL Member Initiated KEK Compromise Message

The process for GL member initiated glkCompromise messages goes like this 🧁

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.a - The GL member can optionally apply confidentiality to the request by wrapping 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.b - The GL member can also optionally apply another SignedData over the EnvelopedData (see Section 3.2.1.2) ✨
2 - When the GLA gets the glkCompromise request, it checks the signingTime and verifies the GL member signature(s). If an additional SignedData and/or EnvelopedData wraps the request (see Section 3.2.1.2 or 3.2.2), the GLA verifies the outer signature and/or decrypts the outer layer before verifying the signature on the innermost SignedData 🧐
- 2.a - If the signingTime attribute value isn't 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 - Else if signature processing continues and the signatures can't be verified, the GLA returns a cMCStatusInfoExt response indicating cMCStatus.failed and otherInfo.failInfo.badMessageCheck. A signingTime attribute is included with the response 🚫
- 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.1 - If the glName isn't supported by the GLA, the GLA returns a response indicating cMCStatusInfoExt with cMCStatus.failed and otherInfo.extendedFailInfo.SKDFailInfo value of invalidGLName. A signingTime attribute is included with the response 🙅‍♀️
  - 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.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.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, which GLO the request gets forwarded to is beyond the scope of this document. Further processing by the GLO is discussed in Section 4.7.2 📨

4.7.2. GLO Initiated KEK Compromise Message ✨

okay bestie, so here's how the GLO kicks off a glkCompromise message 💅

1 - The GLO either:
- 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.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.2 - The GLO can also optionally apply another SignedData over the EnvelopedData (see Section 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.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.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.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.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.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. 🦋

4.8. Request KEK Refresh 🧚

okay so sometimes GL members irrecoverably lose their shared KEK 😭 but here's the good news: the shared KEK is not compromised, so the whole GL doesn't need a full rekey. ✨ Instead, GL members use the glkRefresh message to ask for the shared KEK(s) to be redistributed to them. Figure 10 shows the protocol interactions for GL Key Refresh. Heads up that error messages are not shown in the figure. Also, behavior for the optional transactionId, senderNonce, and recipientNonce CMC control attributes is not addressed in these procedures. 🌈

   +-----+   1       2   +----------+
   | GLA | <-----------> |  Member  |
   +-----+               +----------+

      Figure 10 - GL KEK Refresh

The process for glkRefresh is as follows:

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.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.b - The GL member can also optionally apply another SignedData over the EnvelopedData (see Section 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.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.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.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.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.2 - Else if the glName is supported by the GLA, the GLA ensures that the GL member is on the 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.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. 🎉

4.9. GLA Query Request and Response ✨

okay so bestie, sometimes a GLO is stuck trying to set up a GL 😩 because it doesn't know which algorithm(s) the GLA supports, or some other detail about it. And sometimes prospective GL members or GL members just need to know something about the GLA too 🧚. (Those extra requests aren't defined in this doc, fyi.) That's where glaQueryRequest and glaQueryResponse come in 💖. They exist so you can go get that info. Figure 11 shows how the two messages flow between everyone. Error messages aren't drawn, and the optional transactionId, senderNonce, and recipientNonce CMC control attributes aren't covered by these steps either 🫶.

      +-----+   1    2  +------------------+
      | GLA | <-------> | GLO or GL Member |
      +-----+           +------------------+

Figure 11 - GLA Query Request and Response

Here's the whole vibe, step by step 💅:

1 - The GLO, GL member, or prospective GL member sends a SignedData.PKIData.controlSequence.glaQueryRequest to the GLA (that's the 1 in Figure 11) 🦋. They tell the GLA what info they're curious about. A signingTime attribute rides along with it too ⏰.

1.a - Want privacy? The GLO, GL member, or prospective GL member can optionally wrap the SignedData.PKIData in an EnvelopedData for confidentiality (see Section 3.2.1.2) 🔒.

1.b - They can also optionally throw another SignedData over that EnvelopedData (see Section 3.2.1.2) 🌸.

2 - Once the GLA gets the glaQueryRequest, it decides whether it even accepts glaQueryRequest messages at all 🤔.

2.a - If the GLA says "nah, not accepting these," it sends back a cMCStatusInfoExt with cMCStatus.noSupport, plus whatever else it wants to put in statusString 🙅‍♀️.

2.b - Else if the GLA does accept GLAQueryRequests, it checks the signingTime and verifies the signature(s) from the GLO, GL member, or prospective GL member 🔍. If there's an extra SignedData and/or EnvelopedData wrapping the request (see Section 3.2.1.2 or 3.2.2), the GLA verifies the outer signature and/or decrypts the outer layer before it checks the signature on the innermost SignedData 🪆.

2.b.1 - If the signingTime value isn't in the locally accepted time window, the GLA MAY send back a response with cMCStatus.failed and otherInfo.failInfo.badTime, along with a signingTime attribute ⏳.

2.b.2 - Else if the signature processing carries on but the signatures can't be verified, the GLA returns a cMCStatusInfoExt with cMCStatus.failed and otherInfo.failInfo.badMessageCheck. A signingTime attribute is included with it too 💀.

2.b.3 - Else if the signatures verify, the GLA returns a glaQueryResponse (that's the 2 in Figure 11) with the right answer, as long as the glaRequestType is supported 🎉. If the glaRequestType isn't supported, it returns a cMCStatusInfoExt with cMCStatus.noSupport instead. Either way, a signingTime attribute is included with the response ⏰.

2.b.3.a - If the request came wrapped in an EnvelopedData, the GLA wraps the SignedData.PKIResponse in an EnvelopedData too, for confidentiality (see Section 3.2.1.2) 🔐.

2.b.3.b - The GLA can also optionally put another SignedData over that EnvelopedData (see Section 3.2.1.2) 💜.

3 - When the glaQueryResponse lands, the GLO, GL member, or prospective GL member checks the signingTime and verifies the GLA signature(s) 👀. If an extra SignedData and/or EnvelopedData wraps the response (see Section 3.2.1.2 or 3.2.2), they verify the outer signature and/or decrypt the outer layer first, and only then verify the signature on the innermost SignedData 🪞.

3.a - If the signingTime value isn't in the locally accepted time window, the GLO, GL member, or prospective GL member MAY send back a response with cMCStatus.failed and otherInfo.failInfo.badTime, plus a signingTime attribute ⌛.

3.b - Else if signature processing carries on and the signatures don't verify, the GLO, GL member, or prospective GL member returns a cMCStatusInfoExt with cMCStatus.failed and otherInfo.failInfo.badMessageCheck. A signingTime attribute is included with that response too 😭.

3.c - Else if the signatures verify, 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.1 - If the name of the GL doesn't match the name in the certificate that signed the message, the GLO ought not believe the response 🚩.

3.c.2 - Else if the GL name matches the name in the certificate and the response was a glaQueryResponse, then the GLO, GL member, or prospective GL member may use the info inside it ✅.

4.10. Update Member Certificate 🎀

okay this one's about certificates going stale, and it's giving drama 😤. When the GLO generates a glAddMember request, when the GLA generates a glKey message, or when the GLA processes a glAddMember, a GL member's certificate might have expired or be invalid 💀. In those cases, the GLO or GLA can ask that GL member to send a new certificate, so the GLA doesn't get stuck and unable to generate a glKey message for that member 🫠.

There are also times when a GL member knows its certificate is about to expire or has been revoked, and then it won't be able to receive GL rekeys 🙈. Behavior for the optional transactionId, senderNonce, and recipientNonce CMC control attributes isn't addressed in these procedures either 🍓.

4.10.1. GLO and GLA Initiated Update Member Certificate 💅

Okay so, the GLO-initiated glUpdateCert goes like this 🫶

1 - The GLO or GLA sends a SignedData.PKIData.controlSequence.glProvideCert request to the GL member. The GLO or GLA puts the GL name in glName and the GL member name in glMemberName. A signingTime attribute also rides along with this request ⏰

1.a - The GLO or GLA can optionally apply confidentiality to the request by wrapping 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.b - The GLO or GLA can also optionally apply another SignedData over the EnvelopedData (see Section 3.2.1.2). 🎀

2 - When the GL member gets the glProvideCert message, they check the signingTime and verify the GLO or GLA signature(s). If an additional SignedData and/or EnvelopedData wraps 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 before verifying the signature on the innermost SignedData. 🔍

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.b - Else if signature processing continues and the signatures cannot be verified, the GL member returns a cMCStatusInfoExt response indicating cMCStatus.failed and otherInfo.failInfo.badMessageCheck. A signingTime attribute is also included with the response. 🥲

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, and the member's encryption certificate in glMember.certificates.pKC. The GL member can also include any attribute certificates tied to the member's encryption certificate in glMember.certificates.aC, and the certification path for the member's encryption and attribute certificates in glMember.certificates.certPath. A signingTime attribute is included with the response too. 📜

2.c.1 - The GL member can optionally apply confidentiality to the request by wrapping 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.2 - The GL member can also optionally apply another SignedData over the EnvelopedData (see Section 3.2.1.2).

3 - When the GLO or GLA gets the glUpdateCert message, they check the signingTime and verify the GL member signature(s). If an additional SignedData and/or EnvelopedData wraps 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 before verifying the signature on the innermost SignedData. 🧐

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.b - Else if signature processing continues and the signatures cannot be verified, the GLO or GLA returns a cMCStatusInfoExt response indicating cMCStatus.failed and otherInfo.failInfo.badMessageCheck. A signingTime attribute is also included with the response. 💔

3.c - Else if the signatures verify, the GLO or GLA verifies the member's encryption certificate.

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. A signingTime attribute is included with either response.

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. A signingTime attribute is included with the response.

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. ✅

4.10.2. GL Member Initiated Update Member Certificate 🦋

The process for an unsolicited GL member glUpdateCert is as follows:

1 - The GL member sends a Signed.PKIData.controlSequence.glUpdateCert that includes the GL name in glName, the member's name in glMember.glMemberName, and the member's encryption certificate in glMember.certificates.pKC. The GL member can also include any attribute certificates associated with the member's encryption certificate in glMember.certificates.aC, and the certification path associated with the member's encryption and attribute certificates in glMember.certificates.certPath. The GL member MUST also include a signingTime attribute with this request. 📝

1.a - The GL member can optionally apply confidentiality to the request by wrapping 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.b - The GL member can also optionally apply another SignedData over the EnvelopedData (see Section 3.2.1.2).

2 - When the glUpdateCert message arrives, the GLA checks the signingTime and verifies the GL member signature(s). If an additional SignedData and/or EnvelopedData wraps the response (see Section 3.2.1.2 or 3.2.2), the GLA verifies the outer signature and/or decrypts the outer layer before verifying the signature on the innermost 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.b - Else if signature processing continues and the signatures cannot be verified, the GLA returns a cMCStatusInfoExt response indicating cMCStatus.failed and otherInfo.failInfo.badMessageCheck. 🙃

2.c - Else if the signatures verify, the GLA verifies the member's encryption certificate.

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. A signingTime attribute is included with the response.

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. 🚀

5. Distribution Message 📬

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. 🌈

                     1   +----------+
               +-------> | Member 1 |
               |         +----------+
   +-----+     |     1   +----------+
   | GLA | ----+-------> |   ...    |
   +-----+     |         +----------+
               |     1   +----------+
               +-------> | Member n |
                         +----------+

Figure 12 - GL Key Distribution

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. 🤫

When the glKey message is generated as a result of a:

glAddMember request,
glkComrpomise indication,
glkRefresh request,
glDeleteMember request with the GL's glAdministration set to managed or closed, and
glRekey request with generationCounter set to zero (0).

The GLA MUST use either the kari (see Section 12.3.2 of [CMS]) or ktri (see Section 12.3.1 of [CMS]) choice in glKey.glkWrapped.RecipientInfo to ensure that only the intended recipients receive the shared KEK. The GLA MUST support the ktri choice. 🔐

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. 💖

5.1. Distribution Process 🚚✨

okay so here's how distribution goes down whenever a glKey message gets generated 💅

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.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.b - The GLA MAY also optionally apply another SignedData over the EnvelopedData.SignedData.PKIData (see Section 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.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.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.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. 🎉

6. Algorithms 🧮

this section lists the algorithms that MUST be implemented. Additional algorithms that SHOULD be implemented are also included. Further algorithms MAY also be implemented. 💜

6.1. KEK Generation Algorithm 🎲

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. Using inadequate pseudo-random number generators (PRNGs) to make cryptographic keys can result in little or no security, and that's lowkey terrifying 😭 An attacker may find it much easier to recreate the PRNG environment that produced the keys and search the resulting small set of possibilities, rather than brute forcing the whole key space. Generating quality random numbers is genuinely hard. RFC 4086 [RANDOM] offers important guidance in this area, and Appendix 3 of FIPS Pub 186 [FIPS] provides one quality PRNG technique. 🔐

6.2. Shared KEK Wrap Algorithm 🎀

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). 🫧

The algorithm object identifiers included in glkWrapped are as specified in [CMSALG] and [CMSAES].

6.3. Shared KEK Algorithm 🗝️

The shared KEK distributed and indicated in glkAlgorithm MUST support the symmetric key-encryption algorithms as specified in [CMSALG] and [CMSAES]. ✨

7. Message Transport 📬

SMTP [SMTP] MUST be supported. Other transport mechanisms MAY also be supported. 💌

8. Security Considerations 🚨

okay this section is SERIOUS bestie, read it all 🙈

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. 👑

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. 💀

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. 🔑

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. ⏳

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. 🚩

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. 🥺

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. 💎

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. ⏰

9. Acknowledgements 🫶

Thanks to Russ Housley and Jim Schaad for providing much of the background and review required to write this document. 🌸

10. References 📚

10.1. Normative References

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[CMS] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3852, July 2004.
[CMC] Schaad, J. and M. Myers, "Certificate Management over CMS (CMC)", RFC 5272, June 2008.
[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.
[ACPROF] Farrell, S. and R. Housley, "An Internet Attribute Certificate Profile for Authorization", RFC 3281, April 2002.
[MSG] Ramsdell, B., Ed., "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification", RFC 3851, July 2004.
[ESS] Hoffman, P., Ed., "Enhanced Security Services for S/MIME", RFC 2634, June 1999.
[CMSALG] Housley, R., "Cryptographic Message Syntax (CMS) Algorithms", RFC 3370, August 2002.
[CMSAES] Schaad, J., "Use of the Advanced Encryption Standard (AES) Encryption Algorithm in Cryptographic Message Syntax (CMS)", RFC 3565, July 2003.
[SMTP] Klensin, J., Ed., "Simple Mail Transfer Protocol", RFC 2821, April 2001.

10.2. Informative References

[X400TRANS] Hoffman, P. and C. Bonatti, "Transporting Secure/Multipurpose Internet Mail Extensions (S/MIME) Objects in X.400", RFC 3855, July 2004.
[RANDOM] Eastlake, D., 3rd, Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
[FIPS] National Institute of Standards and Technology, FIPS Pub 186-2: Digital Signature Standard, January 2000.

Appendix A. ASN.1 Module ✨

okay bestie, this is the full ASN.1 module, so the formatting matters a lot 💅 it's the official definitions for all the GL control attributes and error codes, and every single line is copied exactly as written 🧚

SMIMESymmetricKeyDistribution
  { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
    pkcs-9(9) smime(16) modules(0) symkeydist(12) }

DEFINITIONS IMPLICIT TAGS ::=
BEGIN

-- EXPORTS All --
-- The types and values defined in this module are exported for use
-- in the other ASN.1 modules.  Other applications may use them for
-- their own purposes.

IMPORTS

-- PKIX Part 1 - Implicit [PROFILE]
   GeneralName
     FROM PKIX1Implicit88 { iso(1) identified-organization(3) dod(6)
          internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
          id-pkix1-implicit(19) }

-- PKIX Part 1 - Explicit [PROFILE]
   AlgorithmIdentifier, Certificate
     FROM PKIX1Explicit88 { iso(1) identified-organization(3) dod(6)
          internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
          id-pkix1-explicit(18) }

-- Cryptographic Message Syntax [CMS]
   RecipientInfos, KEKIdentifier, CertificateSet
     FROM CryptographicMessageSyntax2004 {iso(1) member-body(2)
       us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) modules(0)
       cms-2004(24) }

-- Advanced Encryption Standard (AES) with CMS [CMSAES]
   id-aes128-wrap
     FROM CMSAesRsaesOaep { iso(1) member-body(2) us(840)
       rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) modules(0)
       id-mod-cms-aes(19) }

-- Attribute Certificate Profile [ACPROF]
   AttributeCertificate FROM
      PKIXAttributeCertificate { iso(1) identified-organization(3)
      dod(6) internet(1) security(5) mechanisms(5) pkix(7)
      id-mod(0) id-mod-attribute-cert(12) };

-- This defines the GL symmetric key distribution object identifier
-- arc.

id-skd OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
  rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) skd(8) }

-- This defines the GL Use KEK control attribute.

id-skd-glUseKEK OBJECT IDENTIFIER ::= { id-skd 1 }

GLUseKEK ::= SEQUENCE {
  glInfo                GLInfo,
  glOwnerInfo           SEQUENCE SIZE (1..MAX) OF GLOwnerInfo,
  glAdministration      GLAdministration DEFAULT 1,
  glKeyAttributes       GLKeyAttributes OPTIONAL }

GLInfo ::= SEQUENCE {
  glName     GeneralName,
  glAddress  GeneralName }

GLOwnerInfo ::= SEQUENCE {
  glOwnerName     GeneralName,
  glOwnerAddress  GeneralName,
  certificates    Certificates OPTIONAL }

GLAdministration ::= INTEGER {
  unmanaged  (0),
  managed    (1),
  closed     (2) }

GLKeyAttributes ::= SEQUENCE {
  rekeyControlledByGLO       [0] BOOLEAN DEFAULT FALSE,
  recipientsNotMutuallyAware [1] BOOLEAN DEFAULT TRUE,
  duration                   [2] INTEGER DEFAULT 0,
  generationCounter          [3] INTEGER DEFAULT 2,
  requestedAlgorithm         [4] AlgorithmIdentifier
                              DEFAULT { id-aes128-wrap } }

-- This defines the Delete GL control attribute.
-- It has the simple type GeneralName.

id-skd-glDelete OBJECT IDENTIFIER ::= { id-skd 2 }

DeleteGL ::= GeneralName

-- This defines the Add GL Member control attribute.

id-skd-glAddMember OBJECT IDENTIFIER ::= { id-skd 3 }
GLAddMember ::= SEQUENCE {
  glName    GeneralName,
  glMember  GLMember }

GLMember ::= SEQUENCE {
  glMemberName     GeneralName,
  glMemberAddress  GeneralName OPTIONAL,
  certificates     Certificates OPTIONAL }

Certificates ::= SEQUENCE {
   pKC                [0] Certificate OPTIONAL,
                               -- See [PROFILE]
   aC                 [1] SEQUENCE SIZE (1.. MAX) OF
                          AttributeCertificate OPTIONAL,
                               -- See [ACPROF]
   certPath           [2] CertificateSet OPTIONAL }
                               -- From [CMS]

-- This defines the Delete GL Member control attribute.

id-skd-glDeleteMember OBJECT IDENTIFIER ::= { id-skd 4 }

GLDeleteMember ::= SEQUENCE {
  glName            GeneralName,
  glMemberToDelete  GeneralName }

-- This defines the Delete GL Member control attribute.

id-skd-glRekey OBJECT IDENTIFIER ::= { id-skd 5 }

GLRekey ::= SEQUENCE {
  glName              GeneralName,
  glAdministration    GLAdministration OPTIONAL,
  glNewKeyAttributes  GLNewKeyAttributes OPTIONAL,
  glRekeyAllGLKeys    BOOLEAN OPTIONAL }

GLNewKeyAttributes ::= SEQUENCE {
  rekeyControlledByGLO       [0] BOOLEAN OPTIONAL,
  recipientsNotMutuallyAware [1] BOOLEAN OPTIONAL,
  duration                   [2] INTEGER OPTIONAL,
  generationCounter          [3] INTEGER OPTIONAL,
  requestedAlgorithm         [4] AlgorithmIdentifier OPTIONAL }

-- This defines the Add and Delete GL Owner control attributes.

id-skd-glAddOwner OBJECT IDENTIFIER ::= { id-skd 6 }
id-skd-glRemoveOwner OBJECT IDENTIFIER ::= { id-skd 7 }
GLOwnerAdministration ::= SEQUENCE {
  glName       GeneralName,
  glOwnerInfo  GLOwnerInfo }

-- This defines the GL Key Compromise control attribute.
-- It has the simple type GeneralName.

id-skd-glKeyCompromise OBJECT IDENTIFIER ::= { id-skd 8 }

GLKCompromise ::= GeneralName

-- This defines the GL Key Refresh control attribute.

id-skd-glkRefresh OBJECT IDENTIFIER ::= { id-skd 9 }

GLKRefresh ::= SEQUENCE {
   glName  GeneralName,
   dates   SEQUENCE SIZE (1..MAX) OF Date }

Date ::= SEQUENCE {
  start GeneralizedTime,
  end   GeneralizedTime OPTIONAL }

-- This defines the GLA Query Request control attribute.

id-skd-glaQueryRequest OBJECT IDENTIFIER ::= { id-skd 11 }

GLAQueryRequest ::= SEQUENCE {
  glaRequestType   OBJECT IDENTIFIER,
  glaRequestValue  ANY DEFINED BY glaRequestType }

-- This defines the GLA Query Response control attribute.

id-skd-glaQueryResponse OBJECT IDENTIFIER ::= { id-skd 12 }

GLAQueryResponse ::= SEQUENCE {
  glaResponseType   OBJECT IDENTIFIER,
  glaResponseValue  ANY DEFINED BY glaResponseType }

-- This defines the GLA Request/Response (glaRR) arc for
-- glaRequestType/glaResponseType.

id-cmc-glaRR OBJECT IDENTIFIER ::= { iso(1)
  identified-organization(3) dod(6) internet(1) security(5)
  mechanisms(5) pkix(7) cmc(7) glaRR(99) }

-- This defines the Algorithm Request.

id-cmc-gla-skdAlgRequest OBJECT IDENTIFIER ::= { id-cmc-glaRR 1 }

SKDAlgRequest ::= NULL

-- This defines the Algorithm Response.

id-cmc-gla-skdAlgResponse OBJECT IDENTIFIER ::= { id-cmc-glaRR 2 }

-- Note that the response for algorithmSupported request is the
-- smimeCapabilities attribute as defined in MsgSpec [MSG].
-- This defines the control attribute to request an updated
-- certificate to the GLA.

id-skd-glProvideCert OBJECT IDENTIFIER ::= { id-skd 13 }

GLManageCert ::= SEQUENCE {
  glName    GeneralName,
  glMember  GLMember }

-- This defines the control attribute to return an updated
-- certificate to the GLA.  It has the type GLManageCert.

id-skd-glManageCert OBJECT IDENTIFIER ::= { id-skd 14 }

-- This defines the control attribute to distribute the GL shared
-- KEK.

id-skd-glKey OBJECT IDENTIFIER ::= { id-skd 15 }

GLKey ::= SEQUENCE {
  glName        GeneralName,
  glIdentifier  KEKIdentifier,  -- See [CMS]
  glkWrapped    RecipientInfos,      -- See [CMS]
  glkAlgorithm  AlgorithmIdentifier,
  glkNotBefore  GeneralizedTime,
  glkNotAfter   GeneralizedTime }

-- This defines the CMC error types.

id-cet-skdFailInfo  OBJECT IDENTIFIER ::= { iso(1)
  identified-organization(3) dod(6) internet(1) security(5)
  mechanisms(5) pkix(7) cet(15) skdFailInfo(1) }

SKDFailInfo ::= INTEGER {
  unspecified           (0),
  closedGL              (1),
  unsupportedDuration   (2),
  noGLACertificate      (3),
  invalidCert           (4),
  unsupportedAlgorithm  (5),
  noGLONameMatch        (6),
  invalidGLName         (7),
  nameAlreadyInUse      (8),
  noSpam                (9),
-- obsolete             (10),
  alreadyAMember        (11),
  notAMember            (12),
  alreadyAnOwner        (13),
  notAnOwner            (14) }

END -- SMIMESymmetricKeyDistribution

Author's Address 🎀

the author is Sean Turner 💖

Sean Turner
IECA, Inc.
3057 Nutley Street, Suite 106
Fairfax, VA 22031
USA

EMail: turners@ieca.com

Full Copyright Statement 🌸

this doc is covered by the rights, licenses and restrictions in BCP 78, and unless that says otherwise, the authors keep all their rights 📜

the document and its info are provided on an "AS IS" basis, and the contributor, the organization they represent or are sponsored by (if any), the Internet Society, the IETF Trust, and the Internet Engineering Task Force all disclaim every warranty, whether express or implied 💀. that includes no promise that using the info won't infringe any rights, and no implied warranties of merchantability or fitness for a particular purpose 🙈

Intellectual Property 🦋

the IETF doesn't take a position on whether any IPR or other rights that someone might claim over the tech in this doc are valid or in scope, or on whether any license for them is available, and it hasn't independently gone looking for any such rights 🔍 info about how rights work for RFC docs is in BCP 78 and BCP 79.

copies of IPR disclosures sent to the IETF Secretariat, any assurances of licenses that might be made available, and the results of any attempt to get a general license or permission for implementers or users are all available from the IETF's online IPR repository at http://www.ietf.org/ipr 🫶

and the IETF invites anyone to flag any copyrights, patents, patent applications, or other proprietary rights that might cover tech needed to implement this standard. just send that info to the IETF at ietf-ipr@ietf.org 💜

📦 where this page comes from

ietf: rfc5275 2008-06
💖 girlified by claude-haiku-5-5 on 2026-10-17: a language model's rewrite of the original, under its terms