tech-invite   World Map     

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

RFC 5275

 
 
 

CMS Symmetric Key Management and Distribution

Part 4 of 5, p. 57 to 79
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 57 
4.5.  Request Rekey of GL

   From time to time, the GL will need to be rekeyed.  Some situations
   follow:

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

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

     - When the current shared KEK has been compromised.

     - When the current shared KEK is about to expire.  Consider two
       cases:

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

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

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

   The GLA and GLO are the only entities allowed to initiate a GL rekey.
   The GLO indicated whether they are going to control rekeys or whether
   the GLA is going to control rekeys when they assigned the shared KEK
   to GL (see Section 3.1.1).  The GLO initiates a GL rekey at any time.
   The GLA can be configured to automatically rekey the GL prior to the
   expiration of the shared KEK (the length of time before the
   expiration is an implementation decision).  The GLA can also
   automatically rekey GLs that have been compromised, but this is
   covered in Section 5.  Figure 7 depicts the protocol interactions to
   request a GL rekey.  Note that error messages are not depicted.
   Additionally, behavior for the optional transactionId, senderNonce,
   and recipientNonce CMC control attributes is not addressed in these
   procedures.

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

   Figure 7 - GL Rekey Request

Top      Up      ToC       Page 59 
4.5.1.  GLO Initiated Rekey Requests

   The process for GLO initiated glRekey requests is as follows:

   1 - The GLO sends a SignedData.PKIData.controlSequence.glRekey
       request to the GLA (1 in Figure 7).  The GLO includes the glName.
       If glAdministration and glKeyNewAttributes are omitted then there
       is no change from the previously registered GL values for these
       fields.  If the GLO wants to force a rekey for all outstanding
       shared KEKs, it includes the glRekeyAllGLKeys set to TRUE.  The
       GLO MUST also include a 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
           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, 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 present does not match a GL stored on 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.

Top      Up      ToC       Page 60 
       2.c.2 - Else if the glName present matches a GL stored on the
               GLA, the GLA checks that a registered GLO signed the
               request by checking that one of the names in the
               certificate used to sign the request is 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 match, the GLA checks the
                   glNewKeyAttribute values.

           2.c.2.b.1 - If the new value for 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.c.2.b.2 - Else if the new value duration is not supportable
                       (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.c.2.b.3 - Else if the GL is not supportable for other
                       reasons that 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.c.2.b.4 - Else if the new requestedAlgorithm and duration
                       are supportable or the glNewKeyAttributes was
                       omitted, the GLA returns a
                       cMCStatusInfoExt.cMCStatus.success and a
                       sigingTime attribute (2 in Figure 7).  The GLA
                       also uses the glKey message to distribute the
                       rekey shared KEK (see Section 5).

Top      Up      ToC       Page 61 
             2.c.2.b.4.a - The GLA applies confidentiality to 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.4.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 forwarded
       response (see Section 3.2.1.2 or 3.2.2), the GLO verifies the
       outer signature and/or decrypts the forwarded response 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 GLA 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 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
                   successfully rekeyed the GL.

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

Top      Up      ToC       Page 62 
4.5.2.  GLA Initiated Rekey Requests

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

   1 - The GLA generates for all GLOs a
       SignedData.PKIData.controlSequence.cMCStatusInfoExt.cMCStatus
       success and includes a signingTime attribute (A in Figure 7).

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

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

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

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

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

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

       2.b.2 - Else if the name of the GL does match the name present in
               the certificate and the response is
               cMCStatusInfoExt.cMCStatus.success, the GLO knows the GLA
               has successfully rekeyed the GL.

Top      Up      ToC       Page 63 
4.6.  Change GLO

   Management of managed and closed GLs can become difficult for one GLO
   if the GL membership grows large.  To support distributing the
   workload, GLAs support having GLs be managed by multiple GLOs.  The
   glAddOwner and glRemoveOwner messages are designed to support adding
   and removing registered GLOs.  Figure 8 depicts the protocol
   interactions to send glAddOwner and glRemoveOwner messages and the
   resulting response messages.  Note that error messages are not shown.
   Additionally, behavior for the optional transactionId, senderNonce,
   and recipientNonce CMC control attributes is not addressed in these
   procedures.

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

   Figure 8 - GLO Add and Delete Owners

   The process for glAddOwner and glDeleteOwner is as follows:

   1 - The GLO sends a SignedData.PKIData.controlSequence.glAddOwner or
       glRemoveOwner request to the GLA (1 in Figure 8).  The GLO
       includes the GL name in glName, and the name and address of the
       GLO in glOwnerName and glOwnerAddress, respectively.  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 glAddOwner or glRemoveOwner request, the GLA
       checks the signingTime and verifies the GLO signature(s).  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.

Top      Up      ToC       Page 64 
     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 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
               ensures that a registered GLO signed the glAddOwner or
               glRemoveOwner request by checking that one of the names
               present in the digital signature certificate used to sign
               the glAddOwner or glDeleteOwner request matches the name
               of a registered GLO.

         2.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 match, the GLA returns a
                   cMCStatusInfoExt.cMCStatus.success and a signingTime
                   attribute (2 in Figure 4).  The GLA also takes
                   administrative actions to associate the new
                   glOwnerName with the GL in the case of glAddOwner or
                   to disassociate the old glOwnerName with the GL in
                   the cased of glRemoveOwner.

           2.c.2.b.1 - The GLA applies 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.b.2 - The GLA can also optionally apply another
                       SignedData over the EnvelopedData (see Section
                       3.2.1.2).

Top      Up      ToC       Page 65 
   3 - Upon receipt of the cMCStatusInfoExt response, the GLO checks the
       signingTime and verifies the GLA's 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.cMCStatus.success, the GLO has
                   successfully added or removed the GLO.

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

4.7.  Indicate KEK Compromise

   There will be times when the shared KEK is compromised.  GL members
   and GLOs use glkCompromise to tell the GLA that the shared KEK has
   been compromised.  Figure 9 depicts the protocol interactions for GL
   Key Compromise.  Note that error messages are not shown.
   Additionally, behavior for the optional transactionId, senderNonce,
   and recipientNonce CMC control attributes is not addressed in these
   procedures.

Top      Up      ToC       Page 66 
   +-----+  2{1}                  4  +----------+
   | GLO | <----------+    +-------> | Member 1 |
   +-----+  5,3{1}    |    |         +----------+
   +-----+ <----------+    |      4  +----------+
   | GLA |  1              +-------> |   ...    |
   +-----+ <---------------+         +----------+
                           |      4  +----------+
                           +-------> | Member n |
                                     +----------+

   Figure 9 - GL Key Compromise

4.7.1.  GL Member Initiated KEK Compromise Message

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

   1 - The GL member sends a
       SignedData.PKIData.controlSequence.glkCompromise request to the
       GLA (1 in Figure 9).  The GL member includes the name of the GL
       in GeneralName.  The GL member MUST also include the signingTime
       attribute with this request.

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

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

   2 - Upon receipt of the glkCompromise request, the GLA checks the
       signingTime and verifies the GL member signature(s).  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.

Top      Up      ToC       Page 67 
     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 checking that the indicated GL name 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 who 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 member, the name in
               glMember.glMemberName needs to match one of the names in
               the certificate used to sign the request.

         2.c.2.a - If the GLO signed the request, the GLA generates a
                   glKey message as described in Section 5 to rekey the
                   GL (4 in Figure 9).

         2.c.2.b - Else if someone other than the GLO signed the
                   request, the GLA forwards the glkCompromise message
                   (see Section 3.2.3) to the GLO (2{1} in Figure 9).
                   If there is more than one GLO, to which GLO the
                   request is forwarded is beyond the scope of this
                   document.  Further processing by the GLO is discussed
                   in Section 4.7.2.

4.7.2.  GLO Initiated KEK Compromise Message

   The process for GLO initiated glkCompromise messages is as follows:

   1 - The GLO either:

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

Top      Up      ToC       Page 68 
       1.a.1 - The GLO can optionally apply confidentiality to the
               request by encapsulating the SignedData.PKIData in an
               EnvelopedData (see Section 3.2.1.2).  The glkCompromise
               can be included in an EnvelopedData generated with the
               compromised shared KEK.

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

     1.b - Otherwise, checks the signingTime and verifies the GLA and GL
           member signatures on the forwarded glkCompromise message.  If
           an additional SignedData and/or EnvelopedData encapsulates
           the request (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.

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

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

         1.b.2.a - If the signatures verify, the GLO checks that the
                   names in the certificate match the name of the signer
                   (i.e., the name in the certificate used to sign the
                   GL member's request is the GL member).

           1.b.2.a.1 - If either name does not match, the GLO ought not
                       trust the signer and it ought not forward the
                       message to the GLA.

           1.b.2.a.2 - Else if the names match and the signatures
                       verify, the GLO determines whether to forward the
                       glkCompromise message back to the GLA (3{1} in
                       Figure 9).  Further processing by the GLA is in 2
                       of Section 4.7.1.  The GLO can also return a
                       response to the prospective member with
                       cMCStatusInfoExt.cMCtatus.success indicating that
                       the glkCompromise message was successfully
                       received.

Top      Up      ToC       Page 69 
4.8.  Request KEK Refresh

   There will be times when GL members have irrecoverably lost their
   shared KEK.  The shared KEK is not compromised and a rekey of the
   entire GL is not necessary.  GL members use the glkRefresh message to
   request that the shared KEK(s) be redistributed to them.  Figure 10
   depicts the protocol interactions for GL Key Refresh.  Note that
   error messages are not shown.  Additionally, behavior for the
   optional transactionId, senderNonce, and recipientNonce CMC control
   attributes is not addressed in these procedures.

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

      Figure 10 - GL KEK Refresh

   The process for glkRefresh is as follows:

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

     1.a - The 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 GL member can also optionally apply another SignedData
           over the EnvelopedData (see Section 3.2.1.2).

   2 - Upon receipt of the glkRefresh request, the GLA checks the
       signingTime and verifies the GL member signature(s).  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 decrypt 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.

Top      Up      ToC       Page 70 
     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 checking that the GLGeneralName matches a glName
           stored on the GLA.

       2.c.1 - If the name of the GL 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 the GL member is 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
                   noSpam.  Additionally, a signingTime attribute is
                   included with the response.

         2.c.2.b - Else if the glMemberName is present on the GL, the
                   GLA returns a cMCStatusInfoExt.cMCStatus.success, a
                   signingTime attribute, and a glKey message (2 in
                   Figure 10) as described in Section 5.

4.9.  GLA Query Request and Response

   There will be certain times when a GLO is having trouble setting up a
   GL because it does not know the algorithm(s) or some other
   characteristic that the GLA supports.  There can also be times when
   prospective GL members or GL members need to know something about the
   GLA (these requests are not defined in the document).  The
   glaQueryRequest and glaQueryResponse messages have been defined to
   support determining this information.  Figure 11 depicts the protocol
   interactions for glaQueryRequest and glaQueryResponse.  Note that
   error messages are not shown.  Additionally, behavior for the
   optional transactionId, senderNonce, and recipientNonce CMC control
   attributes is not addressed in these procedures.

Top      Up      ToC       Page 71 
         +-----+   1    2  +------------------+
         | GLA | <-------> | GLO or GL Member |
         +-----+           +------------------+

   Figure 11 - GLA Query Request and Response

   The process for glaQueryRequest and glaQueryResponse is as follows:

   1 - The GLO, GL member, or prospective GL member sends a
       SignedData.PKIData.controlSequence.glaQueryRequest request to the
       GLA (1 in Figure 11).  The GLO, GL member, or prospective GL
       member indicates the information it is interested in receiving
       from the GLA.  Additionally, a signingTime attribute is included
       with this request.

     1.a - The GLO, GL member, or 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 GLO, GL member, or prospective GL member can also
           optionally apply another SignedData over the EnvelopedData
           (see Section 3.2.1.2).

   2 - Upon receipt of the glaQueryRequest, the GLA determines if it
       accepts glaQueryRequest messages.

     2.a - If the GLA does not accept glaQueryRequest messages, the GLA
           returns a cMCStatusInfoExt response indicating
           cMCStatus.noSupport and any other information in
           statusString.

     2.b - Else if the GLA does accept GLAQueryRequests, the GLA checks
           the signingTime and verifies the GLO, GL member, or
           prospective GL member signature(s).  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.b.1 - 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.

Top      Up      ToC       Page 72 
       2.b.2 - Else if the 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.b.3 - Else if the signatures verify, the GLA returns a
               glaQueryResponse (2 in Figure 11) with the correct
               response if the glaRequestType is supported or returns a
               cMCStatusInfoExt response indicating cMCStatus.noSupport
               if the glaRequestType is not supported.  Additionally, a
               signingTime attribute is included with the response.

         2.b.3.a - The GLA applies 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.b.3.b - The GLA can also optionally apply another SignedData
                   over the EnvelopedData (see Section 3.2.1.2).

   3 - Upon receipt of the glaQueryResponse, the GLO, GL member, or
       prospective GL member 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, GL member, or prospective GL member 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, GL member, or prospective GL
           member 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 not verify, the GLO, GL member, or prospective GL member
           returns a cMCStatusInfoExt response indicating
           cMCStatus.failed and otherInfo.failInfo.badMessageCheck.
           Additionally, a signingTime attribute is included with the
           response.

     3.c - Else if the signatures verify, then the GLO, GL member, or
           prospective GL member checks that one of the names in the
           certificate used to sign the response matches the name of the
           GL.

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

       3.c.2 - Else if the name of the GL matches the name present in
               the certificate and the response was glaQueryResponse,
               then the GLO, GL member, or prospective GL member may use
               the information contained therein.

4.10.  Update Member Certificate

   When the GLO generates a glAddMember request, when the GLA generates
   a glKey message, or when the GLA processes a glAddMember, there can
   be instances when the GL member's certificate has expired or is
   invalid.  In these instances, the GLO or GLA may request that the GL
   member provide a new certificate to avoid the GLA from being unable
   to generate a glKey message for the GL member.  There might also be
   times when the GL member knows that its certificate is about to
   expire or has been revoked, and GL member will not be able to receive
   GL rekeys.  Behavior for the optional transactionId, senderNonce, and
   recipientNonce CMC control attributes is not addressed in these
   procedures.

4.10.1.  GLO and GLA Initiated Update Member Certificate

   The process for GLO initiated glUpdateCert is as follows:

   1 - The GLO or GLA sends a
       SignedData.PKIData.controlSequence.glProvideCert request to the
       GL member.  The GLO or GLA indicates the GL name in glName and
       the GL member name in glMemberName.  Additionally, a signingTime
       attribute is included with this request.

     1.a - The GLO or GLA can optionally apply confidentiality to the
           request by encapsulating the SignedData.PKIData in an
           EnvelopedData (see Section 3.2.1.2).  If the GL member's PKC
           has been revoked, the GLO or GLA ought not use it to generate
           the EnvelopedData that encapsulates the glProvideCert
           request.

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

Top      Up      ToC       Page 74 
   2 - Upon receipt of the glProvideCert message, the GL member checks
       the signingTime and verifies the GLO or GLA signature(s).  If an
       additional SignedData and/or EnvelopedData encapsulates the
       response (see Section 3.2.1.2 or 3.2.2), the GL member 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 GL member 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 GL member 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 GL member generates a
           Signed.PKIResponse.controlSequence.glUpdateCert that includes
           the GL name in glName, the member's name in
           glMember.glMemberName, the member's encryption certificate in
           glMember.certificates.pKC.  The GL member can also include
           any attribute certificates associated with the member's
           encryption certificate in glMember.certificates.aC, and the
           certification path associated with the member's encryption
           and attribute certificates in glMember.certificates.certPath.
           Additionally, a signingTime attribute is included with the
           response.

       2.c.1 - The GL member can optionally apply confidentiality to the
               request by encapsulating the SignedData.PKIResponse in an
               EnvelopedData (see Section 3.2.1.2).  If the GL member's
               PKC has been revoked, the GL member ought not use it to
               generate the EnvelopedData that encapsulates the
               glProvideCert request.

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

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

Top      Up      ToC       Page 75 
     3.a - If the signingTime attribute value is not within the locally
           accepted time window, the GLO or GLA 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
           cannot be verified, the GLO or GLA returns a cMCStatusInfoExt
           response indicating cMCStatus.failed and
           otherInfo.failInfo.badMessageCheck.  Additionally, a
           signingTime attribute is included with the response.

     3.c - Else if the signatures verify, the GLO or GLA verifies the
           member's encryption certificate.

       3.c.1 - If the member's encryption certificate cannot be
               verified, the GLO returns either another glProvideCert
               request or a cMCStatusInfoExt with cMCStatus.failed and
               the reason why in cMCStatus.statusString. glProvideCert
               should be returned only a certain number of times is
               because if the GL member does not have a valid
               certificate it will never be able to return one.
               Additionally, a signingTime attribute is included with
               either response.

       3.c.2 - Else if the member's encryption certificate cannot be
               verified, the GLA returns another glProvideCert request
               to the GL member or a cMCStatusInfoExt with
               cMCStatus.failed and the reason why in
               cMCStatus.statusString to the GLO. glProvideCert should
               be returned only a certain number of times because if the
               GL member does not have a valid certificate it will never
               be able to return one.  Additionally, a signingTime
               attribute is included with the response.

       3.c.3 - Else if the member's encryption certificate verifies, the
               GLO or GLA will use it in subsequent glAddMember requests
               and glKey messages associated with the GL member.

4.10.2.  GL Member Initiated Update Member Certificate

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

   1 - The GL member sends a Signed.PKIData.controlSequence.glUpdateCert
       that includes the GL name in glName, the member's name in
       glMember.glMemberName, the member's encryption certificate in
       glMember.certificates.pKC.  The GL member can also include any
       attribute certificates associated with the member's encryption
       certificate in glMember.certificates.aC, and the certification

Top      Up      ToC       Page 76 
       path associated with the member's encryption and attribute
       certificates in glMember.certificates.certPath.  The GL member
       MUST also include a signingTime attribute with this request.

     1.a - The GL member can optionally apply confidentiality to the
           request by encapsulating the SignedData.PKIData in an
           EnvelopedData (see Section 3.2.1.2).  If the GL member's PKC
           has been revoked, the GLO or GLA ought not use it to generate
           the EnvelopedData that encapsulates the glProvideCert
           request.

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

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

     2.c - Else if the signatures verify, the GLA verifies the member's
           encryption certificate.

       2.c.1 - If the member's encryption certificate cannot be
               verified, the GLA returns another glProvideCert request
               to the GL member or a cMCStatusInfoExt with
               cMCStatus.failed and the reason why in
               cMCStatus.statusString to the GLO. glProvideCert ought
               not be returned indefinitely;  if the GL member does not
               have a valid certificate it will never be able to return
               one.  Additionally, a signingTime attribute is included
               with the response.

       2.c.2 - Else if the member's encryption certificate verifies, the
               GLA will use it in subsequent glAddMember requests and
               glKey messages associated with the GL member.  The GLA
               also forwards the glUpdateCert message to the GLO.

Top      Up      ToC       Page 77 
5.  Distribution Message

   The GLA uses the glKey message to distribute new, shared KEK(s) after
   receiving glAddMember, glDeleteMember (for closed and managed GLs),
   glRekey, glkCompromise, or glkRefresh requests and returning a
   cMCStatusInfoExt response for the respective request.  Figure 12
   depicts the protocol interactions to send out glKey messages.  Unlike
   the procedures defined for the administrative messages, the
   procedures defined in this section MUST be implemented by GLAs for
   origination and by GL members on reception.  Note that error messages
   are not shown.  Additionally, behavior for the optional
   transactionId, senderNonce, and recipientNonce CMC control attributes
   is not addressed in these procedures.

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

   Figure 12 - GL Key Distribution

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

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

     - glAddMember request,

     - glkComrpomise indication,

     - glkRefresh request,

     - glDeleteMember request with the GL's glAdministration set to
       managed or closed, and

     - glRekey request with generationCounter set to zero (0).

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

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

5.1.  Distribution Process

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

   1 - The GLA MUST send a SignedData.PKIData.controlSequence.glKey to
       each member by including glName, glIdentifier, glkWrapped,
       glkAlgorithm, glkNotBefore, and glkNotAfter.  If the GLA cannot
       generate a glKey message for the GL member because the GL
       member's PKC has expired or is otherwise invalid, the GLA MAY
       send a glUpdateCert to the GL member requesting a new certificate
       be provided (see Section 4.10).  The number of glKey messages
       generated for the GL is described in Section 3.1.13.
       Additionally, a signingTime attribute is included with the
       distribution message(s).

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

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

   2 - Upon receipt of the glKey message, the GL members MUST check the
       signingTime and verify the signature over the innermost
       SignedData.PKIData.  If an additional SignedData and/or
       EnvelopedData encapsulates the message (see Section 3.2.1.2 or
       3.2.2), the GL member MUST verify the outer signature and/or
       decrypt the outer layer prior to verifying the signature on the
       SignedData.PKIData.controlSequence.glKey.

     2.a - If the 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 GL member MUST return a
           cMCStatusInfoExt response indicating cMCStatus.failed and
           otherInfo.failInfo.badMessageCheck.  Additionally, a
           signingTime attribute is included with the response.

Top      Up      ToC       Page 79 
     2.c - Else if the signatures verify, the GL member processes the
           RecipientInfos according to [CMS].  Once unwrapped, the GL
           member should store the shared KEK in a safe place.  When
           stored, the glName, glIdentifier, and shared KEK should be
           associated.  Additionally, the GL member MUST return a
           cMCStatusInfoExt indicating cMCStatus.success to tell the GLA
           the KEK was received.



(page 79 continued on part 5)

Next RFC Part