SMIME Working Group                                           S. Turner
Internet Draft                                                     IECA
Document: draft-ietf-smime-symkeydist-01.txt                  July draft-ietf-smime-symkeydist-02.txt           October 31, 2000
Expires:  January 14,  April 2001

                   S/MIME Symmetric Key Distribution

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026 [1].

   This document is an Internet-Draft. Internet-Drafts are working
   documents of the Internet Engineering Task Force (IETF), its areas,
   and its working groups. Note that other groups may also distribute
   working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six
   months and may be updated, replaced, or obsoleted by other documents
   at any time. It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This draft is being discussed on the 'ietf-smime' mailing list. To
   subscribe, send a message to ietf-smime-request@imc.org with the
   single word subscribe in the body of the message. There is a Web
   site for the mailing list at <http://www.imc.org/ietf-smime/>.

Abstract

   This document describes a mechanism to manage (i.e., setup,
   distribute, and rekey) keys used with symmetric cryptographic
   algorithms. Also defined herein is a mechanism to organize users
   into groups to support distribution of encrypted content using
   symmetric cryptographic algorithms. The mechanisms use mechanism uses the
   Cryptographic Message Syntax (CMS) protocol [2] and Certificate
   Management Message over CMS (CMC) protocol [3] to manage the
   symmetric keys. Any member of the group can then later use this
   distributed shared key to decrypt other CMS encrypted objects with
   the symmetric key. This mechanism has been developed to support
   S/MIME Mail List Agents (MLAs).

Turner                                                               1

Conventions used in this document

   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 RFC-2119 [4].

   1. INTRODUCTION....................................................3
   1.1 APPLICABILITY TO E-MAIL........................................4
   1.2 APPLICABILITY TO REPOSITORIES..................................4
   2. ARCHITECTURE....................................................4 ARCHITECTURE....................................................5
   3. PROTOCOL INTERACTIONS...........................................6
   3.1 CONTROL ATTRIBUTES.............................................7
   3.1.1 GL USE KEK...................................................7 KEK...................................................8
   3.1.2 GL DELETE...................................................10
   3.1.3 GL ADD MEMBERS..............................................10 MEMBER...............................................10
   3.1.4 GL DELETE MEMBERS...........................................11
   3.1.5 GL REKEY....................................................12
   3.1.6 GL ADD OWNER................................................13
   3.1.7 GL REMOVE OWNER.............................................13
   3.1.8 GL KEY COMPROMISE...........................................14
   3.1.9 GL KEY REFRESH..............................................14
   3.1.10 GL SUCCESS INFORMATION.....................................14
   3.1.11 GL FAIL INFORMATION........................................15
   3.1.12 GLA QUERY REQUEST..........................................17
   3.1.13 GLA QUERY RESPONSE.........................................18 RESPONSE.........................................17
   3.1.14 GL KEY.....................................................18 PROVIDE CERT............................................17
   3.1.15 GL UPDATE CERT.............................................18
   3.1.16 GL KEY.....................................................19
   3.2 USE OF CMC, CMS, AND PKIX.....................................19 PKIX.....................................20
   3.2.1 PROTECTION LAYERS...........................................19 LAYERS...........................................20
   3.2.1.1 MINIMUM PROTECTION........................................19 PROTECTION........................................21
   3.2.1.2 ADDITIONAL PROTECTION.....................................20 PROTECTION.....................................21
   3.2.2 COMBINING REQUESTS AND RESPONSES............................20 RESPONSES............................21
   3.2.3 GLA GENERATED MESSAGES......................................22 MESSAGES......................................23
   3.2.4 CMC CONTROL ATTRIBUTES......................................23 ATTRIBUTES......................................24
   3.2.5 PKIX........................................................23 RESUBMITTED GL MEMBER MESSAGES..............................26
   3.2.6 PKIX........................................................26
   4 ADMINISTRATIVE MESSAGES.........................................23 MESSAGES.........................................26
   4.1 ASSIGN KEK TO GL..............................................23 GL..............................................26
   4.2 DELETE GL FROM GLA............................................26 GLA............................................29
   4.3 ADD MEMBERS TO GL.............................................28 GL.............................................31
   4.3.1 GLO INITIATED ADDITIONS.....................................29 ADDITIONS.....................................32
   4.3.2 PROSPECTIVE MEMBER INITIATED ADDITIONS......................34 ADDITIONS......................37
   4.4 DELETE MEMBERS FROM GL........................................36 GL........................................39
   4.4.1 GLO INITIATED DELETIONS.....................................37 DELETIONS.....................................40
   4.4.2 MEMBER INITIATED DELETIONS..................................41 DELETIONS..................................44
   4.5 REQUEST REKEY OF GL...........................................42 GL...........................................45
   4.5.1 GLO INITIATED REKEY REQUESTS................................43 REQUESTS................................46
   4.5.2 GLA INITIATED REKEY REQUESTS................................45 REQUESTS................................48
   4.6 CHANGE GLO....................................................45 GLO....................................................48
   4.7 INDICATE KEK COMPROMISE.......................................47 COMPROMISE.......................................50
   4.7.1 GL MEMBER INITIATED KEK COMPROMISE MESSAGE..................51

Turner                                                               2
   4.7.2 GLO INITIATED KEK COMPROMISE MESSAGE........................52
   4.8 REQUEST KEK REFRESH...........................................49 REFRESH...........................................53
   4.9 GLA QUERY REQUEST AND RESPONSE................................50 RESPONSE................................54
   4.10 UPDATE MEMBER CERTIFICATE....................................56
   4.10.1 GLO AND GLA INITIATED UPDATE MEMBER CERTIFICATE............56
   4.10.2 GL MEMBER INITIATED UPDATE MEMBER CERTIFICATE..............57
   5 DISTRIBUTION MESSAGE............................................52 MESSAGE............................................58
   5.1 DISTRIBUTION PROCESS..........................................53

Turner                                                               2 PROCESS..........................................59
   6 KEY WRAPPING....................................................53 ALGORITHMS......................................................60
   6.1 KEK GENERATION ALGORITHM......................................60
   6.2 SHARED KEK WRAP ALGORITHM.....................................60
   6.3 SHARED KEK ALGORITHM..........................................61
   7 ALGORITHMS......................................................54 TRANSPORT.......................................................61
   8 TRANSPORT.......................................................54
   9 USING THE GROUP KEY.............................................54 KEY.............................................61
   9 SECURITY CONSIDERATIONS.........................................61
   10 SCHEMA REQUIREMENTS............................................54 REFERENCES.....................................................61
   11 SECURITY CONSIDERATIONS........................................54 ACKNOWLEDGEMENTS...............................................62
   12 REFERENCES.....................................................55
   13 ACKNOWLEDGEMENTS...............................................55
   14 AUTHOR'S ADDRESSES.............................................55 ADDRESSES.............................................62

1. Introduction

   With the ever-expanding use of secure electronic communications
   (e.g., S/MIME [2]), users require a mechanism to distribute
   encrypted data to multiple recipients (i.e., a group of users).
   There are essentially two ways to encrypt the data for recipients:
   using asymmetric algorithms with public key certificates (PKCs) or
   symmetric algorithms with symmetric keys.

   With asymmetric algorithms, the originator forms an originator-
   determined content-encryption key (CEK) and encrypts the content,
   using a symmetric algorithm. Then, using an asymmetric algorithm and
   the recipient's PKCs, the originator generates per-recipient
   information that either (a) encrypts the CEK for a particular
   recipient (ktri ReipientInfo CHOICE), or (b) transfers sufficient
   parameters to enable a particular recipient to independently
   generate the same KEK (kari RecipientInfo CHOICE). If the group is
   large, the amount of per-recipient information required may take
   quite some time to generate, not to mention the time required to
   collect and validate the PKCs for each of the recipients. Each
   recipient identifies their per-recipient information and uses the
   private key associated with the public key of their PKC to decrypt
   the CEK and hence gain access to the encrypted content.

   With symmetric algorithms, the origination process is the same as
   with asymmetric algorithms except for what encrypts the CEK. Instead
   of using PKCs, the originator uses a previously distributed secret
   key-encryption key (KEK) to encrypt the CEK (kekri RecipientInfo
   CHOICE). Only one copy of the encrypted CEK is required because all
   the recipients already have the shared KEK needed to decrypt the CEK
   and hence gain access to the encrypted content.

Turner                                                               3
   The security provided by the shared KEK is only as good as the sum
   of the techniques employed by each member of the group to keep the
   KEK secret from nonmembers. These techniques are beyond the scope of
   this document. Only the members of the list and the key manager
   should have the KEK in order to maintain the secrecy of the group.
   Access control to the information protected by the KEK is determined
   by the entity that encrypts the information, as all members of the
   group have access. If the entity that is performing the encryption
   wants to ensure some subset of the group does not gain access to the

Turner                                                               3
   information either a different KEK should be used (shared with this
   smaller group) or asymmetric algorithms should be used.

1.1 Applicability to E-mail

   One primary audience for this distribution mechanism is e-mail.
   Distribution lists sometimes referred to as mail lists, have been
   defined to support distribution of messages to recipients subscribed
   to the mail list. There are two models for how the mail list can be
   used. If the originator is a member of the mail list, the originator
   sends messages encrypted with the shared KEK to the mail list (e.g.,
   listserv or majordomo) and the message is distributed to the mail
   list members. If the originator is not a member of the mail list
   (does not have the shared KEK), the originator sends the message
   (encrypted for the MLA) to the mail list agent (MLA) and the MLA
   then forms the shared KEK needed to encrypt the message. In either
   case the recipients of the mail list use the previously distributed-
   shared KEK to decrypt the message.

1.2 Applicability to Repositories

   Objects can also be distributed via a repository (e.g., Light Weight
   Directory Protocol (LDAP) servers, X.500 Directory System Agents
   (DSAs), Web-based servers). If an object is stored in a repository
   encrypted with a symmetric key algorithm, any one with the shared
   KEK and access to that object can then decrypt that object. The
   encrypted object and the encrypted, shared KEK can be stored in the
   repository.

Turner                                                               4

2. Architecture

   Figure 1 depicts the architecture to support symmetric key
   distribution. The Group List Agent (GLA) supports two distinct
   functions with two different agents:

     - 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) to which the shared KEKs are
       distributed.

Turner                                                               4

     +----------------------------------------------+
     |              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 may support multiple KMAs. KMAs may be differentiated by the
   'goodness' of the random number used to generate the shared KEK or
   the key management technique used to distribute the shared KEK.
   Outside the GLA, KMAs are differentiated by the digital signatures
   they apply to the messages they generate. A GLA in general supports only one
   GMA, but the GMA may support multiple GLs. Multiple KMAs may support
   a GMA in the same fashion as GLAs support multiple KMAs. Assigning a
   particular KMA to a GL is beyond the scope of this document.

   Modeling real world GL implementations shows that there are very
   restrictive GLs, where a human determines GL membership, and very
   open GLs, where there are no restrictions on GL membership. To
   support this spectrum, the mechanism described herein supports both
   managed (i.e., where access control is applied) and unmanaged (i.e.,
   where no access control is applied) GLs. The access control
   mechanism for managed lists is beyond the scope of this document.

   In either case, the GL must initially be constructed by an entity
   hereafter called the Group List Owner (GLO). There may be multiple
   entities who 'own' the GL and who are allowed to make changes the
   GL's properties or membership. The GLO determines if the GL will be
   managed or unmanaged and is the only entity that may delete the GL.
   GLO(s) may or may not be GL members.

Turner                                                               5
   Though Figure 1 depicts the GLA as encompassing both the KMA and GMA
   functions, the two functions could be supported by the same entity
   or they could be supported by two different entities. If two
   entities are used, they could be located on one or two platforms.
   There is however a close relationship between the KMA and GMA
   functions. If the GMA stores all information pertaining to the GLs
   and the KMA merely generates keys, a corrupted GMA could cause
   havoc. To protect against a corrupted GMA, the KMA would be forced

Turner                                                               5
   to double check the requests it receives to ensure the GMA did not
   tamper with them. These duplicative checks blur the functionality of
   the two components together. For this reason, the interactions
   between the KMA and GMA are beyond the scope of this document.
   Proprietary mechanisms may be used to separate the functions by
   strengthening the trust relationship between the two entities.
   Henceforth, the distinction between the two agents is omitted; the
   term GLA will be used to address both functions. It should be noted
   that corrupt GLA can always cause havoc.

3. Protocol Interactions

   There are existing mechanisms (e.g., listserv and majordomo) to
   support managing GLs; however, this document does not address
   securing these mechanisms, as they are not standardized. Instead, it
   defines protocol interactions, as depicted in Figure 2, used by the
   GL members, GLA, and GLO to manage GLs and distribute shared KEKs.
   The interactions have been divided into administration messages and
   distribution messages. The administrative messages are the request
   and response messages needed to setup the GL, delete the GL, add
   members to the GL, delete members of the GL, and request a group
   rekey, etc. The distribution messages are the messages that
   distribute the shared KEKs. The following paragraphs describe the
   ASN.1 for both the administration and distribution messages.
   Paragraph 4 describes how to use the administration messages and
   paragraph 5 describes how to use the distribution messages.

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

                      Figure 2 - Protocol Interactions

Turner                                                               6

3.1 Control Attributes

   The messages are based on including control attributes in CMC's
   PKIData.controlSequence
   PKIData for requests and CMC's
   ResponseBody.controlSequence ResponseBody0 for responses. The
   content-types PKIData and PKIResponse are then encapsulated in CMS's
   SignedData or EnvelopedData, or a combination of the two (see
   paragraph 3.2). The following are the control attributes defined in
   this document:

   Implementation
    Requirement

         Control
        Attribute          OID          Syntax
   --------------  ------------------
   -------------------  ----------- -----------------
       MAY
    glUseKEK            id-skd 1    GLUseKEK
       MAY
    glDelete            id-skd 2    GLDelete
       MAY          glAddMembers    GeneralName
    glAddMember         id-skd 3    GLAddMembers
       MAY          glDeleteMembers    glAddMember
    glDeleteMember      id-skd 4    GLDeleteMembers
       MAY    GLDeleteMember
    glRekey             id-skd 5    GLRekey
       MAY          glAddOwners
    glAddOwner          id-skd 6    GLAddOwners
       MAY          glRemoveOwners    GLOwnerAdministration
    glRemoveOwner       id-skd 7    GLRemoveOwners
       MAY    GLOwnerAdministration
    glkCompromise       id-skd 8    GLKCompromise
       SHOULD    GeneralName
    glkRefresh          id-skd 9    GLKRefresh
       MAY    GeneralName
    glSuccessInfo       id-skd 10   GLSuccessInfo
       MAY
    glFailInfo          id-skd 11   GLFailInfo
       MAY          glAQueryRequest
    glaQueryRequest     id-skd 12   GLAQueryRequest
       MAY          glAQueryResponse
    glaQueryResponse    id-skd 13   GLAQueryResponse
       MUST         glKey
    glProvideCert       id-skd 14   GLProvideCert
    glUpdateCert        id-skd 15   GLUpdateCert
    glKey               id-skd 16   GLKey

   GLSuccessInfo, GLFailInfo, and GLAQueryResponse are responses and go
   into the PKIResponse content-type, all other messages are requests
   and go into the PKIData content-type.

3.1.1 GL USE KEK

   The GLO uses GLUseKEK to request that a shared KEK be assigned to a
   GL.

   GLUseKEK ::= SEQUENCE {
     glName                    GeneralName,
     glOwner                   SEQUENCE SIZE (1..MAX) OF GeneralName,
     glAdministration          GLAdministration,
     glDistributionMethod      GLDistributionMethod,
     glKeyAttributes       [0] GLKeyAttributes OPTIONAL }

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

Turner                                                               7
   GLDistributionMethod ::= CHOICE {
     rfc822Name                 [0] IA5String,
     x400Address                    ORAddress,
     directoryName                  Name,
     uniformResourceIdentifier  [1] IA5String }

   GLKeyAttributes ::= SEQUENCE {
     rekeyControlledByGLO   [0] BOOLEAN DEFAULT FALSE,
     recipientMutuallyAware [1] BOOLEAN DEFAULT TRUE,
     duration               [2] INTEGER DEAULT (0),
     generationCounter      [3] INTEGER DEFAULT {2},
     requestedAlgorithm     [4] AlgorithmIdentifier OPTIONAL }

   The fields in GLUseKEK have the following meaning:

     - glName is are the name of implementation requirements for the GL. The control
   attributes defined herein:

           Implementation Requirement         |   Control
     GLO    |        GLA          | GL Member |  Attribute
   O    R   | O      R       F    | O    R    |
   -------- | ------------------  | --------- | ----------
   MAY  N/A | N/A    MAY     N/A  | N/A  N/A  | glUseKEK
   MAY  N/A | N/A    MAY     N/A  | N/A  N/A  | glDelete
   MAY  MAY | N/A    MUST    MAY  | N/A  MUST | glAddMember
   MAY  MAY | N/A    MUST    MAY  | N/A  MUST | glDeleteMember
   MAY  N/A | N/A    MAY     N/A  | N/A  N/A  | glRekey
   MAY  N/A | N/A    MAY     N/A  | N/A  N/A  | glAddOwner
   MAY  N/A | N/A    MAY     N/A  | N/A  N/A  | glRemoveOwner
   MAY  MAY | N/A    MUST    MAY  | MUST N/A  | glkCompromise
   MAY  N/A | N/A    MUST    N/A  | MUST N/A  | glkRefresh
   N/A  MAY | MUST   N/A     N/A  | N/A  MUST | glSucessInfo
   N/A  MAY | MUST   N/A     N/A  | N/A  MUST | glFailInfo
   MAY  N/A | N/A    SHOULD  N/A  | MAY  MAY  | glaQueryRequest
   N/A  MAY | SHOULD N/A     N/A  | MAY  MAY  | glaQueryResponse
   MAY  N/A | MUST   N/A     MAY  | N/A  MUST | glProvideCert
   N/A  MAY | N/A    MUST    MAY  | MUST N/A  | glUpdateCert
   N/A  N/A | MUST   N/A     N/A  | N/A  MUST | glKey

Turner                                                               7
   glSuccessInfo, glFailInfo, glaQueryResponse, and gloResponse are
   responses and go into the PKIResponse content-type, all other
   control attributes are included in requests and go into the PKIData
   content-type. The exception is glUpdateCert which may be included in
   either PKIData or PKIResponse.

3.1.1 GL USE KEK

   The GLO uses glUseKEK to request that a shared KEK be assigned to a
   GL. glUseKEK messages MUST be signed by the GLO. The glUseKEK
   control attribute shall have the syntax GLUseKEK:

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

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

   GLOwnerInfo ::= SEQUENCE {
     glOwnerName     GeneralName,
     glOwnerAddress  GeneralName }

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

   GLKeyAttributes ::= SEQUENCE {
     rekeyControlledByGLO   [0] BOOLEAN DEFAULT FALSE,
     recipientMutuallyAware [1] BOOLEAN DEFAULT TRUE,
     duration               [2] INTEGER DEAULT (0),
     generationCounter      [3] INTEGER DEFAULT (2),
     requestedAlgorithm     [4] AlgorithmIdentifier
                                 DEFAULT (id-alg-CMS3DESwrap) OPTIONAL
   }

   The fields in GLUseKEK have the following meaning:

     - glInfo indicates the GL's name in glName and the GL's address in
       glAddress. In some instances the glName and glAddress may be the
       same, but this is not always the case. The name and address MUST
       be unique for a given GLA.

     - glOwner glOwnerInfo indicates the owner of GL owner's name in glOwnerName and the GL.
       GL owner's address in glOwnerAddress. One of the names in
       glOwner

Turner                                                               8
       glOwnerName MUST match one of the names in the certificate used
       to sign this SignedData.PKIData creating the GL (i.e., the
       immediate signer). Multiple GLOs MAY be indicated if
       glAdministration is set to managed or closed.

     - glAdministration indicates how the GL should be administered.
       The default is for the list to be unmanaged managed. Three values are
       supported for glAdministration:

       - Unmanaged - When the GLO sets glAdministration to unmanaged,
         they are allowing prospective members to request being added
         and deleted from the GL without GLO intervention. They are
         also indicating that only one GLO may be associated at any one
         time with the GL.

       - Managed - When the GLO sets glAdministration to managed, they
         are allowing prospective members to request being added to and
         deleted from the GL, but the request is redirected by the GLA
         to GLO for review. The GLO makes the determination as to
         whether to honor the request.

       - Closed - When the GLO sets glAdministration to closed, they
         are not allowing prospective members to request being added to
         or deleted from the GL. The GLA will only accept glAddMember
         and glDeleteMember requests from prospective members. Three possibilities exist: the GLO.

     - Unmanaged glKeyAttributes indicates the attributes the GLO wants the GLA
       to assign to the shared KEK. If this field is omitted, GL rekeys
       will be controlled by the GLA, the recipients are allowed to
       know about one another, the algorithm will Triple-DES (see
       paragrpah 7), the shared KEK will be valid for a calendar month
       (i.e., first of the month until the last day of the month), and
       two shared KEKs will be distributed initially. The fields in
       glKeyAttributes have the following meaning:

       - When rekeyControlledByGLO indicates whether the GL rekey messages
         will be generated by the GLO or by the GLA. The default is for
         the GLA to control rekeys. If GL rekey is controlled by the
         GLA, the GLO sets glAdministration to unmanaged,
         they are allowing prospective members GL will continue to request being added
         and deleted from be rekeyed until the GLO deletes
         the GL without or changes the GL rekey to be GLO intervention.

       - Managed controlled.

       - When recipientsMutuallyAware indicates that the GLO sets glAdministration to managed, they
         are allowing prospective members wants the GLA
         to request being added and
         deleted from distribute the GL, but shared KEK individually for each of the request GL
         members (i.e., a separate glKey message is sent to GLO for
         review. The requests are redirected to the GLO. each
         recipient). The GLO makes
         the determination as to whether default is for separate glKey message to honor not
         be required.

         NOTE: This supports lists where one member does not know the request.

       - Closed - When
         identities of the GLO sets glAdministration other members. For example, a list is
         configured granting submit permissions to closed, they only one member. All
         other members are 'listening.' The security policy of the list
         does not allowing prospective allow the members to request being added
         and deleted from know who else is on the GL. The GLA will only accept GLAddMembers
         and GLDeleteMembers requests list. If

Turner                                                               9
         a glKey is constructed for all of the GL members, information
         about each of the members may be derived from the GLO.

     - glDistributionMethod indicates information
         in RecipientInfos. To make sure the mechanism glkey message does not
         divulge information about the GLA should
       distribute shared KEKs. Internet mail (rfc822Name) MUST be
       supported and X.400 (x400Address), X.500 (directoryName), and
       web (uniformResourceIdentifier) MAY other recipients, a separate
         glKey message would be supported (see paragraph
       8). sent to each GL member.

       - glKeyAttributes duration indicates the attributes the GLO wants length of time (in days) during which
         the GLA
       to assign to shared KEK is considered valid. The value zero (0)
         indicates that the shared KEK. If KEK is valid for a calendar month.
         For example if the field duration is omitted, zero (0), if the GL rekeys

Turner                                                               8 shared KEK
         is requested on July 24, the first key will be controlled by the GLA, valid until the recipients are allowed to
       know about one another,
         end of July and the algorithm next key will be as specified in
       paragraph 7, valid for the entire
         month of August. If the value is not zero (0), the shared KEK
         will be valid for a calendar month
       (i.e., first the number of days indicated by the month until value.
         For example, if the last day value of the month), duration is seven (7) and
       two the
         shared KEK is requested on Monday but not generated until
         Tuesday (2359); the shared KEKs will be distributed initially. valid from Tuesday
         (2359) to Tuesday (2359). The fields in
       glKeyAttributes have exact time of the following meaning: day is
         determined when the key is generated.

       - rekeyControlledByGLO generationCounter indicates whether the number of keys the GLO wants
         the GLA to distribute. To ensure uninterrupted function of the
         GL rekey messages
         will two (2) shared KEKs at a minimum MUST be generated by initially
         distributed. The second shared KEK is distributed with the
         first shared KEK, so that when the first shared KEK is no
         longer valid the second key can be used. If the GLA controls
         rekey then it also indicates the number of shared KEKs the GLO or by
         wants outstanding at any one time. See paragraphs 4.5 and 5
         for more on rekey.

       - requestedAlgorithm indicates the algorithm and any parameters
         the GLA. The default is for GLO wants the GLA to control rekeys. If GL rekey is controlled by the
         GLA, use to generate the shared KEK. See
         paragraph 7 for more on algorithms.

3.1.2 GL will continue Delete

   GLOs use glDelete to request that a GL be rekeyed until deleted from the GLO deletes GLA. The
   glDelete control attribute shall have the GL or changes syntax GeneralName. The
   name of the GL rekey to be GLO controlled.

       - recipientsMutuallyAware indicates that the GLO wants deleted is included in GeneralName. The
   glDelete message MUST be signed by the GLA GLO.

3.1.3 GL Add Member

   GLOs use glAddMember to distribute the shared KEK individually for each request addition of the new members and
   prospective GL members (i.e., a separate GLKey message is sent use glAddMember to each
         recipient). request being added to the
   GL. The default is for separate GLKey glAddMember message to not must be required.

         NOTE: This supports lists where one member does not know signed by either the
         identities of GLO or the other members. For example, a list is
         configured granting submit permissions to only one
   prospective GL member. All
         other members are 'listening.' The security policy of glAddMember control attribute shall have
   the list
         does not allow syntax GLAddMember:

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

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

   Certificates ::= SEQUENCE {
      membersPKC         Certificate,
                                  -- See X.509
      membersAC          SEQUENCE OF AttributeCertificate OPTIONAL,
                                  -- See X.509
      certificationPath  CertificateSet OPTIONAL }
                                  -- From CMS [2]

   CertificateSet ::= SET OF CertificateChoices

   CertificateChoices ::= CHOICE {
     certificate              Certificate,    -- See X.509
     extendedCertificate  [0] IMPLICIT ExtendedCertificate,
                                              -- Obsolete
     attrCert             [1] IMPLICIT AttributeCertificate }
                                              -- See X.509 and X9.57

   The fields in GLAddMembers have the members to know who else is on following meaning:

     - glName indicates the list. If
         a GLKey is constructed for all name of the GL members, information
         about each of to which the members may member should
       be derived from the information
         in RecipientInfos. To make sure added.

     - glMember indicates the GLKey message does not
         divulge information about particulars for the other recipients, a separate
         GLKey message would be sent to each GL member.

       - duration
       glMemberName indicates the length name of time (in days) during which the shared KEK is considered valid. The value zero (0) GL member and
       glMemberAddress indicates that the shared KEK is valid for a calendar month.
         For example if the duration is zero (0), if the GL shared KEK
         is requested on July 24, the first key will be valid until member's address. In some
       instances the
         end of July glMemberName and the next key will glMemberAddress may be valid for the entire
         month of August. If the value same,
       but this is not zero (0), always the shared KEK case. certificates.membersPKC
       includes the member's encryption certificate that will be valid used
       to at least initially encrypt the shared KEK for that member.
       certificates.membersAC MAY be included to convey any attribute
       certificate associated with the number of days indicated by member's encryption certificate.
       certificates.certificationPath MAY also be included to convey
       the value.
         For example, if certification path corresponding to the value of duration is seven (7) member's encryption
       and the
         shared KEK attribute certificates. The certification path is requested on Monday but not generated until
         Tuesday (2359); optional
       because it may already be included elsewhere in the message
       (e.g., in the outer CMS layer).

3.1.4 GL Delete Members

   GLOs use glDeleteMember to request deletion of GL members and
   prospective non-GL members use glDeleteMember to request being

Turner                                                              11
   removed from the shared KEKs will GL. The glDeleteMember message must be valid from Tuesday
         (2359) to Tuesday (2359). signed by
   either the GLO or the prospective GL member. The exact time of glDeleteMember
   control attribute shall have the day is
         determined when syntax GLDeleteMember:

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

   The fields in GLDeleteMembers have the key is generated. following meaning:

     - generationCounter glName indicates the number name of keys the GLO wants GL from which the GLA to distribute. To ensure uninterrupted function member should
       be removed.

     - glMemberToDelete indicates the name of the member to be deleted.

3.1.5 GL two (2) shared KEKs at Rekey

   GLOs use the glRekey to request a minimum GL rekey. The glRekey message MUST
   be initially
         distributed. signed by the GLO. The second shared KEK is distributed with glRekey control attribute shall have the
         first shared KEK, so that when
   syntax GLRekey:

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

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

   The fields in GLRekey have the first shared KEK following meaning:

     - glName indicates the name of the GL to be rekeyed.

     - glAdministration indicates if there is no
         longer valid any change to how the second key can GL
       should be used. administered. See paragraphs 4.5
         and 5 paragraph 3.1.1 for more on rekey.

Turner                                                               9 the three
       options. This field is only included if there is a change from
       the previously registered administered.

     - requestedAlgorithm glNewKeyAttributes indicates whether the rekey of the GLO is
       controlled by the GLA or GL, what algorithm and any parameters the
       GLO wants the GLA to use wishes to generate use, the shared KEK. See
         paragraph 7 for more on algorithms.

3.1.2 GL Delete

   GLOs use GLDelete to request that a GL duration of the key, and how many
       outstanding keys should be deleted issued. The field is only included if
       there is a change from the GLA.

   GLDelete ::= GLNameAndIdentifier

   GLNameAndIdentifier ::= SEQUENCE {
     glName       GeneralName,
     glIdentifier GLIdentifier OPTIONAL }

   The fields in GLDelete have previously registered
       glKeyAttributes. If the following meaning:

     - glName indicates value zero (0) is specified in
       generationCounter the name GLO is indicating that it wants all of the

Turner                                                              12
       outstanding GL to be deleted.

     - glIdentifier indicates shared KEKs rekeyed. For example, suppose the identifier of GLO
       used the GL glUseKEK with duration set to be deleted.
       It MAY be omitted if it two (2) and the glRekey
       message is unknown (e.g., sent during the GLO hasn't
       received first duration with generationCounter
       set to zero (0). The GLA would know to generate a GLSuccessInfo assigning the glIdentifier glKey message
       to replace both the GL)
       or has been lost by shared KEK currently being used and the GLO.

3.1.3
       shared KEK for the second duration.

3.1.6 GL Add Members Owner

   GLOs use GLAddMembers the glAddOwner to request addition of that a new members and
   prospective GL members' use GLAddMembers GLO be allowed to
   administer the GL. In addition, a registered GLO may use the request being added
   to update their certificate on the GL.

   GLAddMembers ::= SEQUENCE {
     glName           GeneralName,
     glMembers        SEQUENCE SIZE (1..MAX) OF GLMember,
     glIdentifier     GLIdentifier OPTIONAL }

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

   Certificates GLA. In this case, the new GLO
   certificate is signed by the old GLO certificate. The glAddOwner
   message MUST be signed a registered GLO. The glAddOwner control
   attribute shall have the syntax GLOwnerAdministration:

   GLOwnerAdministration ::= SEQUENCE {
      membersPKC         Certificate,
                                  -- See X.509
      membersAC          SEQUENCE OF AttributeCertificate OPTIONAL,
                                  -- See X.509
      certificationPath  CertificateSet OPTIONAL }
                                  -- From CMS [2]

   CertificateSet ::= SET OF CertificateChoices

Turner                                                              10
   CertificateChoices ::= CHOICE {
     certificate              Certificate,    -- See X.509
     extendedCertificate  [0] IMPLICIT ExtendedCertificate,
                                              -- Obsolete
     attrCert             [1] IMPLICIT AttributeCertificate
     glName       GeneralName,
     glOwnerInfo  GLOwnerInfo }
                                              -- See X.509 and X9.57

   The fields in GLAddMembers GLAddOwners have the following meaning:

     - glName indicates the name of the GL to which the member new GLO should
       be added. associated.

     - glMembers indicates the particulars for the GL member(s) to be
       added to the GL. GLMemberName glOwnerInfo indicates the name and address of the new GLO.

3.1.7 GL
       member. certificates.membersPKC includes Remove Owner

   GLOs use the member's encryption
       certificate that will be used glRemoveOwner to encrypt the shared KEK for request that
       member. certificates.membersAC MAY a GLO be included to convey any
       attribute certificate associated disassociated
   with the member's encryption
       certificate. certificates.certificationPath MAY also GL. The glRemoveOwner message MUST be included
       to convey signed a registered
   GLO. Unmanaged GLs may only have one GLO. If the certification path corresponding to GLA processes a
   glRemoveOwner for an unmanaged GL, only one GLO shall be associated
   with the member's
       encryption and attribute certificates. GL at any given time. The certification path is
       optional because it may already be included elsewhere in glRemoveOwner control attribute
   shall have the
       message (e.g., syntax GLOwnerAdministration:

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

   The fields in GLRemoveOwners have the outer CMS layer). following meaning:

     - glIdentifier glName indicates the identifier name of the GL to which the
       member GLO should be added. It MAY be omitted if it is unknown
       (e.g.,
       disassociated.

     - glOwnerInfo indicates the GLO hasn't received a GLSuccessInfo assigning name and address of the
       glIdentifier GLO to be
       removed.

Turner                                                              13

3.1.8 GL Key Compromise

   GL members and GLOs use glkCompromise to indicate that the GL) or shared
   KEK possessed has been lost by compromised. The glKeyCompromise control
   attribute shall have the GLO. The
       prospective GL member MAY omit this field. syntax GeneralName. The GLO MUST omit name of the
       field if GL to
   which the GLAddMembers compromised key is associated GLUseKEK with is included in
   GeneralName. This message is always redirected by the GLA to the GLO
   for further action. The glkCompromise MUST NOT be included in an
   EnvelopedData generated with the same SignedData.PKIData content-type.

3.1.4 compromised shared KEK.

3.1.9 GL Delete Members

   GLOs use GLDeleteMembers to request deletion of Key Refresh

   GL members and
   prospective non-GL members use GLDeleteMembers the glkRefresh to request being
   removed from that the GL.

   GLDeleteMembers shared KEK be
   redistributed to them. The glKeyRefresh control attribute shall have
   the syntax GeneralName. The GL member includes the GL's name in
   GeneralName.

3.1.10 GL Success Information

   The GLA uses glSuccessInfo to indicate a successful result of an
   administrative message. A separate glSuccessInfo is returned for
   each action (e.g., if there are four successful glAddMember requests
   then four glSuccessInfo responses are generated). The glSuccessInfo
   message MUST be signed by the GLA. The glSucessInfo control
   attribute shall have the syntax GLSucessInfo:

   GLSuccessInfo ::= SEQUENCE {
     glName            GeneralName,
     glMembersToDelete SEQUENCE SIZE (1..MAX) OF GeneralName,
     glInfo       GLInfo,
     glIdentifier      GLIdentifier GLIdentifier,
     action       Action }

   Action ::= SEQUENCE {
     actionCode     ActionCode,
     glMemberName   [0] GeneralName OPTIONAL,
     glOwnerName    [1] GeneralName OPTIONAL }

   ActionCode ::= INTEGER {
     assignedKEK   (0),
     deletedGL     (1),
     addedMember   (2),
     deletedMember (3),
     rekeyedGL     (4),
     addedGLO      (5),
     removedGLO    (6) }

   The fields in GLDeleteMembers GLSuccessInfo have the following meaning:

     - glName glInfo indicates the GL's name of the GL from which in glName and the member should
       be removed. GL's address in
       glAddress.

Turner                                                              11                                                              14
     - glIdentifier identifies GL's unique shared KEK.

     - glMembersToDelete action indicates the name of successfully performed action.
       action.actionCode indicates whether the shared KEK was assigned
       to the GL, whether the GL was deleted, whether a member was
       added to a GL, whether a member to be
       deleted.

     - glIdentifier indicates the identifier of was deleted from a GL, whether
       the GL was rekeyed, whether a new GLO was added, and whether a
       GLO was removed. If members were added to which a GL or deleted from a
       GL the
       member should members MUST be deleted. The prospective non-GL member indicated in glMemberName and glOwnerName
       MUST
       include the field. The be omitted. If a GLO MAY omit this field if it is unknown
       (e.g., was added to a GL or deleted from a
       GL, the GLO hasn't received MUST be indicated in glOwnerName and glMemberName
       MUST be omitted. If a GLSuccessInfo assigning the
       glIdentifier shared KEK was assigned to the GL) a GL or has been lost by the GLO.

3.1.5 a GL Rekey

   GLOs use the GLRekey
       was deleted both glOwnerName and glMember MUST be omitted.

3.1.11 GL Fail Information

   The GLA uses glFailInfo to request indicate that there was a GL rekey.

   GLRekey problem
   performing a requested action. A separate glFailInfo is returned for
   each action (e.g., if there are four denied glAddMember requests
   then four glFailInfo responses are generated). The glFailInfo
   message MUST be signed by the GLA. The glFailInfo control attribute
   shall have the syntax GLFailInfo:

   GLFailInfo ::= SEQUENCE {
     glName        GeneralName,
     glIdentifier         GLIdentifier,
     glOwner
     error         Error }

   Error ::= SEQUENCE SIZE (0..MAX) OF GeneralName,
     glAdministration     GLAdministration OPTIONAL,
     glDistributionMethod GLDistributionMethod {
     errorCode        ErrorCode,
     glMemberName [0] GeneralName OPTIONAL,
     glKeyAttributes      GLKeyAttributes
     glOwnerName  [1] GeneralName OPTIONAL }

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

Turner                                                              15
   The fields in GLRekey have the following meaning:

     - glName indicates the name of the GL to be rekeyed.

     - glIdentifier identifies GLFailInfo have the shared KEK to be rekeyed. following meaning:

     - glOwner glName indicates the owner(s) name of the GL.  The field is only
       included if there is a change from the registered GLOs.

     - glAdministration indicates how the GL should be administered.
       See paragraph 3.1.1 for the three options.  This field is only
       included if there is a change from the previously registered
       administered.

     - glDistributionMethod indicates the mechanism the shared KEK
       should be distributed. The field is only included if there is a
       change from to which the previously registered glDistributionMethod. error
       corresponds.

     - glKeyAttributes error indicates whether the rekey of the GLO is
       controlled by reason why the GLA or GL, what algorithm and parameters the
       GLO wishes was unable to use, the duration of the key, and how many
       outstanding keys should be issued. The field is only included if
       there is a change from the previously registered
       glKeyAttributes. If the value zero (0) is specified in
       generationCounter perform the GLO is indicating that it wants all of
       request. It also indicates the
       outstanding GL shared KEKs rekeyed. For example, suppose the member or GLO
       used the GLUseKEK with duration set to two (2) and the GLRekey
       message is sent during which the first duration with generationCounter
       set to zero (0).  The GLA would know
       error corresponds. If members were not added to generate a GLKey message

Turner                                                              12
       to replace both the shared KEK currently being used and the
       shared KEK for the second duration.

3.1.6 GL Add Owner

   GLOs use the GLAddOwners to request that or deleted
       from a new GLO be allowed to
   administer GL the GL.  These requests are only applicable members MUST be indicated in glMemberName. If a
       GLO was not added to GLs that
   are managed (i.e., administered.managed) a GL or closed (i.e.,
   administered.closed).

   GLAddOwners ::= GLOwnerAdministration

   GLOwnerAdministration ::= SEQUENCE {
     glName       GeneralName,
     glOwner      SEQUENCE SIZE (1..MAX) OF GeneralName,
     glIdentifier GLIdentifier OPTIONAL }

   The fields deleted from a GL, the GLO MUST be
       indicated in GLAddOwners have glOwnerName. The errors are returned under the
       following meaning: conditions:

       - glName unspecified indicates that the name of the GL GLA is unable or unwilling to which
         perform the new GLO should
       be associated. requested action and does not want to indicate
         why.

       - glOwner closedGL indicates that members can only be added or deleted
         by the name(s) of the new GLO(s). GLO.

       - glIdentifier optionally unsupportedDuration indicates the identifier of GLA does not support
         generating keys that are valid for the GL to
       which requested duration.

       - noGLACertificate indicates that the GLO should be associated. It MAY be omitted if it is
       unknown (e.g., GLA does not have a valid
         certificate.

       - invalidCert indicates the GLO hasn't received member's encryption certificate was
         not verifiable (i.e., signature did not validate,
         certificate's serial number present on a GLSuccessInfo assigning CRL, etc.).

       - unsupportedAlgorithm indicates the glIdentifier to GLA does not support the GL) or has been lost by
         requested algorithm.

       - noGLONameMatch indicates that one of the GLO

3.1.7 GL Remove Owner

   GLOs use names in the GLRemoveOwners
         certificate used to request that sign a GLO be disassociated
   with the GL.  These requests are only applicable to managed GLs.

   GLRemoveOwners ::= GLOwnerAdministration

   The fields in GLRemoveOwners have request does not match the following meaning: name of
         a registered GLO.

       - glName invalidGLName indicates the name of GLA does not support the GL to which glName
         present in the GLO should be
       disassociated. request.

       - glOwner nameAlreadyInUse indicates the name of glName is already assigned on
         the GLO. GLA.

       - glIdentifier optionally noSpam indicates the identifier of the prospective GL to
       which member did not sign the GLO should be disassociated. It MAY be omitted
         request (i.e., if it
       is unknown (e.g., the GLO hasn't received a GLSuccessInfo
       assigning the glIdentifier to name in glMember.glMemberName does not
         match one of the GL) or has been lost by names in the
       GLO

Turner                                                              13

3.1.8 GL Key Compromise

   GL members use GLKCompromise certificate used to indicate that the shared KEK they
   possessed has been compromised.

   GLKCompromise ::= GLNameAndIdentifier

   The fields in GLKeyCompromise have sign the following meanings:
         request).

       - glName alreadyAMember indicates the name of the GL. prospective GL member is already
         a GL member.

Turner                                                              16
       - glIdentifier notAMember indicates the identifier of the prospective non-GL member is not a GL for which
         member.

       - alreadyAnOwner indicates the
       shared KEK prospective GLO is associated. The GL members MAY omit this field if
       it already a GLO.

       - notAnOwner indicates the prospective non-GLO is unknown.

3.1.9 GL Key Refresh not a GLO.

3.1.12 GLA Query Request

   GLOs and GL members use the GLKRefresh glaQueryRequest to request that ascertain information
   about the shared KEK be
   redistributed to them.

   GLKRefresh ::= GLNameAndIdentifier GLA. The fields in GLKRefresh glaQueryRequest control attribute shall have the
   syntax GLAQueryRequest:

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

   One request type is defined herein to following meaning:

     - glName indicates support the name of GLO in determining
   the GL.

     - glIdentifier algorithms supported by the GLA:

   id-rt-algorithmSupported { id-tbd }

   There is no value defined for id-rt-algorithmSupported. Including
   the id-rt-algorithmSupport indicates that the identifier of GLO wishes to know the GL for which
   algorithms that the
       shared KEK is associated. The GL members MAY omit this field if
       it is unknown.

3.1.10 GL Success Information

   The GLA uses GLSuccessInfo to indicate supports.

3.1.13 GLA Query Response

   GLA's return the glaQueryResponse after receiving a successful result of an
   administrative message.

   GLSuccessInfo GLAQueryRequest.
   The glaQueryResponse MUST be signed by a GLA. The glaQueryResponse
   control attribute shall have the syntax GLAQueryResponse:

   GLAQueryResponse ::= SEQUENCE {
     glName       GeneralName,
     glIdentifier GLIdentifier,
     action       SEQUENCE SIZE (1..MAX) OF Action
     glaResponseType   OBJECT IDENTIFIER,
     glaResponseValue  ANY DEFINED BY glaResponseType }

   ** With multiple GLOs do we want

   One response type is defined herein for the GLA to indicate which GLO asked for the
   action
   algorithms it supports:

   smimeCapabilities OBJECT IDENTIFIER ::=
   {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 15}
   -- Identifies the algorithms supported by the GLA (see MsgSpec [5])

3.1.14 GL Provide Cert

   GLAs and GLOs use glProvideCert to request that a GL member provide
   an updated or new encryption certificate. The glProvideCert message
   MUST be performed? **

   Action signed by either GLA or GLO. If the GL member's PKC has been

Turner                                                              17
   revoked, the GLO or GLA MUST NOT use it to generate the
   EnvelopedData that encapsulates the glProvideCert request. The
   glProvideCert control attribute shall have the syntax GLProvideCert:

   GLProvideCert ::= SEQUENCE {
     actionCode     ActionCode,
     glName        GeneralName,
     glMemberName   [0] GeneralName OPTIONAL,
     glOwnerName    [1] GeneralName OPTIONAL }

Turner                                                              14
   ActionCode ::= INTEGER {
     assignedKEK   (0),
     deletedGL     (1),
     addedMember   (2),
     deletedMember (3),
     rekeyedGL     (4),
     addedGLO      (5),
     removedGLO    (6) }  GeneralName}

   The fields in GLSuccessInfo GLProvideCert have the following meaning:

     - glName indicates the name of the GL.

     - glIdentifier identifies the specific GL on to which the GLA (the GLA may
       support multiple GLs). GL member's new
       certificate should be associated.

     - action indicates the successfully performed action.
       action.actionCode glMemberName indicates whether the shared KEK was assigned
       to the GL, whether name of the GL was deleted, whether a member was
       added or deleted member.

3.1.15 GL Update Cert

   GL members use glUpdateCert to or from provide a specific GL, whether new certificate for the GL.
   GL
       rekeyed, whether a new GLO was added, and whether a GLO was
       deleted. If members were added may generate a glUpdateCert unsolicited or deleted from as a result of
   a glProvideCert message. GL the members MUST be indicated in glMemberName.  If a GLO was added or
       deleted from sign the GL, glUpdateCert. If
   the GL member's encryption certificate has been revoked, the GLO(s) MUST be indicated in
       glOwnerName.

3.1.11 GL Fail Information

   The GLA uses GLFailInfo
   member MUST NOT use it to indicate generate the EnvelopedData that there was a problem
   performing a requested action.

   GLFailInfo
   encapsulates the glUpdateCert request or response. The glUpdateCert
   control attribute shall have the syntax GLUpdateCert:

   GLUpdateCert ::= SEQUENCE {
     glName    GeneralName,
     error         SEQUENCE SIZE (1..MAX) OF Error,
     glIdentifier  GLIdentifier OPTIONAL }

   ** With multiple GLOs do we want to indicate which GLO asked for the
   action to be performed? **

   Error ::= SEQUENCE {
     errorCode        ErrorCode,
     glMemberName [0] GeneralName OPTIONAL,
     glOwnerName  [1] GeneralName OPTIONAL }

Turner                                                              15
   ErrorCode ::= INTEGER {
     unspecified (0),
     closedGL (1)
     unsupportedDuration (2)
     unsupportedDistribtuionMethod (3),
     invalidCert (4),
     unsupportedAlgorithm (5),
     noGLONameMatch (6),
     invalidGLName (7),
     invalidGLNameGLIdentifierCombination (8),
     nameAlreadyInUse (9),
     noSpam (10),
     deniedAccess (11),
     alreadyAMember (12),
     notAMember (13),
     alreadyAnOwner (14)
     notAnOwner (15)
     glMember  GLMember }

   The fields in GLFailInfo GLUpdateCert have the following meaning:

     - glName indicates the name of the GL to which the error
       corresponds. GL member's new
       certificate should be associated.

     - error glMemberCert indicates the reason why the GLA was unable to perform particulars for the
       request. It also GL member.
       glMemberName indicates the GL member or GLO to which the
       error corresponds. If member's name and glMemberAddress
       indicates the error corresponds to a GL member or
       GLO, a separate Error sequence MUST member's address. certificates.membersPKC
       includes the member's encryption certificate that will be used
       to encrypt the shared KEK for each GL member
       or GLO. that member.
       certificates.membersAC MAY be included to convey any attribute
       certificate associated with the member's encryption certificate.
       certificates.certificationPath MAY also be included to convey
       the certification path corresponding to the member's encryption
       and attribute certificates. The errors are returned under certification path is optional
       because it may already be included elsewhere in the following conditions:

       - unspecified indicates that message
       (e.g., in the outer CMS layer).

Turner                                                              18

3.1.16 GL Key

   The GLA is unable uses glKey to perform distribute the
         requested action but is unwilling to indicate why.

       - closedGL indicates that members can only shared KEK. The glKey message
   MUST be added or deleted signed by the GLO.

       - unsupportedDuration indicates GLA. The glKey control attribute shall have
   the GLA does not support
         generating keys that are valid for syntax GLKey:

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

   The fields in GLKey have the requested duration. following meaning:

     - unsupportedDistribtuionMethod indicates that glName is the GLA does not
         support any name of the requested delivery methods. GL.

     - invalidCert indicates glIdentifier is the member's encryption certificate was
         not verifiable (i.e., signature did not validate, certificate
         present on a CRL, etc.)

       - unsupportedAlgorithm indicates key identifier of the GLA does not support shared KEK. When GL
       members use the
         requested algorithm.

       - noGLONameMatch indicates shared KEK to encrypt data objects for other GL
       members, they place the name glIdentifier in one of the certificates
         used
       RecipientInfo.kekri.kekid.keyIdentifier field. Two options are
       provided to sign generate a request does not match unique key identifier. The first choice
       concatenates the GLA's subject name of the
         registered GLO.

Turner                                                              16
       - invalidGLName indicates from the GLA does not support digital signature
       certificate used to sign the glName
         present in glKey message and counter. The
       second choice concatenates the request.

       - invalidGLNameGLIdentifierCombination indicates GLA's subjectKeyIdentifier, from
       the GLA does
         not support digital signature certificate used to sign the glName glKey
       message, and glIdentifier present in the
         request. a counter. The second choice must be supported.

     - nameAlreadyInUse indicates glkWrapped is the glName GL's wrapped shared KEK. The RecipientInfos
       shall be generated as specified in paragraph 6.2 of CMS [2]. The
       kari RecipientInfo choice MUST be supported. The EncryptedKey
       field, which is already assigned on
         the GLA.

       - noSpam indicates the prospective GL member did not sign the
         request (i.e., if shared KEK, MUST be generated according to
       the name paragraph concerning random number generation in glMembers.glMemberName does not
         match one the
       security considerations of CMS [2].

     - glkAlgorithm identifies the names in algorithm the certificate shared KEK is used to sign the
         request).
       with.

     - alreadyAMember glkNotBefore indicates the prospective GL member is already
         a GL member.

       - notAMember indicates date at which the prospective non-GL member shared KEK is not a GL
         member.

       - alreadyAnOwner indicates
       considered valid. GeneralizedTime values MUST be expressed UTC
       (Zulu) and MUST include seconds (i.e., times are
       YYYYMMDDHHMMSSZ), even where the prospective GLO number of seconds is already a GLO. zero.
       GeneralizedTime values MUST NOT include fractional seconds.

     - notAnOwner glkNotAfter indicates the prospective non-GL member is not a
         GLO.

     - glIdentifier identifies the specific GL. It MAY be omitted if date after which the response shared KEK is a result of a GLUseKEK request otherwise it
       considered invalid. GeneralizedTime values MUST be present.

3.1.12 GLA Query Request

   GLOs use expressed UTC
       (Zulu) and MUST include seconds (i.e., times are
       YYYYMMDDHHMMSSZ), even where the GLQueryRequest to ascertain what type number of GL seconds is zero.
       GeneralizedTime values MUST NOT include fractional seconds.

Turner                                                              19
   If the GLA
   supports.

   GLAQueryRequest ::= SEQUENCE SIZE (1..MAX) OF GLOQuestions

   GLOQuestions ::= INTEGER {
     supportedAlgorithms  (0),
     distributionMethods  (1) }

   The fields glKey message is in GLAQueryRequest have the following meaning:

     - supportedAlgorithms indicates the GLO would like response to know the
       algorithms the a glUseKEK message:

     - The GLA supports MUST generate separate glKey messages for generating and distribution each recipient
       if glUseKEK.glKeyAttributes.recipientMutuallyAware is set to
       FALSE.

     - The GLA MUST generate X number of glKey messages, where X is the
       shared KEK.

     - distributionMethod indicates
       value in glUseKEK.glKeyAttributes.generationCounter.

   If the GLO would like glKey message is in response to know the
       distribution methods the a glRekey message:

     - The GLA supports MUST generate separate glKey messages for distributing the
       shared KEK.

Turner                                                              17

3.1.13 each recipient
       if glRekey.glNewKeyAttributes.recipientMutuallyAware is set to
       FALSE.

     - The GLA Query Response

   GLA's return MUST generate X number of glKey messages, where X is the GLAQueryResponse after receiving a GLAQueryRequest.

   GLAQueryResponse ::= SEQUENCE {
     supportedAlgorithms  SEQUENCE OF AlgorithmIdentifier OPTIONAL,
     distributionMethods  SEQUENCE OF GLDistributionMethod OPTIONAL }

   The fields
       value in GLAQueryResponse have glUseKEK.glKeyAttributes.generationCounter. If the following meaning:

     - supportAlgorithms indicates
       value is zero (0), the algorithm(s) and parameters that GLA supports for generating and distributing MUST generate X number of glKey
       messages, where X is the number of outstanding shared KEK.

     - distributionMethod indicates KEKs for
       the distribution method(s) GL (e.g., if there are two outstanding shared KEK and the GLA
       supports
       generationCounter for distribution the shared KEK.

3.1.14 GL Key

   The GLA uses GLKey glUseKEK message was set to distribute three then
       two glKey messages are generated).

   If the shared KEK.

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

   GLIdentifier ::= CHOICE {
     issuerNameAndCounter    [0] IssuerNameAndCounter,
     keyIdentifierAndCounter [1] KeyIdentifierAndCounter }

   IssuerNameAndCounter ::= SEQUENCE {
     issuer   GeneralName,
     counter  INTEGER }

   KeyIdentifierAndCounter ::= SEQUENCE {
     keyIdentifier SubjectKeyIdentifier,
     counter       INTEGER }

   SubjectKeyIdentifier ::= OCTET STRING

   The fields glKey message was not in GLKey have the following meaning:

     - glName is the name of response to a glRekey or glUseKEK
   (e.g., where the GL. GLA controls rekey):

     - glIdentifier identifies The GLA MUST generate separate glKey messages for each recipient
       if glUseKEK.glNewKeyAttributes.recipientMutuallyAware that set
       up the specific GL on the GLA (the GLA may
       support multiple GLs). Two options are provided. was set to FALSE.

     - The
       issuerNameAndCounter alternative identifies GLA MUST generate X glKey messages prior to the GLA's who

Turner                                                              18
       created duration on
       the last outstanding shared KEK expiring, where X is the
       generationCounter minus one (1).

3.2 Use of CMC, CMS, and a counter. PKIX

   The keyIdentifierAndCounter
       choice identifies following paragraphs outline the GLA's certificate that was used to encrypt use of CMC, CMS, and PKIX.

3.2.1 Protection Layers

   The following paragraphs outline the shared KEK protection required for the GL members and
   control attributes defined herein.

Turner                                                              20

3.2.1.1 Minimum Protection

   At a counter. In either case
       the counter is minimum, a monotonically increasing number. The
       keyIdentifierAndCounter choice SignedData MUST be supported.

     - glkWrapped protect each request and response
   encapsulated in PKIData and PKIResponse. The following is a
   depiction of the GL's wrapped shared KEK. The RecipientInfos
       shall minimum wrappings:

     Minimum Protection
     ------------------
     SignedData
      PKIData or PKIResponse
       controlSequence

   Prior to taking any action on any request or response SignedData(s)
   MUST be generated as specified in paragraph 6.2 of processed according to CMS [2]. The
       kari RecipientInfo choice MUST

3.2.1.2 Additional Protection

   An additional EnvelopedData MAY also be supported. The EncryptedKey
       field, which is used to provide
   confidentiality of the shared KEK, MUST request and response. An additional
   SignedData MAY also be generated according added to provide authentication and integrity
   of the paragraph concerning random number generation in encapsulated EnvelopedData. The following is a depiction of
   the
       security considerations optional additional wrappings:

     Confidentiality Protection     A&I of Confidentiality Protection
     --------------------------     ---------------------------------
     EnvelopedData                  SignedData
      SignedData                     EnvelopedData
       PKIData or PKIResponse         SignedData
        controlSequence                PKIData or PKIResponse
                                        controlSequence

   If an incoming message was encrypted, the corresponding outgoing
   message MUST also be encrypted. All EnvelopedData objects MUST be
   processed as specified in CMS [2].

     - glkAlgorithm identifies

   If the GLO or GL member applies confidentiality to a request, the
   EnvelopedData MUST be encrypted for the algorithm GLA. If the shared KEK GLA is used
       with.

     - glkNotBefore indicates to
   forward the date at which GL member request to the shared KEK is
       considered valid. GeneralizedTime values MUST be expressed
       Greenwich Mean Time (Zulu) and MUST include seconds (i.e., times
       are YYYYMMDDHHMMSSZ), even where GLO, the number of seconds is zero.
       GeneralizedTime values MUST NOT include fractional seconds.

     - glkNotAfter indicates GLA decrypts the date after which
   EnvelopedData, strips the shared KEK is
       considered invalid. GeneralizedTime values MUST be expressed
       Greenwich Mean Time (Zulu) confidentiality layer off, and MUST include seconds (i.e., times
       are YYYYMMDDHHMMSSZ), even where applies its
   own confidentiality layer for the number of seconds is zero.
       GeneralizedTime values MUST NOT include fractional seconds.

3.2 Use of CMC, CMS, GLO.

3.2.2 Combining Requests and PKIX

3.2.1 Protection Layers

3.2.1.1 Minimum Protection

   At a minimum, a SignedData MUST protect each request Responses

   Mutlipe requests and response
   encapsulated 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.
   PKIResponse.cmsSequence. A separate cmsSequence MUST be used for

Turner                                                              21
   different GLs (i.e., requests corresponding to two different GLs are
   included in different cmsSequences). The following is a
   depiction of the minimum wrappings:

     Minimum Protection
     ------------------ diagram
   depicting multiple requests and responses combined in one PKIData
   and PKIResponse:

         Multiple Request and Response
     Request                        Response
     -------                        --------
     SignedData                      SignedData
      PKIData                         PKIResponse
       cmsSequence                     cmsSequence
        SignedData                      SignedData
         PKIData or                         PKIResponse
          controlSequence

   Prior                 controlSequence
           Zero or more requests          Zero or more responses
           corresponding to taking any action on any request one GL.        corresponding to one GL.
        SignedData                      SignedData
         PKIData                         PKIResponse
          controlSequence                 controlSequence
           Zero or response SignedData(s)
   MUST be processed according more requests          Zero or more responses
           corresponding to CMS [2].

Turner                                                              19

3.2.1.2 Additional Protection

   An additional EnvelopedData MAY also be used another GL.   corresponding to provide another GL.

   When applying confidentiality of the request and response. An additional
   SignedData MAY also be added to provide authentication multiple requests and integrity responses,
   all of the encapsulated requests/response MAY be included in one EnvelopedData.
   The following is a depiction of
   the optional additional wrappings: depiction:

       Confidentiality Protection     A&I of Confidentiality Protection
     --------------------------     --------------------------------- Multiple Requests and Responses
     Wrapped Together
     ----------------
     EnvelopedData
      SignedData
      SignedData                     EnvelopedData
       PKIData or PKIResponse
        cmsSequence
         SignedData
          PKIResponse
           controlSequence                PKIData
            Zero or PKIResponse more requests
            corresponding to one GL.
         SignedData
          PKIData
           controlSequence

   If an incoming message was encrypted, the
            Zero or more requests
            corresponding outgoing
   message to one GL.

Turner                                                              22
   Certain combinations of requests in one PKIData.controlSequence and
   one PKIResponse.controlSequence are not allowed. The invalid
   combinations listed here MUST also NOT be encrypted. All EnvelopedData objects MUST generated:

        Invalid Combinations
     ---------------------------
     glUseKEK   & glDeleteMember
     glUseKEK   & glRekey
     glUseKEK   & glDelete
     glDelete   & glAddMember
     glDelete   & glDeleteMember
     glDelete   & glRekey
     glDelete   & glAddOwner
     glDelete   & glRemoveOwner
     glFailInfo & glKey

   To avoid unnecessary errors, certain requests and responses should
   be processed prior to others. The following is the priority of
   message processing, if not listed it is an implementation decision
   as specified in CMS [2].

   If to which to process first: glUseKEK before glAddMember, glRekey
   before glAddMember, and glDeleteMember before glRekey.

3.2.3 GLA Generated Messages

   When the GLO or GLA generates a glSuccessInfo, it generates one for each
   request. action.actionCode values of assignedKEK, deletedGL,
   rekeyedGL, addedGLO, and deletedGLO are not returned to GL members.
   Likewise, when the GLA generates glFailInfo it generates one each
   request. error values of unsupportedDuration,
   unsupportedDeliveryMethod, unsupportedAlgorithm, noGLONameMatch,
   nameAlreadyInUse, alreadyAnOwner, notAnOwner are not returned to GL member applies confidentiality
   members.

   If GLKeyAttributes.recipientMutuallyAware is set to FALSE, a request, the
   EnvelopedData
   separate PKIResponse.glSucessInfo, PKIResponse.glFailInfo, and
   PKIData.glKey MUST be encrypted generated for the GLA. each recipient.

   If the GLA is supposed
   to forward the GL member request GLO, has multiple GLOs, the GLA decrypts the
   EnvelopedData, strips MUST send the confidentiality layer off, glSuccessInfo and applies its
   own confidentiality layer for
   glFailInfo messages to the requesting GLO.

3.2.2 Combining Requests and Responses

   Multiple requests and responses MAY be combined in one PKIData or
   PKIResponse by using PKIData.cmsSequence and
   PKIResponse.cmsSequence. A separate cmsSequence MUST be used for
   different GLs (i.e., requests corresponding to two different GLs are
   included in different cmsSequences). The following mechanism another GLO
   to determine which GLO made the request is a diagram
   depicting multiple requests and responses combined in one PKIData
   and PKIResponse: beyond the scope of this
   document.

Turner                                                              20
         Multiple Request                                                              23
   If a GL is managed and Response
     Request                        Response
     -------                        --------
     SignedData                      SignedData
      PKIData                         PKIResponse
       cmsSequence                     cmsSequence
        SignedData                      SignedData
         PKIData                         PKIResponse
          controlSequence                 controlSequence
           Zero or more requests          Zero the GLA receives a glAddMember,
   glDeleteMember, or more responses
           corresponding to one GL.        corresponding glkCompromise message, the GLA redirects the
   request to one GL. the GLO for review. An additional, SignedData MUST be
   applied to the redirected request as follows:

     GLA Forwarded Requests
     ----------------------
     SignedData
      PKIData                         PKIResponse
          controlSequence
        cmsSequence
          PKIData
            controlSequence
           Zero or more requests          Zero or more responses
           corresponding to one GL.        corresponding

3.2.4 CMC Control Attributes

   Certain control attributes defined in CMC [3] are allowed; they are
   as follows: cMCStatusInfo, transactionId, senderNonce,
   recipientNonce, and queryPending.

   cMCStatusInfo is used by GLAs to one GL.

   When applying confidentiality indicate to multiple requests GLOs and responses,
   either each GL members
   whether a request was or was not successfully completed. If the
   request or was successful, the GLA returns a cMCStatusInfo response MAY be encrypted individually or all
   of
   with cMCStatus.success and optionally other pertinent information in
   stutsString. If the requests/response MAY be included response was not successful, the GLA returns a
   cMCStatusInfo response with cMCStatus.failed and optionally other
   pertinent information in one EnvelopedData. The
   following statusString.

   When the GL is a depiction of managed and the choices using PKIData:

       Confidentiality of Multiple Requests GLO has reviewed GL member initiated
   glAddMember, glDeleteMember, and Responses
     Individually Wrapped            Wrapped Together
     --------------------            ----------------
     SignedData                      EnvelopedData
      PKIData                         SignedData
       cmsSequence                     PKIData
        EnvelopedData                   cmsSequence
         SignedData                      SignedData
          PKIData                         PKIResponse
           controlSequence                 controlSequence
            Zero or more requests          Zero or more requests
            corresponding to one GL.        corresponding glkComrpomise requests, the GLO
   uses cMCStatusInfo to one GL.
        EnvelopedData                    SignedData
         SignedData                       PKIData
          PKIData                          controlSequence
           controlSequence                  Zero or more requests
            Zero indicate the success or more requests          corresponding failure of the
   request. If the request is allowed, cMCStatus.success is returned
   and statusString is optionally returned to one GL.
            corresponding convey additional
   information. If the request is denied, cMCStatus.failed is returned
   and statusString is optionally returned to one GL.

Turner                                                              21
   Certain combinations of requests in one PKIData.controlSequence convey additional
   information.

   cMCStatusInfo is used by GLOs, GLAs, and
   one PKIResponse.controlSequence are not allowed. The invalid
   combinations listed here GL members to indicate that
   signature verification failed. If the signature failed to verify,
   the cMCStatusInfo control attribute MUST NOT be generated:

        Invalid Combinations
     ---------------------------
     GLUseKEK   & GLDeleteMembers
     GLUseKEK   & GLRekey
     GLUseKEK   & GLDelete
     GLDelete   & GLAddMembers
     GLDelete   & GLDeleteMembers
     GLDelete   & GLRekey
     GLDelete   & GLAddOwners
     GLDelete   & GLRemoveOwners
     GLFailInfo & GLKey

   To avoid unnecessary errors, certain requests 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.

   [Not sure the above is completely correct.]

   cMCStatusInfo is also used by GLOs and responses should GLAs to indicate that a
   request could not be performed immediately. If the request could not
   be processed prior immediately by the GLA or GLO, the cMCStatusInfo
   control attribute MUST be returned indicating cMCStatus.pending and
   otherInfo.pendInfo. When requests are redirected to others. The following the GLO for

Turner                                                              24
   approval (for managed lists), the GLA MUST NOT return a
   cMCStatusInfo indicating query pending.

   cMCStatusInfo is also used by GLAs to indicate that a
   glaQueryRequest is not supported. If the priority of
   message processing, if glaQueryRequest is not listed it
   supported, the cMCStatusInfo control attribute MUST be returned
   indicating cMCStatus.noSupport and statusString is an implementation decision
   as optionally
   returned to which convey additional information.

   transactionId MAY be included by GLOs, GLAs, or GL members to process first: GLUseKEK before GLAddMembers,
   GLAddMembers before GLRekey, GLDeleteMembers before GLRekey,
   identify a given transaction. All subsequent requests and
   GLSuccessInfo before GLKey.

   ** Need responses
   related to think more about the priority of processing **

3.2.3 original request MUST include the same transactionId
   control attribute. If GL members include a transactionId and the
   request is redirected to the GLO, the GLA Generated Messages

   When MAY include an additional
   transactionId in the outer PKIData. If the GLA included an
   additional transactionId in the outer PKIData, when the GLO
   generates a GLSuccessInfo, cMCStatusInfo response it generates one for the GLA with
   the GLA's transactionId and one for the GL member with the GL
   member's transactionId.

   senderNonce and another recipientNonce (see paragraph 5.6 of [3]) MAY be
   used to provide application-level replay prevention. Originating
   messages include only a value for senderNonce. If a message includes
   a senderNonce, the response MUST include the transmitted value of
   the previously received senderNonce as recipientNonce and include a
   new value for senderNonce. If GL members include a senderNonce and
   the request is redirected to the GLO, depending on the actionCode.
   action.actionCode values of assignedKEK, deletedGL, rekeyedGL,
   addedGLO, and deletedGLO are not returned to GL members. Likewise, GLA MAY include an
   additional senderNonce in the outer PKIData. If the GLA included an
   additional senderNonce in the outer PKIData, when the GLO generates GLFailInfo it
   the response:

     - It generates one for the GL member GLA by including the senderNonce from
       the GLA as the recipientNonce and includes a new value for
       senderNonce

     - It generates one for the GLO, depending on GL member by including the senderNonce
       from the actionCode. error values of
   unsupportedDuration, unsupportedDeliveryMethod,
   unsupportedAlgorithm, noGLONameMatch, nameAlreadyInUse,
   alreadyAnOwner, notAnOwner are not returned to GL members.

   Separate GLSucessInfo, GLFailInfo, member as the recipientNonce and GLKey messages includes a new
       value for senderNonce. The value of this senderNonce MUST be
   generated for each recipient if GL was setup with
   GLKeyAttributes.recipientMutuallyAware set to FALSE.

   If
       different than the GL has multiple GLOs, value in the GLA MUST send a copy of all
   GLSuccessInfo and GLFailInfo messages senderNonce returned to each GLO.

   If a GL the GLA.

   The following is managed and the GLA receives a prospective GL member add
   or delete request or implementation requirement for the CMC control
   attributes:

           Implementation Requirement         |   Control
     GLO receives a GLFailInfo from the GL. and    |        GLA          | GL Member |  Attribute
   O    R   | O      R       F    | O    R    |
   -------- | ------------------  | --------- | ----------
   MUST MUST| MUST   MUST    N/A  | MUST MUST | cMCStatus
   MAY  MAY | MAY    MAY     N/A  | MAY  MAY  | transactionId
   MAY  MAY | MAY    MAY     N/A  | MAY  MAY  | senderNonce
   MAY  MAY | MAY    MAY     N/A  | MAY  MAY  | recepientNonce

Turner                                                              25

3.2.5 Resubmitted GL Member Messages

   When the GL is managed, managed the GLA forwards the request GL member requests to the
   GLO for
   review. An additional, SignedData MUST be applied to GLO approval. If the GLO approves the forwarded request as follows:

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

3.2.4 CMC Control Attributes

   ** Elaborate more **

   Can use:

   CMCFailInfo.badMessageCheck - To indicate it reforms the
   glAddMember, glDeleteMember, or glkCompromise message by stripping
   of the GL member's signature did not verify.

   transactionId - To track particular requests/responses.

   senderNonce and recipientNonce - For sequence integrity.

3.2.5 resigning the request.

3.2.6 PKIX

   Signatures, certificates, and CRLs are verified according to PKIX
   [5].
   [6].

   Name matching is performed according to PKIX [5]. [6].

4 Administrative Messages

   There are a number of administrative messages that must be performed
   to manage a GL: creating the GL, deleting the GL, adding members to
   the GL, deleting members from the GL, and requesting a group rekey. GL. The following sections describe each of messages'
   request and response combinations in detail. The GLKRefresh procedures defined
   in this paragraph 4.8 SHOULD be implemented all other procedures MAY be
   implemented. are not prescriptive.

4.1 Assign KEK To GL

   Prior to generating a group key, a GL MUST be setup. setup and a shared KEK
   assigned to the GL. Figure 3 depicts the protocol interactions to
   setup and assign a GL. shared KEK. Note that error messages are not
   depicted in Figure 3.

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

                Figure 3 - Create Group List

Turner                                                              23

   The process is as follows:

     1 - The GLO is the entity responsible for requesting the creation
         of the GL. The GLO sends a
         SignedData.PKIData.controlSequence.GLUseKEK
         SignedData.PKIData.controlSequence.glUseKEK request to the GLA
         (1 in Figure 3). The GLO MUST include: glName, glOwner,
         glAdministration, distributionMethod. glAddress,
         glOwnerName, glOwnerAddress, and glAdministration. The GLO MAY
         also include their preferences for the shared KEK in
         glKeyAttributes by indicating whether the GLO controls the
         rekey in rekeyControlledByGLO, whether separate GLKey glKey messages
         should be sent to each recipient in recipientMutuallyAware,
         the requested algorithm to be used with the shared KEK in
         requestedAlgorithm, the duration of the shared KEK, and how

Turner                                                              26
         many shared KEKs should be initially distributed in duration
         and generationCounter, respectively.

       a
         generationCounter.

     1.a - If the GLO knows of members to be added to the GL, the
           GLAddMembers
           glAddMember request MAY be included in the same
           controlSequence as the GLUseKEK glUseKEK request (see paragraph
           3.2.2). The GLO MUST indicate the same glName in the
           GLAddMembers
           glAddMember request as in GLUseKEK.glName. The GLO MUST
           also include the member's encryption certificate in
           certificate.membersPKC. The GLO MAY also include any
           attribute certificates associated with the member's
           encryption certificate in membersAC and the certification
           path for the member's encryption and attribute certificates.
           The GLO MUST omit the glIdentifier, as it is unknown at this
           point glUseKEK.glInfo.glName. Further
           glAddMember procedures are covered in the setup procedure.

       b paragraph 4.3.

     1.b - The GLO MAY optionally apply confidentiality to the request
           by encapsulating the SignedData.PKIData in an EnvelopedData
           (see paragraph 3.2.1.2).

       c

     1.c - The GLO MAY also optionally apply another SignedData over
           the EnvelopedData (see paragraph 3.2.1.2).

     2 - Upon receipt of the request, the GLA verifies the signature on
         the inner most SignedData.PKIData. If an additional SignedData
         and/or EnvelopedData encapsulates the request (see paragraph paragraphs
         3.2.1.2 or and 3.2.2), the GLA MUST verify the outer signature signature(s)
         and/or decrypt the outer layer layer(S) prior to verifying the
         signature on the inner most SignedData.

       a

     2.a - If the signature(s) does(do) not verify, the GLA MUST return
           a cMCStatusInfo response indicating CMCFailInfo.badMessageCheck.

       b cMCStatus.failed and
           otherInfo.failInfo.badMessageCheck.

     2.b - If the signature(s) does(do) verify, verify but the GLA does not
           have a valid certificate, the GLA MUST return a
           glFailInfo.errorCode.noValidGLACertificate.

     2.c - If the signature(s) does(do) verify and the GLA does have a
           valid certificate, the GLA MUST check that one of the names
           in the certificate used to sign the request matches one of
           the name names in CreateGL.glOwner.

Turner                                                              24
         1 glUseKEK.glOwnerInfo.glOwnerName.

     2.c.1 - If the names do not match, the GLA MUST return a response
             indicating GLFailInfo.errorCode.noGLONameMatch.

         2 glFailInfo.errorCode.noGLONameMatch.

     2.c.2 - If names do all match, the GLA MUST ensure the combination
             of the requested
             glName is not already in use. The GLA MUST also check any GLAddMembers
             glAddMember included within the controlSequence with this GLCreate.
             glUseKEK. Further processing of the GLAddMembers glAddMember is covered
             in paragraph 4.3.

           a

     2.c.2.a - If the glName is already in use the GLA MUST return a
               response indicating
               GLFailInfo.errorCode.nameAlreadyInUse.

           b
               glFailInfo.errorCode.nameAlreadyInUse.

Turner                                                              27
     2.c.2.b - If the requestedAlgorithm is not supported, the GLA MUST
               return a response indicating
               GLFailInfo.errorCode.unsupportedAlgorithm.

           c
               glFailInfo.errorCode.unsupportedAlgorithm.

     2.c.2.c - If the duration is not supportable, determining this is
               beyond the scope of this document, the GLA MUST return a
               response indicating
               GLFailInfo.errorCode.unsupportedDuration.

           d
               glFailInfo.errorCode.unsupportedDuration.

     2.c.2.d - If the glAdministration is set to closed (0) and there
               is more than one GLO in glOwner, the GLA MUST return a
               response indicating
               glFailInfo.errorCode.onlyOneGLOAllowed.

     2.c.2.e - If the GL is not supportable for other reasons, which
               the GLA does not wish to disclose, the GLA MUST return a
               response indicating GLFailInfo.errorCode.unspecified.

           e glFailInfo.errorCode.unspecified.

     2.c.2.f - If the glName distribution is not already in use, the duration is
               supportable, and the requestedAlgorithm is supported,
               the GLA MUST return a GLSuccessInfo to all
               GLOs glSuccessInfo indicating the
               glName, the corresponding glIdentifier, and an
               action.actionCode.assignedKEK (2 in Figure 3). The GLA
               also takes administrative actions, which are beyond the
               scope of this document, to store the glName, distributionMethod, glOwner, glAddress,
               glKeyAttributes, glOwnerName, and any member
               that has been added.

             1 glOwnerAddress. The
               GLA also sends a glKey message as described in paragraph
               5.

     2.c.2.f.1 - The GLA MUST apply confidentiality to the response by
                 encapsulating the SignedData.PKIResponse in an
                 EnvelopedData if the request was encapsulated in an
                 EnvelopedData (see paragraph 3.2.1.2).

             2

     2.c.2.f.2 - The GLA MAY also optionally apply another SignedData
                 over the EnvelopedData (see paragraph 3.2.1.2).

     3 - Upon receipt of the GLSuccessInfo glSuccessInfo or GLFailInfo glFailInfo responses, the
         GLO verifies the GLA's signature(s). If an additional
         SignedData and/or EnvelopedData encapsulates the response (see
         paragraph 3.2.1.2 or 3.2.2), the GLO MUST verify the outer
         signature and/or decrypt the outer layer prior to verifying
         the signature on the inner most SignedData.

Turner                                                              25
       a SignedData.

     3.a - If the signatures do not verify, the GLO MUST return a
           cMCStatusInfo response indicating CMCFailInfo.badMessageCheck.

       b cMCStatus.failed and
           otherInfo.failInfo.badMessageCheck.

     3.b - If the signatures do verify and the response was
           GLSuccessInfo,
           glSuccessInfo, the GLO has successfully created the GL.

       c

Turner                                                              28
     3.c - If the signatures do verify and the response was GLFailInfo, glFailInfo,
           the GLO MAY reattempt to create the GL using the information
           provided in the GLFailInfo glFailInfo response. The GLO may also use
           the GLAQueryRequest glaQueryRequest to determine the algorithms and
           distribution methods other
           characteristics supported by the GLA (see paragraph 4.9).

4.2 Delete GL From GLA

   From time to time, there are instances when a GL is no longer
   needed. In this case the GLO must delete the GL. Figure 4 depicts
   that protocol interactions to delete a GL.

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

                 Figure 4 - Delete Group List

   The process is as follows:

     1 - The GLO is the entity responsible for requesting the deletion
         of the GL. The GLO sends a
         SignedData.PKIData.controlSequence.GLDelete
         SignedData.PKIData.controlSequence.glDelete request to the GLA
         (1 in Figure 4). The GLO MUST include the name of the GL to be deleted MUST be
         included in
         glName. The GLO MAY also include the GL identifier
         glIdentifier.

       b GeneralName.

     1.a - The GLO MAY optionally apply confidentiality to the request
           by encapsulating the SignedData.PKIData in an EnvelopedData
           (see paragraph 3.2.1.2).

       c

     1.b - The GLO MAY also optionally apply another SignedData over
           the EnvelopedData (see paragraph 3.2.1.2).

     2 - Upon receipt of the request the GLA verifies the signature on
         the inner most SignedData.PKIData. If an additional SignedData
         and/or EnvelopedData encapsulates the request (see paragraph
         3.2.1.2 or 3.2.2), the GLA MUST verify the outer signature
         and/or decrypt the outer layer prior to verifying the
         signature on the inner most SignedData.

       a

     2.a - If the signature(s) does(do) not verify, the GLA MUST return
           a cMCStatusInfo response indicating CMCFailInfo.badMessageCheck.

Turner                                                              26
       b cMCStatus.failed and
           otherInfo.failInfo.badMessageCheck.

     2.b - If the signature(s) does(do) verify, the GLA MUST make sure
           the GL is supported by checking either that the glName is
           supported (in the case the glIdentifier is omitted) or that the combination of glName and glIdentifier GL's Name matches a
           glName
           and glIdentifier combination stored on the GLA.

         1

Turner                                                              29
     2.b.1 - If the glIdentifier is omitted and the glName is not supported by the GLA, the GLA MUST
             return a response indicating GLFailInfo.errorCode.invalidGLName.

         2 - If the glName and glIdentifier are present and do not
             match a GL stored on the GLA, the GLA MUST return a
             response indicating
             GLFailInfo.errorCode.invalidGLNameGLIdentifierCombination.

         3
             glFailInfo.errorCode.invalidGLName.

     2.b.2 - If the glIdentifier is omitted and the glName is supported by the GLA or if the glIdentifier/glName combination is
             supported by the GLA, the GLA MUST ensure
             a registered GLO signed the GLDelete glDelete request by checking
             if one of the name names present in the digital signature
             certificate used to sign the GLDelete glDelete request matches one of the registered GLOs. a
             registered GLO.

     2.b.2.a - If the names do not match, the GLA MUST return a
               response indicating GLFailInfo.errorCode.noGLONameMatch.

           b glFailInfo.errorCode.noGLONameMatch.

     2.b.2.b - If the names do match but the GL is not deletable for
               other reasons, which the GLA does not wish to disclose,
               the GLA MUST return a response indicating
               GLFailInfo.errorCode.unspecified.

           c
               glFailInfo.errorCode.unspecified. Actions beyond the
               scope of this document must then be taken to delete the
               GL from the GLA.

     2.b.2.c - If all the names do match, the GLA MUST return to all
               the GLOs a GLSucessInfo
               glSuccessInfo indicating the glName, the
               corresponding glIdentifier, and an
               action.actionCode.deletedGL (2 in Figure 4).
               glMemberName and glOwnerName MUST be omitted. The GLA
               MUST not accept further requests for member additions,
               member deletions, or group rekeys for this GL.

             1

     2.b.2.c.1 - The GLA MUST apply confidentiality to the response by
                 encapsulating the SignedData.PKIResponse in an
                 EnvelopedData if the request was encapsulated in an
                 EnvelopedData (see paragraph 3.2.1.2).

             2

     2.b.2.c.2 - The GLA MAY also optionally apply another SignedData
                 over the EnvelopedData (see paragraph 3.2.1.2).

     3 - Upon receipt of the GLSuccessInfo glSuccessInfo or GLFailInfo glFailInfo response, the
         GLO verifies the GLA's signature(s). If an additional
         SignedData and/or EnvelopedData encapsulates the response (see
         paragraph 3.2.1.2 or 3.2.2), the GLO MUST verify the outer
         signature and/or decrypt the outer layer prior to verifying
         the signature on the inner most SignedData.

Turner                                                              27
       a

     3.a - If the signature(s) does(do) not verify, the GLO MUST return
           a cMCStatusInfo response indicating CMCFailInfo.badMessageCheck.

       b cMCStatus.failed and
           otherInfo.failInfo.badMessageCheck.

     3.b - If the signatures do verify and the response was
           GLSuccessInfo,
           glSuccessInfo, the GLO has successfully deleted the GL.

       c

     3.c - If the signatures do verify and the response was GLFailInfo, glFailInfo,
           the GLO MAY reattempt to delete the GL using the information
           provided in the GLFailInfo glFailInfo response.

Turner                                                              30

4.3 Add Members To GL

   To add members to GLs, either the GLO or prospective members use the
   GLAddMembers
   glAddMember request. There are however different scenarios that
   should be supported. Either the GLO or prospective members may
   submit the GLAddMembers request to the GLA, but the The GLA processes
   the requests differently. The GLO and prospective GL member
   requests differently though. GLOs can submit the request at any time
   to add members to the GL, and the GLA, once it has verified the
   request came from the GLO a registered GLO, should process it. If a
   prospective member sends the request, the GLA needs to determine how
   the GL is administered. When the GLO initially configured the GL,
   they set the GL to be unmanaged, managed, or closed (see paragraph
   3.1.1). In the unmanaged case, the GLA merely processes the member's
   request. For the managed case, the GLA forwards the requests from
   the prospective members to the GLO. 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 paragraphs describe the processing required by for the GLO,
   GLO(s), GLA, and prospective GL members depending on where the
   glAddMeber request originated, either from the a GLO or from prospective
   members. Figure 5 depicts the protocol interactions for the three
   options. Note that the error messages are not depicted.

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

                   Figure 5 - Member Addition

   An important decision that needs to be made on a group by group
   basis is whether to rekey the group every time a new member is

Turner                                                              28
   added. Typically, unmanaged GLs should not be rekeyed when a new
   member is added, as the overhead associated with rekeying the group
   becomes prohibitive, as the group becomes large. However, managed
   and closed GLs MUST be rekeyed to maintain the secrecy of the group.
   An option to rekeying the 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 paragraphs 4.5 and 5.

Turner                                                              31

4.3.1 GLO Initiated Additions

   The process for GLO initiated GLAddMembers glAddMember requests is as follows:

     1 - The GLO collects the names and pertinent information for the
         members member(s)
         to be added (this MAY be done through an out of bands means).
         The GLO then sends a
         SignedData.PKIData.controlSequence.GLAddMembers SignedData.PKIData.controlSequence with a
         separate glAddMember request for each member to the GLA (1 in
         Figure 5). The GLO MUST include: the GL name in glName, the
         member's name in glMembers.glMemberName, glMember.glMemberName, the member's address
         in glMember.glMemberAddress, and the member's encryption
         certificate in
         glMembers.certificates.membersPKC. glMember.certificates.membersPKC. The GLO MAY
         also include
         the GL identifier in glIdentifier, if known, any attribute certificates associated with the
         member's encryption certificate in glMembers.certificates.membersAC,
         glMember.certificates.membersAC, and the certification path
         associated with the member's encryption and attribute
         certificates in
         glMembers.certificates.certificationPath.

       a glMember.certificates.certificationPath.

     1.a - The GLO MAY optionally apply confidentiality to the request
           by encapsulating the SignedData.PKIData in an EnvelopedData
           (see paragraph 3.2.1.2).

       b

     1.b - The GLO MAY also optionally apply another SignedData over
           the EnvelopedData (see paragraph 3.2.1.2).

     2 - Upon receipt of the request, the GLA verifies the signature on
         the inner most SignedData.PKIData. If an additional SignedData
         and/or EnvelopedData encapsulates the request (see paragraph
         3.2.1.2 or 3.2.2), the GLA MUST verify the outer signature
         and/or decrypt the outer layer prior to verifying the
         signature on the inner most SignedData.

       a

     2.a - If the signature(s) does(do) not verify, the GLA MUST return
           a cMCStatusInfo response indicating CMCFailInfo.badMessageCheck.

       b cMCStatus.failed and
           otherInfo.failInfo.badMessageCheck.

     2.b - If the signature(s) does(do) verify, the GLAddMembers glAddMember request
           is included in a controlSequence with the GLUseKEK glUseKEK request,
           and the processing of 2.b.2 in paragraph 4.1 item 2.e is successfully
           completed the GLA MUST return to all GLOs a GLSuccessInfo glSuccessInfo indicating the
           glName, the corresponding glIdentifier, an
           action.actionCode.addedMember, and action.glMemberName (2 in

Turner                                                              29
           Figure 5). The response MUST be constructed as specified in
           paragraph 3.2.3.

         1

     2.b.1 - The GLA MUST apply confidentiality to the response by
             encapsulating the SignedData.PKIData in an EnvelopedData
             if the request was encapsulated in an EnvelopedData (see
             paragraph 3.2.1.2).

         2

     2.b.2 - The GLA MAY also optionally apply another SignedData over
             the EnvelopedData (see paragraph 3.2.1.2).

       c

Turner                                                              32
     2.c - If the signature(s) does(do) verify and the GLAddMember
           request is not included in a controlSequence with the
           GLCreate request, the GLA MUST make sure the GL is supported
           by checking either that the glName is supported (in the case
           the glIdentifier is omitted) or that the combination of glName and glIdentifier matches a glName and glIdentifier stored on the
           GLA.

         1

     2.c.1 - If the glIdentifier is omitted and the glName is not supported by the GLA, the GLA MUST
             return a response indicating GLFailInfo.errorCode.invalidGLName.

         2 - If the glName and glIdentifier are present and do not
             match a GL stored on the GLA, the GLA MUST return a
             response indicating
             GLFailInfo.errorCode.invalidGLNameGLIdentifierCombination.

         3
             glFailInfo.errorCode.invalidGLName.

     2.c.2 - If the glIdentifier is omitted and the glName is supported by the GLA or if the glIdentifier/glName combination is
             present and supported, GLA, the GLA MUST check
             to see if the glMemberName is present on the GL.

           a

     2.c.2.a - If the glMemberName is present on the GL, the GLA MUST
               return a response indicating
               GLFailInfo.errorCode.alreadyAMember.

           b
               glFailInfo.errorCode.alreadyAMember.

     2.c.2.b - If the glMemberName is not present on the GL, the GLA
               the GLA
               MUST check how the GL is administered.

             1

     2.c.2.b.1 - If the GL is closed, the GLA MUST check 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 one of the registered GLOs. a registered GLO.

     2.c.2.b.1.a - If the names do not match, the GLA MUST return a
                   response indicating
                   GLFailInfo.errorCode.noGLONameMatch.

               b
                   glFailInfo.errorCode.noGLONameMatch.

     2.c.2.b.1.b - If the names do match, the GLA MUST verify the
                   member's encryption certificate.

Turner                                                              30
                 1

     2.c.2.b.1.b.1 - If the member's encryption certificate does not
                     verify, the GLA MUST MAY return a response indicating
                     GLFailInfo.errorCode.invalidCert.

                 2
                     glFailInfo.errorCode.invalidCert to the GLO. If
                     the GLA does not return a glFailInfo response, the
                     GLA MUST issue a glProvideCert request (see
                     paragraph 4.10).

     2.c.2.b.1.b.2 - If the member's certificate does verify, the GLA
                     MUST return to all GLOs a GLSuccessInfo glSuccessInfo to the GLO indicating
                     the glName, the corresponding glIdentifier, an
                     action.actionCode.addedMember, and
                     action.glMemberName (2 in Figure 5). The response
                     MUST be constructed as in paragraph 3.2.3. The GLA also
                     takes administrative actions, which are beyond the
                     scope of this document, to add the member with to the
                     GL stored on the GLA. The GLA will MUST also distribute
                     the shared KEK to the member via the mechanism
                     described in paragraph 5.

                   a

     2.c.2.b.1.b.2.a - The GLA MUST apply confidentiality to the
                       response by encapsulating the SignedData.PKIData

Turner                                                              33
                       in an EnvelopedData if the request was
                       encapsulated in an EnvelopedData (see paragraph
                       3.2.1.2).

                   b

     2.c.2.b.1.b.2.b - The GLA MAY also optionally apply another
                       SignedData over the EnvelopedData (see paragraph
                       3.2.1.2).

             2

     2.c.2.b.2 - If the GL is managed, the GLA MUST check that either
                 the a
                 registered GLO or the prospective member signed the
                 request. For the GLO, GLOs, one of the names in the certificate
                 used to sign the request MUST match one of the a registered
                 GLOs. GLO.
                 For the prospective member, the name in
                 glMembers.glMemberName
                 glMember.glMemberName MUST match one of the names in
                 the certificate used to sign the request.

              a _

     2.c.2.b.2.a - If the signer is neither a registered GLO or nor the
                   prospective GL member, the GLA MUST return a
                   response indicating GLFailInfo.errorCode.noSpam.

              b glFailInfo.errorCode.noSpam.

     2.c.2.b.2.b - If the signer is the a registered GLO, the GLA MUST
                   verify the member's encryption certificate.

                 1

     2.c.2.b.2.b.1 - If the member's certificate does not verify, the
                     GLA MUST MAY return a response indicating
                     GLFailInfo.errorCode.invalidCert.

                 2
                     glFailInfo.errorCode.invalidCert. If the GLA does
                     not return a glFailInfo response, the GLA MUST
                     issue a glProvideCert request (see paragraph
                     4.10).

     2.c.2.b.2.b.2 - If the member's certificate does verify, the GLA
                     MUST return to all GLOs GLSuccessInfo glSuccessInfo indicating the glName,
                     the corresponding glIdentifier, an
                     action.actionCode.addedMember, and
                     action.glMemberName to the GLO (2 in Figure 5).
                     The response MUST be constructed as in paragraph
                     3.2.3. The GLA also takes administrative actions,

Turner                                                              31 which
                     are beyond the scope of this document, to add the
                     member with to the GL stored on the GLA. The GLA will MUST
                     also distribute the shared KEK to the member via
                     the mechanism described in paragraph 5.

                   a

     2.c.2.b.2.b.2.a - The GLA MUST apply confidentiality to the
                       response by encapsulating the SignedData.PKIData
                       in an EnvelopedData if the request was
                       encapsulated in an EnvelopedData (see paragraph
                       3.2.1.2).

                   b

     2.c.2.b.2.b.2.b - The GLA MAY also optionally apply another
                       SignedData over the EnvelopedData (see paragraph
                       3.2.1.2).

               c

Turner                                                              34
     2.c.2.b.2.c - If the signer is the prospective member, the GLA
                   forwards
                   MUST forward the GLAddMembers glAddMember request (see paragraph
                   3.2.3) to the a registered GLO (B{A} in Figure 5). Which If
                   there is more than one registered GLO, the GLO to
                   which the request is forwarded to is beyond the
                   scope of this document. Further processing of the
                   forwarded request by the GLO GLOs is addressed in 3 of
                   paragraph 4.3.2.

                 1

     2.c.2.b.2.c.1 - The GLA MUST apply confidentiality to the
                     forwarded request by encapsulating the
                     SignedData.PKIData in an EnvelopedData if the
                     original request was encapsulated in an
                     EnvelopedData (see paragraph 3.2.1.2).

                 2

     2.c.2.b.2.c.2 - The GLA MAY also optionally apply another
                     SignedData over the EnvelopedData (see paragraph
                     3.2.1.2).

             3

     2.c.2.b.3 - If the GL is unmanaged, the GLA MUST check that either
                 the
                 a registered GLO or the prospective member signed the
                 request. For the GLO, GLOs, one of the names in the certificate
                 used to sign the request MUST match one of match the name of a
                 registered
                 GLOs. GLO. For the prospective member, the name
                 in
                 glMembers.glMemberName glMember.glMemberName MUST match one of the names
                 in the certificate used to sign the request.

               a

     2.c.2.b.3.a - If the signer is not the neither a registered GLO or nor the
                   prospective member, the GLA MUST return a response
                   indicating
                   GLFailInfo.errorCdoe.noSpam.

               b glFailInfo.errorCode.noSpam.

     2.c.2.b.3.b - If the signer is either the a registered GLO or the
                   prospective member, the GLA MUST verify the member's
                   encryption certificate.

                 1

     2.c.2.b.3.b.1 - If the member's certificate does not verify, the
                     GLA MUST MAY return a response indicating
                     GLFailInfo.errorCode.invalidCert.

Turner                                                              32
                 2
                     glFailInfo.errorCode.invalidCert to either the GLO
                     or the prospective member depending on where the
                     request originated. If the GLA does not return a
                     glFailInfo response, the GLA MUST issue a
                     glProvideCert request (see paragraph 4.10) to
                     either the GLO or prospective member depending on
                     where the request originated.

     2.c.2.b.3.b.2 - If the member's certificate does verify, the GLA
                     MUST return a GLSucessInfo glSuccessInfo indicating the glName,
                     the corresponding glIdentifier, an
                     action.actionCode.addedMember, and
                     action.glMemberName to the GLO (2 in Figure 5) if
                     the GLO signed the request and to the GL member (3
                     in Figure 5) if the GL member signed the request.
                     The response MUST be constructed as in paragraph
                     3.2.3.

Turner                                                              35
                     The GLA also takes administrative actions, which
                     are beyond the scope of this document, to add the
                     member with to the GL stored on the GLA. The GLA will MUST
                     also distribute the shared KEK shared KEK to the member via
                     the mechanism described in paragraph 5.

     2.c.2.b.3.b.2.a - The GLA MUST apply confidentiality to the
                       response by encapsulating the SignedData.PKIData
                       in an EnvelopedData if the request was
                       encapsulated in an EnvelopedData (see paragraph
                       3.2.1.2).

     2.c.2.b.3.b.2.b - The GLA MAY also optionally apply another
                       SignedData over the EnvelopedData (see paragraph
                       3.2.1.2).

     3 - Upon receipt of the glSuccessInfo or glFailInfo response, the
         GLO verifies the GLA's signature(s). If an additional
         SignedData and/or EnvelopedData encapsulates the response (see
         paragraph 3.2.1.2 or 3.2.2), the GLO MUST verify the outer
         signature and/or decrypt the outer layer prior to verifying
         the signature on the inner most SignedData.

     3.a - If the signature(s) does (do) not verify, the GLO MUST
           return a cMCStatusInfo response indicating cMCStatus.failed
           and otherInfo.failInfo.badMessageCheck.

     3.b - If the signature(s) does(do) verify and the response is
           glSuccessInfo, the GLO has added the member to the GL. If
           member was added to a managed list and the original request
           was signed by the member, the GLO MUST send a
           cMCStatusInfo.cMCStatus.success to the GL member.

     3.c - If the GLO received a glFailInfo, for any reason, the GLO
           MAY reattempt to add the member via the mechanism described in paragraph 5.

                   a - The GLA MUST apply confidentiality to the
                       forwarded request by encapsulating the
                       SignedData.PKIData in an EnvelopedData if GL using the
                       request was encapsulated
           information provided in an EnvelopedData
                       (see paragraph 3.2.1.2).

                   b - The GLA MAY also optionally apply another
                       SignedData over the EnvelopedData (see paragraph
                       3.2.1.2).

     3 glFailInfo response.

     4 - Upon receipt of the GLSuccessInfo glSuccessInfo, glFailInfo, or GLFailInfo cMCStatus
         response, the
         GLO prospective member verifies the GLA's
         signature(s) or GLO's signature(s). If an additional
         SignedData and/or EnvelopedData encapsulates the response (see
         paragraph 3.2.1.2 or 3.2.2), the GLO MUST verify the outer
         signature and/or decrypt the outer layer prior to verifying
         the signature on the inner most SignedData.

       a

     4.a - If the signature(s) does (do) signatures do not verify, the GLO prospective member MUST
           return a cMCStatusInfo response indicating CMCFailInfo.badMessageCheck.

       b cMCStatus.failed
           and otherInfo.failInfo.badMessageCheck.

     4.b - If the signature(s) does(do) signatures do verify, the GLO prospective member has been
           added the
           member to the GL.

       c

Turner                                                              36
     4.c - If the GLO prospective member received a GLFailInfo, glFailInfo, for any
           reason, the GLO prospective member MAY reattempt to add the member
           themselves to the GL using the information provided in the GLFailInfo
           glFailInfo response.

     4

4.3.2 Prospective Member Initiated Additions

   The process for prospective member initiated glAddMember requests is
   as follows:

     1 - The prospective GL member sends a
         SignedData.PKIData.controlSequence.glAddMember request to the
         GLA (A in Figure 5). The prospective GL member MUST include:
         the GL name in glName, their name in glMember.glMemberName,
         their address in glMember.glMemberAddress, and their
         encryption certificate in glMember.certificates.membersPKC.
         The prospective GL member MAY also include any attribute
         certificates associated with their encryption certificate in
         glMember.certificates.membersAC, and the certification path
         associated with their encryption and attribute certificates in
         glMember.certificates.certificationPath.

     1.a - The prospective GL member MAY optionally apply
           confidentiality to the request by encapsulating the
           SignedData.PKIData in an EnvelopedData (see paragraph
           3.2.1.2).

     1.b - The prospective GL member MAY also optionally apply another
           SignedData over the EnvelopedData (see paragraph 3.2.1.2).

     2 - Upon receipt of the GLSuccessInfo or GLFailInfo response, request, the GLA verifies the request as
         per 2 in paragraph 4.3.1.

     3 - Upon receipt of the forwarded request, the GLO verifies the
         prospective GL member's signature on the
         prospective member verifies inner most
         SignedData.PKIData and the GLA's signature(s). signature on the outer layer.
         If an
         additional SignedData and/or EnvelopedData encapsulates the
         response inner most layer (see
         paragraph 3.2.1.2 or 3.2.2), the GLO MUST verify
         the outer signature and/or decrypt the outer
         layer prior to verifying the signature on the inner most
         SignedData.

       a

     3.a - If the signatures do signature(s) does(do) not verify, the prospective member GLO MUST return
           a cMCStatusInfo response indicating CMCFailInfo.badMessageCheck.

Turner                                                              33
       b cMCStatus.failed and
           otherInfo.failInfo.badMessageCheck.

     3.b - If the signatures do signature(s) does(do) verify, the prospective member has been
           added GLO MUST check to
           make sure one of the GL.

       c 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 MAY send a
             SignedData.PKIResponse.controlSequence message back to the

Turner                                                              37
             prospective member received a GLFailInfo, for any
           reason, with cMCStatusInfo.cMCStatus.failed
             indicating why the prospective member MAY reattempt to add
           themselves was denied in
             cMCStausInfo.statusString. This stops people from adding
             people to GLs without their permission.

     3.b.2 - If the GL using names do match, the information provided in GLO determines whether the
           GLFailInfo response.

4.3.2 Prospective Member Initiated Additions

   The process for
             prospective member initiated GLAddMembers requests is as follows:

     1 - 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 GL member sends is not
               allowed to join the GL, the GLO MAY return a
         SignedData.PKIData.controlSequence.GLAddMembers request
               SignedData.PKIResponse.controlSequence message back to
               the
         GLA (A prospective member with
               cMCStatusInfo.cMCtatus.failed indicating why the
               prospective member was denied in Figure 5). The cMCStatus.statusString.

     3.b.2.b - If GLO determines the prospective GL member is allowed to
               join the GL, the GLO MUST include: verify the member's encryption
               certificate.

     3.b.2.b.1 - If the member's certificate does not verify, the GLO
                 MAY return a SignedData.PKIResponse.controlSequence
                 back to the prospective member with
                 cMCStatusInfo.cMCtatus.failed indicating that the
                 member's encryption certificate did not verify in
                 cMCStatus.statusString. If the GLO does not return a
                 cMCStatusInfo response, the GL name in glName, GLO MUST send a
                 SignedData.PKIData.controlSequence.glProvideCert
                 message to the member's name in
         glMembers.glMemberName, their encryption certificate in
         glMembers.certificates.membersPKC. The prospective GL member
         MAY also include the GL identifier in glIdentifier, if known,
         any attribute certificates associated with their requesting a new
                 encryption certificate in glMembers.certificates.membersAC, and (see paragraph 4.10).

     3.b.2.b.2 - If the
         certification path associated with their encryption and
         attribute certificates member's certificate does verify, the GLO
                 resubmits the glAddMember request (see paragraph
                 3.2.5) to the GLA (1 in
         glMembers.certificates.certificationPath

       a Figure 5).

     3.b.2.b.2.a - The prospective GL member MAY optionally GLO MUST apply confidentiality to the new
                   GLAddMember request by encapsulating the
                   SignedData.PKIData in an EnvelopedData if the
                   initial request was encapsulated in an EnvelopedData
                   (see paragraph 3.2.1.2).

       b

     3.b.2.b.2.b - The prospective GL member GLO MAY also optionally apply another SignedData
                   over the EnvelopedData (see paragraph 3.2.1.2).

     2

     4 - Upon receipt of the request, the GLA verifies the request Processing continues as
         per 2 in 2 of paragraph 4.3.1.

     3 - Upon receipt of the forwarded request,

Turner                                                              38

4.4 Delete Members From GL

   To delete members from GLs, either the GLO verifies or prospective non-
   members use the glDeleteMember request. The GLA processes GLO and
   prospective GL member's signature on non-GL member requests differently. The GLO can submit
   the inner most
         SignedData.PKIData request at any time to delete members from the GL, and the GLA's signature on GLA,
   once it has verified the outer layer.
         If an EnvelopedData encapsulates request came from a registered GLO, should
   delete the inner most layer (see
         paragraph 3.2.1.2 or 3.2.2), member. If a prospective member sends the GLO MUST decrypt request, the outer
         layer prior
   GLA needs to verifying determine how the signature on GL is administered. When the inner most
         SignedData.

       a - If GLO
   initially configured the signature(s) does(do) not verify, GL, they set the GLO MUST return
           a response indicating CMCFailInfo.badMessageCheck.

       b - If GL to be unmanaged,
   managed, or closed (see paragraph 3.1.1). In the signature(s) does(do) verify, unmanaged case, the GLO MUST check to
           make sure one of
   GLA merely processes the names in member's request. For the certificate used to sign managed case, the request matches
   GLA forwards the name in glMembers.glMemberName.

Turner                                                              34
         1 - If requests from the names do not match, prospective members to the GLO may send
   for review. Where there are multiple GLOs for a message
             back, GL, which GLO the
   request is out forwarded to is beyond the scope of scope, 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 member, members. The following paragraphs describe
   the processing for the GLO(s), GLA, and prospective non-GL members
   depending on policy, to indicate that GL members can only
             add themselves lists.  This stops people where the request originated, either from adding
             people to GLs without their permission.

         2 - If a GLO or from
   prospective non-members. Figure 6 depicts the names do match, protocol interactions
   for the three options. Note that the error messages are not
   depicted.

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

                   Figure 6 - Member Deletion

   If the
             prospective member is allowed not removed from the GL, they will continue to
   receive and be added. The mechanism
             is beyond the scope of this document; however, able to decrypt data protected with the GLO
             should check shared KEK
   and will continue to receive rekeys. For unmanaged lists, there is
   no point to see a group rekey because there is no guarantee that the glMembers.glMemberName is
   member requesting to be removed has not already added themselves
   back on the GL. GL under a - If different name. For managed and closed GLs,
   the GLO determines MUST take steps to ensure the prospective member being deleted is not
               allowed to join the GL, on
   the GLO MAY return a message,
               which is beyond GL twice. After ensuring this, managed and closed GLs MUST be
   rekeyed to maintain the scope secrecy of this document, to indicate
               why the prospective member is not allowed to join.

           b - group. If GLO determines the prospective member GLO is allowed to
               join sure the GL,
   member has been deleted the GLO group rekey mechanism MUST verify be used to
   distribute the member's encryption
               certificate. new key (see paragraphs 4.5 and 5).

Turner                                                              39

4.4.1 GLO Initiated Deletions

   The process for GLO initiated glDeleteMember requests is as follows:

     1 - If The GLO collects the member's certificate does not verify, pertinent information for the GLO member(s)
         to be deleted (this MAY return a message, which is be done through an out of scope, to the
                 prospective member indicating that their encryption
                 certificate is not valid.

             2 - If the member's certificate does verify, the bands
         means). The GLO
                 reforms GLAddMembers then sends a
         SignedData.PKIData.controlSequence with a separate
         glDeleteMember request (the prospective member's
                 signature is discarded and the GLO applies their own
                 signature) for each member to the GLA (1 in Figure 5) by including:
         6). The GLO MUST include: the GL name in glName, glName and the
         member's name in
                 glMembers.glMemberName, the member's encryption
                 certificate in glMembers.certificates.membersPKC. The
                 GLO MAY also include glMemberToDelete. If the GL identifier in
                 glIdentifier, if known, any attribute certificates
                 associated with from which the member's encryption certificate
         member is being deleted in
                 glMembers.certificates.membersAC, a closed or managed GL, the GLO
         MUST also generate a glRekey request and the
                 certification path associated include it with the member's
                 encryption and attribute certificates in
                 glMembers.certificates.certificationPath.

               a
         glDeletemember request (see paragraph 4.5).

     1.a - The GLO MUST MAY optionally apply confidentiality to the new
                   GLAddMember request
           by encapsulating the SignedData.PKIData in an EnvelopedData if the
                   initial request was encapsulated in an EnvelopedData
           (see paragraph 3.2.1.2).

               b

     1.b - The GLO MAY also optionally apply another SignedData over
           the EnvelopedData (see paragraph 3.2.1.2).

     4 - Processing continues as in

     2 - Upon receipt of paragraph 4.3.1.

Turner                                                              35

4.4 Delete Members From GL

   To delete members from GLs, either the GLO or prospective non-
   members use request, the GLDeleteMembers request. There are however different
   scenarios that should be supported. Either GLA verifies the GLO or prospective
   members may submit signature on
         the GLDeleteMembers request to inner most SignedData.PKIData. If an additional SignedData
         and/or EnvelopedData encapsulates the GLA, but request (see paragraph
         3.2.1.2 or 3.2.2), the GLA processes MUST verify the requests differently. The GLO can submit outer signature
         and/or decrypt the
   request at any time outer layer prior to delete members from the GL, and verifying the GLA, once
   it has verified
         signature on the request came from inner most SignedData.

     2.a - If the GLO should delete signature(s) does(do) not verify, the
   member. If GLA MUST return
           a prospective member sends cMCStatusInfo response indicating cMCStatus.failed and
           otherInfo.failInfo.badMessageCheck.

     2.b - If the request, signature(s) does(do) verify, the GLA needs to
   determine how MUST make sure
           the GL is administered. When the GLO initially
   configured the GL, they set the GL to be unmanaged, managed, or
   closed (see paragraph 3.1.1). In the unmanaged case, the GLA merely
   processes the member's request. For the managed case, supported by the GLA
   forwards the requests from the prospective members to the GLO. Where
   there are multiple GLOs for a GL, which GLO the request is forwarded
   to is beyond by checking that the scope of this document. In glName
           matches a glName stored on the closed case, GLA.

     2.b.1 - If the GLA
   will glName is not accept requests from prospective members. The following
   paragraphs describe the processing required supported by the GLO, GLA, and
   prospective non-GL members depending on where the request
   originated, either from the GLO or from prospective members. Figure
   6 depicts GLA MUST
             return a response indicating
             glFailInfo.errorCode.invalidGLName.

     2.b.2 - If the protocol interactions for glName is supported by the three options. Note that GLA, the error messages are not depicted.

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

                   Figure 6 MUST check
             to see if the glMemberName is present on the GL.

     2.b.2.a - Member Deletion If the member glMemberName is not removed from present on the GL, they will continue to be
   able to receive and decrypt data protected with the shared KEK and
   will continue to receive shared KEK rekeys. For unmanaged lists,
   there is no point to GLA
               MUST return a group rekey because there is no guarantee
   that response indicating
               glFailInfo.errorCode.notAMember.

     2.b.2.b - If the member requesting to be removed has not glMemberName is already added
   themselves back on the list under a different name. For managed and
   closed GLs, GL, the GLO GLA MUST take steps to ensure
               check how the member being
   deleted GL is not on the list twice. After ensuring this, administered.

Turner                                                              40
     2.b.2.b.1 - If the managed GL is closed, the GLA MUST be rekeyed to maintain check that the secrecy
                 registered GLO signed the request by checking that one
                 of the group. If the GLO
   is sure the member has been deleted names in the group rekey mechanism MAY be digital signature certificate used
                 to distribute sign the new key (see paragraphs 4.5 and 5).

Turner                                                              36

4.4.1 GLO Initiated Deletions

   The process for GLO initiated GLDeleteMembers requests is as
   follows:

     1 request matches the registered GLO.

     2.b.2.b.1.a - The GLO collects If the names and pertinent information for do not match, the
         members to be deleted (this MAY be done through an out of
         bands means). The GLO then sends GLA MUST return a
         SignedData.PKIData.controlSequence.GLDeleteMembers request to
                   response indicating
                   glFailInfo.errorCode.noGLONameMatch.

     2.b.2.b.1.b - If the names do match, the GLA (1 in Figure 6). The GLO MUST include: return a
                   glSuccessInfo indicating the GL name in
         glName and glName, the member's name
                   corresponding glIdentifier, an
                   action.actionCode.deletedMember, and
                   action.glMemberName (2 in glMembersToDelete. Figure 5). The GLO MAY
         omit the glIdentifier if it is unknown. If the GL from GLA also
                   takes administrative actions, which are beyond the
                   scope of this document, to delete the member is being deleted in a closed or managed GL, with
                   the GLO GL stored on the GLA. The GLA MUST also generate a GLRekey request and include it with the
         GLDeleteMember request (see rekey
                   group as described in paragraph 4.5).

       a 5.

     2.b.2.b.1.b.1 - The GLO MAY optionally GLA MUST apply confidentiality to the request response
                     by encapsulating the SignedData.PKIData in an
                     EnvelopedData if the request was encapsulated in
                     an EnvelopedData (see paragraph 3.2.1.2).

       b

     2.b.2.b.1.b.2 - The GLO GLA MAY also optionally apply another
                     SignedData over the EnvelopedData (see paragraph
                     3.2.1.2).

     2

     2.b.2.b.2 - Upon receipt of If the request, GL is managed, the GLA verifies MUST check that either a
                 registered GLO or the signature on prospective member signed the inner most SignedData.PKIData. If an additional SignedData
         and/or EnvelopedData encapsulates
                 request. For GLOs, one of the names in the certificate
                 used to sign the request MUST match a registered GLO.
                 For the request (see paragraph
         3.2.1.2 or 3.2.2), prospective member, the GLA name in
                 glMember.glMemberName MUST verify match one of the outer signature
         and/or decrypt names in
                 the outer layer prior certificate used to verifying the
         signature on sign the inner most SignedData.

       a request.

     2.b.2.b.2.a - If the signature(s) does(do) not verify, signer is neither a registered GLO nor the
                   prospective GL member, the GLA MUST return a
                   response indicating CMCFailInfo.badMessageCheck.

       b glFailInfo.errorCode.noSpam.

     2.b.2.b.2.b - If the signature(s) does(do) verify, signer is a registered GLO, the GLA MUST make sure
                   return a glSuccessInfo to the GL is supported by GLO indicating the GLA by checking either that
                   glName, the
           glName is supported (in corresponding glIdentifier, an
                   action.actionCode.deletedMember, and
                   action.glMemberName (2 in Figure 6). The GLA also
                   takes administrative actions, which are beyond the case
                   scope of this document, to delete the glIdentifier is
           omitted) or that member with
                   the combination of glName and glIdentifier
           matches a glName and glIdentifier GL stored on the GLA.

         1 The GLA will also rekey
                   group as described in paragraph 5.

     2.b.2.b.2.b.1 - If the glIdentifier is omitted and the glName is not
             supported by the GLA, the The GLA MUST return a response
             indicating GLFailInfo.errorCode.invalidGLName.

         2 - If apply confidentiality to the glName and glIdentifier are present and do not
             match a GL stored on response
                     by encapsulating the GLA, SignedData.PKIData in an

Turner                                                              41
                     EnvelopedData if the request was encapsulated in
                     an EnvelopedData (see paragraph 3.2.1.2).

     2.b.2.b.2.b.2 - The GLA MUST return a
             response indicating
             GLFailInfo.errorCode.invalidGLNameGLIdentifierCombination.

         3 MAY also optionally apply another
                     SignedData over the EnvelopedData (see paragraph
                     3.2.1.2).

     2.b.2.b.2.c - If the glIdentifier signer is omitted and the glName is supported
             by prospective member, the GLA or if the glIdentifier/glName combination is

Turner                                                              37
             supported by
                   forwards the GLA, glDeleteMember request (see paragraph
                   3.2.3) to the GLA MUST check GLO (B{A} in Figure 6). If there is
                   more than one registered GLO, the GLO to see if which the
             glMemberName
                   request is present on the GL.

           a - If the glMemberName forwarded to is not present on beyond the GL, scope of this
                   document. Further processing of the forwarded
                   request by GLOs is addressed in 3 of paragraph
                   4.4.2.

     2.b.2.b.2.c.1 - The GLA MUST return a response indicating
               GLFailInfo.errorCode.notAMember.

           b - If apply confidentiality to the glMemberName is not already on
                     forwarded request by encapsulating the GL,
                     SignedData.PKIData in an EnvelopedData if the
                     request was encapsulated in an EnvelopedData (see
                     paragraph 3.2.1.2).

     2.b.2.b.2.c.2 - The GLA
               MUST check how MAY also optionally apply another
                     SignedData over the GL is administered.

             1 EnvelopedData (see paragraph
                     3.2.1.2).

     2.b.2.b.3 - If the GL is closed, unmanaged, the GLA MUST check that either
                 a registered GLO or the prospective member signed the request by checking that
                 request. For GLOs, one of the names in the digital signature certificate
                 used to sign the request matches MUST match the name of a
                 registered GLO. For the prospective member, the name
                 in glMember.glMemberName MUST match one of the registered GLOs.

               a names
                 in the certificate used to sign the request.

     2.b.2.b.3.a - If the names do not match, signer is neither the GLO nor the prospective
                   member, the GLA MUST return a response indicating
                   GLFailInfo.errorCode.noGLONameMatch.

               b
                   glFailInfo.errorCode.noSpam.

     2.b.2.b.3.b - If the names do match, signer is either a registered GLO or the
                   member, the GLA MUST return to all
                   GLOs a GLSucessInfo glSuccessInfo
                   indicating the glName, the corresponding
                   glIdentifier, an action.actionCode.deletedMember,
                   and action.glMemberName to the GLO (2 in Figure 5). The response
                   MUST be constructed as 6)
                   if the GLO signed the request and to the GL member
                   (3 in paragraph 3.2.3. Figure 6) if the GL member signed the request.
                   The GLA also takes administrative actions, which are
                   beyond the scope of this document, to delete the
                   member with the GL stored on the GLA. The GLA will also
                   rekey group as described in paragraph 5.

                 1

     2.b.2.b.3.b.1 - The GLA MUST apply confidentiality to the response
                     by encapsulating the SignedData.PKIData in an

Turner                                                              42
                     EnvelopedData if the request was encapsulated in
                     an EnvelopedData (see paragraph 3.2.1.2).

                 2 - The GLA MAY also optionally apply another EnvelopedData (see paragraph 3.2.1.2).

     2.b.2.b.3.b.2 - The GLA MAY also optionally apply another
                     SignedData over the EnvelopedData (see paragraph
                     3.2.1.2).

     3 - Upon receipt of the glSuccessInfo or glFailInfo response, the
         GLO verifies the GLA's signatures. If an additional SignedData over the
         and/or EnvelopedData encapsulates the response (see paragraph
                     3.2.1.2).

             2
         3.2.1.2 or 3.2.2), the GLO MUST verify the outer signature
         and/or decrypt the outer layer prior to verifying the
         signature on the inner most SignedData.

     3.a - If the GL is managed, signature(s) does(do) not verify, the GLA GLO MUST check that either return
           a cMCStatusInfo response indicating cMCStatus.failed and
           otherInfo.failInfo.badMessageCheck.

     3.b - If the signature(s) does(do) verify and the response is
           glSuccessInfo, the GLO or has deleted the prospective member from the GL.
           If member was deleted from a managed list and the original
           request was signed by the request.
                 For member, the GLO, one of GLO MUST send a
           cMCStatusInfo.cMCStatus.success to the names in GL member.

     3.c - If the certificate used GLO received a glFailInfo, for any reason, the GLO
           may reattempt to sign delete the request MUST match one member from the GL using the
           information provided in the glFailInfo response.

     4 - Upon receipt of the registered
                 GLOs. For glSuccessInfo, glFailInfo, or cMCStatus
         response, the prospective member, member verifies the name in
                 glMembers.glMemberName GLA's
         signature(s) or GLO's signature(s). If an additional
         SignedData and/or EnvelopedData encapsulates the response (see
         paragraph 3.2.1.2 or 3.2.2), the GLO MUST match one of verify the names in outer
         signature and/or decrypt the certificate used outer layer prior to sign verifying
         the request.

               a _ signature on the inner most SignedData.

     4.a - If the signer is neither a registered GLO or signature(s) does(do) not verify, the prospective GL member, the GLA
           member MUST return a cMCStatusInfo response indicating GLFailInfo.errorCode.noSpam.

Turner                                                              38
               b
           cMCStatus.failed and otherInfo.failInfo.badMessageCheck.

     4.b - If the signer is signature(s) does(do) verify, the GLO, prospective member
           has been deleted from the GLA MUST return to all
                   GLOs GL.

     4.c - If the prospective member received a GLSucessInfo indicating glFailInfo, for any
           reason, the prospective member MAY reattempt to delete
           themselves from the glName, GL using the
                   corresponding glIdentifier, an
                   action.actionCode.deletedMember, and
                   action.glMemberName (2 information provided in Figure 6). the
           glFailInfo response.

Turner                                                              43

4.4.2 Member Initiated Deletions

   The response
                   MUST be constructed process for prospective non-member initiated glDeleteMember
   requests is as in paragraph 3.2.3. follows:

     1 - The GLA
                   also takes administrative actions, which are beyond
                   the scope of this document, prospective non-GL member sends a
         SignedData.PKIData.controlSequence.glDeleteMember request to delete
         the GLA (A in Figure 6). The prospective non-GL member
                   with MUST
         include: the GL stored on the GLA. The GLA will also
                   rekey group as described name in paragraph 5.

                 1 glName and their name in
         glMemberToDelete.

     1.a - The GLA MUST prospective non-GL member MAY optionally apply
           confidentiality to the response request by encapsulating the
           SignedData.PKIData in an EnvelopedData if the request was encapsulated in
                     an EnvelopedData (see paragraph
           3.2.1.2).

                 2

     1.b - The GLA prospective non-GL member MAY also optionally apply
           another SignedData over the EnvelopedData (see paragraph
           3.2.1.2).

               c

     2 - If the signer is Upon receipt of the prospective member, request, the GLA
                   forwards verifies the GLDeleteMembers request (see paragraph
                   3.2.3) to the GLO (B{A} as
         per 2 in Figure 6). Which GLO the
                   request is forwarded to is beyond the scope of this
                   document. Further processing paragraph 4.4.1.

     3 - Upon receipt of the forwarded
                   request by request, the GLO is addressed in 3 of paragraph
                   4.4.2.

                 1 - The GLA MUST apply confidentiality to verifies the
                     forwarded request by encapsulating
         prospective non-member's signature on the inner most
         SignedData.PKIData in an EnvelopedData if and the
                     request was encapsulated in GLA's signature on the outer layer.
         If an EnvelopedData encapsulates the inner most layer (see
         paragraph 3.2.1.2).

                 2 3.2.1.2 or 3.2.2), the GLO MUST decrypt the outer
         layer prior to verifying the signature on the inner most
         SignedData.

     3.a - The GLA MAY also optionally apply another
                     SignedData over If the EnvelopedData (see paragraph
                     3.2.1.2).

             3 signature(s) does(do) not verify, the GLO MUST return
           a cMCStatusInfo response indicating cMCStatus.failed and
           otherInfo.failInfo.badMessageCheck.

     3.b - If the GL is unmanaged, signature(s) does(do) verify, the GLA GLO MUST check that either
                 the GLO or the prospective member signed the request.
                 For the GLO, to
           make sure one of the names in the certificate certificates used to sign
           the request MUST match one of the registered
                 GLOs. For the prospective member, matches the name in
                 glMembers.glMemberName MUST match one of the names in
                 the certificate used to sign the request.

               a glMemberToDelete.

     3.b.1 - If the signer is names do not match, the GLO or MAY send a
             SignedData.PKIResponse.controlSequence message back to the
             prospective
                   member, the GLA MUST return a response member with cMCStatusInfo.cMCtatus.failed
             indicating
                   GLFailInfo.errorCode.noSpam.

               b why the prospective member was denied in
             cMCStatusInfo.statusString. This stops people from adding
             people to GLs without their permission.

     3.b.2 - If the signer is either names do match, the GLO or the member, the
                   GLA MUST return a GLSucessInfo indicating the

Turner                                                              39
                   glName, resubmits the corresponding glIdentifier, an
                   action.actionCode.deletedMember, and
                   action.glMemberName
             glDeleteMember request (see paragraph 3.2.5) to the GLO (2 GLA (1
             in Figure 6) if
                   the 6). The GLO signed the request and to MUST make sure the GL member (3
                   in Figure 6) if glMemberName is
             already on the GL member signed list and only on the request. list once. The response GLO
             MUST be constructed as in paragraph
                   3.2.3. The GLA also takes administrative actions,
                   which are beyond the scope of this document, to
                   delete the member generate a glRekey request and include it with
             the GL stored on the GLA.

                 1 GLDeleteMember request (see paragraph 4.5).

Turner                                                              44
     3.b.2.a - The GLA GLO MUST apply confidentiality to the response new
               GLDeleteMember request by encapsulating the
               SignedData.PKIData in an EnvelopedData if the initial
               request was encapsulated in an EnvelopedData (see
               paragraph 3.2.1.2).

                 2 - The GLA MAY also optionally apply another
                    SignedData over the EnvelopedData (see paragraph
                    3.2.1.2).

     3 - Upon receipt of the GLSuccessInfo or GLFailInfo response, the
         GLO verifies the GLA's signatures. If an additional SignedData
         and/or EnvelopedData encapsulates the response (see paragraph
         3.2.1.2 or 3.2.2), the 3.2.1.2).

     3.b.2.b - The GLO MUST verify MAY also optionally apply another SignedData
               over the outer signature
         and/or decrypt EnvelopedData (see paragraph 3.2.1.2).

     4 - Further processing is as in 2 of paragraph 4.4.1.

4.5 Request Rekey Of GL

   From time to time the outer layer prior GL will need to verifying be rekeyed. Some situations
   are as follows:

     - When a member is removed from a closed or managed GL. In this
       case, the
         signature on PKIData.controlSequence containing the inner most SignedData. glDeleteMember
       should contain a glRekey request.

     - Depending on policy, when a member is removed from an unmanaged
       GL. If the signature(s) does(do) not verify, policy is to rekey the GLO MUST return
           a response indicating CMCFailInfo.badMessageCheck.

       b - If GL, the signature(s) does(do) verify,
       PKIData.controlSequence containing the GLO has deleted glDeleteMember could also
       contain a glRekey request or an out of bands means could be used
       to tell the
           member from GLA to rekey the GL.

       c Rekeying of unmanaged GLs when
       members are deleted is not advised.

     - If When the GLO received a GLFailInfo, for any reason, current shared KEK has been compromised.

     - When the GLO
           may reattempt current shared KEK is about to delete expire.

       - If the member from GLO controls the GL using rekey, the
           information provided in GLA should not assume
         that a new shared KEK should be distributed, but instead wait
         for the GLFailInfo response.

     4 glRekey message.

       - Upon receipt of If the GLSuccessInfo or GLFailInfo response, GLA controls the
         prospective member verifies GL rekey, the GLA's signature(s). GLA should initiate a
         glKey message as specified in paragraph 5.

   If an
         additional SignedData and/or EnvelopedData encapsulates the
         response generationCounter (see paragraph 3.2.1.2 or 3.2.2), 3.1.1) is set to a value
   greater than one (1) and the GLO MUST verify controls the outer signature and/or decrypt GL rekey, the outer layer prior to
         verifying GLO may
   generate a glRekey any time before the signature last shared KEK has expired.
   To be on the inner most SignedData. safe side, the GLO should request a - If rekey one (1)
   duration before the signature(s) does(do) not verify, last shared KEK expires.

   The GLA and GLO are the prospective
           member MUST return only entities allowed to initiate a response indicating
           CMCFailInfo.badMessageCheck.

       b - If the signature(s) does(do) verify, GL
   rekey. The GLO indicated whether they are going control rekeys or
   whether the prospective member
           has been deleted from GLA is going to control rekeys when the GL.

       c - If assigned the prospective member received
   shared KEK to GL (see paragraph 3.1.1). The GLO MAY initiate a GLFailInfo, for GL
   rekey at any
           reason, the prospective member time. The GLA MAY reattempt be configured to delete

Turner                                                              40
           themselves from automatically rekey
   the GL using prior to the information provided in expiration of the
           GLFailInfo response.

4.4.2 Member shared KEK (the length of time

Turner                                                              45
   before the expiration is an implementation decision). Figure 7
   depicts the protocol interactions to request a GL rekey. Note that
   error messages are not depicted.

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

                     Figure 7 - GL Rekey Request

4.5.1 GLO Initiated Deletions Rekey Requests

   The process for prospective non-member GLO initiated GLDeleteMembers glRekey requests is as follows:

     1 - The prospective non-GL member GLO sends a
         SignedData.PKIData.controlSequence.GLDeleteMembers SignedData.PKIData.controlSequence.glRekey
         request to the GLA (A (1 in Figure 5). 7). The prospective non-GL member GLO MUST
         include: the GL name in glName and their name in
         glMembersToDelete.  The prospective non-GL member MAY omit include the
         glIdentifier if it
         glName. If glAdministration and glKeyNewAttributes are omitted
         then there is unknown. no change from the previously registered GL
         values for these fields. If the GLO wants to force a rekey for
         all outstanding shared KEKs the
         glNewKeyAttributes.generationCounter MUST be set to zero (0)

     1.a - The prospective non-GL member GLO MAY optionally apply confidentiality to the request
           by encapsulating the SignedData.PKIData in an EnvelopedData
           (see paragraph 3.2.1.2).

       b

     1.b - The prospective non-GL member GLO MAY also optionally apply another SignedData over
           the EnvelopedData (see paragraph 3.2.1.2).

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

     3 - Upon receipt of the forwarded request, the GLO verifies the
         prospective GL member's signature on
         the inner most
         SignedData.PKIData and the GLA's signature on the outer layer. SignedData.PKIData. If an additional SignedData
         and/or EnvelopedData encapsulates the inner most layer request (see paragraph
         3.2.1.2 or 3.2.2), the GLO GLA MUST verify the outer signature
         and/or decrypt the outer layer prior to verifying the
         signature on the inner most SignedData.

       a

     2.a - If the signature(s) does(do) not verify, the GLA MUST return
           a cMCStatusInfo response indicating cMCStatus.failed and
           otherInfo.failInfo.badMessageCheck.

     2.b - If the signature(s) does(do) verify, the GLA MUST make sure
           the GL is supported by the GLA by checking that the glName
           matches a glName stored on the GLA.

     2.b.1 - If the glName present does not match a GL stored on the
             GLA, the GLA MUST return a response indicating
             glFailInfo.errorCode.invalidGLName.

     2.b.2 - If the glName present does match a GL stored on the GLA,
             the GLA MUST check that a registered GLO signed the

Turner                                                              46
             request by checking that one of the names in the
             certificate used to sign the request is a registered GLO.

     2.b.2.a - If the names do not match, the GLA MUST return a
               response indicating glFailInfo.errorCode.noGLONameMatch.

     2.b.2.b - If the names do match, the GLA MUST check the
               glNewKeyAttribute values.

     2.b.2.b.1 - If the new value for requestedAlgorithm is not
                 supported, the GLA MUST return a response indicating
                 glFailInfo.errorCode.unsupportedAlgorithm

     2.b.2.b.2 - If the new value duration is not supportable,
                 determining this is beyond the scope this document,
                 the GLA MUST return a response indicating CMCFailInfo.badMessageCheck.

       b
                 glFailInfo.errorCode.unsupportedDuration.

     2.b.2.b.3 - If the signature(s) does(do) verify, the GLO MUST check to
          make sure the name in one of the certificates used to sign
          the request GL is the entity indicated in glMembersToDelete.

         1 - If the names do not match, the GLO may send a message
             back, supportable for other reasons, which is out of scope, to
                 the prospective member,
             depending on policy, to indicate that GL members can only
             add themselves lists.  This stops people from adding
             people GLA does not wish to GLs without their permission.

         2 disclose, the GLA MUST return
                 a response indicating
                 glFailInfo.errorCode.unspecified.

     2.b.2.b.4 - If the names do match, the GLO deletes the member from the
             GL by sending the reformed GLDeleteMembers request (the
             prospective non-GL member's signature is stripped off new requestedAlgorithm and

Turner                                                              41 duration are
                 supportable or the GLO signs it) to glNewKeyAttributes was omitted, the
                 GLA (1 in Figure 6). The GLO MUST
             make sure return a glSuccessInfo to the glMemberName is already on GLO indicating
                 the list and only
             on glName, the list once. new glIdentifier, and an
                 action.actionCode.rekeyedGL (2 in Figure 7). The GLO MUST GLA
                 also generate a GLRekey
             request and include it with uses the GLDeleteMember request glKey message to distribute the rekey
                 shared KEK (see paragraph 4.5).

           a 5).

     2.b.2.b.4.a - The GLO GLA MUST apply confidentiality to the new
               GLDeleteMember request response by
                   encapsulating the SignedData.PKIData in an
                   EnvelopedData if the initial request was encapsulated in an
                   EnvelopedData (see paragraph 3.2.1.2).

           b

     2.b.2.b.4.b - The GLO GLA MAY also optionally apply another SignedData
                   over the EnvelopedData (see paragraph 3.2.1.2).

     4

     3 - Further processing is as in 2 Upon receipt of the glSuccessInfo or glFailInfo response, the
         GLO verifies the GLA's signature(s). If an additional
         SignedData and/or EnvelopedData encapsulates the forwarded
         response (see paragraph 4.4.1.

4.5 Request Rekey Of GL

   From time to time 3.2.1.2 or 3.2.2), the GL will need to be rekeyed. Some situations
   are as follows: GLO MUST verify
         the outer signature and/or decrypt the forwarded response
         prior to verifying the signature on the inner most SignedData.

     3.a - When a member is removed from a closed or managed GL. In this
       case, If the PKIData.controlSequence containing signature(s) does(do) not verify, the GLDeleteMembers
       should contain GLO MUST return
           a GLRekey request. cMCStatusInfo response indicating cMCStatus.failed and
           otherInfo.failInfo.badMessageCheck.

     3.b - Depending on policy, when a member If the signatures verifies and the response is removed from an unmanaged
           glSuccessInfo, the GLO has successfully rekeyed the GL.

Turner                                                              47
     3.c - If the policy is GLO received a glFailInfo, for any reason, the GLO
           may reattempt to rekey the GL, GL using the
       PKIData.controlSequence containing information provided
           in the GLDeleteMembers could
       also contain a GLRekey request or an out glFailInfo response.

4.5.2 GLA Initiated Rekey Requests

   If the GLA is in charge of bands means could be
       used to tell rekeying the GL the GLA to rekey will
   automatically issue a glKey message (see paragraph 5). In addition
   the GL. Rekeying of unmanaged GLs
       when members are deleted is not advised.

     - When GLA will generate a glSuccessInfo to indicate to the current shared KEK GL that a
   successful rekey has been compromised. occurred. The process for GLA will
       automatically perform an initiated rekey without waiting
   is as follows:

     1 - The GLA MUST generate for approval from all GLOs a
         SignedData.PKIData.controlSequence.glSuccessInfo indicating
         the GLO.

     - When glName, the current shared KEK is about to expire. new glIdentifier, and actionCode.rekeyedGL (A
         in Figure 7). glMemberName and glOwnerName are omitted.

     1.a - If the GLO controls The GLA MAY optionally apply confidentiality to the GL rekey, request
           by encapsulating the SignedData.PKIData in an EnvelopedData
           (see paragraph 3.2.1.2).

     1.b - The GLA should not assume
         that a new shared KEK should be distributed, but instead wait
         for MAY also optionally apply another SignedData over
           the GLRekey message. EnvelopedData (see paragraph 3.2.1.2).

     2 - If Upon receipt of the GLA controls glSuccessInfo response, the GL rekey, GLO verifies
         the GLA should initiate a
         GLKey message as specified in paragraph 5. GLA's signature(s). If an additional SignedData and/or
         EnvelopedData encapsulates the generationCounter forwarded response (see
         paragraph 3.1.1) is set to a value
   greater than one (1) and 3.2.1.2 or 3.2.2), the GLO controls MUST verify the GL rekey, outer
         signature and/or decrypt the GLO may
   generate a GLRekey any time before outer layer prior to verifying
         the last shared KEK has expired.
   To be signature on the safe side, inner most SignedData.

     2.a - If the signatures do not verify, the GLO should request MUST return a rekey 1 duration
   before the last shared KEK expires.

Turner                                                              42
   The GLA
           cMCStatusInfo response indicating cMCStatus.failed and GLO are
           otherInfo.failInfo.badMessageCheck.

     2.b - If the only entities allowed to initiate a GL
   rekey. The GLO indicated whether they are going control rekeys or
   whether signatures verifies and the GLA response is going to control rekeys when the assigned
           glSuccessInfo, the
   shared KEK to GL (see paragraph 3.1.1). The GLO MAY initiate a GL
   rekey at any time. The GLA MAY be configured to automatically rekey knows the GL prior to GLA has successfully
           rekeyed the expiration GL.

4.6 Change GLO

   Management of managed and closed GLs can become difficult for one
   GLO if the shared KEK (the length of time
   before GL membership grows large. To support distributing the expiration is an implementation decision).
   workload, GLAs support having GLs be managed by multiple GLOs. The
   glAddOwner and glRemoveOwner messages are designed to support adding
   and removing registered GLOs. Figure 7 8 depicts the protocol
   interactions to request a GL rekey. Note that
   error send glAddOwner and glRemoveOwner messages are not depicted. and the
   resulting response messages.

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

                 Figure 7 8 - GL Rekey Request

4.5.1 GLO Initiated Rekey Requests Add & Delete Owners

   The process for GLO initiated GLRekey requests glAddOwner and glDeleteOwner is as follows:

     1 - The GLO sends a SignedData.PKIData.controlSequence.GLRekey SignedData.PKIData.controlSequence.glAddOwner
         or glRemoveOwner request to the GLA (1 in Figure 7). 8). The GLO
         MUST include the
         glName and the glIdentifier. The GLO MAY include change the
         glOwner, glAdministration, glDistributionMethod, and
         glKeyAttributes. If glOwner, glAdministration,
         glDistributionMethod, and glKeyAttributes are omitted then
         there is no change from include: the previously registered GL values
         for these fields. If name in glName, the GLO wants to force a rekey for all
         outstanding shared KEKs GLO's name in
         glOwnerName, and the glKeyAttributes.generationCounter
         MUST be set to zero (0)

       a GLO's address in glOwnerAddress.

     1.a - The GLO MAY optionally apply confidentiality to the request
           by encapsulating the SignedData.PKIData in an EnvelopedData
           (see paragraph 3.2.1.2).

       b

     1.b - The GLO MAY also optionally apply another SignedData over
           the EnvelopedData (see paragraph 3.2.1.2).

     2 - Upon receipt of the glAddOwner or glRemoveOwner request, the
         GLA verifies the signature on
         the inner most SignedData.PKIData. GLO's signature(s). If an additional
         SignedData and/or EnvelopedData encapsulates the request (see
         paragraph 3.2.1.2 or 3.2.2), the GLA MUST verify the outer
         signature and/or decrypt the outer layer prior to verifying
         the signature on the inner most SignedData.

       a

     2.a - If the signature(s) does(do) not verify, the GLA MUST return
           a cMCStatusInfo response indicating CMCFailInfo.badMessageCheck.

       b cMCStatus.failed and
           otherInfo.failInfo.badMessageCheck.

     2.b - If the signature(s) does(do) verify, the GLA MUST make sure
           the GL is supported by the GLA by checking that that the

Turner                                                              43
           combination of glName and glIdentifier matches a
           glName and
           glIdentifier combination stored on the GLA.

         1

     2.b.1 - If the glName and glIdentifier present do is not match a GL
             stored on supported by the GLA, the GLA MUST
             return a response indicating
             GLFailInfo.errorCode.invalidGLNameGLIdentifierCombination.

         2
             glFailInfo.errorCode.invalidGLName.

     2.b.2 - If the glName and glIdentifier present do match a GL
             stored on is supported by the GLA, the GLA MUST check that ensure
             a registered GLO signed the glAddOwner or glRemoveOwner
             request by checking that one of the names present in the
             digital signature certificate used to sign the glAddOwner
             or glDeleteOwner request is matches the name of a registered
             GLO.

           a

     2.b.2.a - If the names do not match, the GLA MUST return a
               response indicating GLFailInfo.errorCode.noGLONameMatch.

           b glFailInfo.errorCode.noGLONameMatch.

     2.b.2.b - If all the names do match, the GLA MUST return to all
               GLOs a GLSucessInfo
               glSuccessInfo indicating the glName, the new
               glIdentifier, and corresponding

Turner                                                              49
               glIdentifier (for glAddOwner), an action.actionCode.rekeyedGL
               action.actionCode.addedGLO or removedGLO, and the
               respective GLO name in glOwnerName (2 in Figure 7). 4). The
               GLA MUST also uses take administrative actions to associate
               the GLKey message new glOwnerName with the GL in the case of
               glAddOwner or to
               distribute disassociate the rekey shared KEK (see paragraph 5).

             1 old glOwnerName with
               the GL in the cased of glRemoveOwner.

     2.b.2.b.1 - The GLA MUST apply confidentiality to the response by
                 encapsulating the SignedData.PKIData SignedData.PKIResponse in an
                 EnvelopedData if the request was encapsulated in an
                 EnvelopedData (see paragraph 3.2.1.2).

             2

     2.b.2.b.2 - The GLA MAY also optionally apply another SignedData
                 over the EnvelopedData (see paragraph 3.2.1.2).

     3 - Upon receipt of the GLSuccessInfo glSuccessInfo or GLFailInfo glFailInfo response, the
         GLO verifies the GLA's signature(s). If an additional
         SignedData and/or EnvelopedData encapsulates the forwarded response (see
         paragraph 3.2.1.2 or 3.2.2), the GLO MUST verify the outer
         signature and/or decrypt the forwarded response outer layer prior to verifying
         the signature on the inner most SignedData.

       a

     3.a - If the signature(s) does(do) not verify, the GLO MUST return
           a cMCStatusInfo response indicating CMCFailInfo.badMessageCheck.

       b cMCStatus.failed and
           otherInfo.failInfo.badMessageCheck.

     3.b - If the signatures verifies, do verify and the response was
           glSuccessInfo, the GLO has successfully rekeyed added or removed the GL.

       c
           GLO.

     3.c - If the GLO received a GLFailInfo, for any reason, signatures do verify and the response was glFailInfo,
           the GLO
           may MAY reattempt to rekey add or delete the GL GLO using the
           information provided in the GLFailInfo glFailInfo response.

Turner                                                              44

4.5.2 GLA Initiated Rekey Requests

   If

4.7 Indicate KEK Compromise

   The will be times when the GLA shared KEK is in charge of rekeying the compromised. GL or if a GLKCompromise
   message has been properly processed (see paragraph 4.7) members and
   GLOs use glkCompromise to tell the GLA will
   automatically issue a GLKey message (see paragraph 5).  In addition that the GLA will generate a GLSuccessInfo to indicate to shared KEK has been
   compromised. Figure 9 depicts the protocol interactions for GL that a
   successful rekey has occurred. Key
   Compromise.

Turner                                                              50
                +-----+  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 GLA GL member initiated rekey glkCompromise messages is as
   follows:

     1 _ - The GLA MUST generate for all GLOs GL member sends a
         SignedData.PKIData.controlSequence.GLSucessInfo indicating the
         glName,
         SignedData.PKIData.controlSequence.glkCompromise request to
         the new glIdentifier, and actionCode.rekeyedGL (A GLA (1 in Figure 7).

       a 9). The GL member MUST include the GL's
         name in GeneralName.

     1.a - The GLA GL member MAY optionally apply confidentiality to the
           request by encapsulating the SignedData.PKIData in an
           EnvelopedData (see paragraph 3.2.1.2).

       b The glkCompromise
           MUST NOT be included in an EnvelopedData generated with the
           compromised shared KEK.

     1.b - The GLA GL member MAY also optionally apply another SignedData
           over the EnvelopedData (see paragraph 3.2.1.2).

     2 - Upon receipt of the GLSuccessInfo response, glkCompromise requst, the GLO GLA verifies the GLA's
         GL member's signature(s). If an additional SignedData and/or
         EnvelopedData encapsulates the forwarded response request (see paragraph 3.2.1.2
         or 3.2.2), the GLO GLA MUST verify the outer signature and/or
         decrypt the outer layer prior to verifying the signature on signature on
         the inner most SignedData.

     2.a - If the signature(s) does(do) not verify, the GLA MUST return
           a cMCStatusInfo response indicating cMCStatus.failed and
           otherInfo.failInfo.badMessageCheck.

     2.b - If the signature(s) does(do) verify, the GLA MUST make sure
           the GL is supported by checking  that the inner most SignedData. indicated GL name
           matches a glName stored on the GLA.

     2.b.1 - If the signatures do glName is not verify, supported by the GLO GLA, the GLA MUST
             return a response indicating CMCFailInfo.badMessageCheck.

       b
             glFailInfo.errorCode.invalidGLName.

     2.b.2 - If the signatures verifies, glName is supported by the GLO knows GLA, the GLA has
           successfully rekeyed MUST check
             who signed the GL.

4.6 Change GLO

   Management request. For GLOs, one of managed and closed GLs can become difficult for the names in the

Turner                                                              51
             certificate used to sign the request MUST match a
             registered GLO. For the prospective member, the name in
             glMember.glMemberName MUST match one of the names in the
             certificate used to sign the request.

     2.b.2.a - If the GLO if signed the GL membership grows large. To support distributing request, the
   workload, GLAs support having GL be managed by multiple GLOs. The
   GLAddOwners and GLRemoveOwners messages are designed GLA MUST generate a
               glKey message as described in paragraph 5 to support
   adding and removing registered GLOs. rekey the
               GL (4 in Figure depicts 9).

     2.b.2.b - If anyone else signed the protocol
   interactions to send GLAddOwners and GLRemoveOwners messages and request, the
   resulting response messages.

                      +-----+   1    2  +-----+
                      | GLA | <-------> | MUST forward
               the glkCompromise message (see paragraph 3.2.3) to the
               GLO |
                      +-----+           +-----+ (2{1} in Figure 8 _ 9). If there is more than one GLO,
               to which GLO Add & Delete Owners

Turner                                                              45 the request is forwarded is beyond the
               scope of this document. Further processing by the GLO is
               discussed in paragraph 4.7.2.

4.7.2 GLO Initiated KEK Compromise Message

   The process for GLAddOwners and GLDeleteOwners GLO initiated glkCompromise messages is as follows:

     1 - The GLO sends either:

     1.a - Generates the glkCompromise message itself by sending a SignedData.PKIData.controlSequence.GLAddOwners
         or GLRemoveOwners
           SignedData.PKIData.controlSequence.glkCompromise request to
           the GLA (1 (5 in Figure 8). 9). The GLO MUST include: include the GL name in glName, of
           the GLO(s) GL in glOwner.
         The GLO MAY also include the glIdentifier.

       a GeneralName.

     1.a.1 - The GLO MAY optionally apply confidentiality to the
             request by encapsulating the SignedData.PKIData in an
             EnvelopedData (see paragraph 3.2.1.2).

       b The glkCompromise
             MUST NOT be included in an EnvelopedData generated with
             the compromised shared KEK.

     1.a.2 - The GLO MAY also optionally apply another SignedData over
             the EnvelopedData (see paragraph 3.2.1.2).

     2 _ Upon receipt of the GLAddOwners or GLRemoveOwners request,

     1.b - Verifies the
         GLA verifies GLA's and GL member's signatures on the GLO's signature(s).
           forwarded glkCompromise message. If an additional SignedData
           and/or EnvelopedData encapsulates the request (see paragraph
           3.2.1.2 or 3.2.2), the GLA GLO MUST verify the outer signature
           and/or decrypt the outer layer prior to verifying the
           signature on the inner most SignedData.

       a - If the signature(s) does(do) not verify, the GLA MUST return
           a response indicating CMCFailInfo.badMessageCheck.

       b - If the signature(s) does(do) verify, the GLA MUST make sure
           the GL is supported by checking either that the glName is
           supported (in the case the glIdentifier is omitted) or that
           the combination of glName and glIdentifier matches a glName
           and glIdentifier combination stored on the GLA.

         1 - If the glIdentifier is omitted and the glName is not
             supported by the GLA, the GLA MUST return a response
             indicating GLFailInfo.errorCode.invalidGLName.

         2

     1.b.1 - If the glName and glIdentifier are present and signatures do not
             match a GL stored on the GLA, the GLA MUST return a
             response indicating
             GLFailInfo.errorCode.invalidGLNameGLIdentifierCombination.

         3 - If the glIdentifier is omitted and the glName is supported
             by the GLA or if the glIdentifier/glName combination is
             supported by the GLA, verify, the GLA MUST ensure a registered GLO
             signed the GLAddOwners or GLRemoveOwners request by
             checking if the name present in the digital signature
             certificate used to sign the GLDelete request matches one
             of the registered GLOs.

           a - If the names do not match, the GLA MUST return a
             cMCStatusInfo response indicating GLFailInfo.errorCode.noGLONameMatch.

           b cMCStatus.failed and
             otherInfo.failInfo.badMessageCheck.

     1.b.2 - If the names do match, the GLA MUST return to all GLOs a
               GLSucessInfo indicating the glName, the corresponding

Turner                                                              46
               glIdentifier, an action.actionCode.addedGLO or
               removedGLO, and signatures do verify, the respective GLO name in glOwnerName
               (2 MUST determine
             whether to forward the glkCompromise message back to the
             GLA (3{1} in Figure 4). The 9). Further processing by the GLA MUST is
             in 2 of paragraph 4.7.1. The GLO MAY also take administrative
               actions to associate return a the new glOwner name

Turner                                                              52
             prospective member with cMCStatusInfo.cMCtatus.success
             indicating that the glkCompromise message was successfully
             received.

4.8 Request KEK Refresh

   There will be times when GL in
               the case members have misplaced their shared KEK.
   The shared KEK is not compromised and a rekey of GLAddOwners or the entire GL is
   not necessary. GL members use the glkRefresh message to disassociate request that
   the old
               glOwner name with shared KEK(s) be redistributed to them. Figure 10 depicts the
   protocol interactions for GL in the cased of GLRemoveOwners. Key Refresh.

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

                         Figure 10 - GL KEK Refresh

   The process for glkRefresh is as follows:

     1 - The GLA MUST apply confidentiality GL member sends a
         SignedData.PKIData.controlSequence.glkRefresh request to the response by
                 encapsulating the SignedData.PKIResponse in an
                 EnvelopedData if the request was encapsulated
         GLA (1 in an
                 EnvelopedData (see paragraph 3.2.1.2).

             2 - Figure 10). The GLA MAY also optionally apply another SignedData
                 over GL member MUST include name of the EnvelopedData (see paragraph 3.2.1.2).

       a
         GL in GeneralName.

     1.a - The GLO GL member MAY optionally apply confidentiality to the
           request by encapsulating the SignedData.PKIData in an
           EnvelopedData (see paragraph 3.2.1.2).

       b

     1.b - The GLO GL member MAY also optionally apply another SignedData
           over the EnvelopedData (see paragraph 3.2.1.2).

   3

     2 - Upon receipt of the GLSuccessInfo or GLFailInfo response, glkRefresh request, the
       GLO GLA verifies the GLA's
         GL member's signature(s). If an additional SignedData and/or
         EnvelopedData encapsulates the response request (see paragraph 3.2.1.2
         or 3.2.2), the GLO GLA MUST verify the outer signature and/or
         decrypt the outer layer prior to verifying the signature signature on
         the inner most SignedData.

     2.a - If the signature(s) does(do) not verify, the GLA MUST return
           a cMCStatusInfo response indicating cMCStatus.failed and
           otherInfo.failInfo.badMessageCheck.

     2.b - If the signature(s) does(do) verify, the GLA MUST make sure
           the GL is supported by checking that the GL's GeneralName
           matches a glName stored on the inner most SignedData.

     a GLA.

     2.b.1 - If the signature(s) does(do) GL's name is not verify, supported by the GLO GLA, the GLA MUST
             return a response indicating CMCFailInfo.badMessageCheck.

     b
             glFailInfo.errorCode.invalidGLName.

Turner                                                              53
     2.b.2 - If the signatures do verify and glName is supported by the response was
         GLSuccessInfo, GLA, the GLO has successfully added or removed GLA MUST ensure
             the
         GLO.

     c GL member is on the GL.

     2.b.2.a - If the signatures do verify and glMemberName is not present on the GL, the GLA
               MUST return a response was GLFailInfo, indicating
               glFailInfo.errorCode.noSpam.

     2.b.2.b - If the GLO MAY reattempt to add or delete glMemberName is present on the GLO using GL, the
         information provided GLA MUST
               return a glKey message (2 in the GLFailInfo response.

4.7 Indicate KEK Compromise

   The Figure 10) as described in
               paragraph 5.

4.9 GLA Query Request and Response

   There will be certain times when the shared KEK a GLO is compromised. The having trouble setting up
   a GLO because they do not know the algorithm(s) or some other
   characteristic that the GLA supports. There may also be times when
   the prospective GL members
   use the GLKCompromise message or GL members need to tell know something
   about the GLA that (these requests are not defined in the shared KEK
   has document). The
   glaQueryRequest and glaQueryResponse message have been compromised. defined to
   support determining this information. Figure 9 11 depicts the protocol
   interactions for
   GL Key Compromise.

Turner                                                              47 glaQueryRequest and glaQueryResponse.

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

                Figure 9 11 - GL Key Compromise GLA Query Request & Response

   The process for GLKCompromise glaQueryRequest and glaQueryResponse is as follows:

     1 - The GLO, GL member, or prospective GL member sends a
         SignedData.PKIData.controlSequence.GLKCompromise
         SignedData.PKIData.controlSequence.glaQueryRequest request to
         the GLA (1 in Figure 9). 11). The GLO, GL member, or prospective
         GL member MUST include glName and
         MAY include glIdentifier.

       a indicates the information they are interested in
         receiving from the GLA.

     1.a - The GLO, GL member, or prospective GL member MAY optionally
           apply confidentiality to the request by encapsulating the
           SignedData.PKIData in an EnvelopedData (see paragraph
           3.2.1.2).

       b

     1.b - The GLO, GL member, or prospective GL member MAY also
           optionally apply another SignedData over the EnvelopedData
           (see paragraph 3.2.1.2).

     2 _ - Upon receipt of the GLKCompromise requst, glaQueryRequest, the GLA verifies determines if it
         accepts glaQueryRequest messages.

Turner                                                              54
     2.a - If the GLA does not accept glaQueryRequest messages, the GLA
           MUST return a cMCStatusInfo response indicating
           cMCStatus.noSupport and any other information in
           statusString.

     2.b - If the GLA does accept GLAQueryReuests, the GLA MUST verify
           the GLO's, GL member's, or prospective GL member's
           signature(s). If an additional SignedData and/or
           EnvelopedData encapsulates the request (see paragraph
           3.2.1.2 or 3.2.2), the GLA MUST verify the outer signature
           and/or decrypt the outer layer prior to verifying the
           signature on the inner most SignedData.

       a

     2.b.1 - If the signature(s) does(do) not verify, the GLA MUST
             return a cMCStatusInfo response indicating CMCFailInfo.badMessageCheck.

       b
             cMCStatus.failed and otherInfo.failInfo.badMessageCheck.

     2.b.2 - If the signature(s) does(do) verify, the GLA MUST make sure
           the GL is supported by checking either that the glName is
           supported (in the case the glIdentifier is omitted) or that
           the combination of glName and glIdentifier matches return a glName
           and glIdentifier combination stored on
             glaQueryResponse (2 in Figure 11) indicating the GLA.

         1 - If the glIdentifier is omitted and
             requested information if the glName glaRequestType is not supported by the GLA, the GLA MUST
             or return a cMCStatusInfo response indicating GLFailInfo.errorCode.invalidGLName.

         2 - If
             cMCStatus.noSupport if the glName and glIdentifier are present and do glaRequestType is not
             match a GL stored on the GLA, the
             supported.

     2.b.2.a - The GLA MUST return a apply confidentiality to the response indicating
             GLFailInfo.errorCode.invalidGLNameGLIdentifierCombination.

Turner                                                              48 by
               encapsulating the SignedData.PKIResponse in an
               EnvelopedData if the request was encapsulated in an
               EnvelopedData (see paragraph 3.2.1.2).

     2.b.2.b - The GLA MAY also optionally apply another SignedData
               over the EnvelopedData (see paragraph 3.2.1.2).

     3 - If Upon receipt of the glIdentifier is omitted and glaQueryResponse, the glName is supported
             by GLO, GL member, or
         prospective GL member verifies the GLA GLA's signature(s). If an
         additional SignedData and/or EnvelopedData encapsulates the
         response (see paragraph 3.2.1.2 or if 3.2.2), the glIdentifier/glName combination is
             supported by GLO, GL member,
         or prospective GL member MUST verify the GLA, outer signature
         and/or decrypt the GLA MUST ensure outer layer prior to verifying the GL member is
         signature on the GL.

           a inner most SignedData.

     3.a - If one of the names in the certificate used to sign the
               GLKCompromise is signature(s) does(do) not present on the GL, verify, the GLA GLO, GL member,
           or prospective GL member MUST return a cMCStatusInfo
           response indicating
               GLFailInfo.errorCode.noSpam.

           b cMCStatus.failed and
           otherInfo.failInfo.badMessageCheck.

     3.b - If one of the names in signatures do verify and the certificate used to sign response was
           glaQueryResponse, the
               GLKCompromise is present on GLO, GL member, or prospective GL
           member may use the GL, information contained therein.

Turner                                                              55

4.10 Update Member Certificate

   When the GLA MUST:

             1 _ Generate GLO generates a PKIData.cmsSequence for all GLOs (2 in
                 Figure 9) containing glAddMember request, when the original GLKCompromise
                 message and GLA generates
   a PKIResponse.GLSuccessInfo indicating glKey message, or when the
                 glName, new glIdentifier, and an action.actionCode of
                 rekeyedGL.

             2 _ Generate GLA processes a GLKey message as described in paragraph
                 5.1.2 to rekey the GL (3 in Figure 9)

4.8 Request KEK Refresh

   The will glAddMember there may
   be times instances when the GL members have misplaced their shared
   KEK. member's certificate has expired or is invalid.
   In this these instances the shared KEK is not compromised and a rekey of GLO or GLA may request that the
   entire GL is not necessary. The GL members use member
   provide a new certificate to avoid the GLKRefresh
   message GLA from being unable to request that
   generate a glKey message for the shared KEK(s) GL member. There may also be redistributed to them.
   Figure 10 depicts times
   when the protocol interactions for GL Key Refresh.

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

                         Figure 10 - member knows their certificate is about to expire or has
   been revoked and they will not be able to receive GL KEK Refresh rekeys.

4.10.1 GLO and GLA Initiated Update Member Certificate

   The process for GLKRefresh GLO initiated glUpdateCert is as follows:

     1 - The GL member GLO or GLA sends a
         SignedData.PKIData.controlSequence.GLKRefresh
         SignedData.PKIData.controlSequence.glProvideCert request to
         the
         GLA (1 in Figure 10). GL member. The GLO or GLA indicates the GL member MUST include name in glName
         and
         MAY include glIdentifier.

Turner                                                              49
       a the GL member's name in glMemberName.

     1.a - The GL member GLO or GLA MAY optionally apply confidentiality to the
           request by encapsulating the SignedData.PKIData in an
           EnvelopedData (see paragraph 3.2.1.2).

       b If the GL member's
           PKC has been revoked, the GLO or GLA MUST NOT use it to
           generate the EnvelopedData that encapsulates the
           glProvideCert request.

     1.b - The GL member GLO or GLA MAY also optionally apply another SignedData
           over the EnvelopedData (see paragraph 3.2.1.2).

     2 _ - Upon receipt of the GLKRefresh request, glProvideCert message, the GLA GL member
         verifies the
         GL member's GLO's or GLA's signature(s). If an additional
         SignedData and/or EnvelopedData encapsulates the request (see paragraph 3.2.1.2
         or 3.2.2), the GLA MUST verify the outer signature and/or
         decrypt the outer layer prior to verifying the signature on
         the inner most SignedData.

       a - If the signature(s) does(do) not verify, the GLA MUST return
           a response indicating CMCFailInfo.badMessageCheck.

       b - If the signature(s) does(do) verify, the GLA MUST make sure
           the GL is supported by checking either that the glName is
           supported (in the case the glIdentifier is omitted) or that
           the combination of glName and glIdentifier matches a glName
           and glIdentifier combination stored on the GLA.

         1 - If the glIdentifier is omitted and the glName is not
             supported by the GLA, the GLA MUST return a response
             indicating GLFailInfo.errorCode.invalidGLName.

         2 - If the glName and glIdentifier are present and do not
             match a GL stored on the GLA, the GLA MUST return a
             response indicating
             GLFailInfo.errorCode.invalidGLNameGLIdentifierCombination.

         3 - If the glIdentifier is omitted and the glName is supported
             by encapsulates the GLA response (see
         paragraph 3.2.1.2 or if 3.2.2), the glIdentifier/glName combination is
             supported by GL member MUST verify the GLA,
         outer signature and/or decrypt the GLA MUST ensure outer layer prior to
         verifying the GL member is signature on the GL.

           a inner most SignedData.

     2.a - If the glMemberName is signature(s) does(do) not present on the GL, verify, the GLA GL member MUST
           return a cMCStatusInfo response indicating
               GLFailInfo.errorCode.noSpam.

           b cMCStatus.failed
           and otherInfo.failInfo.badMessageCheck.

     2.b - If the glMemberName is present on the GL, signature(s) does(do) verify, the GLA MUST
               return a GLKey message (2 in Figure 10) as described in
               paragraph 5.1.3.

4.9 GLA Query Request and Response

   There will be certain times when a GLO is having trouble setting up GL member generates
           a GLO because they do not know Signed.PKIResponse.controlSequence.glUpdateCert that MUST
           include the algorithm(s) or distribution
   method(s) GL name in glName, the GLA supports. member's name in
           glMember.glMemberName, their encryption certificate in
           glMember.certificates.membersPKC. The GLAQueryRequest GL member MAY also
           include any attribute certificates associated with their
           encryption certificate in glMember.certificates.membersAC,
           and GLAQueryResponse
   message have been defined to support the GLO determining this

Turner                                                              50
   information.  Figure 11 depicts the protocol interactions for
   GLAQueryRequest and GLAQueryResponse.

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

                Figure 11 - GLA Query Request & Response

   The process for GLAQueryRequest certification path associated with their encryption
           and GLAQueryResponse is as follows:

     1 - The GLO sends a
         SignedData.PKIData.controlSequence.GLAQueryRequest request to
         the GLA (1 in Figure 11). The GLO indicates whether they are
         interested attribute certificates in determining what algorithms the GLA supports or
         what distributionMethods the GLA support or both.

       a
           glMember.certificates.certificationPath.

Turner                                                              56
     2.a - The GLO GL member MAY optionally apply confidentiality to the
           request by encapsulating the SignedData.PKIData SignedData.PKIResponse in an
           EnvelopedData (see paragraph 3.2.1.2).

       b If the GL member's
           PKC has been revoked, the GL member MUST NOT use it to
           generate the EnvelopedData that encapsulates the
           glProvideCert request.

     2.b - The GLO GL member MAY also optionally apply another SignedData
           over the EnvelopedData (see paragraph 3.2.1.2).

     2 _

     3 - Upon receipt of the GLQueryRequest, the GLA determines if it
         accepts GLAQueryRequests.

       a - If the GLA does not accept GLAQueryRequests, the GLA MUST
           return a response indicating GLFailInfo.unspecified.

       b - If the GLA does accept GLAQueryReuests, glUpdateCert message, the GLO or GLA MUST verify
         verifies the GLO's GL member's signature(s). If an additional
         SignedData and/or EnvelopedData encapsulates the request response (see
         paragraph 3.2.1.2 or 3.2.2), the GLA GL member MUST verify the
         outer signature and/or decrypt the outer layer prior to
         verifying the signature on the inner most SignedData.

         1

     3.a - If the signature(s) does(do) not verify, the GLO or GLA MUST
           return a cMCStatusInfo response indicating CMCFailInfo.badMessageCheck.

         2 cMCStatus.failed
           and otherInfo.failInfo.badMessageCheck.

     3.b - If the signature(s) does(do) verify, the GLO or GLA MUST
           verify the member's encryption certificate.

     3.b.1 - If the member's encryption certificate does not verify,
             the GLO MAY return either another glProvideCert request or
             a
             GLAQueryResponse (2 cMCStatusInfo with cMCStatus.failed and the reason why
             in Figure 11) indicating cMCStatus.statusString. glProvideCert should be
             returned only a certain number of times because if the GL
             member does not have a valid certificate they will never
             be able to return one.

     3.b.2 - If the member's encryption certificate does not verify,
             the GLA MAY return another glProvideCert request to the GL
             member or a cMCStatusInfo 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 they will never be able to return one.

     3.b.3 - If the
             supportedAlgorithms, member's encryption certificate does verify, the distributionMethod,
             GLO or both. 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 MUST include
         the GL name in glName, the member's name in

Turner                                                              57
         glMember.glMemberName, their encryption certificate in
         glMember.certificates.membersPKC. The GL member MAY also
         include any attribute certificates associated with their
         encryption certificate in glMember.certificates.membersAC, and
         the certification path associated with their encryption and
         attribute certificates in
         glMember.certificates.certificationPath.

     1.a - The GLA MUST GL member MAY optionally apply confidentiality to the response
           request by encapsulating the SignedData.PKIResponse in an
               EnvelopedData if the request was encapsulated SignedData.PKIData in an
           EnvelopedData (see paragraph 3.2.1.2).

           b If the GL member's
           PKC has been revoked, the GLO or GLA MUST NOT use it to
           generate the EnvelopedData that encapsulates the
           glProvideCert request.

     1.b - The GLA GL member MAY also optionally apply another SignedData
           over the EnvelopedData (see paragraph 3.2.1.2).

Turner                                                              51
     3

     2 - Upon receipt of the GLAQueryResponse, glUpdateCert message, the GLO GLA verifies the
         GLA's
         GL member's signature(s). If an additional SignedData and/or
         EnvelopedData encapsulates the response (see paragraph 3.2.1.2
         or 3.2.2), the GLO GLA MUST verify the outer signature and/or
         decrypt the outer layer prior to verifying the signature on
         the inner most SignedData.

       a

     2.a - If the signature(s) does(do) not verify, the GLO GLA MUST return
           a cMCStatusInfo response indicating CMCFailInfo.badMessageCheck.

       b cMCStatus.failed and
           otherInfo.failInfo.badMessageCheck.

     2.b - If the signatures do signature(s) does(do) verify, the GLA MUST verify and the response was
           GLAQueryResponse,
           member's encryption certificate.

     2.b.1 - If the GLO may use member's encryption certificate does not verify,
             the information contained
           therein GLA MAY return another glProvideCert request to attempt the GL
             member or a cMCStatusInfo with cMCStatus.failed and the
             reason why in cMCStatus.statusString to setup the GLO.
             glProvideCert should be returned only a certain number of
             times because if the GL or modify an existing GL. member does not have a valid
             certificate they will never be able to return one.

     2.b.2 - If the member's encryption certificate does verify, the
             GLA will use it in subsequent glAddMember requests and
             glKey messages associated with the GL member. The GLA MUST
             also forward the glUpdateCert message to the GLO.

5 Distribution Message

   The GLA uses the GLKey glKey message to distribute new, shared KEK(s)
   after receiving GLAddMembers, GLDeleteMembers glAddMember, glDeleteMember (for closed and managed
   GLs), GLRekey, GLKCompromise, glRekey, glkCompromise, or GLKRefresh glkRefresh requests and returning a GLSucessInfo
   glSuccessInfo response for the respective request. Figure 12 depicts

Turner                                                              58
   the protocol interactions to send out GLKey glKey messages. The procedures
   defined in this paragraph MUST be implemented.

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

                   Figure 12 - GL Key Distribution

   If the GL was setup with GLKeyAttributes.recipientsMutuallyAware set
   to FALSE, a separate GLKey glKey message MUST be sent to each GL member so
   as to not divulge information about the other GL members.

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

     - GLAddMembers glAddMember request,
     - GLKComrpomise indicate, glkComrpomise indication,
     - GLKRefresh glkRefresh request,
     - GLDeleteMembers glDeleteMember request with the the GL's glAdministration set to
       managed or closed,
     - GLKRekey glRekey request with generationCounter set to zero (0)

   The GLA MUST use either the kari (see paragraph 12.3.2 of CMS [2])
   or ktri (see paragraph 12.3.1 of CMS [2]) choice in
   GLKey.glkWrapped.RecipientInfo
   glKey.glkWrapped.RecipientInfo to ensure only the intended

Turner                                                              52
   recipients receive the shared KEK. The GLA MUST support the
   RecipientInfo.kari kari
   choice.

   When the GLKey glKey message is generated as a result of a GLRekey glRekey request
   with generationCounter greater than zero (0) or when the GLA
   controls rekeys, the GLA MAY use the kari, ktri, or kekri (see
   paragraph 12.3.3 of CMS [2]) in GLKey.glkWrapped.RecipientInfo glKey.glkWrapped.RecipientInfo to
   ensure only the intended recipients receive the shared KEK. The GLA
   MUST support the RecipientInfo.kari choice.

5.1 Distribution Process

   When a GLKey glKey message is generated the process is as follows:

     1 _ - The GLA MUST send a SignedData.PKIData.controlSequence.GLKey SignedData.PKIData.controlSequence.glKey
         to each member by including: glName, glIdentifier, glkWrapped,
         glkAlgorithm, glkNotBefore, and glkNotAfter.

         **Need to be more detailed on how the values are derived as it
           depends on why and when If the GLKey GLA can
         not generate a glKey message for the GL member because the GL
         member's PKC has expired or is invalid, the GLA MAY send a

Turner                                                              59
         glUpdateCert to the GL member requesting a new certificate be
         provided (see paragraph 4.10). The number of glKey messages
         generated for the GL is generated**

       a described in paragraph 3.1.16.

     1.a - The GLA MAY optionally apply another confidentiality layer
           to the message by encapsulating the SignedData.PKIData in
           another EnvelopedData (see paragraph 3.2.1.2).

       b

     1.b - The GLA MAY also optionally apply another SignedData over
           the EnvelopedData.SignedData.PKIData (see paragraph
           3.2.1.2).

     2 - Upon receipt of the message, the GL members MUST verify the
         signature over the inner most SignedData.PKIData. If an
         additional SignedData and/or EnvelopedData encapsulates the
         message (see paragraph 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.

       a
         SignedData.PKIData.controlSequence.glKey.

     2.a - If the signature(s) does(do) not verify, the GL member MUST
           return a cMCStatusInfo response indicating CMCFailInfo.badMessageCheck.

       b cMCStatus.failed
           and otherInfo.failInfo.badMessageCheck.

     2.b - If the signature(s) does(do) verify, the GL member process
           the RecipientInfos according to CMS [2]. 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.

6 Key Wrapping Algorithms

   This section lists the algorithms that must be implemented.
   Additional algorithms that should be implemented are also included.

6.1 KEK Generation Algorithm

   The shared KEK MUST be generated according to the security
   considerations paragraph in CMS [2].

6.2 Shared KEK Wrap Algorithm

   In the mechanisms described in paragraphs 5, the group key shared KEK being
   distributed,
   distributed in an EnvelopedData, glkWrapped MUST be protected by a key of equal or
   greater length (i.e., if a RC2 128-bit key is being

Turner                                                              53 distributed a
   key of 128-bits or greater must be used to protect the key).

7 Algorithms

   Triple-DES is mandatory other are optional.

8 Transport

   SMTP must be supported.

9 Using the Group Key

   [Put in here how this can be used with SMIME MLAs.]

10 Schema Requirements

   [I think we need to specify some MAYs for support of

   The algorithm object classes,
   etc. to support location of the GL and GLO identifiers included in a repository. There glkWrapped are really two choices for the GL mhsDistributionList from RFC 1274
   and addresslist from an Internet-Draft as
   specified in the LDAPEXT WG. The only
   reason I can think 12.3 of not using the one from RFC 1274 is that a MUST
   CONTAIN is mhsORAddress CMS [2].

Turner                                                              60

6.3 Shared KEK Algorithm

   The shared KEK distributed and we're should indicated in glkAlgorithm MUST
   support SMTP. addressList
   (in the ID) doesn't have mhsORAddress symmetric key-encryption algorithms as a must contain. The Owner specified in the both object classes though has the syntax directoryName. We
   might have to roll attribute for the Owner because I think it should
   probably have the GeneralName syntax instead
   paragraph 12.3.3 of just directoryName.]

   [We can also define attributes that can CMS [2]

7 Transport

   SMTP [7] MUST be used to store the group
   key encrypted for an individual group member and for supported. All other transport mechanisms MAY be
   supported.

8 Using the encrypted
   object. Does anyone think this is useful/needed?]

11 Group Key

   TBSL

9 Security Considerations

   Don't have too many GLOs because they could start willie nillie
   adding people you don't like.

   Need to rekey closed and managed GLs if a member is deleted.

   GL members have to store some kind of information about who
   distributed the shared KEK to them so that they can make sure
   subsequent rekeys are originated from the same entity.

   Need to make sure you don't make the key size too small and duration
   long because people will have more time to attack the key.

   Need to make sure you don't make the generationCounter to large
   because then people can attack the last key.

Turner                                                              54

12 If there are 14 keys
   outstanding each with a year's duration attackers might be able
   determine the 14th key.

10 References

   1  Bradner, S., "The Internet Standards Process -- Revision 3", BCP
      9, RFC 2026, October 1996.

   2  Housley, R., "Cryptographic Message Syntax," RFC 2630, June 1999.

   3  Myers, M., Liu, X., Schadd, J., Weinsten, J., "Certificate
      Management Message over CMS," draft-ietf-pkix-cmc-05.txt, July
      1999.

Turner                                                              61
   4  Bradner, S., "Key words for use in RFCs to Indicate Requirement
      Levels", BCP 14, RFC 2119, March 1997.

   5  Ramsdale, B., "S/MIME Version 3 Message Specification," RFC 2633,
      June 1999.

   6  Housley, R., Ford, W., Polk, W. and D. Solo, "Internet X.509
      Public Key Infrastructure: Certificate and CRL Profile", RFC
      2459, January 1999.

13

   7  Postel, j., "Simple Mail Transport Protocol," RFC 821, August
      1982.

11 Acknowledgements

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

14

12 Author's Addresses

   Sean Turner
   IECA, Inc.
   9010 Edgepark Road
   Vienna, VA 22182
   Phone: +1.703.628.3180
   Email: turners@ieca.com

   Expires January 14, April 2001

Turner                                                              55                                                              62