tech-invite   World Map
3GPP     Specs     Glossaries     UICC       IETF     RFCs     Groups     SIP     ABNFs       T+       Search     Home

RFC 5275

 
 
 

CMS Symmetric Key Management and Distribution

Part 2 of 5, p. 7 to 31
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 7 
3.  Protocol Interactions

   There are existing mechanisms (e.g., listserv and majordomo) to
   manage GLs; however, this document does not address securing these
   mechanisms, as they are not standardized.  Instead, it defines
   protocol interactions, as depicted in Figure 2, used by the GL
   members, GLA, and GLO(s) to manage GLs and distribute shared KEKs.
   The interactions have been divided into administration messages and
   distribution messages.  The administrative messages are the request
   and response messages needed to set up the GL, delete the GL, add
   members to the GL, delete members of the GL, request a group rekey,
   add owners to the GL, remove owners of the GL, indicate a group key
   compromise, refresh a group key, interrogate the GLA, and update
   members' and owners' public key certificates.  The distribution

Top      Up      ToC       Page 8 
   messages are the messages that distribute the shared KEKs.  The
   following sections describe the ASN.1 for both the administration and
   distribution messages.  Section 4 describes how to use the
   administration messages, and Section 5 describes how to use the
   distribution messages.

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

        Figure 2 - Protocol Interactions

3.1.  Control Attributes

   To avoid creating an entirely new protocol, the Certificate
   Management over CMS (CMC) protocol was chosen as the foundation of
   this protocol.  The main reason for the choice was the layering
   aspect provided by CMC where one or more control attributes are
   included in message, protected with CMS, to request or respond to a
   desired action.  The CMC PKIData structure is used for requests, and
   the CMC PKIResponse structure is used for responses.  The content-
   types PKIData and PKIResponse are then encapsulated in CMS's
   SignedData or EnvelopedData, or a combination of the two (see Section
   3.2).  The following are the control attributes defined in this
   document:

Top      Up      ToC       Page 9 
         Control
        Attribute          OID          Syntax
   -------------------  ----------- -----------------
    glUseKEK            id-skd 1    GLUseKEK
    glDelete            id-skd 2    GeneralName
    glAddMember         id-skd 3    GLAddMember
    glDeleteMember      id-skd 4    GLDeleteMember
    glRekey             id-skd 5    GLRekey
    glAddOwner          id-skd 6    GLOwnerAdministration
    glRemoveOwner       id-skd 7    GLOwnerAdministration
    glkCompromise       id-skd 8    GeneralName
    glkRefresh          id-skd 9    GLKRefresh
    glaQueryRequest     id-skd 11   GLAQueryRequest
    glaQueryResponse    id-skd 12   GLAQueryResponse
    glProvideCert       id-skd 13   GLManageCert
    glUpdateCert        id-skd 14   GLManageCert
    glKey               id-skd 15   GLKey

   In the following conformance tables, the column headings have the
   following meanings: O for originate, R for receive, and F for
   forward.  There are three types of implementations: GLOs, GLAs, and
   GL members.  The GLO is an optional component, hence all GLO O and
   GLO R messages are optional, and GLA F messages are optional.  The
   first table includes messages that conformant implementations MUST
   support.  The second table includes messages that MAY be implemented.
   The second table should be interpreted as follows: if the control
   attribute is implemented by a component, then it must be implemented
   as indicated.  For example, if a GLA is implemented that supports the
   glAddMember control attribute, then it MUST support receiving the
   glAddMember message.  Note that "-" means not applicable.

                             Required
          Implementation Requirement       |  Control
     GLO   |        GLA        | GL Member | Attribute
    O  R   |  O      R      F  |  O    R   |
   ------- | ----------------- | --------- | ----------
   MAY  -  | MUST    -     MAY |  -   MUST | glProvideCert
   MAY MAY |  -     MUST   MAY | MUST  -   | glUpdateCert
    -   -  | MUST    -      -  |  -   MUST | glKey

Top      Up      ToC       Page 10 
                             Optional
           Implementation Requirement      |  Control
     GLO   |        GLA        | GL Member | Attribute
    O   R  |  O      R      F  |  O    R   |
   ------- | ----------------- | --------- | ----------
   MAY  -  |  -     MAY     -  |  -    -   | glUseKEK
   MAY  -  |  -     MAY     -  |  -    -   | glDelete
   MAY MAY |  -     MUST   MAY | MUST  -   | glAddMember
   MAY MAY |  -     MUST   MAY | MUST  -   | glDeleteMember
   MAY  -  |  -     MAY     -  |  -    -   | glRekey
   MAY  -  |  -     MAY     -  |  -    -   | glAddOwner
   MAY  -  |  -     MAY     -  |  -    -   | glRemoveOwner
   MAY MAY |  -     MUST   MAY | MUST  -   | glkCompromise
   MAY  -  |  -     MUST    -  | MUST  -   | glkRefresh
   MAY  -  |  -     SHOULD  -  | MAY   -   | glaQueryRequest
    -  MAY | SHOULD  -      -  |  -   MAY  | glaQueryResponse

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

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

3.1.1.  GL Use KEK

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

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

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

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

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

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

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

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

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

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

   The fields in GLUseKEK have the following meaning:

     - glInfo indicates the name of the GL in glName and the address of
       the GL in glAddress.  The glName and glAddress can be the same,
       but this is not always the case.  Both the name and address MUST
       be unique for a given GLA.

     - glOwnerInfo indicates:

        -- glOwnerName indicates the name of the owner of the GL.  One
           of the names in glOwnerName MUST match one of the names in
           the certificate (either the subject distinguished name or one
           of the subject alternative names) used to sign this
           SignedData.PKIData creating the GL (i.e., the immediate
           signer).

        -- glOwnerAddress indicates the GL owner's address.

Top      Up      ToC       Page 12 
        -- certificates MAY be included.  It contains the following
           three fields:

            --- certificates.pKC includes the encryption certificate for
                the GLO.  It will be used to encrypt responses for the
                GLO.

            --- certificates.aC MAY be included to convey any attribute
                certificate (see [ACPROF]) associated with the
                encryption certificate of the GLO included in
                certificates.pKC.

            --- certificates.certPath MAY also be included to convey
                certificates that might aid the recipient in
                constructing valid certification paths for the
                certificate provided in certificates.pKC and the
                attribute certificates provided in certificates.aC.
                Theses certificates are optional because they might
                already be included elsewhere in the message (e.g., in
                the outer CMS layer).

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

            --- Unmanaged - When the GLO sets glAdministration to
                unmanaged, it is allowing prospective members to request
                addition and deletion from the GL without GLO
                intervention.

            --- Managed - When the GLO sets glAdministration to managed,
                it is allowing prospective members to request addition
                and deletion from the GL, but the request is redirected
                by the GLA to GLO for review.  The GLO makes the
                determination as to whether to honor the request.

            --- Closed - When the GLO sets glAdministration to closed,
                it is not allowing prospective members to request
                addition or deletion from the GL.  The GLA will only
                accept glAddMember and glDeleteMember requests from the
                GLO.

        -- glKeyAttributes indicates the attributes the GLO wants the
           GLA to assign to the shared KEK.  If this field is omitted,
           GL rekeys will be controlled by the GLA, the recipients are
           allowed to know about one another, the algorithm will be
           AES-128 (see Section 7), the shared KEK will be valid for a
           calendar month (i.e., first of the month until the last day

Top      Up      ToC       Page 13 
           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.

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

                Note: This supports lists where one member does not know
                the identities of the other members.  For example, a
                list is configured granting submit permissions to only
                one member.  All other members are 'listening'.  The
                security policy of the list does not allow the members
                to know who else is on the list.  If a glKey is
                constructed for all of the GL members, information about
                each of the members may be derived from the information
                in RecipientInfos.

                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 in the UTC Zulu time zone.  For example,
                if the duration is zero (0), if the GL shared KEK is
                requested on July 24, the first key will be valid until
                the end of July and the next key will be valid for the
                entire month of August.  If the value is not zero (0),
                the shared KEK will be valid for the number of days
                indicated by the value.  For example, if the value of
                duration is seven (7) and the shared KEK is requested on
                Monday but not generated until Tuesday (13 May 2008);
                the shared KEKs will be valid from Tuesday (13 May 2008)
                to Tuesday (20 May 2008).  The exact time of the day is
                determined when the key is generated.

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

            --- requestedAlgorithm indicates the algorithm and any
                parameters the GLO wants the GLA to use with the shared
                KEK.  The parameters are conveyed via the
                SMIMECapabilities attribute (see [MSG]).  See Section 6
                for more on algorithms.

3.1.2.  Delete GL

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

   DeleteGL ::= GeneralName

3.1.3.  Add GL Member

   GLOs use the glAddMember to request addition of new members, and
   prospective GL members use the glAddMember to request their own
   addition to the GL.  The glAddMember message MUST be signed by either
   the GLO or the prospective GL member.  The glAddMember control
   attribute has the syntax GLAddMember:

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

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

   The fields in GLAddMembers have the following meaning:

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

Top      Up      ToC       Page 15 
     - glMember indicates the particulars for the GL member.  Both of
       the following fields must be unique for a given GL:

        -- glMemberName indicates the name of the GL member.

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

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

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

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

            --- certificates.aC MAY be included to convey any attribute
                certificate (see [ACPROF]) associated with the member's
                encryption certificate.

            --- certificates.certPath MAY also be included to convey
                certificates that might aid the recipient in
                constructing valid certification paths for the
                certificate provided in certificates.pKC and the
                attribute certificates provided in certificates.aC.
                These certificates are optional because they might
                already be included elsewhere in the message (e.g., in
                the outer CMS layer).

3.1.4.  Delete GL Member

   GLOs use the glDeleteMember to request deletion of GL members, and GL
   members use the glDeleteMember to request their own removal from the
   GL.  The glDeleteMember message MUST be signed by either the GLO or
   the GL member.  The glDeleteMember control attribute has the syntax
   GLDeleteMember:

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

Top      Up      ToC       Page 16 
   The fields in GLDeleteMembers have the following meaning:

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

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

3.1.5.  Rekey GL

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

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

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

   The fields in GLRekey have the following meaning:

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

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

     - glNewKeyAttributes indicates whether the rekey of the GLO is
       controlled by the GLA or GL, what algorithm and parameters the
       GLO wishes to use, the duration of the key, and how many keys
       will be issued.  The field is only included if there is a change
       from the previously registered glKeyAttributes.

     - glRekeyAllGLKeys indicates whether the GLO wants all of the
       outstanding GL's shared KEKs rekeyed.  If it is set to TRUE then
       all outstanding KEKs MUST be issued.  If it is set to FALSE then
       all outstanding KEKs need not be reissued.

Top      Up      ToC       Page 17 
3.1.6.  Add GL Owner

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

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

   The fields in GLAddOwners have the following meaning:

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

     - glOwnerInfo indicates the name, address, and certificates of the
       new GLO.  As this message includes names of new GLOs, the
       certificates.pKC MUST be included, and it MUST include the
       encryption certificate of the new GLO.

3.1.7.  Remove GL Owner

   GLOs use the glRemoveOwner to request that a GLO be disassociated
   with the GL.  The glRemoveOwner message MUST be signed by a
   registered GLO.  The glRemoveOwner control attribute has the syntax
   GLOwnerAdministration:

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

   The fields in GLRemoveOwners have the following meaning:

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

     - glOwnerInfo indicates the name and address of the GLO to be
       removed.  The certificates field SHOULD be omitted, as it will be
       ignored.

3.1.8.  GL Key Compromise

   GL members and GLOs use glkCompromise to indicate that the shared KEK
   possessed has been compromised.  The glKeyCompromise control
   attribute has the syntax GeneralName.  This message is always
   redirected by the GLA to the GLO for further action.  The
   glkCompromise MAY be included in an EnvelopedData generated with the

Top      Up      ToC       Page 18 
   compromised shared KEK.  The name of the GL to which the compromised
   key is associated is placed in GeneralName:

   GLKCompromise ::= GeneralName

3.1.9.  GL Key Refresh

   GL members use the glkRefresh to request that the shared KEK be
   redistributed to them.  The glkRefresh control attribute has the
   syntax GLKRefresh.

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

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

   The fields in GLKRefresh have the following meaning:

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

     - dates indicates a date range for keys the GL member wants.  The
       start field indicates the first date the GL member wants and the
       end field indicates the last date.  The end date MAY be omitted
       to indicate the GL member wants all keys from the specified start
       date to the current date.  Note that a procedural mechanism is
       needed to restrict users from accessing messages that they are
       not allowed to access.

3.1.10.  GLA Query Request and Response

   There are situations where GLOs and GL members may need to determine
   some information from the GLA about the GL.  GLOs and GL members use
   the glaQueryRequest, defined in Section 3.1.10.1, to request
   information and GLAs use the glaQueryResponse, defined in Section
   3.1.10.2, to return the requested information.  Section 3.1.10.3
   includes one request and response type and value; others may be
   defined in additional documents.

3.1.10.1.  GLA Query Request

   GLOs and GL members use the glaQueryRequest to ascertain information
   about the GLA.  The glaQueryRequest control attribute has the syntax
   GLAQueryRequest:

Top      Up      ToC       Page 19 
   GLAQueryRequest ::= SEQUENCE {
     glaRequestType   OBJECT IDENTIFIER,
     glaRequestValue  ANY DEFINED BY glaRequestType }

3.1.10.2.  GLA Query Response

   GLAs return the glaQueryResponse after receiving a GLAQueryRequest.
   The glaQueryResponse MUST be signed by a GLA.  The glaQueryResponse
   control attribute has the syntax GLAQueryResponse:

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

3.1.10.3.  Request and Response Types

   Requests and responses are registered as a pair under the following
   object identifier arc:

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

   This document defines one request/response pair for GL members and
   GLOs to query the GLA for the list of algorithm it supports.  The
   following Object Identifier (OID) is included in the glaQueryType
   field:

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

   SKDAlgRequest ::= NULL

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

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

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

3.1.11.  Provide Cert

   GLAs and GLOs use the glProvideCert to request that a GL member
   provide an updated or new encryption certificate.  The glProvideCert
   message MUST be signed by either GLA or GLO.  If the GL member's PKC
   has been revoked, the GLO or GLA MUST NOT use it to generate the
   EnvelopedData that encapsulates the glProvideCert request.  The
   glProvideCert control attribute has the syntax GLManageCert:

Top      Up      ToC       Page 20 
   GLManageCert ::= SEQUENCE {
     glName    GeneralName,
     glMember  GLMember }

   The fields in GLManageCert have the following meaning:

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

     - glMember indicates particulars for the GL member:

        -- glMemberName indicates the GL member's name.

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

        -- certificates SHOULD be omitted.

3.1.12 Update Cert

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

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

   The fields in GLManageCert have the following meaning:

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

     - glMember indicates the particulars for the GL member:

        -- glMemberName indicates the GL member's name.

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

        -- certificates MAY be omitted if the GLManageCert message is
           sent to request the GL member's certificate; otherwise, it
           MUST be included.  It includes the following three fields:

Top      Up      ToC       Page 21 
            --- certificates.pKC includes the member's encryption
                certificate that will be used to encrypt the shared KEK
                for that member.

            --- certificates.aC MAY be included to convey one or more
                attribute certificates associated with the member's
                encryption certificate.

            --- certificates.certPath MAY also be included to convey
                certificates that might aid the recipient in
                constructing valid certification paths for the
                certificate provided in certificates.pKC and the
                attribute certificates provided in certificates.aC.
                These certificates are optional because they might
                already be included elsewhere in the message (e.g., in
                the outer CMS layer).

3.1.13.  GL Key

   The GLA uses the glKey to distribute the shared KEK.  The glKey
   message MUST be signed by the GLA.  The glKey control attribute has
   the syntax GLKey:

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

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

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

   The fields in GLKey have the following meaning:

     - glName is the name of the GL.

     - glIdentifier is the key identifier of the shared KEK.  See
       Section 6.2.3 of [CMS] for a description of the subfields.

Top      Up      ToC       Page 22 
     - glkWrapped is the wrapped shared KEK for the GL for a particular
       duration.  The RecipientInfos MUST be generated as specified in
       Section 6.2 of [CMS].  The ktri RecipientInfo choice MUST be
       supported.  The key in the EncryptedKey field (i.e., the
       distributed shared KEK) MUST be generated according to the
       section concerning random number generation in the security
       considerations of [CMS].

     - glkAlgorithm identifies the algorithm with which the shared KEK
       is used.  Since no encrypted data content is being conveyed at
       this point, the parameters encoded with the algorithm should be
       the structure defined for smimeCapabilities rather than encrypted
       content.

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

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

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

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

     - The GLA MUST generate the requested number of glKey messages.
       The value in glUseKEK.glKeyAttributes.generationCounter indicates
       the number of glKey messages requested.

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

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

     - The GLA MUST generate the requested number of glKey messages.
       The value in glUseKEK.glKeyAttributes.generationCounter indicates
       the number of glKey messages requested.

Top      Up      ToC       Page 23 
     - The GLA MUST generate one glKey message for each outstanding
       shared KEKs for the GL when glRekeyAllGLKeys is set to TRUE.

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

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

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

3.2.  Use of CMC, CMS, and PKIX

   The following sections outline the use of CMC, CMS, and the PKIX
   certificate and CRL profile.

3.2.1.  Protection Layers

   The following sections outline the protection required for the
   control attributes defined in this document.

   Note: There are multiple ways to encapsulate SignedData and
   EnvelopedData.  The first is to use a MIME wrapper around each
   ContentInfo, as specified in [MSG].  The second is not to use a MIME
   wrapper around each ContentInfo, as specified in Transporting S/MIME
   Objects in X.400 [X400TRANS].

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

Top      Up      ToC       Page 24 
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:

                                  Authentication and Integrity
   Confidentiality Protection     of Confidentiality Protection
   --------------------------     -----------------------------
   EnvelopedData                  SignedData
    SignedData                     EnvelopedData
     PKIData or PKIResponse         SignedData
      controlSequence                PKIData or PKIResponse
                                      controlSequence

   If an incoming message is encrypted, the confidentiality of the
   message MUST be preserved.  All EnvelopedData objects MUST be
   processed as specified in [CMS].  If a SignedData is added over an
   EnvelopedData, a ContentHints attribute SHOULD be added.  See Section
   2.9 of Extended Security Services for S/MIME [ESS].

   If the GLO or GL member applies confidentiality to a request, the
   EnvelopedData MUST include the GLA as a recipient.  If the GLA
   forwards the GL member request to the GLO, then the GLA MUST decrypt
   the EnvelopedData content, strip the confidentiality layer, and apply
   its own confidentiality layer as an EnvelopedData with the GLO as a
   recipient.

3.2.2.  Combining Requests and Responses

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

Top      Up      ToC       Page 25 
       Multiple Requests and Responses
   Request                        Response
   -------                        --------
   SignedData                      SignedData
    PKIData                         PKIResponse
     cmsSequence                     cmsSequence
      SignedData                      SignedData
       PKIData                         PKIResponse
        controlSequence                 controlSequence
         One or more requests            One or more responses
         corresponding to one GL         corresponding to one GL
      SignedData                      SignedData
       PKIData                         PKIResponse
        controlSequence                 controlSequence
         One or more requests            One or more responses
         corresponding to another GL     corresponding to another GL

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

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

Top      Up      ToC       Page 26 
   Certain combinations of requests in one PKIData.controlSequence and
   one PKIResponse.controlSequence are not allowed.  The invalid
   combinations listed here MUST NOT be generated:

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

   To avoid unnecessary errors, certain requests and responses SHOULD be
   processed prior to others.  The following is the priority of message
   processing, if not listed it is an implementation decision as to
   which to process first: glUseKEK before glAddMember, glRekey before
   glAddMember, and glDeleteMember before glRekey.  Note that there is a
   processing priority, but it does not imply an ordering within the
   content.

3.2.3.  GLA Generated Messages

   When the GLA generates a success or fail message, it generates one
   for each request.  SKDFailInfo values of unsupportedDuration,
   unsupportedDeliveryMethod, unsupportedAlgorithm, noGLONameMatch,
   nameAlreadyInUse, alreadyAnOwner, and notAnOwner are not returned to
   GL members.

   If GLKeyAttributes.recipientsNotMutuallyAware is set to TRUE, a
   separate PKIResponse.cMCStatusInfoExt and PKIData.glKey MUST be
   generated for each recipient.  However, it is valid to send one
   message with multiple attributes to the same recipient.

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

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

Top      Up      ToC       Page 27 
   GLA Forwarded Requests
   ----------------------
   SignedData
    PKIData
      cmsSequence
        SignedData
         PKIData
          controlSequence

3.2.4.  CMC Control Attributes and CMS Signed Attributes

   CMC carries control attributes as CMS signed attributes.  These
   attributes are defined in [CMC] and [CMS].  Some of these attributes
   are REQUIRED; others are OPTIONAL.  The required attributes are as
   follows: cMCStatusInfoExt transactionId, senderNonce, recipientNonce,
   queryPending, and signingTime.  Other attributes can also be used;
   however, their use is beyond the scope of this document.  The
   following sections specify requirements in addition to those already
   specified in [CMC] and [CMS].

3.2.4.1.  Using cMCStatusInfoExt

   cMCStatusInfoExt is used by GLAs to indicate to GLOs and GL members
   that a request was unsuccessful.  Two classes of failure codes are
   used within this document.  Errors from the CMCFailInfo list, found
   in Section 5.1.4 of CMC, are encoded as defined in CMC.  Error codes
   defined in this document are encoded using the ExtendedFailInfo field
   of the cmcStatusInfoExt structure.  If the same failure code applies
   to multiple commands, a single cmcStatusInfoExt structure can be used
   with multiple items in cMCStatusInfoExt.bodyList.  The GLA MAY also
   return other pertinent information in statusString.  The SKDFailInfo
   object identifier and value are:

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

   SKDFailInfo ::= INTEGER {
     unspecified           (0),
     closedGL              (1),
     unsupportedDuration   (2),
     noGLACertificate      (3),
     invalidCert           (4),
     unsupportedAlgorithm  (5),
     noGLONameMatch        (6),
     invalidGLName         (7),
     nameAlreadyInUse      (8),
     noSpam                (9),

Top      Up      ToC       Page 28 
   -- obsolete             (10),
     alreadyAMember        (11),
     notAMember            (12),
     alreadyAnOwner        (13),
     notAnOwner            (14) }

   The values have the following meaning:

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

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

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

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

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

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

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

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

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

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

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

Top      Up      ToC       Page 29 
     - notAMember indicates that the prospective GL member to be deleted
       is not presently a GL member.

     - alreadyAnOwner indicates that the prospective GLO is already a
       GLO.

     - notAnOwner indicates that the prospective GLO to be deleted is
       not presently a GLO.

   cMCStatusInfoExt is used by GLAs to indicate to GLOs and GL members
   that a request was successfully completed.  If the request was
   successful, the GLA returns a cMCStatusInfoExt response with
   cMCStatus.success and optionally other pertinent information in
   statusString.

   When the GL is managed and the GLO has reviewed GL member initiated
   glAddMember, glDeleteMember, and glkComrpomise requests, the GLO uses
   cMCStatusInfoExt to indicate the success or failure of the request.
   If the request is allowed, cMCStatus.success is returned and
   statusString is optionally returned to convey additional information.
   If the request is denied, cMCStatus.failed is returned and
   statusString is optionally returned to convey additional information.
   Additionally, the appropriate SKDFailInfo can be included in
   cMCStatusInfoExt.extendedFailInfo.

   cMCStatusInfoExt is used by GLOs, GLAs, and GL members to indicate
   that signature verification failed.  If the signature failed to
   verify over any control attribute except a cMCStatusInfoExt, a
   cMCStatusInfoExt control attribute MUST be returned indicating
   cMCStatus.failed and otherInfo.failInfo.badMessageCheck.  If the
   signature over the outermost PKIData failed, the bodyList value is
   zero (0).  If the signature over any other PKIData failed, the
   bodyList value is the bodyPartId value from the request or response.
   GLOs and GL members who receive cMCStatusInfoExt messages whose
   signatures are invalid SHOULD generate a new request to avoid
   badMessageCheck message loops.

   cMCStatusInfoExt is also used by GLOs and GLAs to indicate that a
   request could not be performed immediately.  If the request could not
   be processed immediately by the GLA or GLO, the cMCStatusInfoExt
   control attribute MUST be returned indicating cMCStatus.pending and
   otherInfo.pendInfo.  When requests are redirected to the GLO for
   approval (for managed lists), the GLA MUST NOT return a
   cMCStatusInfoExt indicating query pending.

Top      Up      ToC       Page 30 
   cMCStatusInfoExt is also used by GLAs to indicate that a
   glaQueryRequest is not supported.  If the glaQueryRequest is not
   supported, the cMCStatusInfoExt control attribute MUST be returned
   indicating cMCStatus.noSupport and statusString is optionally
   returned to convey additional information.

   cMCStatusInfoExt is also used by GL members, GLOs, and GLAs to
   indicate that the signingTime (see Section 3.2.4.3) is not close
   enough to the locally specified time.  If the local time is not close
   enough to the time specified in signingTime, a cMCStatus.failed and
   otherInfo.failInfo.badTime MAY be returned.

3.2.4.2.  Using transactionId

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

3.2.4.3.  Using Nonces and signingTime

   The use of nonces (see Section 5.6 of [CMC]) and an indication of
   when the message was signed (see Section 11.3 of [CMS]) can be used
   to provide application-level replay prevention.

   To protect the GL, all messages MUST include the signingTime
   attribute.  Message originators and recipients can then use the time
   provided in this attribute to determine whether they have previously
   received the message.

   If the originating message includes a senderNonce, the response to
   the message MUST include the received senderNonce value as the
   recipientNonce and a new value as the senderNonce value in the
   response.

   If a GLA aggregates multiple messages together or forwards a message
   to a GLO, the GLA MAY optionally generate a new nonce value and
   include that in the wrapping message.  When the response comes back
   from the GLO, the GLA builds a response to the originator(s) of the
   message(s) and deals with each of the nonce values from the
   originating messages.

Top      Up      ToC       Page 31 
   For these attributes, it is necessary to maintain state information
   on exchanges to compare one result to another.  The time period for
   which this information is maintained is a local policy.

3.2.4.4.  CMC and CMS Attribute Support Requirements

   The following are the implementation requirements for CMC control
   attributes and CMS signed attributes for an implementation to be
   considered conformant to this specification:

          Implementation Requirement     |
      GLO    |      GLA      | GL Member | Attribute
    O    R   |  O    R    F  |  O    R   |
   --------- | ------------- | --------- | ----------
   MUST MUST | MUST MUST  -  | MUST MUST | cMCStatusInfoExt
   MAY  MAY  | MUST MUST  -  | MAY  MAY  | transactionId
   MAY  MAY  | MUST MUST  -  | MAY  MAY  | senderNonce
   MAY  MAY  | MUST MUST  -  | MAY  MAY  | recepientNonce
   MUST MUST | MUST MUST  -  | MUST MUST | SKDFailInfo
   MUST MUST | MUST MUST  -  | MUST MUST | signingTime

3.2.5.  Resubmitted GL Member Messages

   When the GL is managed, the GLA forwards the GL member requests to
   the GLO for GLO approval by creating a new request message containing
   the GL member request(s) as a cmsSequence item.  If the GLO approves
   the request, it can either add a new layer of wrapping and send it
   back to the GLA or create a new message and send it to the GLA.
   (Note in this case there are now 3 layers of PKIData messages with
   appropriate signing layers.)

3.2.6.  PKIX Certificate and CRL Profile

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

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

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

   A certificate per GL would be issued to the GLA.

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


Next RFC Part