SMIME Working Group                                           S. Turner
Internet Draft                                                     IECA
Document: draft-ietf-smime-symkeydist-02.txt           October 31, 2000 draft-ietf-smime-symkeydist-03.txt              March 2, 2001
Expires:  April  September 2, 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 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....................................................5
   3. PROTOCOL INTERACTIONS...........................................6
   3.1 CONTROL ATTRIBUTES.............................................7
   3.1.1 GL USE KEK...................................................8
   3.1.2 GL DELETE...................................................10 DELETE GL...................................................11
   3.1.3 GL ADD MEMBER...............................................10
   3.1.4 GL MEMBER...............................................11
   3.1.4 DELETE MEMBERS...........................................11
   3.1.5 GL REKEY....................................................12 MEMBER............................................12
   3.1.5 REKEY GL....................................................13
   3.1.6 GL ADD OWNER................................................13
   3.1.7 GL OWNER................................................14
   3.1.7 REMOVE OWNER.............................................13 GL OWNER.............................................14
   3.1.8 GL KEY COMPROMISE...........................................14
   3.1.9 GL KEY REFRESH..............................................14 REFRESH..............................................15
   3.1.10 GL SUCCESS INFORMATION.....................................14 INFORMATION.....................................15
   3.1.11 GL FAIL INFORMATION........................................15 INFORMATION........................................16
   3.1.12 GLA QUERY REQUEST..........................................17 REQUEST..........................................18
   3.1.13 GLA QUERY RESPONSE.........................................17 RESPONSE.........................................18
   3.1.14 GL PROVIDE CERT............................................17 CERT...............................................19
   3.1.15 GL UPDATE CERT.............................................18 CERT................................................20
   3.1.16 GL KEY.....................................................19 KEY.....................................................21
   3.2 USE OF CMC, CMS, AND PKIX.....................................20 PKIX.....................................22
   3.2.1 PROTECTION LAYERS...........................................20 LAYERS...........................................22
   3.2.1.1 MINIMUM PROTECTION........................................21 PROTECTION........................................23
   3.2.1.2 ADDITIONAL PROTECTION.....................................21 PROTECTION.....................................23
   3.2.2 COMBINING REQUESTS AND RESPONSES............................21 RESPONSES............................23
   3.2.3 GLA GENERATED MESSAGES......................................23 MESSAGES......................................25
   3.2.4 CMC CONTROL ATTRIBUTES......................................24 ATTRIBUTES......................................26
   3.2.5 RESUBMITTED GL MEMBER MESSAGES..............................26 MESSAGES..............................27
   3.2.6 PKIX........................................................26 PKIX........................................................28
   4 ADMINISTRATIVE MESSAGES.........................................26 MESSAGES.........................................28
   4.1 ASSIGN KEK TO GL..............................................26 GL..............................................28
   4.2 DELETE GL FROM GLA............................................29 GLA............................................31
   4.3 ADD MEMBERS TO GL.............................................31 GL.............................................33
   4.3.1 GLO INITIATED ADDITIONS.....................................32 ADDITIONS.....................................34
   4.3.2 PROSPECTIVE MEMBER INITIATED ADDITIONS......................37 ADDITIONS......................40
   4.4 DELETE MEMBERS FROM GL........................................39 GL........................................42
   4.4.1 GLO INITIATED DELETIONS.....................................40 DELETIONS.....................................43
   4.4.2 MEMBER INITIATED DELETIONS..................................44 DELETIONS..................................47
   4.5 REQUEST REKEY OF GL...........................................45 GL...........................................48
   4.5.1 GLO INITIATED REKEY REQUESTS................................46 REQUESTS................................49
   4.5.2 GLA INITIATED REKEY REQUESTS................................48 REQUESTS................................51
   4.6 CHANGE GLO....................................................48 GLO....................................................52
   4.7 INDICATE KEK COMPROMISE.......................................50 COMPROMISE.......................................54
   4.7.1 GL MEMBER INITIATED KEK COMPROMISE MESSAGE..................51 MESSAGE..................55

Turner                                                               2
   4.7.2 GLO INITIATED KEK COMPROMISE MESSAGE........................52 MESSAGE........................56
   4.8 REQUEST KEK REFRESH...........................................53 REFRESH...........................................57
   4.9 GLA QUERY REQUEST AND RESPONSE................................54 RESPONSE................................58
   4.10 UPDATE MEMBER CERTIFICATE....................................56 CERTIFICATE....................................60
   4.10.1 GLO AND GLA INITIATED UPDATE MEMBER CERTIFICATE............56 CERTIFICATE............60
   4.10.2 GL MEMBER INITIATED UPDATE MEMBER CERTIFICATE..............57 CERTIFICATE..............62
   5 DISTRIBUTION MESSAGE............................................58 MESSAGE............................................63
   5.1 DISTRIBUTION PROCESS..........................................59 PROCESS..........................................64
   6 ALGORITHMS......................................................60 ALGORITHMS......................................................64
   6.1 KEK GENERATION ALGORITHM......................................60 ALGORITHM......................................65
   6.2 SHARED KEK WRAP ALGORITHM.....................................60 ALGORITHM.....................................65
   6.3 SHARED KEK ALGORITHM..........................................61 ALGORITHM..........................................65
   7 TRANSPORT.......................................................61 TRANSPORT.......................................................65
   8 USING THE GROUP KEY.............................................61 KEY.............................................65
   9 SECURITY CONSIDERATIONS.........................................61 CONSIDERATIONS.........................................66
   10 REFERENCES.....................................................61 REFERENCES.....................................................66
   11 ACKNOWLEDGEMENTS...............................................62 ACKNOWLEDGEMENTS...............................................66
   12 AUTHOR'S ADDRESSES.............................................62 ADDRESSES.............................................67

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

     +----------------------------------------------+
     |              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. 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
   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
   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 sections describe the
   ASN.1 for both the administration and distribution messages.
   Paragraph Section
   4 describes how to use the administration messages and
   paragraph section 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 for requests and CMC's 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
   section 3.2). The following are the control attributes defined in
   this document:

         Control
        Attribute          OID          Syntax
   -------------------  ----------- -----------------
    glUseKEK            id-skd 1    GLUseKEK
    glDelete            id-skd 2    GeneralName
    glAddMember         id-skd 3    glAddMember    GLAddMember
    glDeleteMember      id-skd 4    GLDeleteMember
    glRekey             id-skd 5    GLRekey
    glAddOwner          id-skd 6    GLOwnerAdministration
    glRemoveOwner       id-skd 7    GLOwnerAdministration
    glkCompromise       id-skd 8    GeneralName
    glkRefresh          id-skd 9    GeneralName    GLKRefresh
    glSuccessInfo       id-skd 10   GLSuccessInfo
    glFailInfo          id-skd 11   GLFailInfo
    glaQueryRequest     id-skd 12   GLAQueryRequest
    glaQueryResponse    id-skd 13   GLAQueryResponse
    glProvideCert       id-skd 14   GLProvideCert   GLManageCert
    glUpdateCert        id-skd 15   GLUpdateCert   GLManageCert
    glKey               id-skd 16   GLKey

   The

   In the following conformance tables, the column headings have the
   following meanings: O for originate, R for receive, F for forward.
   There are three types of implementations: GLOs, GLAs, and GL
   members. The GLO is an optional component hence all of the implementation requirements messages
   for it are optional and the control
   attributes defined herein: GLO forwarding messages to it or the GL
   member. The first table includes messages that MUST be implemented
   in order to be considered conformant to this document. The second
   table includes messages that MAY be implemented in order to be
   considered conformant to this document.

Turner                                                               7
                             Required
           Implementation Requirement         |  Control
     GLO    |       GLA          | GL Member | Attribute
   O    R   | O   |O      R      F    | O    R    |
   -------- | ------------------  | --------- | ----------
   MAY  N/A | N/A    MAY     N/A  | N/A  N/A  | glUseKEK |------------------  |--------- |----------
   MAY  N/A | N/A   -  |MUST    -     MAY     N/A  | N/A  N/A  | glDelete  -   MUST |glProvideCert
   MAY  MAY | N/A -     MUST   MAY  | N/A MUST  -   |glUpdateCert
    -    -  |MUST    -      -   | glAddMember
   MAY  -   MUST |glKey
    -   MAY |MUST    -      -   | N/A  -   MUST |glSucessInfo
    -   MAY |MUST    -      -   | N/A  -   MUST |glFailInfo

                             Optional
           Implementation Requirement         | glDeleteMember
   MAY  N/A  Control
     GLO    | N/A    MAY     N/A       GLA          | N/A  N/A GL Member | glRekey
   MAY  N/A Attribute
   O    R   |O      R      F    | N/A    MAY     N/A O    R    | N/A  N/A
   -------- |------------------  |--------- |----------
   MAY   -  | glAddOwner -     MAY  N/A     -   | N/A  -    -   |glUseKEK
   MAY     N/A   -  | N/A  N/A -     MAY     -   | glRemoveOwner  -    -   |glDelete
   MAY  MAY | N/A -     MUST   MAY  | MUST N/A  | glkCompromise  -   |glAddMember
   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  -   |glDeleteMember
   MAY  N/A | N/A    SHOULD  N/A   -  | -     MAY  MAY     -   | glaQueryRequest
   N/A  -    -   |glRekey
   MAY   -  | SHOULD N/A     N/A  | -     MAY     -   |  -    -   |glAddOwner
   MAY   -  | glaQueryResponse -     MAY  N/A     -   | MUST   N/A  -    -   |glRemoveOwner
   MAY  MAY | N/A -     MUST | glProvideCert
   N/A   MAY  | N/A MUST  -   |glkCompromise
   MAY   -  | -     MUST N/A  | glUpdateCert
   N/A  N/A    -   | MUST   N/A     N/A  -   |glkRefresh
   MAY   -  | N/A  MUST -     SHOULD  -   | glKey

Turner                                                               7 MAY   -   |glaQueryRequest
    -   MAY |SHOULD  -      -   |  -   MAY  |glaQueryResponse

   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 }

Turner                                                               8
   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
     recipientsNotMutuallyAware [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 GLĘs name in glName and the GL's GLĘs address in
       glAddress. In some instances the glName and glAddress may be the
       same, but this is not always the case. The Both the name and address
       MUST be unique for a given GLA.

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

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

Turner                                                               9
         and glDeleteMember requests from the GLO. It is GL policy as
         to whether to forward the request on to the GLO.

     - glKeyAttributes indicates the attributes the GLO wants the GLA
       to assign to the shared KEK. If this field is omitted, GL rekeys
       will be controlled by the GLA, the recipients are allowed to
       know about one another, the algorithm will 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:

       - rekeyControlledByGLO indicates whether the GL rekey messages
         will be generated by the GLO or by the GLA. The default is for
         the GLA to control rekeys. If GL rekey is controlled by the
         GLA, the GL will continue to be rekeyed until the GLO deletes
         the GL or changes the GL rekey to be GLO controlled.

       - recipientsMutuallyAware recipientsNotMutuallyAware indicates that the GLO wants the
         GLA to distribute the shared KEK individually for each of the
         GL members (i.e., a separate glKey message is sent to each
         recipient). The default is for separate glKey message to not
         be required.

         NOTE: This supports lists where one member does not know the
         identities of the other members. For example, a list is
         configured granting submit permissions to only one member. All
         other members are 'listening.' The security policy of the list
         does not allow the members to know who else is on the list. If

Turner                                                               9
         a glKey is constructed for all of the GL members, information
         about each of the members may be derived from the information
         in RecipientInfos. To make sure the glkey message does not
         divulge information about the other recipients, a separate
         glKey message would be sent to each GL member.

       - duration indicates the length of time (in days) during which
         the shared KEK is considered valid. The value zero (0)
         indicates that the shared KEK is valid for a calendar month. month at
         UTC Zulu time zone. For example if the duration is zero (0),
         if the GL shared KEK is requested on July 24, the first key
         will be valid until the end of July and the next key will be
         valid for the entire month of August. If the value is not zero
         (0), the shared KEK will be valid for the number of days
         indicated by the value. For example, if the value of duration
         is seven (7) and the shared KEK is requested on Monday but not
         generated until Tuesday (2359); the shared KEKs will be valid
         from Tuesday (2359) to Tuesday (2359). The exact time of the
         day is determined when the key is generated.

       - generationCounter indicates the number of keys the GLO wants
         the GLA to distribute. To ensure uninterrupted function of the
         GL two (2) shared KEKs at a minimum MUST be initially

Turner                                                              10
         distributed. The second shared KEK is distributed with the
         first shared KEK, so that when the first shared KEK is no
         longer valid the second key can be used. If the GLA controls
         rekey then it also indicates the number of shared KEKs the GLO
         wants outstanding at any one time. See paragraphs sections 4.5 and 5 for
         more on rekey.

       - requestedAlgorithm indicates the algorithm and any parameters
         the GLO wants the GLA to use to generate with the shared KEK. The
         parameters are conveyed via the SMIMECapabilities attribute
         see MSG {x}. See
         paragraph section 7 for more on algorithms.

3.1.2 GL Delete GL

   GLOs use glDelete to request that a GL be deleted from the GLA. The
   glDelete control attribute shall have the syntax GeneralName. The
   name of the GL to be deleted is included in GeneralName. The
   glDelete message MUST be signed by the GLO.

3.1.3 GL Add GL Member

   GLOs use glAddMember to request addition of new members and
   prospective GL members use glAddMember to request being added to the
   GL. The glAddMember message must be signed by either the GLO or the
   prospective GL member. The glAddMember control attribute shall have
   the syntax GLAddMember:

Turner                                                              10

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

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

   Certificates ::= SEQUENCE {
      membersPKC         Certificate,
      pKC         Certificate OPTIONAL,
                                  -- See X.509
      membersAC
      aC          SEQUENCE SIZE (1.. MAX) OF
                             AttributeCertificate OPTIONAL,
                                  -- See X.509
      certificationPath  CertificateSet OPTIONAL }
                                  -- From CMS [2]

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

Turner                                                              11
   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 following meaning:

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

     - glMember indicates the particulars for the GL member. Both of
       the following fields must be unique for a given GL:

       - glMemberName indicates the name of the GL member and member.

       - glMemberAddress indicates the GL member's memberĘs address. It MUST be
          included.

         Note: In some instances the glMemberName and glMemberAddress
        may be the same, but this is not always the case. certificates.membersPKC

       - certificates MUST be included. It contains the following three
       fields:

         - certificates.pKC includes the member's encryption
           certificate that will be used to at least initially encrypt
           the shared KEK for that member.
       certificates.membersAC If the message is generated
           by a prospective GL member, the pKC MUST be included. If the
           message is generated by a GLO, the pKC SHOULD be included.

         - certificates.aC MAY be included to convey any attribute
           certificate associated with the member's memberĘs encryption
           certificate.

         - certificates.certificationPath MAY also be included to
           convey the certification path corresponding to the member's
           encryption and any non-member attribute certificates. certificates are
           placed in attrCert. The certification path is optional
           because it may already be included elsewhere in the message
           (e.g., in the outer CMS layer).

3.1.4 GL Delete Members GL Member

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

Turner                                                              11 removed from the GL. The
   glDeleteMember message must be signed by either the GLO or the

Turner                                                              12
   prospective GL member. The glDeleteMember control attribute shall
   have the syntax GLDeleteMember:

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

   The fields in GLDeleteMembers have the following meaning:

     - glName indicates the name of the GL from which the member should
       be removed.

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

3.1.5 GL Rekey GL

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

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

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

   The fields in GLRekey have the following meaning:

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

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

     - glNewKeyAttributes indicates whether the rekey of the GLO is
       controlled by the GLA or GL, what algorithm and parameters the
       GLO wishes to use, the duration of the key, and how many
       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

Turner                                                              13
     - glRekeyAllGLKeys indicates whether the GLO is indicating that it wants all of the

Turner                                                              12
       outstanding GL GLĘs shared KEKs rekeyed. For example, suppose the GLO
       used the glUseKEK with duration If it is set to two (2) and the glRekey
       message TRUE then
       all outstanding KEKs MUST be issued. If it is sent during the first duration with generationCounter set to zero (0). The GLA would know FALSE then
       all outstanding KEKs need not be resissued.

3.1.6 Add GL Owner

   GLOs use the glAddOwner to generate a glKey message
       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 glAddOwner to request that request that a new GLO be allowed to
   administer the GL. In addition, a registered GLO may use the request
   to update their certificate on the 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 {
     glName       GeneralName,
     glOwnerInfo  GLOwnerInfo }

   The fields in GLAddOwners have the following meaning:

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

     - glOwnerInfo indicates the name and address of the new GLO.

3.1.7 GL Remove GL Owner

   GLOs use the glRemoveOwner to request that a GLO be disassociated
   with the GL. The glRemoveOwner message MUST be signed by a
   registered GLO. Unmanaged GLs may only have one GLO. If the GLA processes a
   glRemoveOwner for an unmanaged GL, only one GLO shall be associated
   with the GL at any given time. The glRemoveOwner control attribute shall have the
   syntax GLOwnerAdministration:

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

   The fields in GLRemoveOwners have the following meaning:

     - glName indicates the name of the GL to which the GLO should be
       disassociated.

     - glOwnerInfo indicates the name and address of the GLO to be
       removed.

Turner                                                              13

3.1.8 GL Key Compromise

   GL members and GLOs use glkCompromise to indicate that the shared
   KEK possessed has been compromised. The glKeyCompromise control
   attribute shall have the syntax GeneralName. The name of the GL to
   which the compromised key is associated with is included in
   GeneralName. This message is always redirected by the GLA to the GLO

Turner                                                              14
   for further action. The glkCompromise MUST NOT be included in an
   EnvelopedData generated with the compromised shared KEK.

3.1.9 GL Key Refresh

   GL members use the glkRefresh to request that the shared KEK be
   redistributed to them. The glKeyRefresh glkRefresh control attribute shall have
   the syntax GeneralName. GLKRefresh.

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

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

   The fields in GLKRefresh have the following meaning:

     - glName indicates the name of the GL for which the GL member includes
       wants shared KEKs.

     - dates indicates a date range for keys the GL's name in
   GeneralName. GL member wants. The
   start field indicates the first date the GL member wants and the end
   field indicates the last date. The end date MAY be omitted to
   indicate the GL member wants all keys from the specified start date
   to the current date. It should be noted that a procedural mechanism
   will be needed to restrict users from accessing messages that they
   are not allowed to access.

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 {
     glInfo       GLInfo,
     glIdentifier GLIdentifier,
     action       Action }

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

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

   The fields in GLSuccessInfo have the following meaning:

     - glInfo indicates the GL's GLĘs name in glName and the GL's GLĘs address in
       glAddress.

Turner                                                              14

     - glIdentifier identifies GL's GLĘs unique shared KEK.

     - action indicates the 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 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 a GL or deleted from a
       GL the members MUST be indicated in glMemberName and glOwnerName
       MUST be omitted. If a GLO was added to a GL or deleted from a
       GL, the GLO MUST be indicated in glOwnerName and glMemberName
       MUST be omitted. If a shared KEK was assigned to a GL or a GL
       was deleted both glOwnerName and glMember glMemberName MUST be omitted.

3.1.11 GL Fail Information

   The GLA uses glFailInfo to indicate that there was a 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,
     error         Error }

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

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

Turner                                                              15

   The fields in GLFailInfo have the following meaning:

     - glName indicates the name of the GL to which the error
       corresponds.

     - error indicates the reason why the GLA was unable to perform the
       request. It also indicates the GL member or GLO to which the
       error corresponds. If members were not added to a GL or deleted
       from a GL the members MUST be indicated in glMemberName. If a
       GLO was not added to a GL or deleted from a GL, the GLO MUST be
       indicated in glOwnerName. The errors are returned under the
       following conditions:

       - unspecified indicates that the GLA is unable or unwilling to
         perform the requested action and does not want to indicate
         why.

       - closedGL indicates that members can only be added or deleted
         by the GLO.

       - unsupportedDuration indicates the GLA does not support
         generating keys that are valid for the requested duration.

       - noGLACertificate indicates that the GLA does not have a valid
         certificate.

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

       - unsupportedAlgorithm indicates the GLA does not support the
         requested algorithm.

Turner                                                              17
       - noGLONameMatch indicates that one of the names in the
         certificate used to sign a request does not match the name of
         a registered GLO.

       - invalidGLName indicates the GLA does not support the glName
         present in the request.

       - nameAlreadyInUse indicates the glName is already assigned on
         the GLA.

       - noSpam indicates the prospective GL member did not sign the
         request (i.e., if the name in glMember.glMemberName does not
         match one of the names in the certificate used to sign the
         request).

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

Turner                                                              16

       - notAMember indicates the prospective non-GL member is not a GL
         member.

       - alreadyAnOwner indicates the prospective GLO is already a GLO.

       - notAnOwner indicates the prospective non-GLO is not a GLO.

3.1.12 GLA Query Request

   GLOs and GL members use the glaQueryRequest to ascertain information
   about the GLA. The 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 support the GLO in determining
   the 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 GLO wishes to know the
   algorithms that the GLA supports.

3.1.13 GLA Query Response

   GLA's

   GLAĘs return the glaQueryResponse after receiving a GLAQueryRequest.
   The glaQueryResponse MUST be signed by a GLA. The glaQueryResponse
   control attribute shall have the syntax GLAQueryResponse:

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

   One response type is defined herein for the GLA to indicate the
   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 signed by either GLA or GLO. If the GL member's 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 GLManageCert:

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

   The fields in GLProvideCert GLManageCert have the following meaning:

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

     - glMemberName glMember indicates name of particulars for the GL member.

3.1.15 member:

       - glMemberName indicates the GL memberĘs name.

       - glMemberAddress indicates the GL memberĘs address. It MAY be
       omitted.

       - certificates SHOULD be omitted.

Turner                                                              19

3.1.15 Update Cert

   GL members and GLOs use glUpdateCert to provide a new certificate
   for the GL. GL members may generate a glUpdateCert unsolicited or as
   a result of a glProvideCert message. GL members MUST sign the
   glUpdateCert. If the GL member's memberĘs encryption certificate has been
   revoked, the GL member MUST NOT use it to generate the EnvelopedData
   that encapsulates the glUpdateCert request or response. The
   glUpdateCert control attribute shall have the syntax GLUpdateCert:

   GLUpdateCert GLManageCert:

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

   The fields in GLUpdateCert GLManageCert have the following meaning:

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

     - glMemberCert glMember indicates the particulars for the GL member. member:

       - glMemberName indicates the GL member's memberĘs name and

       - glMemberAddress indicates the GL member's memberĘs address. certificates.membersPKC It MAY be
       omitted.

       - certificates MAY be omitted if the GLManageCert message is
       sent to request the GL members certificate; else it MUST be
       included. It includes the following three fields:

         - certificates.pKC includes the member's encryption
       certificate that will be used to encrypt the shared KEK for that
       member.
       certificates.membersAC

         - certificates.aC MAY be included to convey any attribute
       certificate associated with the member's 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 certification path is
       optional because it may already be included elsewhere in the
       message (e.g., in the outer CMS layer).

Turner                                                              18                                                              20

3.1.16 GL Key

   The GLA uses glKey to distribute the shared KEK. The glKey message
   MUST be signed by the GLA. The glKey control attribute shall have
   the 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 following meaning:

     - glName is the name of the GL.

     - glIdentifier is the key identifier of the shared KEK. When GL
       members use the shared KEK to encrypt data objects for other GL
       members, they place the glIdentifier in
       RecipientInfo.kekri.kekid.keyIdentifier field. Two There are many
       ways to do this here are two options are provided to generate a
       unique key identifier. The first choice concatenates the GLA's GLAĘs
       subject name from the digital signature certificate used to sign
       the glKey message and counter. The second choice concatenates
       the GLA's GLAĘs subjectKeyIdentifier, from the digital signature
       certificate used to sign the glKey message, and a counter. The second choice must be supported.

     - glkWrapped is the GL's wrapped shared KEK. The RecipientInfos
       shall be generated as specified in paragraph section 6.2 of CMS [2]. The
       kari
       ktri RecipientInfo choice MUST be supported. The key in the
       EncryptedKey
       field, which is field (i.e., the distributed shared KEK, KEK) MUST be
       generated according to the paragraph section concerning random number
       generation in the security considerations of CMS [2].

     - glkAlgorithm identifies the algorithm the shared KEK is used
       with. The parameters are conveyed via the SMIMECapabilities
       attribute see MSG {x}.

     - glkNotBefore indicates the date at which the shared KEK is
       considered valid. GeneralizedTime values MUST be expressed UTC
       (Zulu) and MUST include seconds (i.e., times are
       YYYYMMDDHHMMSSZ), even where the number of seconds is zero.
       GeneralizedTime values MUST NOT include fractional seconds.

     - glkNotAfter indicates the date after which the shared KEK is
       considered invalid. GeneralizedTime values MUST be expressed UTC
       (Zulu) and MUST include seconds (i.e., times are
       YYYYMMDDHHMMSSZ), even where the number of seconds is zero.
       GeneralizedTime values MUST NOT include fractional seconds.

Turner                                                              19                                                              21
   If the glKey message is in response to a glUseKEK message:

     - The GLA MUST generate separate glKey messages for each recipient
       if glUseKEK.glKeyAttributes.recipientMutuallyAware glUseKEK.glKeyAttributes.recipientsNotMutuallyAware is set to
       FALSE. For each recipient you want to generate a message that
       contains that recipientĘs key (i.e., one message with one
       attribute).

     - The GLA MUST generate X number of glKey messages, where X is the
       value in glUseKEK.glKeyAttributes.generationCounter.

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

     - The GLA MUST generate separate glKey messages for each recipient
       if glRekey.glNewKeyAttributes.recipientMutuallyAware glRekey.glNewKeyAttributes.recipientsNotMutuallyAware is set
       to FALSE.

     - The GLA MUST generate X number of glKey messages, where X is the
       value in glUseKEK.glKeyAttributes.generationCounter. If the
       value is zero (0), the

     - The GLA MUST generate X number of glKey messages, where X is the
       number of outstanding shared KEKs for the GL (e.g., if there are two outstanding shared KEK and the
       generationCounter for the glUseKEK message was glRekeyAllGLKeys
       is set to three then
       two glKey messages are generated). TRUE.

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

     - The GLA MUST generate separate glKey messages for each recipient
       if glUseKEK.glNewKeyAttributes.recipientMutuallyAware glUseKEK.glNewKeyAttributes.recipientsNotMutuallyAware that
       set up the GL was set to FALSE.

     - The GLA MUST MAY generate X glKey messages prior to the duration on
       the last outstanding shared KEK expiring, where X is the
       generationCounter minus one (1). Other distribution mechanisms
       may also be supported to support this functionality.

3.2 Use of CMC, CMS, and PKIX

   The following paragraphs sections outline the use of CMC, CMS, and PKIX.

3.2.1 Protection Layers

   The following paragraphs sections outline the protection required for the
   control attributes defined herein.

Turner                                                              20                                                              22

3.2.1.1 Minimum Protection

   At a minimum, a SignedData MUST protect each request and response
   encapsulated in PKIData and PKIResponse. The following is a
   depiction of the minimum wrappings:

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

   Prior to taking any action on any request or response SignedData(s)
   MUST be processed according to CMS [2].

3.2.1.2 Additional Protection

   An additional EnvelopedData MAY also be used to provide
   confidentiality of the request and response. An additional
   SignedData MAY also be added to provide authentication and integrity
   of the encapsulated EnvelopedData. The following is a depiction of
   the 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 confidentiality of the
   message MUST also be encrypted. preserved. All EnvelopedData objects MUST be
   processed as specified in CMS [2].

   If the GLO or GL member applies confidentiality to a request, the
   EnvelopedData MUST be encrypted for the GLA. If the GLA is to
   forward the GL member request to the GLO, the GLA decrypts the
   EnvelopedData, strips the confidentiality layer off, and applies its
   own confidentiality layer for the GLO.

3.2.2 Combining Requests and Responses

   Mutlipe

   Multiple requests and response corresponding to a GL MAY be included
   in one PKIData.controlSequence or PKIResponse.controlSequence.
   Requests and responses for multiple GLs MAY be combined in one
   PKIData or PKIResponse by using PKIData.cmsSequence and
   PKIResponse.cmsSequence. A separate cmsSequence MUST be used for

Turner                                                              21                                                              23
   different GLs (i.e., requests corresponding to two different GLs are
   included in different cmsSequences). The following is a diagram
   depicting multiple requests and responses combined in one PKIData
   and PKIResponse:

         Multiple Request and Response
     Request                        Response
     -------                        --------
     SignedData                      SignedData
      PKIData                         PKIResponse
       cmsSequence                     cmsSequence
        SignedData                      SignedData
         PKIData                         PKIResponse
          controlSequence                 controlSequence
           Zero
           One or more requests          Zero          One or more responses
           corresponding to one GL.        corresponding to one GL.
        SignedData                      SignedData
         PKIData                         PKIResponse
          controlSequence                 controlSequence
           Zero
           One or more requests          Zero          One or more responses
           corresponding to another GL.   corresponding to another GL.

   When applying confidentiality to multiple requests and responses,
   all of the requests/response MAY be included in one EnvelopedData.
   The following is a depiction:

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

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

        Invalid Combinations
     ---------------------------
     glUseKEK   & glDeleteMember
     glUseKEK   & glRekey
     glUseKEK   & glDelete
     glDelete   & glAddMember
     glDelete   & glDeleteMember
     glDelete   & glRekey
     glDelete   & glAddOwner
     glDelete   & glRemoveOwner
     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 to which to process first: glUseKEK before glAddMember, glRekey
   before glAddMember, and glDeleteMember before glRekey. It should be
   noted that there is a priority but it does not imply an order.

3.2.3 GLA Generated Messages

   When the 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
   members.

   If GLKeyAttributes.recipientMutuallyAware GLKeyAttributes.recipientsNotMutuallyAware is set to FALSE, a
   separate PKIResponse.glSucessInfo, PKIResponse.glFailInfo, and
   PKIData.glKey MUST be generated for each recipient.  It is valid to
   send one message with multiple attributes to the same recipient.

   If the GL has multiple GLOs, the GLA MUST send the glSuccessInfo and
   glFailInfo messages to the requesting GLO. The mechanism another GLO to
   determine which GLO made the request is beyond the scope of this
   document.

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

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

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 indicate to GLOs and GL members
   whether a request was or was not successfully completed. If the
   request was successful, the GLA returns a cMCStatusInfo response
   with cMCStatus.success and optionally other pertinent information in
   stutsString. If the response was not successful, the GLA returns a
   cMCStatusInfo response with cMCStatus.failed and optionally other
   pertinent information in statusString.

   When the GL is managed and the GLO has reviewed GL member initiated
   glAddMember, glDeleteMember, and glkComrpomise requests, the GLO
   uses cMCStatusInfo to indicate the success or failure of the
   request. If the request is allowed, cMCStatus.success is returned
   and statusString is optionally returned to convey additional
   information. If the request is denied, cMCStatus.failed is returned
   and statusString is optionally returned to convey additional
   information.

   cMCStatusInfo is used by GLOs, GLAs, and GL members to indicate that
   signature verification failed. If the signature failed to verify,
   the cMCStatusInfo control attribute MUST be returned indicating
   cMCStatus.failed and otherInfo.failInfo.badMessageCheck. If the
   signature over the outermost PKIData failed, the bodyList value is
   zero (0). If the signature over any other PKIData failed the
   bodyList value is the bodyPartId value from the request or response.

   [Not sure the above is completely correct.]

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

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

Turner                                                              26
   cMCStatusInfo is also used by GLAs to indicate that a
   glaQueryRequest is not supported. If the glaQueryRequest is not
   supported, the cMCStatusInfo control attribute MUST be returned
   indicating cMCStatus.noSupport and statusString is optionally
   returned to convey additional information.

   transactionId MAY be included by GLOs, GLAs, or GL members to
   identify a given transaction. All subsequent requests and responses
   related to the original request MUST include the same transactionId
   control attribute. If GL members include a transactionId and the
   request is redirected to the GLO, the GLA MAY include an additional
   transactionId in the outer PKIData. If the GLA included an
   additional transactionId in the outer PKIData, when the GLO
   generates a cMCStatusInfo response it generates one for the GLA with
   the GLA's GLAĘs transactionId and one for the GL member with the GL
   member's
   memberĘs transactionId.

   senderNonce and recipientNonce

   The use of nonces (see paragraph section 5.6 of [3]) MAY can be used to provide
   application-level replay prevention. Originating
   messages include only a value for senderNonce.  If a the originating message
   includes a senderNonce, the response to the message MUST include the transmitted value of
   the previously
   received senderNonce value as the recipientNonce and include a new value for senderNonce. If GL members include as
   a senderNonce and
   the request is redirected to the GLO, the GLA MAY include an
   additional senderNonce value in the outer PKIData. response.

   If the GLA included an
   additional senderNonce in the outer PKIData, when the GLO generates
   the response:

     - It generates one for the a GLA by including the senderNonce from aggratates multiple messages together or forwards a message
   to a GLO, the GLA as the recipientNonce and includes can optionally generate a new nonce value for
       senderNonce

     - It generates one for and
   include that in the GL member by including wrapping message.  When the senderNonce response comes back
   from the GL member as GLO, the recipientNonce and includes GLA builds a new
       value for senderNonce. The value response to the originator(s) of this senderNonce MUST be
       different than the value in
   message(s) and deals with each of the senderNonce returned to nonce values from the GLA.
   originating messages.

   The following is the implementation requirement for the CMC control
   attributes:

           Implementation Requirement          |  Control
     GLO     |       GLA          | GL Member |  Attribute |Attribute
   O    R    | O     R      F    | O   R    |
   -------- | ------------------  |
   --------- | -----------------  |---------  | ----------
   MUST MUST| MUST   MUST    N/A | MUST  MUST    -   | MUSTMUST | 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 GL member requests to
   the GLO for GLO approval. approval by creating a new request message
   containing the GL member request(s) as a cmsSequence item.  If the
   GLO approves the request it reforms can either add a new layer of wrapping
   and send it back to the
   glAddMember, glDeleteMember, GLA or glkCompromise create a new message by stripping
   of the GL member's signature and resigning sends it to the request.

Turner                                                              27
   GLA.  (Note in this case there are now 3 layers of PKIData messages
   with appropriate signing layers.)

3.2.6 PKIX

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

   Name matching is performed according to PKIX [6].

   All distinguished name forms must follow the UTF8String convention
   noted in PKIX [6].

   A certificate per-GL would be issued to the GLA.

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

4 Administrative Messages

   There are a number of administrative messages that must be performed
   to manage a GL. The following sections describe each of messages'
   request and response combinations in detail. The procedures defined
   in this paragraph section are not prescriptive.

4.1 Assign KEK To GL

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

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

                Figure 3 - Create Group List

   The process is as follows:

     1 - The GLO is the entity responsible for requesting the creation
         of the GL. The GLO sends a
         SignedData.PKIData.controlSequence.glUseKEK request to the GLA
         (1 in Figure 3). The GLO MUST include: glName, glAddress,
         glOwnerName, glOwnerAddress, and glAdministration. The GLO MAY
         also include their preferences for the shared KEK in
         glKeyAttributes by indicating whether the GLO controls the
         rekey in rekeyControlledByGLO, whether separate glKey messages

Turner                                                              28
         should be sent to each recipient in recipientMutuallyAware,
         recipientsNotMutuallyAware, 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 generationCounter.

     1.a - If the GLO knows of members to be added to the GL, the
           glAddMember request request(s) MAY be included in the same
           controlSequence as the glUseKEK request (see paragraph section 3.2.2).
           The GLO MUST indicate the same glName in the glAddMember
           request as in glUseKEK.glInfo.glName. Further glAddMember
           procedures are covered in paragraph section 4.3.

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

     1.c - The GLO MAY also optionally apply another SignedData over
           the EnvelopedData (see paragraph section 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 paragraphs sections
         3.2.1.2 and 3.2.2), the GLA MUST verify the outer signature(s)
         and/or decrypt the outer layer(S) prior to verifying the
         signature on the inner most SignedData.

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

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

     2.c - If Instead of
           immediately returning the signature(s) does(do) error code, the GLA MAY attempt to
           get a certificate, possibly using CMC [3].

     2.c - Else the signatures 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
           names in glUseKEK.glOwnerInfo.glOwnerName.

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

Turner                                                              29
     2.c.2 - If Else names do all match, the GLA MUST ensure check that the requested
             glName and glAddress is not already in use. The GLA MUST
             also check any glAddMember included within the
             controlSequence with this glUseKEK. Further processing of
             the glAddMember is covered in paragraph section 4.3.

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

Turner                                                              27

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

     2.c.2.c - If Else the duration is not supportable, determining this
               is beyond the scope of this document, the GLA MUST
               return a response indicating
               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 Else 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.

     2.c.2.f

     2.c.2.e - If Else the glName is not already in use, the duration is
               supportable, and the requestedAlgorithm is supported,
               the GLA MUST return a 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, glAddress,
               glKeyAttributes, glOwnerName, and glOwnerAddress. The
               GLA also sends a glKey message as described in paragraph section
               5.

     2.c.2.f.1

     2.c.2.e.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 section 3.2.1.2).

     2.c.2.f.2

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

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

     3.a - If the signatures do not verify, the GLO MUST return a
           cMCStatusInfo response indicating cMCStatus.failed and
           otherInfo.failInfo.badMessageCheck.

Turner                                                              30
     3.b - Else the signatures do verify, the GLO MUST check that one
           of the names in the certificate used to sign the response
           matches the name of the GL.

     3.b.1 ū If the GLĘs name does not match the name present in the
             certificate used to sign the message, the GLO should not
             believe the response.

     3.b.2 ū Else the GLĘs name does match the name present in the
             certificate and:

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

Turner                                                              28
     3.c

     3.b.2.b - If Else the signatures do verify and the response was
             glFailInfo, the GLO MAY reattempt to create the GL using
             the information provided in the glFailInfo response. The
             GLO may also use the glaQueryRequest to determine the
             algorithms and other characteristics supported by the GLA
             (see paragraph section 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 request to the GLA
         (1 in Figure 4). The name of the GL to be deleted MUST be
         included in GeneralName.

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

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

Turner                                                              31
     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 section
         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.

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

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

Turner                                                              29

     2.b.1 - If the glName is not supported by the GLA, the GLA MUST
             return a response indicating
             glFailInfo.errorCode.invalidGLName.

     2.b.2 - If Else the glName is supported by the GLA, the GLA MUST
             ensure a registered GLO signed the glDelete request by
             checking if one of the names present in the digital
             signature certificate used to sign the glDelete request
             matches a registered GLO.

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

     2.b.2.b - If Else 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. Actions beyond the
               scope of this document must then be taken to delete the
               GL from the GLA.

     2.b.2.c - If Else the names do match, the GLA MUST return a
               glSuccessInfo indicating the glName, 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.

     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 section 3.2.1.2).

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

     3 - Upon receipt of the glSuccessInfo or glFailInfo response, the
         GLO verifies the GLA's signature(s). If an additional

Turner                                                              32
         SignedData and/or EnvelopedData encapsulates the response (see
         paragraph
         section 3.2.1.2 or 3.2.2), the GLO MUST verify the outer
         signature and/or decrypt the outer layer prior to verifying
         the signature on the inner most SignedData.

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

     3.b - Else the signatures do verify, the GLO MUST check that one
           of the names in the certificate used to sign the response
           matches the name of the GL.

     3.b.1 ū If the GLĘs name does not match the name present in the
             certificate used to sign the message, the GLO should not
             believe the response.

     3.b.2 ū Else the GLĘs name does match the name present in the
             certificate and:

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

     3.c

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

Turner                                                              30

4.3 Add Members To GL

   To add members to GLs, either the GLO or prospective members use the
   glAddMember request. The GLA processes GLO and prospective GL member
   requests differently though. GLOs can submit the request at any time
   to add members to the GL, and the GLA, once it has verified the
   request came from a registered GLO, should process it. If a
   prospective member sends the request, the GLA needs to determine how
   the GL is administered. When the GLO initially configured the GL,
   they set the GL to be unmanaged, managed, or closed (see paragraph section
   3.1.1). In the unmanaged case, the GLA merely processes the member's memberĘs
   request. For the managed case, the GLA forwards the requests from
   the prospective members to the GLO for review. Where there are
   multiple GLOs for a GL, which GLO the request is forwarded to is
   beyond the scope of this document. The GLO reviews the request and
   either rejects it or submits a reformed request to the GLA. In the
   closed case, the GLA will not accept requests from prospective
   members. The following paragraphs sections describe the processing for the
   GLO(s), GLA, and prospective GL members depending on where the
   glAddMeber request originated, either from a GLO or from prospective
   members. Figure 5 depicts the protocol interactions for the three
   options. Note that the error messages are not depicted.

Turner                                                              33
                +-----+  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
   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 MAY be rekeyed to maintain the secrecy of the group.
   An option to rekeying managed or closed GLs when a member is added
   is to generate a new GL with a different group key. Group rekeying
   is discussed in paragraphs sections 4.5 and 5.

Turner                                                              31

4.3.1 GLO Initiated Additions

   The process for GLO initiated glAddMember requests is as follows:

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

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

     1.b - The GLO MAY also optionally apply another SignedData over
           the EnvelopedData (see paragraph section 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

Turner                                                              34
         and/or EnvelopedData encapsulates the request (see paragraph section
         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.

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

     2.b - If Else the signature(s) does(do) signatures do verify, the glAddMember request is
           included in a controlSequence with the glUseKEK request, and
           the processing in paragraph section 4.1 item 2.e is successfully
           completed the GLA MUST return a glSuccessInfo indicating the
           glName, the corresponding glIdentifier, an
           action.actionCode.addedMember, and action.glMemberName (2 in
           Figure 5).

     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
             section 3.2.1.2).

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

Turner                                                              32

     2.c - If Else the signature(s) does(do) signatures 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 that
           the glName matches a glName stored on the GLA.

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

     2.c.2 - If Else the glName is supported by the GLA, the GLA MUST
             check to see if the glMemberName is present on the GL.

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

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

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

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

     2.c.2.b.1.b.1 - If the member's encryption certificate does not
                     verify, the GLA MAY return a response indicating
                     glFailInfo.errorCode.invalidCert to the GLO. If
                     the GLA does not return a glFailInfo response, the
                     GLA MUST issue a glProvideCert request (see
                     paragraph
                     section 4.10).

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

     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 section
                       3.2.1.2).

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

     2.c.2.b.2 - If Else the GL is managed, the GLA MUST check that either
                 a registered GLO or the prospective member signed the
                 request. For GLOs, one of the names in the certificate
                 used to sign the request 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.c.2.b.2.a - If the signer is neither a registered GLO nor the
                   prospective GL member, the GLA MUST return a
                   response indicating glFailInfo.errorCode.noSpam.

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

     2.c.2.b.2.b.1 - If the member's certificate does not verify, the
                     GLA MAY return a response indicating
                     glFailInfo.errorCode.invalidCert. If the GLA does
                     not return a glFailInfo response, the GLA MUST
                     issue a glProvideCert request (see paragraph section 4.10).

Turner                                                              36
     2.c.2.b.2.b.2 - If Else the member's certificate does verify, the GLA
                     MUST return glSuccessInfo indicating the glName,
                     the corresponding glIdentifier, an
                     action.actionCode.addedMember, and
                     action.glMemberName to the GLO (2 in Figure 5).
                     The GLA also takes administrative actions, which
                     are beyond the scope of this document, to add the
                     member to the GL stored on the GLA. The GLA MUST
                     also distribute the shared KEK to the member via
                     the mechanism described in paragraph section 5. The GL
                     policy may mandate that the GL memberĘs address be
                     included in the GL memberĘs certificate.

     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 section
                       3.2.1.2).

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

Turner                                                              34

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

     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 section 3.2.1.2).

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

     2.c.2.b.3 - If Else the GL is unmanaged, the GLA MUST check that
                 either a registered GLO or the prospective member
                 signed the request. For GLOs, one of the names in the
                 certificate used to sign the request MUST match the
                 name of 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.

Turner                                                              37
     2.c.2.b.3.a - If the signer is neither a registered GLO nor the
                   prospective member, the GLA MUST return a response
                   indicating glFailInfo.errorCode.noSpam.

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

     2.c.2.b.3.b.1 - If the member's certificate does not verify, the
                     GLA MAY return a response indicating
                     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 section 4.10) to either
                     the GLO or prospective member depending on where
                     the request originated.

     2.c.2.b.3.b.2 - If Else the member's certificate does verify, the GLA
                     MUST return a 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.

Turner                                                              35
                     The GLA also takes administrative actions, which
                     are beyond the scope of this document, to add the
                     member to the GL stored on the GLA. The GLA MUST
                     also distribute the shared KEK to the member via
                     the mechanism described in paragraph section 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 section
                       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 section
                       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
         section 3.2.1.2 or 3.2.2), the GLO MUST verify the outer
         signature and/or decrypt the outer layer prior to verifying
         the signature on the inner most SignedData.

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

Turner                                                              38
     3.b - Else the signatures do verify, the GLO MUST check that one
           of the names in the certificate used to sign the response
           matches the name of the GL.

     3.b.1 ū If the signature(s) does(do) GLĘs name does not match the name present in the
             certificate used to sign the message, the GLO should not
             believe the response.

     3.b.2 ū Else the GLĘs name does match the name present in the
             certificate and:

     3.b.2.a - If the signatures 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

     3.b.2.b - If Else the GLO received a glFailInfo, for any reason, the
             GLO MAY reattempt to add the member to the GL using the
             information provided in the glFailInfo response.

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

     4.a - If the signatures do not verify, the prospective member MUST
           return a cMCStatusInfo response indicating cMCStatus.failed
           and otherInfo.failInfo.badMessageCheck.

     4.b - Else the signatures do verify, the GL member MUST check that
           one of the names in the certificate used to sign the
           response matches the name of the GL.

     4.b.1 ū If the GLĘs name does not match the name present in the
             certificate used to sign the message, the GL member should
             not believe the response.

     4.b.2 ū Else the GLĘs name does match the name present in the
             certificate and:

     4.b.2.a - If the signatures do verify, the prospective member has
             been added to the GL.

Turner                                                              36
     4.c

     4.b.2.b - If Else the prospective member received a glFailInfo, for
             any reason, the prospective member MAY reattempt to add
             themselves to the GL using the information provided in the
             glFailInfo response.

Turner                                                              39

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. glMember.certificates.pKC. The
         prospective GL member MAY also include any attribute
         certificates associated with their encryption certificate in
         glMember.certificates.membersAC,
         glMember.certificates.aC, 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 section
           3.2.1.2).

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

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

     3 - Upon receipt of the forwarded request, the GLO verifies the
         prospective GL member's memberĘs signature on the inner most
         SignedData.PKIData and the GLA's GLAĘs signature on the outer layer.
         If an EnvelopedData encapsulates the inner most layer (see
         paragraph
         section 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 - If

         Note: For cases where the signature(s) does(do) not verify, GL is closed and either a) a
         prospective member sends directly to the GLO MUST return
           a cMCStatusInfo response indicating cMCStatus.failed and
           otherInfo.failInfo.badMessageCheck.

     3.b or b) the GLA has
         mistakenly forwarded the request to the GLO, the GLO should
         first determine whether to honor the request.

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

     3.b - Else the signatures do verify, the GLO MUST check to make
           sure one of the names in the certificate used to sign the
           request matches the name in glMember.glMemberName.

     3.b.1 - If the names do not match, the GLO MAY send a
             SignedData.PKIResponse.controlSequence message back to the

Turner                                                              37                                                              40
             prospective member with cMCStatusInfo.cMCStatus.failed
             indicating why the prospective member was denied in
             cMCStausInfo.statusString. This stops people from adding
             people to GLs without their permission.

     3.b.2 - If Else the names do match, the GLO determines whether the
             prospective member is allowed to be added. The mechanism
             is beyond the scope of this document; however, the GLO
             should check to see that the glMember.glMemberName is not
             already on the GL.

     3.b.2.a - If the GLO determines the prospective member is not
               allowed to join the GL, the GLO MAY return a
               SignedData.PKIResponse.controlSequence message back to
               the prospective member with
               cMCStatusInfo.cMCtatus.failed indicating why the
               prospective member was denied in cMCStatus.statusString.

     3.b.2.b - If Else GLO determines the prospective member is allowed to
               join the GL, the GLO MUST 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
                 memberĘs encryption certificate did not verify in
                 cMCStatus.statusString. If the GLO does not return a
                 cMCStatusInfo response, the GLO MUST send a
                 SignedData.PKIData.controlSequence.glProvideCert
                 message to the prospective member requesting a new
                 encryption certificate (see paragraph section 4.10).

     3.b.2.b.2 - If Else the member's certificate does verify, the GLO
                 resubmits the glAddMember request (see paragraph section 3.2.5)
                 to the GLA (1 in Figure 5).

     3.b.2.b.2.a - The 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 section 3.2.1.2).

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

     4 - Processing continues as in 2 of paragraph section 4.3.1.

Turner                                                              38                                                              41

4.4 Delete Members From GL

   To delete members from GLs, either the GLO or prospective non-
   members use the glDeleteMember request. The GLA processes GLO and
   prospective non-GL member requests differently. The GLO can submit
   the request at any time to delete members from the GL, and the GLA,
   once it has verified the request came from a registered GLO, should
   delete the member. If a 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 section 3.1.1). In the unmanaged case, the
   GLA merely processes the member's memberĘs request. For the managed case, the
   GLA forwards the requests from the prospective members to the GLO
   for review. Where there are multiple GLOs for a GL, which GLO the
   request is forwarded to is beyond the scope of this document. The
   GLO reviews the request and either rejects it or submits a reformed
   request to the GLA. In the closed case, the GLA will not accept
   requests from prospective members. The following paragraphs sections describe
   the processing for the GLO(s), GLA, and prospective non-GL GL members depending on
   where the request originated, either from a GLO or from prospective
   non-members. Figure 6 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 6 - Member Deletion

   If the member is not removed from the GL, they will continue to
   receive and be able to decrypt data protected with the shared KEK
   and will continue to receive rekeys. For unmanaged lists, there is
   no point to a group rekey because there is no guarantee that the
   member requesting to be removed has not already added themselves
   back on the GL under a different name. For managed and closed GLs,
   the GLO MUST take steps to ensure the member being deleted is not on
   the GL twice. After ensuring this, managed and closed GLs MUST be
   rekeyed to maintain the secrecy of the group. If the GLO is sure the
   member has been deleted the group rekey mechanism MUST be used to
   distribute the new key (see paragraphs sections 4.5 and 5).

Turner                                                              39                                                              42

4.4.1 GLO Initiated Deletions

   The process for GLO initiated glDeleteMember requests is as follows:

     1 - The GLO collects the pertinent information for the member(s)
         to be deleted (this MAY be done through an out of bands
         means). The GLO then sends a
         SignedData.PKIData.controlSequence with a separate
         glDeleteMember request for each member to the GLA (1 in Figure
         6). The GLO MUST include: the GL name in glName and the
         member's name in glMemberToDelete. If the GL from which the
         member is being deleted in a closed or managed GL, the GLO
         MUST also generate a glRekey request and include it with the
         glDeletemember request (see paragraph section 4.5).

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

     1.b - The GLO MAY also optionally apply another SignedData over
           the EnvelopedData (see paragraph section 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 section
         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.

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

     2.b - If Else the signature(s) does(do) signatures 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 is not supported by the GLA, the GLA MUST
             return a response indicating
             glFailInfo.errorCode.invalidGLName.

     2.b.2 - If Else the glName is supported by the GLA, the GLA MUST
             check to see if the glMemberName is present on the GL.

     2.b.2.a - If the glMemberName is not present on the GL, the GLA
               MUST return a response indicating
               glFailInfo.errorCode.notAMember.

     2.b.2.b - If Else the glMemberName is already on the GL, the GLA MUST
               check how the GL is administered.

Turner                                                              40                                                              43
     2.b.2.b.1 - If the GL is closed, the GLA MUST check that the
                 registered GLO signed the request by checking that one
                 of the names in the digital signature certificate used
                 to sign the request matches the registered GLO.

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

     2.b.2.b.1.b - If Else the names do match, the GLA MUST return a
                   glSuccessInfo indicating the glName, the
                   corresponding glIdentifier, an
                   action.actionCode.deletedMember, and
                   action.glMemberName (2 in Figure 5). The GLA also
                   takes administrative actions, which are beyond the
                   scope of this document, to delete the member with
                   the GL stored on the GLA. The GLA Note that he GL MUST also rekey
                   group
                   be rekeyed as described in paragraph section 5.

     2.b.2.b.1.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 section 3.2.1.2).

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

     2.b.2.b.2 - If Else the GL is managed, the GLA MUST check that either
                 a registered GLO or the prospective member signed the
                 request. For GLOs, one of the names in the certificate
                 used to sign the request 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.b.2.a - If the signer is neither a registered GLO nor the
                   prospective GL member, the GLA MUST return a
                   response indicating glFailInfo.errorCode.noSpam.

     2.b.2.b.2.b - If Else the signer is a registered GLO, the GLA MUST
                   return a glSuccessInfo to the GLO indicating the
                   glName, the corresponding glIdentifier, an
                   action.actionCode.deletedMember, and
                   action.glMemberName (2 in Figure 6). The GLA also
                   takes administrative actions, which are beyond the
                   scope of this document, to delete the member with
                   the GL stored on the GLA. The GLA Note that the GL will also rekey
                   group
                   be rekeyed as described in paragraph section 5.

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

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

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

     2.b.2.b.2.c - If Else the signer is the prospective member, the GLA
                   forwards the glDeleteMember request (see paragraph section
                   3.2.3) to the GLO (B{A} in Figure 6). If there is
                   more than one registered GLO, the GLO to which the
                   request is forwarded to is beyond the scope of this
                   document. Further processing of the forwarded
                   request by GLOs is addressed in 3 of paragraph section 4.4.2.

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

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

     2.b.2.b.3 - If Else the GL is unmanaged, the GLA MUST check that
                 either a registered GLO or the prospective member
                 signed the request. For GLOs, one of the names in the
                 certificate used to sign the request MUST match the
                 name of 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.b.3.a - If the signer is neither the GLO nor the prospective
                   member, the GLA MUST return a response indicating
                   glFailInfo.errorCode.noSpam.

     2.b.2.b.3.b - If Else the signer is either a registered GLO or the
                   member, the GLA MUST return a glSuccessInfo
                   indicating the glName, the corresponding
                   glIdentifier, an action.actionCode.deletedMember,
                   and action.glMemberName to the GLO (2 in Figure 6)
                   if the GLO signed the request and to the GL member
                   (3 in Figure 6) if the GL member signed the request.
                   The GLA also takes administrative actions, which are
                   beyond the scope of this document, to delete the
                   member with the GL stored on the GLA.

     2.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 section 3.2.1.2).

Turner                                                              45
     2.b.2.b.3.b.2 - The GLA MAY also optionally apply another
                     SignedData over the EnvelopedData (see paragraph section
                     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 section
         3.2.1.2 or 3.2.2), the GLO MUST verify the outer signature
         and/or decrypt the outer layer prior to verifying the
         signature on the inner most SignedData.

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

     3.b - Else the signatures do verify, the GLO MUST check that one
           of the names in the certificate used to sign the response
           matches the name of the GL.

     3.b.1 ū If the signature(s) does(do) GLĘs name does not match the name present in the
             certificate used to sign the message, the GLO should not
             believe the response.

     3.b.2 ū Else the GLĘs name does match the name present in the
             certificate and:

     3.b.2.a - If the signatures do verify and the response is
             glSuccessInfo, the GLO has deleted the member from the GL.
             If member was deleted from a managed list and the original
             request was signed by the member, the GLO MUST send a
             cMCStatusInfo.cMCStatus.success to the GL member.

     3.c

     3.b.2.b - If Else the GLO received a glFailInfo, for any reason, the
             GLO may reattempt to delete the member from the GL using
             the information provided in the glFailInfo response.

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

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

     4.b - If Else the signature(s) does(do) signatures do verify, the prospective GL member
           has been deleted from the GL.

     4.c - If MUST check that
           one of the prospective member received a glFailInfo, for any
           reason, names in the prospective member MAY reattempt certificate used to delete
           themselves from sign the GL using
           response matches the information provided in name of the GL.

Turner                                                              46
     4.b.1 ū If the GLĘs name does not match the name present in the
             certificate used to sign the message, the GL member should
             not believe the response.

     4.b.2 ū Else the GLĘs name does match the name present in the
             certificate and:

     4.b.2.a - If the signature(s) does(do) verify, the prospective
             member has been deleted from the GL.

     4.b.2.b - Else the prospective member received a glFailInfo, for
             any reason, the prospective member MAY reattempt to delete
             themselves from the GL using the information provided in
             the glFailInfo response.

Turner                                                              43

4.4.2 Member Initiated Deletions

   The process for prospective non-member initiated glDeleteMember
   requests is as follows:

     1 - The prospective non-GL member sends a
         SignedData.PKIData.controlSequence.glDeleteMember request to
         the GLA (A in Figure 6). The prospective non-GL member MUST
         include: the GL name in glName and their name in
         glMemberToDelete.

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

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

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

     3 - Upon receipt of the forwarded request, the GLO verifies the
         prospective non-member's non-memberĘs signature on the inner most
         SignedData.PKIData and the GLA's GLAĘs signature on the outer layer.
         If an EnvelopedData encapsulates the inner most layer (see
         paragraph
         section 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.

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

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

     3.b - If Else the signature(s) does(do) signatures do verify, the GLO MUST check to make
           sure one of the names in the certificates used to sign the
           request matches the name in glMemberToDelete.

     3.b.1 - If the names do not match, the GLO MAY send a
             SignedData.PKIResponse.controlSequence message back to the
             prospective member with cMCStatusInfo.cMCtatus.failed
             indicating why the prospective member was denied in
             cMCStatusInfo.statusString. This stops people from adding
             people to GLs without their permission.

     3.b.2 - If Else the names do match, the GLO resubmits the
             glDeleteMember request (see paragraph section 3.2.5) to the GLA (1
             in Figure 6). The GLO MUST make sure the glMemberName is
             already on the list and only on the list once. GL. The GLO MUST also generate a glRekey
             request and include it with the GLDeleteMember request
             (see paragraph section 4.5).

Turner                                                              44

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

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

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

4.5 Request Rekey Of GL

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

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

     - Depending on policy, when a member is removed from an unmanaged
       GL. If the policy is to rekey the GL, the
       PKIData.controlSequence containing the glDeleteMember could also
       contain a glRekey request or an out of bands means could be used
       to tell the GLA to rekey the GL. Rekeying of unmanaged GLs when
       members are deleted is not advised.

     - When the current shared KEK has been compromised.

Turner                                                              48
     - When the current shared KEK is about to expire.

       - If the GLO controls the GL rekey, the GLA should not assume
         that a new shared KEK should be distributed, but instead wait
         for the glRekey message.

       - If the GLA controls the GL rekey, the GLA should initiate a
         glKey message as specified in paragraph section 5.

   If the generationCounter (see paragraph section 3.1.1) is set to a value
   greater than one (1) and the GLO controls the GL rekey, the GLO may
   generate a glRekey any time before the last shared KEK has expired.
   To be on the safe side, the GLO should request a rekey one (1)
   duration before the last shared KEK expires.

   The GLA and GLO are the only entities allowed to initiate a GL
   rekey. The GLO indicated whether they are going control rekeys or
   whether the GLA is going to control rekeys when the assigned the
   shared KEK to GL (see paragraph section 3.1.1). The GLO MAY initiate a GL
   rekey at any time. The GLA MAY be configured to automatically rekey
   the GL prior to the expiration of the shared KEK (the length of time

Turner                                                              45
   before the expiration is an implementation decision). The GLA can
   also automatically rekey GLĘs that have been compromised, but this
   is covered in section 5. Figure 7 depicts the protocol interactions
   to request a GL rekey. Note that error messages are not depicted.

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

                     Figure 7 - GL Rekey Request

4.5.1 GLO Initiated Rekey Requests

   The process for GLO initiated glRekey requests is as follows:

     1 - The GLO sends a SignedData.PKIData.controlSequence.glRekey
         request to the GLA (1 in Figure 7). The GLO MUST include the
         glName. If glAdministration and glKeyNewAttributes are omitted
         then there is no change from the previously registered GL
         values for these fields. If the GLO wants to force a rekey for
         all outstanding shared KEKs it includes the
         glNewKeyAttributes.generationCounter MUST be glRekeyAllGLKeys
         set to zero (0) TRUE.

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

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

Turner                                                              49
     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 section
         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.

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

     2.b - If Else the signature(s) does(do) signatures 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 Else 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 Else 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 Else the new value duration is not supportable,
                 determining this is beyond the scope this document,
                 the GLA MUST return a response indicating
                 glFailInfo.errorCode.unsupportedDuration.

     2.b.2.b.3 - If Else 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.

     2.b.2.b.4 - If Else the new requestedAlgorithm and duration are
                 supportable or the glNewKeyAttributes was omitted, the
                 GLA MUST return a glSuccessInfo to the GLO indicating
                 the glName, the new glIdentifier, and an
                 action.actionCode.rekeyedGL (2 in Figure 7). The GLA
                 also uses the glKey message to distribute the rekey
                 shared KEK (see paragraph section 5).

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

     2.b.2.b.4.b - The GLA MAY also optionally apply another SignedData
                   over the EnvelopedData (see paragraph section 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 forwarded
         response (see paragraph section 3.2.1.2 or 3.2.2), the GLO MUST verify
         the outer signature and/or decrypt the forwarded response
         prior to verifying the signature on the inner most SignedData.

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

     3.b - If Else the signatures verifies and the response is
           glSuccessInfo, do verify, the GLO has successfully rekeyed the GL.

Turner                                                              47
     3.c - If MUST check that one
           of the GLO received a glFailInfo, for any reason, names in the GLO
           may reattempt certificate used to rekey sign the GL using response
           matches the information provided
           in name of the glFailInfo GL.

     3.b.1 ū If the GLĘs name does not match the name present in the
             certificate used to sign the message, the GLO should not
             believe the response.

     3.b.2 ū Else the GLĘs name does match the name present in the
             certificate and:

     3.b.2.a - If the signatures verifies and the response is
             glSuccessInfo, the GLO has successfully rekeyed the GL.

     3.b.2.b - Else the GLO received a glFailInfo, for any reason, the
             GLO may reattempt to rekey the GL using the information
             provided in the glFailInfo response.

4.5.2 GLA Initiated Rekey Requests

   If the GLA is in charge of rekeying the GL the GLA will
   automatically issue a glKey message (see paragraph section 5). In addition the
   GLA will generate a glSuccessInfo to indicate to the GL that a
   successful rekey has occurred. The process for GLA initiated rekey
   is as follows:

     1 - The GLA MUST generate for all GLOs a
         SignedData.PKIData.controlSequence.glSuccessInfo indicating
         the glName, the new glIdentifier, and actionCode.rekeyedGL (A
         in Figure 7). glMemberName and glOwnerName are omitted.

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

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

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

     2.a - If the signatures do not verify, the GLO MUST return a
           cMCStatusInfo response indicating cMCStatus.failed and
           otherInfo.failInfo.badMessageCheck.

     2.b - If Else the signatures verifies do verify, the GLO MUST check that one
           of the names in the certificate used to sign the response
           matches the name of the GL.

     2.b.1 ū If the GLĘs name does not match the name present in the
             certificate used to sign the message, the GLO should not
             believe the response.

     2.b.2 ū Else the GLĘs name does match the name present in the
             certificate and and the response is glSuccessInfo, the GLO
             knows the GLA has successfully rekeyed the GL.

4.6 Change GLO

   Management of managed and closed GLs can become difficult for one
   GLO if the GL membership grows large. To support distributing the
   workload, GLAs support having GLs be managed by multiple GLOs. The
   glAddOwner and glRemoveOwner messages are designed to support adding
   and removing registered GLOs. Figure 8 depicts the protocol
   interactions to send glAddOwner and glRemoveOwner messages and the
   resulting response messages.

Turner                                                              48

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

                 Figure 8 - GLO Add & Delete Owners

   The process for glAddOwner and glDeleteOwner is as follows:

     1 - The GLO sends a SignedData.PKIData.controlSequence.glAddOwner
         or glRemoveOwner request to the GLA (1 in Figure 8). The GLO

Turner                                                              52
         MUST include: the GL name in glName, the GLO's GLOĘs name in
         glOwnerName, and the GLO's 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 section 3.2.1.2).

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

     2 - Upon receipt of the glAddOwner or glRemoveOwner request, the
         GLA verifies the GLO's signature(s). If an additional
         SignedData and/or EnvelopedData encapsulates the request (see
         paragraph
         section 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.

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

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

     2.b.1 - If the glName is not supported by the GLA, the GLA MUST
             return a response indicating
             glFailInfo.errorCode.invalidGLName.

     2.b.2 - If Else the glName is supported by the GLA, the GLA MUST
             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 matches the name
             of 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 Else the names do match, the GLA MUST return a
               glSuccessInfo indicating the glName, the corresponding

Turner                                                              49
               glIdentifier (for glAddOwner), an
               action.actionCode.addedGLO or removedGLO, and the
               respective GLO name in glOwnerName (2 in Figure 4). The
               GLA MUST also take administrative actions to associate
               the new glOwnerName with the GL in the case of
               glAddOwner or to disassociate the old glOwnerName with
               the GL in the cased of glRemoveOwner.

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

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

     2.b.2.b.2 - The GLA MAY also optionally apply another SignedData
                 over the EnvelopedData (see paragraph section 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
         section 3.2.1.2 or 3.2.2), the GLO MUST verify the outer
         signature and/or decrypt the outer layer prior to verifying
         the signature on the inner most SignedData.

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

     3.b - Else the signatures do verify, the GLO MUST check that one
           of the names in the certificate used to sign the response
           matches the name of the GL.

     3.b.1 ū If the GLĘs name does not match the name present in the
             certificate used to sign the message, the GLO should not
             believe the response.

     3.b.2 ū Else the GLĘs name does match the name present in the
             certificate and:

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

     3.c

     3.b.2.b - If Else the signatures do verify and the response was
             glFailInfo, the GLO MAY reattempt to add or delete the GLO
             using the information provided in the glFailInfo response.

4.7 Indicate KEK Compromise

   The will be times when the shared KEK is compromised. GL members and
   GLOs use glkCompromise to tell the GLA that the shared KEK has been
   compromised. Figure 9 depicts the protocol interactions for GL Key
   Compromise.

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

                   Figure 9 - GL Key Compromise

4.7.1 GL Member Initiated KEK Compromise Message

   The process for GL member initiated glkCompromise messages is as
   follows:

     1 - The GL member sends a
         SignedData.PKIData.controlSequence.glkCompromise request to
         the GLA (1 in Figure 9). The GL member MUST include the GL's GLĘs
         name in GeneralName.

     1.a - The GL member MAY optionally apply confidentiality to the
           request by encapsulating the SignedData.PKIData in an
           EnvelopedData (see paragraph section 3.2.1.2). The glkCompromise MUST
           NOT be included in an EnvelopedData generated with the
           compromised shared KEK.

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

     2 - Upon receipt of the glkCompromise requst, request, the GLA verifies
         the GL member's signature(s). If an additional SignedData
         and/or EnvelopedData encapsulates the request (see paragraph section
         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.

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

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

     2.b.1 - If the glName is not supported by the GLA, the GLA MUST
             return a response indicating
             glFailInfo.errorCode.invalidGLName.

     2.b.2 - If Else the glName is supported by the GLA, the GLA MUST
             check who signed the request. For GLOs, one of the names

Turner                                                              55
             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 signed the request, the GLA MUST generate a
               glKey message as described in paragraph section 5 to rekey the GL
               (4 in Figure 9).

     2.b.2.b - If Else anyone else signed the request, the GLA MUST
               forward the glkCompromise message (see paragraph section 3.2.3) to
               the GLO (2{1} in Figure 9). If there is more than one
               GLO, to which GLO the request is forwarded is beyond the
               scope of this document. Further processing by the GLO is
               discussed in paragraph section 4.7.2.

4.7.2 GLO Initiated KEK Compromise Message

   The process for GLO initiated glkCompromise messages is as follows:

     1 - The GLO either:

     1.a - Generates the glkCompromise message itself by sending a
           SignedData.PKIData.controlSequence.glkCompromise request to
           the GLA (5 in Figure 9). The GLO MUST include the name of
           the GL in GeneralName.

     1.a.1 - The GLO MAY optionally apply confidentiality to the
             request by encapsulating the SignedData.PKIData in an
             EnvelopedData (see paragraph section 3.2.1.2). 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 section 3.2.1.2).

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

     1.b.1 - If the signatures do not verify, the GLO MUST return a
             cMCStatusInfo response indicating cMCStatus.failed and
             otherInfo.failInfo.badMessageCheck.

     1.b.2

     1.b.1.a - If the signatures do verify, the GLO MUST check the
               names in the certificate match the name of the signer
               (i.e., the name in the certificate used to sign the GL
               memberĘs request is the GL member).

Turner                                                              56
     1.b.1.a.1 ū If either name does not match, the GLO should not
                 trust the signer and it should not forward the message
                 to the GLA.

     1.b.1.a.2 ū Else the names do math, the signatures do verify, the
                 GLO MUST determine whether to forward the
                 glkCompromise message back to the GLA (3{1} in Figure
                 9). Further processing by the GLA is in 2 of paragraph section
                 4.7.1. The GLO MAY also return a response to the

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 members have misplaced their shared KEK.
   The shared KEK is not compromised and a rekey of the entire GL is
   not necessary. GL members use the glkRefresh message to request that
   the shared KEK(s) be redistributed to them. Figure 10 depicts the
   protocol interactions for GL Key Refresh.

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

                         Figure 10 - GL KEK Refresh

   The process for glkRefresh is as follows:

     1 - The GL member sends a
         SignedData.PKIData.controlSequence.glkRefresh request to the
         GLA (1 in Figure 10). The GL member MUST include name of the
         GL in GeneralName.

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

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

     2 - Upon receipt of the glkRefresh request, the GLA verifies the
         GL member's signature(s). If an additional SignedData and/or
         EnvelopedData encapsulates the request (see paragraph section 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.

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

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

     2.b.1 - If the GL's GLĘs name is not supported by the GLA, the GLA MUST
             return a response indicating
             glFailInfo.errorCode.invalidGLName.

Turner                                                              53

     2.b.2 - If Else the glName is supported by the GLA, the GLA MUST
             ensure the GL member is on the GL.

     2.b.2.a - If the glMemberName is not present on the GL, the GLA
               MUST return a response indicating
               glFailInfo.errorCode.noSpam.

     2.b.2.b - If Else the glMemberName is present on the GL, the GLA MUST
               return a glKey message (2 in Figure 10) as described in
               paragraph
               section 5.

4.9 GLA Query Request and Response

   There will be certain times when a GLO is having trouble setting up
   a GLO GL 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 or GL members need to know something about
   the GLA (these requests are not defined in the document). The
   glaQueryRequest and glaQueryResponse message have been defined to
   support determining this information. Figure 11 depicts the protocol
   interactions for glaQueryRequest and glaQueryResponse.

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

                Figure 11 - GLA Query Request & Response

   The process for glaQueryRequest and glaQueryResponse is as follows:

     1 - The GLO, GL member, or prospective GL member sends a
         SignedData.PKIData.controlSequence.glaQueryRequest request to
         the GLA (1 in Figure 11). The GLO, GL member, or prospective
         GL member indicates the information 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

Turner                                                              58
           SignedData.PKIData in an EnvelopedData (see paragraph section
           3.2.1.2).

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

     2 - Upon receipt of the glaQueryRequest, the GLA 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 Else the GLA does accept GLAQueryReuests, GLAQueryRequests, the GLA MUST
           verify the GLO's, GL member's, memberĘs, or prospective GL member's memberĘs
           signature(s). If an additional SignedData and/or
           EnvelopedData encapsulates the request (see paragraph section 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.

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

     2.b.2 - If Else the signature(s) does(do) signatures do verify, the GLA MUST return a
             glaQueryResponse (2 in Figure 11) indicating the with the
             requested information correct
             response if the glaRequestType is supported or return a
             cMCStatusInfo response indicating cMCStatus.noSupport if
             the glaRequestType is not supported.

     2.b.2.a - 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 section 3.2.1.2).

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

     3 - Upon receipt of the glaQueryResponse, the GLO, GL member, or
         prospective GL member verifies the GLA's signature(s). If an
         additional SignedData and/or EnvelopedData encapsulates the
         response (see paragraph section 3.2.1.2 or 3.2.2), the GLO, GL member,
         or prospective GL member 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) signatures do not verify, the GLO, GL member, or
           prospective GL member MUST return a cMCStatusInfo response

Turner                                                              59
           indicating cMCStatus.failed and
           otherInfo.failInfo.badMessageCheck.

     3.b - If Else the signatures do verify verify, the GLO, GL member, or
           prospective GL member MUST check that one of the names in
           the certificate used to sign the response matches the name
           of the GL.

     3.b.1 ū If the GLĘs name does not match the name present in the
             certificate used to sign the message, the GLO should not
             believe the response.

     3.b.2 - Else the GLĘs name does match the name present in the
           certificate and the response was glaQueryResponse, the GLO,
           GL member, or prospective GL member may use the information
           contained therein.

Turner                                                              55

4.10 Update Member Certificate

   When the GLO generates a glAddMember request, when the GLA generates
   a glKey message, or when the GLA processes a glAddMember there may
   be instances when GL member's memberĘs certificate has expired or is invalid.
   In these instances the GLO or GLA may request that the GL member
   provide a new certificate to avoid the GLA from being unable to
   generate a glKey message for the GL member. There may also be times
   when the GL member knows their certificate is about to expire or has
   been revoked and they will not be able to receive GL rekeys.

4.10.1 GLO and GLA Initiated Update Member Certificate

   The process for GLO initiated glUpdateCert is as follows:

     1 - The GLO or GLA sends a
         SignedData.PKIData.controlSequence.glProvideCert request to
         the GL member. The GLO or GLA indicates the GL name in glName
         and the GL member's memberĘs name in glMemberName.

     1.a - The GLO or GLA MAY optionally apply confidentiality to the
           request by encapsulating the SignedData.PKIData in an
           EnvelopedData (see paragraph section 3.2.1.2). If the GL member's 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 GLO or GLA MAY also optionally apply another SignedData
           over the EnvelopedData (see paragraph section 3.2.1.2).

     2 - Upon receipt of the glProvideCert message, the GL member
         verifies the GLO's GLOĘs or GLA's GLAĘs signature(s). If an additional
         SignedData and/or EnvelopedData encapsulates the response (see
         paragraph
         section 3.2.1.2 or 3.2.2), the GL member MUST verify the outer

Turner                                                              60
         signature and/or decrypt the outer layer prior to verifying
         the signature on the inner most SignedData.

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

     2.b - If Else the signature(s) does(do) signatures do verify, the GL member generates a
           Signed.PKIResponse.controlSequence.glUpdateCert that MUST
           include the GL name in glName, the member's name in
           glMember.glMemberName, their encryption certificate in
           glMember.certificates.membersPKC.
           glMember.certificates.pKC. The GL member MAY also include
           any attribute certificates associated with their encryption
           certificate in glMember.certificates.membersAC, glMember.certificates.aC, and the
           certification path associated with their encryption and
           attribute certificates in
           glMember.certificates.certificationPath.

Turner                                                              56

     2.a - The GL member MAY optionally apply confidentiality to the
           request by encapsulating the SignedData.PKIResponse in an
           EnvelopedData (see paragraph section 3.2.1.2). If the GL member's 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 GL member MAY also optionally apply another SignedData
           over the EnvelopedData (see paragraph section 3.2.1.2).

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

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

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

     3.b.1 - If the member's memberĘs encryption certificate does not verify,
             the GLO MAY return either another glProvideCert request or
             a cMCStatusInfo with cMCStatus.failed and the reason why
             in 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 Else the member's memberĘs encryption certificate does not verify,
             the GLA MAY return another glProvideCert request to the GL

Turner                                                              61
             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 Else the member's memberĘs encryption certificate does verify, the
             GLO or GLA will use it in subsequent glAddMember requests
             and glKey messages associated with the GL member.

4.10.2 GL Member Initiated Update Member Certificate

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

     1 - The GL member sends a
         Signed.PKIData.controlSequence.glUpdateCert that MUST include
         the GL name in glName, the member's name in

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

     1.a - The GL member MAY optionally apply confidentiality to the
           request by encapsulating the SignedData.PKIData in an
           EnvelopedData (see paragraph section 3.2.1.2). If the GL member's 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 MAY also optionally apply another SignedData
           over the EnvelopedData (see paragraph section 3.2.1.2).

     2 - Upon receipt of the glUpdateCert message, the GLA verifies the
         GL member's memberĘs signature(s). If an additional SignedData and/or
         EnvelopedData encapsulates the response (see paragraph section 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.

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

     2.b - If Else the signature(s) does(do) signatures do verify, the GLA MUST verify the
           member's
           memberĘs encryption certificate.

     2.b.1 - If the member's 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

Turner                                                              62
             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.

     2.b.2 - If Else the member's 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 message to distribute new, shared KEK(s)
   after receiving glAddMember, glDeleteMember (for closed and managed
   GLs), glRekey, glkCompromise, or glkRefresh requests and returning a
   glSuccessInfo response for the respective request. Figure 12 depicts

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

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

                   Figure 12 - GL Key Distribution

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

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

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

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

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

5.1 Distribution Process

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

     1 - The GLA MUST send a SignedData.PKIData.controlSequence.glKey
         to each member by including: glName, glIdentifier, glkWrapped,
         glkAlgorithm, glkNotBefore, and glkNotAfter. If the GLA can
         not generate a glKey message for the GL member because the GL
         member's
         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 section 4.10). The number of glKey messages
         generated for the GL is described in paragraph section 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 section 3.2.1.2).

     1.b - The GLA MAY also optionally apply another SignedData over
           the EnvelopedData.SignedData.PKIData (see paragraph section 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 section 3.2.1.2 or 3.2.2), the GL Member MUST
         verify the outer signature and/or decrypt the outer layer
         prior to verifying the signature on the
         SignedData.PKIData.controlSequence.glKey.

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

     2.b - If Else the signature(s) does(do) signatures 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 Algorithms

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

Turner                                                              64

6.1 KEK Generation Algorithm

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

6.2 Shared KEK Wrap Algorithm

   In the mechanisms described in paragraphs sections 5, the shared KEK being
   distributed in glkWrapped MUST be protected by a key of equal or
   greater length (i.e., if a RC2 128-bit key is being distributed a
   key of 128-bits or greater must be used to protect the key).

   The algorithm object identifiers included in glkWrapped are as
   specified in 12.3 of CMS [2].

Turner                                                              60

6.3 Shared KEK Algorithm

   The shared KEK distributed and indicated in glkAlgorithm MUST
   support the symmetric key-encryption algorithms as specified in
   paragraph
   section 12.3.3 of CMS [2]

7 Transport

   SMTP [7] MUST be supported. All other transport mechanisms MAY be
   supported.

8 Using the Group Key

   TBSL

   This document was written with three specific scenarios in mind. Two
   to support mail list agents and one for general message
   distribution. Scenario 1 depicts the originator sending a public key
   (PK) protected message to a MLA who then uses the shared KEK (S) to
   redistribute the message to the members of the list. Scenario 2
   depicts the originator sending a shared KEK protected message to a
   MLA who then redistributes the message to the members of the list
   (the MLA only adds additional recipients). Scenario 3 shows an
   originator sending a shared KEK protected message to a group of
   recipients without using the MLA.

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

         Scenario 1               Scenario 2           Scenario 3

Turner                                                              65

9 Security Considerations

   Don't

   Only have too many GLOs because they could start willie nillie
   adding people you don't like. that are trusted.

   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 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 donĘt make the generationCounter to large
   because then people can attack the last key. If there are 14 keys
   outstanding each with a year's 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, Schaad, 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.

   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.

Turner                                                              66

12 Author's Addresses

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

   Expires April 2001

Turner                                                              62                                                              67
   Annex A: ASN.1 Module

   SMIMESymmetricKeyDistribution
     { TBD }

   DEFINITIONS IMPLICIT TAGS ::=
   BEGIN

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

   IMPORTS

   -- Directory Authentication Framework (X.509)
      AlgorithmIdentifier, AttributeCertificate, Certificate,
        FROM AuthenticationFramework { joint-iso-itu-t ds(5)
             module(1) authenticationFramework(7) 3 }

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

   -- Cryptographic Message Syntax
      RecipientInfos, id-alg-CMS3DESWrap
        FROM CryptographicMessageSyntax { iso(1) member-body(2) us(840)
          rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) modules(0)
   cms(1)};

   -- This defines the GL Use KEK control attribute

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

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

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

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

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

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

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

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

   -- This defines the Add GL Member control attribute

   id-skd-glAddMember OBJECT IDENTIFIER ::= { id-skd 3}

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

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

   Certificates ::= SEQUENCE {
      pKC         Certificate OPTIONAL,
                                  -- See X.509
      aC          SEQUENCE SIZE (1.. MAX) OF
                             AttributeCertificate OPTIONAL,
                                  -- See X.509
      certificationPath  CertificateSet OPTIONAL }
                                  -- From CMS [2]

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

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

Turner                                                              69
   -- This defines the Delete GL Member control attribute

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

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

   -- This defines the Delete GL Member control attribute

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

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

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

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

   id-skd-glAddOwner OBJECT IDENTIFIER ::= { id-skd 6}
   id-skd-glRemoveOwner OBJECT IDENTIFIER ::= { id-skd 7}

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

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

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

   -- This defines the GL Key Refresh control attribute.

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

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

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

Turner                                                              70
   -- This defines the GLA Query Request control attribute.

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

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

   -- This defines the Algorithm Request

   id-rt-algorithmSupported { id-tbd }

   -- This defines the GLA Query Response control attribute.

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

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

   -- Note that the response for algorithmSupported request is the
   -- smimeCapabilities attribute as defined in MsgSpec [5].

   -- This defines the control attribute to request an updated
   -- certificate to the GLA.

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

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

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

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

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

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

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

   END -- SMIMESymmetricKeyDistribution

   September 2, 2001

Turner                                                              72