RFC 5275
CMS Symmetric Key Management and Distribution
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.
- 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
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.
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).
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.
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.
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.
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).
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.
+-----+ 2{1} 4 +----------+ | GLO | <----------+ +-------> | Member 1 | +-----+ 5,3{1} | | +----------+ +-----+ <----------+ | 4 +----------+ | GLA | 1 +-------> | ... | +-----+ <---------------+ +----------+ | 4 +----------+ +-------> | Member n | +----------+ Figure 9 - GL Key Compromise4.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.
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.
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.
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.
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.
+-----+ 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.
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.
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).
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.
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
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.
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.
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.
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)
