RFC 5275
CMS Symmetric Key Management and Distribution
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.
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.
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.
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).
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.
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).
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
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
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).
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.
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.
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
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
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.
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.
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.
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
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.
+-----+ 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).
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.
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
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.
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.
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.
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.
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)
