SMIME Working Group                                           S. Turner
INTERNET DRAFT
Internet Draft                                                     IECA

Expires in on 20 June,
Document: draft-ietf-smime-symkeydist-01.txt                  July 2000                            December 20, 1999
Expires:  January 14, 2001

                   S/MIME Symmetric Key Distribution
                  <draft-ietf-smime-symkeydist-00.txt>

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026. 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 6 six
   months and may be updated, replaced, or may become obsolete 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.
   http://www.ietf.org/ietf/1id-abstracts.txt

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

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

Abstract

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

Turner                                                               1

Conventions used in this document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in
   this document are to be interpreted as described in RFC-2119 [4].

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

Turner                                                               2
   6 KEY WRAPPING....................................................53
   7 ALGORITHMS......................................................54
   8 TRANSPORT.......................................................54
   9 USING THE GROUP KEY.............................................54
   10 SCHEMA REQUIREMENTS............................................54
   11 SECURITY CONSIDERATIONS........................................54
   12 REFERENCES.....................................................55
   13 ACKNOWLEDGEMENTS...............................................55
   14 AUTHOR'S ADDRESSES.............................................55

1. Introduction

   With the ever expanding ever-expanding use of secure electronic communications
   (e.g., S/MIME  [CMS]), [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 the recipients:
   using asymmetric algorithms with public key certificates (PKCs) or
   symmetric algorithms with shared secret symmetric keys.

   With asymmetric algorithms, the encrypting user originator forms an originator-determined 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 encrypting user 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 CEK KEK (kari RecipientInfo CHOICE). If the group is large
   large, the number amount of per-
recipient per-recipient information that needs to be generated required may take
   quite some
time, time to generate, not to mention the time required to
   collect and validate the PKCs for each of the recipients. With symmetric algorithms, all members of Each
   recipient identifies their per-recipient information and uses the group use
a previously shared distributed secret key-encryption
   private key (KEK). The
originating user only needs associated with the public key of their PKC to encrypt decrypt
   the content with CEK and hence gain access to the shared KEK,
which encrypted content.

   With symmetric algorithms, the origination process is then used by every member in the group to decrypt same as
   with asymmetric algorithms except for what encrypts the message.
A mechanism is defined herein to support distribution CEK. Instead
   of shared KEKs in
order to enable symmetric algorithms.

[ST - I interchangeable use group using PKCs, the originator uses a previously distributed secret
   key-encryption key (KEK) to mean shared KEK.  In encrypt the next
version I will use CEK (kekri RecipientInfo
   CHOICE). Only one copy of the encrypted CEK is required because all
   the recipients already have the term shared KEK through out needed to decrypt the CEK
   and hence gain access to the document.] encrypted content.

   The security provided by the symmetric key shared KEK is only as good as the sum
   of the techniques employed by each member of the group to keep the
symmetric key
   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 key KEK in order to maintain the secrecy of the group.
   Access control to the information protected by the symmetric key KEK is determined
   by the entity that encrypts the information, as all members of the
   group have access. If the entity that is performing the encryption
   wants to ensure some subset of the group does not gain access to the

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

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 [MUSTSHOULD].

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 a group of recipients subscribed
   to the originatormail 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 the messages encrypted message with the symmetric 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 group key), 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 key needed for to encrypt the message. In either
   case the recipients of the mail list use the previously distributed group key 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, 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 key encrypted, shared KEK can be stored in the
   repository.

2. Architecture

   Figure 1 depicts the architecture to support symmetric key
   distribution.
Two different functions are required: generating the keys and
distributing the keys. These The Group List Agent (GLA) supports two distinct
   functions are performed by with two conceptually different entities. agents:

     - The Key Management Agent (KMA) which is responsible for
       generating the keys and the shared KEKs.

     - The Group Management Agent (GMA) holds the group
list (GL) to which it is responsible for distributing the keys. Either
the KMA or GMA MAY:

 - Support one GL or multiple GLs;
 - Be collocated one a single platform or on separate platforms.

GLs are managed either through an automated process or by a human (an GL
Owner). Members of
       managing the GLs require access Group List (GL) to which the symmetric key therefore
adding and removing members is an important part of maintaining the
security for the entire group. If the GL is managed through an automated
process, mechanisms, beyond the scope of this document, may be used to
limit the addition of new members (e.g., using an access control list)
or the GL may be configured to allow anyone to join or depart from the
GL. If the GL is managed by a human, messages, beyond the scope of this
document, may be sent between the new member and the GL Owner requesting
the new member be added to the GL. The GL Owner may then decide whether
the new member should be added or not or the GL Owner may simply add a
new member, knowing the new member requires access to the messages. The
GL Owner may or may not be a member of the GL, but the GL Owner is the
only person(s) able to add or delete a GL.

               +----------------------+ shared KEKs are
       distributed.

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

          Figure 1 - Key Distribution Architecture

3 Protocol Interactions

   A few basic interactions occur between the KMA, GMA, Members, and the
optional GL Owner (used if the list is not managed by an automated
process) to GLA may support multiple KMAs. KMAs may be differentiated by the management
   'goodness' of the symmetric keys random number used by the
group (henceforth referred to as generate the group key). Management includes shared KEK or
   the
steps required key management technique used to setup the group key, add new members, delete members,
and distribute a new group key (i.e., rekey). The following sections
describe the procedures for each of shared KEK.
   Outside the management functions.

[ST - Need to add what's mandatory to implement here - I think sending
and receiving gkDistribution messages; storing the distributed key; and
using GLA, KMAs are differentiated by the previously distributed key digital signatures
   they apply to decrypt future messages.]

3.1 Group Key Administration

Figure 2 depicts the scenarios for group key setup administration. Each
of the interactions depicted is discussed messages they generate.

   A GLA in paragraphs 3.1.1, 3.1.2,
3.1.3, and 3.1.4.

                   +----------+                       +----------+
                   | GL Owner | <---+          +----> | Member 1 | <--+
                   +----------+     |          |      +----------+    |
                                    |          |                      |
  +-----+              +-----+ <----+          |      +----------+    |
  | KMA | <----------> | general supports only one GMA, but the GMA | <---------------+----> |   ...    | <--+
  +-----+              +-----+                 |      +----------+    |
     |                                         |                      |
     |                                         |      +----------+    |
     |                                         +----> | Member n | <--+
     |                                                +----------+    |
     +----------------------------------------------------------------+

                     Figure 2 - Group Key Setup

3.1.1 Request/Response Group Key Administration

There are a number of administrative functions that must be performed to
manage may support
   multiple GLs. Multiple KMAs may support a GL: creating the GL, deleting GMA in the GL, adding members same fashion as
   GLAs support multiple KMAs. Assigning a particular KMA to a GL is
   beyond the GL,
deleting members scope of the GL, and requesting this document.

   Modeling real world GL implementations shows that there are very
   restrictive GLs, where a group rekey. The group key
administration request (gkaRequest) and group key administration
responses (gkaResponse) content-types, defined in paragraphs 3.1.1.1 human determines GL membership, and
3.1.1.2, very
   open GLs, where there are defined to no restrictions on GL membership. To
   support these administrative functions. The
gkaRequest and gkaResponse MAY be used between this spectrum, the GL Owner 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 GMA
and between scope of this document.

   In either case, the GL Owner or GMA and the KMA to manage must initially be constructed by an entity
   hereafter called the GL. If the
message is from the GMA to the KMA, it Group List Owner (GLO). There may be on behalf of multiple
   entities who 'own' the GL Owner and who are allowed to make changes the
   GL's properties or from membership. The GLO determines if the GL members.

If will be
   managed or unmanaged and is the only entity that may delete the GL.
   GLO(s) may or may not be GL Owner supports members.

   Though Figure 1 depicts the gkaRequest content-type, it MUST support GLA as encompassing both the corresponding gkaResponse content-type. The KMA and GMA MAY support
forwarding
   functions, the gkaRequest content-type from two functions could be supported by the GL Owner to 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 gkaResponse content-type from the KMA GMA stores all information pertaining to the GL Owner. If GLs
   and the KMA
supports forwarding merely generates keys, a corrupted GMA could cause
   havoc. To protect against a corrupted GMA, the KMA would be forced

Turner                                                               5
   to double check the gkaRequest requests it MUST support forwarding receives to ensure the
gkaResponse. The GMA MAY support generating did not
   tamper with them. These duplicative checks blur the gkaRequest content-type
on behalf functionality of prospective GL member or existing GL members. The
   the two components together. For this reason, the interactions
   between the KMA MAY
support receiving a gkaRequest content-type and generating a gkaResponse
content-type. If GMA are beyond the KMA supports receiving scope of this document.
   Proprietary mechanisms may be used to separate the gkaRequest content-type
it must support generating functions by
   strengthening the gkaResponse content-type.

3.1.1.1 Request For Group Key Administration

The gkaRequest content-type trust relationship between the two entities.
   Henceforth, the distinction between the two agents is defined omitted; the
   term GLA will be used to address both functions.

3. Protocol Interactions

   There are existing mechanisms (e.g., listserv and majordomo) to
   support conveying group key
administration requests from 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 Owner 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 GMA or from the GMA request
   and response messages needed to setup the GL, delete the GL, add
   members to the KMA. GL, delete members of the GL, and request a group
   rekey, etc. The gkaRequest content-type MUST be protected at distribution messages are the messages that
   distribute the shared KEKs. The following paragraphs describe the
   ASN.1 for both the administration and distribution messages.
   Paragraph 4 describes how to use the administration messages and
   paragraph 5 describes how to use the distribution messages.

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

                      Figure 2 - Protocol Interactions

Turner                                                               6

3.1 Control Attributes

   The messages are based on including control attributes in CMC's
   PKIData.controlSequence for requests and CMC's
   ResponseBody.controlSequence for responses. The content-types
   PKIData and PKIResponse are then encapsulated in CMS's SignedData or
   EnvelopedData, or a minimum by
id-signedData [CMS]. It MAY also be further enveloped by id-
envelopedData [CMS]. Other layers MAY also be used. combination of the two (see paragraph 3.2). The
   following object
identifier identifies are the gkaRequest content-type:

id-ct-gkaRequest OBJECT IDENTIFIER ::= { TBD } control attributes defined in this document:

   Implementation
    Requirement    Control Attribute      OID          Syntax
   --------------  ------------------  ----------- -----------------
       MAY          glUseKEK            id-skd 1    GLUseKEK
       MAY          glDelete            id-skd 2    GLDelete
       MAY          glAddMembers        id-skd 3    GLAddMembers
       MAY          glDeleteMembers     id-skd 4    GLDeleteMembers
       MAY          glRekey             id-skd 5    GLRekey
       MAY          glAddOwners         id-skd 6    GLAddOwners
       MAY          glRemoveOwners      id-skd 7    GLRemoveOwners
       MAY          glkCompromise       id-skd 8    GLKCompromise
       SHOULD       glkRefresh          id-skd 9    GLKRefresh
       MAY          glSuccessInfo       id-skd 10   GLSuccessInfo
       MAY          glFailInfo          id-skd 11   GLFailInfo
       MAY          glAQueryRequest     id-skd 12   GLAQueryRequest
       MAY          glAQueryResponse    id-skd 13   GLAQueryResponse
       MUST         glKey               id-skd 14   GLKey

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

3.1.1 GL USE KEK

   The gkaRequest content type MUST have ASN.1 type GKARequest:

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

   GLUseKEK ::= SEQUENCE {
  gkaRequestVersion GKARequestVersion,
  gkAAction         GKAAction,
  transactionId     TransactionId OPTIONAL}

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

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

GKAAction

Turner                                                               7
   GLDistributionMethod ::= CHOICE {
 createGL
     rfc822Name                 [0] GLInformation,
 deleteGL IA5String,
     x400Address                    ORAddress,
     directoryName                  Name,
     uniformResourceIdentifier  [1] GLInformation,
 addGLMembers     [2] GLInformation,
 deleteGLMembers  [3] GLInformation,
 rekeyGL          [4] GLInformation IA5String }

GLInformation

   GLKeyAttributes ::= SEQUENCE {
  glName                GeneralName,
  glIdentifier
     rekeyControlledByGLO   [0]  OCTET STRING OPTIONAL,
  glMembers BOOLEAN DEFAULT FALSE,
     recipientMutuallyAware [1]  SEQUENCE OF GLMember OPTIONAL,
  glOwner BOOLEAN DEFAULT TRUE,
     duration               [2]  GLOwner OPTIONAL,
  effectiveDate INTEGER DEAULT (0),
     generationCounter      [3]  EffectiveDate OPTIONAL,
  distributionDate INTEGER DEFAULT {2},
     requestedAlgorithm     [4]  GeneralizedTime OPTIONAL }

GLMember ::= SEQUENCE {
  OPTIONAL,name                  GeneralName,
  deliveryMethod   [0]  SEQUENCE OF DeliveryMethod AlgorithmIdentifier OPTIONAL }
  certificates     [1]  CertificateSet OPTIONAL,
  crls             [2]  CertificateRevocationListsOPTIONAL }

DeliveryMethod ::= CHOICE {
  rfc822Name                 [0]  IA5String,
  x400Address                [1]  ORAddress,
  directoryName              [2]  Name,
  uniformResourceIdentifier  [3]  IA5String,
  iPAddress                  [4]  OCTET STRING }

CertificateSet ::= SET OF CertificateChoices

CertificateChoices ::= CHOICE {

   The fields in GLUseKEK have the following meaning:

     - glName is the name of the GL. The name MUST be unique for a
       given GLA.

     - glOwner indicates the owner of the GL. One of the names in
       glOwner MUST match one of the names in the certificate              Certificate,    -- See X.509
  extendedCertificate  [0] IMPLICIT ExtendedCertificate,
                                           -- Obsolete
  attrCert             [1] IMPLICIT AttributeCertificate }
                                           -- See X.509 used to
       sign this SignedData.PKIData creating the GL (i.e., the
       immediate signer). Multiple GLOs MAY be indicated if
       glAdministration is set to managed or closed.

     - glAdministration indicates how the GL should be administered.
       The default is for the list to be unmanaged and X9.57

CertificateRevocationLists ::= SET OF CertificateList

GLOwner ::= SEQUENCE {
  name         GeneralName,
  administered BOOLEAN DEFAULT FALSE OPTIONAL }

EffectiveDate  ::=  SEQUENCE {
  notBefore  [0]  GeneralizedTime,
  notAfter   [1]  GeneralizedTime OPTIONAL }

TransactionId ::= OCTET STRING to accept
       requests from prospective members. Three possibilities exist:

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

       - Managed - When the GLO sets glAdministration to managed, they
         are allowing prospective members to request being added and
         deleted from the GL, but the request is sent to GLO for
         review. The requests are redirected to the GLO. 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
         and deleted from the GL. The GLA will only accept GLAddMembers
         and GLDeleteMembers requests from the GLO.

     - glDistributionMethod indicates the mechanism the GLA should
       distribute shared KEKs. Internet mail (rfc822Name) MUST be
       supported and X.400 (x400Address), X.500 (directoryName), and
       web (uniformResourceIdentifier) MAY be supported (see paragraph
       8).

     - glKeyAttributes indicates the attributes the GLO wants the GLA
       to assign to the shared KEK. If the field is omitted, GL rekeys

Turner                                                               8
       will be controlled by the GLA, the recipients are allowed to
       know about one another, the algorithm will be as specified in
       paragraph 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 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
         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.
         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
         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. See paragraphs 4.5
         and 5 for more on rekey.

Turner                                                               9
       - requestedAlgorithm indicates the algorithm and any parameters
         the GLO wants the GLA to use to generate the shared KEK. See
         paragraph 7 for more on algorithms.

3.1.2 GL Delete

   GLOs use GLDelete to request that a GL be deleted from the GLA.

   GLDelete ::= GLNameAndIdentifier

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

   The fields in GLDelete have the following meaning:

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

     - glIdentifier indicates the identifier of the GL to be deleted.
       It MAY be omitted if it is unknown (e.g., the GLO hasn't
       received a GLSuccessInfo assigning the glIdentifier to the GL)
       or has been lost by the GLO.

3.1.3 GL Add Members

   GLOs use GLAddMembers to request addition of new members and
   prospective GL members' use GLAddMembers to request being added to
   the GL.

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

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

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

   CertificateSet ::= SET OF CertificateChoices

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

     - glMembers indicates the particulars for the GL member(s) to be
       added to the GL. GLMemberName indicates the name of the GL
       member. certificates.membersPKC includes the member's encryption
       certificate that will be used to encrypt the shared KEK for that
       member. certificates.membersAC MAY be included to convey any
       attribute certificate associated with the member's encryption
       certificate. certificates.certificationPath MAY also be included
       to convey the certification path corresponding to the member's
       encryption and attribute certificates. The certification path is
       optional because it may already be included elsewhere in the
       message (e.g., in the outer CMS layer).

     - glIdentifier indicates the identifier of the GL to which the
       member should be added. It MAY be omitted if it is unknown
       (e.g., the GLO hasn't received a GLSuccessInfo assigning the
       glIdentifier to the GL) or has been lost by the GLO. The
       prospective GL member MAY omit this field. The GLO MUST omit the
       field if the GLAddMembers associated GLUseKEK message is
       included in the same SignedData.PKIData content-type.

3.1.4 GL Delete Members

   GLOs use GLDeleteMembers to request deletion of GL members and
   prospective non-GL members use GLDeleteMembers to request being
   removed from the GL.

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

   The fields in GLDeleteMembers have the following meaning:

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

Turner                                                              11
     - glMembersToDelete indicates the name of the member to be
       deleted.

     - glIdentifier indicates the identifier of the GL to which the
       member should be deleted. The prospective non-GL member MUST
       include the field. The GLO MAY omit this field if it is unknown
       (e.g., the GLO hasn't received a GLSuccessInfo assigning the
       glIdentifier to the GL) or has been lost by the GLO.

3.1.5 GL Rekey

   GLOs use the GLRekey to request a GL rekey.

   GLRekey ::= SEQUENCE {
     glName               GeneralName,
     glIdentifier         GLIdentifier,
     glOwner              SEQUENCE SIZE (0..MAX) OF GeneralName,
     glAdministration     GLAdministration OPTIONAL,
     glDistributionMethod GLDistributionMethod OPTIONAL,
     glKeyAttributes      GLKeyAttributes OPTIONAL }

   The fields in GLRekey have the following meaning:

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

     - glIdentifier identifies the shared KEK to be rekeyed.

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

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

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

     - glKeyAttributes 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 the GLO is indicating that it wants all of the
       outstanding GL shared KEKs rekeyed. For example, suppose the GLO
       used the GLUseKEK with duration set to two (2) and the GLRekey
       message is sent during the first duration with generationCounter
       set to zero (0).  The GLA would know to generate a GLKey message

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

3.1.6 GL Add Owner

   GLOs use the GLAddOwners to request that a new GLO be allowed to
   administer the GL.  These requests are only applicable to GLs that
   are managed (i.e., administered.managed) or closed (i.e.,
   administered.closed).

   GLAddOwners ::= GLOwnerAdministration

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

   The fields in GLAddOwners have the following meaning:

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

     - glOwner indicates the name(s) of the new GLO(s).

     - glIdentifier optionally indicates the identifier of the GL to
       which the GLO should be associated. It MAY be omitted if it is
       unknown (e.g., the GLO hasn't received a GLSuccessInfo assigning
       the glIdentifier to the GL) or has been lost by the GLO

3.1.7 GL Remove Owner

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

   GLRemoveOwners ::= GLOwnerAdministration

   The fields in GLRemoveOwners have the following meaning:

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

     - glOwner indicates the name of the GLO.

     - glIdentifier optionally indicates the identifier of the GL to
       which the GLO should be disassociated. It MAY be omitted if it
       is unknown (e.g., the GLO hasn't received a GLSuccessInfo
       assigning the glIdentifier to the GL) or has been lost by the
       GLO

Turner                                                              13

3.1.8 GL Key Compromise

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

   GLKCompromise ::= GLNameAndIdentifier

   The fields in GLKeyCompromise have the following meanings:

     - glName indicates the name of the GL.

     - glIdentifier indicates the identifier of the GL for which the
       shared KEK is associated. The GL members MAY omit this field if
       it is unknown.

3.1.9 GL Key Refresh

   GL members use the GLKRefresh to request that the shared KEK be
   redistributed to them.

   GLKRefresh ::= GLNameAndIdentifier

   The fields in GLKRefresh have to following meaning:

     - glName indicates the name of the GL.

     - glIdentifier indicates the identifier of the GL for which the
       shared KEK is associated. The GL members MAY omit this field if
       it is unknown.

3.1.10 GL Success Information

   The GLA uses GLSuccessInfo to indicate a successful result of an
   administrative message.

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

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

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

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

   The fields in GLSuccessInfo have the following meaning:

     - glName indicates the name of the GL.

     - glIdentifier identifies the specific GL on the GLA (the GLA may
       support multiple GLs).

     - 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 or deleted to or from a specific GL, whether the GL
       rekeyed, whether a new GLO was added, and whether a GLO was
       deleted. If members were added or deleted from a GL the members
       MUST be indicated in glMemberName.  If a GLO was added or
       deleted from the GL, the GLO(s) MUST be indicated in
       glOwnerName.

3.1.11 GL Fail Information

   The GLA uses GLFailInfo to indicate that there was a problem
   performing a requested action.

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

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

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

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

   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 the error corresponds to a GL member or
       GLO, a separate Error sequence MUST be used for each GL member
       or GLO.  The errors are returned under the following conditions:

       - unspecified indicates that the GLA is unable to perform the
         requested action but is unwilling 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.

       - unsupportedDistribtuionMethod indicates that the GLA does not
         support any of the requested delivery methods.

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

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

       - noGLONameMatch indicates the name in one of the certificates
         used to sign a request does not match the name of the
         registered GLO.

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

       - invalidGLNameGLIdentifierCombination indicates the GLA does
         not support the glName and glIdentifier 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 glMembers.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.

       - 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-GL member is not a
         GLO.

     - glIdentifier identifies the specific GL. It MAY be omitted if
       the response is a result of a GLUseKEK request otherwise it MUST
       be present.

3.1.12 GLA Query Request

   GLOs use the GLQueryRequest to ascertain what type of GL the GLA
   supports.

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

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

   The fields in GLAQueryRequest have the following meaning:

     - supportedAlgorithms indicates the GLO would like to know the
       algorithms the GLA supports for generating and distribution the
       shared KEK.

     - distributionMethod indicates the GLO would like to know the
       distribution methods the GLA supports for distributing the
       shared KEK.

Turner                                                              17

3.1.13 GLA Query Response

   GLA's return the GLAQueryResponse after receiving a GLAQueryRequest.

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

   The fields in GLAQueryResponse have the following meaning:

     - supportAlgorithms indicates the algorithm(s) and parameters that
       GLA supports for generating and distributing the shared KEK.

     - distributionMethod indicates the distribution method(s) the GLA
       supports for distribution the shared KEK.

3.1.14 GL Key

   The GLA uses GLKey to distribute the shared KEK.

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

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

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

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

   SubjectKeyIdentifier ::= OCTET STRING

   The fields in GLKey have the following meaning:

     - glName is the name of the GL.

     - glIdentifier identifies the specific GL on the GLA (the GLA may
       support multiple GLs). Two options are provided.  The
       issuerNameAndCounter alternative identifies the GLA's who

Turner                                                              18
       created shared KEK and a counter. The keyIdentifierAndCounter
       choice identifies the GLA's certificate that was used to encrypt
       the shared KEK for the GL members and a counter. In either case
       the counter is a monotonically increasing number. The
       keyIdentifierAndCounter choice MUST be supported.

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

     - glkAlgorithm identifies the algorithm the shared KEK is used
       with.

     - glkNotBefore indicates the date at which the shared KEK is
       considered valid. GeneralizedTime values MUST be expressed
       Greenwich Mean Time (Zulu) and MUST include seconds (i.e., times
       are YYYYMMDDHHMMSSZ), even where 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
       Greenwich Mean Time (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.

3.2 Use of CMC, CMS, and PKIX

3.2.1 Protection Layers

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

Turner                                                              19

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
   message MUST also be encrypted. 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 supposed
   to forward the GL member request 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

   Multiple requests and responses MAY be combined in one PKIData or
   PKIResponse by using PKIData.cmsSequence and
   PKIResponse.cmsSequence. A separate cmsSequence MUST be used for
   different GLs (i.e., requests corresponding to two different GLs are
   included in different cmsSequences). The following is a diagram
   depicting multiple requests and responses combined in one PKIData
   and PKIResponse:

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

   When applying confidentiality to multiple requests and responses,
   either each request or response MAY be encrypted individually or all
   of the requests/response MAY be included in one EnvelopedData. The
   following is a depiction of the choices using PKIData:

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

Turner                                                              21
   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   & GLDeleteMembers
     GLUseKEK   & GLRekey
     GLUseKEK   & GLDelete
     GLDelete   & GLAddMembers
     GLDelete   & GLDeleteMembers
     GLDelete   & GLRekey
     GLDelete   & GLAddOwners
     GLDelete   & GLRemoveOwners
     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 GLAddMembers,
   GLAddMembers before GLRekey, GLDeleteMembers before GLRekey, and
   GLSuccessInfo before GLKey.

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

3.2.3 GLA Generated Messages

   When the GLO generates a GLSuccessInfo, it generates one for the GL
   member and another for the GLO, depending on the actionCode.
   action.actionCode values of assignedKEK, deletedGL, rekeyedGL,
   addedGLO, and deletedGLO are not returned to GL members. Likewise,
   when the GLO generates GLFailInfo it generates one for the GL member
   and one for the GLO, depending on the actionCode. error values of
   unsupportedDuration, unsupportedDeliveryMethod,
   unsupportedAlgorithm, noGLONameMatch, nameAlreadyInUse,
   alreadyAnOwner, notAnOwner are not returned to GL members.

   Separate GLSucessInfo, GLFailInfo, and GLKey messages MUST be
   generated for each recipient if GL was setup with
   GLKeyAttributes.recipientMutuallyAware set to FALSE.

   If the GL has multiple GLOs, the GLA MUST send a copy of all
   GLSuccessInfo and GLFailInfo messages to each GLO.

   If a GL is managed and the GLA receives a prospective GL member add
   or delete request or the GLO receives a GLFailInfo from the GL. and
   the GL is managed, the GLA forwards the request to the GLO for
   review. An additional, SignedData MUST be applied to the forwarded
   request as follows:

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

3.2.4 CMC Control Attributes

   ** Elaborate more **

   Can use:

   CMCFailInfo.badMessageCheck - To indicate signature did not verify.

   transactionId - To track particular requests/responses.

   senderNonce and recipientNonce - For sequence integrity.

3.2.5 PKIX

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

   Name matching is performed according to PKIX [5].

4 Administrative Messages

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

4.1 Assign KEK To GL

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

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

                Figure 3 - Create Group List

Turner                                                              23
   The process is as follows:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

       c - If 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
           distribution methods supported by the GLA (see paragraph
           4.9).

4.2 Delete GL From GLA

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

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

                 Figure 4 - Delete Group List

   The process is as follows:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

4.3 Add Members To GL

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

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

                   Figure 5 - Member Addition

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

Turner                                                              28
   added. Typically, unmanaged GLs should not be rekeyed when a new
   member is added, as the overhead associated with rekeying the group
   becomes prohibitive, as the group becomes large. However, managed
   and closed GLs MUST be rekeyed to maintain the secrecy of the group.
   An option to rekeying the managed GLs when a member is added is to
   generate a new GL with a different group key. Group rekeying is
   discussed in paragraphs 4.5 and 5.

4.3.1 GLO Initiated Additions

   The process for GLO initiated GLAddMembers requests is as follows:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Turner                                                              30
                 1 - If the member's encryption certificate does not
                     verify, the GLA MUST return a response indicating
                     GLFailInfo.errorCode.invalidCert.

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

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

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

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

              a _ If the signer is neither a registered GLO or the
                   prospective GL member, the GLA MUST return a
                   response indicating GLFailInfo.errorCode.noSpam.

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

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

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

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

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

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

               c - If the signer is the prospective member, the GLA
                   forwards the GLAddMembers request (see paragraph
                   3.2.3) to the GLO (B{A} in Figure 5). Which GLO the
                   request is forwarded to is beyond the scope of this
                   document. Further processing of the forwarded
                   request by the GLO is addressed in 3 of paragraph
                   4.3.2.

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

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

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

               a - If the signer is not the GLO or the prospective
                   member, the GLA MUST return a response indicating
                   GLFailInfo.errorCdoe.noSpam.

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

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

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

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

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

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

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

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

       c - If 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 or GLFailInfo response, the
         prospective member verifies the GLA's signature(s). If an
         additional SignedData and/or EnvelopedData encapsulates the
         response (see paragraph 3.2.1.2 or 3.2.2), the GLO MUST verify
         the outer signature and/or decrypt the outer layer prior to
         verifying the signature on the inner most SignedData.

       a - If the signatures do not verify, the prospective member MUST
           return a response indicating CMCFailInfo.badMessageCheck.

Turner                                                              33
       b - If the signatures do verify, the prospective member has been
           added to the GL.

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

4.3.2 Prospective Member Initiated Additions

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

     1 - The prospective GL member sends a
         SignedData.PKIData.controlSequence.GLAddMembers request to the
         GLA (A in Figure 5). The prospective GL member MUST include:
         the GL name in glName, the member's name in
         glMembers.glMemberName, their encryption certificate in
         glMembers.certificates.membersPKC. The prospective GL member
         MAY also include the GL identifier in glIdentifier, if known,
         any attribute certificates associated with their encryption
         certificate in glMembers.certificates.membersAC, and the
         certification path associated with their encryption and
         attribute certificates in
         glMembers.certificates.certificationPath

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

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

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

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

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

       b - If the signature(s) does(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 glMembers.glMemberName.

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

         2 - If 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 glMembers.glMemberName is not
             already on the GL.

           a - If the GLO determines the prospective member is not
               allowed to join the GL, the GLO MAY return a message,
               which is beyond the scope of this document, to indicate
               why the prospective member is not allowed to join.

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

             1 - If the member's certificate does not verify, the GLO
                 MAY return a message, which is out of scope, to the
                 prospective member indicating that their encryption
                 certificate is not valid.

             2 - If the member's certificate does verify, the GLO
                 reforms GLAddMembers request (the prospective member's
                 signature is discarded and the GLO applies their own
                 signature) to the GLA (1 in Figure 5) by including:
                 the GL name in glName, the member's name in
                 glMembers.glMemberName, the member's encryption
                 certificate in glMembers.certificates.membersPKC. The
                 GLO MAY also include the GL identifier in
                 glIdentifier, if known, any attribute certificates
                 associated with the member's encryption certificate in
                 glMembers.certificates.membersAC, and the
                 certification path associated with the member's
                 encryption and attribute certificates in
                 glMembers.certificates.certificationPath.

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

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

     4 - Processing continues as in 2 of paragraph 4.3.1.

Turner                                                              35

4.4 Delete Members From GL

   To delete members from GLs, either the GLO or prospective non-
   members use the GLDeleteMembers request. There are however different
   scenarios that should be supported. Either the GLO or prospective
   members may submit the GLDeleteMembers request to the GLA, but the
   GLA processes the 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 the 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 3.1.1). In the unmanaged case, the GLA merely
   processes the member's request. For the managed case, the GLA
   forwards the requests from the prospective members to the GLO. Where
   there are multiple GLOs for a GL, which GLO the request is forwarded
   to is beyond the scope of this document. In the closed case, the GLA
   will not accept requests from prospective members. The following
   paragraphs describe the processing required by the GLO, GLA, and
   prospective non-GL members depending on where the request
   originated, either from the GLO or from prospective members. Figure
   6 depicts 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 be
   able to receive and decrypt data protected with the shared KEK and
   will continue to receive shared KEK rekeys. For unmanaged lists,
   there is no point to a group rekey because there is no guarantee
   that the member requesting to be removed has not already added
   themselves back on the list under a different name. For managed and
   closed GLs, the GLO MUST take steps to ensure the member being
   deleted is not on the list twice. After ensuring this, the managed
   GL MUST be rekeyed to maintain the secrecy of the group. If the GLO
   is sure the member has been deleted the group rekey mechanism MAY be
   used to distribute the new key (see paragraphs 4.5 and 5).

Turner                                                              36

4.4.1 GLO Initiated Deletions

   The process for GLO initiated GLDeleteMembers requests is as
   follows:

     1 - The GLO collects the names and pertinent information for the
         members to be deleted (this MAY be done through an out of
         bands means). The fields GLO then sends a
         SignedData.PKIData.controlSequence.GLDeleteMembers request to
         the GLA (1 in GKSResponse have Figure 6). The GLO MUST include: the following meaning:

Note: GL name in
         glName and the member's name in glMembersToDelete. The support requirement for GLO MAY
         omit the fields glIdentifier if it is determined by unknown. If the action
being performed; therefore, GL from which
         the support requirements are indicated member is being deleted in
paragraphs 3.1.1.3 through 3.1.1.7, where a closed or managed GL, the specific actions are
defined. GLO
         MUST also generate a GLRekey request and include it with the
         GLDeleteMember request (see paragraph 4.5).

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

       b - The version number MUST be 0. GLO MAY also optionally apply another SignedData over
           the EnvelopedData (see paragraph 3.2.1.2).

     2 - gkaAction indicates Upon receipt of the action that request, the GL Owner requests GLA verifies the GMA
perform, thatthe GL Owner requests signature on
         the KMA perform, inner most SignedData.PKIData. If an additional SignedData
         and/or EnvelopedData encapsulates the request (see paragraph
         3.2.1.2 or 3.2.2), the GMA requests GLA MUST verify the KMA perform. The GL Owner MAY request that either outer signature
         and/or decrypt the KMA or GMA
create a GL (createGL), delete a GL (deleteGL), add a member outer layer prior to verifying the
         signature on the inner most SignedData.

       a
specific GL (addGLMembers), delete a member of - If the signature(s) does(do) not verify, the GLA MUST return
           a specific response indicating CMCFailInfo.badMessageCheck.

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

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

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

         3 - If the KMA. The GMA
MAY request, on behalf of glIdentifier is omitted and the GL members, that a member be added or
deleted, assuming glName is supported
             by the GL policy allows this function. All of GLA or if the actions
have glIdentifier/glName combination is

Turner                                                              37
             supported by the same syntax (GLInformation). Different combinations of GLA, the
GLInformation are used GLA MUST check to provide information necessary for see if the KMA or
GMA to perform its requested action. The field combinations are
discussed in 3.1.1.3 through 3.1.1.7, but fields in GLInformation have
             glMemberName is present on the following meaning: GL.

           a - glName If the glMemberName is not present on the name of GL, the GL. GLA
               MUST return a response indicating
               GLFailInfo.errorCode.notAMember.

           b - glIdentifier If the glMemberName is not already on the GL identifier. The GL identifier identifies GL, the specific GL on GLA
               MUST check how the GMA (the GMA may support multiple GLs). It GL is
derived from administered.

             1 - If the group key and GL is returned by closed, the KMA.

    - gkMembers is a collection of GLA MUST check that GLO
                 signed the member(s) request by checking that should be either
added or deleted from one of the GL. The member's name is a GeneralName.
deliveryMethod identifies names
                 in the method by which and address or location digital signature certificate used to
which the KMA should distribute sign the group key. Only
                 request matches one choice for each of the type is allowed (i.e., only one rfc822Name may appear for registered GLOs.

               a given
member). certificates and crls are - If the member's certificate, associated
certificates, and associated certificate revocation lists (CRLs). names do not match, the GLA MUST return a
                   response indicating
                   GLFailInfo.errorCode.noGLONameMatch.

               b - glOwner is If the owner of names do match, the GL. It identifies GLA MUST return to all
                   GLOs a GLSucessInfo indicating the entity that
controls glName, the GL. It
                   corresponding glIdentifier, an
                   action.actionCode.deletedMember, and
                   action.glMemberName (2 in Figure 5). The response
                   MUST be constructed as in paragraph 3.2.3. The GLA
                   also indicates whether takes administrative actions, which are beyond
                   the GL is managed or
unmanaged.

    - effectiveDate indicates scope of this document, to delete the dates that member
                   with the GL Owner wants stored on the KMA GLA. The GLA will also
                   rekey group as described in paragraph 5.

                 1 - The GLA MUST apply confidentiality to set the gkNotBefore and gkNotAfter to response
                     by encapsulating the SignedData.PKIData in an
                     EnvelopedData if the request was encapsulated in
                     an EnvelopedData (see paragraph 3.1.2). 3.2.1.2).

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

             2 - If the GL Owner wants is managed, the key to become
effective and GLA MUST check that either
                 the notAfter indicates GLO or the date prospective member signed the GL Owner wants request.
                 For the key GLO, one of the names in the certificate used
                 to become invalid.

    - distributionDate indicates sign the date that request MUST match one of the GL Owner wants registered
                 GLOs. For the
key distributed.

  - transactionID supports prospective member, the recipient name in
                 glMembers.glMemberName MUST match one of a response message to
correlate this with a previously issued request. For example, the names in
                 the
case of certificate used to sign the request.

               a GMA, which supports multiple GLs, there may be many requests
"outstanding" at _ If the signer is neither a given moment.

3.1.1.2 Response To Group Key Administration

Upon receipt of registered GLO or the gkaRequest content-type
                   prospective GL member, the KMA GLA MUST use the
gkaResponse content-type to indicate the success or failure of return a
                   response indicating GLFailInfo.errorCode.noSpam.

Turner                                                              38
               b - If the
request. The gkaResponse signer is not sent until after the KMA has determined
whether GLO, the member is able GLA MUST return to receive all
                   GLOs a GLSucessInfo indicating the key. glName, the
                   corresponding glIdentifier, an
                   action.actionCode.deletedMember, and
                   action.glMemberName (2 in Figure 6). The KMA may not response
                   MUST be able constructed as in paragraph 3.2.3. The GLA
                   also takes administrative actions, which are beyond
                   the scope of this document, to send delete the member a group key because either
                   with the deliveryMethod is
unsupported or GL stored on the member's certificate is invalid. GLA. The GLA will also
                   rekey group as described in paragraph 5.

                 1 - The id-gkaRequest
content-tye GLA MUST be processed according apply confidentiality to [CMS]. The KMA MUST validate the member's certificate and associated certificates to response
                     by encapsulating the KMA trusted
CA according to [PROFILE] prior to sending a gkaResponse message
indicating success. SignedData.PKIData in an
                     EnvelopedData if the request was encapsulated in
                     an EnvelopedData (see paragraph 3.2.1.2).

                 2 - The gkaResponse message MUST be protected at a
minimum by id-signedData [CMS]. Other layers GLA MAY also be used. The
following object identifier identifies optionally apply another
                     SignedData over the gkaRequest content type:

id-ct-gkaResponse OBJECT IDENTIFIER ::= { TBD }

The gkaResponse content type MUST have ASN.1 type GKAResponse:

GKAResponse ::= SEQUENCE {
  gkaResponseVersion     GKAResponseVersion,
  success                BOOLEAN DEFAULT TRUE,
  glIdentifier           OCTET STRING OPTIONAL,
  errorCode              ErrorCode OPTIONAL,
  transactionId          TransactionId OPTIONAL,
  supportDeliveryMethods DeliveryMethod OPTIONAL}

ErrorCode ::= INTEGER {
  unspecified (0),
    -- Unspecified indicates that EnvelopedData (see paragraph
                     3.2.1.2).

               c - If the KMA signer is unable to
    -- distribute a group key to the prospective member, but the KMA GLA
                   forwards the GLDeleteMembers request (see paragraph
                   3.2.3) to the GLO (B{A} in Figure 6). Which GLO the
                   request is
    -- unwilling forwarded to indicate why.
  managedGL (1)
    -- Indicates that members can only be added or deleted is beyond the scope of this
                   document. Further processing of the forwarded
                   request by the GL
    -- Owner. It GLO is sent back addressed in 3 of paragraph
                   4.4.2.

                 1 - The GLA MUST apply confidentiality to the requestor if
                     forwarded request by encapsulating the entity requesting
    --
                     SignedData.PKIData in an addition is not the GL Owner.
  effectiveDateTooLong (2)
    -- Returned EnvelopedData if the KMA does not support generating keys that are
    -- valid for the entire requested effective dates.
  unsupportedDeliveryMethod (3),
    -- Unsupported delivery method indicates that the KMA does
    -- not support any of the requested delivery methods.
  invalidCert (4),
    -- Certificate for member
                     request was not verifiable (i.e., signature
    -- did not validate, certificate present on a CRL, etc.)
  }

GKAResponseVersion ::= INTEGER  { v0(0) }

The fields encapsulated in GKAResponse have an EnvelopedData (see
                     paragraph 3.2.1.2).

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

             3 - version If the GL is unmanaged, the syntax version number.  It GLA MUST be 0.

  - success indicates whether check that either
                 the KMA is able GLO or the prospective member signed the request.
                 For the GLO, one of the names in the certificate used
                 to send a group key sign the request MUST match one of the registered
                 GLOs. For the prospective member, the name in
                 glMembers.glMemberName MUST match one of the names in
                 the certificate used to sign the
member. request.

               a - If the KMA signer is unable to distribute not the group key to GLO or the prospective
                   member,
it the GLA MUST indicate an errorCode. return a response indicating
                   GLFailInfo.errorCode.noSpam.

               b - glIdentifier indicate If the GL identifier, derived from signer is either the group key.

  - errorCode indicates GLO or the reason why member, the KMA was unable to distribute
                   GLA MUST return a group key to GLSucessInfo indicating the member. Reasons include unspecified, managedGL,
effectiveDateTooLong, unsupportedDeliveryMethod, and invalidCert.

  - transactionID supports

Turner                                                              39
                   glName, the recipient of a response message corresponding glIdentifier, an
                   action.actionCode.deletedMember, and
                   action.glMemberName to
correlate this with a previously issued request. For example, in the
case of a GMA, which supports multiple GLs, there may be many requests
"outstanding" at a given moment.

  - supportedDeliveryMethod MAY be included the indicate GLO (2 in Figure 6) if
                   the delivery
methods GLO signed the KMA supports.

3.1.1.3 Create Group

Prior request and to generating a group key, a GL MUST be setup. The GL Owner is
responsible for creating the GL (1 member (3
                   in Figure 3). The 6) if the GL Owner MAY use a
proprietary mechanism (e.g., listserv or majordomo) or member signed the group key
administration mechanism defined request.
                   The response MUST be constructed as in the paragraph below to perform this
function.

               +----------+ 2,4{3}
               | GL Owner | <-----+
               +----------+       |
                            1     |
  +-----+ 2{1}    3 +-----+ <-----+
  | KMA | <-------> | GMA |
  +-----+           +-----+

      Figure 3 - Create Group List

If
                   3.2.3. The GLA also takes administrative actions,
                   which are beyond the GL Owner decides scope of this document, to use
                   delete the gkaRequest content-type to setup member with the GL stored on the GMA, the gkaRequest content-type GLA.

                 1 - The GLA MUST be submitted apply confidentiality to the GMA
(1 response
                    by encapsulating the SignedData.PKIData in Figure 2) with an
                    EnvelopedData if the gkaAction.createGL CHOICE. request was encapsulated in an
                    EnvelopedData (see paragraph 3.2.1.2).

                 2 - The format for GLA MAY also optionally apply another
                    SignedData over the
createGL CHOICE is as follows: EnvelopedData (see paragraph
                    3.2.1.2).

     3 - glName Upon receipt of the GLSuccessInfo or GLFailInfo response, the
         GLO verifies the GLA's signatures. If an additional SignedData
         and/or EnvelopedData encapsulates the response (see paragraph
         3.2.1.2 or 3.2.2), the GLO MUST be included verify the outer signature
         and/or decrypt the outer layer prior to indicate verifying the name of
         signature on the GL. The value
must be unique for inner most SignedData.

       a given distribution method. - glIdentifier If the signature(s) does(do) not verify, the GLO MUST be omitted as return
           a response indicating CMCFailInfo.badMessageCheck.

       b - If the value is derived signature(s) does(do) verify, the GLO has deleted the
           member from the group
key, which is not yet created. GL.

       c - glMembers MAY be included to indicate If the member(s) GLO received a GLFailInfo, for any reason, the GLO
           may reattempt to be added. If
members are included delete the name member from the GL using the
           information provided in the GLFailInfo response.

     4 - Upon receipt of the GLSuccessInfo or GLFailInfo response, the
         prospective member verifies the GLA's signature(s). If an
         additional SignedData and/or EnvelopedData encapsulates the
         response (see paragraph 3.2.1.2 or 3.2.2), the GLO MUST be include in
GLMember.name. The delivery method MAY be included. verify
         the outer signature and/or decrypt the outer layer prior to
         verifying the signature on the inner most SignedData.

       a - If the GMA does signature(s) does(do) not
support verify, the requested delivery method an error prospective
           member MUST be returned. The
members certificates and crls MAY also be included. return a response indicating
           CMCFailInfo.badMessageCheck.

       b - glOwner.name MUST be included to indicate If the Owner of signature(s) does(do) verify, the prospective member
           has been deleted from the GL. The
GL Owner is

       c - If the only entity allowed prospective member received a GLFailInfo, for any
           reason, the prospective member MAY reattempt to delete

Turner                                                              40
           themselves from the GL (see paragraph
3.1.1.4).  If using the list information provided in the
           GLFailInfo response.

4.4.2 Member Initiated Deletions

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

     1 - The prospective non-GL member sends a
         SignedData.PKIData.controlSequence.GLDeleteMembers request to be managed (i.e., only allow
         the GL Owner
to add or delete GL members) glOwner.administered GLA (A in Figure 5). The prospective non-GL member MUST be set to TRUE;
otherwise,
         include: the list GL name in glName and their name in
         glMembersToDelete.  The prospective non-GL member MAY omit the
         glIdentifier if it is considered to be unmanaged. unknown.

       a - The GMA MUST only
allow additions (see paragraph 3.1.1.5) prospective non-GL member MAY optionally apply
           confidentiality to the GL if one of request by encapsulating the glOwner
names matches one of
           SignedData.PKIData in an EnvelopedData (see paragraph
           3.2.1.2).

       b - The prospective non-GL member MAY also optionally apply
           another SignedData over the names associated with one EnvelopedData (see paragraph
           3.2.1.2).

     2 - Upon receipt of the certificates
used to sign request, the GLA verifies the id-signedData. request as
         per 2 in paragraph 4.4.1.

     3 - effectiveDate MAY be included to indicate Upon receipt of the forwarded request, the dates GLO verifies the
         prospective GL Owner
wishes member's signature on the key to become effective. If this field is omitted inner most
         SignedData.PKIData and the GMA
assumes GLA's signature on the gkNotBefore date outer layer.
         If an EnvelopedData encapsulates the inner most layer (see
         paragraph 3.1.2) is 3.2.1.2 or 3.2.2), the GMA's current
date.

  - distributionDate MAY be included to indicate GLO MUST decrypt the date outer
         layer prior to verifying the GL Owner
wishes signature on the key to be distributed. inner most
         SignedData.

       a - If the distributitionDate is omitted signature(s) does(do) not verify, the GMA assumes GLO MUST return
          a response indicating CMCFailInfo.badMessageCheck.

       b - If the group key should be distributed immediately.

The GMA then forwards signature(s) does(do) verify, the gkaRequest content-type GLO MUST check to
          make sure the KMA (2{1} name in
Figure 3). An additional id-signedData or some other combination one of id-
signedData and id-envelopedData MAY protect the forwarded content-type.

Upon receipt of certificates used to sign
          the gkaRequest content-type, request is the KMA verifies entity indicated in glMembersToDelete.

         1 - If the
gkaRequest content-type and returns names do not match, the GLO may send a gkaResponse (3 in Figure 3). If message
             back, which is out of scope, to the prospective member,
             depending on policy, to indicate that GL members can be created as requested, the KMA MUST return a gkaResponse only
             add themselves lists.  This stops people from adding
             people to GLs without their permission.

         2 - If the GMA indicating success and names do match, the glIdentifier of GLO deletes the newly created
list. If member from the
             GL can not be created as requested by sending the KMA returns a
gkaResponse reformed GLDeleteMembers request (the
             prospective non-GL member's signature is stripped off and

Turner                                                              41
             the GLO signs it) to the GMA indicating failure along with an errorCode.

If there are members included GLA (1 in Figure 6). The GLO MUST
             make sure the gkaRequest glMemberName is already on the KMA list and only
             on the list once. The GLO MUST use also generate a GLRekey
             request and include it with the
mechanism described in GLDeleteMember request
             (see paragraph 3.2 4.5).

           a - The GLO MUST apply confidentiality to distribute the group key.

The GMA then forwards new
               GLDeleteMember request by encapsulating the gkaResponse content-type to
               SignedData.PKIData in an EnvelopedData if the GL Owner (4{3} initial
               request was encapsulated in Figure 3). An additional id-signedData or some other combination of
id-signedData and id-envelopedData an EnvelopedData (see
               paragraph 3.2.1.2).

           b - The GLO MAY protect also optionally apply another SignedData
               over the forwarded conent-
type.

3.1.1.4 Delete Group

To delete a GL (1 EnvelopedData (see paragraph 3.2.1.2).

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

4.5 Request Rekey Of GL

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

     - When a proprietary
mechanim (e.g., listserv or majordomo) member is removed from a closed or the group key administration
mechanism defined in the paragraph below to perform managed GL. In this function. Only
       case, the GL Owner can request that PKIData.controlSequence containing the GLDeleteMembers
       should contain a GL be deleted.

               +----------+ 2,4{3}
               | GL Owner | <-----+
               +----------+       |
                            1     |
  +-----+ 2{1}    3 +-----+ <-----+
  | KMA | <-------> | GMA |
  +-----+           +-----+

      Figure 4 GLRekey request.

     - Delete Group List Depending on policy, when a member is removed from an unmanaged
       GL. If the GL Owner decides to use the gkaRequest content-type policy is to delete rekey the GL, the gkaRequest content-type MUST
       PKIData.controlSequence containing the GLDeleteMembers could
       also contain a GLRekey request or an out of bands means could be submitted
       used to tell the GMA (1 in
Figure 2) with GLA to rekey the GL. Rekeying of unmanaged GLs
       when members are deleted is not advised.

     - When the gkaAction.deleteGL CHOICE. current shared KEK has been compromised. The format GLA will
       automatically perform an rekey without waiting for approval from
       the
deleteGL CHOICE is as follows: GLO.

     - glName MUST be included to indicate the name of When the GL current shared KEK is about to be
deleted. expire.

       - glIdentifier MUST be included to indicate If the identifier of GLO controls the GL
to be deleted.

  - glMembers MUST rekey, the GLA should not assume
         that a new shared KEK should be omitted. distributed, but instead wait
         for the GLRekey message.

       - glOwner MUST be included to indicate If the name of GLA controls the GL Owner.
administered MUST be omitted. The name in this field MUST match one of
the names in one of rekey, the certificates used GLA should initiate a
         GLKey message as specified in content-type used to create
the group.

  - effectiveDate MUST be omitted.

  - distributionDate MUST be omitted.

The GMA MUST not accept further requests from users (in paragraph 5.

   If the case of
unadministered GLs) generationCounter (see paragraph 3.1.1) is set to be added or deleted from a value
   greater than one (1) and the GL. The GMA MUST
forward GLO controls the gkaRequest to GL rekey, the KMA.

Upon receipt of GLO may
   generate a GLRekey any time before the gkaRequest content-type, last shared KEK has expired.
   To be on the KMA verifies safe side, the
gkaRequest content-type and returns GLO should request a gkaResponse (3 in Figure 3)
indicating success and the glIdentifier of rekey 1 duration
   before the deleted GL. errorCode and
supportedDeliveryMethods MUST be omitted. last shared KEK expires.

Turner                                                              42
   The GMA then forwards the gkaResponse content-type to the GL Owner (4{3}
in Figure 3). An additional id-signedData or some other combination of
id-signedData GLA and id-envelopedData MAY protect GLO are the forwarded conent-
type.

3.1.1.5 Add Group Members only entities allowed to initiate a GL setup indicates
   rekey. The GLO indicated whether they are going control rekeys or
   whether the GL GLA is going to be managed or unmanaged. In control rekeys when the
managed case, assigned the
   shared KEK to GL Owner is the only entity allowed (see paragraph 3.1.1). The GLO MAY initiate a GL
   rekey at any time. The GLA MAY be configured to request member
additions automatically rekey
   the GL prior to the GL. In expiration of the unmanaged case, anyone can request to be
added to shared KEK (the length of time
   before the GL. expiration is an implementation decision). Figure 4 7
   depicts the protocol interactions for the two
options.

                   +----------+ 7{6}           2,9{8b} +----------+ 8a
                   | to request a GL Owner | <-+          +-------> | Member 1 | <--+
                   +----------+   |          |         +----------+    |
                               1a |          |                         | rekey. Note that
   error messages are not depicted.

                  +-----+ 4{1a},5 6,8b  1   2,A  +-----+ <--+          | 2,9{8b} +----------+ 8a |
  | KMA | <---------->
                  | GMA GLA | 1b,3          +-------> <-------> |   ... GLO | <--+
                  +-----+           +-----+ <-------------+         +----------+    |
     |                                       |                         |
     |                                       | 2,9{8b} +----------+ 8a |
     |                                       +-------> | Member n | <--+
     |                                                 +----------+    |
     +-----------------------------------------------------------------+

                     Figure 4 7 - Member Addition

A decision that needs 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 and the glIdentifier. The GLO MAY include change the
         glOwner, glAdministration, glDistributionMethod, and
         glKeyAttributes. If glOwner, glAdministration,
         glDistributionMethod, and glKeyAttributes are omitted then
         there is no change from the previously registered GL values
         for these fields. If the GLO wants to force a rekey for all
         outstanding shared KEKs the glKeyAttributes.generationCounter
         MUST be set to zero (0)

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

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

     2 - Upon receipt of the request, the GLA verifies the signature on
         the inner most SignedData.PKIData. If an additional SignedData
         and/or EnvelopedData encapsulates the request (see paragraph
         3.2.1.2 or 3.2.2), the GLA MUST verify the outer signature
         and/or decrypt the outer layer prior to be made verifying the
         signature on a group by group basis is whether to
rekey the group every time inner most SignedData.

       a new member is added. Typically, unmanaged
GLs should - If the signature(s) does(do) not be rekeyed when a new member is added, as verify, the overhead
associated with rekeying GLA MUST return
           a response indicating CMCFailInfo.badMessageCheck.

       b - If the group becomes prohibitive as signature(s) does(do) verify, the group
becomes large. However, managed GLs may be rekeyed depending on group
policy. An option to rekeying GLA MUST make sure
           the managed GLs when a member is added GL is
to generate supported by the GLA by checking that that the

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

         1 - If the glName and glIdentifier present do not match a different group key.

3.1.1.5.1 Managed GLs

The GL Owner MAY use a proprietary mechanism (e.g., listserv or
majordomo) or
             stored on the group key administration mechanism defined below to
add new members to GLA, the GL. GLA MUST return a response
             indicating
             GLFailInfo.errorCode.invalidGLNameGLIdentifierCombination.

         2 - If the glName and glIdentifier present do match a GL Owner decides to use
             stored on the GLA, the gkaRequest content-type GLA MUST be
submitted to check that a registered
             GLO signed the GMA (1a request by checking that one of the names
             in Figure 4) with the gkaAction.addGLMembers
CHOICE. The format for certificate used to sign the addGLMembers CHOICE request is as follows: a
             registered GLO.

           a - glName MUST be included to indicate If the name of names do not match, the GL. GLA MUST return a
               response indicating GLFailInfo.errorCode.noGLONameMatch.

           b - glIdentifier If all the names do match, the GLA MUST be included return to indicate all
               GLOs a GLSucessInfo indicating the GK that should be
distributed to glName, the new member.
               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 5).

             1 - glMembers The GLA MUST be included apply confidentiality to indicate response by
                 encapsulating the member(s) to be added.
The member(s) name(s) is included SignedData.PKIData in GLMember.name. The delivery method
MAY be included. an
                 EnvelopedData if the request was encapsulated in an
                 EnvelopedData (see paragraph 3.2.1.2).

             2 - The members certificates and crls GLA MAY also be included.

  - glOwner.name MUST be included to indicate optionally apply another SignedData
                 over the Owner EnvelopedData (see paragraph 3.2.1.2).

     3 - Upon receipt of the GL. It 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 3.2.1.2 or 3.2.2), the GLO MUST match verify
         the name one of outer signature and/or decrypt the certificates used forwarded response
         prior to sign this gkaRequest
creating verifying the GL. signature on the inner most SignedData.

       a - effectiveDate If the signature(s) does(do) not verify, the GLO MUST be omitted. The value has no meaning as return
           a response indicating CMCFailInfo.badMessageCheck.

       b - If the group
key signatures verifies, the GLO has been previously setup. successfully rekeyed
           the GL.

       c - distributionDate MAY be included to indicate If the date GLO received a GLFailInfo, for any reason, the GLO
           may reattempt to rekey the GL Owner
wishes using the key to be distributed to information provided
           in the new member(s). GLFailInfo response.

Turner                                                              44

4.5.2 GLA Initiated Rekey Requests

   If the
distributitionDate GLA is omitted the KMA assumes the group key should be
distributed immediately.

Upon receipt in charge of rekeying the gkaRequest, GL or if a GLKCompromise
   message has been properly processed (see paragraph 4.7) the GMA MAY process GLA will
   automatically issue a GLKey message (see paragraph 5).  In addition
   the glMembers and
add GLA will generate a GLSuccessInfo to indicate to the member(s) 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.GLSucessInfo indicating the GL stored on
         glName, the GMA. new glIdentifier, and actionCode.rekeyedGL (A in
         Figure 7).

       a - The GMA then forwards
the gkaRequest content-type GLA MAY optionally apply confidentiality to the KMA (4{1a} request
           by encapsulating the SignedData.PKIData in Figure 4). An
additional id-signedData or some other combination of id-signedData and
id-envelopedData an EnvelopedData
           (see paragraph 3.2.1.2).

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

     2 - Upon receipt of the gkaRequest content-type, GLSuccessInfo response, the KMA GLO verifies
         the
gkaRequest content-type and returns a gkaResponse (6 in Figure 4). GLA's signature(s). If an additional SignedData and/or
         EnvelopedData encapsulates the member can be added, forwarded response (see
         paragraph 3.2.1.2 or 3.2.2), the KMA GLO MUST return a gkaResponse to verify the GMA
indicating success and outer
         signature and/or decrypt the glIdentifier of outer layer prior to verifying
         the GL signature on the member was added
to. inner most SignedData.

       a - If the member can signatures do not be added verify, the KMA GLO MUST return a gkaResponse to
the GMA indicating failure along with an errorCode
           response indicating either
unsupportedDeliveryMethod or invalidCert. The supportDeliveryMethods MAY
also be included to assist the GL Owner in determining whether some
other delivery method could be used to distribute the key to the new
member.

The KMA also distributes the group key via the mechanism described in
paragraph 3.2. The KMA also distributes the group key via the mechanism
described in paragraph 3.1.3. The group key is either distributed
through CMCFailInfo.badMessageCheck.

       b - If the GMA (8b and 9{8b} in Figure 4) or directly to signatures verifies, the members
(8a in Figure 4).

The GMA then forwards GLO knows the gkaResponse content-type to GLA has
           successfully rekeyed the GL Owner (7{6}
in Figure 4). An additional id-signedData or some other combination GL.

4.6 Change GLO

   Management of
id-signedData managed and id-envelopedData MAY protect the forwarded conent-
type.

3.1.1.5.2 Unmanaged closed GLs

For automated scenarios, members send a message (1b in Figure 4), which
MAY be unprotected (i.e., unsigned and unencrypted) or protected via id-
signedData, id-envelopedData, or tripled wrapped (i.e., signed and/or
encrypted) [CMS]. If the message is protected with id-envelopedData the
GMA MUST be can become difficult for one of the recipients. A confirmation message (2 in Figure
4) MAY be sent back to the member requesting confirmation of the initial
request to inhibit spamming (i.e., to avoid someone other than
   GLO if the
member requested GL membership grows large. To support distributing the member
   workload, GLAs support having GL be added to the list). managed by multiple GLOs. The response
   GLAddOwners and GLRemoveOwners messages are designed to the
confirmation message (3 in support
   adding and removing registered GLOs. Figure 4) indicates whether depicts the member really
requested addition protocol
   interactions to send GLAddOwners and GLRemoveOwners messages and the GL.
   resulting response messages.

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

                 Figure 8 _ GLO Add & Delete Owners

Turner                                                              45
   The format process for these messages indicated by
1b, 2, GLAddOwners and 3 in Figure 4 are beyond the scope of this document. GLDeleteOwners is as follows:

     1 - The GMA MAY support generating GLO sends a gkaRequest content-type to SignedData.PKIData.controlSequence.GLAddOwners
         or GLRemoveOwners request
members be added. If the GMA supports generating the gkaRequest content-
type, it MUST be submitted to the KMA (5 GLA (1 in Figure 4) with the
gkaAction.addGLMembers CHOICE. 8). The format for the addGLMembers CHOICE is
as follows

  - glName GLO
         MUST be included to indicate include: the GL name of the GL.

  - glIdentifier MUST be included to indicate in glName, the GK that should be
distributed to GLO(s) in glOwner.
         The GLO MAY also include the new member. glIdentifier.

       a - glMembers MUST be included The GLO MAY optionally apply confidentiality to indicate the member(s) to be added.
The member(s) name(s) is included request
           by encapsulating the SignedData.PKIData in GLMember.name. The delivery method
MAY be included. an EnvelopedData
           (see paragraph 3.2.1.2).

       b - The member's certificates and crls GLO MAY also be
included.

  - glOwner.name MUST be omitted.

  - effectiveDate MUST be omitted.

  - distributionDate MUST be omitted. optionally apply another SignedData over
           the EnvelopedData (see paragraph 3.2.1.2).

     2 _ Upon receipt of the gkaRequest content-type, GLAddOwners or GLRemoveOwners request, the KMA
         GLA verifies the
gkaRequest content-type and returns a gkaResponse (6 in Figure 4). GLO's signature(s). If an additional
         SignedData and/or EnvelopedData encapsulates the member can be added, request (see
         paragraph 3.2.1.2 or 3.2.2), the KMA GLA MUST return a gkaResponse to verify the GMA
indicating success and outer
         signature and/or decrypt the glIdentifier of outer layer prior to verifying
         the GL signature on the member was added
to. inner most SignedData.

       a - If the member can signature(s) does(do) not be added verify, the KMA GLA MUST return a gkaResponse to
the GMA indicating failure along with an errorCode indicating
unspecified, managedGL, unsupportedDeliveryMethod, or invalidCert. The
supportDeliveryMethods MAY also be included to assist the GMA in
determining whether some other delivery method could be used to
distribute the key to the new member.

The KMA also distributes the group key via the mechanism described in
paragraph 3.2. The group key is either distributed through
           a response indicating CMCFailInfo.badMessageCheck.

       b - If the GMA (8b
and 9{8b} in Figure 4) or directly to signature(s) does(do) verify, the members (8a in Figure 4).

3.1.1.6 Delete Group Members

GL setup indicates whether GLA MUST make sure
           the GL is to be managed or unmanaged. In supported by checking either that the
managed case, glName is
           supported (in the GL Owner case the glIdentifier is omitted) or that
           the only entity allowed to request member
deletions to combination of glName and glIdentifier matches a glName
           and glIdentifier combination stored on the GL. In GLA.

         1 - If the unmanaged case, anyone can request to be
removed from glIdentifier is omitted and the GL. Figure 5 depicts glName is not
             supported by the protocol interactions for GLA, the
two options.

                   +----------+ 7{6}
                   | GL Owner | <-+
                   +----------+   |
                               1a |
  +-----+ 4{1a},5 6,8b +-----+ <--+               +----------+
  | KMA | <----------> | GMA | 1b,3 GLA MUST return a response
             indicating GLFailInfo.errorCode.invalidGLName.

         2 | Member X |
  +-----+              |     | <----------------> +----------+
     |                 |     |           9{8b},8a
     |                 +-----+ ------+----------> +----------+
     |                               |            | Member 1 |
     |                               |            +----------+
     +-------------------------------+
                                     |   9{8b},8a +----------+
                                     +----------> | Member n |
                                                  +----------+

                 Figure 5 - Member Deletion If the member is glName and glIdentifier are present and do not removed from
             match a GL stored on the GL, they will continue to be able
to receive and decrypt data protected with GLA, the group key GLA MUST return a
             response indicating
             GLFailInfo.errorCode.invalidGLNameGLIdentifierCombination.

         3 - If the glIdentifier is omitted and will
continue to receive group rekeys. Steps should be taken to the glName is supported
             by the GLA or if the glIdentifier/glName combination is
             supported by the GLA, the GLA MUST ensure a new
group key is registered GLO
             signed the GLAddOwners or GLRemoveOwners request by
             checking if the name present in the digital signature
             certificate used (see paragraph 3.1.3). For unmanaged lists, there is
no point to a group rekey because there is no guarantee that sign the GLDelete request matches one
             of the member
requesting to be removed hasn't already added themselves back on registered GLOs.

           a - If the
list under names do not match, the GLA MUST return a different name. For managed GLs,
               response indicating GLFailInfo.errorCode.noGLONameMatch.

           b - If the GL Owner must take
steps names do match, the GLA MUST return to ensure all GLOs a
               GLSucessInfo indicating the member being deleted is not on glName, the list twice. After
ensuring this, corresponding

Turner                                                              46
               glIdentifier, an action.actionCode.addedGLO or
               removedGLO, and the managed GL respective GLO name in glOwnerName
               (2 in Figure 4). The GLA MUST be rekeyed also take administrative
               actions to maintain associate the secrecy new glOwner name with the GL in
               the case of GLAddOwners or to disassociate the group. If old
               glOwner name with the GL Owner is sure in the member has been deleted cased of GLRemoveOwners.

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

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

       a - The GLO MAY optionally apply confidentiality to distribute the new key request
           by encapsulating the SignedData.PKIData in an EnvelopedData
           (see paragraph
3.1.1.7).

3.1.1.6.1 Managed GLs 3.2.1.2).

       b - The GL Owner GLO MAY use a proprietary mechanism (e.g., listserv also optionally apply another SignedData over
           the EnvelopedData (see paragraph 3.2.1.2).

   3 - Upon receipt of the GLSuccessInfo or
majordomo) GLFailInfo response, the
       GLO verifies the GLA's signature(s). If an additional SignedData
       and/or EnvelopedData encapsulates the response (see paragraph
       3.2.1.2 or 3.2.2), the group key administration mechanism defined below GLO MUST verify the outer signature
       and/or decrypt the outer layer prior to
delete members from verifying the GL. signature
       on the inner most SignedData.

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

     b - If the signatures do verify and the response was
         GLSuccessInfo, the GLO has successfully added or removed the
         GLO.

     c - If 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. The GL Owner decides to members
   use the gkaRequest content-type MUST be
submitted GLKCompromise message to tell the GMA (1a in GLA that the shared KEK
   has been compromised. Figure 4) with 9 depicts the gkaAction.addGLMembers
CHOICE. protocol interactions for
   GL Key Compromise.

Turner                                                              47
                +-----+  2                   3  +----------+
                | GLO | <--------+    +-------> | Member 1 |
                +-----+          |    |         +----------+
                +-----+ ---------+    |      3  +----------+
                | GLA |  1            +-------> |   ...    |
                +-----+ <-------------+         +----------+
                                      |      3  +----------+
                                      +-------> | Member n |
                                                +----------+

                   Figure 9 - GL Key Compromise

   The format process for the addGLMembers CHOICE GLKCompromise is as follows:

     1 - glName MUST be included to indicate the name of the GL.

  - glIdentifier MUST be included to indicate the GK that should be
distributed to the new member.

  - glMembers MUST be included The GL member sends a
         SignedData.PKIData.controlSequence.GLKCompromise request to indicate
         the member(s) to be deleted.
The member(s) name(s) is included GLA (1 in GLMember.name. Figure 9). The delivery method GL member MUST be omitted. The members certificates include glName and crls MUST also be omitted.
         MAY include glIdentifier.

       a - glOwner.name MUST be included The GL member MAY optionally apply confidentiality to indicate the Owner of the GL. It
MUST match the name one of
           request by encapsulating the certificates used to sign this
gkaRequest. SignedData.PKIData in an
           EnvelopedData (see paragraph 3.2.1.2).

       b - effectiveDate MUST be omitted. The value has no meaning as GL member MAY also optionally apply another SignedData
           over the group
key has been previously setup.

  - distributionDate MUST be omitted. EnvelopedData (see paragraph 3.2.1.2).

     2 _ Upon receipt of the gkaRequest, GLKCompromise requst, the GMA MAY process the glMembers and
remove the member for GLA verifies the
         GL stored on member's signature(s). If an additional SignedData and/or
         EnvelopedData encapsulates the GMA. The GMA then forwards request (see paragraph 3.2.1.2
         or 3.2.2), the gkaRequest content-type to GLA MUST verify the KMA (4{1a} in Figure 5). An
additional id-signedData or some other combination of id-signedData and
id-envelopedData MAY protect outer signature and/or
         decrypt the forwarded content-type.

Upon receipt of outer layer prior to verifying the gkaRequest content-type, signature on
         the KMA verifies inner most SignedData.

       a - If the
gkaRequest content-type and returns a gkaResponse (6 in Figure 4). The
KMA signature(s) does(do) not verify, the GLA MUST return
           a gkaResponse to the GMA response indicating success and CMCFailInfo.badMessageCheck.

       b - If the
glIdentifier of signature(s) does(do) verify, the GLA MUST make sure
           the GL is supported by checking either that the member was deleted from.

The GMA then forwards glName is
           supported (in the gkaResponse back to case the GL Owner (7{6} in
Figure 5). An additional id-signedData glIdentifier is omitted) or some other that
           the combination of id-
signedData glName and id-envelopedData MAY protect the forwarded conent-type.

The KMA MUST also use the group key distribution mechanism defined in
paragraph 3.1.3 to provide the remaining members with a new group key.

3.1.1.6.2 Unmanaged GLs

For automated scenarios, members send glIdentifier matches a message (1b in Figure 4), which
MAY be unprotected (i.e., unsigned glName
           and unencrypted) or protected via id-
signedData, id-envelopedData, or tripled wrapped (i.e., signed and/or
encrypted) [CMS]. glIdentifier combination stored on the GLA.

         1 - If the message glIdentifier is protected with id-envelopedData the
GMA MUST be one of the recipients. A confirmation message (2 in Figure
4) MAY be sent back to the member requesting confirmation of the initial
request to inhibit spamming (i.e., to avoid someone other than omitted and the
member requested glName is not
             supported by the member be added to GLA, the list). The GLA MUST return a response to the
confirmation message (3 in Figure 4) indicates whether the member really
requested addition to
             indicating GLFailInfo.errorCode.invalidGLName.

         2 - If the GL. The format for these messages indicated by
1b, 2, glName and 3 in Figure 4 glIdentifier are beyond the scope of this document.

The GMA MAY support generating present and do not
             match a gkaRequest content-type to request
members be deleted. If GL stored on the GMA supports generating GLA, the gkaRequest
content-type, it GLA MUST be submitted to the KMA (5 in Figure 5) with the
gkaAction.addGLMembers CHOICE. The format for return a
             response indicating
             GLFailInfo.errorCode.invalidGLNameGLIdentifierCombination.

Turner                                                              48
         3 - If the addGLMembers CHOICE glIdentifier is
as follows

  - omitted and the glName MUST be included to indicate is supported
             by the GLA or if the name of glIdentifier/glName combination is
             supported by the GL.

  - glIdentifier GLA, the GLA MUST be included to indicate ensure the GL the member should
be removed from. is
             on the GL.

           a - glMembers MUST be included to indicate If one of the member(s) names in the certificate used to be deleted.
The member(s) name(s) sign the
               GLKCompromise is included in GLMember.name. The deliveryMethod
MUST be omitted. The member's certificates and crls MUST also be
omitted.

  - glOwner.name MUST be omitted.

  - effectiveDate not present on the GL, the GLA MUST be omitted.
               return a response indicating
               GLFailInfo.errorCode.noSpam.

           b - distributionDate MUST be omitted.

Upon receipt If one of the gkaRequest content-type, names in the KMA verifies certificate used to sign the
gkaRequest content-type and returns
               GLKCompromise is present on the GL, the GLA MUST:

             1 _ Generate a gkaResponse (6 PKIData.cmsSequence for all GLOs (2 in
                 Figure 5). KMA
MUST return a gkaResponse to 9) containing the GMA indicating success original GLKCompromise
                 message and a PKIResponse.GLSuccessInfo indicating the
glIdentifier
                 glName, new glIdentifier, and an action.actionCode of
                 rekeyedGL.

             2 _ Generate a GLKey message as described in paragraph
                 5.1.2 to rekey the GL the member was deleted from.

GL Policy (3 in Figure 9)

4.8 Request KEK Refresh

   The will determine whether the GL is to be rekeyed.

3.1.1.7 Rekey Group

Situations arise where times when the GL needs members have misplaced their shared
   KEK.  In this the shared KEK is not compromised and a new key (i.e., group rekey). An
out rekey of bands means, automatic rekeys by the KMA, or
   entire GL is not necessary. The GL members use the mechanisms
defined below MAY GLKRefresh
   message to request that the shared KEK(s) be used redistributed to initiate a group rekey. Only them.
   Figure 10 depicts the protocol interactions for GL Owner
or KMA are allowed to initiate a group rekey.

                 +----------+ 4{3}               6{5b} Key Refresh.

                                        2   +----------+ 5a
                 | GL Owner | <---+
                                  +-------> | Member 1 | <--+
                 +----------+     |
                                  |         +----------+    |
                             1    |          |                         |
  +-----+ 2{1}  3,5b
                      +-----+ <----+   1 |   6{5b}     2   +----------+ 5a |
  | KMA | <-------->
                      | GMA GLA | ----------------+-------> <---+-------> |   ...    | <--+
  +-----+
                      +-----+     |         +----------+
                                  |
     |                                       |                         |
     |                                       |   6{5b}     2   +----------+ 5a |
     |
                                  +-------> | Member n | <--+
     |
                                            +----------+    |
     +-----------------------------------------------------------------+

                         Figure 6 10 - GL KEK Refresh

   The process for GLKRefresh is as follows:

     1 - Group Rekey The GL Owner MAY generate member sends a gkaRequest content-type and submitted it
         SignedData.PKIData.controlSequence.GLKRefresh request to the GMA
         GLA (1 in Figure 6) with the gkaAction.rekeyGL CHOICE. 10). The format
for the rekeyGL CHOICE is as follows:

  - glName MUST be included to indicate the name of the GL.

  - glIdentifier MUST be included to indicate the GK that should be
rekeyed.

  - glMembers GL member MUST be omitted. include glName and
         MAY include glIdentifier.

Turner                                                              49
       a - glOwner.name MUST be included The GL member MAY optionally apply confidentiality to indicate the Owner of the GL. It
MUST match the name one of the certificates used to sign this gkaRequest
and match one of
           request by encapsulating the names SignedData.PKIData in the certificates used to sign the
gkaRequest that created the GL. an
           EnvelopedData (see paragraph 3.2.1.2).

       b - effectiveDate The GL member MAY be included to indicate also optionally apply another SignedData
           over the dates EnvelopedData (see paragraph 3.2.1.2).

     2 _ Upon receipt of the GL Owner
wishes GLKRefresh request, the new group key to become effective. If this field is omitted GLA verifies the GMA assumes
         GL member's signature(s). If an additional SignedData and/or
         EnvelopedData encapsulates the gkNotBefore date request (see paragraph 3.1.2) is the GMA's
current date.

  - distributionDate MAY be included to indicate 3.2.1.2
         or 3.2.2), the date GLA MUST verify the GL Owner
wishes outer signature and/or
         decrypt the key outer layer prior to be distributed. verifying the signature on
         the inner most SignedData.

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

       b - If the group key should be distributed immediately. This
date MAY overlap with signature(s) does(do) verify, the existing effectiveDate to ensure
prepositioning GLA MUST make sure
           the new group key before GL is supported by checking either that the old group key becomes
invalid.

The GMA then forwards glName is
           supported (in the gkaRequest content-type to case the KMA (2{1} in
Figure 3). An additional id-signedData glIdentifier is omitted) or some other that
           the combination of id-
signedData glName and glIdentifier matches a glName
           and glIdentifier combination stored on the GLA.

         1 - If the glIdentifier is omitted and id-envelopedData MAY protect the forwarded content-type.

Upon receipt of the gkaRequest content-type, glName is not
             supported by the KMA verifies GLA, the
gkaRequest content-type and returns GLA MUST return a gkaResponse (3 in Figure 3). response
             indicating GLFailInfo.errorCode.invalidGLName.

         2 - If the glName and glIdentifier are present and do not
             match a GL can be rekeyed as requested, stored on the KMA GLA, the GLA MUST return a gkaResponse to
the GMA
             response indicating success and
             GLFailInfo.errorCode.invalidGLNameGLIdentifierCombination.

         3 - If the glIdentifier of is omitted and the new group key. If glName is supported
             by the group key can not be rekeyed as requested GLA or if the KMA returns a
gkaResponse to glIdentifier/glName combination is
             supported by the GMA indicating failure along with an errorCode.

The GMA then forwards GLA, the gkaResponse content-type to GLA MUST ensure the GL Owner (4{3}
in Figure 3). An additional id-signedData or some other combination of
id-signedData and id-envelopedData MAY protect member is
             on the forwarded conent-
type.

The KMA also generates GL.

           a - If the group rekey MUST distribute glMemberName is not present on the new group
through GL, the mechanism described in paragraph 3.3.

3.2 Group Key Distribution

The KMA GLA
               MUST support the initial distribution of the group key. It MAY
perform this distribution via an out of bands means, a repository, return a
mail message, or some other means. The gkDistribution content-type is
defined to support electronic means of distributing the group key. response indicating
               GLFailInfo.errorCode.noSpam.

           b - If the gkDistribution method glMemberName is used, it present on the GL, the GLA MUST be protected
               return a GLKey message (2 in id-
envelopedData [CMS]. The gkDistribution content-type MUST Figure 10) as described in
               paragraph 5.1.3.

4.9 GLA Query Request and Response

   There will be protected
on certain times when a per-recipient basis using GLO is having trouble setting up
   a GLO because they do not know the ktri RecipientInfo CHOICE. algorithm(s) or distribution
   method(s) the GLA supports. The kari
RecipientInfo choice MAY be used GLAQueryRequest and GLAQueryResponse
   message have been defined to protect support the message GLO determining this

Turner                                                              50
   information.  Figure 11 depicts the protocol interactions for members. A
further id-signedData MAY also be applied.
   GLAQueryRequest and GLAQueryResponse.

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

                Figure 11 - GLA Query Request & Response

   The KMA MAY send the
gkDistribution content-type either: process for GLAQueryRequest and GLAQueryResponse is as follows:

     1 - Directly The GLO sends a
         SignedData.PKIData.controlSequence.GLAQueryRequest request to each of
         the members (5a GLA (1 in Figure 6).

Note: 11). The following option requires that GLO indicates whether they are
         interested in determining what algorithms the KMA be allowed to submit to GLA supports or
         what distributionMethods the GL. GLA support or both.

       a - Through the GMA (6b an 6{5b} in Figure 6). If this option is used,
the KMA The GLO MAY optionally apply an additional id-envelopedData and other layers (6 in
Figure 2) confidentiality to protect the enveloped gkDistribution content-type for the
GMA. The GMA then distributes the inner most id-envelopedData to request
           by encapsulating the
list based. SignedData.PKIData in an EnvelopedData
           (see paragraph 3.2.1.2).

       b - The GMA GLO MAY also optionally apply a signature to the distributed id-
envelopedData.

The following object identifier identifies another SignedData over
           the gksDistribution content
type:

id-ct-gkDistribution OBJECT IDENTIFIER ::= { TBD }

The gkDistribution content type MUST have ASN.1 type GKDistribution:

GKDistribution :: = SEQUENCE {
  version       GKDistributionVersion,
  glIdentifier  OCTET STRING,
  gk            OCTET STRING,
  gkNotBefore   GeneralizedTime,
  gkNotAfter    GeneralizedTime }

[ST - I think we need to put in some kind EnvelopedData (see paragraph 3.2.1.2).

     2 _ Upon receipt of information about the
algorithm the key must be used for.]

GKDistributionVersion ::= INTEGER  { v0(0) }

The fields in GKSDistribution have GLQueryRequest, the following meaning: GLA determines if it
         accepts GLAQueryRequests.

       a - version is If the syntax version number.  It GLA does not accept GLAQueryRequests, the GLA MUST be 0.
           return a response indicating GLFailInfo.unspecified.

       b - glIdentifier is If the GL identifier. The GL identifier identifies GLA does accept GLAQueryReuests, the
specific GL on GLA MUST verify
           the GMA (the GMA may support multiple GLs). Members use GLO's signature(s). If an additional SignedData and/or
           EnvelopedData encapsulates the glIdentifier to choose request (see paragraph
           3.2.1.2 or 3.2.2), the key to needed to GLA MUST verify the outer signature
           and/or decrypt an envelopedData
with the RecipientInfo.kekri.kekid.keyIdentifer. Two common methods for
generating key identifiers from outer layer prior to verifying the group key are:

      (1) The keyIdentifier is composed of
           signature on the 160-bit SHA-1 hash of inner most SignedData.

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

         2 - If the signature(s) does(do) verify, the GLA MUST return a
             GLAQueryResponse (2 in Figure 11) indicating the BIT STRING gk (excluding
             supportedAlgorithms, the tag,
      length, and number of unused bits).

      (2) The keyIdentifier is composed of distributionMethod, or both.

           a four bit type field with - The GLA MUST apply confidentiality to the value 0100 followed response by
               encapsulating the least significant 60 bits of SignedData.PKIResponse in an
               EnvelopedData if the
      SHA-1 hash of request was encapsulated in an
               EnvelopedData (see paragraph 3.2.1.2).

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

Turner                                                              51
     3 - Upon receipt of the BIT STRING gk.

  - gk is GLAQueryResponse, the group key.

  - gkNotBefore indicates GLO verifies the date at which
         GLA's signature(s). If an additional SignedData and/or
         EnvelopedData encapsulates the key is considered valid.

  - gkNotAfter indicates response (see paragraph 3.2.1.2
         or 3.2.2), the date at which GLO MUST verify the key is considered
invalid.

Members must support processing outer signature and/or
         decrypt the id-envelopedData according outer layer prior to [CMS].

3.3 Group Rekey Distribution

To support group rekey messages, three mechanisms are defined: verifying the signature on
         the inner most SignedData.

       a - Use If the mechanism described in paragraph 3.1.3 (1a(5a in Figure 5)6)
to redistribute signature(s) does(do) not verify, the key (i.e., generate GLO MUST return
           a per-recipient token using response indicating CMCFailInfo.badMessageCheck.

       b - If the
ktri or kari RecipientInfoin signatures do verify and the id-envelopedData encapsulating response was
           GLAQueryResponse, the
gkDistribution content-type). This GLO may entail significant processing
compared with use the other options below.

Note: information contained
           therein to attempt to setup a GL or modify an existing GL.

5 Distribution Message

   The following two options require that GLA uses the KMA be allowed GLKey message to
submit the GMA.

  - Generate id-encryptedData with the ktri orRecipientInfo choice kari
RecipientInfo choicewith the associated GMA(s) as the recipient(s)
(1b(5b in Figure 5)6) encapsulating distribute new, shared KEK(s)
   after receiving GLAddMembers, GLDeleteMembers (for closed and
   managed GLs), GLRekey, GLKCompromise, or GLKRefresh requests and
   returning a id-signedData (signed by the KMA)
which in turn encapsualtes an id-envelopedData with GLSucessInfo response for the kekri
RecipientInfo choice (includes respective request. Figure
   12 depicts the gkDistribution content-type). protocol interactions to send out GLKey messages. The GMA
then strips off the two outer layers andthen sends
   procedures defined in this paragraph MUST be implemented.

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

                   Figure 12 - GL Key Distribution

   If the inner most id-
envelopedData GL was setup with GLKeyAttributes.recipientsMutuallyAware 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. The GMA identifies

   When the GL to which GLKey message is generated as a result of a:
     - GLAddMembers request,
     - GLKComrpomise indicate,
     - GLKRefresh request,
     - GLDeleteMembers request with the
gkDistribution content-type should be submitted the GL's glAdministration set
       to
bytheKEKIdentifier.keyIdentifier. The GMA(s) MAY apply a new
encapsulating id-signedData.  id-signedData. managed or closed,
     - GLKRekey request with generationCounter set to zero (0)
   The KMA MAY GLA MUST use either the kari
RecipientInfo (see paragraph 12.3.2 of CMS [2])
   or ktri (see paragraph 12.3.1 of CMS [2]) choice in
   GLKey.glkWrapped.RecipientInfo to encapsulate the id-signedData (signed by ensure only the
KMA) which in turn encapsulates an id-envelopedData with intended

Turner                                                              52
   recipients receive the kekru
RecipientInfo choice (includes shared KEK. The GLA MUST support the gkDistribution content-type).

  - Generate an id-envelopedData (includes
   RecipientInfo.kari choice.

   When the gkDistribution content-
type) GLKey message is generated as a result of a GLRekey request
   with generationCounter greater than zero (0) or when the kekri RecipientInfo choice for the GL and submit it to GLA
   controls rekeys, the GMA. The id-envelopedData GLA MAY have other layers (e.g., an id-
signedData) applied use the kari, ktri, or kekri (see
   paragraph 12.3.3 of CMS [2]) in GLKey.glkWrapped.RecipientInfo to it.
   ensure only the intended recipients receive the shared KEK. The GMA identifies GLA
   MUST support the GL to which RecipientInfo.kari choice.

5.1 Distribution Process

   When a GLKey message is generated the
gkDistributionthen distributes this content-type should be submitted process is as follows:

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

         **Need to be more detailed on how the GL. values are derived as it
           depends on why and when the GLKey message is generated**

       a - The GMA GLA MAY optionally apply additional layers (e.g., an id-signedData) another confidentiality layer
           to the id-
envelopedData.

In all cases, message by encapsulating the KMA MUST assign a new glIdentifier, use a new group
key SignedData.PKIData in gk, and a new gkNotBefore and gkNotAfter dates.
           another EnvelopedData (see paragraph 3.2.1.2).

       b - The old
gkNotAfter and new gkNotBefore GLA MAY also optionally apply another SignedData over
           the EnvelopedData.SignedData.PKIData (see paragraph
           3.2.1.2).

     2 - Upon receipt of the message, the GL members MUST verify the
         signature over the inner most SignedData.PKIData. If an
         additional SignedData and/or EnvelopedData encapsulates the
         message (see paragraph 3.2.1.2 or 3.2.2), the GL Member MUST overlap by some configurable time,
T. T allows for
         verify the time required to distribute outer signature and/or decrypt the new group key outer layer
         prior to
each of verifying the signature on the
         SignedData.PKIData.controlSequence.GLKey.

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

       b - If T is less than 0, then the signature(s) does(do) verify, the GL members may be
unable to use member process
           the group key to encrypt messages.

[The above case is only for entirely new keys to be distributed. Need RecipientInfos according to
add something CMS [2]. Once unwrapped the
           GL member should store the shared KEK in here about how to indicate that a new key, which is
derived from safe place. When
           stored, the old key, glName, glIdentifier, and shared KEK should be used.]

4
           associated.

6 Key Wrapping

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

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

5

7 Algorithms

   Triple-DES is mandatory other are optional.

6.

8 Transport

   SMTP must be supported.

9 Using the Group Key

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

7.

10 Schema Requirements

   [I think we need to specify some MAYs for support of object classes,
   etc. to support location of the GL and GL Owner GLO in a repository. There
   are really two choices for the GL mhsDistributionList from RFC 1274
   and addresslist from an Internet-Draft in the LDAPEXT WG. The only
   reason I can think of not using the one from RFC 1274 is that a MUST
   CONTAIN is mhsORAddress and we're should support SMTP. addressList
   (in the ID) doesn't have mhsORAddress as a must contain. The Owner
   in the both object classes though has the syntax directoryName. We
   might have to roll attribute for the Owner because I think it should
   probably have the GeneralName syntax instead of just directoryName.]

   [We can also define attributes that can be used to store the group
   key encrypted for an individual group member and for the encrypted
   object. Does anyone think this is useful/needed?]

8. Acknowledgements

Thanks

11 Security Considerations

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

   Need to Russ Housley for providing much rekey closed and managed GLs if a member is deleted.

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

   Need to make sure you don't make the key size too small and review
required duration
   long because people will have more time to write this draft.

9. attack the key.

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

Turner                                                              54

12 References

[CMS] R.

   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.

[ESS] P. Hoffman, "Enhanced Security Services

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

   4  Bradner, S., "Key words for S/MIME," use in RFCs to Indicate Requirement
      Levels", BCP 14, RFC 2534,
June 1999.

[PROFILE] 2119, March 1997.

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

10. Security Considerations

TBSL

[ Need

13 Acknowledgements

   Thanks to talk about the consequences Russ Housley and Jim Schaad for providing much of a compromised group KEK. ]

11. Patents

I don't hold any (on the
   background and review required to write this or any other topic) does anyone know of any?

12. Editor's Address draft.

14 Author's Addresses

   Sean Turner
   IECA, Inc.
   9010 Edgepark Road
   Vienna, VA 22182
   Phone: (703)
628-3180 E-Mail: +1.703.628.3180
   Email: turners@ieca.com

Annex A - ASN.1 Module

TBSL

   Expires January 14, 2001

Turner                                                              55