draft-ietf-smime-symkeydist-10.txt   rfc5275.txt 
SMIME Working Group S. Turner, IECA
Internet Draft January 28, 2008
Intended Status: Standard Track
Expires: July 28, 2008
CMS Symmetric Key Management and Distribution
draft-ietf-smime-symkeydist-10.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Network Working Group S. Turner
and may be updated, replaced, or obsoleted by other documents at any Request for Comments: 5275 IECA
time. It is inappropriate to use Internet-Drafts as reference Category: Standards Track June 2008
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft will expire on July 28, 2008. CMS Symmetric Key Management and Distribution
Copyright Notice Status of This Memo
Copyright (C) The IETF Trust (2008). This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Abstract Abstract
This document describes a mechanism to manage (i.e., setup, This document describes a mechanism to manage (i.e., set up,
distribute, and rekey) keys used with symmetric cryptographic distribute, and rekey) keys used with symmetric cryptographic
algorithms. Also defined herein is a mechanism to organize users into algorithms. Also defined herein is a mechanism to organize users
groups to support distribution of encrypted content using symmetric into groups to support distribution of encrypted content using
cryptographic algorithms. The mechanism uses the Cryptographic symmetric cryptographic algorithms. The mechanism uses the
Message Syntax (CMS) protocol [CMS] and Certificate Management Cryptographic Message Syntax (CMS) protocol and Certificate
Message over CMS (CMC) protocol [CMC] to manage the symmetric keys. Management over CMS (CMC) protocol to manage the symmetric keys. Any
Any member of the group can then later use this distributed shared member of the group can then later use this distributed shared key to
key to decrypt other CMS encrypted objects with the symmetric key. decrypt other CMS encrypted objects with the symmetric key. This
mechanism has been developed to support Secure/Multipurpose Internet
This mechanism has been developed to support S/MIME Mail List Agents Mail Extensions (S/MIME) Mail List Agents (MLAs).
(MLAs).
Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
Table of Contents Table of Contents
1. Introduction...................................................3 1. Introduction ....................................................4
1.1. Applicability to E-mail...................................4 1.1. Conventions Used in This Document ..........................4
1.2. Applicability to Repositories.............................5 1.2. Applicability to E-mail ....................................5
1.3. Using the Group Key.......................................5 1.3. Applicability to Repositories ..............................5
2. Architecture...................................................5 1.4. Using the Group Key ........................................5
3. Protocol Interactions..........................................7 2. Architecture ....................................................6
3.1. Control Attributes........................................8 3. Protocol Interactions ...........................................7
3.1.1. GL USE KEK..........................................10 3.1. Control Attributes .........................................8
3.1.2. Delete GL...........................................13 3.1.1. GL Use KEK .........................................10
3.1.3. Add GL Member.......................................14 3.1.2. Delete GL ..........................................14
3.1.4. Delete GL Member....................................15 3.1.3. Add GL Member ......................................14
3.1.5. Rekey GL............................................15 3.1.4. Delete GL Member ...................................15
3.1.6. Add GL Owner........................................16 3.1.5. Rekey GL ...........................................16
3.1.7. Remove GL Owner.....................................17 3.1.6. Add GL Owner .......................................16
3.1.8. GL Key Compromise...................................17 3.1.7. Remove GL Owner ....................................17
3.1.9. GL Key Refresh......................................17 3.1.8. GL Key Compromise ..................................17
3.1.10. GLA Query Request and Response.....................18 3.1.9. GL Key Refresh .....................................18
3.1.10.1. GLA Query Request.............................18 3.1.10. GLA Query Request and Response ....................18
3.1.10.2. GLA Query Response............................18 3.1.10.1. GLA Query Request ........................18
3.1.10.3. Request and Response Types....................19 3.1.10.2. GLA Query Response .......................19
3.1.11. Provide Cert.......................................19 3.1.10.3. Request and Response Types ...............19
3.1.12. Update Cert........................................20 3.1.11. Provide Cert ......................................19
3.1.13. GL Key.............................................21 3.1.12. Update Cert .......................................20
3.2. Use of CMC, CMS, and PKIX................................23 3.1.13. GL Key ............................................21
3.2.1. Protection Layers...................................23 3.2. Use of CMC, CMS, and PKIX .................................23
3.2.1.1. Minimum Protection.............................23 3.2.1. Protection Layers ..................................23
3.2.1.2. Additional Protection..........................24 3.2.1.1. Minimum Protection ........................23
3.2.2. Combining Requests and Responses....................25 3.2.1.2. Additional Protection .....................24
3.2.3. GLA Generated Messages..............................26 3.2.2. Combining Requests and Responses ...................24
3.2.4. CMC Control Attributes and CMS Signed Attributes....27 3.2.3. GLA Generated Messages .............................26
3.2.4.1. Using cMCStatusInfoExt.........................27 3.2.4. CMC Control Attributes and CMS Signed Attributes ...27
3.2.4.2. Using transactionId............................30 3.2.4.1. Using cMCStatusInfoExt ....................27
3.2.4.3. Using nonces and signingTime...................30 3.2.4.2. Using transactionId .......................30
3.2.4.4. CMC and CMS Attribute Support Requirements.....31 3.2.4.3. Using Nonces and signingTime ..............30
3.2.5. Resubmitted GL Member Messages......................31 3.2.4.4. CMC and CMS Attribute Support
3.2.6. PKIX Certificate and CRL Profile....................32 Requirements ..............................31
3.2.5. Resubmitted GL Member Messages .....................31
4. Administrative Messages.......................................32 3.2.6. PKIX Certificate and CRL Profile ...................31
4.1. Assign KEK To GL.........................................32 4. Administrative Messages ........................................32
4.2. Delete GL From GLA.......................................36 4.1. Assign KEK to GL ..........................................32
4.3. Add Members To GL........................................38 4.2. Delete GL from GLA ........................................36
4.3.1. GLO Initiated Additions.............................40 4.3. Add Members to GL .........................................38
4.3.2. Prospective Member Initiated Additions..............46 4.3.1. GLO Initiated Additions ............................39
4.4. Delete Members From GL...................................49 4.3.2. Prospective Member Initiated Additions .............47
4.4.1. GLO Initiated Deletions.............................50 4.4. Delete Members from GL ....................................49
4.4.2. Member Initiated Deletions..........................55 4.4.1. GLO Initiated Deletions ............................50
4.5. Request Rekey Of GL......................................57 4.4.2. Member Initiated Deletions .........................56
4.5.1. GLO Initiated Rekey Requests........................58 4.5. Request Rekey of GL .......................................57
4.5.2. GLA Initiated Rekey Requests........................61 4.5.1. GLO Initiated Rekey Requests .......................59
4.6. Change GLO...............................................62 4.5.2. GLA Initiated Rekey Requests .......................62
4.7. Indicate KEK Compromise..................................64 4.6. Change GLO ................................................63
4.7.1. GL Member Initiated KEK Compromise Message..........65 4.7. Indicate KEK Compromise ...................................65
4.7.2. GLO Initiated KEK Compromise Message................66 4.7.1. GL Member Initiated KEK Compromise Message .........66
4.8. Request KEK Refresh......................................67 4.7.2. GLO Initiated KEK Compromise Message ...............67
4.9. GLA Query Request and Response...........................69 4.8. Request KEK Refresh .......................................69
4.10. Update Member Certificate...............................71 4.9. GLA Query Request and Response ............................70
4.10.1. GLO and GLA Initiated Update Member Certificate....72 4.10. Update Member Certificate ................................73
4.10.2. GL Member Initiated Update Member Certificate......74 4.10.1. GLO and GLA Initiated Update Member Certificate ...73
5. Distribution Message..........................................75 4.10.2. GL Member Initiated Update Member Certificate .....75
5.1. Distribution Process.....................................76 5. Distribution Message ...........................................77
6. Algorithms....................................................78 5.1. Distribution Process ......................................78
6.1. KEK Generation Algorithm.................................78 6. Algorithms .....................................................79
6.2. Shared KEK Wrap Algorithm................................78 6.1. KEK Generation Algorithm ..................................79
6.3. Shared KEK Algorithm.....................................78 6.2. Shared KEK Wrap Algorithm .................................79
7. Message Transport.............................................78 6.3. Shared KEK Algorithm ......................................79
8. Security Considerations.......................................78 7. Message Transport ..............................................80
9. IANA Considerations...........................................80 8. Security Considerations ........................................80
10. Acknowledgements.............................................80 9. Acknowledgements ...............................................81
11. References...................................................80 10. References ....................................................81
11.1. Normative References....................................80 10.1. Normative References .....................................81
11.2. Informative References..................................81 10.2. Informative References ...................................82
12. ASN.1 Module.................................................81 Appendix A. ASN.1 Module ..........................................83
1. Introduction 1. Introduction
With the ever-expanding use of secure electronic communications With the ever-expanding use of secure electronic communications
(e.g., S/MIME [MSG]), users require a mechanism to distribute (e.g., S/MIME [MSG]), users require a mechanism to distribute
encrypted data to multiple recipients (i.e., a group of users). There encrypted data to multiple recipients (i.e., a group of users).
are essentially two ways to encrypt the data for recipients: using There are essentially two ways to encrypt the data for recipients:
asymmetric algorithms with public key certificates (PKCs) or using asymmetric algorithms with public key certificates (PKCs) or
symmetric algorithms with symmetric keys. symmetric algorithms with symmetric keys.
With asymmetric algorithms, the originator forms an originator- With asymmetric algorithms, the originator forms an originator-
determined content-encryption key (CEK) and encrypts the content, determined content-encryption key (CEK) and encrypts the content,
using a symmetric algorithm. Then, using an asymmetric algorithm and using a symmetric algorithm. Then, using an asymmetric algorithm and
the recipient's PKCs, the originator generates per-recipient the recipient's PKCs, the originator generates per-recipient
information that either (a) encrypts the CEK for a particular information that either (a) encrypts the CEK for a particular
recipient (ktri RecipientInfo CHOICE), or (b) transfers sufficient recipient (ktri RecipientInfo CHOICE) or (b) transfers sufficient
parameters to enable a particular recipient to independently generate parameters to enable a particular recipient to independently generate
the same KEK (kari RecipientInfo CHOICE). If the group is large, the same KEK (kari RecipientInfo CHOICE). If the group is large,
processing of the per-recipient information may take quite some time, processing of the per-recipient information may take quite some time,
not to mention the time required to collect and validate the PKCs for not to mention the time required to collect and validate the PKCs for
each of the recipients. Each recipient identifies its per-recipient each of the recipients. Each recipient identifies its per-recipient
information and uses the private key associated with the public key information and uses the private key associated with the public key
of its PKC to decrypt the CEK and hence gain access to the encrypted of its PKC to decrypt the CEK and hence gain access to the encrypted
content. content.
With symmetric algorithms, the origination process is slightly With symmetric algorithms, the origination process is slightly
different. Instead of using PKCs, the originator uses a previously different. Instead of using PKCs, the originator uses a previously
distributed secret key-encryption key (KEK) to encrypt the CEK (kekri distributed secret key-encryption key (KEK) to encrypt the CEK (kekri
RecipientInfo CHOICE). Only one copy of the encrypted CEK is required RecipientInfo CHOICE). Only one copy of the encrypted CEK is
because all the recipients already have the shared KEK needed to required because all the recipients already have the shared KEK
decrypt the CEK and hence gain access to the encrypted content. needed to decrypt the CEK and hence gain access to the encrypted
content.
The techniques to protect the shared KEK are beyond the scope of this The techniques to protect the shared KEK are beyond the scope of this
document. Only the members of the list and the key manager should document. Only the members of the list and the key manager should
have the KEK in order to maintain confidentiality. Access control to have the KEK in order to maintain confidentiality. Access control to
the information protected by the KEK is determined by the entity that the information protected by the KEK is determined by the entity that
encrypts the information, as all members of the group have access. If encrypts the information, as all members of the group have access.
the entity that is performing the encryption wants to ensure some If the entity performing the encryption wants to ensure that some
subset of the group does not gain access to the information either a subset of the group does not gain access to the information, either a
different KEK should be used (shared only with this smaller group) or different KEK should be used (shared only with this smaller group) or
asymmetric algorithms should be used. asymmetric algorithms should be used.
1.1. Applicability to E-mail 1.1. Conventions Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14, RFC 2119
[RFC2119].
1.2. Applicability to E-mail
One primary audience for this distribution mechanism is e-mail. One primary audience for this distribution mechanism is e-mail.
Distribution lists, sometimes referred to as mail lists, support the Distribution lists, sometimes referred to as mail lists, support the
distribution of messages to recipients subscribed to the mail list. distribution of messages to recipients subscribed to the mail list.
There are two models for how the mail list can be used. If the There are two models for how the mail list can be used. If the
originator is a member of the mail list, the originator sends originator is a member of the mail list, the originator sends
messages encrypted with the shared KEK to the mail list (e.g., messages encrypted with the shared KEK to the mail list (e.g.,
listserv or majordomo) and the message is distributed to the mail listserv or majordomo) and the message is distributed to the mail
list members. If the originator is not a member of the mail list list members. If the originator is not a member of the mail list
(does not have the shared KEK), the originator sends the message (does not have the shared KEK), the originator sends the message
(encrypted for the MLA) to the mail list agent (MLA), and then the (encrypted for the MLA) to the Mail List Agent (MLA), and then the
MLA uses the shared KEK to encrypt the message for the members. In MLA uses the shared KEK to encrypt the message for the members. In
either case the recipients of the mail list use the previously either case, the recipients of the mail list use the previously
distributed-shared KEK to decrypt the message. distributed-shared KEK to decrypt the message.
1.2. Applicability to Repositories 1.3. Applicability to Repositories
Objects can also be distributed via a repository (e.g., Lightweight Objects can also be distributed via a repository (e.g., Lightweight
Directory Protocol (LDAP) servers, X.500 Directory System Agents Directory Access Protocol (LDAP) servers, X.500 Directory System
(DSAs), Web-based servers). If an object is stored in a repository Agents (DSAs), Web-based servers). If an object is stored in a
encrypted with a symmetric key algorithm, anyone with the shared KEK repository encrypted with a symmetric key algorithm, anyone with the
and access to that object can then decrypt that object. The encrypted shared KEK and access to that object can then decrypt that object.
object and the encrypted, shared KEK can be stored in the repository. The encrypted object and the encrypted, shared KEK can be stored in
the repository.
1.3. Using the Group Key 1.4. Using the Group Key
This document was written with three specific scenarios in mind: two This document was written with three specific scenarios in mind: two
supporting mail list agents and one for general message distribution. supporting Mail List Agents and one for general message distribution.
Scenario 1 depicts the originator sending a public key (PK) protected Scenario 1 depicts the originator sending a public key (PK) protected
message to a MLA who then uses the shared KEK(s) to redistribute the message to an MLA who then uses the shared KEK(s) to redistribute the
message to the members of the list. Scenario 2 depicts the originator message to the members of the list. Scenario 2 depicts the
sending a shared KEK protected message to a MLA who then originator sending a shared KEK protected message to an MLA who then
redistributes the message to the members of the list (the MLA only redistributes the message to the members of the list (the MLA only
adds additional recipients). The key used by the originator could adds additional recipients). The key used by the originator could be
either be a key shared amongst all recipients or just between the a key shared either amongst all recipients or just between the member
member and the MLA. Note that if the originator use a key shared only and the MLA. Note that if the originator uses a key shared only with
with the MLA, then the MLA will need to decrypt the message and the MLA, then the MLA will need to decrypt the message and reencrypt
rencrypt the message for the list recipients. Scenario 3 shows an the message for the list recipients. Scenario 3 shows an originator
originator sending a shared KEK protected message to a group of sending a shared KEK protected message to a group of recipients
recipients without an intermediate MLA. without an intermediate MLA.
+----> +----> +----> +----> +----> +---->
PK +-----+ S | S +-----+ S | S | PK +-----+ S | S +-----+ S | S |
----> | MLA | --+----> ----> | MLA | --+----> ----+----> ----> | MLA | --+----> ----> | MLA | --+----> ----+---->
+-----+ | +-----+ | | +-----+ | +-----+ | |
+----> +----> +----> +----> +----> +---->
Scenario 1 Scenario 2 Scenario 3
2. Architecture Scenario 1 Scenario 2 Scenario 3
2. Architecture
Figure 1 depicts the architecture to support symmetric key Figure 1 depicts the architecture to support symmetric key
distribution. The Group List Agent (GLA) supports two distinct distribution. The Group List Agent (GLA) supports two distinct
functions with two different agents: functions with two different agents:
- The Key Management Agent (KMA) which is responsible for generating - The Key Management Agent (KMA), which is responsible for
the shared KEKs. generating the shared KEKs.
- The Group Management Agent (GMA) which is responsible for managing - The Group Management Agent (GMA), which is responsible for
the Group List (GL) to which the shared KEKs are distributed. managing the Group List (GL) to which the shared KEKs are
distributed.
+----------------------------------------------+ +----------------------------------------------+
| Group List Agent | +-------+ | Group List Agent | +-------+
| +------------+ + -----------------------+ | | Group | | +------------+ + -----------------------+ | | Group |
| | Key | | Group Management Agent | |<-->| List | | | Key | | Group Management Agent | |<-->| List |
| | Management |<-->| +------------+ | | | Owner | | | Management |<-->| +------------+ | | | Owner |
| | Agent | | | Group List | | | +-------+ | | Agent | | | Group List | | | +-------+
| +------------+ | +------------+ | | | +------------+ | +------------+ | |
| | / | \ | | | | / | \ | |
| +------------------------+ | | +------------------------+ |
+----------------------------------------------+ +----------------------------------------------+
/ | \ / | \
/ | \ / | \
+----------+ +---------+ +----------+ +----------+ +---------+ +----------+
| Member 1 | | ... | | Member n | | Member 1 | | ... | | Member n |
+----------+ +---------+ +----------+ +----------+ +---------+ +----------+
Figure 1 - Key Distribution Architecture Figure 1 - Key Distribution Architecture
A GLA may support multiple KMAs. A GLA in general supports only one A GLA may support multiple KMAs. A GLA in general supports only one
GMA, but the GMA may support multiple GLs. Multiple KMAs may support GMA, but the GMA may support multiple GLs. Multiple KMAs may support
a GMA in the same fashion as GLAs support multiple KMAs. Assigning a a GMA in the same fashion as GLAs support multiple KMAs. Assigning a
particular KMA to a GL is beyond the scope of this document. particular KMA to a GL is beyond the scope of this document.
Modeling real world GL implementations shows that there are very Modeling real-world GL implementations shows that there are very
restrictive GLs, where a human determines GL membership, and very restrictive GLs, where a human determines GL membership, and very
open GLs, where there are no restrictions on GL membership. To open GLs, where there are no restrictions on GL membership. To
support this spectrum, the mechanism described herein supports both support this spectrum, the mechanism described herein supports both
managed (i.e., where access control is applied) and unmanaged (i.e., managed (i.e., where access control is applied) and unmanaged (i.e.,
where no access control is applied) GLs. The access control mechanism where no access control is applied) GLs. The access control
for managed lists is beyond the scope of this document. mechanism for managed lists is beyond the scope of this document.
Note: If the distribution for the list is performed by an entity Note: If the distribution for the list is performed by an entity
other than the originator (e.g., an MLA distributing a mail message), other than the originator (e.g., an MLA distributing a mail message),
this entity can also enforce access control rules. this entity can also enforce access control rules.
In either case, the GL must initially be constructed by an entity In either case, the GL must initially be constructed by an entity
hereafter called the Group List Owner (GLO). There may be multiple hereafter called the Group List Owner (GLO). There may be multiple
entities who 'own' the GL and who are allowed to make changes to the entities who 'own' the GL and who are allowed to make changes to the
GL's properties or membership. The GLO determines if the GL will be GL's properties or membership. The GLO determines if the GL will be
managed or unmanaged and is the only entity that may delete the GL. managed or unmanaged and is the only entity that may delete the GL.
GLO(s) may or may not be GL members. GLO(s) may also set up lists GLO(s) may or may not be GL members. GLO(s) may also set up lists
that are closed, where the GLO solely determines GL membership. that are closed, where the GLO solely determines GL membership.
Though Figure 1 depicts the GLA as encompassing both the KMA and GMA Though Figure 1 depicts the GLA as encompassing both the KMA and GMA
functions, the two functions could be supported by the same entity or functions, the two functions could be supported by the same entity or
they could be supported by two different entities. If two entities they could be supported by two different entities. If two entities
are used, they could be located on one or two platforms. There is are used, they could be located on one or two platforms. There is
however a close relationship between the KMA and GMA functions. If however a close relationship between the KMA and GMA functions. If
the GMA stores all information pertaining to the GLs and the KMA the GMA stores all information pertaining to the GLs and the KMA
merely generates keys, a corrupted GMA could cause havoc. To protect merely generates keys, a corrupted GMA could cause havoc. To protect
against a corrupted GMA, the KMA would be forced to double check the against a corrupted GMA, the KMA would be forced to double check the
requests it receives to ensure the GMA did not tamper with them. requests it receives to ensure that the GMA did not tamper with them.
These duplicative checks blur the functionality of the two components These duplicative checks blur the functionality of the two components
together. For this reason, the interactions between the KMA and GMA together. For this reason, the interactions between the KMA and GMA
are beyond the scope of this document. are beyond the scope of this document.
Proprietary mechanisms may be used to separate the functions by Proprietary mechanisms may be used to separate the functions by
strengthening the trust relationship between the two entities. strengthening the trust relationship between the two entities.
Henceforth, the distinction between the two agents is not discussed Henceforth, the distinction between the two agents is not discussed
further; the term GLA will be used to address both functions. It further; the term GLA will be used to address both functions. It
should be noted that corrupt GLA can always cause havoc. should be noted that a corrupt GLA can always cause havoc.
3. Protocol Interactions 3. Protocol Interactions
There are existing mechanisms (e.g., listserv and majordomo) to There are existing mechanisms (e.g., listserv and majordomo) to
manage GLs; however, this document does not address securing these manage GLs; however, this document does not address securing these
mechanisms, as they are not standardized. Instead, it defines mechanisms, as they are not standardized. Instead, it defines
protocol interactions, as depicted in Figure 2, used by the GL protocol interactions, as depicted in Figure 2, used by the GL
members, GLA, and GLO(s) to manage GLs and distribute shared KEKs. members, GLA, and GLO(s) to manage GLs and distribute shared KEKs.
The interactions have been divided into administration messages and The interactions have been divided into administration messages and
distribution messages. The administrative messages are the request distribution messages. The administrative messages are the request
and response messages needed to setup the GL, delete the GL, add and response messages needed to set up the GL, delete the GL, add
members to the GL, delete members of the GL, request a group rekey, members to the GL, delete members of the GL, request a group rekey,
add owners to the GL, remove owners of the GL, indicate a group key add owners to the GL, remove owners of the GL, indicate a group key
compromise, refresh a group key, interrogate the GLA, and update compromise, refresh a group key, interrogate the GLA, and update
member's and owner's public key certificates. The distribution members' and owners' public key certificates. The distribution
messages are the messages that distribute the shared KEKs. The messages are the messages that distribute the shared KEKs. The
following sections describe the ASN.1 for both the administration and following sections describe the ASN.1 for both the administration and
distribution messages. Section 4 describes how to use the distribution messages. Section 4 describes how to use the
administration messages, and section 5 describes how to use the administration messages, and Section 5 describes how to use the
distribution messages. distribution messages.
+-----+ +----------+ +-----+ +----------+
| GLO | <---+ +----> | Member 1 | | GLO | <---+ +----> | Member 1 |
+-----+ | | +----------+ +-----+ | | +----------+
| | | |
+-----+ <------+ | +----------+ +-----+ <------+ | +----------+
| GLA | <-------------+----> | ... | | GLA | <-------------+----> | ... |
+-----+ | +----------+ +-----+ | +----------+
| |
| +----------+ | +----------+
+----> | Member n | +----> | Member n |
+----------+ +----------+
Figure 2 - Protocol Interactions Figure 2 - Protocol Interactions
3.1. Control Attributes 3.1. Control Attributes
To avoid creating an entirely new protocol, the Certificate To avoid creating an entirely new protocol, the Certificate
Management Messages over CMS (CMC) protocol was chosen as the Management over CMS (CMC) protocol was chosen as the foundation of
foundation of this protocol. The main reason for the choice was the this protocol. The main reason for the choice was the layering
layering aspect provided by CMC where one or more control attributes aspect provided by CMC where one or more control attributes are
are included in message, protected with CMS, to request or respond to included in message, protected with CMS, to request or respond to a
a desired action. The CMC PKIData structure is used for requests, and desired action. The CMC PKIData structure is used for requests, and
the CMC PKIResponse structure is used for responses. The content- the CMC PKIResponse structure is used for responses. The content-
types PKIData and PKIResponse are then encapsulated in CMS's types PKIData and PKIResponse are then encapsulated in CMS's
SignedData or EnvelopedData, or a combination of the two (see section SignedData or EnvelopedData, or a combination of the two (see Section
3.2). The following are the control attributes defined in this 3.2). The following are the control attributes defined in this
document: document:
Control Control
Attribute OID Syntax Attribute OID Syntax
------------------- ----------- ----------------- ------------------- ----------- -----------------
glUseKEK id-skd 1 GLUseKEK glUseKEK id-skd 1 GLUseKEK
glDelete id-skd 2 GeneralName glDelete id-skd 2 GeneralName
glAddMember id-skd 3 GLAddMember glAddMember id-skd 3 GLAddMember
glDeleteMember id-skd 4 GLDeleteMember glDeleteMember id-skd 4 GLDeleteMember
glRekey id-skd 5 GLRekey glRekey id-skd 5 GLRekey
glAddOwner id-skd 6 GLOwnerAdministration glAddOwner id-skd 6 GLOwnerAdministration
glRemoveOwner id-skd 7 GLOwnerAdministration glRemoveOwner id-skd 7 GLOwnerAdministration
glkCompromise id-skd 8 GeneralName glkCompromise id-skd 8 GeneralName
glkRefresh id-skd 9 GLKRefresh glkRefresh id-skd 9 GLKRefresh
glaQueryRequest id-skd 11 GLAQueryRequest glaQueryRequest id-skd 11 GLAQueryRequest
glaQueryResponse id-skd 12 GLAQueryResponse glaQueryResponse id-skd 12 GLAQueryResponse
glProvideCert id-skd 13 GLManageCert glProvideCert id-skd 13 GLManageCert
glUpdateCert id-skd 14 GLManageCert glUpdateCert id-skd 14 GLManageCert
glKey id-skd 15 GLKey glKey id-skd 15 GLKey
In the following conformance tables, the column headings have the In the following conformance tables, the column headings have the
following meanings: O for originate, R for receive, and F for following meanings: O for originate, R for receive, and F for
forward. There are three types of implementations: GLOs, GLAs, and GL forward. There are three types of implementations: GLOs, GLAs, and
members. The GLO is an optional component hence all GLO O and GLO R GL members. The GLO is an optional component, hence all GLO O and
messages are optional, and GLA F messages are optional. The first GLO R messages are optional, and GLA F messages are optional. The
table includes messages that conformant implementions MUST support. first table includes messages that conformant implementations MUST
The second table includes messages that MAY be implemented. The support. The second table includes messages that MAY be implemented.
second table should be interpreted as follows: if the control The second table should be interpreted as follows: if the control
attribute is implemented by a component then it must be implemented attribute is implemented by a component, then it must be implemented
as indicated. For example, if a GLA is implemented that supports the as indicated. For example, if a GLA is implemented that supports the
glAddMember control attribute, then it MUST support receiving the glAddMember control attribute, then it MUST support receiving the
glAddMember message. Note that "-" means not applicable. glAddMember message. Note that "-" means not applicable.
Required
Implementation Requirement | Control
GLO | GLA | GL Member | Attribute
O R | O R F | O R |
------- | ----------------- | --------- | ----------
MAY - | MUST - MAY | - MUST | glProvideCert
MAY MAY | - MUST MAY | MUST - | glUpdateCert
- - | MUST - - | - MUST | glKey
Optional Required
Implementation Requirement | Control Implementation Requirement | Control
GLO | GLA | GL Member | Attribute GLO | GLA | GL Member | Attribute
O R | O R F | O R | O R | O R F | O R |
------- | ----------------- | --------- | ---------- ------- | ----------------- | --------- | ----------
MAY - | - MAY - | - - | glUseKEK MAY - | MUST - MAY | - MUST | glProvideCert
MAY - | - MAY - | - - | glDelete MAY MAY | - MUST MAY | MUST - | glUpdateCert
MAY MAY | - MUST MAY | MUST - | glAddMember - - | MUST - - | - MUST | glKey
MAY MAY | - MUST MAY | MUST - | glDeleteMember Optional
MAY - | - MAY - | - - | glRekey Implementation Requirement | Control
MAY - | - MAY - | - - | glAddOwner GLO | GLA | GL Member | Attribute
MAY - | - MAY - | - - | glRemoveOwner O R | O R F | O R |
MAY MAY | - MUST MAY | MUST - | glkCompromise ------- | ----------------- | --------- | ----------
MAY - | - MUST - | MUST - | glkRefresh MAY - | - MAY - | - - | glUseKEK
MAY - | - SHOULD - | MAY - | glaQueryRequest MAY - | - MAY - | - - | glDelete
- MAY | SHOULD - - | - MAY | glaQueryResponse MAY MAY | - MUST MAY | MUST - | glAddMember
MAY MAY | - MUST MAY | MUST - | glDeleteMember
MAY - | - MAY - | - - | glRekey
MAY - | - MAY - | - - | glAddOwner
MAY - | - MAY - | - - | glRemoveOwner
MAY MAY | - MUST MAY | MUST - | glkCompromise
MAY - | - MUST - | MUST - | glkRefresh
MAY - | - SHOULD - | MAY - | glaQueryRequest
- MAY | SHOULD - - | - MAY | glaQueryResponse
glaQueryResponse and gloResponse are carried in the CMC PKIResponse glaQueryResponse is carried in the CMC PKIResponse content-type, all
content-type, all other control attributes are carried in the CMC other control attributes are carried in the CMC PKIData content-type.
PKIData content-type. The exception is glUpdateCert which can be The exception is glUpdateCert, which can be carried in either PKIData
carried in either PKIData or PKIResponse. or PKIResponse.
Success and failure messages use CMC (see section 3.2.4). Success and failure messages use CMC (see Section 3.2.4).
3.1.1. GL USE KEK 3.1.1. GL Use KEK
The GLO uses glUseKEK to request that a shared KEK be assigned to a The GLO uses glUseKEK to request that a shared KEK be assigned to a
GL. glUseKEK messages MUST be signed by the GLO. The glUseKEK control GL. glUseKEK messages MUST be signed by the GLO. The glUseKEK
attribute has the syntax GLUseKEK: control attribute has the syntax GLUseKEK:
GLUseKEK ::= SEQUENCE { GLUseKEK ::= SEQUENCE {
glInfo GLInfo, glInfo GLInfo,
glOwnerInfo SEQUENCE SIZE (1..MAX) OF GLOwnerInfo, glOwnerInfo SEQUENCE SIZE (1..MAX) OF GLOwnerInfo,
glAdministration GLAdministration DEFAULT 1, glAdministration GLAdministration DEFAULT 1,
glKeyAttributes GLKeyAttributes OPTIONAL } glKeyAttributes GLKeyAttributes OPTIONAL }
GLInfo ::= SEQUENCE { GLInfo ::= SEQUENCE {
glName GeneralName, glName GeneralName,
glAddress GeneralName } glAddress GeneralName }
GLOwnerInfo ::= SEQUENCE { GLOwnerInfo ::= SEQUENCE {
glOwnerName GeneralName, glOwnerName GeneralName,
glOwnerAddress GeneralName, glOwnerAddress GeneralName,
certificate Certificates OPTIONAL } certificate Certificates OPTIONAL }
Certificates ::= SEQUENCE { Certificates ::= SEQUENCE {
pKC [0] Certificate OPTIONAL, pKC [0] Certificate OPTIONAL,
-- See [PROFILE] -- See [PROFILE]
aC [1] SEQUENCE SIZE (1.. MAX) OF aC [1] SEQUENCE SIZE (1.. MAX) OF
AttributeCertificate OPTIONAL, AttributeCertificate OPTIONAL,
-- See [ACPROF] -- See [ACPROF]
certPath [2] CertificateSet OPTIONAL } certPath [2] CertificateSet OPTIONAL }
-- From [CMS] -- From [CMS]
-- CertificateSet and CertificateChoices are included only -- CertificateSet and CertificateChoices are included only
-- for illustrative purposes as they are imported from [CMS]. -- for illustrative purposes as they are imported from [CMS].
CertificateSet ::= SET SIZE (1..MAX) OF CertificateChoices CertificateSet ::= SET SIZE (1..MAX) OF CertificateChoices
-- CertificateChoices supports X.509 public key certificates in -- CertificateChoices supports X.509 public key certificates in
-- certificates and v2 attribute certificates in v2AttrCert. -- certificates and v2 attribute certificates in v2AttrCert.
GLAdministration ::= INTEGER { GLAdministration ::= INTEGER {
unmanaged (0), unmanaged (0),
managed (1), managed (1),
closed (2) } closed (2) }
GLKeyAttributes ::= SEQUENCE { GLKeyAttributes ::= SEQUENCE {
rekeyControlledByGLO [0] BOOLEAN DEFAULT FALSE, rekeyControlledByGLO [0] BOOLEAN DEFAULT FALSE,
recipientsNotMutuallyAware [1] BOOLEAN DEFAULT TRUE, recipientsNotMutuallyAware [1] BOOLEAN DEFAULT TRUE,
duration [2] INTEGER DEFAULT 0, duration [2] INTEGER DEFAULT 0,
generationCounter [3] INTEGER DEFAULT 2, generationCounter [3] INTEGER DEFAULT 2,
requestedAlgorithm [4] AlgorithmIdentifier requestedAlgorithm [4] AlgorithmIdentifier
DEFAULT { id-aes128-wrap } } DEFAULT { id-aes128-wrap } }
The fields in GLUseKEK have the following meaning: The fields in GLUseKEK have the following meaning:
- glInfo indicates the name of the GL in glName and the address of - glInfo indicates the name of the GL in glName and the address of
the GL in glAddress. The glName and glAddress can be the same, the GL in glAddress. The glName and glAddress can be the same,
but this is not always the case. Both the name and address MUST but this is not always the case. Both the name and address MUST
be unique for a given GLA. be unique for a given GLA.
- glOwnerInfo indicates: - glOwnerInfo indicates:
-- glOwnerName indicates the name of the owner of the GL. One of -- glOwnerName indicates the name of the owner of the GL. One
the names in glOwnerName MUST match one of the names in the of the names in glOwnerName MUST match one of the names in
certificate (either the subject distinguished name or one of the certificate (either the subject distinguished name or one
the subject alternative names) used to sign this of the subject alternative names) used to sign this
SignedData.PKIData creating the GL (i.e., the immediate SignedData.PKIData creating the GL (i.e., the immediate
signer). signer).
-- glOwnerAddress indicates the address of the owner of the GL. -- glOwnerAddress indicates the GL owner's address.
-- certificates MAY be included. It contains the following three -- certificates MAY be included. It contains the following
fields: three fields:
--- certificates.pKC includes the encryption certificate for --- certificates.pKC includes the encryption certificate for
the GLO. It will be used to encrypt responses for the the GLO. It will be used to encrypt responses for the
GLO. GLO.
--- certificates.aC MAY be included to convey any attribute --- certificates.aC MAY be included to convey any attribute
certificate (see [ACPROF]) associated with the certificate (see [ACPROF]) associated with the
encryption certificate of the GLO included in encryption certificate of the GLO included in
certificates.pKC. certificates.pKC.
--- certificates.certPath MAY also be included to convey --- certificates.certPath MAY also be included to convey
certificates that might aid the recipient in certificates that might aid the recipient in
constructing valid certification paths for the constructing valid certification paths for the
certificate provided in certificates.pKC and the certificate provided in certificates.pKC and the
attribute certificates provided in certificates.aC. attribute certificates provided in certificates.aC.
Theses certificates are optional because they might Theses certificates are optional because they might
already be included elsewhere in the message (e.g., in already be included elsewhere in the message (e.g., in
the outer CMS layer). the outer CMS layer).
-- glAdministration indicates how the GL ought to be -- glAdministration indicates how the GL ought to be
administered. The default is for the list to be managed. administered. The default is for the list to be managed.
Three values are supported for glAdministration: Three values are supported for glAdministration:
--- Unmanaged - When the GLO sets glAdministration to --- Unmanaged - When the GLO sets glAdministration to
unmanaged, it is allowing prospective members to unmanaged, it is allowing prospective members to request
request addition and deletion from the GL without GLO addition and deletion from the GL without GLO
intervention. intervention.
--- Managed - When the GLO sets glAdministration to managed, --- Managed - When the GLO sets glAdministration to managed,
it is allowing prospective members to request addition it is allowing prospective members to request addition
and deletion from the GL, but the request is redirected and deletion from the GL, but the request is redirected
by the GLA to GLO for review. The GLO makes the by the GLA to GLO for review. The GLO makes the
determination as to whether to honor the request. determination as to whether to honor the request.
--- Closed - When the GLO sets glAdministration to closed, --- Closed - When the GLO sets glAdministration to closed,
it is not allowing prospective members to request it is not allowing prospective members to request
addition or deletion from the GL. The GLA will only addition or deletion from the GL. The GLA will only
accept glAddMember and glDeleteMember requests from the accept glAddMember and glDeleteMember requests from the
GLO. GLO.
-- glKeyAttributes indicates the attributes the GLO wants the -- glKeyAttributes indicates the attributes the GLO wants the
GLA to assign to the shared KEK. If this field is omitted, GLA to assign to the shared KEK. If this field is omitted,
GL rekeys will be controlled by the GLA, the recipients are GL rekeys will be controlled by the GLA, the recipients are
allowed to know about one another, the algorithm will be allowed to know about one another, the algorithm will be
Triple-DES (see paragrpah 7), the shared KEK will be valid AES-128 (see Section 7), the shared KEK will be valid for a
for a calendar month (i.e., first of the month until the calendar month (i.e., first of the month until the last day
last day of the month), and two shared KEKs will be of the month), and two shared KEKs will be distributed
distributed initially. The fields in glKeyAttributes have initially. The fields in glKeyAttributes have the following
the following meaning: meaning:
--- rekeyControlledByGLO indicates whether the GL rekey --- rekeyControlledByGLO indicates whether the GL rekey
messages will be generated by the GLO or by the GLA. messages will be generated by the GLO or by the GLA.
The default is for the GLA to control rekeys. If GL The default is for the GLA to control rekeys. If GL
rekey is controlled by the GLA, the GL will continue to rekey is controlled by the GLA, the GL will continue to
be rekeyed until the GLO deletes the GL or changes the be rekeyed until the GLO deletes the GL or changes the
GL rekey to be GLO controlled. GL rekey to be GLO controlled.
--- recipientsNotMutuallyAware indicates that the GLO wants --- recipientsNotMutuallyAware indicates that the GLO wants
the GLA to distribute the shared KEK individually for the GLA to distribute the shared KEK individually for
each of the GL members (i.e., a separate glKey message each of the GL members (i.e., a separate glKey message
is sent to each recipient). The default is for separate is sent to each recipient). The default is for separate
glKey message not to be required. glKey message not to be required.
NOTE: This supports lists where one member does not Note: This supports lists where one member does not know
know the identities of the other members. For example, the identities of the other members. For example, a
a list is configured granting submit permissions to list is configured granting submit permissions to only
only one member. All other members are 'listening.' The one member. All other members are 'listening'. The
security policy of the list does not allow the members security policy of the list does not allow the members
to know who else is on the list. If a glKey is to know who else is on the list. If a glKey is
constructed for all of the GL members, information constructed for all of the GL members, information about
about each of the members may be derived from the each of the members may be derived from the information
information in RecipientInfos. To make sure the glkey in RecipientInfos.
message does not divulge information about the other
recipients, a separate glKey message would be sent to To make sure the glkey message does not divulge
each GL member. information about the other recipients, a separate glKey
message would be sent to each GL member.
--- duration indicates the length of time (in days) during --- duration indicates the length of time (in days) during
which the shared KEK is considered valid. The value which the shared KEK is considered valid. The value
zero (0) indicates that the shared KEK is valid for a zero (0) indicates that the shared KEK is valid for a
calendar month in the UTC Zulu time zone. For example calendar month in the UTC Zulu time zone. For example,
if the duration is zero (0), if the GL shared KEK is if the duration is zero (0), if the GL shared KEK is
requested on July 24, the first key will be valid until requested on July 24, the first key will be valid until
the end of July and the next key will be valid for the the end of July and the next key will be valid for the
entire month of August. If the value is not zero (0), entire month of August. If the value is not zero (0),
the shared KEK will be valid for the number of days the shared KEK will be valid for the number of days
indicated by the value. For example, if the value of indicated by the value. For example, if the value of
duration is seven (7) and the shared KEK is requested duration is seven (7) and the shared KEK is requested on
on Monday but not generated until Tuesday (2359); the Monday but not generated until Tuesday (13 May 2008);
shared KEKs will be valid from Tuesday (2359) to the shared KEKs will be valid from Tuesday (13 May 2008)
Tuesday (2359). The exact time of the day is determined to Tuesday (20 May 2008). The exact time of the day is
when the key is generated. determined when the key is generated.
--- generationCounter indicates the number of keys the GLO --- generationCounter indicates the number of keys the GLO
wants the GLA to distribute. To ensure uninterrupted wants the GLA to distribute. To ensure uninterrupted
function of the GL two (2) shared KEKs at a minimum function of the GL, two (2) shared KEKs at a minimum
MUST be initially distributed. The second shared KEK is MUST be initially distributed. The second shared KEK is
distributed with the first shared KEK, so that when the distributed with the first shared KEK, so that when the
first shared KEK is no longer valid the second key can first shared KEK is no longer valid the second key can
be used. If the GLA controls rekey then it also be used. If the GLA controls rekey, then it also
indicates the number of shared KEKs the GLO wants indicates the number of shared KEKs the GLO wants
outstanding at any one time. See sections 4.5 and 5 for outstanding at any one time. See Sections 4.5 and 5 for
more on rekey. more on rekey.
--- requestedAlgorithm indicates the algorithm and any --- requestedAlgorithm indicates the algorithm and any
parameters the GLO wants the GLA to use with the shared parameters the GLO wants the GLA to use with the shared
KEK. The parameters are conveyed via the KEK. The parameters are conveyed via the
SMIMECapabilities attribute (see [MSG]). See section 6 SMIMECapabilities attribute (see [MSG]). See Section 6
for more on algorithms. for more on algorithms.
3.1.2. Delete GL 3.1.2. Delete GL
GLOs use glDelete to request that a GL be deleted from the GLA. The GLOs use glDelete to request that a GL be deleted from the GLA. The
glDelete control attribute has the syntax GeneralName. The glDelete glDelete control attribute has the syntax GeneralName. The glDelete
message MUST be signed by the GLO. The name of the GL to be deleted message MUST be signed by the GLO. The name of the GL to be deleted
is included in GeneralName: is included in GeneralName:
DeleteGL ::= GeneralName DeleteGL ::= GeneralName
3.1.3. Add GL Member 3.1.3. Add GL Member
GLOs use the glAddMember to request addition of new members, and GLOs use the glAddMember to request addition of new members, and
prospective GL members use the glAddMember to request their own prospective GL members use the glAddMember to request their own
addition to the GL. The glAddMember message MUST be signed by either addition to the GL. The glAddMember message MUST be signed by either
the GLO or the prospective GL member. The glAddMember control the GLO or the prospective GL member. The glAddMember control
attribute has the syntax GLAddMember: attribute has the syntax GLAddMember:
GLAddMember ::= SEQUENCE { GLAddMember ::= SEQUENCE {
glName GeneralName, glName GeneralName,
glMember GLMember } glMember GLMember }
GLMember ::= SEQUENCE { GLMember ::= SEQUENCE {
glMemberName GeneralName, glMemberName GeneralName,
glMemberAddress GeneralName OPTIONAL, glMemberAddress GeneralName OPTIONAL,
certificates Certificates OPTIONAL } certificates Certificates OPTIONAL }
The fields in GLAddMembers have the following meaning: The fields in GLAddMembers have the following meaning:
- glName indicates the name of the GL to which the member should be - glName indicates the name of the GL to which the member should be
added. added.
- glMember indicates the particulars for the GL member. Both of the - glMember indicates the particulars for the GL member. Both of
following fields must be unique for a given GL: the following fields must be unique for a given GL:
-- glMemberName indicates the name of the GL member. -- glMemberName indicates the name of the GL member.
-- glMemberAddress indicates the GL member's address. It MUST be -- glMemberAddress indicates the GL member's address. It MUST
included. be included.
Note: In some instances the glMemberName and glMemberAddress Note: In some instances, the glMemberName and glMemberAddress
may be the same, but this is not always the case. may be the same, but this is not always the case.
-- certificates MUST be included. It contains the following three -- certificates MUST be included. It contains the following
fields: three fields:
--- certificates.pKC includes the member's encryption --- certificates.pKC includes the member's encryption
certificate. It will be used, at least initially, to certificate. It will be used, at least initially, to
encrypt the shared KEK for that member. If the message is encrypt the shared KEK for that member. If the message
generated by a prospective GL member, the pKC MUST be is generated by a prospective GL member, the pKC MUST be
included. If the message is generated by a GLO, the pKC included. If the message is generated by a GLO, the pKC
SHOULD be included. SHOULD be included.
--- certificates.aC MAY be included to convey any attribute --- certificates.aC MAY be included to convey any attribute
certificate (see [ACPROF]) associated with the member's certificate (see [ACPROF]) associated with the member's
encryption certificate. encryption certificate.
--- certificates.certPath MAY also be included to convey --- certificates.certPath MAY also be included to convey
certificates that might aid the recipient in constructing certificates that might aid the recipient in
valid certification paths for the certificate provided in constructing valid certification paths for the
certificates.pKC and the attribute certificates provided certificate provided in certificates.pKC and the
in certificates.aC. These certificates are optional attribute certificates provided in certificates.aC.
because they might already be included elsewhere in the These certificates are optional because they might
message (e.g., in the outer CMS layer). already be included elsewhere in the message (e.g., in
the outer CMS layer).
3.1.4. Delete GL Member 3.1.4. Delete GL Member
GLOs use the glDeleteMember to request deletion of GL members, and GL GLOs use the glDeleteMember to request deletion of GL members, and GL
members use the glDeleteMember to request their own removal from the members use the glDeleteMember to request their own removal from the
GL. The glDeleteMember message MUST be signed by either the GLO or GL. The glDeleteMember message MUST be signed by either the GLO or
the GL member. The glDeleteMember control attribute has the syntax the GL member. The glDeleteMember control attribute has the syntax
GLDeleteMember: GLDeleteMember:
GLDeleteMember ::= SEQUENCE { GLDeleteMember ::= SEQUENCE {
glName GeneralName, glName GeneralName,
glMemberToDelete GeneralName } glMemberToDelete GeneralName }
The fields in GLDeleteMembers have the following meaning: The fields in GLDeleteMembers have the following meaning:
- glName indicates the name of the GL from which the member should - glName indicates the name of the GL from which the member should
be removed. be removed.
- glMemberToDelete indicates the name or address of the member to - glMemberToDelete indicates the name or address of the member to
be deleted. be deleted.
3.1.5. Rekey GL 3.1.5. Rekey GL
GLOs use the glRekey to request a GL rekey. The glRekey message MUST GLOs use the glRekey to request a GL rekey. The glRekey message MUST
be signed by the GLO. The glRekey control attribute has the syntax be signed by the GLO. The glRekey control attribute has the syntax
GLRekey: GLRekey:
GLRekey ::= SEQUENCE { GLRekey ::= SEQUENCE {
glName GeneralName, glName GeneralName,
glAdministration GLAdministration OPTIONAL, glAdministration GLAdministration OPTIONAL,
glNewKeyAttributes GLNewKeyAttributes OPTIONAL, glNewKeyAttributes GLNewKeyAttributes OPTIONAL,
glRekeyAllGLKeys BOOLEAN OPTIONAL } glRekeyAllGLKeys BOOLEAN OPTIONAL }
GLNewKeyAttributes ::= SEQUENCE { GLNewKeyAttributes ::= SEQUENCE {
rekeyControlledByGLO [0] BOOLEAN OPTIONAL, rekeyControlledByGLO [0] BOOLEAN OPTIONAL,
recipientsNotMutuallyAware [1] BOOLEAN OPTIONAL, recipientsNotMutuallyAware [1] BOOLEAN OPTIONAL,
duration [2] INTEGER OPTIONAL, duration [2] INTEGER OPTIONAL,
generationCounter [3] INTEGER OPTIONAL, generationCounter [3] INTEGER OPTIONAL,
requestedAlgorithm [4] AlgorithmIdentifier OPTIONAL } requestedAlgorithm [4] AlgorithmIdentifier OPTIONAL }
The fields in GLRekey have the following meaning: The fields in GLRekey have the following meaning:
- glName indicates the name of the GL to be rekeyed. - glName indicates the name of the GL to be rekeyed.
- glAdministration indicates if there is any change to how the GL - glAdministration indicates if there is any change to how the GL
should be administered. See section 3.1.1 for the three options. should be administered. See Section 3.1.1 for the three options.
This field is only included if there is a change from the This field is only included if there is a change from the
previously registered administered. previously registered glAdministration.
- glNewKeyAttributes indicates whether the rekey of the GLO is - glNewKeyAttributes indicates whether the rekey of the GLO is
controlled by the GLA or GL, what algorithm and parameters the controlled by the GLA or GL, what algorithm and parameters the
GLO wishes to use, the duration of the key, and how many keys GLO wishes to use, the duration of the key, and how many keys
will be issued. The field is only included if there is a change will be issued. The field is only included if there is a change
from the previously registered glKeyAttributes. from the previously registered glKeyAttributes.
- glRekeyAllGLKeys indicates whether the GLO wants all of the - glRekeyAllGLKeys indicates whether the GLO wants all of the
outstanding GL's shared KEKs rekeyed. If it is set to TRUE then outstanding GL's shared KEKs rekeyed. If it is set to TRUE then
all outstanding KEKs MUST be issued. If it is set to FALSE then all outstanding KEKs MUST be issued. If it is set to FALSE then
all outstanding KEKs need not be resissued. all outstanding KEKs need not be reissued.
3.1.6. Add GL Owner 3.1.6. Add GL Owner
GLOs use the glAddOwner to request that a new GLO be allowed to GLOs use the glAddOwner to request that a new GLO be allowed to
administer the GL. The glAddOwner message MUST be signed by a administer the GL. The glAddOwner message MUST be signed by a
registered GLO. The glAddOwner control attribute has the syntax registered GLO. The glAddOwner control attribute has the syntax
GLOwnerAdministration: GLOwnerAdministration:
GLOwnerAdministration ::= SEQUENCE { GLOwnerAdministration ::= SEQUENCE {
glName GeneralName, glName GeneralName,
glOwnerInfo GLOwnerInfo } glOwnerInfo GLOwnerInfo }
The fields in GLAddOwners have the following meaning: The fields in GLAddOwners have the following meaning:
- glName indicates the name of the GL to which the new GLO should - glName indicates the name of the GL to which the new GLO should
be associated. be associated.
- glOwnerInfo indicates the name, address, and certificates of the - glOwnerInfo indicates the name, address, and certificates of the
new GLO. As this message includes names of new GLOs, the new GLO. As this message includes names of new GLOs, the
certificates.pKC MUST be included, and it MUST include the certificates.pKC MUST be included, and it MUST include the
encryption certificate of the new GLO. encryption certificate of the new GLO.
3.1.7. Remove GL Owner 3.1.7. Remove GL Owner
GLOs use the glRemoveOwner to request that a GLO be disassociated GLOs use the glRemoveOwner to request that a GLO be disassociated
with the GL. The glRemoveOwner message MUST be signed by a registered with the GL. The glRemoveOwner message MUST be signed by a
GLO. The glRemoveOwner control attribute has the syntax registered GLO. The glRemoveOwner control attribute has the syntax
GLOwnerAdministration: GLOwnerAdministration:
GLOwnerAdministration ::= SEQUENCE { GLOwnerAdministration ::= SEQUENCE {
glName GeneralName, glName GeneralName,
glOwnerInfo GLOwnerInfo } glOwnerInfo GLOwnerInfo }
The fields in GLRemoveOwners have the following meaning: The fields in GLRemoveOwners have the following meaning:
- glName indicates the name of the GL to which the GLO should be - glName indicates the name of the GL to which the GLO should be
disassociated. disassociated.
- glOwnerInfo indicates the name and address of the GLO to be - glOwnerInfo indicates the name and address of the GLO to be
removed. The certificates field SHOULD be omitted, as it will be removed. The certificates field SHOULD be omitted, as it will be
ignored. ignored.
3.1.8. GL Key Compromise 3.1.8. GL Key Compromise
GL members and GLOs use glkCompromise to indicate that the shared KEK GL members and GLOs use glkCompromise to indicate that the shared KEK
possessed has been compromised. The glKeyCompromise control attribute possessed has been compromised. The glKeyCompromise control
has the syntax GeneralName. This message is always redirected by the attribute has the syntax GeneralName. This message is always
GLA to the GLO for further action. The glkCompromise MAY be included redirected by the GLA to the GLO for further action. The
in an EnvelopedData generated with the compromised shared KEK. The glkCompromise MAY be included in an EnvelopedData generated with the
name of the GL to which the compromised key is associated with is compromised shared KEK. The name of the GL to which the compromised
placed in GeneralName: key is associated is placed in GeneralName:
GLKCompromise ::= GeneralName GLKCompromise ::= GeneralName
3.1.9. GL Key Refresh 3.1.9. GL Key Refresh
GL members use the glkRefresh to request that the shared KEK be GL members use the glkRefresh to request that the shared KEK be
redistributed to them. The glkRefresh control attribute has the redistributed to them. The glkRefresh control attribute has the
syntax GLKRefresh. syntax GLKRefresh.
GLKRefresh ::= SEQUENCE { GLKRefresh ::= SEQUENCE {
glName GeneralName, glName GeneralName,
dates SEQUENCE SIZE (1..MAX) OF Date } dates SEQUENCE SIZE (1..MAX) OF Date }
Date ::= SEQUENCE { Date ::= SEQUENCE {
start GeneralizedTime, start GeneralizedTime,
end GeneralizedTime OPTIONAL } end GeneralizedTime OPTIONAL }
The fields in GLKRefresh have the following meaning: The fields in GLKRefresh have the following meaning:
- glName indicates the name of the GL for which the GL member wants - glName indicates the name of the GL for which the GL member wants
shared KEKs. shared KEKs.
- dates indicates a date range for keys the GL member wants. The - dates indicates a date range for keys the GL member wants. The
start field indicates the first date the GL member wants and the start field indicates the first date the GL member wants and the
end field indicates the last date. The end date MAY be omitted end field indicates the last date. The end date MAY be omitted
to indicate the GL member wants all keys from the specified to indicate the GL member wants all keys from the specified start
start date to the current date. Note that a procedural mechanism date to the current date. Note that a procedural mechanism is
is needed to restrict users from accessing messages that they needed to restrict users from accessing messages that they are
are not allowed to access. not allowed to access.
3.1.10. GLA Query Request and Response 3.1.10. GLA Query Request and Response
There are situations where GLOs and GL members may need to determine There are situations where GLOs and GL members may need to determine
some information from the GLA about the GL. GLOs and GL members use some information from the GLA about the GL. GLOs and GL members use
the glaQueryRequest, defined in section 3.1.10.1, to request the glaQueryRequest, defined in Section 3.1.10.1, to request
information and GLAs use the glaQueryResponse, defined in section information and GLAs use the glaQueryResponse, defined in Section
3.1.10.2, to return the requested information. Section 3.1.10.3 3.1.10.2, to return the requested information. Section 3.1.10.3
includes one request and response type and value; others may be includes one request and response type and value; others may be
defined in additional documents. defined in additional documents.
3.1.10.1. GLA Query Request 3.1.10.1. GLA Query Request
GLOs and GL members use the glaQueryRequest to ascertain information GLOs and GL members use the glaQueryRequest to ascertain information
about the GLA. The glaQueryRequest control attribute has the syntax about the GLA. The glaQueryRequest control attribute has the syntax
GLAQueryRequest: GLAQueryRequest:
GLAQueryRequest ::= SEQUENCE { GLAQueryRequest ::= SEQUENCE {
glaRequestType OBJECT IDENTIFIER, glaRequestType OBJECT IDENTIFIER,
glaRequestValue ANY DEFINED BY glaRequestType } glaRequestValue ANY DEFINED BY glaRequestType }
3.1.10.2. GLA Query Response 3.1.10.2. GLA Query Response
GLAs return the glaQueryResponse after receiving a GLAQueryRequest. GLAs return the glaQueryResponse after receiving a GLAQueryRequest.
The glaQueryResponse MUST be signed by a GLA. The glaQueryResponse The glaQueryResponse MUST be signed by a GLA. The glaQueryResponse
control attribute has the syntax GLAQueryResponse: control attribute has the syntax GLAQueryResponse:
GLAQueryResponse ::= SEQUENCE { GLAQueryResponse ::= SEQUENCE {
glaResponseType OBJECT IDENTIFIER, glaResponseType OBJECT IDENTIFIER,
glaResponseValue ANY DEFINED BY glaResponseType } glaResponseValue ANY DEFINED BY glaResponseType }
3.1.10.3. Request and Response Types 3.1.10.3. Request and Response Types
Request and Responses are registered as a pair under the following Requests and responses are registered as a pair under the following
object identifier arc: object identifier arc:
id-cmc-glaRR OBJECT IDENTIFIER ::= { id-cmc 99 } id-cmc-glaRR OBJECT IDENTIFIER ::= { id-cmc 99 }
This document defines one request/response pair for GL members and This document defines one request/response pair for GL members and
GLOs to query the GLA for the list of algorithm it supports. The GLOs to query the GLA for the list of algorithm it supports. The
following object identifier (OID) is included in the glaQueryType following Object Identifier (OID) is included in the glaQueryType
field: field:
id-cmc-gla-skdAlgRequest OBJECT IDENTIFIER ::={ id-cmc-glaRR 1 } id-cmc-gla-skdAlgRequest OBJECT IDENTIFIER ::={ id-cmc-glaRR 1 }
SKDAlgRequest ::= NULL SKDAlgRequest ::= NULL
If the GLA supports GLAQueryRequest and GLAQueryResponse messages, If the GLA supports GLAQueryRequest and GLAQueryResponse messages,
the GLA may return the following OID in the glaQueryType field: the GLA may return the following OID in the glaQueryType field:
id-cmc-gla-skdAlgResponse OBJECT IDENTIFIER ::= { id-cmc-glaRR 2 } id-cmc-gla-skdAlgResponse OBJECT IDENTIFIER ::= { id-cmc-glaRR 2 }
The glaQueryValue has the form of the smimeCapabilities attributes as The glaQueryValue has the form of the smimeCapabilities attributes as
defined in [MSG]. defined in [MSG].
3.1.11. Provide Cert 3.1.11. Provide Cert
GLAs and GLOs use the glProvideCert to request that a GL member GLAs and GLOs use the glProvideCert to request that a GL member
provide an updated or new encryption certificate. The glProvideCert provide an updated or new encryption certificate. The glProvideCert
message MUST be signed by either GLA or GLO. If the GL member's PKC message MUST be signed by either GLA or GLO. If the GL member's PKC
has been revoked, the GLO or GLA MUST NOT use it to generate the has been revoked, the GLO or GLA MUST NOT use it to generate the
EnvelopedData that encapsulates the glProvideCert request. The EnvelopedData that encapsulates the glProvideCert request. The
glProvideCert control attribute has the syntax GLManageCert: glProvideCert control attribute has the syntax GLManageCert:
GLManageCert ::= SEQUENCE { GLManageCert ::= SEQUENCE {
glName GeneralName, glName GeneralName,
glMember GLMember } glMember GLMember }
The fields in GLManageCert have the following meaning: The fields in GLManageCert have the following meaning:
- glName indicates the name of the GL to which the GL member's new - glName indicates the name of the GL to which the GL member's new
certificate is to be associated. certificate is to be associated.
- glMember indicates particulars for the GL member: - glMember indicates particulars for the GL member:
-- glMemberName indicates the GL member's name. -- glMemberName indicates the GL member's name.
-- glMemberAddress indicates the GL member's address. It MAY be -- glMemberAddress indicates the GL member's address. It MAY be
omitted. omitted.
-- certificates SHOULD be omitted. -- certificates SHOULD be omitted.
3.1.12. Update Cert 3.1.12 Update Cert
GL members and GLOs use the glUpdateCert to provide a new certificate GL members and GLOs use the glUpdateCert to provide a new certificate
for the GL. GL members can generate an unsolicited glUpdateCert or for the GL. GL members can generate an unsolicited glUpdateCert or
generate a response glUpdateCert as a result of receiveing a generate a response glUpdateCert as a result of receiving a
glProvideCert message. GL members MUST sign the glUpdateCert. If the glProvideCert message. GL members MUST sign the glUpdateCert. If
GL member's encryption certificate has been revoked, the GL member the GL member's encryption certificate has been revoked, the GL
MUST NOT use it to generate the EnvelopedData that encapsulates the member MUST NOT use it to generate the EnvelopedData that
glUpdateCert request or response. The glUpdateCert control attribute encapsulates the glUpdateCert request or response. The glUpdateCert
has the syntax GLManageCert: control attribute has the syntax GLManageCert:
GLManageCert ::= SEQUENCE { GLManageCert ::= SEQUENCE {
glName GeneralName, glName GeneralName,
glMember GLMember } glMember GLMember }
The fields in GLManageCert have the following meaning: The fields in GLManageCert have the following meaning:
- glName indicates the name of the GL to which the GL member's new - glName indicates the name of the GL to which the GL member's new
certificate should be associated. certificate should be associated.
- glMember indicates the particulars for the GL member: - glMember indicates the particulars for the GL member:
-- glMemberName indicates the GL member's name. -- glMemberName indicates the GL member's name.
-- glMemberAddress indicates the GL member's address. It MAY be -- glMemberAddress indicates the GL member's address. It MAY be
omitted. omitted.
-- certificates MAY be omitted if the GLManageCert message is -- certificates MAY be omitted if the GLManageCert message is
sent to request the GL member's certificate; otherwise, it sent to request the GL member's certificate; otherwise, it
MUST be included. It includes the following three fields: MUST be included. It includes the following three fields:
---- certificates.pKC includes the member's encryption --- certificates.pKC includes the member's encryption
certificate that will be used to encrypt the shared KEK certificate that will be used to encrypt the shared KEK
for that member. for that member.
--- certificates.aC MAY be included to convey one or more --- certificates.aC MAY be included to convey one or more
attribute certificate associated with the member's attribute certificates associated with the member's
encryption certificate. encryption certificate.
--- certificates.certPath MAY also be included to convey --- certificates.certPath MAY also be included to convey
certificates that might aid the recipient in certificates that might aid the recipient in
constructing valid certification paths for the constructing valid certification paths for the
certificate provided in certificates.pKC and the certificate provided in certificates.pKC and the
attribute certificates provided in certificates.aC. attribute certificates provided in certificates.aC.
These certificates is optional because they might These certificates are optional because they might
already be included elsewhere in the message (e.g., in already be included elsewhere in the message (e.g., in
the outer CMS layer). the outer CMS layer).
3.1.13. GL Key 3.1.13. GL Key
The GLA uses the glKey to distribute the shared KEK. The glKey The GLA uses the glKey to distribute the shared KEK. The glKey
message MUST be signed by the GLA. The glKey control attribute has message MUST be signed by the GLA. The glKey control attribute has
the syntax GLKey: the syntax GLKey:
GLKey ::= SEQUENCE { GLKey ::= SEQUENCE {
glName GeneralName, glName GeneralName,
glIdentifier KEKIdentifier, -- See [CMS] glIdentifier KEKIdentifier, -- See [CMS]
glkWrapped RecipientInfos, -- See [CMS] glkWrapped RecipientInfos, -- See [CMS]
glkAlgorithm AlgorithmIdentifier, glkAlgorithm AlgorithmIdentifier,
glkNotBefore GeneralizedTime, glkNotBefore GeneralizedTime,
glkNotAfter GeneralizedTime } glkNotAfter GeneralizedTime }
-- KEKIdentifier is included only for illustrative purposes as -- KEKIdentifier is included only for illustrative purposes as
-- it is imported from [CMS]. -- it is imported from [CMS].
KEKIdentifier ::= SEQUENCE { KEKIdentifier ::= SEQUENCE {
keyIdentifier OCTET STRING, keyIdentifier OCTET STRING,
date GeneralizedTime OPTIONAL, date GeneralizedTime OPTIONAL,
other OtherKeyAttribute OPTIONAL } other OtherKeyAttribute OPTIONAL }
The fields in GLKey have the following meaning: The fields in GLKey have the following meaning:
- glName is the name of the GL. - glName is the name of the GL.
- glIdentifier is the key identifier of the shared KEK. See - glIdentifier is the key identifier of the shared KEK. See
paragraph 6.2.3 of [CMS] for a description of the subfields. Section 6.2.3 of [CMS] for a description of the subfields.
- glkWrapped is the wrapped shared KEK for the GL for a particular - glkWrapped is the wrapped shared KEK for the GL for a particular
duration. The RecipientInfos MUST be generated as specified in duration. The RecipientInfos MUST be generated as specified in
section 6.2 of [CMS]. The ktri RecipientInfo choice MUST be Section 6.2 of [CMS]. The ktri RecipientInfo choice MUST be
supported. The key in the EncryptedKey field (i.e., the supported. The key in the EncryptedKey field (i.e., the
distributed shared KEK) MUST be generated according to the distributed shared KEK) MUST be generated according to the
section concerning random number generation in the security section concerning random number generation in the security
considerations of [CMS]. considerations of [CMS].
- glkAlgorithm identifies the algorithm the shared KEK is used - glkAlgorithm identifies the algorithm with which the shared KEK
with. Since no encrypted data content is being conveyed at this is used. Since no encrypted data content is being conveyed at
point, the parameters encoded with the algorithm should be the this point, the parameters encoded with the algorithm should be
structure defined for smimeCapabilities rather than encrypted the structure defined for smimeCapabilities rather than encrypted
content. content.
- glkNotBefore indicates the date at which the shared KEK is - glkNotBefore indicates the date at which the shared KEK is
considered valid. GeneralizedTime values MUST be expressed in considered valid. GeneralizedTime values MUST be expressed in
UTC (Zulu) and MUST include seconds (i.e., times are UTC (Zulu) and MUST include seconds (i.e., times are
YYYYMMDDHHMMSSZ), even where the number of seconds is zero. YYYYMMDDHHMMSSZ), even where the number of seconds is zero.
GeneralizedTime values MUST NOT include fractional seconds. GeneralizedTime values MUST NOT include fractional seconds.
- glkNotAfter indicates the date after which the shared KEK is - glkNotAfter indicates the date after which the shared KEK is
considered invalid. GeneralizedTime values MUST be expressed in considered invalid. GeneralizedTime values MUST be expressed in
UTC (Zulu) and MUST include seconds (i.e., times are UTC (Zulu) and MUST include seconds (i.e., times are
YYYYMMDDHHMMSSZ), even where the number of seconds is zero. YYYYMMDDHHMMSSZ), even where the number of seconds is zero.
GeneralizedTime values MUST NOT include fractional seconds. GeneralizedTime values MUST NOT include fractional seconds.
If the glKey message is in response to a glUseKEK message: If the glKey message is in response to a glUseKEK message:
- The GLA MUST generate separate glKey messages for each recipient - The GLA MUST generate separate glKey messages for each recipient
if glUseKEK.glKeyAttributes.recipientsNotMutuallyAware is set to if glUseKEK.glKeyAttributes.recipientsNotMutuallyAware is set to
TRUE. For each recipient, you want to generate a message that TRUE. For each recipient, you want to generate a message that
contains that recipient's key (i.e., one message with one contains that recipient's key (i.e., one message with one
attribute). attribute).
- The GLA MUST generate the requested number of glKey messages. The - The GLA MUST generate the requested number of glKey messages.
value in glUseKEK.glKeyAttributes.generationCounter indicates The value in glUseKEK.glKeyAttributes.generationCounter indicates
the number of glKey messages requested. the number of glKey messages requested.
If the glKey message is in response to a glRekey message: If the glKey message is in response to a glRekey message:
- The GLA MUST generate separate glKey messages for each recipient - The GLA MUST generate separate glKey messages for each recipient
if glRekey.glNewKeyAttributes.recipientsNotMutuallyAware is set if glRekey.glNewKeyAttributes.recipientsNotMutuallyAware is set
to TRUE. to TRUE.
- The GLA MUST generate the requested number of glKey messages. The - The GLA MUST generate the requested number of glKey messages.
value in glUseKEK.glKeyAttributes.generationCounter indicates The value in glUseKEK.glKeyAttributes.generationCounter indicates
the number of glKey messages requested. the number of glKey messages requested.
- The GLA MUST generate one glKey messagefor each outstanding - The GLA MUST generate one glKey message for each outstanding
shared KEKs for the GL when glRekeyAllGLKeys is set to TRUE. shared KEKs for the GL when glRekeyAllGLKeys is set to TRUE.
If the glKey message was not in response to a glRekey or glUseKEK If the glKey message was not in response to a glRekey or glUseKEK
(e.g., where the GLA controls rekey): (e.g., where the GLA controls rekey):
- The GLA MUST generate separate glKey messages for each recipient - The GLA MUST generate separate glKey messages for each recipient
when glUseKEK.glNewKeyAttributes.recipientsNotMutuallyAware that when glUseKEK.glNewKeyAttributes.recipientsNotMutuallyAware that
set up the GL was set to TRUE. set up the GL was set to TRUE.
- The GLA MAY generate glKey messages prior to the duration on the - The GLA MAY generate glKey messages prior to the duration on the
last outstanding shared KEK expiring, where the number of glKey last outstanding shared KEK expiring, where the number of glKey
messages generated is generationCounter minus one (1). Other messages generated is generationCounter minus one (1). Other
distribution mechanisms can also be supported to support this distribution mechanisms can also be supported to support this
functionality. functionality.
3.2. Use of CMC, CMS, and PKIX 3.2. Use of CMC, CMS, and PKIX
The following sections outline the use of CMC, CMS, and the PKIX The following sections outline the use of CMC, CMS, and the PKIX
certificate and CRL profile. certificate and CRL profile.
3.2.1. Protection Layers 3.2.1. Protection Layers
The following sections outline the protection required for the The following sections outline the protection required for the
control attributes defined in this document. control attributes defined in this document.
Note: There are multiple ways to encapsulate SignedData and Note: There are multiple ways to encapsulate SignedData and
EnvelopedData. The first is to use a MIME wrapper around each EnvelopedData. The first is to use a MIME wrapper around each
ContentInfo, as specified in [MSG]. The second is to not use a MIME ContentInfo, as specified in [MSG]. The second is not to use a MIME
wrapper around each ContentInfo, as specified in Transporting S/MIME wrapper around each ContentInfo, as specified in Transporting S/MIME
Objects in X.400 [X400TRANS]. Objects in X.400 [X400TRANS].
3.2.1.1. Minimum Protection 3.2.1.1. Minimum Protection
At a minimum, a SignedData MUST protect each request and response At a minimum, a SignedData MUST protect each request and response
encapsulated in PKIData and PKIResponse. The following is a depiction encapsulated in PKIData and PKIResponse. The following is a
of the minimum wrappings: depiction of the minimum wrappings:
Minimum Protection Minimum Protection
------------------ ------------------
SignedData SignedData
PKIData or PKIResponse PKIData or PKIResponse
controlSequence controlSequence
Prior to taking any action on any request or response SignedData(s) Prior to taking any action on any request or response SignedData(s)
MUST be processed according to [CMS]. MUST be processed according to [CMS].
3.2.1.2. Additional Protection 3.2.1.2. Additional Protection
An additional EnvelopedData MAY also be used to provide An additional EnvelopedData MAY also be used to provide
confidentiality of the request and response. An additional SignedData confidentiality of the request and response. An additional
MAY also be added to provide authentication and integrity of the SignedData MAY also be added to provide authentication and integrity
encapsulated EnvelopedData. The following is a depiction of the of the encapsulated EnvelopedData. The following is a depiction of
optional additional wrappings: the optional additional wrappings:
Authentication and Integrity Authentication and Integrity
Confidentiality Protection of Confidentiality Protection Confidentiality Protection of Confidentiality Protection
-------------------------- ----------------------------- -------------------------- -----------------------------
EnvelopedData SignedData EnvelopedData SignedData
SignedData EnvelopedData SignedData EnvelopedData
PKIData or PKIResponse SignedData PKIData or PKIResponse SignedData
controlSequence PKIData or PKIResponse controlSequence PKIData or PKIResponse
controlSequence controlSequence
If an incoming message is encrypted, the confidentiality of the If an incoming message is encrypted, the confidentiality of the
message MUST be preserved. All EnvelopedData objects MUST be message MUST be preserved. All EnvelopedData objects MUST be
processed as specified in [CMS]. If a SignedData is added over an processed as specified in [CMS]. If a SignedData is added over an
EnvelopedData, a ContentHints attribute SHOULD be added. See EnvelopedData, a ContentHints attribute SHOULD be added. See Section
paragraph 2.9 of Extended Security Services for S/MIME [ESS]. 2.9 of Extended Security Services for S/MIME [ESS].
If the GLO or GL member applies confidentiality to a request, the If the GLO or GL member applies confidentiality to a request, the
EnvelopedData MUST include the GLA as a recipient. If the GLA EnvelopedData MUST include the GLA as a recipient. If the GLA
forwards the GL member request to the GLO, then the GLA MUST decrypt forwards the GL member request to the GLO, then the GLA MUST decrypt
the EnvelopedData content, strip the confidentiality layer, and apply the EnvelopedData content, strip the confidentiality layer, and apply
its own confidentiality layer as an EnvelopedData with the GLO as a its own confidentiality layer as an EnvelopedData with the GLO as a
recipient. recipient.
3.2.2. Combining Requests and Responses 3.2.2. Combining Requests and Responses
Multiple requests and response corresponding to a GL MAY be included Multiple requests and responses corresponding to a GL MAY be included
in one PKIData.controlSequence or PKIResponse.controlSequence. in one PKIData.controlSequence or PKIResponse.controlSequence.
Requests and responses for multiple GLs MAY be combined in one Requests and responses for multiple GLs MAY be combined in one
PKIData or PKIResponse by using PKIData.cmsSequence and PKIData or PKIResponse by using PKIData.cmsSequence and
PKIResponse.cmsSequence. A separate cmsSequence MUST be used for PKIResponse.cmsSequence. A separate cmsSequence MUST be used for
different GLs. That is, requests corresponding to two different GLs different GLs. That is, requests corresponding to two different GLs
are included in different cmsSequences. The following is a diagram are included in different cmsSequences. The following is a diagram
depicting multiple requests and responses combined in one PKIData and depicting multiple requests and responses combined in one PKIData and
PKIResponse: PKIResponse:
Multiple Request and Response Multiple Requests and Responses
Request Response Request Response
------- -------- ------- --------
SignedData SignedData SignedData SignedData
PKIData PKIResponse PKIData PKIResponse
cmsSequence cmsSequence cmsSequence cmsSequence
SignedData SignedData SignedData SignedData
PKIData PKIResponse PKIData PKIResponse
controlSequence controlSequence controlSequence controlSequence
One or more requests One or more responses One or more requests One or more responses
corresponding to one GL corresponding to one GL corresponding to one GL corresponding to one GL
SignedData SignedData SignedData SignedData
PKIData PKIResponse PKIData PKIResponse
controlSequence controlSequence controlSequence controlSequence
One or more requests One or more responses One or more requests One or more responses
corresponding to another GL corresponding to another GL corresponding to another GL corresponding to another GL
When applying confidentiality to multiple requests and responses, all When applying confidentiality to multiple requests and responses, all
of the requests/response MAY be included in one EnvelopedData. of the requests/responses MAY be included in one EnvelopedData. The
following is a depiction:
The following is a depiction:
Confidentiality of Multiple Requests and Responses Confidentiality of Multiple Requests and Responses
Wrapped Together Wrapped Together
---------------- ----------------
EnvelopedData EnvelopedData
SignedData SignedData
PKIData PKIData
cmsSequence cmsSequence
SignedData SignedData
PKIResponse PKIResponse
controlSequence controlSequence
One or more requests One or more requests
corresponding to one GL corresponding to one GL
SignedData SignedData
PKIData PKIData
controlSequence controlSequence
One or more requests One or more requests
corresponding to one GL corresponding to one GL
Certain combinations of requests in one PKIData.controlSequence and Certain combinations of requests in one PKIData.controlSequence and
one PKIResponse.controlSequence are not allowed. The invalid one PKIResponse.controlSequence are not allowed. The invalid
combinations listed here MUST NOT be generated: combinations listed here MUST NOT be generated:
Invalid Combinations Invalid Combinations
--------------------------- ---------------------------
glUseKEK & glDeleteMember glUseKEK & glDeleteMember
glUseKEK & glRekey glUseKEK & glRekey
glUseKEK & glDelete glUseKEK & glDelete
glDelete & glAddMember glDelete & glAddMember
glDelete & glDeleteMember glDelete & glDeleteMember
glDelete & glRekey glDelete & glRekey
glDelete & glAddOwner glDelete & glAddOwner
glDelete & glRemoveOwner glDelete & glRemoveOwner
To avoid unnecessary errors, certain requests and responses SHOULD be To avoid unnecessary errors, certain requests and responses SHOULD be
processed prior to others. The following is the priority of message processed prior to others. The following is the priority of message
processing, if not listed it is an implementation decision as to processing, if not listed it is an implementation decision as to
which to process first: glUseKEK before glAddMember, glRekey before which to process first: glUseKEK before glAddMember, glRekey before
glAddMember, and glDeleteMember before glRekey. Note that there is a glAddMember, and glDeleteMember before glRekey. Note that there is a
processing priority but it does not imply an ordering within the processing priority, but it does not imply an ordering within the
content. content.
3.2.3. GLA Generated Messages 3.2.3. GLA Generated Messages
When the GLA generates a success or fail message, it generates one When the GLA generates a success or fail message, it generates one
for each request. SKDFailInfo values of unsupportedDuration, for each request. SKDFailInfo values of unsupportedDuration,
unsupportedDeliveryMethod, unsupportedAlgorithm, noGLONameMatch, unsupportedDeliveryMethod, unsupportedAlgorithm, noGLONameMatch,
nameAlreadyInUse, alreadyAnOwner, notAnOwner are not returned to GL nameAlreadyInUse, alreadyAnOwner, and notAnOwner are not returned to
members. GL members.
If GLKeyAttributes.recipientsNotMutuallyAware is set to TRUE, a If GLKeyAttributes.recipientsNotMutuallyAware is set to TRUE, a
separate PKIResponse.cMCStatusInfoExt and PKIData.glKey MUST be separate PKIResponse.cMCStatusInfoExt and PKIData.glKey MUST be
generated for each recipient. However, it is valid to send one generated for each recipient. However, it is valid to send one
message with multiple attributes to the same recipient. message with multiple attributes to the same recipient.
If the GL has multiple GLOs, the GLA MUST send cMCStatusInfoExt If the GL has multiple GLOs, the GLA MUST send cMCStatusInfoExt
messages to the requesting GLO. The mechanism to determine which GLO messages to the requesting GLO. The mechanism to determine which GLO
made the request is beyond the scope of this document. made the request is beyond the scope of this document.
If a GL is managed and the GLA receives a glAddMember, If a GL is managed and the GLA receives a glAddMember,
glDeleteMember, or glkCompromise message, the GLA redirects the glDeleteMember, or glkCompromise message, the GLA redirects the
request to the GLO for review. An additional, SignedData MUST be request to the GLO for review. An additional, SignedData MUST be
applied to the redirected request as follows: applied to the redirected request as follows:
GLA Forwarded Requests GLA Forwarded Requests
---------------------- ----------------------
SignedData
PKIData
cmsSequence
SignedData SignedData
PKIData PKIData
cmsSequence controlSequence
SignedData
PKIData
controlSequence
3.2.4. CMC Control Attributes and CMS Signed Attributes 3.2.4. CMC Control Attributes and CMS Signed Attributes
CMC carries control attributes as CMS signed attributes. These CMC carries control attributes as CMS signed attributes. These
attributes are defined in [CMC] and [CMS]. Some of these attributes attributes are defined in [CMC] and [CMS]. Some of these attributes
are REQUIRED; others are OPTIONAL. The required attributes are as are REQUIRED; others are OPTIONAL. The required attributes are as
follows: cMCStatusInfoExt transactionId, senderNonce, recipientNonce, follows: cMCStatusInfoExt transactionId, senderNonce, recipientNonce,
queryPending, and signingTime. Other attributes can also be used; queryPending, and signingTime. Other attributes can also be used;
however, their use is beyond the scope of this document. The however, their use is beyond the scope of this document. The
following sections specify requirements in addition to those already following sections specify requirements in addition to those already
specified in [CMC] and [CMS]. specified in [CMC] and [CMS].
3.2.4.1. Using cMCStatusInfoExt 3.2.4.1. Using cMCStatusInfoExt
cMCStatusInfoExt is used by GLAs to indicate to GLOs and GL members cMCStatusInfoExt is used by GLAs to indicate to GLOs and GL members
that a request was unsuccessful. Two classes of failure codes are that a request was unsuccessful. Two classes of failure codes are
used within this document. Errors from the CMCFailInfo list, found in used within this document. Errors from the CMCFailInfo list, found
section 5.1.4 of CMC, are encoded as defined in CMC. Error codes in Section 5.1.4 of CMC, are encoded as defined in CMC. Error codes
defined in this document are encoded using the ExtendedFailInfo field defined in this document are encoded using the ExtendedFailInfo field
of the cmcStatusInfoExt structure. If the same failure code applies of the cmcStatusInfoExt structure. If the same failure code applies
to multiple commands, a single cmcStatusInfoExt structure can be used to multiple commands, a single cmcStatusInfoExt structure can be used
with multiple items in cMCStatusInfoExt.bodyList. The GLA MAY also with multiple items in cMCStatusInfoExt.bodyList. The GLA MAY also
return other pertinent information in statusString. The SKDFailInfo return other pertinent information in statusString. The SKDFailInfo
object identifier and value are: object identifier and value are:
id-cet-skdFailInfo OBJECT IDENTIFIER ::= { iso(1) id-cet-skdFailInfo OBJECT IDENTIFIER ::= { iso(1)
identified-organization(3) dod(6) internet(1) security(5) identified-organization(3) dod(6) internet(1) security(5)
mechanisms(5) pkix(7) cet(15) skdFailInfo(1) } mechanisms(5) pkix(7) cet(15) skdFailInfo(1) }
SKDFailInfo ::= INTEGER { SKDFailInfo ::= INTEGER {
unspecified (0), unspecified (0),
closedGL (1), closedGL (1),
unsupportedDuration (2), unsupportedDuration (2),
noGLACertificate (3), noGLACertificate (3),
invalidCert (4), invalidCert (4),
unsupportedAlgorithm (5), unsupportedAlgorithm (5),
noGLONameMatch (6), noGLONameMatch (6),
invalidGLName (7), invalidGLName (7),
nameAlreadyInUse (8), nameAlreadyInUse (8),
noSpam (9), noSpam (9),
deniedAccess (10),
alreadyAMember (11), -- obsolete (10),
notAMember (12), alreadyAMember (11),
alreadyAnOwner (13), notAMember (12),
notAnOwner (14) } alreadyAnOwner (13),
notAnOwner (14) }
The values have the following meaning: The values have the following meaning:
- unspecified indicates that the GLA is unable or unwilling to - unspecified indicates that the GLA is unable or unwilling to
perform the requested action and does not want to indicate the perform the requested action and does not want to indicate the
reason. reason.
- closedGL indicates that members can only be added or deleted by - closedGL indicates that members can only be added or deleted by
the GLO. the GLO.
- unsupportedDuration indicates the GLA does not support generating - unsupportedDuration indicates that the GLA does not support
keys that are valid for the requested duration. generating keys that are valid for the requested duration.
- noGLACertificate indicates that the GLA does not have a valid - noGLACertificate indicates that the GLA does not have a valid
certificate. certificate.
- invalidCert indicates the member's encryption certificate was not - invalidCert indicates that the member's encryption certificate
verifiable (i.e., signature did not validate, certificate's was not verifiable (i.e., signature did not validate,
serial number present on a CRL, expired, etc.). certificate's serial number present on a CRL, the certificate
expired, etc.).
- unsupportedAlgorithm indicates the GLA does not support the - unsupportedAlgorithm indicates the GLA does not support the
requested algorithm. requested algorithm.
- noGLONameMatch indicates that one of the names in the certificate - noGLONameMatch indicates that one of the names in the certificate
used to sign a request does not match the name of a registered used to sign a request does not match the name of a registered
GLO. GLO.
- invalidGLName indicates the GLA does not support the glName - invalidGLName indicates that the GLA does not support the glName
present in the request. present in the request.
- nameAlreadyInUse indicates the glName is already assigned on the - nameAlreadyInUse indicates that the glName is already assigned on
GLA. the GLA.
- noSpam indicates the prospective GL member did not sign the - noSpam indicates that the prospective GL member did not sign the
request (i.e., if the name in glMember.glMemberName does not request (i.e., if the name in glMember.glMemberName does not
match one of the names (either the subject distinguished name or match one of the names (either the subject distinguished name or
one of the subject alternative names) in the certificate used to one of the subject alternative names) in the certificate used to
sign the request). sign the request).
- alreadyAMember indicates the prospective GL member is already a - alreadyAMember indicates that the prospective GL member is
GL member. already a GL member.
- notAMember indicates the prospective GL member to be deleted is - notAMember indicates that the prospective GL member to be deleted
not presently a GL member. is not presently a GL member.
- alreadyAnOwner indicates the prospective GLO is already a GLO. - alreadyAnOwner indicates that the prospective GLO is already a
GLO.
- notAnOwner indicates the prospective GLO to be deleted is not - notAnOwner indicates that the prospective GLO to be deleted is
presently a GLO. not presently a GLO.
cMCStatusInfoExt is used by GLAs to indicate to GLOs and GL members cMCStatusInfoExt is used by GLAs to indicate to GLOs and GL members
that a request was successfully completed. If the request was that a request was successfully completed. If the request was
successful, the GLA returns a cMCStatusInfoExt response with successful, the GLA returns a cMCStatusInfoExt response with
cMCStatus.success and optionally other pertinent information in cMCStatus.success and optionally other pertinent information in
statusString. statusString.
When the GL is managed and the GLO has reviewed GL member initiated When the GL is managed and the GLO has reviewed GL member initiated
glAddMember, glDeleteMember, and glkComrpomise requests, the GLO uses glAddMember, glDeleteMember, and glkComrpomise requests, the GLO uses
cMCStatusInfoExt to indicate the success or failure of the request. cMCStatusInfoExt to indicate the success or failure of the request.
If the request is allowed, cMCStatus.success is returned and If the request is allowed, cMCStatus.success is returned and
statusString is optionally returned to convey additional information. statusString is optionally returned to convey additional information.
If the request is denied, cMCStatus.failed is returned and If the request is denied, cMCStatus.failed is returned and
statusString is optionally returned to convey additional information. statusString is optionally returned to convey additional information.
Additionally, the appropriate SKDFailInfo can be included in Additionally, the appropriate SKDFailInfo can be included in
cMCStatusInfoExt.extendedFailInfo. cMCStatusInfoExt.extendedFailInfo.
cMCStatusInfoExt is used by GLOs, GLAs, and GL members to indicate cMCStatusInfoExt is used by GLOs, GLAs, and GL members to indicate
that signature verification failed. If the signature failed to verify that signature verification failed. If the signature failed to
over any control attibute except a cMCStatusInfoExt, a verify over any control attribute except a cMCStatusInfoExt, a
cMCStatusInfoExt control attribute MUST be returned indicating cMCStatusInfoExt control attribute MUST be returned indicating
cMCStatus.failed and otherInfo.failInfo.badMessageCheck. If the cMCStatus.failed and otherInfo.failInfo.badMessageCheck. If the
signature over the outermost PKIData failed, the bodyList value is signature over the outermost PKIData failed, the bodyList value is
zero (0). If the signature over any other PKIData failed the bodyList zero (0). If the signature over any other PKIData failed, the
value is the bodyPartId value from the request or response. GLOs and bodyList value is the bodyPartId value from the request or response.
GL members who receive cMCStatusInfoExt messages whose signatures are GLOs and GL members who receive cMCStatusInfoExt messages whose
invalid SHOULD generate a new request to avoid badMessageCheck signatures are invalid SHOULD generate a new request to avoid
message loops. badMessageCheck message loops.
cMCStatusInfoExt is also used by GLOs and GLAs to indicate that a cMCStatusInfoExt is also used by GLOs and GLAs to indicate that a
request could not be performed immediately. If the request could not request could not be performed immediately. If the request could not
be processed immediately by the GLA or GLO, the cMCStatusInfoExt be processed immediately by the GLA or GLO, the cMCStatusInfoExt
control attribute MUST be returned indicating cMCStatus.pending and control attribute MUST be returned indicating cMCStatus.pending and
otherInfo.pendInfo. When requests are redirected to the GLO for otherInfo.pendInfo. When requests are redirected to the GLO for
approval (for managed lists), the GLA MUST NOT return a approval (for managed lists), the GLA MUST NOT return a
cMCStatusInfoExt indicating query pending. cMCStatusInfoExt indicating query pending.
cMCStatusInfoExt is also used by GLAs to indicate that a cMCStatusInfoExt is also used by GLAs to indicate that a
glaQueryRequest is not supported. If the glaQueryRequest is not glaQueryRequest is not supported. If the glaQueryRequest is not
supported, the cMCStatusInfoExt control attribute MUST be returned supported, the cMCStatusInfoExt control attribute MUST be returned
indicating cMCStatus.noSupport and statusString is optionally indicating cMCStatus.noSupport and statusString is optionally
returned to convey additional information. returned to convey additional information.
cMCStatusInfoExt is also used by GL members, GLOs, and GLAs to cMCStatusInfoExt is also used by GL members, GLOs, and GLAs to
indicate that the signingTime (see section 3.2.4.3) is not close indicate that the signingTime (see Section 3.2.4.3) is not close
enough to the locally specified time. If the local time is not close enough to the locally specified time. If the local time is not close
enough to the time specified in signingTime, a cMCStatus.failed and enough to the time specified in signingTime, a cMCStatus.failed and
otherInfo.failInfo.badTime MAY be returned. otherInfo.failInfo.badTime MAY be returned.
3.2.4.2. Using transactionId 3.2.4.2. Using transactionId
transactionId MAY be included by GLOs, GLAs, or GL members to transactionId MAY be included by GLOs, GLAs, or GL members to
identify a given transaction. All subsequent requests and responses identify a given transaction. All subsequent requests and responses
related to the original request MUST include the same transactionId related to the original request MUST include the same transactionId
control attribute. If GL members include a transactionId and the control attribute. If GL members include a transactionId and the
request is redirected to the GLO, the GLA MAY include an additional request is redirected to the GLO, the GLA MAY include an additional
transactionId in the outer PKIData. If the GLA included an additional transactionId in the outer PKIData. If the GLA included an
transactionId in the outer PKIData, when the GLO generates a additional transactionId in the outer PKIData, when the GLO generates
cMCStatusInfoExt response it generates one for the GLA with the GLA's a cMCStatusInfoExt response it generates one for the GLA with the
transactionId and one for the GL member with the GL member's GLA's transactionId and one for the GL member with the GL member's
transactionId. transactionId.
3.2.4.3. Using nonces and signingTime 3.2.4.3. Using Nonces and signingTime
The use of nonces (see section 5.6 of [CMC]) and an indication of The use of nonces (see Section 5.6 of [CMC]) and an indication of
when the message was signed (see section 11.3 of [CMS]) can be used when the message was signed (see Section 11.3 of [CMS]) can be used
to provide application-level replay prevention. to provide application-level replay prevention.
To protect the GL, all messages MUST include the signingTime To protect the GL, all messages MUST include the signingTime
attribute. Message originators and recipients can then use the time attribute. Message originators and recipients can then use the time
provided in this attribute to determine whether they have previously provided in this attribute to determine whether they have previously
received the message. received the message.
If the originating message includes a senderNonce, the response to If the originating message includes a senderNonce, the response to
the message MUST include the received senderNonce value as the the message MUST include the received senderNonce value as the
recipientNonce and a new value as the senderNonce value in the recipientNonce and a new value as the senderNonce value in the
response. response.
If a GLA aggragates multiple messages together or forwards a message If a GLA aggregates multiple messages together or forwards a message
to a GLO, the GLA MAY optionally generate a new nonce value and to a GLO, the GLA MAY optionally generate a new nonce value and
include that in the wrapping message. When the response comes back include that in the wrapping message. When the response comes back
from the GLO, the GLA builds a response to the originator(s) of the from the GLO, the GLA builds a response to the originator(s) of the
message(s) and deals with each of the nonce values from the message(s) and deals with each of the nonce values from the
originating messages. originating messages.
For these attributes it is necessary to maintain state information on For these attributes, it is necessary to maintain state information
exchanges to compare one result to another. The time period for which on exchanges to compare one result to another. The time period for
this information is maintained in a local policy. which this information is maintained is a local policy.
3.2.4.4. CMC and CMS Attribute Support Requirements 3.2.4.4. CMC and CMS Attribute Support Requirements
The following are the implementation requirements for CMC control The following are the implementation requirements for CMC control
attributes and CMS signed attributes for an implementation be attributes and CMS signed attributes for an implementation to be
considered conformant to this specification: considered conformant to this specification:
Implementation Requirement | Implementation Requirement |
GLO | GLA | GL Member | Attribute GLO | GLA | GL Member | Attribute
O R | O R F | O R | O R | O R F | O R |
--------- | ------------- | --------- | ---------- --------- | ------------- | --------- | ----------
MUST MUST | MUST MUST - | MUST MUST | cMCStatusInfoExt MUST MUST | MUST MUST - | MUST MUST | cMCStatusInfoExt
MAY MAY | MUST MUST - | MAY MAY | transactionId MAY MAY | MUST MUST - | MAY MAY | transactionId
MAY MAY | MUST MUST - | MAY MAY | senderNonce MAY MAY | MUST MUST - | MAY MAY | senderNonce
MAY MAY | MUST MUST - | MAY MAY | recepientNonce MAY MAY | MUST MUST - | MAY MAY | recepientNonce
MUST MUST | MUST MUST - | MUST MUST | SKDFailInfo MUST MUST | MUST MUST - | MUST MUST | SKDFailInfo
MUST MUST | MUST MUST - | MUST MUST | signingTime MUST MUST | MUST MUST - | MUST MUST | signingTime
3.2.5. Resubmitted GL Member Messages 3.2.5. Resubmitted GL Member Messages
When the GL is managed, the GLA forwards the GL member requests to When the GL is managed, the GLA forwards the GL member requests to
the GLO for GLO approval by creating a new request message containing the GLO for GLO approval by creating a new request message containing
the GL member request(s) as a cmsSequence item. If the GLO approves the GL member request(s) as a cmsSequence item. If the GLO approves
the request it can either add a new layer of wrapping and send it the request, it can either add a new layer of wrapping and send it
back to the GLA or create a new message and send it to the GLA. (Note back to the GLA or create a new message and send it to the GLA.
in this case there are now 3 layers of PKIData messages with (Note in this case there are now 3 layers of PKIData messages with
appropriate signing layers.) appropriate signing layers.)
3.2.6. PKIX Certificate and CRL Profile 3.2.6. PKIX Certificate and CRL Profile
Signatures, certificates, and CRLs are verified according to the PKIX Signatures, certificates, and CRLs are verified according to the PKIX
profile [PROFILE]. profile [PROFILE].
Name matching is performed according to the PKIX profile [PROFILE]. Name matching is performed according to the PKIX profile [PROFILE].
All distinguished name forms must follow the UTF8String convention All distinguished name forms must follow the UTF8String convention
noted in the PKIX profile [PROFILE]. noted in the PKIX profile [PROFILE].
A certificate per-GL would be issued to the GLA. A certificate per GL would be issued to the GLA.
GL policy may mandate that the GL member's address be included in the GL policy may mandate that the GL member's address be included in the
GL member's certificate. GL member's certificate.
4. Administrative Messages 4. Administrative Messages
There are a number of administrative messages that must be performed There are a number of administrative messages that must be exchanged
to manage a GL. The following sections describe each request and to manage a GL. The following sections describe each request and
response message combination in detail. The procedures defined in response message combination in detail. The procedures defined in
this section are not prescriptive. this section are not prescriptive.
4.1. Assign KEK To GL 4.1. Assign KEK to GL
Prior to generating a group key, a GL needs to be setup and a shared 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 KEK assigned to the GL. Figure 3 depicts the protocol interactions
setup and assign a shared KEK. Note that error messages are not to set up and assign a shared KEK. Note that error messages are not
depicted in Figure 3. Additionally, behavior for the optional depicted in Figure 3. Additionally, behavior for the optional
transactionId, senderNonce, and recipientNonce CMC control attributes transactionId, senderNonce, and recipientNonce CMC control attributes
is not addressed in these procedures. is not addressed in these procedures.
+-----+ 1 2 +-----+ +-----+ 1 2 +-----+
| GLA | <-------> | GLO | | GLA | <-------> | GLO |
+-----+ +-----+ +-----+ +-----+
Figure 3 - Create Group List Figure 3 - Create Group List
The process is as follows: The process is as follows:
1 - The GLO is the entity responsible for requesting the creation 1 - The GLO is the entity responsible for requesting the creation of
of the GL. The GLO sends a the GL. The GLO sends a
SignedData.PKIData.controlSequence.glUseKEK request to the GLA SignedData.PKIData.controlSequence.glUseKEK request to the GLA (1
(1 in Figure 3). The GLO MUST include: glName, glAddress, in Figure 3). The GLO MUST include glName, glAddress,
glOwnerName, glOwnerAddress, and glAdministration. The GLO MAY glOwnerName, glOwnerAddress, and glAdministration. The GLO MAY
also include their preferences for the shared KEK in also include their preferences for the shared KEK in
glKeyAttributes by indicating whether the GLO controls the glKeyAttributes by indicating whether the GLO controls the rekey
rekey in rekeyControlledByGLO, whether separate glKey messages in rekeyControlledByGLO, whether separate glKey messages should
should be sent to each recipient in recipientsNotMutuallyAware, be sent to each recipient in recipientsNotMutuallyAware, the
the requested algorithm to be used with the shared KEK in requested algorithm to be used with the shared KEK in
requestedAlgorithm, the duration of the shared KEK, and how requestedAlgorithm, the duration of the shared KEK, and how many
many shared KEKs should be initially distributed in shared KEKs should be initially distributed in generationCounter.
generationCounter. The GLO MUST also include the signingTime The GLO MUST also include the signingTime attribute with this
attribute with this request. request.
1.a - If the GLO knows of members to be added to the GL, the 1.a - If the GLO knows of members to be added to the GL, the
glAddMember request(s) MAY be included in the same glAddMember request(s) MAY be included in the same
controlSequence as the glUseKEK request (see section 3.2.2). controlSequence as the glUseKEK request (see Section 3.2.2).
The GLO indicates the same glName in the glAddMember request The GLO indicates the same glName in the glAddMember request
as in glUseKEK.glInfo.glName. Further glAddMember procedures as in glUseKEK.glInfo.glName. Further glAddMember procedures
are covered in section 4.3. are covered in Section 4.3.
1.b - The GLO can apply confidentiality to the request by 1.b - The GLO can apply confidentiality to the request by
encapsulating the SignedData.PKIData in an EnvelopedData encapsulating the SignedData.PKIData in an EnvelopedData (see
(see section 3.2.1.2). Section 3.2.1.2).
1.c - The GLO can also optionally apply another SignedData over the 1.c - The GLO can also optionally apply another SignedData over the
EnvelopedData (see section 3.2.1.2). EnvelopedData (see Section 3.2.1.2).
2 - Upon receipt of the request, the GLA checks the signingTime and 2 - Upon receipt of the request, the GLA checks the signingTime and
verifies the signature on the inner most SignedData.PKIData. If verifies the signature on the innermost SignedData.PKIData. If
an additional SignedData and/or EnvelopedData encapsulates the an additional SignedData and/or EnvelopedData encapsulates the
request (see sections 3.2.1.2 and 3.2.2), the GLA verifies the request (see Sections 3.2.1.2 and 3.2.2), the GLA verifies the
outer signature(s) and/or decrypt the outer layer(s) prior to outer signature(s) and/or decrypts the outer layer(s) prior to
verifying the signature on the inner most SignedData. verifying the signature on the innermost SignedData.
2.a - If the signingTime attribute value is not within the locally 2.a - If the signingTime attribute value is not within the locally
accepted time window, the GLA MAY return a response accepted time window, the GLA MAY return a response
indicating cMCStatus.failed and otherInfo.failInfo.badTime indicating cMCStatus.failed and otherInfo.failInfo.badTime
and a signingTime attribute. and a signingTime attribute.
2.b - Else if signature processing continues and if the signatures 2.b - Else if signature processing continues and if the signatures
do not verify, the GLA returns a cMCStatusInfoExt response do not verify, the GLA returns a cMCStatusInfoExt response
indicating cMCStatus.failed and indicating cMCStatus.failed and
otherInfo.failInfo.badMessageCheck. Additionally, a otherInfo.failInfo.badMessageCheck. Additionally, a
signingTime attribute is included with the response. signingTime attribute is included with the response.
2.c - Else if the signatures do verify but the GLA does not have a 2.c - Else if the signatures do verify but the GLA does not have a
valid certificate, the GLA returns a cMCStatusInfoExt with valid certificate, the GLA returns a cMCStatusInfoExt with
cMCStatus.failed and otherInfo.extendedFailInfo.SKDFailInfo cMCStatus.failed and otherInfo.extendedFailInfo.SKDFailInfo
value of noValidGLACertificate. Additionally, a signingTime value of noValidGLACertificate. Additionally, a signingTime
attribute is included with the response. Instead of attribute is included with the response. Instead of
immediately returning the error code, the GLA attempts to immediately returning the error code, the GLA attempts to get
get a certificate, possibly using [CMC]. a certificate, possibly using [CMC].
2.d - Else the signatures are valid and the GLA does have a valid 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, the GLA checks that one of the names in the
certificate used to sign the request matches one of the certificate used to sign the request matches one of the names
names in glUseKEK.glOwnerInfo.glOwnerName. in glUseKEK.glOwnerInfo.glOwnerName.
2.d.1 - If the names do not match, the GLA returns a response 2.d.1 - If the names do not match, the GLA returns a response
indicating cMCStatusInfoExt with cMCStatus.failed and indicating cMCStatusInfoExt with cMCStatus.failed and
otherInfo.extendedFailInfo.SKDFailInfo value of otherInfo.extendedFailInfo.SKDFailInfo value of
noGLONameMatch. Additionally, a signingTime attribute is noGLONameMatch. Additionally, a signingTime attribute is
included with the response. included with the response.
2.d.2 - Else if the names all match, the GLA checks that the glName 2.d.2 - Else if the names all match, the GLA checks that the
and glAddress is not already in use. The GLA also checks glName and glAddress are not already in use. The GLA
any glAddMember included within the controlSequence with also checks any glAddMember included within the
this glUseKEK. Further processing of the glAddMember is controlSequence with this glUseKEK. Further processing
covered in section 4.3. of the glAddMember is covered in Section 4.3.
2.d.2.a - If the glName is already in use the GLA returns a 2.d.2.a - If the glName is already in use, the GLA returns a
response indicating cMCStatusInfoExt with response indicating cMCStatusInfoExt with
cMCStatus.failed and cMCStatus.failed and
otherInfo.extendedFailInfo.SKDFailInfo value of otherInfo.extendedFailInfo.SKDFailInfo value of
nameAlreadyInUse. Additionally, a signingTime attribute nameAlreadyInUse. Additionally, a signingTime
is included with the response. attribute is included with the response.
2.d.2.b - Else if the requestedAlgorithm is not supported, the GLA 2.d.2.b - Else if the requestedAlgorithm is not supported, the
returns a response indicating cMCStatusInfoExt with GLA returns a response indicating cMCStatusInfoExt
cMCStatus.failed and with cMCStatus.failed and
otherInfo.extendedFailInfo.SKDFailInfo value of otherInfo.extendedFailInfo.SKDFailInfo value of
unsupportedAlgorithm. Additionally, a signingTime unsupportedAlgorithm. Additionally, a signingTime
attribute is included with the response. attribute is included with the response.
2.d.2.c - Else if the duration cannot be supported, determining 2.d.2.c - Else if the duration cannot be supported, determining
this is beyond the scope of this document, the GLA this is beyond the scope of this document, the GLA
returns a response indicating cMCStatusInfoExt with returns a response indicating cMCStatusInfoExt with
cMCStatus.failed and cMCStatus.failed and
otherInfo.extendedFailInfo.SKDFailInfo value of otherInfo.extendedFailInfo.SKDFailInfo value of
unsupportedDuration. Additionally, a signingTime unsupportedDuration. Additionally, a signingTime
attribute is included with the response. attribute is included with the response.
2.d.2.d - Else if the GL cannot be supported for other reasons, 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 which the GLA does not wish to disclose, the GLA
a response indicating cMCStatusInfoExt with returns a response indicating cMCStatusInfoExt with
cMCStatus.failed and cMCStatus.failed and
otherInfo.extendedFailInfo.SKDFailInfo value of otherInfo.extendedFailInfo.SKDFailInfo value of
unspecified. Additionally, a signingTime attribute is unspecified. Additionally, a signingTime attribute
included with the response. is included with the response.
2.d.2.e - Else if the glName is not already in use, the duration 2.d.2.e - Else if the glName is not already in use, the
can be supported, and the requestedAlgorithm is duration can be supported, and the requestedAlgorithm
supported, the GLA MUST return a cMCStatusInfoExt is supported, the GLA MUST return a cMCStatusInfoExt
indicating cMCStatus.success and a signingTime attribute. indicating cMCStatus.success and a signingTime
(2 in Figure 3). The GLA also takes administrative attribute. (2 in Figure 3). The GLA also takes
actions, which are beyond the scope of this document, to administrative actions, which are beyond the scope of
store the glName, glAddress, glKeyAttributes, this document, to store the glName, glAddress,
glOwnerName, and glOwnerAddress. The GLA also sends a glKeyAttributes, glOwnerName, and glOwnerAddress.
glKey message as described in section 5. 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 2.d.2.e.1 - The GLA can apply confidentiality to the response
encapsulating the SignedData.PKIResponse in an by encapsulating the SignedData.PKIResponse in an
EnvelopedData if the request was encapsulated in an EnvelopedData if the request was encapsulated in
EnvelopedData (see section 3.2.1.2). an EnvelopedData (see Section 3.2.1.2).
2.d.2.e.2 - The GLA can also optionally apply another SignedData 2.d.2.e.2 - The GLA can also optionally apply another
over the EnvelopedData (see section 3.2.1.2). SignedData over the EnvelopedData (see Section
3.2.1.2).
3 - Upon receipt of the cMCStatusInfoExt responses, the GLO checks 3 - Upon receipt of the cMCStatusInfoExt responses, the GLO checks
the signingTime and verifies the GLA signature(s). If an the signingTime and verifies the GLA signature(s). If an
additional SignedData and/or EnvelopedData encapsulates the additional SignedData and/or EnvelopedData encapsulates the
response (see section 3.2.1.2 or 3.2.2), the GLO verifies the response (see Section 3.2.1.2 or 3.2.2), the GLO verifies the
outer signature and/or decrypt the outer layer prior to outer signature and/or decrypts the outer layer prior to
verifying the signature on the inner most SignedData. verifying the signature on the innermost SignedData.
3.a - If the signingTime attribute value is not within the locally 3.a - If the signingTime attribute value is not within the locally
accepted time window, the GLO MAY return a response accepted time window, the GLO MAY return a response
indicating cMCStatus.failed and otherInfo.failInfo.badTime indicating cMCStatus.failed and otherInfo.failInfo.badTime
and a signingTime attribute. and a signingTime attribute.
3.b - Else if signature processing continues and if the signatures 3.b - Else if signature processing continues and if the signatures
do verify, the GLO MUST check that one of the names in the do verify, the GLO MUST check that one of the names in the
certificate used to sign the response matches the name of certificate used to sign the response matches the name of the
the GL. GL.
3.b.1 - If the name of the GL does not match the name present in 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 the certificate used to sign the message, the GLO should
not believe the response. not believe the response.
3.b.2 - Else if the name of the GL does match the name present in 3.b.2 - Else if the name of the GL does match the name present in
the certificate and: the certificate and:
3.b.2.a - If the signatures do verify and the response was 3.b.2.a - If the signatures do verify and the response was
cMCStatusInfoExt indicating cMCStatus.success, the GLO cMCStatusInfoExt indicating cMCStatus.success, the
has successfully created the GL. GLO has successfully created the GL.
3.b.2.b - Else if the signatures are valid and the response is 3.b.2.b - Else if the signatures are valid and the response is
cMCStatusInfoExt.cMCStatus.failed with any reason, the cMCStatusInfoExt.cMCStatus.failed with any reason,
GLO can reattempt to create the GL using the information the GLO can reattempt to create the GL using the
provided in the response. The GLO can also use the information provided in the response. The GLO can
glaQueryRequest to determine the algorithms and other also use the glaQueryRequest to determine the
characteristics supported by the GLA (see section 4.9). algorithms and other characteristics supported by the
GLA (see Section 4.9).
4.2. Delete GL From GLA 4.2. Delete GL from GLA
From time to time, there are instances when a GL is no longer needed. 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 that protocol In this case, the GLO deletes the GL. Figure 4 depicts the protocol
interactions to delete a GL. Note that behavior for the optional interactions to delete a GL. Note that behavior for the optional
transactionId, senderNonce, and recipientNonce CMC control attributes transactionId, senderNonce, and recipientNonce CMC control attributes
is not addressed in these procedures. is not addressed in these procedures.
+-----+ 1 2 +-----+ +-----+ 1 2 +-----+
| GLA | <-------> | GLO | | GLA | <-------> | GLO |
+-----+ +-----+ +-----+ +-----+
Figure 4 - Delete Group List Figure 4 - Delete Group List
The process is as follows: The process is as follows:
1 - The GLO is responsible for requesting the deletion of the GL. 1 - The GLO is responsible for requesting the deletion of the GL.
The GLO sends a SignedData.PKIData.controlSequence.glDelete The GLO sends a SignedData.PKIData.controlSequence.glDelete
request to the GLA (1 in Figure 4). The name of the GL to be 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 deleted is included in GeneralName. The GLO MUST also include
the signingTime attribute and can also include a transactionId the signingTime attribute and can also include a transactionId
and senderNonce attributes. and senderNonce attributes.
1.a - The GLO can optionally apply confidentiality to the request 1.a - The GLO can optionally apply confidentiality to the request
by encapsulating the SignedData.PKIData in an EnvelopedData by encapsulating the SignedData.PKIData in an EnvelopedData
(see section 3.2.1.2). (see Section 3.2.1.2).
1.b - The GLO MAY optionally apply another SignedData over the 1.b - The GLO MAY optionally apply another SignedData over the
EnvelopedData (see section 3.2.1.2). EnvelopedData (see Section 3.2.1.2).
2 - Upon receipt of the request the GLA checks the signingTime and 2 - Upon receipt of the request, the GLA checks the signingTime and
verifies the signature on the inner most SignedData.PKIData. If verifies the signature on the innermost SignedData.PKIData. If
an additional SignedData and/or EnvelopedData encapsulates the an additional SignedData and/or EnvelopedData encapsulates the
request (see section 3.2.1.2 or 3.2.2), the GLA verifies 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 outer signature and/or decrypts the outer layer prior to
verifying the signature on the inner most SignedData. verifying the signature on the innermost SignedData.
2.a - If the signingTime attribute value is not within the locally 2.a - If the signingTime attribute value is not within the locally
accepted time window, the GLA MAY return a response accepted time window, the GLA MAY return a response
indicating cMCStatus.failed and otherInfo.failInfo.badTime indicating cMCStatus.failed and otherInfo.failInfo.badTime
and a signingTime attribute. and a signingTime attribute.
2.b - Else if signature processing continues and if the signatures 2.b - Else if signature processing continues and if the signatures
cannot be verified, the GLA returns a cMCStatusInfoExt cannot be verified, the GLA returns a cMCStatusInfoExt
response indicating cMCStatus.failed and response indicating cMCStatus.failed and
otherInfo.failInfo.badMessageCheck. Additionally, a otherInfo.failInfo.badMessageCheck. Additionally, a
signingTime attribute is included with the response. signingTime attribute is included with the response.
2.c - Else if the signatures verify, the GLA makes sure the GL is 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 supported by checking the name of the GL matches a glName
stored on the GLA. stored on the GLA.
2.c.1 - If the glName is not supported by the GLA, the GLA returns 2.c.1 - If the glName is not supported by the GLA, the GLA
a response indicating cMCStatusInfoExt with returns a response indicating cMCStatusInfoExt with
cMCStatus.failed and otherInfo.extendedFailInfo.SKDFailInfo cMCStatus.failed and
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
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 otherInfo.extendedFailInfo.SKDFailInfo value of
noGLONameMatch. Additionally, a signingTime attribute is invalidGLName. Additionally, a signingTime attribute is
included with the response. included with the response.
2.c.2.b - Else if the names do match, but the GL cannot be deleted 2.c.2 - Else if the glName is supported by the GLA, the GLA
for other reasons, which the GLA does not wish to ensures that a registered GLO signed the glDelete request
disclose, the GLA returns a response indicating by checking if one of the names present in the digital
cMCStatusInfoExt with cMCStatus.failed and signature certificate used to sign the glDelete request
otherInfo.extendedFailInfo.SKDFailInfo value of matches a registered GLO.
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 2.c.2.a - If the names do not match, the GLA returns a response
cMCStatusInfoExt indicating cMCStatus.success and a indicating cMCStatusInfoExt with cMCStatus.failed and
signingTime attribute (2 in Figure 4). The GLA ought not otherInfo.extendedFailInfo.SKDFailInfo value of
accept further requests for member additions, member noGLONameMatch. Additionally, a signingTime
deletions, or group rekeys for this GL. attribute is included with the response.
2.c.2.c.1 - The GLA can apply confidentiality to the response by 2.c.2.b - Else if the names do match, but the GL cannot be
encapsulating the SignedData.PKIResponse in an deleted for other reasons, which the GLA does not
EnvelopedData if the request was encapsulated in an wish to disclose, the GLA returns a response
EnvelopedData (see section 3.2.1.2). 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.2 - The GLA MAY optionally apply another SignedData over 2.c.2.c - Else if the names do match, the GLA returns a
the EnvelopedData (see section 3.2.1.2). 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.
3 - Upon receipt of the cMCStatusInfoExt response, the GLO checks 2.c.2.c.1 - The GLA can apply confidentiality to the response
the signingTime and verifies the GLA signature(s). If an by encapsulating the SignedData.PKIResponse in an
additional SignedData and/or EnvelopedData encapsulates the EnvelopedData if the request was encapsulated in
response (see section 3.2.1.2 or 3.2.2), the GLO verifies the an EnvelopedData (see Section 3.2.1.2).
outer signature and/or decrypt the outer layer prior to
verifying the signature on the inner most SignedData. 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 3.a - If the signingTime attribute value is not within the locally
accepted time window, the GLO MAY return a response accepted time window, the GLO MAY return a response
indicating cMCStatus.failed and otherInfo.failInfo.badTime indicating cMCStatus.failed and otherInfo.failInfo.badTime
and a signingTime attribute. and a signingTime attribute.
3.b - Else if signature processing continues and if the signatures 3.b - Else if signature processing continues and if the signatures
verify, the GLO checks that one of the names in the verify, the GLO checks that one of the names in the
certificate used to sign the response matches the name of certificate used to sign the response matches the name of the
the GL. GL.
3.b.1 - If the name of the GL does not match the name present in 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 the certificate used to sign the message, the GLO should
not believe the response. not believe the response.
3.b.2 - Else if the name of the GL does match the name present in 3.b.2 - Else if the name of the GL does match the name present in
the certificate and: the certificate and:
3.b.2.a - If the signatures verify and the response was 3.b.2.a - If the signatures verify and the response was
cMCStatusInfoExt indicating cMCStatus.success, the GLO cMCStatusInfoExt indicating cMCStatus.success, the
has successfully deleted the GL. GLO has successfully deleted the GL.
3.b.2.b - Else if the signatures do verify and the response was 3.b.2.b - Else if the signatures do verify and the response was
cMCStatusInfoExt.cMCStatus.failed with any reason, the cMCStatusInfoExt.cMCStatus.failed with any reason,
GLO can reattempt to delete the GL using the information the GLO can reattempt to delete the GL using the
provided in the response. information provided in the response.
4.3. Add Members To GL 4.3. Add Members to GL
To add members to GLs, either the GLO or prospective members use the To add members to GLs, either the GLO or prospective members use the
glAddMember request. The GLA processes GLO and prospective GL member glAddMember request. The GLA processes GLO and prospective GL member
requests differently though. GLOs can submit the request at any time 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 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 request came from a registered GLO, should process it. If a
prospective member sends the request, the GLA needs to determine how prospective member sends the request, the GLA needs to determine how
the GL is administered. When the GLO initially configured the GL, the GL is administered. When the GLO initially configured the GL, it
they set the GL to be unmanaged, managed, or closed (see section set the GL to be unmanaged, managed, or closed (see Section 3.1.1).
3.1.1). In the unmanaged case, the GLA merely processes the member's In the unmanaged case, the GLA merely processes the member's request.
request. For the managed case, the GLA forwards the requests from the In the managed case, the GLA forwards the requests from the
prospective members to the GLO for review. Where there are multiple 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 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 scope of this document. The GLO reviews the request and either
rejects it or submits a reformed request to the GLA. In the closed rejects it or submits a reformed request to the GLA. In the closed
case, the GLA will not accept requests from prospective members. The case, the GLA will not accept requests from prospective members. The
following sections describe the processing for the GLO(s), GLA, and following sections describe the processing for the GLO(s), GLA, and
prospective GL members depending on where the glAddMeber request prospective GL members depending on where the glAddMeber request
originated, either from a GLO or from prospective members. Figure 5 originated, either from a GLO or from prospective members. Figure 5
depicts the protocol interactions for the three options. Note that depicts the protocol interactions for the three options. Note that
the error messages are not depicted. Additionally, note that behavior the error messages are not depicted. Additionally, note that
for the optional transactionId, senderNonce, and recipientNonce CMC behavior for the optional transactionId, senderNonce, and
control attributes is not addressed in these procedures. recipientNonce CMC control attributes is not addressed in these
procedures.
+-----+ 2,B{A} 3 +----------+ +-----+ 2,B{A} 3 +----------+
| GLO | <--------+ +-------> | Member 1 | | GLO | <--------+ +-------> | Member 1 |
+-----+ | | +----------+ +-----+ | | +----------+
1 | | 1 | |
+-----+ <--------+ | 3 +----------+ +-----+ <--------+ | 3 +----------+
| GLA | A +-------> | ... | | GLA | A +-------> | ... |
+-----+ <-------------+ +----------+ +-----+ <-------------+ +----------+
| |
| 3 +----------+ | 3 +----------+
+-------> | Member n | +-------> | Member n |
+----------+ +----------+
Figure 5 - Member Addition Figure 5 - Member Addition
An important decision that needs to be made on a group by group basis 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. 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 Typically, unmanaged GLs should not be rekeyed when a new member is
added, as the overhead associated with rekeying the group becomes added, as the overhead associated with rekeying the group becomes
prohibitive, as the group becomes large. However, managed and closed prohibitive, as the group becomes large. However, managed and closed
GLs can be rekeyed to maintain the confidentiality of the traffic GLs can be rekeyed to maintain the confidentiality of the traffic
sent by group members. An option to rekeying managed or closed GLs 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 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. key. Group rekeying is discussed in Sections 4.5 and 5.
4.3.1. GLO Initiated Additions 4.3.1. GLO Initiated Additions
The process for GLO initiated glAddMember requests is as follows: The process for GLO initiated glAddMember requests is as follows:
1 - The GLO collects the pertinent information for the member(s) to 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 be added (this may be done through an out-of-bands means). The
GLO then sends a SignedData.PKIData.controlSequence with a GLO then sends a SignedData.PKIData.controlSequence with a
separate glAddMember request for each member to the GLA (1 in separate glAddMember request for each member to the GLA (1 in
Figure 5). The GLO includes: the GL name in glName, the Figure 5). The GLO includes the GL name in glName, the member's
member's name in glMember.glMemberName, the member's address in name in glMember.glMemberName, the member's address in
glMember.glMemberAddress, and the member's encryption glMember.glMemberAddress, and the member's encryption certificate
certificate in glMember.certificates.pKC. The GLO can also in glMember.certificates.pKC. The GLO can also include any
include any attribute certificates associated with the member's attribute certificates associated with the member's encryption
encryption certificate in glMember.certificates.aC, and the certificate in glMember.certificates.aC, and the certification
certification path associated with the member's encryption and path associated with the member's encryption and attribute
attribute certificates in glMember.certificates.certPath. The certificates in glMember.certificates.certPath. The GLO MUST
GLO MUST also include the signingTime attribute with this also include the signingTime attribute with this request.
request.
1.a - The GLO can optionally apply confidentiality to the request 1.a - The GLO can optionally apply confidentiality to the request
by encapsulating the SignedData.PKIData in an EnvelopedData by encapsulating the SignedData.PKIData in an EnvelopedData
(see section 3.2.1.2). (see Section 3.2.1.2).
1.b - The GLO can also optionally apply another SignedData over the 1.b - The GLO can also optionally apply another SignedData over the
EnvelopedData (see section 3.2.1.2). EnvelopedData (see Section 3.2.1.2).
2 - Upon receipt of the request, the GLA checks the signingTime and 2 - Upon receipt of the request, the GLA checks the signingTime and
verifies the signature on the inner most SignedData.PKIData. If verifies the signature on the innermost SignedData.PKIData. If
an additional SignedData and/or EnvelopedData encapsulates the an additional SignedData and/or EnvelopedData encapsulates the
request (see section 3.2.1.2 or 3.2.2), the GLA verifies 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 outer signature and/or decrypts the outer layer prior to
verifying the signature on the inner most SignedData. verifying the signature on the innermost SignedData.
2.a - If the signingTime attribute value is not within the locally 2.a - If the signingTime attribute value is not within the locally
accepted time window, the GLA MAY return a response accepted time window, the GLA MAY return a response
indicating cMCStatus.failed and otherInfo.failInfo.badTime indicating cMCStatus.failed and otherInfo.failInfo.badTime
and a signingTime attribute. and a signingTime attribute.
2.b - Else if signature processing continues and if the signatures 2.b - Else if signature processing continues and if the signatures
cannot be verified, the GLA returns a cMCStatusInfoExt cannot be verified, the GLA returns a cMCStatusInfoExt
response indicating cMCStatus.failed and response indicating cMCStatus.failed and
otherInfo.failInfo.badMessageCheck. Additionally, a otherInfo.failInfo.badMessageCheck. Additionally, a
signingTime attribute is included with the response. signingTime attribute is included with the response.
2.c - Else if the signatures verify, the glAddMember request is 2.c - Else if the signatures verify, the glAddMember request is
included in a controlSequence with the glUseKEK request, and included in a controlSequence with the glUseKEK request, and
the processing in section 4.1 item 2.e is successfully the processing in Section 4.1 item 2.d is successfully
completed the GLA returns a cMCStatusInfoExt indicating completed, the GLA returns a cMCStatusInfoExt indicating
cMCStatus.success and a signingTime attribute (2 in Figure cMCStatus.success and a signingTime attribute (2 in Figure
5). 5).
2.c.1 - The GLA can apply confidentiality to the response by 2.c.1 - The GLA can apply confidentiality to the response by
encapsulating the SignedData.PKIData in an EnvelopedData if encapsulating the SignedData.PKIData in an EnvelopedData
the request was encapsulated in an EnvelopedData (see if the request was encapsulated in an EnvelopedData (see
section 3.2.1.2). Section 3.2.1.2).
2.c.2 - The GLA can also optionally apply another SignedData over 2.c.2 - The GLA can also optionally apply another SignedData over
the EnvelopedData (see section 3.2.1.2). the EnvelopedData (see Section 3.2.1.2).
2.d - Else if the signatures verify and the GLAddMember request is 2.d - Else if the signatures verify and the GLAddMember request is
not included in a controlSequence with the GLCreate request, not included in a controlSequence with the GLCreate request,
the GLA makes sure the GL is supported by checking that the the GLA makes sure the GL is supported by checking that the
glName matches a glName stored on the GLA. glName matches a glName stored on the GLA.
2.d.1 - If the glName is not supported by the GLA, the GLA returns 2.d.1 - If the glName is not supported by the GLA, the GLA
a response indicating cMCStatusInfoExt with 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 cMCStatus.failed and
otherInfo.extendedFailInfo.SKDFailInfo value of otherInfo.extendedFailInfo.SKDFailInfo value of
alreadyAMember. Additionally, a signingTime attribute is invalidGLName. Additionally, a signingTime attribute is
included with the response. included with the response.
2.d.2.b - Else if the glMemberName is not present on the GL, the 2.d.2 - Else if the glName is supported by the GLA, the GLA
GLA checks how the GL is administered. checks to see if the glMemberName is present on the GL.
2.d.2.b.1 - If the GL is closed, the GLA checks that a registered 2.d.2.a - If the glMemberName is present on the GL, the GLA
GLO signed the request by checking that one of the returns a response indicating cMCStatusInfoExt with
names in the digital signature certificate used to cMCStatus.failed and
sign the request matches a registered GLO. otherInfo.extendedFailInfo.SKDFailInfo value of
alreadyAMember. Additionally, a signingTime
attribute is included with the response.
2.d.2.b.1.a - If the names do not match, the GLA returns a response 2.d.2.b - Else if the glMemberName is not present on the GL,
indicating cMCStatusInfoExt with cMCStatus.failed and the GLA checks how the GL is administered.
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 2.d.2.b.1 - If the GL is closed, the GLA checks that a
member's encryption certificate. 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.b.1 - If the member's encryption certificate cannot be 2.d.2.b.1.a - If the names do not match, the GLA returns a
verified, the GLA can return a response indicating response indicating cMCStatusInfoExt with
cMCStatusInfoExt with cMCStatus.failed and cMCStatus.failed and
otherInfo.extendedFailInfo.SKDFailInfo value of otherInfo.extendedFailInfo.SKDFailInfo value
invalidCert to the GLO. Additionally, a of noGLONameMatch. Additionally, a
signingTime attribute is included with the signingTime attribute is included with the
response. If the GLA does not return a response.
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 2.d.2.b.1.b - Else if the names match, the GLA verifies the
returns a cMCStatusInfoExt indicating member's encryption certificate.
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 2.d.2.b.1.b.1 - If the member's encryption certificate
by encapsulating the SignedData.PKIData in an cannot be verified, the GLA can return a
EnvelopedData if the request was encapsulated in response indicating cMCStatusInfoExt with
an EnvelopedData (see section 3.2.1.2). cMCStatus.failed and
otherInfo.extendedFailInfo.SKDFailInfo
value of invalidCert to the GLO.
2.d.2.b.1.b.2.b - The GLA can also optionally apply another Additionally, a signingTime attribute is
SignedData over the EnvelopedData (see section included with the response. If the GLA
3.2.1.2). does not return a
cMCStatusInfoExt.cMCStatus.failed
response, the GLA issues a glProvideCert
request (see Section 4.10).
2.d.2.b.2 - Else if the GL is managed, the GLA checks that either a 2.d.2.b.1.b.2 - Else if the member's certificate
registered GLO or the prospective member signed the verifies, the GLA returns a
request. For GLOs, one of the names in the certificate cMCStatusInfoExt indicating
used to sign the request needs to match a registered cMCStatus.success and a signingTime
GLO. For the prospective member, the name in attribute (2 in Figure 5). The GLA also
glMember.glMemberName needs to match one of the names takes administrative actions, which are
in the certificate used to sign the request. 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.2.a - If the signer is neither a registered GLO nor the 2.d.2.b.1.b.2.a - The GLA applies confidentiality to
prospective GL member, the GLA returns a response the response by encapsulating the
indicating cMCStatusInfoExt with cMCStatus.failed and SignedData.PKIData in an
otherInfo.extendedFailInfo.SKDFailInfo value of EnvelopedData if the request was
noSpam. Additionally, a signingTime attribute is encapsulated in an EnvelopedData (see
included with the response. Section 3.2.1.2).
2.d.2.b.2.b - Else if the signer is a registered GLO, the GLA 2.d.2.b.1.b.2.b - The GLA can also optionally apply
verifies the member's encryption certificate. another SignedData over the
EnvelopedData (see Section 3.2.1.2).
2.d.2.b.2.b.1 - If the member's certificate cannot be verified, the 2.d.2.b.2 - Else if the GL is managed, the GLA checks that
GLA can return a response indicating either a registered GLO or the prospective member
cMCStatusInfoExt with cMCStatus.failed and signed the request. For GLOs, one of the names
otherInfo.extendedFailInfo.SKDFailInfo value of in the certificate used to sign the request needs
invalidCert. Additionally, a signingTime attribute to match a registered GLO. For the prospective
is included with the response. If the GLA does not member, the name in glMember.glMemberName needs
return a cMCStatus.failed response, the GLA MUST to match one of the names in the certificate used
issue a glProvideCert request (see section 4.10). to sign the request.
2.d.2.b.2.b.2 - Else if the member's certificate verifies, the GLA 2.d.2.b.2.a - If the signer is neither a registered GLO nor
MUST return a cMCStatusInfoExt indicating the prospective GL member, the GLA returns a
cMCStatus.success and a signingTime attribute to response indicating cMCStatusInfoExt with
the GLO (2 in Figure 5). The GLA also takes cMCStatus.failed and
administrative actions, which are beyond the scope otherInfo.extendedFailInfo.SKDFailInfo value
of this document, to add the member to the GL of noSpam. Additionally, a signingTime
stored on the GLA. The GLA also distributes the attribute is included with the response.
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 2.d.2.b.2.b - Else if the signer is a registered GLO, the
by encapsulating the SignedData.PKIData in an GLA verifies the member's encryption
EnvelopedData if the request was encapsulated in certificate.
an EnvelopedData (see section 3.2.1.2).
2.d.2.b.2.b.2.b - The GLA can also optionally apply another 2.d.2.b.2.b.1 - If the member's certificate cannot be
SignedData over the EnvelopedData (see section verified, the GLA can return a response
3.2.1.2). 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.c - Else if the signer is the prospective member, the GLA 2.d.2.b.2.b.2 - Else if the member's certificate
forwards the glAddMember request (see section verifies, the GLA MUST return a
3.2.3) to a registered GLO (B{A} in Figure 5). If cMCStatusInfoExt indicating
there is more than one registered GLO, the GLO to cMCStatus.success and a signingTime
which the request is forwarded to is beyond the attribute to the GLO (2 in Figure 5).
scope of this document. Further processing of the The GLA also takes administrative
forwarded request by GLOs is addressed in 3 of actions, which are beyond the scope of
section 4.3.2. 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.c.1 - The GLA applies confidentiality to the forwarded 2.d.2.b.2.b.2.a - The GLA applies confidentiality to
request by encapsulating the SignedData.PKIData in the response by encapsulating the
an EnvelopedData if the original request was SignedData.PKIData in an
encapsulated in an EnvelopedData (see section EnvelopedData if the request was
3.2.1.2). encapsulated in an EnvelopedData (see
Section 3.2.1.2).
2.d.2.b.2.c.2 - The GLA can also optionally apply another 2.d.2.b.2.b.2.b - The GLA can also optionally apply
SignedData over the EnvelopedData (see section another SignedData over the
3.2.1.2). EnvelopedData (see Section 3.2.1.2).
2.d.2.b.3 - Else if the GL is unmanaged, the GLA checks that either 2.d.2.b.2.c - Else if the signer is the prospective member,
a registered GLO or the prospective member signed the the GLA forwards the glAddMember request (see
request. For GLOs, one of the names in the certificate Section 3.2.3) to a registered GLO (B{A} in
used to sign the request needs tp match the name of a Figure 5). If there is more than one
registered GLO. For the prospective member, the name registered GLO, the GLO to which the request
in glMember.glMemberName needs to match one of the is forwarded is beyond the scope of this
names in the certificate used to sign the request. document. Further processing of the
forwarded request by GLOs is addressed in 3
of Section 4.3.2.
2.d.2.b.3.a - If the signer is neither a registered GLO nor the 2.d.2.b.2.c.1 - The GLA applies confidentiality to the
prospective member, the GLA returns a response forwarded request by encapsulating the
indicating cMCStatusInfoExt with cMCStatus.failed and SignedData.PKIData in an EnvelopedData if
otherInfo.extendedFailInfo.SKDFailInfo value of the original request was encapsulated in
noSpam. Additionally, a signingTime attribute is an EnvelopedData (see Section 3.2.1.2).
included with the response.
2.d.2.b.3.b - Else if the signer is either a registered GLO or the 2.d.2.b.2.c.2 - The GLA can also optionally apply another
prospective member, the GLA verifies the member's SignedData over the EnvelopedData (see
encryption certificate. Section 3.2.1.2).
2.d.2.b.3.b.1 - If the member's certificate cannot be verified, the 2.d.2.b.3 - Else if the GL is unmanaged, the GLA checks that
GLA can return a response indicating either a registered GLO or the prospective member
cMCStatusInfoExt with cMCStatus.failed and signed the request. For GLOs, one of the names
otherInfo.extendedFailInfo.SKDFailInfo value of in the certificate used to sign the request needs
invalidCert and a signingTime attribute to either to match the name of a registered GLO. For the
the GLO or the prospective member depending on prospective member, the name in
where the request originated. If the GLA does not glMember.glMemberName needs to match one of the
return a cMCStatus.failed response, the GLA issues names in the certificate used to sign the
a glProvideCert request (see section 4.10) to request.
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 2.d.2.b.3.a - If the signer is neither a registered GLO nor
returns a cMCStatusInfoExt indicating the prospective member, the GLA returns a
cMCStatus.success and a signingTime attribute to response indicating cMCStatusInfoExt with
the GLO (2 in Figure 5) if the GLO signed the cMCStatus.failed and
request and to the GL member (3 in Figure 5) if otherInfo.extendedFailInfo.SKDFailInfo value
the GL member signed the request. The GLA also of noSpam. Additionally, a signingTime
takes administrative actions, which are beyond the attribute is included with the response.
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 2.d.2.b.3.b - Else if the signer is either a registered GLO
by encapsulating the SignedData.PKIData in an or the prospective member, the GLA verifies
EnvelopedData if the request was encapsulated in the member's encryption certificate.
an EnvelopedData (see section 3.2.1.2).
2.d.2.b.3.b.2.b - The GLA can also optionally apply another 2.d.2.b.3.b.1 - If the member's certificate cannot be
SignedData over the EnvelopedData (see section verified, the GLA can return a response
3.2.1.2). 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.
3 - Upon receipt of the cMCStatusInfoExt response, the GLO checks 2.d.2.b.3.b.2 - Else if the member's certificate
the signingTime and verifies the GLA signature(s). If an verifies, the GLA returns a
additional SignedData and/or EnvelopedData encapsulates the cMCStatusInfoExt indicating
response (see section 3.2.1.2 or 3.2.2), the GLO verifies the cMCStatus.success and a signingTime
outer signature and/or decrypt the outer layer prior to attribute to the GLO (2 in Figure 5) if
verifying the signature on the inner most SignedData. 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 3.a - If the signingTime attribute value is not within the locally
accepted time window, the GLO MAY return a response accepted time window, the GLO MAY return a response
indicating cMCStatus.failed and otherInfo.failInfo.badTime indicating cMCStatus.failed and otherInfo.failInfo.badTime
and a signingTime attribute. and a signingTime attribute.
3.b - Else if signature processing continues and if the signatures 3.b - Else if signature processing continues and if the signatures
verify, the GLO checks that one of the names in the verify, the GLO checks that one of the names in the
certificate used to sign the response matches the name of certificate used to sign the response matches the name of the
the GL. GL.
3.b.1 - If the name of the GL does not match the name present in 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 the certificate used to sign the message, the GLO should
not believe the response. not believe the response.
3.b.2 - Else if the name of the GL matches the name present in the 3.b.2 - Else if the name of the GL matches the name present in
certificate and: the certificate and:
3.b.2.a - If the signatures verify and the response is 3.b.2.a - If the signatures verify and the response is
cMCStatusInfoExt indicating cMCStatus.success, the GLA cMCStatusInfoExt indicating cMCStatus.success, the
has added the member to the GL. If member was added to a GLA has added the member to the GL. If the member
managed list and the original request was signed by the was added to a managed list and the original request
member, the GLO sends a was signed by the member, the GLO sends a
cMCStatusInfoExt.cMCStatus.success and a signingTime cMCStatusInfoExt.cMCStatus.success and a signingTime
attribute to the GL member. attribute to the GL member.
3.b.2.b - Else if the GLO received a 3.b.2.b - Else if the GLO received a
cMCStatusInfoExt.cMCStatus.failed with any reason, the cMCStatusInfoExt.cMCStatus.failed with any reason,
GLO can reattempt to add the member to the GL using the the GLO can reattempt to add the member to the GL
information provided in the response. using the information provided in the response.
4 - Upon receipt of the cMCStatusInfoExt response, the prospective 4 - Upon receipt of the cMCStatusInfoExt response, the prospective
member checks the signingTime and verifies the GLA signatures member checks the signingTime and verifies the GLA signatures or
or GLO signatures. If an additional SignedData and/or GLO signatures. If an additional SignedData and/or EnvelopedData
EnvelopedData encapsulates the response (see section 3.2.1.2 or encapsulates the response (see Section 3.2.1.2 or 3.2.2), the GLO
3.2.2), the GLO verifies the outer signature and/or decrypt the verifies the outer signature and/or decrypts the outer layer
outer layer prior to verifying the signature on the inner most prior to verifying the signature on the innermost SignedData.
SignedData.
4.a - If the signingTime attribute value is not within the locally 4.a - If the signingTime attribute value is not within the locally
accepted time window, the prospective member MAY return a accepted time window, the prospective member MAY return a
response indicating cMCStatus.failed and response indicating cMCStatus.failed and
otherInfo.failInfo.badTime and a signingTime attribute. otherInfo.failInfo.badTime and a signingTime attribute.
4.b - Else if signature processing continues and if the signatures 4.b - Else if signature processing continues and if the signatures
verify, the GL member checks that one of the names in the verify, the GL member checks that one of the names in the
certificate used to sign the response matches the name of certificate used to sign the response matches the name of the
the GL. GL.
4.b.1 - If the name of the GL does not match the name present in 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 the certificate used to sign the message, the GL member
should not believe the response. should not believe the response.
4.b.2 - Else if the name of the GL matches the name present in the 4.b.2 - Else if the name of the GL matches the name present in the
certificate and: certificate and:
4.b.2.a - If the signatures verify, the prospective member has been 4.b.2.a - If the signatures verify, the prospective member has
added to the GL. been added to the GL.
4.b.2.b - Else if the prospective member received a 4.b.2.b - Else if the prospective member received a
cMCStatusInfoExt.cMCStatus.failed, for any reason, the cMCStatusInfoExt.cMCStatus.failed, for any reason,
prospective member MAY reattempt to add themselves to the the prospective member MAY reattempt to add itself to
GL using the information provided in the response. the GL using the information provided in the
response.
4.3.2. Prospective Member Initiated Additions 4.3.2. Prospective Member Initiated Additions
The process for prospective member initiated glAddMember requests is The process for prospective member initiated glAddMember requests is
as follows: as follows:
1 - The prospective GL member sends a 1 - The prospective GL member sends a
SignedData.PKIData.controlSequence.glAddMember request to the SignedData.PKIData.controlSequence.glAddMember request to the GLA
GLA (A in Figure 5). The prospective GL member includes: the GL (A in Figure 5). The prospective GL member includes: the GL name
name in glName, their name in glMember.glMemberName, their in glName, their name in glMember.glMemberName, their address in
address in glMember.glMemberAddress, and their encryption glMember.glMemberAddress, and their encryption certificate in
certificate in glMember.certificates.pKC. The prospective GL glMember.certificates.pKC. The prospective GL member can also
member can also include any attribute certificates associated include any attribute certificates associated with their
with their encryption certificate in glMember.certificates.aC, encryption certificate in glMember.certificates.aC, and the
and the certification path associated with their encryption and certification path associated with their encryption and attribute
attribute certificates in glMember.certificates.certPath. The certificates in glMember.certificates.certPath. The prospective
prosepective member MUST also include the signingTime attribute member MUST also include the signingTime attribute with this
with this request. request.
1.a - The prospective GL member can optionally apply 1.a - The prospective GL member can optionally apply
confidentiality to the request by encapsulating the confidentiality to the request by encapsulating the
SignedData.PKIData in an EnvelopedData (see section SignedData.PKIData in an EnvelopedData (see Section 3.2.1.2).
3.2.1.2).
1.b - The prospective GL member MAY optionally apply another 1.b - The prospective GL member MAY optionally apply another
SignedData over the EnvelopedData (see section 3.2.1.2). SignedData over the EnvelopedData (see Section 3.2.1.2).
2 - Upon receipt of the request, the GLA verifies the request as 2 - Upon receipt of the request, the GLA verifies the request as per
per 2 in section 4.3.1. 2 in Section 4.3.1.
3 - Upon receipt of the forwarded request, the GLO checks the 3 - Upon receipt of the forwarded request, the GLO checks the
signingTime and verifies the prospective GL member signature on signingTime and verifies the prospective GL member signature on
the inner most SignedData.PKIData and the GLA signature on the the innermost SignedData.PKIData and the GLA signature on the
outer layer. If an EnvelopedData encapsulates the inner most outer layer. If an EnvelopedData encapsulates the innermost
layer (see section 3.2.1.2 or 3.2.2), the GLO decrypts the layer (see Section 3.2.1.2 or 3.2.2), the GLO decrypts the outer
outer layer prior to verifying the signature on the inner most layer prior to verifying the signature on the innermost
SignedData. SignedData.
Note: For cases where the GL is closed and either a) a Note: For cases where the GL is closed and either a) a
prospective member sends directly to the GLO or b) the GLA has prospective member sends directly to the GLO or b) the GLA has
mistakenly forwarded the request to the GLO, the GLO should mistakenly forwarded the request to the GLO, the GLO should first
first determine whether to honor the request. determine whether to honor the request.
3.a - If the signingTime attribute value is not within the locally 3.a - If the signingTime attribute value is not within the locally
accepted time window, the GLO MAY return a response accepted time window, the GLO MAY return a response
indicating cMCStatus.failed and otherInfo.failInfo.badTime. indicating cMCStatus.failed and otherInfo.failInfo.badTime.
3.b - Else if signature processing continues and if the signatures 3.b - Else if signature processing continues and if the signatures
verify, the GLO checks to make sure one of the names in the verify, the GLO checks to make sure one of the names in the
certificate used to sign the request matches the name in certificate used to sign the request matches the name in
glMember.glMemberName. glMember.glMemberName.
3.b.1 - If the names do not match, the GLO sends a 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 SignedData.PKIResponse.controlSequence message back to
the prospective member with the prospective member with
cMCStatusInfoExt.cMCtatus.failed indicating why the cMCStatusInfoExt.cMCStatus.failed indicating why the
prospective member was denied in cMCStatus.statusString. prospective member was denied in
Additionally, a signingTime attribute is included with cMCStausInfo.statusString. This stops people from adding
the response. people to GLs without their permission. Additionally, a
signingTime attribute is included with the response.
3.b.2.b - Else if GLO determines the prospective member is allowed 3.b.2 - Else if the names match, the GLO determines whether the
to join the GL, the GLO verifies the member's encryption prospective member is allowed to be added. The mechanism
certificate. 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.b.1 - If the member's certificate cannot be verified, the GLO 3.b.2.a - If the GLO determines the prospective member is not
returns a SignedData.PKIResponse.controlSequence back allowed to join the GL, the GLO can return a
to the prospective member with SignedData.PKIResponse.controlSequence message back
cMCStatusInfoExt.cMCtatus.failed indicating that the to the prospective member with
member's encryption certificate did not verify in cMCStatusInfoExt.cMCtatus.failed indicating why the
cMCStatus.statusString. Additionally, a signingTime prospective member was denied in
attribute is included with the response. If the GLO cMCStatus.statusString. Additionally, a signingTime
does not return a cMCStatusInfoExt response, the GLO attribute is included with the response.
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 3.b.2.b - Else if the GLO determines the prospective member is
resubmits the glAddMember request (see section 3.2.5) allowed to join the GL, the GLO verifies the member's
to the GLA (1 in Figure 5). encryption certificate.
3.b.2.b.2.a - The GLO applies confidentiality to the new 3.b.2.b.1 - If the member's certificate cannot be verified,
GLAddMember request by encapsulating the the GLO returns a
SignedData.PKIData in an EnvelopedData if the initial SignedData.PKIResponse.controlSequence back to
request was encapsulated in an EnvelopedData (see the prospective member with
section 3.2.1.2). 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.b - The GLO can also optionally apply another SignedData 3.b.2.b.2 - Else if the member's certificate verifies, the
over the EnvelopedData (see section 3.2.1.2). GLO resubmits the glAddMember request (see
Section 3.2.5) to the GLA (1 in Figure 5).
4 - Processing continues as in 2 of section 4.3.1. 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).
4.4. Delete Members From GL 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 To delete members from GLs, either the GLO or members to be removed
use the glDeleteMember request. The GLA processes GLO and members use the glDeleteMember request. The GLA processes the GLO, and
requesting their own removal make requests differently. The GLO can members requesting their own removal make requests differently. The
submit the request at any time to delete members from the GL, and the GLO can submit the request at any time to delete members from the GL,
GLA, once it has verified the request came from a registered GLO, and the GLA, once it has verified the request came from a registered
should delete the member. If a member sends the request, the GLA GLO, should delete the member. If a member sends the request, the
needs to determine how the GL is administered. When the GLO initially GLA needs to determine how the GL is administered. When the GLO
configured the GL, they set the GL to be unmanaged, managed, or initially configured the GL, it set the GL to be unmanaged, managed,
closed (see section 3.1.1). In the unmanaged case, the GLA merely or closed (see Section 3.1.1). In the unmanaged case, the GLA merely
processes the member's request. For the managed case, the GLA processes the member's request. In the managed case, the GLA
forwards the requests from the member to the GLO for review. Where 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 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 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 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 the closed case, the GLA will not accept requests from members. The
following sections describe the processing for the GLO(s), GLA, and following sections describe the processing for the GLO(s), GLA, and
GL members depending on where the request originated, either from a GL members depending on where the request originated, either from a
GLO or from members wanting to be removed. Figure 6 depicts the GLO or from members wanting to be removed. Figure 6 depicts the
protocol interactions for the three options. Note that the error protocol interactions for the three options. Note that the error
messages are not depicted. Additionally, behavior for the optional messages are not depicted. Additionally, behavior for the optional
transactionId, senderNonce, and recipientNonce CMC control attributes transactionId, senderNonce, and recipientNonce CMC control attributes
is not addressed in these procedures. is not addressed in these procedures.
+-----+ 2,B{A} 3 +----------+ +-----+ 2,B{A} 3 +----------+
| GLO | <--------+ +-------> | Member 1 | | GLO | <--------+ +-------> | Member 1 |
+-----+ | | +----------+ +-----+ | | +----------+
1 | | 1 | |
+-----+ <--------+ | 3 +----------+ +-----+ <--------+ | 3 +----------+
| GLA | A +-------> | ... | | GLA | A +-------> | ... |
+-----+ <-------------+ +----------+ +-----+ <-------------+ +----------+
| |
| 3 +----------+ | 3 +----------+
+-------> | Member n | +-------> | Member n |
+----------+ +----------+
Figure 6 - Member Deletion Figure 6 - Member Deletion
If the member is not removed from the GL, they will continue to If the member is not removed from the GL, it will continue to receive
receive and be able to decrypt data protected with the shared KEK and and be able to decrypt data protected with the shared KEK and will
will continue to receive rekeys. For unmanaged lists, there is no continue to receive rekeys. For unmanaged lists, there is no point
point to a group rekey because there is no guarantee that the member to a group rekey because there is no guarantee that the member
requesting to be removed has not already added themselves back on the requesting to be removed has not already added itself back on the GL
GL under a different name. For managed and closed GLs, the GLO needs under a different name. For managed and closed GLs, the GLO needs to
to take steps to ensure the member being deleted is not on the GL 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 twice. After ensuring this, managed and closed GLs can be rekeyed to
maintain the confidentiality of the traffic sent by group members. If maintain the confidentiality of the traffic sent by group members.
the GLO is sure the member has been deleted the group rekey mechanism If the GLO is sure the member has been deleted, the group rekey
can be used to distribute the new key (see sections 4.5 and 5). mechanism can be used to distribute the new key (see Sections 4.5 and
5).
4.4.1. GLO Initiated Deletions 4.4.1. GLO Initiated Deletions
The process for GLO initiated glDeleteMember requests is as follows: The process for GLO initiated glDeleteMember requests is as follows:
1 - The GLO collects the pertinent information for the member(s) to 1 - The GLO collects the pertinent information for the member(s) to
be deleted (this can be done through an out of bands means). be deleted (this can be done through an out-of-band means). The
The GLO then sends a SignedData.PKIData.controlSequence with a GLO then sends a SignedData.PKIData.controlSequence with a
separate glDeleteMember request for each member to the GLA (1 separate glDeleteMember request for each member to the GLA (1 in
in Figure 6). The GLO MUST include: the GL name in glName and Figure 6). The GLO MUST include the GL name in glName and the
the member's name in glMemberToDelete. If the GL from which the member's name in glMemberToDelete. If the GL from which the
member is being deleted in a closed or managed GL, the GLO MUST member is being deleted is a closed or managed GL, the GLO MUST
also generate a glRekey request and include it with the also generate a glRekey request and include it with the
glDeletemember request (see section 4.5). The GLO MUST also glDeletemember request (see Section 4.5). The GLO MUST also
include the signingTime attribute with this request. include the signingTime attribute with this request.
1.a - The GLO can optionally apply confidentiality to the request 1.a - The GLO can optionally apply confidentiality to the request
by encapsulating the SignedData.PKIData in an EnvelopedData by encapsulating the SignedData.PKIData in an EnvelopedData
(see section 3.2.1.2). (see Section 3.2.1.2).
1.b - The GLO can also optionally apply another SignedData over the 1.b - The GLO can also optionally apply another SignedData over the
EnvelopedData (see section 3.2.1.2). EnvelopedData (see Section 3.2.1.2).
2 - Upon receipt of the request, the GLA checks the signingTime 2 - Upon receipt of the request, the GLA checks the signingTime
attribute and verifies the signature on the inner most attribute and verifies the signature on the innermost
SignedData.PKIData. If an additional SignedData and/or SignedData.PKIData. If an additional SignedData and/or
EnvelopedData encapsulates the request (see section 3.2.1.2 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 3.2.2), the GLA verifies the outer signature and/or decrypts the
outer layer prior to verifying the signature on the inner most outer layer prior to verifying the signature on the innermost
SignedData. SignedData.
2.a - If the signingTime attribute value is not within the locally 2.a - If the signingTime attribute value is not within the locally
accepted time window, the GLA MAY return a response accepted time window, the GLA MAY return a response
indicating cMCStatus.failed and otherInfo.failInfo.badTime indicating cMCStatus.failed and otherInfo.failInfo.badTime
and a signingTime attribute. and a signingTime attribute.
2.b - Else if signature processing continues and if the signatures 2.b - Else if signature processing continues and if the signatures
cannot be verified, the GLA returns a cMCStatusInfoExt cannot be verified, the GLA returns a cMCStatusInfoExt
response indicating cMCStatus.failed and response indicating cMCStatus.failed and
otherInfo.failInfo.badMessageCheck. Additionally, a otherInfo.failInfo.badMessageCheck. Additionally, a
signingTime attribute is included with the response. signingTime attribute is included with the response.
2.c - Else if the signatures verify, the GLA makes sure the GL is 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 supported by the GLA by checking that the glName matches a
glName stored on the GLA. glName stored on the GLA.
2.c.1 - If the glName is not supported by the GLA, the GLA returns 2.c.1 - If the glName is not supported by the GLA, the GLA
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 returns a response indicating cMCStatusInfoExt with
cMCStatus.failed and cMCStatus.failed and
otherInfo.extendedFailInfo.SKDFailInfo value of otherInfo.extendedFailInfo.SKDFailInfo value of
notAMember. Additionally, a signingTime attribute is invalidGLName. Additionally, a signingTime attribute is
included with the response. included with the response.
2.c.2.b - Else if the glMemberName is already on the GL, the GLA 2.c.2 - Else if the glName is supported by the GLA, the GLA
checks how the GL is administered. checks to see if the glMemberName is present on the GL.
2.c.2.b.1 - If the GL is closed, the GLA checks that the registered 2.c.2.a - If the glMemberName is not present on the GL, the GLA
GLO signed the request by checking that one of the returns a response indicating cMCStatusInfoExt with
names in the digital signature certificate used to sign cMCStatus.failed and
the request matches the registered GLO. otherInfo.extendedFailInfo.SKDFailInfo value of
notAMember. Additionally, a signingTime attribute is
included with the response.
2.c.2.b.1.a - If the names do not match, the GLA returns a response 2.c.2.b - Else if the glMemberName is already on the GL, the
indicating cMCStatusInfoExt with cMCStatus.failed and GLA checks how the GL is administered.
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 2.c.2.b.1 - If the GL is closed, the GLA checks that the
cMCStatusInfoExt.cMCStatus.success and a signingTime registered GLO signed the request by checking
attribute (2 in Figure 5). The GLA also takes that one of the names in the digital signature
administrative actions, which are beyond the scope of certificate used to sign the request matches the
this document, to delete the member with the GL registered GLO.
stored on the GLA. Note that he 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 2.c.2.b.1.a - If the names do not match, the GLA returns a
encapsulating the SignedData.PKIData in an response indicating cMCStatusInfoExt with
EnvelopedData if the request was encapsulated in cMCStatus.failed and
an EnvelopedData (see section 3.2.1.2). otherInfo.extendedFailInfo.SKDFailInfo value
of closedGL. Additionally, a signingTime
attribute is included with the response.
2.c.2.b.1.b.2 - The GLA can also optionally apply another 2.c.2.b.1.b - Else if the names do match, the GLA returns a
SignedData over the EnvelopedData (see section cMCStatusInfoExt.cMCStatus.success and a
3.2.1.2). 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.2 - Else if the GL is managed, the GLA checks that either a 2.c.2.b.1.b.1 - The GLA applies confidentiality to the
registered GLO or the prospective member signed the response by encapsulating the
request. For GLOs, one of the names in the certificate SignedData.PKIData in an EnvelopedData if
used to sign the request needs to match a registered the request was encapsulated in an
GLO. For the prospective member, the name in EnvelopedData (see Section 3.2.1.2).
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 2.c.2.b.1.b.2 - The GLA can also optionally apply another
prospective GL member, the GLA returns a response SignedData over the EnvelopedData (see
indicating cMCStatusInfoExt with cMCStatus.failed and Section 3.2.1.2).
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 2.c.2.b.2 - Else if the GL is managed, the GLA checks that
returns a cMCStatusInfoExt.cMCStatus.success and a either a registered GLO or the prospective member
signingTime attribute(2 in Figure 6). The GLA also signed the request. For GLOs, one of the names
takes administrative actions, which are beyond the in the certificate used to sign the request needs
scope of this document, to delete the member with the to match a registered GLO. For the prospective
GL stored on the GLA. Note that the GL will also be member, the name in glMember.glMemberName needs
rekeyed as described in section 5. to match one of the names in the certificate used
to sign the request.
2.c.2.b.2.b.1 - The GLA applies confidentiality to the response by 2.c.2.b.2.a - If the signer is neither a registered GLO nor
encapsulating the SignedData.PKIData in an the prospective GL member, the GLA returns a
EnvelopedData if the request was encapsulated in response indicating cMCStatusInfoExt with
an EnvelopedData (see section 3.2.1.2). cMCStatus.failed and
otherInfo.extendedFailInfo.SKDFailInfo value
of noSpam. Additionally, a signingTime
attribute is included with the response.
2.c.2.b.2.b.2 - The GLA can also optionally apply another 2.c.2.b.2.b - Else if the signer is a registered GLO, the
SignedData over the EnvelopedData (see section GLA returns a
3.2.1.2). 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.c - Else if the signer is the prospective member, the GLA 2.c.2.b.2.b.1 - The GLA applies confidentiality to the
forwards the glDeleteMember request (see section response by encapsulating the
3.2.3) to the GLO (B{A} in Figure 6). If there is SignedData.PKIData in an EnvelopedData if
more than one registered GLO, the GLO to which the the request was encapsulated in an
request is forwarded to is beyond the scope of this EnvelopedData (see Section 3.2.1.2).
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 2.c.2.b.2.b.2 - The GLA can also optionally apply another
request by encapsulating the SignedData.PKIData in an SignedData over the EnvelopedData (see
EnvelopedData if the request was encapsulated in an Section 3.2.1.2).
EnvelopedData (see section 3.2.1.2).
2.c.2.b.2.c.2 - The GLA can also optionally apply another 2.c.2.b.2.c - Else if the signer is the prospective member,
SignedData over the EnvelopedData (see section the GLA forwards the glDeleteMember request
3.2.1.2). (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.3 - Else if the GL is unmanaged, the GLA checks that either 2.c.2.b.2.c.1 - The GLA applies confidentiality to the
a registered GLO or the prospective member signed the forwarded request by encapsulating the
request. For GLOs, one of the names in the certificate SignedData.PKIData in an EnvelopedData if
used to sign the request needs to match the name of a the request was encapsulated in an
registered GLO. For the prospective member, the name EnvelopedData (see Section 3.2.1.2).
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 2.c.2.b.2.c.2 - The GLA can also optionally apply another
member, the GLA returns a response indicating SignedData over the EnvelopedData (see
cMCStatusInfoExt with cMCStatus.failed and Section 3.2.1.2).
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 2.c.2.b.3 - Else if the GL is unmanaged, the GLA checks that
member, the GLA returns a either a registered GLO or the prospective member
cMCStatusInfoExt.cMCStatus.success and a signingTime signed the request. For GLOs, one of the names
attribute to the GLO (2 in Figure 6) if the GLO in the certificate used to sign the request needs
signed the request and to the GL member (3 in Figure to match the name of a registered GLO. For the
6) if the GL member signed the request. The GLA also prospective member, the name in
takes administrative actions, which are beyond the glMember.glMemberName needs to match one of the
scope of this document, to delete the member with the names in the certificate used to sign the
GL stored on the GLA. request.
2.c.2.b.3.b.1 - The GLA applies confidentiality to the response by 2.c.2.b.3.a - If the signer is neither the GLO nor the
encapsulating the SignedData.PKIData in an prospective member, the GLA returns a
EnvelopedData if the request was encapsulated in response indicating cMCStatusInfoExt with
an EnvelopedData (see section 3.2.1.2). cMCStatus.failed and
otherInfo.extendedFailInfo.SKDFailInfo value
of noSpam. Additionally, a signingTime
attribute is included with the response.
2.c.2.b.3.b.2 - The GLA can also optionally apply another 2.c.2.b.3.b - Else if the signer is either a registered GLO
SignedData over the EnvelopedData (see section or the member, the GLA returns a
3.2.1.2). 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.
3 - Upon receipt of the cMCStatusInfoExt response, the GLO checks 2.c.2.b.3.b.1 - The GLA applies confidentiality to the
the signingTime and verifies the GLA signatures. If an response by encapsulating the
additional SignedData and/or EnvelopedData encapsulates the SignedData.PKIData in an EnvelopedData if
response (see section 3.2.1.2 or 3.2.2), the GLO verifies the the request was encapsulated in an
outer signature and/or decrypt the outer layer prior to EnvelopedData (see Section 3.2.1.2).
verifying the signature on the inner most SignedData.
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 3.a - If the signingTime attribute value is not within the locally
accepted time window, the GLO MAY return a response accepted time window, the GLO MAY return a response
indicating cMCStatus.failed and otherInfo.failInfo.badTime indicating cMCStatus.failed and otherInfo.failInfo.badTime
and a signingTime attribute. and a signingTime attribute.
3.b - Else if signature processing continues and if the signatures 3.b - Else if signature processing continues and if the signatures
do verify, the GLO checks that one of the names in the do verify, the GLO checks that one of the names in the
certificate used to sign the response matches the name of certificate used to sign the response matches the name of the
the GL. GL.
3.b.1 - If the name of the GL does not match the name present in 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 the certificate used to sign the message, the GLO should
not believe the response. not believe the response.
3.b.2 - Else if the name of the GL matches the name present in the 3.b.2 - Else if the name of the GL matches the name present in
certificate and: the certificate and:
3.b.2.a - If the signatures verify and the response is 3.b.2.a - If the signatures verify and the response is
cMCStatusInfoExt.cMCStatus.success, the GLO has deleted cMCStatusInfoExt.cMCStatus.success, the GLO has
the member from the GL. If member was deleted from a deleted the member from the GL. If member was
managed list and the original request was signed by the deleted from a managed list and the original request
member, the GLO sends a was signed by the member, the GLO sends a
cMCStatusInfoExt.cMCStatus.success and a signingTime cMCStatusInfoExt.cMCStatus.success and a signingTime
attribute to the GL member. attribute to the GL member.
3.b.2.b - Else if the GLO received a 3.b.2.b - Else if the GLO received a
cMCStatusInfoExt.cMCStatus.failed with any reason, the cMCStatusInfoExt.cMCStatus.failed with any reason,
GLO may reattempt to delete the member from the GL using the GLO may reattempt to delete the member from the
the information provided in the response. GL using the information provided in the response.
4 - Upon receipt of the cMCStatusInfoExt response, the member 4 - Upon receipt of the cMCStatusInfoExt response, the member checks
checks the signingTime and verifies the GLA signature(s) or GLO the signingTime and verifies the GLA signature(s) or GLO
signature(s). If an additional SignedData and/or EnvelopedData signature(s). If an additional SignedData and/or EnvelopedData
encapsulates the response (see section 3.2.1.2 or 3.2.2), the encapsulates the response (see Section 3.2.1.2 or 3.2.2), the GLO
GLO verifies the outer signature and/or decrypt the outer layer verifies the outer signature and/or decrypts the outer layer
prior to verifying the signature on the inner most SignedData. prior to verifying the signature on the innermost SignedData.
4.a - If the signingTime attribute value is not within the locally 4.a - If the signingTime attribute value is not within the locally
accepted time window, the prospective member MAY return a accepted time window, the prospective member MAY return a
response indicating cMCStatus.failed and response indicating cMCStatus.failed and
otherInfo.failInfo.badTime and a signingTime attribute. otherInfo.failInfo.badTime and a signingTime attribute.
4.b - Else if signature processing continues and if the signatures 4.b - Else if signature processing continues and if the signatures
verify, the GL member checks that one of the names in the verify, the GL member checks that one of the names in the
certificate used to sign the response matches the name of certificate used to sign the response matches the name of the
the GL. GL.
4.b.1 - If the name of the GL does not match the name present in 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 the certificate used to sign the message, the GL member
should not believe the response. should not believe the response.
4.b.2 - Else if the name of the GL matches the name present in the 4.b.2 - Else if the name of the GL matches the name present in
certificate and: the certificate and:
4.b.2.a - If the signature(s) verify, the member has been deleted 4.b.2.a - If the signature(s) verify, the member has been
from the GL. deleted from the GL.
4.b.2.b - Else if the member received a 4.b.2.b - Else if the member received a
cMCStatusInfoExt.cMCStatus.failed with any reason, the cMCStatusInfoExt.cMCStatus.failed with any reason,
member can reattempt to delete themselves from the GL the member can reattempt to delete itself from the GL
using the information provided in the response. using the information provided in the response.
4.4.2. Member Initiated Deletions 4.4.2. Member Initiated Deletions
The process for member initiated deletion of their own membership The process for member initiated deletion of its own membership using
using the glDeleteMember requests is as follows: the glDeleteMember requests is as follows:
1 - The member sends a 1 - The member sends a
SignedData.PKIData.controlSequence.glDeleteMember request to SignedData.PKIData.controlSequence.glDeleteMember request to the
the GLA (A in Figure 6). The member includes: the name of the GLA (A in Figure 6). The member includes the name of the GL in
GL in glName and their own name in glMemberToDelete. The GL glName and the member's own name in glMemberToDelete. The GL
member MUST also include the signingTime attribute with this member MUST also include the signingTime attribute with this
request. request.
1.a - The member can optionally apply confidentiality to the 1.a - The member can optionally apply confidentiality to the
request by encapsulating the SignedData.PKIData in an request by encapsulating the SignedData.PKIData in an
EnvelopedData (see section 3.2.1.2). EnvelopedData (see Section 3.2.1.2).
1.b - The member can also optionally apply another SignedData over 1.b - The member can also optionally apply another SignedData over
the EnvelopedData (see section 3.2.1.2). the EnvelopedData (see Section 3.2.1.2).
2 - Upon receipt of the request, the GLA verifies the request as 2 - Upon receipt of the request, the GLA verifies the request as per
per 2 in section 4.4.1. 2 in Section 4.4.1.
3 - Upon receipt of the forwarded request, the GLO checks the 3 - Upon receipt of the forwarded request, the GLO checks the
signingTime and verifies the member signature on the inner most signingTime and verifies the member signature on the innermost
SignedData.PKIData and the GLA signature on the outer layer. If SignedData.PKIData and the GLA signature on the outer layer. If
an EnvelopedData encapsulates the inner most layer (see section an EnvelopedData encapsulates the innermost layer (see Section
3.2.1.2 or 3.2.2), the GLO decrypts the outer layer prior to 3.2.1.2 or 3.2.2), the GLO decrypts the outer layer prior to
verifying the signature on the inner most SignedData. Note: For verifying the signature on the innermost SignedData.
cases where the GL is closed and either (a) a prospective
member sends directly to the GLO or (b) the GLA has mistakenly Note: For cases where the GL is closed and either (a) a
forwarded the request to the GLO, the GLO should first prospective member sends directly to the GLO or (b) the GLA has
determine whether to honor the request. 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 3.a - If the signingTime attribute value is not within the locally
accepted time window, the GLO MAY return a response accepted time window, the GLO MAY return a response
indicating cMCStatus.failed and otherInfo.failInfo.badTime indicating cMCStatus.failed and otherInfo.failInfo.badTime
and a signingTime attribute. and a signingTime attribute.
3.b - Else if signature processing continues if the signatures 3.b - Else if signature processing continues if the signatures
cannot be verified, the GLO returns a cMCStatusInfoExt cannot be verified, the GLO returns a cMCStatusInfoExt
response indicating cMCStatus.failed and response indicating cMCStatus.failed and
otherInfo.failInfo.badMessageCheck and a signingTime otherInfo.failInfo.badMessageCheck and a signingTime
attribute. attribute.
3.c - Else if the signatures verify, the GLO checks to make sure 3.c - Else if the signatures verify, the GLO checks to make sure
one of the names in the certificates used to sign the one of the names in the certificates used to sign the request
request matches the name in glMemberToDelete. matches the name in glMemberToDelete.
3.c.1 - If the names match, the GLO sends a 3.c.1 - If the names do not match, the GLO sends a
SignedData.PKIResponse.controlSequence message back to the SignedData.PKIResponse.controlSequence message back to
prospective member with cMCStatusInfoExt.cMCtatus.failed the prospective member with
indicating why the prospective member was denied in cMCStatusInfoExt.cMCtatus.failed indicating why the
cMCStatusInfoExt.statusString. This stops people from prospective member was denied in
adding people to GLs without their permission. cMCStatusInfoExt.statusString. This stops people from
Additionally, a signingTime attribute is included with the adding people to GLs without their permission.
response. Additionally, a signingTime attribute is included with
the response.
3.c.2 - Else if the names match, the GLO resubmits the 3.c.2 - Else if the names match, the GLO resubmits the
glDeleteMember request (see section 3.2.5) to the GLA (1 in glDeleteMember request (see Section 3.2.5) to the GLA (1
Figure 6). The GLO makes sure the glMemberName is already in Figure 6). The GLO makes sure the glMemberName is
on the GL. The GLO also generates a glRekey request and already on the GL. The GLO also generates a glRekey
include it with the GLDeleteMember request (see section request and include it with the GLDeleteMember request
4.5). (see Section 4.5).
3.c.2.a - The GLO applies confidentiality to the new GLDeleteMember 3.c.2.a - The GLO applies confidentiality to the new
request by encapsulating the SignedData.PKIData in an GLDeleteMember request by encapsulating the
EnvelopedData if the initial request was encapsulated in SignedData.PKIData in an EnvelopedData if the initial
an EnvelopedData (see section 3.2.1.2). 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 3.c.2.b - The GLO can also optionally apply another SignedData
the EnvelopedData (see section 3.2.1.2). over the EnvelopedData (see Section 3.2.1.2).
4 - Further processing is as in 2 of section 4.4.1. 4 - Further processing is as in 2 of Section 4.4.1.
4.5. Request Rekey Of GL 4.5. Request Rekey of GL
From time to time, the GL will need to be rekeyed. Some situations From time to time, the GL will need to be rekeyed. Some situations
follow: follow:
- When a member is removed from a closed or managed GL. In this - When a member is removed from a closed or managed GL. In this
case, the PKIData.controlSequence containing the glDeleteMember case, the PKIData.controlSequence containing the glDeleteMember
ought to contain a glRekey request. ought to contain a glRekey request.
- Depending on policy, when a member is removed from an unmanaged - Depending on policy, when a member is removed from an unmanaged
GL. If the policy is to rekey the GL, the GL. If the policy is to rekey the GL, the
PKIData.controlSequence containing the glDeleteMember could also PKIData.controlSequence containing the glDeleteMember could also
contain a glRekey request or an out of bands means could be used 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 to tell the GLA to rekey the GL. Rekeying of unmanaged GLs when
members are deleted is not advised. members are deleted is not advised.
- When the current shared KEK has been compromised. - When the current shared KEK has been compromised.
- When the current shared KEK is about to expire. Consider two - When the current shared KEK is about to expire. Consider two
cases: cases:
- If the GLO controls the GL rekey, the GLA should not assume -- If the GLO controls the GL rekey, the GLA should not assume
that a new shared KEK should be distributed, but instead wait that a new shared KEK should be distributed, but instead wait
for the glRekey message. for the glRekey message.
- If the GLA controls the GL rekey, the GLA should initiate a -- If the GLA controls the GL rekey, the GLA should initiate a
glKey message as specified in section 5. glKey message as specified in Section 5.
If the generationCounter (see section 3.1.1) is set to a value 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 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. 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) To be on the safe side, the GLO ought to request a rekey one (1)
duration before the last shared KEK expires. duration before the last shared KEK expires.
The GLA and GLO are the only entities allowed to initiate a GL rekey. 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 GLO indicated whether they are going to control rekeys or whether
the GLA is going to control rekeys when they assigned the shared KEK 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. 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 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 of the shared KEK (the length of time before the
expiration is an implementation decision). The GLA can also expiration is an implementation decision). The GLA can also
automatically rekey GLs that have been compromised, but this is automatically rekey GLs that have been compromised, but this is
covered in section 5. Figure 7 depicts the protocol interactions to covered in Section 5. Figure 7 depicts the protocol interactions to
request a GL rekey. Note that error messages are not depicted. request a GL rekey. Note that error messages are not depicted.
Additionally, behavior for the optional transactionId, senderNonce, Additionally, behavior for the optional transactionId, senderNonce,
and recipientNonce CMC control attributes is not addressed in these and recipientNonce CMC control attributes is not addressed in these
procedures. procedures.
+-----+ 1 2,A +-----+ +-----+ 1 2,A +-----+
| GLA | <-------> | GLO | | GLA | <-------> | GLO |
+-----+ +-----+ +-----+ +-----+
Figure 7 - GL Rekey Request Figure 7 - GL Rekey Request
4.5.1. GLO Initiated Rekey Requests 4.5.1. GLO Initiated Rekey Requests
The process for GLO initiated glRekey requests is as follows: The process for GLO initiated glRekey requests is as follows:
1 - The GLO sends a SignedData.PKIData.controlSequence.glRekey 1 - The GLO sends a SignedData.PKIData.controlSequence.glRekey
request to the GLA (1 in Figure 7). The GLO includes the request to the GLA (1 in Figure 7). The GLO includes the glName.
glName. If glAdministration and glKeyNewAttributes are omitted If glAdministration and glKeyNewAttributes are omitted then there
then there is no change from the previously registered GL is no change from the previously registered GL values for these
values for these fields. If the GLO wants to force a rekey for fields. If the GLO wants to force a rekey for all outstanding
all outstanding shared KEKs it includes the glRekeyAllGLKeys shared KEKs, it includes the glRekeyAllGLKeys set to TRUE. The
set to TRUE. The GLO MUST also include a signingTime attribute GLO MUST also include a signingTime attribute with this request.
is included with this request.
1.a - The GLO can optionally apply confidentiality to the request 1.a - The GLO can optionally apply confidentiality to the request
by encapsulating the SignedData.PKIData in an EnvelopedData by encapsulating the SignedData.PKIData in an EnvelopedData
(see section 3.2.1.2). (see Section 3.2.1.2).
1.b - The GLO can also optionally apply another SignedData over the 1.b - The GLO can also optionally apply another SignedData over the
EnvelopedData (see section 3.2.1.2). EnvelopedData (see Section 3.2.1.2).
2 - Upon receipt of the request, the GLA checks the signingTime and 2 - Upon receipt of the request, the GLA checks the signingTime and
verifies the signature on the inner most SignedData.PKIData. If verifies the signature on the innermost SignedData.PKIData. If
an additional SignedData and/or EnvelopedData encapsulates the an additional SignedData and/or EnvelopedData encapsulates the
request (see section 3.2.1.2 or 3.2.2), the GLA verifies 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 outer signature and/or decrypts the outer layer prior to
verifying the signature on the inner most SignedData. verifying the signature on the innermost SignedData.
2.a - If the signingTime attribute value is not within the locally 2.a - If the signingTime attribute value is not within the locally
accepted time window, the GLA MAY return a response accepted time window, the GLA MAY return a response
indicating cMCStatus.failed and otherInfo.failInfo.badTime indicating cMCStatus.failed and otherInfo.failInfo.badTime
and a signingTime attribute. and a signingTime attribute.
2.b - Else if signature processing continues and if the signatures 2.b - Else if signature processing continues and if the signatures
do not verify, the GLA returns a cMCStatusInfoExt response do not verify, the GLA returns a cMCStatusInfoExt response
indicating cMCStatus.failed and indicating cMCStatus.failed and
otherInfo.failInfo.badMessageCheck. Additionally, a otherInfo.failInfo.badMessageCheck. Additionally, a
signingTime attribute is included with the response. signingTime attribute is included with the response.
2.c - Else if the signatures do verify, the GLA makes sure the GL 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 is supported by the GLA by checking that the glName matches a
a glName stored on the GLA. 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 2.c.1 - If the glName present does not match a GL stored on the
indicating cMCStatusInfoExt with cMCStatus.failed and GLA, the GLA returns a response indicating
cMCStatusInfoExt with cMCStatus.failed and
otherInfo.extendedFailInfo.SKDFailInfo value of otherInfo.extendedFailInfo.SKDFailInfo value of
noGLONameMatch. Additionally, a signingTime attribute is invalidGLName. Additionally, a signingTime attribute is
included with the response. included with the response.
2.c.2.b - Else if the names match, the GLA checks the 2.c.2 - Else if the glName present matches a GL stored on the
glNewKeyAttribute values. 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.b.1 - If the new value for requestedAlgorithm is not 2.c.2.a - If the names do not match, the GLA returns a response
supported, the GLA returns a response indicating indicating cMCStatusInfoExt with cMCStatus.failed and
cMCStatusInfoExt with cMCStatus.failed and otherInfo.extendedFailInfo.SKDFailInfo value of
otherInfo.extendedFailInfo.SKDFailInfo value of noGLONameMatch. Additionally, a signingTime
unsupportedAlgorithm. Additionally, a signingTime attribute is included with the response.
attribute is included with the response.
2.c.2.b.2 - Else if the new value duration is not supportable, 2.c.2.b - Else if the names match, the GLA checks the
determining this is beyond the scope this document, glNewKeyAttribute values.
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, 2.c.2.b.1 - If the new value for requestedAlgorithm is not
which the GLA does not wish to disclose, the GLA supported, the GLA returns a response indicating
returns a response indicating cMCStatusInfoExt with cMCStatusInfoExt with cMCStatus.failed and
cMCStatus.failed and otherInfo.extendedFailInfo.SKDFailInfo value of
otherInfo.extendedFailInfo.SKDFailInfo value of unsupportedAlgorithm. Additionally, a
unspecified. Additionally, a signingTime attribute is signingTime attribute is included with the
included with the response. response.
2.c.2.b.4 - Else if the new requestedAlgorithm and duration are 2.c.2.b.2 - Else if the new value duration is not supportable
supportable or the glNewKeyAttributes was omitted, the (determining this is beyond the scope of this
GLA returns a cMCStatusInfoExt.cMCStatus.success and a document), the GLA returns a response indicating
sigingTime attribute (2 in Figure 7). The GLA also cMCStatusInfoExt with cMCStatus.failed and
uses the glKey message to distribute the rekey shared otherInfo.extendedFailInfo.SKDFailInfo value of
KEK (see section 5). unsupportedDuration. Additionally, a signingTime
attribute is included with the response.
2.c.2.b.4.a - The GLA applies confidentiality to response by 2.c.2.b.3 - Else if the GL is not supportable for other
encapsulating the SignedData.PKIData in an reasons that the GLA does not wish to disclose,
EnvelopedData if the request was encapsulated in an the GLA returns a response indicating
EnvelopedData (see section 3.2.1.2). 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.b - The GLA can also optionally apply another SignedData 2.c.2.b.4 - Else if the new requestedAlgorithm and duration
over the EnvelopedData (see section 3.2.1.2). 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).
3 - Upon receipt of the cMCStatusInfoExt response, the GLO checks 2.c.2.b.4.a - The GLA applies confidentiality to response
the signingTime and verifies the GLA signature(s). If an by encapsulating the SignedData.PKIData in an
additional SignedData and/or EnvelopedData encapsulates the EnvelopedData if the request was encapsulated
forwarded response (see section 3.2.1.2 or 3.2.2), the GLO in an EnvelopedData (see Section 3.2.1.2).
verifies the outer signature and/or decrypt the forwarded
response prior to verifying the signature on the inner most 2.c.2.b.4.b - The GLA can also optionally apply another
SignedData. 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 3.a - If the signingTime attribute value is not within the locally
accepted time window, the GLA MAY return a response accepted time window, the GLA MAY return a response
indicating cMCStatus.failed and otherInfo.failInfo.badTime indicating cMCStatus.failed and otherInfo.failInfo.badTime
and a signingTime attribute. and a signingTime attribute.
3.b - Else if signature processing continues and if the signatures 3.b - Else if signature processing continues and if the signatures
verify, the GLO checks that one of the names in the verify, the GLO checks that one of the names in the
certificate used to sign the response matches the name of certificate used to sign the response matches the name of the
the GL. GL.
3.b.1 - If the name of the GL does not match the name present in 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 the certificate used to sign the message, the GLO should
not believe the response. not believe the response.
3.b.2 - Else if the name of the GL matches the name present in the 3.b.2 - Else if the name of the GL matches the name present in
certificate and: the certificate and:
3.b.2.a - If the signatures verify and the response is 3.b.2.a - If the signatures verify and the response is
cMCStatusInfoExt.cMCStatus.success, the GLO has cMCStatusInfoExt.cMCStatus.success, the GLO has
successfully rekeyed the GL. successfully rekeyed the GL.
3.b.2.b - Else if the GLO received a 3.b.2.b - Else if the GLO received a
cMCStatusInfoExt.cMCStatus.failed with any reason, the cMCStatusInfoExt.cMCStatus.failed with any reason,
GLO can reattempt to rekey the GL using the information the GLO can reattempt to rekey the GL using the
provided in the response. information provided in the response.
4.5.2. GLA Initiated Rekey Requests 4.5.2. GLA Initiated Rekey Requests
If the GLA is in charge of rekeying the GL the GLA will automatically 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 issue a glKey message (see Section 5). In addition the GLA will
generate a cMCStatusInfoExt to indicate to the GL that a successful generate a cMCStatusInfoExt to indicate to the GL that a successful
rekey has occurred. The process for GLA initiated rekey is as rekey has occurred. The process for GLA initiated rekey is as
follows: follows:
1 - The GLA generates for all GLOs a 1 - The GLA generates for all GLOs a
SignedData.PKIData.controlSequence.cMCStatusInfoExt.cMCStatus. SignedData.PKIData.controlSequence.cMCStatusInfoExt.cMCStatus
success and includes a signingTime attribute (A in Figure 7). success and includes a signingTime attribute (A in Figure 7).
1.a - The GLA can optionally apply confidentiality to the request 1.a - The GLA can optionally apply confidentiality to the request
by encapsulating the SignedData.PKIData in an EnvelopedData by encapsulating the SignedData.PKIData in an EnvelopedData
(see section 3.2.1.2). (see Section 3.2.1.2).
1.b - The GLA can also optionally apply another SignedData over the 1.b - The GLA can also optionally apply another SignedData over the
EnvelopedData (see section 3.2.1.2). EnvelopedData (see Section 3.2.1.2).
2 - Upon receipt of the cMCStatusInfoExt.cMCStatus.success 2 - Upon receipt of the cMCStatusInfoExt.cMCStatus.success response,
response, the GLO checks the signingTime and verifies the GLA the GLO checks the signingTime and verifies the GLA signature(s).
signature(s). If an additional SignedData and/or EnvelopedData If an additional SignedData and/or EnvelopedData encapsulates the
encapsulates the forwarded response (see section 3.2.1.2 or forwarded response (see Section 3.2.1.2 or 3.2.2), the GLO MUST
3.2.2), the GLO MUST verify the outer signature and/or decrypt verify the outer signature and/or decrypt the outer layer prior
the outer layer prior to verifying the signature on the inner to verifying the signature on the innermost SignedData.
most SignedData.
2.a - If the signingTime attribute value is not within the locally 2.a - If the signingTime attribute value is not within the locally
accepted time window, the GLO MAY return a response accepted time window, the GLO MAY return a response
indicating cMCStatus.failed and otherInfo.failInfo.badTime indicating cMCStatus.failed and otherInfo.failInfo.badTime
and a signingTime attribute. and a signingTime attribute.
2.b - Else if signature processing continues and if the signatures 2.b - Else if signature processing continues and if the signatures
verify, the GLO checks that one of the names in the verify, the GLO checks that one of the names in the
certificate used to sign the response matches the name of certificate used to sign the response matches the name of the
the GL. GL.
2.b.1 - If the name of the GL does not match the name present in 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 the certificate used to sign the message, the GLO ought
believe the response. not believe the response.
2.b.2 - Else if the name of the GL does match the name present in 2.b.2 - Else if the name of the GL does match the name present in
the certificate and and the response is the certificate and the response is
cMCStatusInfoExt.cMCStatus.success, the GLO knows the GLA cMCStatusInfoExt.cMCStatus.success, the GLO knows the GLA
has successfully rekeyed the GL. has successfully rekeyed the GL.
4.6. Change GLO 4.6. Change GLO
Management of managed and closed GLs can become difficult for one GLO Management of managed and closed GLs can become difficult for one GLO
if the GL membership grows large. To support distributing the if the GL membership grows large. To support distributing the
workload, GLAs support having GLs be managed by multiple GLOs. The workload, GLAs support having GLs be managed by multiple GLOs. The
glAddOwner and glRemoveOwner messages are designed to support adding glAddOwner and glRemoveOwner messages are designed to support adding
and removing registered GLOs. Figure 8 depicts the protocol and removing registered GLOs. Figure 8 depicts the protocol
interactions to send glAddOwner and glRemoveOwner messages and the interactions to send glAddOwner and glRemoveOwner messages and the
resulting response messages. Note that error messages are not shown. resulting response messages. Note that error messages are not shown.
Additionally, behavior for the optional transactionId, senderNonce, Additionally, behavior for the optional transactionId, senderNonce,
and recipientNonce CMC control attributes is not addressed in these and recipientNonce CMC control attributes is not addressed in these
procedures. procedures.
+-----+ 1 2 +-----+ +-----+ 1 2 +-----+
| GLA | <-------> | GLO | | GLA | <-------> | GLO |
+-----+ +-----+ +-----+ +-----+
Figure 8 - GLO Add & Delete Owners Figure 8 - GLO Add and Delete Owners
The process for glAddOwner and glDeleteOwner is as follows: The process for glAddOwner and glDeleteOwner is as follows:
1 - The GLO sends a SignedData.PKIData.controlSequence.glAddOwner 1 - The GLO sends a SignedData.PKIData.controlSequence.glAddOwner or
or glRemoveOwner request to the GLA (1 in Figure 8). The GLO glRemoveOwner request to the GLA (1 in Figure 8). The GLO
includes: the GL name in glName, the name and address of the includes the GL name in glName, and the name and address of the
GLO in glOwnerName and glOwnerAddress, respectively. The GLO GLO in glOwnerName and glOwnerAddress, respectively. The GLO
MUST also include the signingTime attribute with this request. MUST also include the signingTime attribute with this request.
1.a - The GLO can optionally apply confidentiality to the request 1.a - The GLO can optionally apply confidentiality to the request
by encapsulating the SignedData.PKIData in an EnvelopedData by encapsulating the SignedData.PKIData in an EnvelopedData
(see section 3.2.1.2). (see Section 3.2.1.2).
1.b - The GLO can also optionally apply another SignedData over the 1.b - The GLO can also optionally apply another SignedData over the
EnvelopedData (see section 3.2.1.2). EnvelopedData (see Section 3.2.1.2).
2 - Upon receipt of the glAddOwner or glRemoveOwner request, the 2 - Upon receipt of the glAddOwner or glRemoveOwner request, the GLA
GLA checks the signingTime and verifies the GLO signature(s). checks the signingTime and verifies the GLO signature(s). If an
If an additional SignedData and/or EnvelopedData encapsulates additional SignedData and/or EnvelopedData encapsulates the
the request (see section 3.2.1.2 or 3.2.2), the GLA verifies request (see Section 3.2.1.2 or 3.2.2), the GLA verifies the
the outer signature and/or decrypt the outer layer prior to outer signature and/or decrypts the outer layer prior to
verifying the signature on the inner most SignedData. verifying the signature on the innermost SignedData.
2.a - If the signingTime attribute value is not within the locally 2.a - If the signingTime attribute value is not within the locally
accepted time window, the GLA MAY return a response accepted time window, the GLA MAY return a response
indicating cMCStatus.failed and otherInfo.failInfo.badTime indicating cMCStatus.failed and otherInfo.failInfo.badTime
and a signingTime attribute. and a signingTime attribute.
2.b - Else if signature processing continues and if the signatures 2.b - Else if signature processing continues and if the signatures
cannot verified, the GLA returns a cMCStatusInfoExt response cannot be verified, the GLA returns a cMCStatusInfoExt
indicating cMCStatus.failed and response indicating cMCStatus.failed and
otherInfo.failInfo.badMessageCheck. Additionally, a otherInfo.failInfo.badMessageCheck. Additionally, a
signingTime attribute is included with the response. signingTime attribute is included with the response.
2.c - Else if the signatures verify, the GLA makes sure the GL is 2.c - Else if the signatures verify, the GLA makes sure the GL is
supported by checking that the glName matches a glName supported by checking that the glName matches a glName stored
stored on the GLA. 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
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 2.c.1 - If the glName is not supported by the GLA, the GLA
indicating cMCStatusInfoExt with cMCStatus.failed and returns a response indicating cMCStatusInfoExt with
cMCStatus.failed and
otherInfo.extendedFailInfo.SKDFailInfo value of otherInfo.extendedFailInfo.SKDFailInfo value of
noGLONameMatch. Additionally, a signingTime attribute is invalidGLName. Additionally, a signingTime attribute is
included with the response. included with the response.
2.c.2.b - Else if the names match, the GLA returns a 2.c.2 - Else if the glName is supported by the GLA, the GLA
cMCStatusInfoExt.cMCStatus.success and a signingTime ensures that a registered GLO signed the glAddOwner or
attribute (2 in Figure 4). The GLA also takes glRemoveOwner request by checking that one of the names
administrative actions to associate the new glOwnerName present in the digital signature certificate used to sign
with the GL in the case of glAddOwner or to disassociate the glAddOwner or glDeleteOwner request matches the name
the old glOwnerName with the GL in the cased of of a registered GLO.
glRemoveOwner.
2.c.2.b.1 - The GLA applies confidentiality to the response by 2.c.2.a - If the names do not match, the GLA returns a response
encapsulating the SignedData.PKIResponse in an indicating cMCStatusInfoExt with cMCStatus.failed and
EnvelopedData if the request was encapsulated in an otherInfo.extendedFailInfo.SKDFailInfo value of
EnvelopedData (see section 3.2.1.2). noGLONameMatch. Additionally, a signingTime
attribute is included with the response.
2.c.2.b.2 - The GLA can also optionally apply another SignedData 2.c.2.b - Else if the names match, the GLA returns a
over the EnvelopedData (see section 3.2.1.2). 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.
3 - Upon receipt of the cMCStatusInfoExt response, the GLO checks 2.c.2.b.1 - The GLA applies confidentiality to the response
the signingTime and verifies the GLA's signature(s). If an by encapsulating the SignedData.PKIResponse in an
additional SignedData and/or EnvelopedData encapsulates the EnvelopedData if the request was encapsulated in
response (see section 3.2.1.2 or 3.2.2), the GLO verifies the an EnvelopedData (see Section 3.2.1.2).
outer signature and/or decrypt the outer layer prior to
verifying the signature on the inner most SignedData. 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 3.a - If the signingTime attribute value is not within the locally
accepted time window, the GLO MAY return a response accepted time window, the GLO MAY return a response
indicating cMCStatus.failed and otherInfo.failInfo.badTime indicating cMCStatus.failed and otherInfo.failInfo.badTime
and a signingTime attribute. and a signingTime attribute.
3.b - Else if signature processing continues and if the signatures 3.b - Else if signature processing continues and if the signatures
verify, the GLO checks that one of the names in the verify, the GLO checks that one of the names in the
certificate used to sign the response matches the name of certificate used to sign the response matches the name of the
the GL. GL.
3.b.1 - If the name of GL does not match the name present in the 3.b.1 - If the name of the GL does not match the name present in
certificate used to sign the message, the GLO should not the certificate used to sign the message, the GLO should
believe the response. not believe the response.
3.b.2 - Else if the name of the GL does match the name present in 3.b.2 - Else if the name of the GL does match the name present in
the certificate and: the certificate and:
3.b.2.a - If the signatures verify and the response was 3.b.2.a - If the signatures verify and the response was
cMCStatusInfoExt.cMCStatus.success, the GLO has cMCStatusInfoExt.cMCStatus.success, the GLO has
successfully added or removed the GLO. successfully added or removed the GLO.
3.b.2.b - Else if the signatures verify and the response was 3.b.2.b - Else if the signatures verify and the response was
cMCStatusInfoExt.cMCStatus.failed with any reason, the cMCStatusInfoExt.cMCStatus.failed with any reason,
GLO can reattempt to add or delete the GLO using the the GLO can reattempt to add or delete the GLO using
information provided in the response. the information provided in the response.
4.7. Indicate KEK Compromise 4.7. Indicate KEK Compromise
There will be times when the shared KEK is compromised. GL members 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 and GLOs use glkCompromise to tell the GLA that the shared KEK has
been compromised. Figure 9 depicts the protocol interactions for GL been compromised. Figure 9 depicts the protocol interactions for GL
Key Compromise. Note that error messages are not shown. Additionally, Key Compromise. Note that error messages are not shown.
behavior for the optional transactionId, senderNonce, and Additionally, behavior for the optional transactionId, senderNonce,
recipientNonce CMC control attributes is not addressed in these and recipientNonce CMC control attributes is not addressed in these
procedures. procedures.
+-----+ 2{1} 4 +----------+ +-----+ 2{1} 4 +----------+
| GLO | <----------+ +-------> | Member 1 | | GLO | <----------+ +-------> | Member 1 |
+-----+ 5,3{1} | | +----------+ +-----+ 5,3{1} | | +----------+
+-----+ <----------+ | 4 +----------+ +-----+ <----------+ | 4 +----------+
| GLA | 1 +-------> | ... | | GLA | 1 +-------> | ... |
+-----+ <---------------+ +----------+ +-----+ <---------------+ +----------+
| 4 +----------+ | 4 +----------+
+-------> | Member n | +-------> | Member n |
+----------+ +----------+
Figure 9 - GL Key Compromise Figure 9 - GL Key Compromise
4.7.1. GL Member Initiated KEK Compromise Message 4.7.1. GL Member Initiated KEK Compromise Message
The process for GL member initiated glkCompromise messages is as The process for GL member initiated glkCompromise messages is as
follows: follows:
1 - The GL member sends a 1 - The GL member sends a
SignedData.PKIData.controlSequence.glkCompromise request to the SignedData.PKIData.controlSequence.glkCompromise request to the
GLA (1 in Figure 9). The GL member includes the name of the GL GLA (1 in Figure 9). The GL member includes the name of the GL
in GeneralName. The GL member MUST also include the signingTime in GeneralName. The GL member MUST also include the signingTime
attribute with this request. attribute with this request.
1.a - The GL member can optionally apply confidentiality to the 1.a - The GL member can optionally apply confidentiality to the
request by encapsulating the SignedData.PKIData in an request by encapsulating the SignedData.PKIData in an
EnvelopedData (see section 3.2.1.2). The glkCompromise can EnvelopedData (see Section 3.2.1.2). The glkCompromise can
be included in an EnvelopedData generated with the be included in an EnvelopedData generated with the
compromised shared KEK. compromised shared KEK.
1.b - The GL member can also optionally apply another SignedData 1.b - The GL member can also optionally apply another SignedData
over the EnvelopedData (see section 3.2.1.2). over the EnvelopedData (see Section 3.2.1.2).
2 - Upon receipt of the glkCompromise request, the GLA checks the 2 - Upon receipt of the glkCompromise request, the GLA checks the
signingTime and verifies the GL member signature(s). If an signingTime and verifies the GL member signature(s). If an
additional SignedData and/or EnvelopedData encapsulates the additional SignedData and/or EnvelopedData encapsulates the
request (see section 3.2.1.2 or 3.2.2), the GLA verifies 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 outer signature and/or decrypts the outer layer prior to
verifying the signature on the inner most SignedData. verifying the signature on the innermost SignedData.
2.a - If the signingTime attribute value is not within the locally 2.a - If the signingTime attribute value is not within the locally
accepted time window, the GLA MAY return a response accepted time window, the GLA MAY return a response
indicating cMCStatus.failed and otherInfo.failInfo.badTime indicating cMCStatus.failed and otherInfo.failInfo.badTime
and a signingTime attribute. and a signingTime attribute.
2.b - Else if signature processing continues and if the signatures 2.b - Else if signature processing continues and if the signatures
cannotbe verified, the GLA returns a cMCStatusInfoExt cannot be verified, the GLA returns a cMCStatusInfoExt
response indicating cMCStatus.failed and response indicating cMCStatus.failed and
otherInfo.failInfo.badMessageCheck. Additionally, a otherInfo.failInfo.badMessageCheck. Additionally, a
signingTime attribute is included with the response. signingTime attribute is included with the response.
2.c - Else if the signatures verify, the GLA makes sure the GL is 2.c - Else if the signatures verify, the GLA makes sure the GL is
supported by checking that the indicated GL name matches a supported by checking that the indicated GL name matches a
glName stored on the GLA. glName stored on the GLA.
2.c.1 - If the glName is not supported by the GLA, the GLA returns 2.c.1 - If the glName is not supported by the GLA, the GLA
a response indicating cMCStatusInfoExt with returns a response indicating cMCStatusInfoExt with
cMCStatus.failed and otherInfo.extendedFailInfo.SKDFailInfo cMCStatus.failed and
value of invalidGLName. Additionally, a signingTime otherInfo.extendedFailInfo.SKDFailInfo value of
attribute is included with the response. 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 2.c.2 - Else if the glName is supported by the GLA, the GLA
who signed the request. For GLOs, one of the names in the checks who signed the request. For GLOs, one of the
certificate used to sign the request needs to match a names in the certificate used to sign the request needs
registered GLO. For the member, the name in to match a registered GLO. For the member, the name in
glMember.glMemberName needs to match one of the names in glMember.glMemberName needs to match one of the names in
the certificate used to sign the request. the certificate used to sign the request.
2.c.2.a - If the GLO signed the request, the GLA generates a glKey 2.c.2.a - If the GLO signed the request, the GLA generates a
message as described in section 5 to rekey the GL (4 in glKey message as described in Section 5 to rekey the
Figure 9). GL (4 in Figure 9).
2.c.2.b - Else if someone other than the GLO signed the request, 2.c.2.b - Else if someone other than the GLO signed the
the GLA forwards the glkCompromise message (see section request, the GLA forwards the glkCompromise message
3.2.3) to the GLO (2{1} in Figure 9). If there is more (see Section 3.2.3) to the GLO (2{1} in Figure 9).
than one GLO, to which GLO the request is forwarded is If there is more than one GLO, to which GLO the
beyond the scope of this document. Further processing by request is forwarded is beyond the scope of this
the GLO is discussed in section 4.7.2. document. Further processing by the GLO is discussed
in Section 4.7.2.
4.7.2. GLO Initiated KEK Compromise Message 4.7.2. GLO Initiated KEK Compromise Message
The process for GLO initiated glkCompromise messages is as follows: The process for GLO initiated glkCompromise messages is as follows:
1 - The GLO either: 1 - The GLO either:
1.a - Generates the glkCompromise message itself by sending a 1.a - Generates the glkCompromise message itself by sending a
SignedData.PKIData.controlSequence.glkCompromise request to SignedData.PKIData.controlSequence.glkCompromise request to
the GLA (5 in Figure 9). The GLO includes the name of the GL the GLA (5 in Figure 9). The GLO includes the name of the GL
in GeneralName. The GLO MUST also include a signingTime in GeneralName. The GLO MUST also include a signingTime
attribute with this request. attribute with this request.
1.a.1 - The GLO can optionally apply confidentiality to the request 1.a.1 - The GLO can optionally apply confidentiality to the
by encapsulating the SignedData.PKIData in an EnvelopedData request by encapsulating the SignedData.PKIData in an
(see section 3.2.1.2). The glkCompromise can be included in EnvelopedData (see Section 3.2.1.2). The glkCompromise
an EnvelopedData generated with the compromised shared KEK. can be included in an EnvelopedData generated with the
compromised shared KEK.
1.a.2 - The GLO can also optionally apply another SignedData over 1.a.2 - The GLO can also optionally apply another SignedData over
the EnvelopedData (see section 3.2.1.2). the EnvelopedData (see Section 3.2.1.2).
1.b - Otherwise, checks the signingTime and verifies the GLA and GL 1.b - Otherwise, checks the signingTime and verifies the GLA and GL
member signatures on the forwarded glkCompromise message. If member signatures on the forwarded glkCompromise message. If
an additional SignedData and/or EnvelopedData encapsulates an additional SignedData and/or EnvelopedData encapsulates
the request (see section 3.2.1.2 or 3.2.2), the GLO verifies the request (see Section 3.2.1.2 or 3.2.2), the GLO verifies
the outer signature and/or decrypt the outer layer prior to the outer signature and/or decrypts the outer layer prior to
verifying the signature on the inner most SignedData. verifying the signature on the innermost SignedData.
1.b.1 - If the signingTime attribute value is not within the 1.b.1 - If the signingTime attribute value is not within the
locally accepted time window, the GLO MAY return a response locally accepted time window, the GLO MAY return a
indicating cMCStatus.failed and otherInfo.failInfo.badTime response indicating cMCStatus.failed and
and a signingTime attribute. otherInfo.failInfo.badTime and a signingTime attribute.
1.b.2 - Else if signature processing continues and if the 1.b.2 - Else if signature processing continues and if the
signatures cannot be verified, the GLO returns a signatures cannot be verified, the GLO returns a
cMCStatusInfoExt response indicating cMCStatus.failed and cMCStatusInfoExt response indicating cMCStatus.failed and
otherInfo.failInfo.badMessageCheck. Additionally, a otherInfo.failInfo.badMessageCheck. Additionally, a
signingTime attribute is included with the response. signingTime attribute is included with the response.
1.b.2.a - If the signatures verify, the GLO checks the names in the 1.b.2.a - If the signatures verify, the GLO checks that the
certificate match the name of the signer (i.e., the name names in the certificate match the name of the signer
in the certificate used to sign the GL member's request (i.e., the name in the certificate used to sign the
is the GL member). GL member's request is the GL member).
1.b.2.a.1 - If either name does not match, the GLO ought not trust 1.b.2.a.1 - If either name does not match, the GLO ought not
the signer and it ought not forward the message to the trust the signer and it ought not forward the
GLA. message to the GLA.
1.b.2.a.2 - Else if the names match and the signatures verify, the 1.b.2.a.2 - Else if the names match and the signatures
GLO determines whether to forward the glkCompromise verify, the GLO determines whether to forward the
message back to the GLA (3{1} in Figure 9). Further glkCompromise message back to the GLA (3{1} in
processing by the GLA is in 2 of section 4.7.1. The Figure 9). Further processing by the GLA is in 2
GLO can also return a response to the prospective of Section 4.7.1. The GLO can also return a
member with cMCStatusInfoExt.cMCtatus.success response to the prospective member with
indicating that the glkCompromise message was cMCStatusInfoExt.cMCtatus.success indicating that
successfully received. the glkCompromise message was successfully
received.
4.8. Request KEK Refresh 4.8. Request KEK Refresh
There will be times when GL members have unrecoverably lost their There will be times when GL members have irrecoverably lost their
shared KEK. The shared KEK is not compromised and a rekey of the 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 entire GL is not necessary. GL members use the glkRefresh message to
request that the shared KEK(s) be redistributed to them. Figure 10 request that the shared KEK(s) be redistributed to them. Figure 10
depicts the protocol interactions for GL Key Refresh. Note that error depicts the protocol interactions for GL Key Refresh. Note that
messages are not shown. Additionally, behavior for the optional error messages are not shown. Additionally, behavior for the
transactionId, senderNonce, and recipientNonce CMC control attributes optional transactionId, senderNonce, and recipientNonce CMC control
is not addressed in these procedures. attributes is not addressed in these procedures.
+-----+ 1 2 +----------+ +-----+ 1 2 +----------+
| GLA | <-----------> | Member | | GLA | <-----------> | Member |
+-----+ +----------+ +-----+ +----------+
Figure 10 - GL KEK Refresh Figure 10 - GL KEK Refresh
The process for glkRefresh is as follows: The process for glkRefresh is as follows:
1 - The GL member sends a 1 - The GL member sends a
SignedData.PKIData.controlSequence.glkRefresh request to the SignedData.PKIData.controlSequence.glkRefresh request to the GLA
GLA (1 in Figure 10). The GL member includes name of the GL in (1 in Figure 10). The GL member includes name of the GL in
GeneralName. The GL member MUST also include a signingTime GeneralName. The GL member MUST also include a signingTime
attribute with this request. attribute with this request.
1.a - The GL member can optionally apply confidentiality to the 1.a - The GL member can optionally apply confidentiality to the
request by encapsulating the SignedData.PKIData in an request by encapsulating the SignedData.PKIData in an
EnvelopedData (see section 3.2.1.2). EnvelopedData (see Section 3.2.1.2).
1.b - The GL member can also optionally apply another SignedData 1.b - The GL member can also optionally apply another SignedData
over the EnvelopedData (see section 3.2.1.2). over the EnvelopedData (see Section 3.2.1.2).
2 - Upon receipt of the glkRefresh request, the GLA checks the 2 - Upon receipt of the glkRefresh request, the GLA checks the
signingTime and verifies the GL member signature(s). If an signingTime and verifies the GL member signature(s). If an
additional SignedData and/or EnvelopedData encapsulates the additional SignedData and/or EnvelopedData encapsulates the
request (see section 3.2.1.2 or 3.2.2), the GLA verifies 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 outer signature and/or decrypt the outer layer prior to verifying
verifying the signature on the inner most SignedData. the signature on the innermost SignedData.
2.a - If the signingTime attribute value is not within the locally 2.a - If the signingTime attribute value is not within the locally
accepted time window, the GLA MAY return a response accepted time window, the GLA MAY return a response
indicating cMCStatus.failed and otherInfo.failInfo.badTime indicating cMCStatus.failed and otherInfo.failInfo.badTime
and a signingTime attribute. and a signingTime attribute.
2.b - Else if signature processing continues and if the signatures 2.b - Else if signature processing continues and if the signatures
cannot be verified, the GLA returns a cMCStatusInfoExt cannot be verified, the GLA returns a cMCStatusInfoExt
response indicating cMCStatus.failed and response indicating cMCStatus.failed and
otherInfo.failInfo.badMessageCheck. Additionally, a otherInfo.failInfo.badMessageCheck. Additionally, a
signingTime attribute is included with the response. signingTime attribute is included with the response.
2.c - Else if the signatures verify, the GLA makes sure the GL is 2.c - Else if the signatures verify, the GLA makes sure the GL is
supported by checking that the GLGeneralName matches a supported by checking that the GLGeneralName matches a glName
glName stored on the GLA. stored on the GLA.
2.c.1 - If the name of the GL is not supported by the GLA, the GLA 2.c.1 - If the name of the GL is not supported by the GLA, the
returns a response indicating cMCStatusInfoExt with GLA returns a response indicating cMCStatusInfoExt with
cMCStatus.failed and otherInfo.extendedFailInfo.SKDFailInfo cMCStatus.failed and
value of invalidGLName. Additionally, a signingTime otherInfo.extendedFailInfo.SKDFailInfo value of
attribute is included with the response. 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 2.c.2 - Else if the glName is supported by the GLA, the GLA
the GL member is on the GL. ensures that the GL member is on the GL.
2.c.2.a - If the glMemberName is not present on the GL, the GLA 2.c.2.a - If the glMemberName is not present on the GL, the GLA
returns a response indicating cMCStatusInfoExt with returns a response indicating cMCStatusInfoExt with
cMCStatus.failed and cMCStatus.failed and
otherInfo.extendedFailInfo.SKDFailInfo value of noSpam. otherInfo.extendedFailInfo.SKDFailInfo value of
Additionally, a signingTime attribute is included with noSpam. Additionally, a signingTime attribute is
the response. included with the response.
2.c.2.b - Else if the glMemberName is present on the GL, the GLA 2.c.2.b - Else if the glMemberName is present on the GL, the
returns a cMCStatusInfoExt.cMCStatus.success, a GLA returns a cMCStatusInfoExt.cMCStatus.success, a
signingTime attribute, and a glKey message (2 in Figure signingTime attribute, and a glKey message (2 in
10) as described in section 5. Figure 10) as described in Section 5.
4.9. GLA Query Request and Response 4.9. GLA Query Request and Response
There will be certain times when a GLO is having trouble setting up a There will be certain times when a GLO is having trouble setting up a
GL because they do not know the algorithm(s) or some other GL because it does not know the algorithm(s) or some other
characteristic that the GLA supports. There can also be times when characteristic that the GLA supports. There can also be times when
prospective GL members or GL members need to know something about the prospective GL members or GL members need to know something about the
GLA (these requests are not defined in the document). The GLA (these requests are not defined in the document). The
glaQueryRequest and glaQueryResponse message have been defined to glaQueryRequest and glaQueryResponse messages have been defined to
support determining this information. Figure 11 depicts the protocol support determining this information. Figure 11 depicts the protocol
interactions for glaQueryRequest and glaQueryResponse. Note error interactions for glaQueryRequest and glaQueryResponse. Note that
messages are not shown. Additionally, behavior for the optional error messages are not shown. Additionally, behavior for the
transactionId, senderNonce, and recipientNonce CMC control attributes optional transactionId, senderNonce, and recipientNonce CMC control
is not addressed in these procedures. attributes is not addressed in these procedures.
+-----+ 1 2 +------------------+ +-----+ 1 2 +------------------+
| GLA | <-------> | GLO or GL Member | | GLA | <-------> | GLO or GL Member |
+-----+ +------------------+ +-----+ +------------------+
Figure 11 - GLA Query Request & Response Figure 11 - GLA Query Request and Response
The process for glaQueryRequest and glaQueryResponse is as follows: The process for glaQueryRequest and glaQueryResponse is as follows:
1 - The GLO, GL member, or prospective GL member sends a 1 - The GLO, GL member, or prospective GL member sends a
SignedData.PKIData.controlSequence.glaQueryRequest request to SignedData.PKIData.controlSequence.glaQueryRequest request to the
the GLA (1 in Figure 11). The GLO, GL member, or prospective GL GLA (1 in Figure 11). The GLO, GL member, or prospective GL
member indicates the information they are interested in member indicates the information it is interested in receiving
receiving from the GLA. Additionally, a signingTime attribute from the GLA. Additionally, a signingTime attribute is included
is included with this request. with this request.
1.a - The GLO, GL member, or prospective GL member can optionally 1.a - The GLO, GL member, or prospective GL member can optionally
apply confidentiality to the request by encapsulating the apply confidentiality to the request by encapsulating the
SignedData.PKIData in an EnvelopedData (see section SignedData.PKIData in an EnvelopedData (see Section 3.2.1.2).
3.2.1.2).
1.b - The GLO, GL member, or prospective GL member can also 1.b - The GLO, GL member, or prospective GL member can also
optionally apply another SignedData over the EnvelopedData optionally apply another SignedData over the EnvelopedData
(see section 3.2.1.2). (see Section 3.2.1.2).
2 - Upon receipt of the glaQueryRequest, the GLA determines if it 2 - Upon receipt of the glaQueryRequest, the GLA determines if it
accepts glaQueryRequest messages. accepts glaQueryRequest messages.
2.a - If the GLA does not accept glaQueryRequest messages, the GLA 2.a - If the GLA does not accept glaQueryRequest messages, the GLA
returns a cMCStatusInfoExt response indicating returns a cMCStatusInfoExt response indicating
cMCStatus.noSupport and any other information in cMCStatus.noSupport and any other information in
statusString. statusString.
2.b - Else if the GLA does accept GLAQueryRequests, the GLA checks 2.b - Else if the GLA does accept GLAQueryRequests, the GLA checks
the signingTime and verifies the GLO, GL member, or the signingTime and verifies the GLO, GL member, or
prospective GL member signature(s). If an additional prospective GL member signature(s). If an additional
SignedData and/or EnvelopedData encapsulates the request SignedData and/or EnvelopedData encapsulates the request (see
(see section 3.2.1.2 or 3.2.2), the GLA verifies the outer Section 3.2.1.2 or 3.2.2), the GLA verifies the outer
signature and/or decrypt the outer layer prior to verifying signature and/or decrypts the outer layer prior to verifying
the signature on the inner most SignedData. the signature on the innermost SignedData.
2.b.1 - If the signingTime attribute value is not within the 2.b.1 - If the signingTime attribute value is not within the
locally accepted time window, the GLA MAY return a response locally accepted time window, the GLA MAY return a
indicating cMCStatus.failed and otherInfo.failInfo.badTime response indicating cMCStatus.failed and
and a signingTime attribute. otherInfo.failInfo.badTime and a signingTime attribute.
2.b.2 - Else if the signature processing continues and if the 2.b.2 - Else if the signature processing continues and if the
signatures cannot be verified, the GLA returns a signatures cannot be verified, the GLA returns a
cMCStatusInfoExt response indicating cMCStatus.failed and cMCStatusInfoExt response indicating cMCStatus.failed and
otherInfo.failInfo.badMessageCheck. Additionally, a otherInfo.failInfo.badMessageCheck. Additionally, a
signingTime attribute is included with the response. signingTime attribute is included with the response.
2.b.3 - Else if the signatures verify, the GLA returns a 2.b.3 - Else if the signatures verify, the GLA returns a
glaQueryResponse (2 in Figure 11) with the correct response glaQueryResponse (2 in Figure 11) with the correct
if the glaRequestType is supported or return a response if the glaRequestType is supported or returns a
cMCStatusInfoExt response indicating cMCStatus.noSupport if cMCStatusInfoExt response indicating cMCStatus.noSupport
the glaRequestType is not supported. Additionally, a if the glaRequestType is not supported. Additionally, a
signingTime attribute is included with the response. signingTime attribute is included with the response.
2.b.3.a - The GLA applies confidentiality to the response by 2.b.3.a - The GLA applies confidentiality to the response by
encapsulating the SignedData.PKIResponse in an encapsulating the SignedData.PKIResponse in an
EnvelopedData if the request was encapsulated in an EnvelopedData if the request was encapsulated in an
EnvelopedData (see section 3.2.1.2). EnvelopedData (see Section 3.2.1.2).
2.b.3.b - The GLA can also optionally apply another SignedData over 2.b.3.b - The GLA can also optionally apply another SignedData
the EnvelopedData (see section 3.2.1.2). over the EnvelopedData (see Section 3.2.1.2).
3 - Upon receipt of the glaQueryResponse, the GLO, GL member, or 3 - Upon receipt of the glaQueryResponse, the GLO, GL member, or
prospective GL member checks the signingTime and verifies the prospective GL member checks the signingTime and verifies the GLA
GLA signature(s). If an additional SignedData and/or signature(s). If an additional SignedData and/or EnvelopedData
EnvelopedData encapsulates the response (see section 3.2.1.2 or encapsulates the response (see Section 3.2.1.2 or 3.2.2), the
3.2.2), the GLO, GL member, or prospective GL member verifies GLO, GL member, or prospective GL member verifies the outer
the outer signature and/or decrypt the outer layer prior to signature and/or decrypts the outer layer prior to verifying the
verifying the signature on the inner most SignedData. signature on the innermost SignedData.
3.a - If the signingTime attribute value is not within the locally 3.a - If the signingTime attribute value is not within the locally
accepted time window, the GLO, GL member, or prospective GL accepted time window, the GLO, GL member, or prospective GL
member MAY return a response indicating cMCStatus.failed and member MAY return a response indicating cMCStatus.failed and
otherInfo.failInfo.badTime and a signingTime attribute. otherInfo.failInfo.badTime and a signingTime attribute.
3.b - Else if signature processing continues and if the signatures 3.b - Else if signature processing continues and if the signatures
do not verify, the GLO, GL member, or prospective GL member do not verify, the GLO, GL member, or prospective GL member
returns a cMCStatusInfoExt response indicating returns a cMCStatusInfoExt response indicating
cMCStatus.failed and otherInfo.failInfo.badMessageCheck. cMCStatus.failed and otherInfo.failInfo.badMessageCheck.
Additionally, a signingTime attribute is included with the Additionally, a signingTime attribute is included with the
response. response.
3.c - Else if the signatures verify, then the GLO, GL member, or 3.c - Else if the signatures verify, then the GLO, GL member, or
prospective GL member checks that one of the names in the prospective GL member checks that one of the names in the
certificate used to sign the response matches the name of certificate used to sign the response matches the name of the
the GL. GL.
3.c.1 - If the name of the GL does not match the name present in 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 the certificate used to sign the message, the GLO ought
believe the response. not believe the response.
3.c.2 - Else if the name of the GL matches the name present in the 3.c.2 - Else if the name of the GL matches the name present in
certificate and the response was glaQueryResponse, then the the certificate and the response was glaQueryResponse,
GLO, GL member, or prospective GL member may use the then the GLO, GL member, or prospective GL member may use
information contained therein. the information contained therein.
4.10. Update Member Certificate 4.10. Update Member Certificate
When the GLO generates a glAddMember request, when the GLA generates When the GLO generates a glAddMember request, when the GLA generates
a glKey message, or when the GLA processes a glAddMember there can be a glKey message, or when the GLA processes a glAddMember, there can
instances when GL member's certificate has expired or is invalid. In be instances when the GL member's certificate has expired or is
these instances the GLO or GLA may request that the GL member provide invalid. In these instances, the GLO or GLA may request that the GL
a new certificate to avoid the GLA from being unable to generate a member provide a new certificate to avoid the GLA from being unable
glKey message for the GL member. There might also be times when the to generate a glKey message for the GL member. There might also be
GL member knows their certificate is about to expire or has been times when the GL member knows that its certificate is about to
revoked and they will not be able to receive GL rekeys. Behavior for expire or has been revoked, and GL member will not be able to receive
the optional transactionId, senderNonce, and recipientNonce CMC GL rekeys. Behavior for the optional transactionId, senderNonce, and
control attributes is not addressed in these procedures. recipientNonce CMC control attributes is not addressed in these
procedures.
4.10.1. GLO and GLA Initiated Update Member Certificate 4.10.1. GLO and GLA Initiated Update Member Certificate
The process for GLO initiated glUpdateCert is as follows: The process for GLO initiated glUpdateCert is as follows:
1 - The GLO or GLA sends a 1 - The GLO or GLA sends a
SignedData.PKIData.controlSequence.glProvideCert request to the SignedData.PKIData.controlSequence.glProvideCert request to the
GL member. The GLO or GLA indicates the GL name in glName and GL member. The GLO or GLA indicates the GL name in glName and
the GL member name in glMemberName. Additionally, a signingTime the GL member name in glMemberName. Additionally, a signingTime
attribute is included with this request. attribute is included with this request.
1.a - The GLO or GLA can optionally apply confidentiality to the 1.a - The GLO or GLA can optionally apply confidentiality to the
request by encapsulating the SignedData.PKIData in an request by encapsulating the SignedData.PKIData in an
EnvelopedData (see section 3.2.1.2). If the GL member's PKC 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 has been revoked, the GLO or GLA ought not use it to generate
generate the EnvelopedData that encapsulates the the EnvelopedData that encapsulates the glProvideCert
glProvideCert request. request.
1.b - The GLO or GLA can also optionally apply another SignedData 1.b - The GLO or GLA can also optionally apply another SignedData
over the EnvelopedData (see section 3.2.1.2). over the EnvelopedData (see Section 3.2.1.2).
2 - Upon receipt of the glProvideCert message, the GL member checks 2 - Upon receipt of the glProvideCert message, the GL member checks
the signingTime and verifies the GLO or GLA signature(s). If an the signingTime and verifies the GLO or GLA signature(s). If an
additional SignedData and/or EnvelopedData encapsulates the additional SignedData and/or EnvelopedData encapsulates the
response (see section 3.2.1.2 or 3.2.2), the GL member verifies response (see Section 3.2.1.2 or 3.2.2), the GL member verifies
the outer signature and/or decrypt the outer layer prior to the outer signature and/or decrypts the outer layer prior to
verifying the signature on the inner most SignedData. verifying the signature on the innermost SignedData.
2.a - If the signingTime attribute value is not within the locally 2.a - If the signingTime attribute value is not within the locally
accepted time window, the GL member MAY return a response accepted time window, the GL member MAY return a response
indicating cMCStatus.failed and otherInfo.failInfo.badTime indicating cMCStatus.failed and otherInfo.failInfo.badTime
and a signingTime attribute. and a signingTime attribute.
2.b - Else if signature processing continues and if the signatures 2.b - Else if signature processing continues and if the signatures
cannot be verified, the GL member returns a cMCStatusInfoExt cannot be verified, the GL member returns a cMCStatusInfoExt
response indicating cMCStatus.failed and response indicating cMCStatus.failed and
otherInfo.failInfo.badMessageCheck. Additionally, a otherInfo.failInfo.badMessageCheck. Additionally, a
signingTime attribute is included with the response. signingTime attribute is included with the response.
2.c - Else if the signatures verify, the GL member generates a 2.c - Else if the signatures verify, the GL member generates a
Signed.PKIResponse.controlSequence.glUpdateCert that Signed.PKIResponse.controlSequence.glUpdateCert that includes
includes the GL name in glName, the member name in the GL name in glName, the member's name in
glMember.glMemberName, their encryption certificate in glMember.glMemberName, the member's encryption certificate in
glMember.certificates.pKC. The GL member can also include glMember.certificates.pKC. The GL member can also include
any attribute certificates associated with their encryption any attribute certificates associated with the member's
certificate in glMember.certificates.aC, and the encryption certificate in glMember.certificates.aC, and the
certification path associated with their encryption and certification path associated with the member's encryption
attribute certificates in glMember.certificates.certPath. and attribute certificates in glMember.certificates.certPath.
Additionally, a signingTime attribute is included with the Additionally, a signingTime attribute is included with the
response. response.
2.c.1 - The GL member can optionally apply confidentiality to the 2.c.1 - The GL member can optionally apply confidentiality to the
request by encapsulating the SignedData.PKIResponse in an request by encapsulating the SignedData.PKIResponse in an
EnvelopedData (see section 3.2.1.2). If the GL member's PKC EnvelopedData (see Section 3.2.1.2). If the GL member's
has been revoked, the GL member ought not use it to PKC has been revoked, the GL member ought not use it to
generate the EnvelopedData that encapsulates the generate the EnvelopedData that encapsulates the
glProvideCert request. glProvideCert request.
2.c.2 - The GL member can also optionally apply another SignedData 2.c.2 - The GL member can also optionally apply another
over the EnvelopedData (see section 3.2.1.2). SignedData over the EnvelopedData (see Section 3.2.1.2).
3 - Upon receipt of the glUpdateCert message, the GLO or GLA checks 3 - Upon receipt of the glUpdateCert message, the GLO or GLA checks
the signingTime and verifies the GL member signature(s). If an the signingTime and verifies the GL member signature(s). If an
additional SignedData and/or EnvelopedData encapsulates the additional SignedData and/or EnvelopedData encapsulates the
response (see section 3.2.1.2 or 3.2.2), the GL member verifies response (see Section 3.2.1.2 or 3.2.2), the GL member verifies
the outer signature and/or decrypt the outer layer prior to the outer signature and/or decrypts the outer layer prior to
verifying the signature on the inner most SignedData. verifying the signature on the innermost SignedData.
3.a - If the signingTime attribute value is not within the locally 3.a - If the signingTime attribute value is not within the locally
accepted time window, the GLO or GLA MAY return a response accepted time window, the GLO or GLA MAY return a response
indicating cMCStatus.failed and otherInfo.failInfo.badTime indicating cMCStatus.failed and otherInfo.failInfo.badTime
and a signingTime attribute. and a signingTime attribute.
3.b - Else if signature processing continues and if the signatures 3.b - Else if signature processing continues and if the signatures
cannot be verified, the GLO or GLA returns a cannot be verified, the GLO or GLA returns a cMCStatusInfoExt
cMCStatusInfoExt response indicating cMCStatus.failed and response indicating cMCStatus.failed and
otherInfo.failInfo.badMessageCheck. Additionally, a otherInfo.failInfo.badMessageCheck. Additionally, a
signingTime attribute is included with the response. signingTime attribute is included with the response.
3.c - Else if the signatures verify, the GLO or GLA verifies the 3.c - Else if the signatures verify, the GLO or GLA verifies the
member's encryption certificate. member's encryption certificate.
3.c.1 - If the member's encryption certificate cannot be verified, 3.c.1 - If the member's encryption certificate cannot be
the GLO returns either another glProvideCert request or a verified, the GLO returns either another glProvideCert
cMCStatusInfoExt with cMCStatus.failed and the reason why request or a cMCStatusInfoExt with cMCStatus.failed and
in cMCStatus.statusString. glProvideCert should be returned the reason why in cMCStatus.statusString. glProvideCert
only a certain number of times because if the GL member should be returned only a certain number of times is
does not have a valid certificate they will never be able because if the GL member does not have a valid
to return one. Additionally, a signingTime attribute is certificate it will never be able to return one.
included with either response. Additionally, a signingTime attribute is included with
either response.
3.c.2 - Else if the member's encryption certificate cannot be 3.c.2 - Else if the member's encryption certificate cannot be
verified, the GLA returns another glProvideCert request to verified, the GLA returns another glProvideCert request
the GL member or a cMCStatusInfoExt with cMCStatus.failed to the GL member or a cMCStatusInfoExt with
and the reason why in cMCStatus.statusString to the GLO. cMCStatus.failed and the reason why in
glProvideCert should be returned only a certain number of cMCStatus.statusString to the GLO. glProvideCert should
times because if the GL member does not have a valid be returned only a certain number of times because if the
certificate they will never be able to return one. GL member does not have a valid certificate it will never
Additionally, a signingTime attribute is included with the be able to return one. Additionally, a signingTime
response. attribute is included with the response.
3.c.3 - Else if the member's encryption certificate verifies, the 3.c.3 - Else if the member's encryption certificate verifies, the
GLO or GLA will use it in subsequent glAddMember requests GLO or GLA will use it in subsequent glAddMember requests
and glKey messages associated with the GL member. and glKey messages associated with the GL member.
4.10.2. GL Member Initiated Update Member Certificate 4.10.2. GL Member Initiated Update Member Certificate
The process for an unsolicited GL member glUpdateCert is as follows: The process for an unsolicited GL member glUpdateCert is as follows:
1 - The GL member sends a 1 - The GL member sends a Signed.PKIData.controlSequence.glUpdateCert
Signed.PKIData.controlSequence.glUpdateCert that includes the that includes the GL name in glName, the member's name in
GL name in glName, the member name in glMember.glMemberName, glMember.glMemberName, the member's encryption certificate in
their encryption certificate in glMember.certificates.pKC. The glMember.certificates.pKC. The GL member can also include any
GL member can also include any attribute certificates attribute certificates associated with the member's encryption
associated with their encryption certificate in certificate in glMember.certificates.aC, and the certification
glMember.certificates.aC, and the certification path associated path associated with the member's encryption and attribute
with their encryption and attribute certificates in certificates in glMember.certificates.certPath. The GL member
glMember.certificates.certPath. The GL member MUST also include MUST also include a signingTime attribute with this request.
a signingTime attribute with this request.
1.a - The GL member can optionally apply confidentiality to the 1.a - The GL member can optionally apply confidentiality to the
request by encapsulating the SignedData.PKIData in an request by encapsulating the SignedData.PKIData in an
EnvelopedData (see section 3.2.1.2). If the GL member's PKC 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 has been revoked, the GLO or GLA ought not use it to generate
generate the EnvelopedData that encapsulates the the EnvelopedData that encapsulates the glProvideCert
glProvideCert request. request.
1.b - The GL member can also optionally apply another SignedData 1.b - The GL member can also optionally apply another SignedData
over the EnvelopedData (see section 3.2.1.2). over the EnvelopedData (see Section 3.2.1.2).
2 - Upon receipt of the glUpdateCert message, the GLA checks the 2 - Upon receipt of the glUpdateCert message, the GLA checks the
signingTime and verifies the GL member signature(s). If an signingTime and verifies the GL member signature(s). If an
additional SignedData and/or EnvelopedData encapsulates the additional SignedData and/or EnvelopedData encapsulates the
response (see section 3.2.1.2 or 3.2.2), the GLA verifies the response (see Section 3.2.1.2 or 3.2.2), the GLA verifies the
outer signature and/or decrypt the outer layer prior to outer signature and/or decrypts the outer layer prior to
verifying the signature on the inner most SignedData. verifying the signature on the innermost SignedData.
2.a - If the signingTime attribute value is not within the locally 2.a - If the signingTime attribute value is not within the locally
accepted time window, the GLA MAY return a response accepted time window, the GLA MAY return a response
indicating cMCStatus.failed and otherInfo.failInfo.badTime indicating cMCStatus.failed and otherInfo.failInfo.badTime
and a signingTime attribute. and a signingTime attribute.
2.b - Else if signature processing continues and if the signatures 2.b - Else if signature processing continues and if the signatures
cannot be verified, the GLA returns a cMCStatusInfoExt cannot be verified, the GLA returns a cMCStatusInfoExt
response indicating cMCStatus.failed and response indicating cMCStatus.failed and
otherInfo.failInfo.badMessageCheck. otherInfo.failInfo.badMessageCheck.
2.c - Else if the signatures verify, the GLA verifies the member's 2.c - Else if the signatures verify, the GLA verifies the member's
encryption certificate. encryption certificate.
2.c.1 - If the member's encryption certificate cannot be verified, 2.c.1 - If the member's encryption certificate cannot be
the GLA returns another glProvideCert request to the GL verified, the GLA returns another glProvideCert request
member or a cMCStatusInfoExt with cMCStatus.failed and the to the GL member or a cMCStatusInfoExt with
reason why in cMCStatus.statusString to the GLO. cMCStatus.failed and the reason why in
glProvideCert ought not be returned indefinitely; if the cMCStatus.statusString to the GLO. glProvideCert ought
GL member does not have a valid certificate they will never not be returned indefinitely; if the GL member does not
be able to return one. Additionally, a signingTime have a valid certificate it will never be able to return
attribute is included with the response. one. Additionally, a signingTime attribute is included
with the response.
2.c.2 - Else if the member's encryption certificate verifies, the 2.c.2 - Else if the member's encryption certificate verifies, the
GLA will use it in subsequent glAddMember requests and GLA will use it in subsequent glAddMember requests and
glKey messages associated with the GL member. The GLA also glKey messages associated with the GL member. The GLA
forwards the glUpdateCert message to the GLO. also forwards the glUpdateCert message to the GLO.
5. Distribution Message 5. Distribution Message
The GLA uses the glKey message to distribute new, shared KEK(s) after The GLA uses the glKey message to distribute new, shared KEK(s) after
receiving glAddMember, glDeleteMember (for closed and managed GLs), receiving glAddMember, glDeleteMember (for closed and managed GLs),
glRekey, glkCompromise, or glkRefresh requests and returning a glRekey, glkCompromise, or glkRefresh requests and returning a
cMCStatusInfoExt response for the respective request. Figure 12 cMCStatusInfoExt response for the respective request. Figure 12
depicts the protocol interactions to send out glKey messages. Unlike depicts the protocol interactions to send out glKey messages. Unlike
the procedures defined for the administrative messages, the the procedures defined for the administrative messages, the
procedures defined in this section MUST be implemented by GLAs for procedures defined in this section MUST be implemented by GLAs for
origination and by GL members on reception. Note that error messages origination and by GL members on reception. Note that error messages
are not shown. Additionally, behavior for the optional transactionId, are not shown. Additionally, behavior for the optional
senderNonce, and recipientNonce CMC control attributes is not transactionId, senderNonce, and recipientNonce CMC control attributes
addressed in these procedures. is not addressed in these procedures.
1 +----------+ 1 +----------+
+-------> | Member 1 | +-------> | Member 1 |
| +----------+ | +----------+
+-----+ | 1 +----------+ +-----+ | 1 +----------+
| GLA | ----+-------> | ... | | GLA | ----+-------> | ... |
+-----+ | +----------+ +-----+ | +----------+
| 1 +----------+ | 1 +----------+
+-------> | Member n | +-------> | Member n |
+----------+ +----------+
Figure 12 - GL Key Distribution Figure 12 - GL Key Distribution
If the GL was setup with GLKeyAttributes.recipientsNotMutuallyAware If the GL was set up with GLKeyAttributes.recipientsNotMutuallyAware
set to TRUE, a separate glKey message MUST be sent to each GL member set to TRUE, a separate glKey message MUST be sent to each GL member
so as to not divulge information about the other GL members. so as not to divulge information about the other GL members.
When the glKey message is generated as a result of a: When the glKey message is generated as a result of a:
- glAddMember request, - glAddMember request,
- glkComrpomise indication, - glkComrpomise indication,
- glkRefresh request, - glkRefresh request,
- glDeleteMember request with the GL's glAdministration set to - glDeleteMember request with the GL's glAdministration set to
managed or closed, and managed or closed, and
- glRekey request with generationCounter set to zero (0). - glRekey request with generationCounter set to zero (0).
The GLA MUST use either the kari (see section 12.3.2 of [CMS]) or 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 ktri (see Section 12.3.1 of [CMS]) choice in
glKey.glkWrapped.RecipientInfo to ensure only the intended recipients glKey.glkWrapped.RecipientInfo to ensure that only the intended
receive the shared KEK. The GLA MUST support the ktri choice. 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 When the glKey message is generated as a result of a glRekey request
with generationCounter greater than zero (0) or when the GLA controls 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 rekeys, the GLA MAY use the kari, ktri, or kekri (see Section 12.3.3
of [CMS]) in glKey.glkWrapped.RecipientInfo to ensure only the of [CMS]) in glKey.glkWrapped.RecipientInfo to ensure that only the
intended recipients receive the shared KEK. The GLA MUST support the intended recipients receive the shared KEK. The GLA MUST support the
RecipientInfo.ktri choice. RecipientInfo.ktri choice.
5.1. Distribution Process 5.1. Distribution Process
When a glKey message is generated the process is as follows: When a glKey message is generated, the process is as follows:
1 - The GLA MUST send a SignedData.PKIData.controlSequence.glKey to 1 - The GLA MUST send a SignedData.PKIData.controlSequence.glKey to
each member by including: glName, glIdentifier, glkWrapped, each member by including glName, glIdentifier, glkWrapped,
glkAlgorithm, glkNotBefore, and glkNotAfter. If the GLA can not glkAlgorithm, glkNotBefore, and glkNotAfter. If the GLA cannot
generate a glKey message for the GL member because the GL generate a glKey message for the GL member because the GL
member's PKC has expired or is otherwise invalid, the GLA MAY member's PKC has expired or is otherwise invalid, the GLA MAY
send a glUpdateCert to the GL member requesting a new send a glUpdateCert to the GL member requesting a new certificate
certificate be provided (see section 4.10). The number of glKey be provided (see Section 4.10). The number of glKey messages
messages generated for the GL is described in section 3.1.16. generated for the GL is described in Section 3.1.13.
Additionally, a signingTime attribute is included with the Additionally, a signingTime attribute is included with the
distribution message(s). distribution message(s).
1.a - The GLA MAY optionally apply another confidentiality layer to 1.a - The GLA MAY optionally apply another confidentiality layer to
the message by encapsulating the SignedData.PKIData in the message by encapsulating the SignedData.PKIData in
another EnvelopedData (see section 3.2.1.2). another EnvelopedData (see Section 3.2.1.2).
1.b - The GLA MAY also optionally apply another SignedData over the 1.b - The GLA MAY also optionally apply another SignedData over the
EnvelopedData.SignedData.PKIData (see section 3.2.1.2). EnvelopedData.SignedData.PKIData (see Section 3.2.1.2).
2 - Upon receipt of the glKey message, the GL members MUST check 2 - Upon receipt of the glKey message, the GL members MUST check the
the signingTime and verify the signature over the inner most signingTime and verify the signature over the innermost
SignedData.PKIData. If an additional SignedData and/or SignedData.PKIData. If an additional SignedData and/or
EnvelopedData encapsulates the message (see section 3.2.1.2 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 3.2.2), the GL member MUST verify the outer signature and/or
decrypt the outer layer prior to verifying the signature on the decrypt the outer layer prior to verifying the signature on the
SignedData.PKIData.controlSequence.glKey. SignedData.PKIData.controlSequence.glKey.
2.a - If the signingTime attribute value is not within the locally 2.a - If the signingTime attribute value is not within the locally
accepted time window, the GLA MAY return a response accepted time window, the GLA MAY return a response
indicating cMCStatus.failed and otherInfo.failInfo.badTime indicating cMCStatus.failed and otherInfo.failInfo.badTime
and a signingTime attribute. and a signingTime attribute.
2.b - Else if signature processing continues and if the signatures 2.b - Else if signature processing continues and if the signatures
cannot be verified, the GL member MUST return a cannot be verified, the GL member MUST return a
cMCStatusInfoExt response indicating cMCStatus.failed and cMCStatusInfoExt response indicating cMCStatus.failed and
otherInfo.failInfo.badMessageCheck. Additionally, a otherInfo.failInfo.badMessageCheck. Additionally, a
signingTime attribute is included with the response. signingTime attribute is included with the response.
2.c - Else if the signatures verify, the GL member process the 2.c - Else if the signatures verify, the GL member processes the
RecipientInfos according to [CMS]. Once unwrapped the GL RecipientInfos according to [CMS]. Once unwrapped, the GL
member should store the shared KEK in a safe place. When member should store the shared KEK in a safe place. When
stored, the glName, glIdentifier, and shared KEK should be stored, the glName, glIdentifier, and shared KEK should be
associated. Additionally, the GL member MUST return a associated. Additionally, the GL member MUST return a
cMCStatusInfoExt indicating cMCStatus.success to tell the cMCStatusInfoExt indicating cMCStatus.success to tell the GLA
GLA the KEK was received. the KEK was received.
6. Algorithms 6. Algorithms
This section lists the algorithms that MUST be implemented. This section lists the algorithms that MUST be implemented.
Additional algorithms that SHOULD be implemented are also included. Additional algorithms that SHOULD be implemented are also included.
Further algorithms MAY also be implemented. Further algorithms MAY also be implemented.
6.1. KEK Generation Algorithm 6.1. KEK Generation Algorithm
Implementations MUST randomly generate content-encryption keys, Implementations MUST randomly generate content-encryption keys,
message-authentication keys, initialization vectors (IVs), and message-authentication keys, initialization vectors (IVs), and
padding. Also, the generation of public/private key pairs relies on a padding. Also, the generation of public/private key pairs relies on
random numbers. The use of inadequate pseudo-random number generators a random numbers. The use of inadequate pseudo-random number
(PRNGs) to generate cryptographic keys can result in little or no generators (PRNGs) to generate cryptographic keys can result in
security. An attacker may find it much easier to reproduce the PRNG little or no security. An attacker may find it much easier to
environment that produced the keys, searching the resulting small set reproduce the PRNG environment that produced the keys, searching the
of possibilities, rather than brute force searching the whole key resulting small set of possibilities, rather than brute force
space. The generation of quality random numbers is difficult. RFC searching the whole key space. The generation of quality random
1750 [RANDOM] offers important guidance in this area, and Appendix 3 numbers is difficult. RFC 4086 [RANDOM] offers important guidance in
of FIPS Pub 186 [FIPS] provides one quality PRNG technique. this area, and Appendix 3 of FIPS Pub 186 [FIPS] provides one quality
PRNG technique.
6.2. Shared KEK Wrap Algorithm 6.2. Shared KEK Wrap Algorithm
In the mechanisms described in sections 5, the shared KEK being In the mechanisms described in Section 5, the shared KEK being
distributed in glkWrapped MUST be protected by a key of equal or distributed in glkWrapped MUST be protected by a key of equal or
greater length (i.e., if an AES 128-bit key is being distributed a greater length (e.g., if an AES 128-bit key is being distributed, a
key of 128-bits or greater must be used to protect the key). The key of 128 bits or greater must be used to protect the key).
algorithm object identifiers included in glkWrapped are as specified
in [CMSALG] and [CMSAES].
6.3. Shared KEK Algorithm The algorithm object identifiers included in glkWrapped are as
specified in [CMSALG] and [CMSAES].
6.3. Shared KEK Algorithm
The shared KEK distributed and indicated in glkAlgorithm MUST support The shared KEK distributed and indicated in glkAlgorithm MUST support
the symmetric key-encryption algorithms as specified in section the symmetric key-encryption algorithms as specified in [CMSALG] and
[CMSALG] and [CMSAES]. [CMSAES].
7. Message Transport 7. Message Transport
SMTP [SMTP] MUST be supported. Other transport mechanisms MAY also be SMTP [SMTP] MUST be supported. Other transport mechanisms MAY also
supported. be supported.
8. Security Considerations 8. Security Considerations
As GLOs control setting up and tearing down the GL, rekeying the GL, As GLOs control setting up and tearing down the GL and rekeying the
and can control member additions and deletions, GLOs play an GL, and can control member additions and deletions, GLOs play an
important role in the management of the GL, and only "trusted" GLOs important role in the management of the GL, and only "trusted" GLOs
should be used. should be used.
If a member is deleted or removed from a closed or a managed GL, the If a member is deleted or removed from a closed or a managed GL, the
GL needs to be rekeyed. If the GL is not rekeyed after a member is GL needs to be rekeyed. If the GL is not rekeyed after a member is
removed or deleted, the member still posses the group key and will be removed or deleted, the member still possesses the group key and will
able to continue to decrypt any messages that can be obtained. be able to continue to decrypt any messages that can be obtained.
Members who store KEKs MUST associate the name of the GLA that Members who store KEKs MUST associate the name of the GLA that
distributed the key so that the members can make sure subsequent distributed the key so that the members can make sure subsequent
rekeys are originated from the same entity. rekeys are originated from the same entity.
When generating keys, care should be taken to ensure that the key When generating keys, care should be taken to ensure that the key
size is not too small and duration too long because attackers will size is not too small and duration too long because attackers will
have more time to attack the key. Key size should be selected to have more time to attack the key. Key size should be selected to
adequately protect sensitive business communications. adequately protect sensitive business communications.
GLOs and GLAs need to make sure that the generationCounter and GLOs and GLAs need to make sure that the generationCounter and
duration are not too large. For example, if the GLO indicates that duration are not too large. For example, if the GLO indicates that
the generationCounter is 14 and the duration is one year, then 14 the generationCounter is 14 and the duration is one year, then 14
keys are generated each with a validity period of a year. An attacker keys are generated each with a validity period of a year. An
will have at least 13 years to attack the final key. attacker will have at least 13 years to attack the final key.
Assume that two or more parties have a shared KEK, and the shared KEK Assume that two or more parties have a shared KEK, and the shared KEK
is used to encrypt a second KEK for confidential distribution to is used to encrypt a second KEK for confidential distribution to
those parties. The second KEK might be used to encrypt a third KEK; those parties. The second KEK might be used to encrypt a third KEK,
the third KEK might be used to encrypt a fourth KEK; and so on. If the third KEK might be used to encrypt a fourth KEK, and so on. If
any of the KEKs in such a chain is compromised, all of the subsequent any of the KEKs in such a chain is compromised, all of the subsequent
KEKs in the chain MUST also be considered compromised. KEKs in the chain MUST also be considered compromised.
An attacker can attack the group's shared KEK by attacking one An attacker can attack the group's shared KEK by attacking one
member's copy of the shared KEK or attacking multiple member's copies member's copy of the shared KEK or attacking multiple members' copies
of the shared KEK. For the attacker it may be easier to either attack of the shared KEK. For the attacker, it may be easier to either
the group member with the weakest security protecting their copy of attack the group member with the weakest security protecting its copy
the shared KEK or by attacking multiple group members. of the shared KEK or attack multiple group members.
An aggregation of the information gathered during the attack(s) may An aggregation of the information gathered during the attack(s) may
lead to the compromise of the group's shared KEK. Mechanisms to lead to the compromise of the group's shared KEK. Mechanisms to
protect the shared KEK should be commensurate with value of the data protect the shared KEK should be commensurate with value of the data
being protected. being protected.
The nonce and signingTime attributes are used to protect against The nonce and signingTime attributes are used to protect against
replay attacks. However, these provisions are only helpful if replay attacks. However, these provisions are only helpful if
entities maintain state information about the messages they have sent entities maintain state information about the messages they have sent
or received for comparison. If sufficient information is not or received for comparison. If sufficient information is not
maintained on each exchange, nonces and signingTime are not helpful. maintained on each exchange, nonces and signingTime are not helpful.
Local policy determines the amount and duration of state information Local policy determines the amount and duration of state information
that is maintained. Additionally, without a unified time source, that is maintained. Additionally, without a unified time source,
there is the possibility of clocks drifting. Local policy determines there is the possibility of clocks drifting. Local policy determines
the acceptable difference between the local time and signingTime, the acceptable difference between the local time and signingTime,
which must compensate for unsynchronized clock. Implementations MUST which must compensate for unsynchronized clocks. Implementations
handle messages with siginingTime attributes that indicate they were MUST handle messages with siginingTime attributes that indicate they
created in the future. were created in the future.
9. IANA Considerations
None: All identifiers are already registered. Please remove this
section prior to publication as an RFC.
10. Acknowledgements 9. Acknowledgements
Thanks to Russ Housley and Jim Schaad for providing much of the Thanks to Russ Housley and Jim Schaad for providing much of the
background and review required to write this document. background and review required to write this document.
11. References 10. References
11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 10.1. Normative References
Requirement Levels", BCP 14, RFC 2119, March 1997.
[CMS] Housley, R., "Cryptographic Message Syntax," RFC 3852, [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
July 2004. Requirement Levels", BCP 14, RFC 2119, March 1997.
[CMC] Myers, M., Liu, X., Schaad, J., Weinsten, J., [CMS] Housley, R., "Cryptographic Message Syntax (CMS)", RFC
"Certificate Management Message over CMS," work-in- 3852, July 2004.
progress, December 2007.
[PROFILE] Housley, R., Ford, W., Polk, W. and D. Solo, "Internet [CMC] Schaad, J. and M. Myers, "Certificate Management over
X.509 Public Key Infrastructure: Certificate and CRL CMS (CMC)", RFC 5272, June 2008.
Profile", RFC 3280, April 2002.
[ACPROF] Farrell, S., Housley, R., "An Internet Attribute [PROFILE] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Certificate Profile for Authorization", RFC 3281, April Housley, R., and W. Polk, "Internet X.509 Public Key
2002. Infrastructure Certificate and Certificate Revocation
List (CRL) Profile", RFC 5280, May 2008.
[MSG] Ramsdale, B., "S/MIME Version 3.1 Message Specification," [ACPROF] Farrell, S. and R. Housley, "An Internet Attribute
RFC 3851, July 2004. Certificate Profile for Authorization", RFC 3281, April
2002.
[ESS] Hoffman, P., "Extended Security Services for S/MIME", RFC [MSG] Ramsdell, B., Ed., "Secure/Multipurpose Internet Mail
2634, June 1999. Extensions (S/MIME) Version 3.1 Message Specification",
RFC 3851, July 2004.
Schaad, J., "Extended Security Services (ESS) Update: [ESS] Hoffman, P., Ed., "Enhanced Security Services for
Adding CertID Algorithm Agility", RFC 5035, August 2007. S/MIME", RFC 2634, June 1999.
[CMSALG] Housley, R., "Cryptographic Message Syntax (CMS) [CMSALG] Housley, R., "Cryptographic Message Syntax (CMS)
Algorithms", RFC 3370, August 2002. Algorithms", RFC 3370, August 2002.
[CMSAES] Schaad, J., "Advanced Encryption Standard (AES) Encryption [CMSAES] Schaad, J., "Use of the Advanced Encryption Standard
Algorithm in Cryptographic Message Syntax (CMS) ", RFC (AES) Encryption Algorithm in Cryptographic Message
3565, July 2003. Syntax (CMS)", RFC 3565, July 2003.
[SMTP] Klensin, J., "Simple Mail Transport Protocol," RFC 2821, [SMTP] Klensin, J., Ed., "Simple Mail Transfer Protocol", RFC
April 2001. 2821, April 2001.
11.2. Informative References 10.2. Informative References
[X400TRANS] Hoffman, P., and C. Bonatti, "Transporting S/MIME Objects [X400TRANS] Hoffman, P. and C. Bonatti, "Transporting
in X.400", RFC 3855, July 2004. Secure/Multipurpose Internet Mail Extensions (S/MIME)
Objects in X.400", RFC 3855, July 2004.
[RANDOM] Eastlake, D., Crocker, S. and J. Schiller, "Randomness [RANDOM] Eastlake, D., 3rd, Schiller, J., and S. Crocker,
Recommendations for Security", RFC 4086, June 2005. "Randomness Requirements for Security", BCP 106, RFC
4086, June 2005.
[FIPS] National Institute of Standards and Technology. FIPS Pub [FIPS] National Institute of Standards and Technology, FIPS Pub
186-2: Digital Signature Standard. 27 January 2000. 186-2: Digital Signature Standard, January 2000.
12. ASN.1 Module Appendix A. ASN.1 Module
SMIMESymmetricKeyDistribution SMIMESymmetricKeyDistribution
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) pkcs-9(9) smime(16) modules(0) symkeydist(12) }
smime(16) modules(0) symkeydist(12) }
DEFINITIONS IMPLICIT TAGS ::= DEFINITIONS IMPLICIT TAGS ::=
BEGIN BEGIN
-- EXPORTS All -- -- EXPORTS All --
-- The types and values defined in this module are exported for use -- The types and values defined in this module are exported for use
-- in the other ASN.1 modules. Other applications may use them for -- in the other ASN.1 modules. Other applications may use them for
-- their own purposes. -- their own purposes.
IMPORTS IMPORTS
-- PKIX Part 1 - Implicit -- PKIX Part 1 - Implicit [PROFILE]
GeneralName
GeneralName FROM PKIX1Implicit88 { iso(1) identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
FROM PKIX1Implicit88 { iso(1) identified-organization(3) dod(6) id-pkix1-implicit(19) }
internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
id-pkix1-implicit(19) }
-- PKIX Part 1 - Explicit
AlgorithmIdentifier, Certificate
FROM PKIX1Explicit88 { iso(1) identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
id-pkix1-explicit(18) }
-- Cryptographic Message Syntax
RecipientInfos, KEKIdentifier, CertificateSet
FROM CryptographicMessageSyntax2004 {iso(1) member-body(2) us(840)
rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) modules(0)
cms-2004(24) }
-- Advanced Encryption Standard (AES) with CMS
id-aes128-wrap
FROM CMSAesRsaesOaep { iso(1) member-body(2) us(840) rsadsi(113549) -- PKIX Part 1 - Explicit [PROFILE]
pkcs(1) pkcs-9(9) smime(16) modules(0) id-mod-cms-aes(19) } AlgorithmId