tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search

RFC 5275

 
 
 

CMS Symmetric Key Management and Distribution

Part 3 of 5, p. 32 to 57
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 32 
4.  Administrative Messages

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

4.1.  Assign KEK to GL

   Prior to generating a group key, a GL needs to be set up and a shared
   KEK assigned to the GL.  Figure 3 depicts the protocol interactions
   to set up and assign a shared KEK.  Note that error messages are not
   depicted in Figure 3.  Additionally, behavior for the optional
   transactionId, senderNonce, and recipientNonce CMC control attributes
   is not addressed in these procedures.

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

   Figure 3 - Create Group List

   The process is as follows:

   1 - The GLO is the entity responsible for requesting the creation of
       the GL.  The GLO sends a
       SignedData.PKIData.controlSequence.glUseKEK request to the GLA (1
       in Figure 3).  The GLO MUST include glName, glAddress,
       glOwnerName, glOwnerAddress, and glAdministration.  The GLO MAY
       also include their preferences for the shared KEK in
       glKeyAttributes by indicating whether the GLO controls the rekey
       in rekeyControlledByGLO, whether separate glKey messages should
       be sent to each recipient in recipientsNotMutuallyAware, 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 generationCounter.
       The GLO MUST also include the signingTime attribute with this
       request.

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

Top      Up      ToC       Page 33 
     1.b - The GLO can apply confidentiality to the request by
           encapsulating the SignedData.PKIData in an EnvelopedData (see
           Section 3.2.1.2).

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

   2 - Upon receipt of the request, the GLA checks the signingTime and
       verifies the signature on the innermost SignedData.PKIData.  If
       an additional SignedData and/or EnvelopedData encapsulates the
       request (see Sections 3.2.1.2 and 3.2.2), the GLA verifies the
       outer signature(s) and/or decrypts the outer layer(s) prior to
       verifying the signature on the innermost SignedData.

     2.a - If the signingTime attribute value is not within the locally
           accepted time window, the GLA MAY return a response
           indicating cMCStatus.failed and otherInfo.failInfo.badTime
           and a signingTime attribute.

     2.b - Else if signature processing continues and if the signatures
           do not verify, the GLA returns a cMCStatusInfoExt response
           indicating cMCStatus.failed and
           otherInfo.failInfo.badMessageCheck.  Additionally, a
           signingTime attribute is included with the response.

     2.c - Else if the signatures do verify but the GLA does not have a
           valid certificate, the GLA returns a cMCStatusInfoExt with
           cMCStatus.failed and otherInfo.extendedFailInfo.SKDFailInfo
           value of noValidGLACertificate.  Additionally, a signingTime
           attribute is included with the response.  Instead of
           immediately returning the error code, the GLA attempts to get
           a certificate, possibly using [CMC].

     2.d - Else the signatures are valid and the GLA does have a valid
           certificate, the GLA checks that one of the names in the
           certificate used to sign the request matches one of the names
           in glUseKEK.glOwnerInfo.glOwnerName.

       2.d.1 - If the names do not match, the GLA returns a response
               indicating cMCStatusInfoExt with cMCStatus.failed and
               otherInfo.extendedFailInfo.SKDFailInfo value of
               noGLONameMatch.  Additionally, a signingTime attribute is
               included with the response.

Top      Up      ToC       Page 34 
       2.d.2 - Else if the names all match, the GLA checks that the
               glName and glAddress are not already in use.  The GLA
               also checks any glAddMember included within the
               controlSequence with this glUseKEK.  Further processing
               of the glAddMember is covered in Section 4.3.

         2.d.2.a - If the glName is already in use, the GLA returns a
                   response indicating cMCStatusInfoExt with
                   cMCStatus.failed and
                   otherInfo.extendedFailInfo.SKDFailInfo value of
                   nameAlreadyInUse.  Additionally, a signingTime
                   attribute is included with the response.

         2.d.2.b - Else if the requestedAlgorithm is not supported, the
                   GLA returns a response indicating cMCStatusInfoExt
                   with cMCStatus.failed and
                   otherInfo.extendedFailInfo.SKDFailInfo value of
                   unsupportedAlgorithm.  Additionally, a signingTime
                   attribute is included with the response.

         2.d.2.c - Else if the duration cannot be supported, determining
                   this is beyond the scope of this document, the GLA
                   returns a response indicating cMCStatusInfoExt with
                   cMCStatus.failed and
                   otherInfo.extendedFailInfo.SKDFailInfo value of
                   unsupportedDuration.  Additionally, a signingTime
                   attribute is included with the response.

         2.d.2.d - Else if the GL cannot be supported for other reasons,
                   which the GLA does not wish to disclose, the GLA
                   returns a response indicating cMCStatusInfoExt with
                   cMCStatus.failed and
                   otherInfo.extendedFailInfo.SKDFailInfo value of
                   unspecified.  Additionally, a signingTime attribute
                   is included with the response.

         2.d.2.e - Else if the glName is not already in use, the
                   duration can be supported, and the requestedAlgorithm
                   is supported, the GLA MUST return a cMCStatusInfoExt
                   indicating cMCStatus.success and a signingTime
                   attribute. (2 in Figure 3).  The GLA also takes
                   administrative actions, which are beyond the scope of
                   this document, to store the glName, glAddress,
                   glKeyAttributes, glOwnerName, and glOwnerAddress.
                   The GLA also sends a glKey message as described in
                   section 5.

Top      Up      ToC       Page 35 
           2.d.2.e.1 - The GLA can apply confidentiality to the response
                       by encapsulating the SignedData.PKIResponse in an
                       EnvelopedData if the request was encapsulated in
                       an EnvelopedData (see Section 3.2.1.2).

           2.d.2.e.2 - The GLA can also optionally apply another
                       SignedData over the EnvelopedData (see Section
                       3.2.1.2).

   3 - Upon receipt of the cMCStatusInfoExt responses, the GLO checks
       the signingTime and verifies the GLA signature(s).  If an
       additional SignedData and/or EnvelopedData encapsulates the
       response (see Section 3.2.1.2 or 3.2.2), the GLO verifies the
       outer signature and/or decrypts the outer layer prior to
       verifying the signature on the innermost SignedData.

     3.a - If the signingTime attribute value is not within the locally
           accepted time window, the GLO MAY return a response
           indicating cMCStatus.failed and otherInfo.failInfo.badTime
           and a signingTime attribute.

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

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

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

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

         3.b.2.b - Else if the signatures are valid and the response is
                   cMCStatusInfoExt.cMCStatus.failed with any reason,
                   the GLO can reattempt to create the GL using the
                   information provided in the response.  The GLO can
                   also use the glaQueryRequest to determine the
                   algorithms and other characteristics supported by the
                   GLA (see Section 4.9).

Top      Up      ToC       Page 36 
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 deletes the GL.  Figure 4 depicts the protocol
   interactions to delete a GL.  Note that behavior for the optional
   transactionId, senderNonce, and recipientNonce CMC control attributes
   is not addressed in these procedures.

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

      Figure 4 - Delete Group List

   The process is as follows:

   1 - The GLO is responsible for requesting the deletion of the GL.
       The GLO sends a SignedData.PKIData.controlSequence.glDelete
       request to the GLA (1 in Figure 4).  The name of the GL to be
       deleted is included in GeneralName.  The GLO MUST also include
       the signingTime attribute and can also include a transactionId
       and senderNonce attributes.

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

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

   2 - Upon receipt of the request, the GLA checks the signingTime and
       verifies the signature on the innermost SignedData.PKIData.  If
       an additional SignedData and/or EnvelopedData encapsulates the
       request (see Section 3.2.1.2 or 3.2.2), the GLA verifies the
       outer signature and/or decrypts the outer layer prior to
       verifying the signature on the innermost SignedData.

     2.a - If the signingTime attribute value is not within the locally
           accepted time window, the GLA MAY return a response
           indicating cMCStatus.failed and otherInfo.failInfo.badTime
           and a signingTime attribute.

     2.b - Else if signature processing continues and if the signatures
           cannot be verified, the GLA returns a cMCStatusInfoExt
           response indicating cMCStatus.failed and
           otherInfo.failInfo.badMessageCheck.  Additionally, a
           signingTime attribute is included with the response.

Top      Up      ToC       Page 37 
     2.c - Else if the signatures verify, the GLA makes sure the GL is
           supported by checking the name of the GL matches a glName
           stored on the GLA.

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

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

         2.c.2.a - If the names do not match, the GLA returns a response
                   indicating cMCStatusInfoExt with cMCStatus.failed and
                   otherInfo.extendedFailInfo.SKDFailInfo value of
                   noGLONameMatch.  Additionally, a signingTime
                   attribute is included with the response.

         2.c.2.b - Else if the names do match, but the GL cannot be
                   deleted for other reasons, which the GLA does not
                   wish to disclose, the GLA returns a response
                   indicating cMCStatusInfoExt with cMCStatus.failed and
                   otherInfo.extendedFailInfo.SKDFailInfo value of
                   unspecified.  Additionally, a signingTime attribute
                   is included with the response.  Actions beyond the
                   scope of this document must then be taken to delete
                   the GL from the GLA.

         2.c.2.c - Else if the names do match, the GLA returns a
                   cMCStatusInfoExt indicating cMCStatus.success and a
                   signingTime attribute (2 in Figure 4).  The GLA ought
                   not accept further requests for member additions,
                   member deletions, or group rekeys for this GL.

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

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

Top      Up      ToC       Page 38 
   3 - Upon receipt of the cMCStatusInfoExt response, the GLO checks the
       signingTime and verifies the GLA signature(s).  If an additional
       SignedData and/or EnvelopedData encapsulates the response (see
       Section 3.2.1.2 or 3.2.2), the GLO verifies the outer signature
       and/or decrypts the outer layer prior to verifying the signature
       on the innermost SignedData.

     3.a - If the signingTime attribute value is not within the locally
           accepted time window, the GLO MAY return a response
           indicating cMCStatus.failed and otherInfo.failInfo.badTime
           and a signingTime attribute.

     3.b - Else if signature processing continues and if the signatures
           verify, the GLO checks that one of the names in the
           certificate used to sign the response matches the name of the
           GL.

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

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

         3.b.2.a - If the signatures verify and the response was
                   cMCStatusInfoExt indicating cMCStatus.success, the
                   GLO has successfully deleted the GL.

         3.b.2.b - Else if the signatures do verify and the response was
                   cMCStatusInfoExt.cMCStatus.failed with any reason,
                   the GLO can reattempt to delete the GL using the
                   information provided in the response.

4.3.  Add Members to GL

   To add members to GLs, either the GLO or prospective members use the
   glAddMember request.  The GLA processes GLO and prospective GL member
   requests differently though.  GLOs can submit the request at any time
   to add members to the GL, and the GLA, once it has verified the
   request came from a registered GLO, should process it.  If a
   prospective member sends the request, the GLA needs to determine how
   the GL is administered.  When the GLO initially configured the GL, it
   set the GL to be unmanaged, managed, or closed (see Section 3.1.1).
   In the unmanaged case, the GLA merely processes the member's request.
   In the managed case, the GLA forwards the requests from the
   prospective members to the GLO for review.  Where there are multiple
   GLOs for a GL, which GLO the request is forwarded to is beyond the
   scope of this document.  The GLO reviews the request and either

Top      Up      ToC       Page 39 
   rejects it or submits a reformed request to the GLA.  In the closed
   case, the GLA will not accept requests from prospective members.  The
   following sections describe the processing for the GLO(s), GLA, and
   prospective GL members depending on where the glAddMeber request
   originated, either from a GLO or from prospective members.  Figure 5
   depicts the protocol interactions for the three options.  Note that
   the error messages are not depicted.  Additionally, note that
   behavior for the optional transactionId, senderNonce, and
   recipientNonce CMC control attributes is not addressed in these
   procedures.

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

         Figure 5 - Member Addition

   An important decision that needs to be made on a group-by-group basis
   is whether to rekey the group every time a new member is added.
   Typically, unmanaged GLs should not be rekeyed when a new member is
   added, as the overhead associated with rekeying the group becomes
   prohibitive, as the group becomes large.  However, managed and closed
   GLs can be rekeyed to maintain the confidentiality of the traffic
   sent by group members.  An option to rekeying managed or closed GLs
   when a member is added is to generate a new GL with a different group
   key.  Group rekeying is discussed in Sections 4.5 and 5.

4.3.1.  GLO Initiated Additions

   The process for GLO initiated glAddMember requests is as follows:

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

Top      Up      ToC       Page 40 
       certificate in glMember.certificates.aC, and the certification
       path associated with the member's encryption and attribute
       certificates in glMember.certificates.certPath.  The GLO MUST
       also include the signingTime attribute with this request.

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

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

   2 - Upon receipt of the request, the GLA checks the signingTime and
       verifies the signature on the innermost SignedData.PKIData.  If
       an additional SignedData and/or EnvelopedData encapsulates the
       request (see Section 3.2.1.2 or 3.2.2), the GLA verifies the
       outer signature and/or decrypts the outer layer prior to
       verifying the signature on the innermost SignedData.

     2.a - If the signingTime attribute value is not within the locally
           accepted time window, the GLA MAY return a response
           indicating cMCStatus.failed and otherInfo.failInfo.badTime
           and a signingTime attribute.

     2.b - Else if signature processing continues and if the signatures
           cannot be verified, the GLA returns a cMCStatusInfoExt
           response indicating cMCStatus.failed and
           otherInfo.failInfo.badMessageCheck.  Additionally, a
           signingTime attribute is included with the response.

     2.c - Else if the signatures verify, the glAddMember request is
           included in a controlSequence with the glUseKEK request, and
           the processing in Section 4.1 item 2.d is successfully
           completed, the GLA returns a cMCStatusInfoExt indicating
           cMCStatus.success and a signingTime attribute (2 in Figure
           5).

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

       2.c.2 - The GLA can also optionally apply another SignedData over
               the EnvelopedData (see Section 3.2.1.2).

Top      Up      ToC       Page 41 
     2.d - Else if the signatures verify and the GLAddMember request is
           not included in a controlSequence with the GLCreate request,
           the GLA makes sure the GL is supported by checking that the
           glName matches a glName stored on the GLA.

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

       2.d.2 - Else if the glName is supported by the GLA, the GLA
               checks to see if the glMemberName is present on the GL.

         2.d.2.a - If the glMemberName is present on the GL, the GLA
                   returns a response indicating cMCStatusInfoExt with
                   cMCStatus.failed and
                   otherInfo.extendedFailInfo.SKDFailInfo value of
                   alreadyAMember.  Additionally, a signingTime
                   attribute is included with the response.

         2.d.2.b - Else if the glMemberName is not present on the GL,
                   the GLA checks how the GL is administered.

           2.d.2.b.1 - If the GL is closed, the GLA checks that a
                       registered GLO signed the request by checking
                       that one of the names in the digital signature
                       certificate used to sign the request matches a
                       registered GLO.

             2.d.2.b.1.a - If the names do not match, the GLA returns a
                           response indicating cMCStatusInfoExt with
                           cMCStatus.failed and
                           otherInfo.extendedFailInfo.SKDFailInfo value
                           of noGLONameMatch.  Additionally, a
                           signingTime attribute is included with the
                           response.

             2.d.2.b.1.b - Else if the names match, the GLA verifies the
                           member's encryption certificate.

               2.d.2.b.1.b.1 - If the member's encryption certificate
                               cannot be verified, the GLA can return a
                               response indicating cMCStatusInfoExt with
                               cMCStatus.failed and
                               otherInfo.extendedFailInfo.SKDFailInfo
                               value of invalidCert to the GLO.

Top      Up      ToC       Page 42 
                               Additionally, a signingTime attribute is
                               included with the response.  If the GLA
                               does not return a
                               cMCStatusInfoExt.cMCStatus.failed
                               response, the GLA issues a glProvideCert
                               request (see Section 4.10).

               2.d.2.b.1.b.2 - Else if the member's certificate
                               verifies, the GLA returns a
                               cMCStatusInfoExt indicating
                               cMCStatus.success and a signingTime
                               attribute (2 in Figure 5).  The GLA also
                               takes administrative actions, which are
                               beyond the scope of this document, to add
                               the member to the GL stored on the GLA.
                               The GLA also distributes the shared KEK
                               to the member via the mechanism described
                               in Section 5.

                 2.d.2.b.1.b.2.a - The GLA applies confidentiality to
                                   the response by encapsulating the
                                   SignedData.PKIData in an
                                   EnvelopedData if the request was
                                   encapsulated in an EnvelopedData (see
                                   Section 3.2.1.2).

                 2.d.2.b.1.b.2.b - The GLA can also optionally apply
                                   another SignedData over the
                                   EnvelopedData (see Section 3.2.1.2).

           2.d.2.b.2 - Else if the GL is managed, the GLA checks that
                       either a registered GLO or the prospective member
                       signed the request.  For GLOs, one of the names
                       in the certificate used to sign the request needs
                       to match a registered GLO.  For the prospective
                       member, the name in glMember.glMemberName needs
                       to match one of the names in the certificate used
                       to sign the request.

             2.d.2.b.2.a - If the signer is neither a registered GLO nor
                           the prospective GL member, the GLA returns a
                           response indicating cMCStatusInfoExt with
                           cMCStatus.failed and
                           otherInfo.extendedFailInfo.SKDFailInfo value
                           of noSpam.  Additionally, a signingTime
                           attribute is included with the response.

Top      Up      ToC       Page 43 
             2.d.2.b.2.b - Else if the signer is a registered GLO, the
                           GLA verifies the member's encryption
                           certificate.

               2.d.2.b.2.b.1 - If the member's certificate cannot be
                               verified, the GLA can return a response
                               indicating cMCStatusInfoExt with
                               cMCStatus.failed and
                               otherInfo.extendedFailInfo.SKDFailInfo
                               value of invalidCert.  Additionally, a
                               signingTime attribute is included with
                               the response.  If the GLA does not return
                               a cMCStatus.failed response, the GLA MUST
                               issue a glProvideCert request (see
                               Section 4.10).

               2.d.2.b.2.b.2 - Else if the member's certificate
                               verifies, the GLA MUST return a
                               cMCStatusInfoExt indicating
                               cMCStatus.success and a signingTime
                               attribute to the GLO (2 in Figure 5).
                               The GLA also takes administrative
                               actions, which are beyond the scope of
                               this document, to add the member to the
                               GL stored on the GLA.  The GLA also
                               distributes the shared KEK to the member
                               via the mechanism described in Section 5.
                               The GL policy may mandate that the GL
                               member's address be included in the GL
                               member's certificate.

                 2.d.2.b.2.b.2.a - The GLA applies confidentiality to
                                   the response by encapsulating the
                                   SignedData.PKIData in an
                                   EnvelopedData if the request was
                                   encapsulated in an EnvelopedData (see
                                   Section 3.2.1.2).

                 2.d.2.b.2.b.2.b - The GLA can also optionally apply
                                   another SignedData over the
                                   EnvelopedData (see Section 3.2.1.2).

             2.d.2.b.2.c - Else if the signer is the prospective member,
                           the GLA forwards the glAddMember request (see
                           Section 3.2.3) to a registered GLO (B{A} in
                           Figure 5).  If there is more than one
                           registered GLO, the GLO to which the request
                           is forwarded is beyond the scope of this

Top      Up      ToC       Page 44 
                           document.  Further processing of the
                           forwarded request by GLOs is addressed in 3
                           of Section 4.3.2.

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

               2.d.2.b.2.c.2 - The GLA can also optionally apply another
                               SignedData over the EnvelopedData (see
                               Section 3.2.1.2).

           2.d.2.b.3 - Else if the GL is unmanaged, the GLA checks that
                       either a registered GLO or the prospective member
                       signed the request.  For GLOs, one of the names
                       in the certificate used to sign the request needs
                       to match the name of a registered GLO.  For the
                       prospective member, the name in
                       glMember.glMemberName needs to match one of the
                       names in the certificate used to sign the
                       request.

             2.d.2.b.3.a - If the signer is neither a registered GLO nor
                           the prospective member, the GLA returns a
                           response indicating cMCStatusInfoExt with
                           cMCStatus.failed and
                           otherInfo.extendedFailInfo.SKDFailInfo value
                           of noSpam.  Additionally, a signingTime
                           attribute is included with the response.

             2.d.2.b.3.b - Else if the signer is either a registered GLO
                           or the prospective member, the GLA verifies
                           the member's encryption certificate.

               2.d.2.b.3.b.1 - If the member's certificate cannot be
                               verified, the GLA can return a response
                               indicating cMCStatusInfoExt with
                               cMCStatus.failed and
                               otherInfo.extendedFailInfo.SKDFailInfo
                               value of invalidCert and a signingTime
                               attribute to either the GLO or the
                               prospective member depending on where the
                               request originated.  If the GLA does not
                               return a cMCStatus.failed response, the
                               GLA issues a glProvideCert request (see

Top      Up      ToC       Page 45 
                               Section 4.10) to either the GLO or
                               prospective member depending on where the
                               request originated.

               2.d.2.b.3.b.2 - Else if the member's certificate
                               verifies, the GLA returns a
                               cMCStatusInfoExt indicating
                               cMCStatus.success and a signingTime
                               attribute 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 GLA also takes
                               administrative actions, which are beyond
                               the scope of this document, to add the
                               member to the GL stored on the GLA.  The
                               GLA also distributes the shared KEK to
                               the member via the mechanism described in
                               Section 5.

                 2.d.2.b.3.b.2.a - The GLA applies confidentiality to
                                   the response by encapsulating the
                                   SignedData.PKIData in an
                                   EnvelopedData if the request was
                                   encapsulated in an EnvelopedData (see
                                   Section 3.2.1.2).

                 2.d.2.b.3.b.2.b - The GLA can also optionally apply
                                   another SignedData over the
                                   EnvelopedData (see Section 3.2.1.2).

   3 - Upon receipt of the cMCStatusInfoExt response, the GLO checks the
       signingTime and verifies the GLA signature(s).  If an additional
       SignedData and/or EnvelopedData encapsulates the response (see
       Section 3.2.1.2 or 3.2.2), the GLO verifies the outer signature
       and/or decrypts the outer layer prior to verifying the signature
       on the innermost SignedData.

     3.a - If the signingTime attribute value is not within the locally
           accepted time window, the GLO MAY return a response
           indicating cMCStatus.failed and otherInfo.failInfo.badTime
           and a signingTime attribute.

     3.b - Else if signature processing continues and if the signatures
           verify, the GLO checks that one of the names in the
           certificate used to sign the response matches the name of the
           GL.

Top      Up      ToC       Page 46 
       3.b.1 - If the name of the GL does not match the name present in
               the certificate used to sign the message, the GLO should
               not believe the response.

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

         3.b.2.a - If the signatures verify and the response is
                   cMCStatusInfoExt indicating cMCStatus.success, the
                   GLA has added the member to the GL.  If the member
                   was added to a managed list and the original request
                   was signed by the member, the GLO sends a
                   cMCStatusInfoExt.cMCStatus.success and a signingTime
                   attribute to the GL member.

         3.b.2.b - Else if the GLO received a
                   cMCStatusInfoExt.cMCStatus.failed with any reason,
                   the GLO can reattempt to add the member to the GL
                   using the information provided in the response.

   4 - Upon receipt of the cMCStatusInfoExt response, the prospective
       member checks the signingTime and verifies the GLA signatures or
       GLO signatures.  If an additional SignedData and/or EnvelopedData
       encapsulates the response (see Section 3.2.1.2 or 3.2.2), the GLO
       verifies the outer signature and/or decrypts the outer layer
       prior to verifying the signature on the innermost SignedData.

     4.a - If the signingTime attribute value is not within the locally
           accepted time window, the prospective member MAY return a
           response indicating cMCStatus.failed and
           otherInfo.failInfo.badTime and a signingTime attribute.

     4.b - Else if signature processing continues and if the signatures
           verify, the GL member checks that one of the names in the
           certificate used to sign the response matches the name of the
           GL.

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

     4.b.2 - Else if the name of the GL matches the name present in the
               certificate and:

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

Top      Up      ToC       Page 47 
         4.b.2.b - Else if the prospective member received a
                   cMCStatusInfoExt.cMCStatus.failed, for any reason,
                   the prospective member MAY reattempt to add itself to
                   the GL using the information provided in the
                   response.

4.3.2.  Prospective Member Initiated Additions

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

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

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

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

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

   3 - Upon receipt of the forwarded request, the GLO checks the
       signingTime and verifies the prospective GL member signature on
       the innermost SignedData.PKIData and the GLA signature on the
       outer layer.  If an EnvelopedData encapsulates the innermost
       layer (see Section 3.2.1.2 or 3.2.2), the GLO decrypts the outer
       layer prior to verifying the signature on the innermost
       SignedData.

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

Top      Up      ToC       Page 48 
     3.a - If the signingTime attribute value is not within the locally
           accepted time window, the GLO MAY return a response
           indicating cMCStatus.failed and otherInfo.failInfo.badTime.

     3.b - Else if signature processing continues and if the signatures
           verify, the GLO checks to make sure one of the names in the
           certificate used to sign the request matches the name in
           glMember.glMemberName.

       3.b.1 - If the names do not match, the GLO sends a
               SignedData.PKIResponse.controlSequence message back to
               the prospective member with
               cMCStatusInfoExt.cMCStatus.failed indicating why the
               prospective member was denied in
               cMCStausInfo.statusString.  This stops people from adding
               people to GLs without their permission.  Additionally, a
               signingTime attribute is included with the response.

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

         3.b.2.a - If the GLO determines the prospective member is not
                   allowed to join the GL, the GLO can return a
                   SignedData.PKIResponse.controlSequence message back
                   to the prospective member with
                   cMCStatusInfoExt.cMCtatus.failed indicating why the
                   prospective member was denied in
                   cMCStatus.statusString.  Additionally, a signingTime
                   attribute is included with the response.

         3.b.2.b - Else if the GLO determines the prospective member is
                   allowed to join the GL, the GLO verifies the member's
                   encryption certificate.

           3.b.2.b.1 - If the member's certificate cannot be verified,
                       the GLO returns a
                       SignedData.PKIResponse.controlSequence back to
                       the prospective member with
                       cMCStatusInfoExt.cMCtatus.failed indicating that
                       the member's encryption certificate did not
                       verify in cMCStatus.statusString.  Additionally,
                       a signingTime attribute is included with the
                       response.  If the GLO does not return a
                       cMCStatusInfoExt response, the GLO sends a

Top      Up      ToC       Page 49 
                       SignedData.PKIData.controlSequence.glProvideCert
                       message to the prospective member requesting a
                       new encryption certificate (see Section 4.10).

           3.b.2.b.2 - Else if the member's certificate verifies, the
                       GLO resubmits the glAddMember request (see
                       Section 3.2.5) to the GLA (1 in Figure 5).

             3.b.2.b.2.a - The GLO applies confidentiality to the new
                           GLAddMember request by encapsulating the
                           SignedData.PKIData in an EnvelopedData if the
                           initial request was encapsulated in an
                           EnvelopedData (see Section 3.2.1.2).

             3.b.2.b.2.b - The GLO can also optionally apply another
                           SignedData over the EnvelopedData (see
                           Section 3.2.1.2).

   4 - Processing continues as in 2 of Section 4.3.1.

4.4.  Delete Members from GL

   To delete members from GLs, either the GLO or members to be removed
   use the glDeleteMember request.  The GLA processes the GLO, and
   members requesting their own removal make requests differently.  The
   GLO can submit the request at any time to delete members from the GL,
   and the GLA, once it has verified the request came from a registered
   GLO, should delete the member.  If a member sends the request, the
   GLA needs to determine how the GL is administered.  When the GLO
   initially configured the GL, it set the GL to be unmanaged, managed,
   or closed (see Section 3.1.1).  In the unmanaged case, the GLA merely
   processes the member's request.  In the managed case, the GLA
   forwards the requests from the member to the GLO for review.  Where
   there are multiple GLOs for a GL, which GLO the request is forwarded
   to is beyond the scope of this document.  The GLO reviews the request
   and either rejects it or submits a reformed request to the GLA.  In
   the closed case, the GLA will not accept requests from members.  The
   following sections describe the processing for the GLO(s), GLA, and
   GL members depending on where the request originated, either from a
   GLO or from members wanting to be removed.  Figure 6 depicts the
   protocol interactions for the three options.  Note that the error
   messages are not depicted.  Additionally, behavior for the optional
   transactionId, senderNonce, and recipientNonce CMC control attributes
   is not addressed in these procedures.

Top      Up      ToC       Page 50 
   +-----+  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, it will continue to receive
   and be able to decrypt data protected with the shared KEK and will
   continue to receive rekeys.  For unmanaged lists, there is no point
   to a group rekey because there is no guarantee that the member
   requesting to be removed has not already added itself back on the GL
   under a different name.  For managed and closed GLs, the GLO needs to
   take steps to ensure that the member being deleted is not on the GL
   twice.  After ensuring this, managed and closed GLs can be rekeyed to
   maintain the confidentiality of the traffic sent by group members.
   If the GLO is sure the member has been deleted, the group rekey
   mechanism can be used to distribute the new key (see Sections 4.5 and
   5).

4.4.1.  GLO Initiated Deletions

   The process for GLO initiated glDeleteMember requests is as follows:

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

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

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

Top      Up      ToC       Page 51 
   2 - Upon receipt of the request, the GLA checks the signingTime
       attribute and verifies the signature on the innermost
       SignedData.PKIData.  If an additional SignedData and/or
       EnvelopedData encapsulates the request (see Section 3.2.1.2 or
       3.2.2), the GLA verifies the outer signature and/or decrypts the
       outer layer prior to verifying the signature on the innermost
       SignedData.

     2.a - If the signingTime attribute value is not within the locally
           accepted time window, the GLA MAY return a response
           indicating cMCStatus.failed and otherInfo.failInfo.badTime
           and a signingTime attribute.

     2.b - Else if signature processing continues and if the signatures
           cannot be verified, the GLA returns a cMCStatusInfoExt
           response indicating cMCStatus.failed and
           otherInfo.failInfo.badMessageCheck.  Additionally, a
           signingTime attribute is included with the response.

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

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

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

         2.c.2.a - If the glMemberName is not present on the GL, the GLA
                   returns a response indicating cMCStatusInfoExt with
                   cMCStatus.failed and
                   otherInfo.extendedFailInfo.SKDFailInfo value of
                   notAMember.  Additionally, a signingTime attribute is
                   included with the response.

         2.c.2.b - Else if the glMemberName is already on the GL, the
                   GLA checks how the GL is administered.

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

Top      Up      ToC       Page 52 
             2.c.2.b.1.a - If the names do not match, the GLA returns a
                           response indicating cMCStatusInfoExt with
                           cMCStatus.failed and
                           otherInfo.extendedFailInfo.SKDFailInfo value
                           of closedGL.  Additionally, a signingTime
                           attribute is included with the response.

             2.c.2.b.1.b - Else if the names do match, the GLA returns a
                           cMCStatusInfoExt.cMCStatus.success and a
                           signingTime attribute (2 in Figure 5).  The
                           GLA also takes administrative actions, which
                           are beyond the scope of this document, to
                           delete the member with the GL stored on the
                           GLA.  Note that the GL also needs to be
                           rekeyed as described in Section 5.

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

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

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

             2.c.2.b.2.a - If the signer is neither a registered GLO nor
                           the prospective GL member, the GLA returns a
                           response indicating cMCStatusInfoExt with
                           cMCStatus.failed and
                           otherInfo.extendedFailInfo.SKDFailInfo value
                           of noSpam.  Additionally, a signingTime
                           attribute is included with the response.

             2.c.2.b.2.b - Else if the signer is a registered GLO, the
                           GLA returns a
                           cMCStatusInfoExt.cMCStatus.success and a
                           signingTime attribute(2 in Figure 6).  The
                           GLA also takes administrative actions, which

Top      Up      ToC       Page 53 
                           are beyond the scope of this document, to
                           delete the member with the GL stored on the
                           GLA.  Note that the GL will also be rekeyed
                           as described in Section 5.

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

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

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

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

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

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

Top      Up      ToC       Page 54 
             2.c.2.b.3.a - If the signer is neither the GLO nor the
                           prospective member, the GLA returns a
                           response indicating cMCStatusInfoExt with
                           cMCStatus.failed and
                           otherInfo.extendedFailInfo.SKDFailInfo value
                           of noSpam.  Additionally, a signingTime
                           attribute is included with the response.

             2.c.2.b.3.b - Else if the signer is either a registered GLO
                           or the member, the GLA returns a
                           cMCStatusInfoExt.cMCStatus.success and a
                           signingTime attribute to the GLO (2 in Figure
                           6) if the GLO signed the request and to the
                           GL member (3 in Figure 6) if the GL member
                           signed the request.  The GLA also takes
                           administrative actions, which are beyond the
                           scope of this document, to delete the member
                           with the GL stored on the GLA.

               2.c.2.b.3.b.1 - The GLA applies confidentiality to the
                               response by encapsulating the
                               SignedData.PKIData in an EnvelopedData if
                               the request was encapsulated in an
                               EnvelopedData (see Section 3.2.1.2).

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

   3 - Upon receipt of the cMCStatusInfoExt response, the GLO checks the
       signingTime and verifies the GLA signatures.  If an additional
       SignedData and/or EnvelopedData encapsulates the response (see
       Section 3.2.1.2 or 3.2.2), the GLO verifies the outer signature
       and/or decrypts the outer layer prior to verifying the signature
       on the innermost SignedData.

     3.a - If the signingTime attribute value is not within the locally
           accepted time window, the GLO MAY return a response
           indicating cMCStatus.failed and otherInfo.failInfo.badTime
           and a signingTime attribute.

     3.b - Else if signature processing continues and if the signatures
           do verify, the GLO checks that one of the names in the
           certificate used to sign the response matches the name of the
           GL.

Top      Up      ToC       Page 55 
       3.b.1 - If the name of the GL does not match the name present in
               the certificate used to sign the message, the GLO should
               not believe the response.

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

         3.b.2.a - If the signatures verify and the response is
                   cMCStatusInfoExt.cMCStatus.success, the GLO has
                   deleted the member from the GL.  If member was
                   deleted from a managed list and the original request
                   was signed by the member, the GLO sends a
                   cMCStatusInfoExt.cMCStatus.success and a signingTime
                   attribute to the GL member.

         3.b.2.b - Else if the GLO received a
                   cMCStatusInfoExt.cMCStatus.failed with any reason,
                   the GLO may reattempt to delete the member from the
                   GL using the information provided in the response.

   4 - Upon receipt of the cMCStatusInfoExt response, the member checks
       the signingTime and verifies the GLA signature(s) or GLO
       signature(s).  If an additional SignedData and/or EnvelopedData
       encapsulates the response (see Section 3.2.1.2 or 3.2.2), the GLO
       verifies the outer signature and/or decrypts the outer layer
       prior to verifying the signature on the innermost SignedData.

     4.a - If the signingTime attribute value is not within the locally
           accepted time window, the prospective member MAY return a
           response indicating cMCStatus.failed and
           otherInfo.failInfo.badTime and a signingTime attribute.

     4.b - Else if signature processing continues and if the signatures
           verify, the GL member checks that one of the names in the
           certificate used to sign the response matches the name of the
           GL.

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

       4.b.2 - Else if the name of the GL matches the name present in
               the certificate and:

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

Top      Up      ToC       Page 56 
         4.b.2.b - Else if the member received a
                   cMCStatusInfoExt.cMCStatus.failed with any reason,
                   the member can reattempt to delete itself from the GL
                   using the information provided in the response.

4.4.2.  Member Initiated Deletions

   The process for member initiated deletion of its own membership using
   the glDeleteMember requests is as follows:

   1 - The member sends a
       SignedData.PKIData.controlSequence.glDeleteMember request to the
       GLA (A in Figure 6).  The member includes the name of the GL in
       glName and the member's own name in glMemberToDelete.  The GL
       member MUST also include the signingTime attribute with this
       request.

     1.a - The member can optionally apply confidentiality to the
           request by encapsulating the SignedData.PKIData in an
           EnvelopedData (see Section 3.2.1.2).

     1.b - The member can also optionally apply another SignedData over
           the EnvelopedData (see Section 3.2.1.2).

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

   3 - Upon receipt of the forwarded request, the GLO checks the
       signingTime and verifies the member signature on the innermost
       SignedData.PKIData and the GLA signature on the outer layer.  If
       an EnvelopedData encapsulates the innermost layer (see Section
       3.2.1.2 or 3.2.2), the GLO decrypts the outer layer prior to
       verifying the signature on the innermost SignedData.

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

     3.a - If the signingTime attribute value is not within the locally
           accepted time window, the GLO MAY return a response
           indicating cMCStatus.failed and otherInfo.failInfo.badTime
           and a signingTime attribute.

Top      Up      ToC       Page 57 
     3.b - Else if signature processing continues if the signatures
           cannot be verified, the GLO returns a cMCStatusInfoExt
           response indicating cMCStatus.failed and
           otherInfo.failInfo.badMessageCheck and a signingTime
           attribute.

     3.c - Else if the signatures verify, the GLO checks to make sure
           one of the names in the certificates used to sign the request
           matches the name in glMemberToDelete.

       3.c.1 - If the names do not match, the GLO sends a
               SignedData.PKIResponse.controlSequence message back to
               the prospective member with
               cMCStatusInfoExt.cMCtatus.failed indicating why the
               prospective member was denied in
               cMCStatusInfoExt.statusString.  This stops people from
               adding people to GLs without their permission.
               Additionally, a signingTime attribute is included with
               the response.

       3.c.2 - Else if the names match, the GLO resubmits the
               glDeleteMember request (see Section 3.2.5) to the GLA (1
               in Figure 6).  The GLO makes sure the glMemberName is
               already on the GL.  The GLO also generates a glRekey
               request and include it with the GLDeleteMember request
               (see Section 4.5).

         3.c.2.a - The GLO applies confidentiality to the new
                   GLDeleteMember request by encapsulating the
                   SignedData.PKIData in an EnvelopedData if the initial
                   request was encapsulated in an EnvelopedData (see
                   Section 3.2.1.2).

         3.c.2.b - The GLO can also optionally apply another SignedData
                   over the EnvelopedData (see Section 3.2.1.2).

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



(page 57 continued on part 4)

Next RFC Part