draft-ietf-smime-symkeydist-01.txt   draft-ietf-smime-symkeydist-02.txt 
SMIME Working Group S. Turner SMIME Working Group S. Turner
Internet Draft IECA Internet Draft IECA
Document: draft-ietf-smime-symkeydist-01.txt July 2000 Document: draft-ietf-smime-symkeydist-02.txt October 31, 2000
Expires: January 14, 2001 Expires: April 2001
S/MIME Symmetric Key Distribution S/MIME Symmetric Key Distribution
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026 [1]. all provisions of Section 10 of RFC2026 [1].
This document is an Internet-Draft. Internet-Drafts are working This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, documents of the Internet Engineering Task Force (IETF), its areas,
skipping to change at line 41 skipping to change at line 41
subscribe, send a message to ietf-smime-request@imc.org with the subscribe, send a message to ietf-smime-request@imc.org with the
single word subscribe in the body of the message. There is a Web single word subscribe in the body of the message. There is a Web
site for the mailing list at <http://www.imc.org/ietf-smime/>. site for the mailing list at <http://www.imc.org/ietf-smime/>.
Abstract Abstract
This document describes a mechanism to manage (i.e., setup, This document describes a mechanism to manage (i.e., setup,
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 algorithms. Also defined herein is a mechanism to organize users
into groups to support distribution of encrypted content using into groups to support distribution of encrypted content using
symmetric cryptographic algorithms. The mechanisms use the symmetric cryptographic algorithms. The mechanism uses the
Cryptographic Message Syntax (CMS) protocol [2] and Certificate Cryptographic Message Syntax (CMS) protocol [2] and Certificate
Management Message over CMS (CMC) protocol [3] to manage the Management Message over CMS (CMC) protocol [3] to manage the
symmetric keys. Any member of the group can then later use this symmetric keys. Any member of the group can then later use this
distributed shared key to decrypt other CMS encrypted objects with distributed shared key to decrypt other CMS encrypted objects with
the symmetric key. This mechanism has been developed to support the symmetric key. This mechanism has been developed to support
S/MIME Mail List Agents (MLAs). S/MIME Mail List Agents (MLAs).
Turner 1 Turner 1
Conventions used in this document Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
this document are to be interpreted as described in RFC-2119 [4]. document are to be interpreted as described in RFC-2119 [4].
1. INTRODUCTION....................................................3 1. INTRODUCTION....................................................3
1.1 APPLICABILITY TO E-MAIL........................................4 1.1 APPLICABILITY TO E-MAIL........................................4
1.2 APPLICABILITY TO REPOSITORIES..................................4 1.2 APPLICABILITY TO REPOSITORIES..................................4
2. ARCHITECTURE....................................................4 2. ARCHITECTURE....................................................5
3. PROTOCOL INTERACTIONS...........................................6 3. PROTOCOL INTERACTIONS...........................................6
3.1 CONTROL ATTRIBUTES.............................................7 3.1 CONTROL ATTRIBUTES.............................................7
3.1.1 GL USE KEK...................................................7 3.1.1 GL USE KEK...................................................8
3.1.2 GL DELETE...................................................10 3.1.2 GL DELETE...................................................10
3.1.3 GL ADD MEMBERS..............................................10 3.1.3 GL ADD MEMBER...............................................10
3.1.4 GL DELETE MEMBERS...........................................11 3.1.4 GL DELETE MEMBERS...........................................11
3.1.5 GL REKEY....................................................12 3.1.5 GL REKEY....................................................12
3.1.6 GL ADD OWNER................................................13 3.1.6 GL ADD OWNER................................................13
3.1.7 GL REMOVE OWNER.............................................13 3.1.7 GL REMOVE OWNER.............................................13
3.1.8 GL KEY COMPROMISE...........................................14 3.1.8 GL KEY COMPROMISE...........................................14
3.1.9 GL KEY REFRESH..............................................14 3.1.9 GL KEY REFRESH..............................................14
3.1.10 GL SUCCESS INFORMATION.....................................14 3.1.10 GL SUCCESS INFORMATION.....................................14
3.1.11 GL FAIL INFORMATION........................................15 3.1.11 GL FAIL INFORMATION........................................15
3.1.12 GLA QUERY REQUEST..........................................17 3.1.12 GLA QUERY REQUEST..........................................17
3.1.13 GLA QUERY RESPONSE.........................................18 3.1.13 GLA QUERY RESPONSE.........................................17
3.1.14 GL KEY.....................................................18 3.1.14 GL PROVIDE CERT............................................17
3.2 USE OF CMC, CMS, AND PKIX.....................................19 3.1.15 GL UPDATE CERT.............................................18
3.2.1 PROTECTION LAYERS...........................................19 3.1.16 GL KEY.....................................................19
3.2.1.1 MINIMUM PROTECTION........................................19 3.2 USE OF CMC, CMS, AND PKIX.....................................20
3.2.1.2 ADDITIONAL PROTECTION.....................................20 3.2.1 PROTECTION LAYERS...........................................20
3.2.2 COMBINING REQUESTS AND RESPONSES............................20 3.2.1.1 MINIMUM PROTECTION........................................21
3.2.3 GLA GENERATED MESSAGES......................................22 3.2.1.2 ADDITIONAL PROTECTION.....................................21
3.2.4 CMC CONTROL ATTRIBUTES......................................23 3.2.2 COMBINING REQUESTS AND RESPONSES............................21
3.2.5 PKIX........................................................23 3.2.3 GLA GENERATED MESSAGES......................................23
4 ADMINISTRATIVE MESSAGES.........................................23 3.2.4 CMC CONTROL ATTRIBUTES......................................24
4.1 ASSIGN KEK TO GL..............................................23 3.2.5 RESUBMITTED GL MEMBER MESSAGES..............................26
4.2 DELETE GL FROM GLA............................................26 3.2.6 PKIX........................................................26
4.3 ADD MEMBERS TO GL.............................................28 4 ADMINISTRATIVE MESSAGES.........................................26
4.3.1 GLO INITIATED ADDITIONS.....................................29 4.1 ASSIGN KEK TO GL..............................................26
4.3.2 PROSPECTIVE MEMBER INITIATED ADDITIONS......................34 4.2 DELETE GL FROM GLA............................................29
4.4 DELETE MEMBERS FROM GL........................................36 4.3 ADD MEMBERS TO GL.............................................31
4.4.1 GLO INITIATED DELETIONS.....................................37 4.3.1 GLO INITIATED ADDITIONS.....................................32
4.4.2 MEMBER INITIATED DELETIONS..................................41 4.3.2 PROSPECTIVE MEMBER INITIATED ADDITIONS......................37
4.5 REQUEST REKEY OF GL...........................................42 4.4 DELETE MEMBERS FROM GL........................................39
4.5.1 GLO INITIATED REKEY REQUESTS................................43 4.4.1 GLO INITIATED DELETIONS.....................................40
4.5.2 GLA INITIATED REKEY REQUESTS................................45 4.4.2 MEMBER INITIATED DELETIONS..................................44
4.6 CHANGE GLO....................................................45 4.5 REQUEST REKEY OF GL...........................................45
4.7 INDICATE KEK COMPROMISE.......................................47 4.5.1 GLO INITIATED REKEY REQUESTS................................46
4.8 REQUEST KEK REFRESH...........................................49 4.5.2 GLA INITIATED REKEY REQUESTS................................48
4.9 GLA QUERY REQUEST AND RESPONSE................................50 4.6 CHANGE GLO....................................................48
5 DISTRIBUTION MESSAGE............................................52 4.7 INDICATE KEK COMPROMISE.......................................50
5.1 DISTRIBUTION PROCESS..........................................53 4.7.1 GL MEMBER INITIATED KEK COMPROMISE MESSAGE..................51
Turner 2 Turner 2
6 KEY WRAPPING....................................................53 4.7.2 GLO INITIATED KEK COMPROMISE MESSAGE........................52
7 ALGORITHMS......................................................54 4.8 REQUEST KEK REFRESH...........................................53
8 TRANSPORT.......................................................54 4.9 GLA QUERY REQUEST AND RESPONSE................................54
9 USING THE GROUP KEY.............................................54 4.10 UPDATE MEMBER CERTIFICATE....................................56
10 SCHEMA REQUIREMENTS............................................54 4.10.1 GLO AND GLA INITIATED UPDATE MEMBER CERTIFICATE............56
11 SECURITY CONSIDERATIONS........................................54 4.10.2 GL MEMBER INITIATED UPDATE MEMBER CERTIFICATE..............57
12 REFERENCES.....................................................55 5 DISTRIBUTION MESSAGE............................................58
13 ACKNOWLEDGEMENTS...............................................55 5.1 DISTRIBUTION PROCESS..........................................59
14 AUTHOR'S ADDRESSES.............................................55 6 ALGORITHMS......................................................60
6.1 KEK GENERATION ALGORITHM......................................60
6.2 SHARED KEK WRAP ALGORITHM.....................................60
6.3 SHARED KEK ALGORITHM..........................................61
7 TRANSPORT.......................................................61
8 USING THE GROUP KEY.............................................61
9 SECURITY CONSIDERATIONS.........................................61
10 REFERENCES.....................................................61
11 ACKNOWLEDGEMENTS...............................................62
12 AUTHOR'S ADDRESSES.............................................62
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 [2]), users require a mechanism to distribute (e.g., S/MIME [2]), users require a mechanism to distribute
encrypted data to multiple recipients (i.e., a group of users). encrypted data to multiple recipients (i.e., a group of users).
There are essentially two ways to encrypt the data for recipients: There are essentially two ways to encrypt the data for recipients:
using 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.
skipping to change at line 147 skipping to change at line 156
the CEK and hence gain access to the encrypted content. the CEK and hence gain access to the encrypted content.
With symmetric algorithms, the origination process is the same as With symmetric algorithms, the origination process is the same as
with asymmetric algorithms except for what encrypts the CEK. Instead with asymmetric algorithms except for what encrypts the CEK. Instead
of using PKCs, the originator uses a previously distributed secret of using PKCs, the originator uses a previously distributed secret
key-encryption key (KEK) to encrypt the CEK (kekri RecipientInfo key-encryption key (KEK) to encrypt the CEK (kekri RecipientInfo
CHOICE). Only one copy of the encrypted CEK is required because all CHOICE). Only one copy of the encrypted CEK is required because all
the recipients already have the shared KEK needed to decrypt the CEK the recipients already have the shared KEK needed to decrypt the CEK
and hence gain access to the encrypted content. and hence gain access to the encrypted content.
Turner 3
The security provided by the shared KEK is only as good as the sum The security provided by the shared KEK is only as good as the sum
of the techniques employed by each member of the group to keep the of the techniques employed by each member of the group to keep the
KEK secret from nonmembers. These techniques are beyond the scope of KEK secret from nonmembers. These techniques are beyond the scope of
this document. Only the members of the list and the key manager this document. Only the members of the list and the key manager
should have the KEK in order to maintain the secrecy of the group. should have the KEK in order to maintain the secrecy of the group.
Access control to the information protected by the KEK is determined Access control to the information protected by the KEK is determined
by the entity that encrypts the information, as all members of the by the entity that encrypts the information, as all members of the
group have access. If the entity that is performing the encryption group have access. If the entity that is performing the encryption
wants to ensure some subset of the group does not gain access to the wants to ensure some subset of the group does not gain access to the
Turner 3
information either a different KEK should be used (shared with this information either a different KEK should be used (shared with this
smaller group) or asymmetric algorithms should be used. smaller group) or asymmetric algorithms should be used.
1.1 Applicability to E-mail 1.1 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, have been Distribution lists sometimes referred to as mail lists, have been
defined to support distribution of messages to recipients subscribed defined to support distribution of messages to recipients subscribed
to the mail list. There are two models for how the mail list can be to the mail list. There are two models for how the mail list can be
used. If the originator is a member of the mail list, the originator used. If the originator is a member of the mail list, the originator
skipping to change at line 187 skipping to change at line 195
1.2 Applicability to Repositories 1.2 Applicability to Repositories
Objects can also be distributed via a repository (e.g., Light Weight Objects can also be distributed via a repository (e.g., Light Weight
Directory Protocol (LDAP) servers, X.500 Directory System Agents Directory Protocol (LDAP) servers, X.500 Directory System Agents
(DSAs), Web-based servers). If an object is stored in a repository (DSAs), Web-based servers). If an object is stored in a repository
encrypted with a symmetric key algorithm, any one with the shared encrypted with a symmetric key algorithm, any one with the shared
KEK and access to that object can then decrypt that object. The KEK and access to that object can then decrypt that object. The
encrypted object and the encrypted, shared KEK can be stored in the encrypted object and the encrypted, shared KEK can be stored in the
repository. repository.
Turner 4
2. Architecture 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 - The Key Management Agent (KMA) which is responsible for
generating the shared KEKs. generating the shared KEKs.
- The Group Management Agent (GMA) which is responsible for - The Group Management Agent (GMA) which is responsible for
managing the Group List (GL) to which the shared KEKs are managing the Group List (GL) to which the shared KEKs are
distributed. distributed.
Turner 4
+----------------------------------------------+ +----------------------------------------------+
| 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. KMAs may be differentiated by the A GLA may support multiple KMAs. A GLA in general supports only one
'goodness' of the random number used to generate the shared KEK or GMA, but the GMA may support multiple GLs. Multiple KMAs may support
the key management technique used to distribute the shared KEK. a GMA in the same fashion as GLAs support multiple KMAs. Assigning a
Outside the GLA, KMAs are differentiated by the digital signatures particular KMA to a GL is beyond the scope of this document.
they apply to the messages they generate.
A GLA in general supports only one 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 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 where no access control is applied) GLs. The access control
mechanism for managed lists is beyond the scope of this document. mechanism for managed lists is beyond the scope of this document.
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 the entities who 'own' the GL and who are allowed to make changes 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 or may not be GL members.
Turner 5
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 functions, the two functions could be supported by the same entity
or they could be supported by two different entities. If two or they could be supported by two different entities. If two
entities are used, they could be located on one or two platforms. entities are used, they could be located on one or two platforms.
There is however a close relationship between the KMA and GMA There is however a close relationship between the KMA and GMA
functions. If the GMA stores all information pertaining to the GLs functions. If the GMA stores all information pertaining to the GLs
and the KMA merely generates keys, a corrupted GMA could cause and the KMA merely generates keys, a corrupted GMA could cause
havoc. To protect against a corrupted GMA, the KMA would be forced havoc. To protect against a corrupted GMA, the KMA would be forced
Turner 5
to double check the requests it receives to ensure the GMA did not to double check the requests it receives to ensure the GMA did not
tamper with them. These duplicative checks blur the functionality of tamper with them. These duplicative checks blur the functionality of
the two components together. For this reason, the interactions the two components together. For this reason, the interactions
between the KMA and GMA are beyond the scope of this document. between the KMA and GMA 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 omitted; the Henceforth, the distinction between the two agents is omitted; the
term GLA will be used to address both functions. term GLA will be used to address both functions. It should be noted
that 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
support managing GLs; however, this document does not address support managing GLs; however, this document does not address
securing these mechanisms, as they are not standardized. Instead, it securing these mechanisms, as they are not standardized. Instead, it
defines protocol interactions, as depicted in Figure 2, used by the defines protocol interactions, as depicted in Figure 2, used by the
GL members, GLA, and GLO to manage GLs and distribute shared KEKs. GL members, GLA, and GLO 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
skipping to change at line 299 skipping to change at line 302
+----> | Member n | +----> | Member n |
+----------+ +----------+
Figure 2 - Protocol Interactions Figure 2 - Protocol Interactions
Turner 6 Turner 6
3.1 Control Attributes 3.1 Control Attributes
The messages are based on including control attributes in CMC's The messages are based on including control attributes in CMC's
PKIData.controlSequence for requests and CMC's PKIData for requests and CMC's ResponseBody0 for responses. The
ResponseBody.controlSequence for responses. The content-types content-types PKIData and PKIResponse are then encapsulated in CMS's
PKIData and PKIResponse are then encapsulated in CMS's SignedData or SignedData or EnvelopedData, or a combination of the two (see
EnvelopedData, or a combination of the two (see paragraph 3.2). The paragraph 3.2). The following are the control attributes defined in
following are the control attributes defined in this document: this document:
Implementation Control
Requirement Control Attribute OID Syntax Attribute OID Syntax
-------------- ------------------ ----------- ----------------- ------------------- ----------- -----------------
MAY glUseKEK id-skd 1 GLUseKEK glUseKEK id-skd 1 GLUseKEK
MAY glDelete id-skd 2 GLDelete glDelete id-skd 2 GeneralName
MAY glAddMembers id-skd 3 GLAddMembers glAddMember id-skd 3 glAddMember
MAY glDeleteMembers id-skd 4 GLDeleteMembers glDeleteMember id-skd 4 GLDeleteMember
MAY glRekey id-skd 5 GLRekey glRekey id-skd 5 GLRekey
MAY glAddOwners id-skd 6 GLAddOwners glAddOwner id-skd 6 GLOwnerAdministration
MAY glRemoveOwners id-skd 7 GLRemoveOwners glRemoveOwner id-skd 7 GLOwnerAdministration
MAY glkCompromise id-skd 8 GLKCompromise glkCompromise id-skd 8 GeneralName
SHOULD glkRefresh id-skd 9 GLKRefresh glkRefresh id-skd 9 GeneralName
MAY glSuccessInfo id-skd 10 GLSuccessInfo glSuccessInfo id-skd 10 GLSuccessInfo
MAY glFailInfo id-skd 11 GLFailInfo glFailInfo id-skd 11 GLFailInfo
MAY glAQueryRequest id-skd 12 GLAQueryRequest glaQueryRequest id-skd 12 GLAQueryRequest
MAY glAQueryResponse id-skd 13 GLAQueryResponse glaQueryResponse id-skd 13 GLAQueryResponse
MUST glKey id-skd 14 GLKey glProvideCert id-skd 14 GLProvideCert
glUpdateCert id-skd 15 GLUpdateCert
glKey id-skd 16 GLKey
GLSuccessInfo, GLFailInfo, and GLAQueryResponse are responses and go The following are the implementation requirements for the control
into the PKIResponse content-type, all other messages are requests attributes defined herein:
and go into the PKIData content-type.
Implementation Requirement | Control
GLO | GLA | GL Member | Attribute
O R | O R F | O R |
-------- | ------------------ | --------- | ----------
MAY N/A | N/A MAY N/A | N/A N/A | glUseKEK
MAY N/A | N/A MAY N/A | N/A N/A | glDelete
MAY MAY | N/A MUST MAY | N/A MUST | glAddMember
MAY MAY | N/A MUST MAY | N/A MUST | glDeleteMember
MAY N/A | N/A MAY N/A | N/A N/A | glRekey
MAY N/A | N/A MAY N/A | N/A N/A | glAddOwner
MAY N/A | N/A MAY N/A | N/A N/A | glRemoveOwner
MAY MAY | N/A MUST MAY | MUST N/A | glkCompromise
MAY N/A | N/A MUST N/A | MUST N/A | glkRefresh
N/A MAY | MUST N/A N/A | N/A MUST | glSucessInfo
N/A MAY | MUST N/A N/A | N/A MUST | glFailInfo
MAY N/A | N/A SHOULD N/A | MAY MAY | glaQueryRequest
N/A MAY | SHOULD N/A N/A | MAY MAY | glaQueryResponse
MAY N/A | MUST N/A MAY | N/A MUST | glProvideCert
N/A MAY | N/A MUST MAY | MUST N/A | glUpdateCert
N/A N/A | MUST N/A N/A | N/A MUST | glKey
Turner 7
glSuccessInfo, glFailInfo, glaQueryResponse, and gloResponse are
responses and go into the PKIResponse content-type, all other
control attributes are included in requests and go into the PKIData
content-type. The exception is glUpdateCert which may be included in
either PKIData or PKIResponse.
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. GL. glUseKEK messages MUST be signed by the GLO. The glUseKEK
control attribute shall have the syntax GLUseKEK:
GLUseKEK ::= SEQUENCE { GLUseKEK ::= SEQUENCE {
glName GeneralName, glInfo GLInfo,
glOwner SEQUENCE SIZE (1..MAX) OF GeneralName, glOwnerInfo SEQUENCE SIZE (1..MAX) OF GLOwnerInfo,
glAdministration GLAdministration, glAdministration GLAdministration DEFAULT (1),
glDistributionMethod GLDistributionMethod,
glKeyAttributes [0] GLKeyAttributes OPTIONAL } glKeyAttributes [0] GLKeyAttributes OPTIONAL }
GLInfo ::= SEQUENCE {
glName GeneralName,
glAddress GeneralName }
GLOwnerInfo ::= SEQUENCE {
glOwnerName GeneralName,
glOwnerAddress GeneralName }
GLAdministration ::= INTEGER { GLAdministration ::= INTEGER {
unmanaged (0), unmanaged (0),
managed (1), managed (1),
closed (2) } closed (2) }
Turner 7
GLDistributionMethod ::= CHOICE {
rfc822Name [0] IA5String,
x400Address ORAddress,
directoryName Name,
uniformResourceIdentifier [1] IA5String }
GLKeyAttributes ::= SEQUENCE { GLKeyAttributes ::= SEQUENCE {
rekeyControlledByGLO [0] BOOLEAN DEFAULT FALSE, rekeyControlledByGLO [0] BOOLEAN DEFAULT FALSE,
recipientMutuallyAware [1] BOOLEAN DEFAULT TRUE, recipientMutuallyAware [1] BOOLEAN DEFAULT TRUE,
duration [2] INTEGER DEAULT (0), duration [2] INTEGER DEAULT (0),
generationCounter [3] INTEGER DEFAULT {2}, generationCounter [3] INTEGER DEFAULT (2),
requestedAlgorithm [4] AlgorithmIdentifier OPTIONAL } requestedAlgorithm [4] AlgorithmIdentifier
DEFAULT (id-alg-CMS3DESwrap) OPTIONAL
}
The fields in GLUseKEK have the following meaning: The fields in GLUseKEK have the following meaning:
- glName is the name of the GL. The name MUST be unique for a - glInfo indicates the GL's name in glName and the GL's address in
given GLA. glAddress. In some instances the glName and glAddress may be the
same, but this is not always the case. The name and address MUST
be unique for a given GLA.
- glOwner indicates the owner of the GL. One of the names in - glOwnerInfo indicates the GL owner's name in glOwnerName and the
glOwner MUST match one of the names in the certificate used to GL owner's address in glOwnerAddress. One of the names in
sign this SignedData.PKIData creating the GL (i.e., the
Turner 8
glOwnerName MUST match one of the names in the certificate used
to sign this SignedData.PKIData creating the GL (i.e., the
immediate signer). Multiple GLOs MAY be indicated if immediate signer). Multiple GLOs MAY be indicated if
glAdministration is set to managed or closed. glAdministration is set to managed or closed.
- glAdministration indicates how the GL should be administered. - glAdministration indicates how the GL should be administered.
The default is for the list to be unmanaged and to accept The default is for the list to be managed. Three values are
requests from prospective members. Three possibilities exist: supported for glAdministration:
- Unmanaged - When the GLO sets glAdministration to unmanaged, - Unmanaged - When the GLO sets glAdministration to unmanaged,
they are allowing prospective members to request being added they are allowing prospective members to request being added
and deleted from the GL without GLO intervention. and deleted from the GL without GLO intervention. They are
also indicating that only one GLO may be associated at any one
time with the GL.
- Managed - When the GLO sets glAdministration to managed, they - Managed - When the GLO sets glAdministration to managed, they
are allowing prospective members to request being added and are allowing prospective members to request being added to and
deleted from the GL, but the request is sent to GLO for deleted from the GL, but the request is redirected by the GLA
review. The requests are redirected to the GLO. The GLO makes to GLO for review. The GLO makes the determination as to
the determination as to whether to honor the request. whether to honor the request.
- Closed - When the GLO sets glAdministration to closed, they - Closed - When the GLO sets glAdministration to closed, they
are not allowing prospective members to request being added are not allowing prospective members to request being added to
and deleted from the GL. The GLA will only accept GLAddMembers or deleted from the GL. The GLA will only accept glAddMember
and GLDeleteMembers requests from the GLO. and glDeleteMember requests from the GLO.
- glDistributionMethod indicates the mechanism the GLA should
distribute shared KEKs. Internet mail (rfc822Name) MUST be
supported and X.400 (x400Address), X.500 (directoryName), and
web (uniformResourceIdentifier) MAY be supported (see paragraph
8).
- glKeyAttributes indicates the attributes the GLO wants the GLA - glKeyAttributes indicates the attributes the GLO wants the GLA
to assign to the shared KEK. If the field is omitted, GL rekeys to assign to the shared KEK. If this field is omitted, GL rekeys
Turner 8
will be controlled by the GLA, the recipients are allowed to will be controlled by the GLA, the recipients are allowed to
know about one another, the algorithm will be as specified in know about one another, the algorithm will Triple-DES (see
paragraph 7, the shared KEK will be valid for a calendar month paragrpah 7), the shared KEK will be valid for a calendar month
(i.e., first of the month until the last day of the month), and (i.e., first of the month until the last day of the month), and
two shared KEKs will be distributed initially. The fields in two shared KEKs will be distributed initially. The fields in
glKeyAttributes have the following meaning: glKeyAttributes have the following meaning:
- rekeyControlledByGLO indicates whether the GL rekey messages - rekeyControlledByGLO indicates whether the GL rekey messages
will be generated by the GLO or by the GLA. The default is for will be generated by the GLO or by the GLA. The default is for
the GLA to control rekeys. If GL rekey is controlled by the the GLA to control rekeys. If GL rekey is controlled by the
GLA, the GL will continue to be rekeyed until the GLO deletes GLA, the GL will continue to be rekeyed until the GLO deletes
the GL or changes the GL rekey to be GLO controlled. the GL or changes the GL rekey to be GLO controlled.
- recipientsMutuallyAware indicates that the GLO wants the GLA - recipientsMutuallyAware indicates that the GLO wants the GLA
to distribute the shared KEK individually for each of the GL to distribute the shared KEK individually for each of the GL
members (i.e., a separate GLKey message is sent to each members (i.e., a separate glKey message is sent to each
recipient). The default is for separate GLKey message to not recipient). The default is for separate glKey message to not
be required. be required.
NOTE: This supports lists where one member does not know the NOTE: This supports lists where one member does not know the
identities of the other members. For example, a list is identities of the other members. For example, a list is
configured granting submit permissions to only one member. All configured granting submit permissions to only one member. All
other members are 'listening.' The security policy of the list other members are 'listening.' The security policy of the list
does not allow the members to know who else is on the list. If does not allow the members to know who else is on the list. If
a GLKey is constructed for all of the GL members, information
Turner 9
a glKey is constructed for all of the GL members, information
about each of the members may be derived from the information about each of the members may be derived from the information
in RecipientInfos. To make sure the GLKey message does not in RecipientInfos. To make sure the glkey message does not
divulge information about the other recipients, a separate divulge information about the other recipients, a separate
GLKey message would be sent to each GL member. glKey message would be sent to each GL member.
- duration indicates the length of time (in days) during which - duration indicates the length of time (in days) during which
the shared KEK is considered valid. The value zero (0) the shared KEK is considered valid. The value zero (0)
indicates that the shared KEK is valid for a calendar month. indicates that the shared KEK is valid for a calendar month.
For example if the duration is zero (0), if the GL shared KEK For example if the duration is zero (0), if the GL shared KEK
is requested on July 24, the first key will be valid until the is requested on July 24, the first key will be valid until the
end of July and the next key will be valid for the entire end of July and the next key will be valid for the entire
month of August. If the value is not zero (0), the shared KEK month of August. If the value is not zero (0), the shared KEK
will be valid for the number of days indicated by the value. will be valid for the number of days indicated by the value.
For example, if the value of duration is seven (7) and the For example, if the value of duration is seven (7) and the
shared KEK is requested on Monday but not generated until shared KEK is requested on Monday but not generated until
Tuesday (2359); the shared KEKs will be valid from Tuesday Tuesday (2359); the shared KEKs will be valid from Tuesday
(2359) to Tuesday (2359). The exact time of the day is (2359) to Tuesday (2359). The exact time of the day is
determined when the key is generated. determined when the key is generated.
- generationCounter indicates the number of keys the GLO wants - generationCounter indicates the number of keys the GLO wants
the GLA to distribute. To ensure uninterrupted function of the the GLA to distribute. To ensure uninterrupted function of the
GL two (2) shared KEKs at a minimum MUST be initially GL two (2) shared KEKs at a minimum MUST be initially
distributed. The second shared KEK is distributed with the distributed. The second shared KEK is distributed with the
first shared KEK, so that when the first shared KEK is no first shared KEK, so that when the first shared KEK is no
longer valid the second key can be used. See paragraphs 4.5 longer valid the second key can be used. If the GLA controls
and 5 for more on rekey. rekey then it also indicates the number of shared KEKs the GLO
wants outstanding at any one time. See paragraphs 4.5 and 5
for more on rekey.
Turner 9
- requestedAlgorithm indicates the algorithm and any parameters - requestedAlgorithm indicates the algorithm and any parameters
the GLO wants the GLA to use to generate the shared KEK. See the GLO wants the GLA to use to generate the shared KEK. See
paragraph 7 for more on algorithms. paragraph 7 for more on algorithms.
3.1.2 GL Delete 3.1.2 GL Delete
GLOs use GLDelete to request that a GL be deleted from the GLA. GLOs use glDelete to request that a GL be deleted from the GLA. The
glDelete control attribute shall have the syntax GeneralName. The
GLDelete ::= GLNameAndIdentifier name of the GL to be deleted is included in GeneralName. The
glDelete message MUST be signed by the GLO.
GLNameAndIdentifier ::= SEQUENCE {
glName GeneralName,
glIdentifier GLIdentifier OPTIONAL }
The fields in GLDelete have the following meaning:
- glName indicates the name of the GL to be deleted.
- glIdentifier indicates the identifier of the GL to be deleted.
It MAY be omitted if it is unknown (e.g., the GLO hasn't
received a GLSuccessInfo assigning the glIdentifier to the GL)
or has been lost by the GLO.
3.1.3 GL Add Members 3.1.3 GL Add Member
GLOs use GLAddMembers to request addition of new members and GLOs use glAddMember to request addition of new members and
prospective GL members' use GLAddMembers to request being added to prospective GL members use glAddMember to request being added to the
the GL. GL. The glAddMember message must be signed by either the GLO or the
prospective GL member. The glAddMember control attribute shall have
the syntax GLAddMember:
GLAddMembers ::= SEQUENCE { Turner 10
GLAddMember ::= SEQUENCE {
glName GeneralName, glName GeneralName,
glMembers SEQUENCE SIZE (1..MAX) OF GLMember, glMember GLMember }
glIdentifier GLIdentifier OPTIONAL }
GLMember ::= SEQUENCE { GLMember ::= SEQUENCE {
glMemberName GeneralName, glMemberName GeneralName,
glMemberAddress GeneralName,
certificates Certificates } certificates Certificates }
Certificates ::= SEQUENCE { Certificates ::= SEQUENCE {
membersPKC Certificate, membersPKC Certificate,
-- See X.509 -- See X.509
membersAC SEQUENCE OF AttributeCertificate OPTIONAL, membersAC SEQUENCE OF AttributeCertificate OPTIONAL,
-- See X.509 -- See X.509
certificationPath CertificateSet OPTIONAL } certificationPath CertificateSet OPTIONAL }
-- From CMS [2] -- From CMS [2]
CertificateSet ::= SET OF CertificateChoices CertificateSet ::= SET OF CertificateChoices
Turner 10
CertificateChoices ::= CHOICE { CertificateChoices ::= CHOICE {
certificate Certificate, -- See X.509 certificate Certificate, -- See X.509
extendedCertificate [0] IMPLICIT ExtendedCertificate, extendedCertificate [0] IMPLICIT ExtendedCertificate,
-- Obsolete -- Obsolete
attrCert [1] IMPLICIT AttributeCertificate } attrCert [1] IMPLICIT AttributeCertificate }
-- See X.509 and X9.57 -- See X.509 and X9.57
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 - glName indicates the name of the GL to which the member should
be added. be added.
- glMembers indicates the particulars for the GL member(s) to be - glMember indicates the particulars for the GL member.
added to the GL. GLMemberName indicates the name of the GL glMemberName indicates the name of the GL member and
member. certificates.membersPKC includes the member's encryption glMemberAddress indicates the GL member's address. In some
certificate that will be used to encrypt the shared KEK for that instances the glMemberName and glMemberAddress may be the same,
member. certificates.membersAC MAY be included to convey any but this is not always the case. certificates.membersPKC
attribute certificate associated with the member's encryption includes the member's encryption certificate that will be used
certificate. certificates.certificationPath MAY also be included to at least initially encrypt the shared KEK for that member.
to convey the certification path corresponding to the member's certificates.membersAC MAY be included to convey any attribute
encryption and attribute certificates. The certification path is certificate associated with the member's encryption certificate.
optional because it may already be included elsewhere in the certificates.certificationPath MAY also be included to convey
message (e.g., in the outer CMS layer). the certification path corresponding to the member's encryption
and attribute certificates. The certification path is optional
- glIdentifier indicates the identifier of the GL to which the because it may already be included elsewhere in the message
member should be added. It MAY be omitted if it is unknown (e.g., in the outer CMS layer).
(e.g., the GLO hasn't received a GLSuccessInfo assigning the
glIdentifier to the GL) or has been lost by the GLO. The
prospective GL member MAY omit this field. The GLO MUST omit the
field if the GLAddMembers associated GLUseKEK message is
included in the same SignedData.PKIData content-type.
3.1.4 GL Delete Members 3.1.4 GL Delete Members
GLOs use GLDeleteMembers to request deletion of GL members and GLOs use glDeleteMember to request deletion of GL members and
prospective non-GL members use GLDeleteMembers to request being prospective non-GL members use glDeleteMember to request being
removed from the GL.
GLDeleteMembers ::= SEQUENCE { Turner 11
removed from the GL. The glDeleteMember message must be signed by
either the GLO or the prospective GL member. The glDeleteMember
control attribute shall have the syntax GLDeleteMember:
GLDeleteMember ::= SEQUENCE {
glName GeneralName, glName GeneralName,
glMembersToDelete SEQUENCE SIZE (1..MAX) OF GeneralName, glMemberToDelete GeneralName }
glIdentifier GLIdentifier OPTIONAL }
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.
Turner 11 - glMemberToDelete indicates the name of the member to be deleted.
- glMembersToDelete indicates the name of the member to be
deleted.
- glIdentifier indicates the identifier of the GL to which the
member should be deleted. The prospective non-GL member MUST
include the field. The GLO MAY omit this field if it is unknown
(e.g., the GLO hasn't received a GLSuccessInfo assigning the
glIdentifier to the GL) or has been lost by the GLO.
3.1.5 GL Rekey 3.1.5 GL Rekey
GLOs use the GLRekey to request a GL rekey. GLOs use the glRekey to request a GL rekey. The glRekey message MUST
be signed by the GLO. The glRekey control attribute shall have the
syntax GLRekey:
GLRekey ::= SEQUENCE { GLRekey ::= SEQUENCE {
glName GeneralName, glName GeneralName,
glIdentifier GLIdentifier,
glOwner SEQUENCE SIZE (0..MAX) OF GeneralName,
glAdministration GLAdministration OPTIONAL, glAdministration GLAdministration OPTIONAL,
glDistributionMethod GLDistributionMethod OPTIONAL, glNewKeyAttributes GLNewKeyAttributes OPTIONAL }
glKeyAttributes GLKeyAttributes OPTIONAL }
GLNewKeyAttributes ::= SEQUENCE {
rekeyControlledByGLO [0] BOOLEAN OPTIONAL,
recipientMutuallyAware [1] BOOLEAN OPTIONAL,
duration [2] INTEGER OPTIONAL,
generationCounter [3] INTEGER 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.
- glIdentifier identifies the shared KEK to be rekeyed. - glAdministration indicates if there is any change to how the GL
should be administered. See paragraph 3.1.1 for the three
- glOwner indicates the owner(s) of the GL. The field is only options. This field is only included if there is a change from
included if there is a change from the registered GLOs. the previously registered administered.
- glAdministration indicates how the GL should be administered.
See paragraph 3.1.1 for the three options. This field is only
included if there is a change from the previously registered
administered.
- glDistributionMethod indicates the mechanism the shared KEK
should be distributed. The field is only included if there is a
change from the previously registered glDistributionMethod.
- glKeyAttributes 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 GLO wishes to use, the duration of the key, and how many
outstanding keys should be issued. The field is only included if outstanding keys should be issued. The field is only included if
there is a change from the previously registered there is a change from the previously registered
glKeyAttributes. If the value zero (0) is specified in glKeyAttributes. If the value zero (0) is specified in
generationCounter the GLO is indicating that it wants all of the generationCounter the GLO is indicating that it wants all of the
outstanding GL shared KEKs rekeyed. For example, suppose the GLO
used the GLUseKEK with duration set to two (2) and the GLRekey
message is sent during the first duration with generationCounter
set to zero (0). The GLA would know to generate a GLKey message
Turner 12 Turner 12
outstanding GL shared KEKs rekeyed. For example, suppose the GLO
used the glUseKEK with duration set to two (2) and the glRekey
message is sent during the first duration with generationCounter
set to zero (0). The GLA would know to generate a glKey message
to replace both the shared KEK currently being used and the to replace both the shared KEK currently being used and the
shared KEK for the second duration. shared KEK for the second duration.
3.1.6 GL Add Owner 3.1.6 GL Add Owner
GLOs use the GLAddOwners 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. These requests are only applicable to GLs that administer the GL. In addition, a registered GLO may use the request
are managed (i.e., administered.managed) or closed (i.e., to update their certificate on the GLA. In this case, the new GLO
administered.closed). certificate is signed by the old GLO certificate. The glAddOwner
message MUST be signed a registered GLO. The glAddOwner control
GLAddOwners ::= GLOwnerAdministration attribute shall have the syntax GLOwnerAdministration:
GLOwnerAdministration ::= SEQUENCE { GLOwnerAdministration ::= SEQUENCE {
glName GeneralName, glName GeneralName,
glOwner SEQUENCE SIZE (1..MAX) OF GeneralName, glOwnerInfo GLOwnerInfo }
glIdentifier GLIdentifier OPTIONAL }
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.
- glOwner indicates the name(s) of the new GLO(s). - glOwnerInfo indicates the name and address of the new GLO.
- glIdentifier optionally indicates the identifier of the GL to
which the GLO should be associated. It MAY be omitted if it is
unknown (e.g., the GLO hasn't received a GLSuccessInfo assigning
the glIdentifier to the GL) or has been lost by the GLO
3.1.7 GL Remove Owner 3.1.7 GL Remove Owner
GLOs use the GLRemoveOwners to request that a GLO be disassociated GLOs use the glRemoveOwner to request that a GLO be disassociated
with the GL. These requests are only applicable to managed GLs. with the GL. The glRemoveOwner message MUST be signed a registered
GLO. Unmanaged GLs may only have one GLO. If the GLA processes a
glRemoveOwner for an unmanaged GL, only one GLO shall be associated
with the GL at any given time. The glRemoveOwner control attribute
shall have the syntax GLOwnerAdministration:
GLRemoveOwners ::= GLOwnerAdministration GLOwnerAdministration ::= SEQUENCE {
glName GeneralName,
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.
- glOwner indicates the name of the GLO. - glOwnerInfo indicates the name and address of the GLO to be
removed.
- glIdentifier optionally indicates the identifier of the GL to
which the GLO should be disassociated. It MAY be omitted if it
is unknown (e.g., the GLO hasn't received a GLSuccessInfo
assigning the glIdentifier to the GL) or has been lost by the
GLO
Turner 13 Turner 13
3.1.8 GL Key Compromise 3.1.8 GL Key Compromise
GL members use GLKCompromise to indicate that the shared KEK they GL members and GLOs use glkCompromise to indicate that the shared
possessed has been compromised. KEK possessed has been compromised. The glKeyCompromise control
attribute shall have the syntax GeneralName. The name of the GL to
GLKCompromise ::= GLNameAndIdentifier which the compromised key is associated with is included in
GeneralName. This message is always redirected by the GLA to the GLO
The fields in GLKeyCompromise have the following meanings: for further action. The glkCompromise MUST NOT be included in an
EnvelopedData generated with the compromised shared KEK.
- glName indicates the name of the GL.
- glIdentifier indicates the identifier of the GL for which the
shared KEK is associated. The GL members MAY omit this field if
it is unknown.
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. redistributed to them. The glKeyRefresh control attribute shall have
the syntax GeneralName. The GL member includes the GL's name in
GLKRefresh ::= GLNameAndIdentifier GeneralName.
The fields in GLKRefresh have to following meaning:
- glName indicates the name of the GL.
- glIdentifier indicates the identifier of the GL for which the
shared KEK is associated. The GL members MAY omit this field if
it is unknown.
3.1.10 GL Success Information 3.1.10 GL Success Information
The GLA uses GLSuccessInfo to indicate a successful result of an The GLA uses glSuccessInfo to indicate a successful result of an
administrative message. administrative message. A separate glSuccessInfo is returned for
each action (e.g., if there are four successful glAddMember requests
then four glSuccessInfo responses are generated). The glSuccessInfo
message MUST be signed by the GLA. The glSucessInfo control
attribute shall have the syntax GLSucessInfo:
GLSuccessInfo ::= SEQUENCE { GLSuccessInfo ::= SEQUENCE {
glName GeneralName, glInfo GLInfo,
glIdentifier GLIdentifier, glIdentifier GLIdentifier,
action SEQUENCE SIZE (1..MAX) OF Action } action Action }
** With multiple GLOs do we want to indicate which GLO asked for the
action to be performed? **
Action ::= SEQUENCE { Action ::= SEQUENCE {
actionCode ActionCode, actionCode ActionCode,
glMemberName [0] GeneralName OPTIONAL, glMemberName [0] GeneralName OPTIONAL,
glOwnerName [1] GeneralName OPTIONAL } glOwnerName [1] GeneralName OPTIONAL }
Turner 14
ActionCode ::= INTEGER { ActionCode ::= INTEGER {
assignedKEK (0), assignedKEK (0),
deletedGL (1), deletedGL (1),
addedMember (2), addedMember (2),
deletedMember (3), deletedMember (3),
rekeyedGL (4), rekeyedGL (4),
addedGLO (5), addedGLO (5),
removedGLO (6) } removedGLO (6) }
The fields in GLSuccessInfo have the following meaning: The fields in GLSuccessInfo have the following meaning:
- glName indicates the name of the GL. - glInfo indicates the GL's name in glName and the GL's address in
glAddress.
- glIdentifier identifies the specific GL on the GLA (the GLA may Turner 14
support multiple GLs). - glIdentifier identifies GL's unique shared KEK.
- action indicates the successfully performed action. - action indicates the successfully performed action.
action.actionCode indicates whether the shared KEK was assigned action.actionCode indicates whether the shared KEK was assigned
to the GL, whether the GL was deleted, whether a member was to the GL, whether the GL was deleted, whether a member was
added or deleted to or from a specific GL, whether the GL added to a GL, whether a member was deleted from a GL, whether
rekeyed, whether a new GLO was added, and whether a GLO was the GL was rekeyed, whether a new GLO was added, and whether a
deleted. If members were added or deleted from a GL the members GLO was removed. If members were added to a GL or deleted from a
MUST be indicated in glMemberName. If a GLO was added or GL the members MUST be indicated in glMemberName and glOwnerName
deleted from the GL, the GLO(s) MUST be indicated in MUST be omitted. If a GLO was added to a GL or deleted from a
glOwnerName. GL, the GLO MUST be indicated in glOwnerName and glMemberName
MUST be omitted. If a shared KEK was assigned to a GL or a GL
was deleted both glOwnerName and glMember MUST be omitted.
3.1.11 GL Fail Information 3.1.11 GL Fail Information
The GLA uses GLFailInfo to indicate that there was a problem The GLA uses glFailInfo to indicate that there was a problem
performing a requested action. performing a requested action. A separate glFailInfo is returned for
each action (e.g., if there are four denied glAddMember requests
then four glFailInfo responses are generated). The glFailInfo
message MUST be signed by the GLA. The glFailInfo control attribute
shall have the syntax GLFailInfo:
GLFailInfo ::= SEQUENCE { GLFailInfo ::= SEQUENCE {
glName GeneralName, glName GeneralName,
error SEQUENCE SIZE (1..MAX) OF Error, error Error }
glIdentifier GLIdentifier OPTIONAL }
** With multiple GLOs do we want to indicate which GLO asked for the
action to be performed? **
Error ::= SEQUENCE { Error ::= SEQUENCE {
errorCode ErrorCode, errorCode ErrorCode,
glMemberName [0] GeneralName OPTIONAL, glMemberName [0] GeneralName OPTIONAL,
glOwnerName [1] GeneralName OPTIONAL } glOwnerName [1] GeneralName OPTIONAL }
Turner 15
ErrorCode ::= INTEGER { ErrorCode ::= INTEGER {
unspecified (0), unspecified (0),
closedGL (1) closedGL (1)
unsupportedDuration (2) unsupportedDuration (2)
unsupportedDistribtuionMethod (3), noGLACertificate (3),
invalidCert (4), invalidCert (4),
unsupportedAlgorithm (5), unsupportedAlgorithm (5),
noGLONameMatch (6), noGLONameMatch (6),
invalidGLName (7), invalidGLName (7),
invalidGLNameGLIdentifierCombination (8), onlyOneGLOAllowed (8),
nameAlreadyInUse (9), nameAlreadyInUse (9),
noSpam (10), noSpam (10),
deniedAccess (11), deniedAccess (11),
alreadyAMember (12), alreadyAMember (12),
notAMember (13), notAMember (13),
alreadyAnOwner (14) alreadyAnOwner (14)
notAnOwner (15) } notAnOwner (15) }
Turner 15
The fields in GLFailInfo have the following meaning: The fields in GLFailInfo have the following meaning:
- glName indicates the name of the GL to which the error - glName indicates the name of the GL to which the error
corresponds. corresponds.
- error indicates the reason why the GLA was unable to perform the - error indicates the reason why the GLA was unable to perform the
request. It also indicates the GL member or GLO to which the request. It also indicates the GL member or GLO to which the
error corresponds. If the error corresponds to a GL member or error corresponds. If members were not added to a GL or deleted
GLO, a separate Error sequence MUST be used for each GL member from a GL the members MUST be indicated in glMemberName. If a
or GLO. The errors are returned under the following conditions: GLO was not added to a GL or deleted from a GL, the GLO MUST be
indicated in glOwnerName. The errors are returned under the
following conditions:
- unspecified indicates that the GLA is unable to perform the - unspecified indicates that the GLA is unable or unwilling to
requested action but is unwilling to indicate why. perform the requested action and does not want to indicate
why.
- closedGL indicates that members can only be added or deleted - closedGL indicates that members can only be added or deleted
by the GLO. by the GLO.
- unsupportedDuration indicates the GLA does not support - unsupportedDuration indicates the GLA does not support
generating keys that are valid for the requested duration. generating keys that are valid for the requested duration.
- unsupportedDistribtuionMethod indicates that the GLA does not - noGLACertificate indicates that the GLA does not have a valid
support any of the requested delivery methods. certificate.
- invalidCert indicates the member's encryption certificate was - invalidCert indicates the member's encryption certificate was
not verifiable (i.e., signature did not validate, certificate not verifiable (i.e., signature did not validate,
present on a CRL, etc.) certificate's serial number present on a CRL, etc.).
- unsupportedAlgorithm indicates the GLA does not support the - unsupportedAlgorithm indicates the GLA does not support the
requested algorithm. requested algorithm.
- noGLONameMatch indicates the name in one of the certificates - noGLONameMatch indicates that one of the names in the
used to sign a request does not match the name of the certificate used to sign a request does not match the name of
registered GLO. a registered GLO.
Turner 16
- invalidGLName indicates the GLA does not support the glName - invalidGLName indicates the GLA does not support the glName
present in the request. present in the request.
- invalidGLNameGLIdentifierCombination indicates the GLA does
not support the glName and glIdentifier present in the
request.
- nameAlreadyInUse indicates the glName is already assigned on - nameAlreadyInUse indicates the glName is already assigned on
the GLA. the GLA.
- noSpam indicates the prospective GL member did not sign the - noSpam indicates the prospective GL member did not sign the
request (i.e., if the name in glMembers.glMemberName does not request (i.e., if the name in glMember.glMemberName does not
match one of the names in the certificate used to sign the match one of the names in the certificate used to sign the
request). request).
- alreadyAMember indicates the prospective GL member is already - alreadyAMember indicates the prospective GL member is already
a GL member. a GL member.
Turner 16
- notAMember indicates the prospective non-GL member is not a GL - notAMember indicates the prospective non-GL member is not a GL
member. member.
- alreadyAnOwner indicates the prospective GLO is already a GLO. - alreadyAnOwner indicates the prospective GLO is already a GLO.
- notAnOwner indicates the prospective non-GL member is not a - notAnOwner indicates the prospective non-GLO is not a GLO.
GLO.
- glIdentifier identifies the specific GL. It MAY be omitted if
the response is a result of a GLUseKEK request otherwise it MUST
be present.
3.1.12 GLA Query Request 3.1.12 GLA Query Request
GLOs use the GLQueryRequest to ascertain what type of GL the GLA GLOs and GL members use the glaQueryRequest to ascertain information
supports. about the GLA. The glaQueryRequest control attribute shall have the
syntax GLAQueryRequest:
GLAQueryRequest ::= SEQUENCE SIZE (1..MAX) OF GLOQuestions GLAQueryRequest ::= SEQUENCE {
glaRequestType OBJECT IDENTIFIER,
glaRequestValue ANY DEFINED BY glaResponseType }
GLOQuestions ::= INTEGER { One request type is defined herein to support the GLO in determining
supportedAlgorithms (0), the algorithms supported by the GLA:
distributionMethods (1) }
The fields in GLAQueryRequest have the following meaning: id-rt-algorithmSupported { id-tbd }
- supportedAlgorithms indicates the GLO would like to know the There is no value defined for id-rt-algorithmSupported. Including
algorithms the GLA supports for generating and distribution the the id-rt-algorithmSupport indicates that the GLO wishes to know the
shared KEK. algorithms that the GLA supports.
- distributionMethod indicates the GLO would like to know the 3.1.13 GLA Query Response
distribution methods the GLA supports for distributing the
shared KEK. GLA's return the glaQueryResponse after receiving a GLAQueryRequest.
The glaQueryResponse MUST be signed by a GLA. The glaQueryResponse
control attribute shall have the syntax GLAQueryResponse:
GLAQueryResponse ::= SEQUENCE {
glaResponseType OBJECT IDENTIFIER,
glaResponseValue ANY DEFINED BY glaResponseType }
One response type is defined herein for the GLA to indicate the
algorithms it supports:
smimeCapabilities OBJECT IDENTIFIER ::=
{iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 15}
-- Identifies the algorithms supported by the GLA (see MsgSpec [5])
3.1.14 GL Provide Cert
GLAs and GLOs use glProvideCert to request that a GL member provide
an updated or new encryption certificate. The glProvideCert message
MUST be signed by either GLA or GLO. If the GL member's PKC has been
Turner 17 Turner 17
revoked, the GLO or GLA MUST NOT use it to generate the
EnvelopedData that encapsulates the glProvideCert request. The
glProvideCert control attribute shall have the syntax GLProvideCert:
3.1.13 GLA Query Response GLProvideCert ::= SEQUENCE {
glName GeneralName,
glMemberName GeneralName}
GLA's return the GLAQueryResponse after receiving a GLAQueryRequest. The fields in GLProvideCert have the following meaning:
GLAQueryResponse ::= SEQUENCE { - glName indicates the name of the GL to which the GL member's new
supportedAlgorithms SEQUENCE OF AlgorithmIdentifier OPTIONAL, certificate should be associated.
distributionMethods SEQUENCE OF GLDistributionMethod OPTIONAL }
The fields in GLAQueryResponse have the following meaning: - glMemberName indicates name of the GL member.
- supportAlgorithms indicates the algorithm(s) and parameters that 3.1.15 GL Update Cert
GLA supports for generating and distributing the shared KEK.
- distributionMethod indicates the distribution method(s) the GLA GL members use glUpdateCert to provide a new certificate for the GL.
supports for distribution the shared KEK. GL members may generate a glUpdateCert unsolicited or as a result of
a glProvideCert message. GL members MUST sign the glUpdateCert. If
the GL member's encryption certificate has been revoked, the GL
member MUST NOT use it to generate the EnvelopedData that
encapsulates the glUpdateCert request or response. The glUpdateCert
control attribute shall have the syntax GLUpdateCert:
3.1.14 GL Key GLUpdateCert ::= SEQUENCE {
glName GeneralName,
glMember GLMember }
The GLA uses GLKey to distribute the shared KEK. The fields in GLUpdateCert have the following meaning:
- glName indicates the name of the GL to which the GL member's new
certificate should be associated.
- glMemberCert indicates the particulars for the GL member.
glMemberName indicates the GL member's name and glMemberAddress
indicates the GL member's address. certificates.membersPKC
includes the member's encryption certificate that will be used
to encrypt the shared KEK for that member.
certificates.membersAC MAY be included to convey any attribute
certificate associated with the member's encryption certificate.
certificates.certificationPath MAY also be included to convey
the certification path corresponding to the member's encryption
and attribute certificates. The certification path is optional
because it may already be included elsewhere in the message
(e.g., in the outer CMS layer).
Turner 18
3.1.16 GL Key
The GLA uses glKey to distribute the shared KEK. The glKey message
MUST be signed by the GLA. The glKey control attribute shall have
the syntax GLKey:
GLKey ::= SEQUENCE { GLKey ::= SEQUENCE {
glName GeneralName, glName GeneralName,
glIdentifier GLIdentifier, glIdentifier OCTET STRING,
glkWrapped RecipientInfos, -- See CMS [2] glkWrapped RecipientInfos, -- See CMS [2]
glkAlgorithm AlgorithmIdentifier, glkAlgorithm AlgorithmIdentifier,
glkNotBefore GeneralizedTime, glkNotBefore GeneralizedTime,
glkNotAfter GeneralizedTime } glkNotAfter GeneralizedTime }
GLIdentifier ::= CHOICE {
issuerNameAndCounter [0] IssuerNameAndCounter,
keyIdentifierAndCounter [1] KeyIdentifierAndCounter }
IssuerNameAndCounter ::= SEQUENCE {
issuer GeneralName,
counter INTEGER }
KeyIdentifierAndCounter ::= SEQUENCE {
keyIdentifier SubjectKeyIdentifier,
counter INTEGER }
SubjectKeyIdentifier ::= OCTET STRING
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 identifies the specific GL on the GLA (the GLA may - glIdentifier is the key identifier of the shared KEK. When GL
support multiple GLs). Two options are provided. The members use the shared KEK to encrypt data objects for other GL
issuerNameAndCounter alternative identifies the GLA's who members, they place the glIdentifier in
RecipientInfo.kekri.kekid.keyIdentifier field. Two options are
Turner 18 provided to generate a unique key identifier. The first choice
created shared KEK and a counter. The keyIdentifierAndCounter concatenates the GLA's subject name from the digital signature
choice identifies the GLA's certificate that was used to encrypt certificate used to sign the glKey message and counter. The
the shared KEK for the GL members and a counter. In either case second choice concatenates the GLA's subjectKeyIdentifier, from
the counter is a monotonically increasing number. The the digital signature certificate used to sign the glKey
keyIdentifierAndCounter choice MUST be supported. message, and a counter. The second choice must be supported.
- glkWrapped is the GL's wrapped shared KEK. The RecipientInfos - glkWrapped is the GL's wrapped shared KEK. The RecipientInfos
shall be generated as specified in paragraph 6.2 of CMS [2]. The shall be generated as specified in paragraph 6.2 of CMS [2]. The
kari RecipientInfo choice MUST be supported. The EncryptedKey kari RecipientInfo choice MUST be supported. The EncryptedKey
field, which is the shared KEK, MUST be generated according to field, which is the shared KEK, MUST be generated according to
the paragraph concerning random number generation in the the paragraph concerning random number generation in the
security considerations of CMS [2]. security considerations of CMS [2].
- glkAlgorithm identifies the algorithm the shared KEK is used - glkAlgorithm identifies the algorithm the shared KEK is used
with. with.
- 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 considered valid. GeneralizedTime values MUST be expressed UTC
Greenwich Mean Time (Zulu) and MUST include seconds (i.e., times (Zulu) and MUST include seconds (i.e., times are
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 considered invalid. GeneralizedTime values MUST be expressed UTC
Greenwich Mean Time (Zulu) and MUST include seconds (i.e., times (Zulu) and MUST include seconds (i.e., times are
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.
Turner 19
If the glKey message is in response to a glUseKEK message:
- The GLA MUST generate separate glKey messages for each recipient
if glUseKEK.glKeyAttributes.recipientMutuallyAware is set to
FALSE.
- The GLA MUST generate X number of glKey messages, where X is the
value in glUseKEK.glKeyAttributes.generationCounter.
If the glKey message is in response to a glRekey message:
- The GLA MUST generate separate glKey messages for each recipient
if glRekey.glNewKeyAttributes.recipientMutuallyAware is set to
FALSE.
- The GLA MUST generate X number of glKey messages, where X is the
value in glUseKEK.glKeyAttributes.generationCounter. If the
value is zero (0), the GLA MUST generate X number of glKey
messages, where X is the number of outstanding shared KEKs for
the GL (e.g., if there are two outstanding shared KEK and the
generationCounter for the glUseKEK message was set to three then
two glKey messages are generated).
If the glKey message was not in response to a glRekey or glUseKEK
(e.g., where the GLA controls rekey):
- The GLA MUST generate separate glKey messages for each recipient
if glUseKEK.glNewKeyAttributes.recipientMutuallyAware that set
up the GL was set to FALSE.
- The GLA MUST generate X glKey messages prior to the duration on
the last outstanding shared KEK expiring, where X is the
generationCounter minus one (1).
3.2 Use of CMC, CMS, and PKIX 3.2 Use of CMC, CMS, and PKIX
The following paragraphs outline the use of CMC, CMS, and PKIX.
3.2.1 Protection Layers 3.2.1 Protection Layers
The following paragraphs outline the protection required for the
control attributes defined herein.
Turner 20
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 encapsulated in PKIData and PKIResponse. The following is a
depiction 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 [2]. MUST be processed according to CMS [2].
Turner 19
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 confidentiality of the request and response. An additional
SignedData MAY also be added to provide authentication and integrity SignedData MAY also be added to provide authentication and integrity
of the encapsulated EnvelopedData. The following is a depiction of of the encapsulated EnvelopedData. The following is a depiction of
the optional additional wrappings: the optional additional wrappings:
Confidentiality Protection A&I of Confidentiality Protection Confidentiality Protection A&I of Confidentiality Protection
-------------------------- --------------------------------- -------------------------- ---------------------------------
skipping to change at line 973 skipping to change at line 1047
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 was encrypted, the corresponding outgoing If an incoming message was encrypted, the corresponding outgoing
message MUST also be encrypted. All EnvelopedData objects MUST be message MUST also be encrypted. All EnvelopedData objects MUST be
processed as specified in CMS [2]. processed as specified in CMS [2].
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 be encrypted for the GLA. If the GLA is supposed EnvelopedData MUST be encrypted for the GLA. If the GLA is to
to forward the GL member request GLO, the GLA decrypts the forward the GL member request to the GLO, the GLA decrypts the
EnvelopedData, strips the confidentiality layer off, and applies its EnvelopedData, strips the confidentiality layer off, and applies its
own confidentiality layer for the GLO. own confidentiality layer for the GLO.
3.2.2 Combining Requests and Responses 3.2.2 Combining Requests and Responses
Multiple requests and responses MAY be combined in one PKIData or Mutlipe requests and response corresponding to a GL MAY be included
PKIResponse by using PKIData.cmsSequence and in one PKIData.controlSequence or PKIResponse.controlSequence.
Requests and responses for multiple GLs MAY be combined in one
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
Turner 21
different GLs (i.e., requests corresponding to two different GLs are different GLs (i.e., requests corresponding to two different GLs are
included in different cmsSequences). The following is a diagram included in different cmsSequences). The following is a diagram
depicting multiple requests and responses combined in one PKIData depicting multiple requests and responses combined in one PKIData
and PKIResponse: and PKIResponse:
Turner 20
Multiple Request and Response Multiple Request and Response
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
Zero or more requests Zero or more responses Zero or more requests Zero 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
Zero or more requests Zero or more responses Zero or more requests Zero or more responses
corresponding to one GL. corresponding to one GL. corresponding to another GL. corresponding to another GL.
When applying confidentiality to multiple requests and responses, When applying confidentiality to multiple requests and responses,
either each request or response MAY be encrypted individually or all all of the requests/response MAY be included in one EnvelopedData.
of the requests/response MAY be included in one EnvelopedData. The The following is a depiction:
following is a depiction of the choices using PKIData:
Confidentiality of Multiple Requests and Responses Confidentiality of Multiple Requests and Responses
Individually Wrapped Wrapped Together Wrapped Together
-------------------- ---------------- ----------------
SignedData EnvelopedData EnvelopedData
PKIData SignedData SignedData
cmsSequence PKIData PKIData
EnvelopedData cmsSequence cmsSequence
SignedData SignedData SignedData
PKIData PKIResponse PKIResponse
controlSequence controlSequence controlSequence
Zero or more requests Zero or more requests Zero or more requests
corresponding to one GL. corresponding to one GL. corresponding to one GL.
EnvelopedData SignedData SignedData
SignedData PKIData PKIData
PKIData controlSequence controlSequence
controlSequence Zero or more requests Zero or more requests
Zero or more requests corresponding to one GL.
corresponding to one GL. corresponding to one GL.
Turner 21 Turner 22
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 & GLDeleteMembers glUseKEK & glDeleteMember
GLUseKEK & GLRekey glUseKEK & glRekey
GLUseKEK & GLDelete glUseKEK & glDelete
GLDelete & GLAddMembers glDelete & glAddMember
GLDelete & GLDeleteMembers glDelete & glDeleteMember
GLDelete & GLRekey glDelete & glRekey
GLDelete & GLAddOwners glDelete & glAddOwner
GLDelete & GLRemoveOwners glDelete & glRemoveOwner
GLFailInfo & GLKey glFailInfo & glKey
To avoid unnecessary errors, certain requests and responses should To avoid unnecessary errors, certain requests and responses should
be processed prior to others. The following is the priority of be processed prior to others. The following is the priority of
message processing, if not listed it is an implementation decision message processing, if not listed it is an implementation decision
as to which to process first: GLUseKEK before GLAddMembers, as to which to process first: glUseKEK before glAddMember, glRekey
GLAddMembers before GLRekey, GLDeleteMembers before GLRekey, and before glAddMember, and glDeleteMember before glRekey.
GLSuccessInfo before GLKey.
** Need to think more about the priority of processing **
3.2.3 GLA Generated Messages 3.2.3 GLA Generated Messages
When the GLO generates a GLSuccessInfo, it generates one for the GL When the GLA generates a glSuccessInfo, it generates one for each
member and another for the GLO, depending on the actionCode. request. action.actionCode values of assignedKEK, deletedGL,
action.actionCode values of assignedKEK, deletedGL, rekeyedGL, rekeyedGL, addedGLO, and deletedGLO are not returned to GL members.
addedGLO, and deletedGLO are not returned to GL members. Likewise, Likewise, when the GLA generates glFailInfo it generates one each
when the GLO generates GLFailInfo it generates one for the GL member request. error values of unsupportedDuration,
and one for the GLO, depending on the actionCode. error values of unsupportedDeliveryMethod, unsupportedAlgorithm, noGLONameMatch,
unsupportedDuration, unsupportedDeliveryMethod, nameAlreadyInUse, alreadyAnOwner, notAnOwner are not returned to GL
unsupportedAlgorithm, noGLONameMatch, nameAlreadyInUse, members.
alreadyAnOwner, notAnOwner are not returned to GL members.
Separate GLSucessInfo, GLFailInfo, and GLKey messages MUST be If GLKeyAttributes.recipientMutuallyAware is set to FALSE, a
generated for each recipient if GL was setup with separate PKIResponse.glSucessInfo, PKIResponse.glFailInfo, and
GLKeyAttributes.recipientMutuallyAware set to FALSE. PKIData.glKey MUST be generated for each recipient.
If the GL has multiple GLOs, the GLA MUST send a copy of all If the GL has multiple GLOs, the GLA MUST send the glSuccessInfo and
GLSuccessInfo and GLFailInfo messages to each GLO. glFailInfo messages to the requesting GLO. The mechanism another GLO
to determine which GLO made the request is beyond the scope of this
document.
If a GL is managed and the GLA receives a prospective GL member add Turner 23
or delete request or the GLO receives a GLFailInfo from the GL. and If a GL is managed and the GLA receives a glAddMember,
the GL is managed, the GLA forwards the request to the GLO for glDeleteMember, or glkCompromise message, the GLA redirects the
review. An additional, SignedData MUST be applied to the forwarded request to the GLO for review. An additional, SignedData MUST be
request as follows: applied to the redirected request as follows:
Turner 22
GLA Forwarded Requests GLA Forwarded Requests
---------------------- ----------------------
SignedData SignedData
PKIData PKIData
cmsSequence cmsSequence
PKIData PKIData
controlSequence controlSequence
3.2.4 CMC Control Attributes 3.2.4 CMC Control Attributes
** Elaborate more ** Certain control attributes defined in CMC [3] are allowed; they are
as follows: cMCStatusInfo, transactionId, senderNonce,
recipientNonce, and queryPending.
Can use: cMCStatusInfo is used by GLAs to indicate to GLOs and GL members
whether a request was or was not successfully completed. If the
request was successful, the GLA returns a cMCStatusInfo response
with cMCStatus.success and optionally other pertinent information in
stutsString. If the response was not successful, the GLA returns a
cMCStatusInfo response with cMCStatus.failed and optionally other
pertinent information in statusString.
CMCFailInfo.badMessageCheck - To indicate signature did not verify. When the GL is managed and the GLO has reviewed GL member initiated
glAddMember, glDeleteMember, and glkComrpomise requests, the GLO
uses cMCStatusInfo to indicate the success or failure of the
request. If the request is allowed, cMCStatus.success is returned
and statusString is optionally returned to convey additional
information. If the request is denied, cMCStatus.failed is returned
and statusString is optionally returned to convey additional
information.
transactionId - To track particular requests/responses. cMCStatusInfo is used by GLOs, GLAs, and GL members to indicate that
signature verification failed. If the signature failed to verify,
the cMCStatusInfo control attribute MUST be returned indicating
cMCStatus.failed and otherInfo.failInfo.badMessageCheck. If the
signature over the outermost PKIData failed, the bodyList value is
zero (0). If the signature over any other PKIData failed the
bodyList value is the bodyPartId value from the request or response.
senderNonce and recipientNonce - For sequence integrity. [Not sure the above is completely correct.]
3.2.5 PKIX cMCStatusInfo is also used by GLOs and GLAs to indicate that a
request could not be performed immediately. If the request could not
be processed immediately by the GLA or GLO, the cMCStatusInfo
control attribute MUST be returned indicating cMCStatus.pending and
otherInfo.pendInfo. When requests are redirected to the GLO for
Turner 24
approval (for managed lists), the GLA MUST NOT return a
cMCStatusInfo indicating query pending.
cMCStatusInfo is also used by GLAs to indicate that a
glaQueryRequest is not supported. If the glaQueryRequest is not
supported, the cMCStatusInfo control attribute MUST be returned
indicating cMCStatus.noSupport and statusString is optionally
returned to convey additional information.
transactionId MAY be included by GLOs, GLAs, or GL members to
identify a given transaction. All subsequent requests and responses
related to the original request MUST include the same transactionId
control attribute. If GL members include a transactionId and the
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, when the GLO
generates a cMCStatusInfo response it generates one for the GLA with
the GLA's transactionId and one for the GL member with the GL
member's transactionId.
senderNonce and recipientNonce (see paragraph 5.6 of [3]) MAY be
used to provide application-level replay prevention. Originating
messages include only a value for senderNonce. If a message includes
a senderNonce, the response MUST include the transmitted value of
the previously received senderNonce as recipientNonce and include a
new value for senderNonce. If GL members include a senderNonce and
the request is redirected to the GLO, the GLA MAY include an
additional senderNonce in the outer PKIData. If the GLA included an
additional senderNonce in the outer PKIData, when the GLO generates
the response:
- It generates one for the GLA by including the senderNonce from
the GLA as the recipientNonce and includes a new value for
senderNonce
- It generates one for the GL member by including the senderNonce
from the GL member as the recipientNonce and includes a new
value for senderNonce. The value of this senderNonce MUST be
different than the value in the senderNonce returned to the GLA.
The following is the implementation requirement for the CMC control
attributes:
Implementation Requirement | Control
GLO | GLA | GL Member | Attribute
O R | O R F | O R |
-------- | ------------------ | --------- | ----------
MUST MUST| MUST MUST N/A | MUST MUST | cMCStatus
MAY MAY | MAY MAY N/A | MAY MAY | transactionId
MAY MAY | MAY MAY N/A | MAY MAY | senderNonce
MAY MAY | MAY MAY N/A | MAY MAY | recepientNonce
Turner 25
3.2.5 Resubmitted GL Member Messages
When the GL is managed the GLA forwards GL member requests to the
GLO for GLO approval. If the GLO approves the request it reforms the
glAddMember, glDeleteMember, or glkCompromise message by stripping
of the GL member's signature and resigning the request.
3.2.6 PKIX
Signatures, certificates, and CRLs are verified according to PKIX Signatures, certificates, and CRLs are verified according to PKIX
[5]. [6].
Name matching is performed according to PKIX [5]. Name matching is performed according to PKIX [6].
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 performed
to manage a GL: creating the GL, deleting the GL, adding members to to manage a GL. The following sections describe each of messages'
the GL, deleting members from the GL, and requesting a group rekey. request and response combinations in detail. The procedures defined
The following sections describe each of messages' request and in this paragraph are not prescriptive.
response combinations in detail. The GLKRefresh procedures in
paragraph 4.8 SHOULD be implemented all other procedures MAY be
implemented.
4.1 Assign KEK To GL 4.1 Assign KEK To GL
Prior to generating a group key, a GL MUST be setup. Figure 3 Prior to generating a group key, a GL MUST be setup and a shared KEK
depicts the protocol interactions to setup a GL. Note that error assigned to the GL. Figure 3 depicts the protocol interactions to
messages are not depicted in Figure 3. setup and assign a shared KEK. Note that error messages are not
depicted in Figure 3.
+-----+ 1 2 +-----+ +-----+ 1 2 +-----+
| GLA | <-------> | GLO | | GLA | <-------> | GLO |
+-----+ +-----+ +-----+ +-----+
Figure 3 - Create Group List Figure 3 - Create Group List
Turner 23
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 the GL. The GLO sends a of the GL. The GLO sends a
SignedData.PKIData.controlSequence.GLUseKEK request to the GLA SignedData.PKIData.controlSequence.glUseKEK request to the GLA
(1 in Figure 3). The GLO MUST include: glName, glOwner, (1 in Figure 3). The GLO MUST include: glName, glAddress,
glAdministration, distributionMethod. The GLO MAY also include glOwnerName, glOwnerAddress, and glAdministration. The GLO MAY
their preferences for the shared KEK in glKeyAttributes by also include their preferences for the shared KEK in
indicating whether the GLO controls the rekey in glKeyAttributes by indicating whether the GLO controls the
rekeyControlledByGLO, whether separate GLKey messages should rekey in rekeyControlledByGLO, whether separate glKey messages
be sent to each recipient in recipientMutuallyAware, the should be sent to each recipient in recipientMutuallyAware,
requested algorithm to be used with the shared KEK in the 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 shared KEKs should be initially distributed in duration
and generationCounter, respectively.
a - If the GLO knows of members to be added to the GL, the Turner 26
GLAddMembers request MAY be included in the same many shared KEKs should be initially distributed in
controlSequence as the GLUseKEK request (see paragraph generationCounter.
1.a - If the GLO knows of members to be added to the GL, the
glAddMember request MAY be included in the same
controlSequence as the glUseKEK request (see paragraph
3.2.2). The GLO MUST indicate the same glName in the 3.2.2). The GLO MUST indicate the same glName in the
GLAddMembers request as in GLUseKEK.glName. The GLO MUST glAddMember request as in glUseKEK.glInfo.glName. Further
also include the member's encryption certificate in glAddMember procedures are covered in paragraph 4.3.
certificate.membersPKC. The GLO MAY also include any
attribute certificates associated with the member's
encryption certificate in membersAC and the certification
path for the member's encryption and attribute certificates.
The GLO MUST omit the glIdentifier, as it is unknown at this
point in the setup procedure.
b - The GLO MAY optionally apply confidentiality to the request 1.b - The GLO MAY optionally apply confidentiality to the request
by encapsulating the SignedData.PKIData in an EnvelopedData by encapsulating the SignedData.PKIData in an EnvelopedData
(see paragraph 3.2.1.2). (see paragraph 3.2.1.2).
c - The GLO MAY also optionally apply another SignedData over 1.c - The GLO MAY also optionally apply another SignedData over
the EnvelopedData (see paragraph 3.2.1.2). the EnvelopedData (see paragraph 3.2.1.2).
2 - Upon receipt of the request, the GLA verifies the signature on 2 - Upon receipt of the request, the GLA verifies the signature on
the inner most SignedData.PKIData. If an additional SignedData the inner most SignedData.PKIData. If an additional SignedData
and/or EnvelopedData encapsulates the request (see paragraph and/or EnvelopedData encapsulates the request (see paragraphs
3.2.1.2 or 3.2.2), the GLA MUST verify the outer signature 3.2.1.2 and 3.2.2), the GLA MUST verify the outer signature(s)
and/or decrypt the outer layer prior to verifying the and/or decrypt the outer layer(S) prior to verifying the
signature on the inner most SignedData. signature on the inner most SignedData.
a - If the signature(s) does(do) not verify, the GLA MUST return 2.a - If the signature(s) does(do) not verify, the GLA MUST return
a response indicating CMCFailInfo.badMessageCheck. a cMCStatusInfo response indicating cMCStatus.failed and
otherInfo.failInfo.badMessageCheck.
b - If the signature(s) does(do) verify, the GLA MUST check that 2.b - If the signature(s) does(do) verify but the GLA does not
one of the names in the certificate used to sign the request have a valid certificate, the GLA MUST return a
matches the name in CreateGL.glOwner. glFailInfo.errorCode.noValidGLACertificate.
Turner 24 2.c - If the signature(s) does(do) verify and the GLA does have a
1 - If the names do not match, the GLA MUST return a response valid certificate, the GLA MUST check that one of the names
indicating GLFailInfo.errorCode.noGLONameMatch. in the certificate used to sign the request matches one of
the names in glUseKEK.glOwnerInfo.glOwnerName.
2 - If names do all match, the GLA MUST ensure the combination 2.c.1 - If the names do not match, the GLA MUST return a response
of the requested glName is not already in use. The GLA indicating glFailInfo.errorCode.noGLONameMatch.
MUST also check any GLAddMembers included within the
controlSequence with this GLCreate. Further processing of
the GLAddMembers is covered in paragraph 4.3.
a - If the glName is already in use the GLA MUST return a 2.c.2 - If names do all match, the GLA MUST ensure the requested
glName is not already in use. The GLA MUST also check any
glAddMember included within the controlSequence with this
glUseKEK. Further processing of the glAddMember is covered
in paragraph 4.3.
2.c.2.a - If the glName is already in use the GLA MUST return a
response indicating response indicating
GLFailInfo.errorCode.nameAlreadyInUse. glFailInfo.errorCode.nameAlreadyInUse.
b - If the requestedAlgorithm is not supported, the GLA MUST Turner 27
2.c.2.b - If the requestedAlgorithm is not supported, the GLA MUST
return a response indicating return a response indicating
GLFailInfo.errorCode.unsupportedAlgorithm. glFailInfo.errorCode.unsupportedAlgorithm.
c - If the duration is not supportable, determining this is 2.c.2.c - If the duration is not supportable, determining this is
beyond the scope of this document, the GLA MUST return a beyond the scope of this document, the GLA MUST return a
response indicating response indicating
GLFailInfo.errorCode.unsupportedDuration. glFailInfo.errorCode.unsupportedDuration.
d - If the GL is not supportable for other reasons, which 2.c.2.d - If the glAdministration is set to closed (0) and there
is more than one GLO in glOwner, the GLA MUST return a
response indicating
glFailInfo.errorCode.onlyOneGLOAllowed.
2.c.2.e - If the GL is not supportable for other reasons, which
the GLA does not wish to disclose, the GLA MUST return a the GLA does not wish to disclose, the GLA MUST return a
response indicating GLFailInfo.errorCode.unspecified. response indicating glFailInfo.errorCode.unspecified.
e - If the glName distribution is not already in use, the 2.c.2.f - If the glName is not already in use, the duration is
duration is supportable, and the requestedAlgorithm is supportable, and the requestedAlgorithm is supported,
supported, the GLA MUST return a GLSuccessInfo to all the GLA MUST return a glSuccessInfo indicating the
GLOs indicating the glName, the corresponding glName, the corresponding glIdentifier, and an
glIdentifier, and an action.actionCode.assignedKEK (2 in action.actionCode.assignedKEK (2 in Figure 3). The GLA
Figure 3). The GLA also takes administrative actions, also takes administrative actions, which are beyond the
which are beyond the scope of this document, to store scope of this document, to store the glName, glAddress,
the glName, distributionMethod, glOwner, and any member glKeyAttributes, glOwnerName, and glOwnerAddress. The
that has been added. GLA also sends a glKey message as described in paragraph
5.
1 - The GLA MUST apply confidentiality to the response by 2.c.2.f.1 - The GLA MUST apply 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 paragraph 3.2.1.2). EnvelopedData (see paragraph 3.2.1.2).
2 - The GLA MAY also optionally apply another SignedData 2.c.2.f.2 - The GLA MAY also optionally apply another SignedData
over the EnvelopedData (see paragraph 3.2.1.2). over the EnvelopedData (see paragraph 3.2.1.2).
3 - Upon receipt of the GLSuccessInfo or GLFailInfo responses, the 3 - Upon receipt of the glSuccessInfo or glFailInfo responses, the
GLO verifies the GLA's signature(s). If an additional GLO verifies the GLA's signature(s). If an additional
SignedData and/or EnvelopedData encapsulates the response (see SignedData and/or EnvelopedData encapsulates the response (see
paragraph 3.2.1.2 or 3.2.2), the GLO MUST verify the outer paragraph 3.2.1.2 or 3.2.2), the GLO MUST verify the outer
signature and/or decrypt the outer layer prior to verifying signature and/or decrypt the outer layer prior to verifying
the signature on the inner most SignedData. the signature on the inner most SignedData.
Turner 25 3.a - If the signatures do not verify, the GLO MUST return a
a - If the signatures do not verify, the GLO MUST return a cMCStatusInfo response indicating cMCStatus.failed and
response indicating CMCFailInfo.badMessageCheck. otherInfo.failInfo.badMessageCheck.
b - If the signatures do verify and the response was 3.b - If the signatures do verify and the response was
GLSuccessInfo, the GLO has successfully created the GL. glSuccessInfo, the GLO has successfully created the GL.
c - If the signatures do verify and the response was GLFailInfo, Turner 28
3.c - If the signatures do verify and the response was glFailInfo,
the GLO MAY reattempt to create the GL using the information the GLO MAY reattempt to create the GL using the information
provided in the GLFailInfo response. The GLO may also use provided in the glFailInfo response. The GLO may also use
the GLAQueryRequest to determine the algorithms and the glaQueryRequest to determine the algorithms and other
distribution methods supported by the GLA (see paragraph characteristics supported by the GLA (see paragraph 4.9).
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 From time to time, there are instances when a GL is no longer
needed. In this case the GLO must delete the GL. Figure 4 depicts needed. In this case the GLO must delete the GL. Figure 4 depicts
that protocol interactions to delete a GL. that protocol interactions to delete a GL.
+-----+ 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 the entity responsible for requesting the deletion 1 - The GLO is the entity responsible for requesting the deletion
of the GL. The GLO sends a of the GL. The GLO sends a
SignedData.PKIData.controlSequence.GLDelete request to the GLA SignedData.PKIData.controlSequence.glDelete request to the GLA
(1 in Figure 4). The GLO MUST include the name of the GL in (1 in Figure 4). The name of the GL to be deleted MUST be
glName. The GLO MAY also include the GL identifier included in GeneralName.
glIdentifier.
b - The GLO MAY optionally apply confidentiality to the request 1.a - The GLO MAY optionally apply confidentiality to the request
by encapsulating the SignedData.PKIData in an EnvelopedData by encapsulating the SignedData.PKIData in an EnvelopedData
(see paragraph 3.2.1.2). (see paragraph 3.2.1.2).
c - The GLO MAY also optionally apply another SignedData over 1.b - The GLO MAY also optionally apply another SignedData over
the EnvelopedData (see paragraph 3.2.1.2). the EnvelopedData (see paragraph 3.2.1.2).
2 - Upon receipt of the request the GLA verifies the signature on 2 - Upon receipt of the request the GLA verifies the signature on
the inner most SignedData.PKIData. If an additional SignedData the inner most SignedData.PKIData. If an additional SignedData
and/or EnvelopedData encapsulates the request (see paragraph and/or EnvelopedData encapsulates the request (see paragraph
3.2.1.2 or 3.2.2), the GLA MUST verify the outer signature 3.2.1.2 or 3.2.2), the GLA MUST verify the outer signature
and/or decrypt the outer layer prior to verifying the and/or decrypt the outer layer prior to verifying the
signature on the inner most SignedData. signature on the inner most SignedData.
a - If the signature(s) does(do) not verify, the GLA MUST return 2.a - If the signature(s) does(do) not verify, the GLA MUST return
a response indicating CMCFailInfo.badMessageCheck. a cMCStatusInfo response indicating cMCStatus.failed and
otherInfo.failInfo.badMessageCheck.
Turner 26
b - If the signature(s) does(do) verify, the GLA MUST make sure
the GL is supported by checking either that the glName is
supported (in the case the glIdentifier is omitted) or that
the combination of glName and glIdentifier matches a glName
and glIdentifier combination stored on the GLA.
1 - If the glIdentifier is omitted and the glName is not 2.b - If the signature(s) does(do) verify, the GLA MUST make sure
supported by the GLA, the GLA MUST return a response the GL is supported by checking the GL's Name matches a
indicating GLFailInfo.errorCode.invalidGLName. glName stored on the GLA.
2 - If the glName and glIdentifier are present and do not Turner 29
match a GL stored on the GLA, the GLA MUST return a 2.b.1 - If the glName is not supported by the GLA, the GLA MUST
response indicating return a response indicating
GLFailInfo.errorCode.invalidGLNameGLIdentifierCombination. glFailInfo.errorCode.invalidGLName.
3 - If the glIdentifier is omitted and the glName is supported 2.b.2 - If the glName is supported by the GLA, the GLA MUST ensure
by the GLA or if the glIdentifier/glName combination is a registered GLO signed the glDelete request by checking
supported by the GLA, the GLA MUST ensure a registered GLO if one of the names present in the digital signature
signed the GLDelete request by checking if the name certificate used to sign the glDelete request matches a
present in the digital signature certificate used to sign registered GLO.
the GLDelete request matches one of the registered GLOs.
a - If the names do not match, the GLA MUST return a 2.b.2.a - If the names do not match, the GLA MUST return a
response indicating GLFailInfo.errorCode.noGLONameMatch. response indicating glFailInfo.errorCode.noGLONameMatch.
b - If the names do match but the GL is not deletable for 2.b.2.b - If the names do match but the GL is not deletable for
other reasons, which the GLA does not wish to disclose, other reasons, which the GLA does not wish to disclose,
the GLA MUST return a response indicating the GLA MUST return a response indicating
GLFailInfo.errorCode.unspecified. glFailInfo.errorCode.unspecified. Actions beyond the
scope of this document must then be taken to delete the
GL from the GLA.
c - If all the names do match, the GLA MUST return to all 2.b.2.c - If the names do match, the GLA MUST return a
the GLOs a GLSucessInfo indicating the glName, the glSuccessInfo indicating the glName, and an
corresponding glIdentifier, and an action.actionCode.deletedGL (2 in Figure 4).
action.actionCode.deletedGL (2 in Figure 4). The GLA glMemberName and glOwnerName MUST be omitted. The GLA
MUST not accept further requests for member additions, MUST not accept further requests for member additions,
member deletions, or group rekeys for this GL. member deletions, or group rekeys for this GL.
1 - The GLA MUST apply confidentiality to the response by 2.b.2.c.1 - The GLA MUST apply 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 paragraph 3.2.1.2). EnvelopedData (see paragraph 3.2.1.2).
2 - The GLA MAY also optionally apply another SignedData 2.b.2.c.2 - The GLA MAY also optionally apply another SignedData
over the EnvelopedData (see paragraph 3.2.1.2). over the EnvelopedData (see paragraph 3.2.1.2).
3 - Upon receipt of the GLSuccessInfo or GLFailInfo response, the 3 - Upon receipt of the glSuccessInfo or glFailInfo response, the
GLO verifies the GLA's signature(s). If an additional GLO verifies the GLA's signature(s). If an additional
SignedData and/or EnvelopedData encapsulates the response (see SignedData and/or EnvelopedData encapsulates the response (see
paragraph 3.2.1.2 or 3.2.2), the GLO MUST verify the outer paragraph 3.2.1.2 or 3.2.2), the GLO MUST verify the outer
signature and/or decrypt the outer layer prior to verifying signature and/or decrypt the outer layer prior to verifying
the signature on the inner most SignedData. the signature on the inner most SignedData.
Turner 27 3.a - If the signature(s) does(do) not verify, the GLO MUST return
a - If the signature(s) does(do) not verify, the GLO MUST return a cMCStatusInfo response indicating cMCStatus.failed and
a response indicating CMCFailInfo.badMessageCheck. otherInfo.failInfo.badMessageCheck.
b - If the signatures do verify and the response was 3.b - If the signatures do verify and the response was
GLSuccessInfo, the GLO has successfully deleted the GL. glSuccessInfo, the GLO has successfully deleted the GL.
c - If the signatures do verify and the response was GLFailInfo, 3.c - If the signatures do verify and the response was glFailInfo,
the GLO MAY reattempt to delete the GL using the information the GLO MAY reattempt to delete the GL using the information
provided in the GLFailInfo response. provided in the glFailInfo response.
Turner 30
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
GLAddMembers request. There are however different scenarios that glAddMember request. The GLA processes GLO and prospective GL member
should be supported. Either the GLO or prospective members may requests differently though. GLOs can submit the request at any time
submit the GLAddMembers request to the GLA, but the GLA processes
the requests differently. The GLO 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 the GLO should process it. If a prospective member request came from a registered GLO, should process it. If a
sends the request, the GLA needs to determine how the GL is prospective member sends the request, the GLA needs to determine how
administered. When the GLO initially configured the GL, they set the the GL is administered. When the GLO initially configured the GL,
GL to be unmanaged, managed, or closed (see paragraph 3.1.1). In the they set the GL to be unmanaged, managed, or closed (see paragraph
unmanaged case, the GLA merely processes the member's request. For 3.1.1). In the unmanaged case, the GLA merely processes the member's
the managed case, the GLA forwards the requests from the prospective request. For the managed case, the GLA forwards the requests from
members to the GLO. Where there are multiple GLOs for a GL, which the prospective members to the GLO for review. Where there are
GLO the request is forwarded to is beyond the scope of this multiple GLOs for a GL, which GLO the request is forwarded to is
document. In the closed case, the GLA will not accept requests from beyond the scope of this document. The GLO reviews the request and
prospective members. The following paragraphs describe the either rejects it or submits a reformed request to the GLA. In the
processing required by the GLO, GLA, and prospective GL members closed case, the GLA will not accept requests from prospective
depending on where the request originated, either from the GLO or members. The following paragraphs describe the processing for the
from prospective members. Figure 5 depicts the protocol interactions GLO(s), GLA, and prospective GL members depending on where the
for the three options. Note that the error messages are not glAddMeber request originated, either from a GLO or from prospective
depicted. members. Figure 5 depicts the protocol interactions for the three
options. Note that the error messages are not depicted.
+-----+ 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 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 basis is whether to rekey the group every time a new member is
Turner 28
added. Typically, unmanaged GLs should not be rekeyed when a new added. Typically, unmanaged GLs should not be rekeyed when a new
member is added, as the overhead associated with rekeying the group member is added, as the overhead associated with rekeying the group
becomes prohibitive, as the group becomes large. However, managed becomes prohibitive, as the group becomes large. However, managed
and closed GLs MUST be rekeyed to maintain the secrecy of the group. and closed GLs MUST be rekeyed to maintain the secrecy of the group.
An option to rekeying the managed GLs when a member is added is to An option to rekeying managed or closed GLs when a member is added
generate a new GL with a different group key. Group rekeying is is to generate a new GL with a different group key. Group rekeying
discussed in paragraphs 4.5 and 5. is discussed in paragraphs 4.5 and 5.
Turner 31
4.3.1 GLO Initiated Additions 4.3.1 GLO Initiated Additions
The process for GLO initiated GLAddMembers requests is as follows: The process for GLO initiated glAddMember requests is as follows:
1 - The GLO collects the names and pertinent information for the 1 - The GLO collects the pertinent information for the member(s)
members to be added (this MAY be done through an out of bands to be added (this MAY be done through an out of bands means).
means). The GLO then sends a The GLO then sends a SignedData.PKIData.controlSequence with a
SignedData.PKIData.controlSequence.GLAddMembers request to the separate glAddMember request for each member to the GLA (1 in
GLA (1 in Figure 5). The GLO MUST include: the GL name in Figure 5). The GLO MUST include: the GL name in glName, the
glName, the member's name in glMembers.glMemberName, the member's name in glMember.glMemberName, the member's address
in glMember.glMemberAddress, and the member's encryption
certificate in glMember.certificates.membersPKC. The GLO MAY
also include any attribute certificates associated with the
member's encryption certificate in member's encryption certificate in
glMembers.certificates.membersPKC. The GLO MAY also include glMember.certificates.membersAC, and the certification path
the GL identifier in glIdentifier, if known, any attribute associated with the member's encryption and attribute
certificates associated with the member's encryption certificates in glMember.certificates.certificationPath.
certificate in glMembers.certificates.membersAC, and the
certification path associated with the member's encryption and
attribute certificates in
glMembers.certificates.certificationPath.
a - The GLO MAY optionally apply confidentiality to the request 1.a - The GLO MAY optionally apply confidentiality to the request
by encapsulating the SignedData.PKIData in an EnvelopedData by encapsulating the SignedData.PKIData in an EnvelopedData
(see paragraph 3.2.1.2). (see paragraph 3.2.1.2).
b - The GLO MAY also optionally apply another SignedData over 1.b - The GLO MAY also optionally apply another SignedData over
the EnvelopedData (see paragraph 3.2.1.2). the EnvelopedData (see paragraph 3.2.1.2).
2 - Upon receipt of the request, the GLA verifies the signature on 2 - Upon receipt of the request, the GLA verifies the signature on
the inner most SignedData.PKIData. If an additional SignedData the inner most SignedData.PKIData. If an additional SignedData
and/or EnvelopedData encapsulates the request (see paragraph and/or EnvelopedData encapsulates the request (see paragraph
3.2.1.2 or 3.2.2), the GLA MUST verify the outer signature 3.2.1.2 or 3.2.2), the GLA MUST verify the outer signature
and/or decrypt the outer layer prior to verifying the and/or decrypt the outer layer prior to verifying the
signature on the inner most SignedData. signature on the inner most SignedData.
a - If the signature(s) does(do) not verify, the GLA MUST return 2.a - If the signature(s) does(do) not verify, the GLA MUST return
a response indicating CMCFailInfo.badMessageCheck. a cMCStatusInfo response indicating cMCStatus.failed and
otherInfo.failInfo.badMessageCheck.
b - If the signature(s) does(do) verify, the GLAddMembers 2.b - If the signature(s) does(do) verify, the glAddMember request
request is included in a controlSequence with the GLUseKEK is included in a controlSequence with the glUseKEK request,
request, and the processing of 2.b.2 is successfully and the processing in paragraph 4.1 item 2.e is successfully
completed the GLA MUST return to all GLOs a GLSuccessInfo completed the GLA MUST return a glSuccessInfo indicating the
indicating the glName, the corresponding glIdentifier, an glName, the corresponding glIdentifier, an
action.actionCode.addedMember, and action.glMemberName (2 in action.actionCode.addedMember, and action.glMemberName (2 in
Figure 5).
Turner 29 2.b.1 - The GLA MUST apply confidentiality to the response by
Figure 5). The response MUST be constructed as specified in
paragraph 3.2.3.
1 - The GLA MUST apply confidentiality to the response by
encapsulating the SignedData.PKIData in an EnvelopedData encapsulating the SignedData.PKIData in an EnvelopedData
if the request was encapsulated in an EnvelopedData (see if the request was encapsulated in an EnvelopedData (see
paragraph 3.2.1.2). paragraph 3.2.1.2).
2 - The GLA MAY also optionally apply another SignedData over 2.b.2 - The GLA MAY also optionally apply another SignedData over
the EnvelopedData (see paragraph 3.2.1.2). the EnvelopedData (see paragraph 3.2.1.2).
c - If the signature(s) does(do) verify and the GLAddMember Turner 32
2.c - If the signature(s) does(do) verify and the GLAddMember
request is not included in a controlSequence with the request is not included in a controlSequence with the
GLCreate request, the GLA MUST make sure the GL is supported GLCreate request, the GLA MUST make sure the GL is supported
by checking either that the glName is supported (in the case by checking that the glName matches a glName stored on the
the glIdentifier is omitted) or that the combination of GLA.
glName and glIdentifier matches a glName and glIdentifier
stored on the GLA.
1 - If the glIdentifier is omitted and the glName is not
supported by the GLA, the GLA MUST return a response
indicating GLFailInfo.errorCode.invalidGLName.
2 - If the glName and glIdentifier are present and do not 2.c.1 - If the glName is not supported by the GLA, the GLA MUST
match a GL stored on the GLA, the GLA MUST return a return a response indicating
response indicating glFailInfo.errorCode.invalidGLName.
GLFailInfo.errorCode.invalidGLNameGLIdentifierCombination.
3 - If the glIdentifier is omitted and the glName is supported 2.c.2 - If the glName is supported by the GLA, the GLA MUST check
by the GLA or if the glIdentifier/glName combination is to see if the glMemberName is present on the GL.
present and supported, the GLA MUST check to see if the
glMemberName is present on the GL.
a - If the glMemberName is present on the GL, the GLA MUST 2.c.2.a - If the glMemberName is present on the GL, the GLA MUST
return a response indicating return a response indicating
GLFailInfo.errorCode.alreadyAMember. glFailInfo.errorCode.alreadyAMember.
b - If the glMemberName is not present on the GL, the GLA 2.c.2.b - If the glMemberName is not present on the GL, the GLA
the GLA MUST check how the GL is administered. MUST check how the GL is administered.
1 - If the GL is closed, the GLA MUST check that GLO 2.c.2.b.1 - If the GL is closed, the GLA MUST check that a
signed the request by checking that one of the names registered GLO signed the request by checking that one
in the digital signature certificate used to sign the of the names in the digital signature certificate used
request matches one of the registered GLOs. to sign the request matches a registered GLO.
a - If the names do not match, the GLA MUST return a 2.c.2.b.1.a - If the names do not match, the GLA MUST return a
response indicating response indicating
GLFailInfo.errorCode.noGLONameMatch. glFailInfo.errorCode.noGLONameMatch.
b - If the names do match, the GLA MUST verify the 2.c.2.b.1.b - If the names do match, the GLA MUST verify the
member's encryption certificate. member's encryption certificate.
Turner 30 2.c.2.b.1.b.1 - If the member's encryption certificate does not
1 - If the member's encryption certificate does not verify, the GLA MAY return a response indicating
verify, the GLA MUST return a response indicating glFailInfo.errorCode.invalidCert to the GLO. If
GLFailInfo.errorCode.invalidCert. the GLA does not return a glFailInfo response, the
GLA MUST issue a glProvideCert request (see
paragraph 4.10).
2 - If the member's certificate does verify, the GLA 2.c.2.b.1.b.2 - If the member's certificate does verify, the GLA
MUST return to all GLOs a GLSuccessInfo indicating MUST return a glSuccessInfo to the GLO indicating
the glName, the corresponding glIdentifier, an the glName, the corresponding glIdentifier, an
action.actionCode.addedMember, and action.actionCode.addedMember, and
action.glMemberName (2 in Figure 5). The response action.glMemberName (2 in Figure 5). The GLA also
MUST be constructed as in paragraph 3.2.3. The GLA takes administrative actions, which are beyond the
also takes administrative actions, which are scope of this document, to add the member to the
beyond the scope of this document, to add the GL stored on the GLA. The GLA MUST also distribute
member with the GL stored on the GLA. The GLA will the shared KEK to the member via the mechanism
also distribute the shared KEK to the member via described in paragraph 5.
the mechanism described in paragraph 5.
a - The GLA MUST apply confidentiality to the 2.c.2.b.1.b.2.a - The GLA MUST apply confidentiality to the
response by encapsulating the SignedData.PKIData response by encapsulating the SignedData.PKIData
Turner 33
in an EnvelopedData if the request was in an EnvelopedData if the request was
encapsulated in an EnvelopedData (see paragraph encapsulated in an EnvelopedData (see paragraph
3.2.1.2). 3.2.1.2).
b - The GLA MAY also optionally apply another 2.c.2.b.1.b.2.b - The GLA MAY also optionally apply another
SignedData over the EnvelopedData (see paragraph SignedData over the EnvelopedData (see paragraph
3.2.1.2). 3.2.1.2).
2 - If the GL is managed, the GLA MUST check that either 2.c.2.b.2 - If the GL is managed, the GLA MUST check that either a
the GLO or the prospective member signed the request. registered GLO or the prospective member signed the
For the GLO, one of the names in the certificate used request. For GLOs, one of the names in the certificate
to sign the request MUST match one of the registered used to sign the request MUST match a registered GLO.
GLOs. For the prospective member, the name in For the prospective member, the name in
glMembers.glMemberName MUST match one of the names in glMember.glMemberName MUST match one of the names in
the certificate used to sign the request. the certificate used to sign the request.
a _ If the signer is neither a registered GLO or the 2.c.2.b.2.a - If the signer is neither a registered GLO nor the
prospective GL member, the GLA MUST return a prospective GL member, the GLA MUST return a
response indicating GLFailInfo.errorCode.noSpam. response indicating glFailInfo.errorCode.noSpam.
b - If the signer is the GLO, the GLA MUST verify the 2.c.2.b.2.b - If the signer is a registered GLO, the GLA MUST
member's encryption certificate. verify the member's encryption certificate.
1 - If the member's certificate does not verify, the 2.c.2.b.2.b.1 - If the member's certificate does not verify, the
GLA MUST return a response indicating GLA MAY return a response indicating
GLFailInfo.errorCode.invalidCert. glFailInfo.errorCode.invalidCert. If the GLA does
not return a glFailInfo response, the GLA MUST
issue a glProvideCert request (see paragraph
4.10).
2 - If the member's certificate does verify, the GLA 2.c.2.b.2.b.2 - If the member's certificate does verify, the GLA
MUST return to all GLOs GLSuccessInfo indicating MUST return glSuccessInfo indicating the glName,
the glName, the corresponding glIdentifier, an the corresponding glIdentifier, an
action.actionCode.addedMember, and action.actionCode.addedMember, and
action.glMemberName to the GLO (2 in Figure 5). action.glMemberName to the GLO (2 in Figure 5).
The response MUST be constructed as in paragraph The GLA also takes administrative actions, which
3.2.3. The GLA also takes administrative actions, are beyond the scope of this document, to add the
member to the GL stored on the GLA. The GLA MUST
Turner 31 also distribute the shared KEK to the member via
which are beyond the scope of this document, to the mechanism described in paragraph 5.
add the member with the GL stored on the GLA. The
GLA will also distribute the shared KEK to the
member via the mechanism described in paragraph 5.
a - The GLA MUST apply confidentiality to the 2.c.2.b.2.b.2.a - The GLA MUST apply confidentiality to the
response by encapsulating the SignedData.PKIData response by encapsulating the SignedData.PKIData
in an EnvelopedData if the request was in an EnvelopedData if the request was
encapsulated in an EnvelopedData (see paragraph encapsulated in an EnvelopedData (see paragraph
3.2.1.2). 3.2.1.2).
b - The GLA MAY also optionally apply another 2.c.2.b.2.b.2.b - The GLA MAY also optionally apply another
SignedData over the EnvelopedData (see paragraph SignedData over the EnvelopedData (see paragraph
3.2.1.2). 3.2.1.2).
c - If the signer is the prospective member, the GLA Turner 34
forwards the GLAddMembers request (see paragraph 2.c.2.b.2.c - If the signer is the prospective member, the GLA
3.2.3) to the GLO (B{A} in Figure 5). Which GLO the MUST forward the glAddMember request (see paragraph
request is forwarded to is beyond the scope of this 3.2.3) to a registered GLO (B{A} in Figure 5). If
document. Further processing of the forwarded there is more than one registered GLO, the GLO to
request by the GLO is addressed in 3 of paragraph which the request is forwarded to is beyond the
4.3.2. scope of this document. Further processing of the
forwarded request by GLOs is addressed in 3 of
paragraph 4.3.2.
1 - The GLA MUST apply confidentiality to the 2.c.2.b.2.c.1 - The GLA MUST apply confidentiality to the
forwarded request by encapsulating the forwarded request by encapsulating the
SignedData.PKIData in an EnvelopedData if the SignedData.PKIData in an EnvelopedData if the
original request was encapsulated in an original request was encapsulated in an
EnvelopedData (see paragraph 3.2.1.2). EnvelopedData (see paragraph 3.2.1.2).
2 - The GLA MAY also optionally apply another 2.c.2.b.2.c.2 - The GLA MAY also optionally apply another
SignedData over the EnvelopedData (see paragraph SignedData over the EnvelopedData (see paragraph
3.2.1.2). 3.2.1.2).
3 - If the GL is unmanaged, the GLA MUST check that either 2.c.2.b.3 - If the GL is unmanaged, the GLA MUST check that either
the GLO or the prospective member signed the request. a registered GLO or the prospective member signed the
For the GLO, one of the names in the certificate used request. For GLOs, one of the names in the certificate
to sign the request MUST match one of the registered used to sign the request MUST match the name of a
GLOs. For the prospective member, the name in registered GLO. For the prospective member, the name
glMembers.glMemberName MUST match one of the names in in glMember.glMemberName MUST match one of the names
the certificate used to sign the request. in the certificate used to sign the request.
a - If the signer is not the GLO or the prospective 2.c.2.b.3.a - If the signer is neither a registered GLO nor the
member, the GLA MUST return a response indicating prospective member, the GLA MUST return a response
GLFailInfo.errorCdoe.noSpam. indicating glFailInfo.errorCode.noSpam.
b - If the signer is either the GLO or the prospective 2.c.2.b.3.b - If the signer is either a registered GLO or the
member, the GLA MUST verify the member's encryption prospective member, the GLA MUST verify the member's
certificate. encryption certificate.
1 - If the member's certificate does not verify, the 2.c.2.b.3.b.1 - If the member's certificate does not verify, the
GLA MUST return a response indicating GLA MAY return a response indicating
GLFailInfo.errorCode.invalidCert. glFailInfo.errorCode.invalidCert to either the GLO
or the prospective member depending on where the
request originated. If the GLA does not return a
glFailInfo response, the GLA MUST issue a
glProvideCert request (see paragraph 4.10) to
either the GLO or prospective member depending on
where the request originated.
Turner 32 2.c.2.b.3.b.2 - If the member's certificate does verify, the GLA
2 - If the member's certificate does verify, the GLA MUST return a glSuccessInfo indicating the glName,
MUST return a GLSucessInfo indicating the glName,
the corresponding glIdentifier, an the corresponding glIdentifier, an
action.actionCode.addedMember, and action.actionCode.addedMember, and
action.glMemberName to the GLO (2 in Figure 5) if action.glMemberName to the GLO (2 in Figure 5) if
the GLO signed the request and to the GL member (3 the GLO signed the request and to the GL member (3
in Figure 5) if the GL member signed the request. in Figure 5) if the GL member signed the request.
The response MUST be constructed as in paragraph
3.2.3. The GLA also takes administrative actions,
which are beyond the scope of this document, to
add the member with the GL stored on the GLA. The
GLA will also distribute the shared KEK to the
member via the mechanism described in paragraph 5.
a - The GLA MUST apply confidentiality to the Turner 35
forwarded request by encapsulating the The GLA also takes administrative actions, which
SignedData.PKIData in an EnvelopedData if the are beyond the scope of this document, to add the
request was encapsulated in an EnvelopedData member to the GL stored on the GLA. The GLA MUST
(see paragraph 3.2.1.2). also distribute the shared KEK to the member via
the mechanism described in paragraph 5.
b - The GLA MAY also optionally apply another 2.c.2.b.3.b.2.a - The GLA MUST apply confidentiality to the
response by encapsulating the SignedData.PKIData
in an EnvelopedData if the request was
encapsulated in an EnvelopedData (see paragraph
3.2.1.2).
2.c.2.b.3.b.2.b - The GLA MAY also optionally apply another
SignedData over the EnvelopedData (see paragraph SignedData over the EnvelopedData (see paragraph
3.2.1.2). 3.2.1.2).
3 - Upon receipt of the GLSuccessInfo or GLFailInfo response, the 3 - Upon receipt of the glSuccessInfo or glFailInfo response, the
GLO verifies the GLA's signature(s). If an additional GLO verifies the GLA's signature(s). If an additional
SignedData and/or EnvelopedData encapsulates the response (see SignedData and/or EnvelopedData encapsulates the response (see
paragraph 3.2.1.2 or 3.2.2), the GLO MUST verify the outer paragraph 3.2.1.2 or 3.2.2), the GLO MUST verify the outer
signature and/or decrypt the outer layer prior to verifying signature and/or decrypt the outer layer prior to verifying
the signature on the inner most SignedData. the signature on the inner most SignedData.
a - If the signature(s) does (do) not verify, the GLO MUST 3.a - If the signature(s) does (do) not verify, the GLO MUST
return a response indicating CMCFailInfo.badMessageCheck. return a cMCStatusInfo response indicating cMCStatus.failed
and otherInfo.failInfo.badMessageCheck.
b - If the signature(s) does(do) verify, the GLO has added the 3.b - If the signature(s) does(do) verify and the response is
member to the GL. glSuccessInfo, the GLO has added the member to the GL. If
member was added to a managed list and the original request
was signed by the member, the GLO MUST send a
cMCStatusInfo.cMCStatus.success to the GL member.
c - If the GLO received a GLFailInfo, for any reason, the GLO 3.c - If the GLO received a glFailInfo, for any reason, the GLO
MAY reattempt to add the member to the GL using the MAY reattempt to add the member to the GL using the
information provided in the GLFailInfo response. information provided in the glFailInfo response.
4 - Upon receipt of the GLSuccessInfo or GLFailInfo response, the 4 - Upon receipt of the glSuccessInfo, glFailInfo, or cMCStatus
prospective member verifies the GLA's signature(s). If an response, the prospective member verifies the GLA's
additional SignedData and/or EnvelopedData encapsulates the signature(s) or GLO's signature(s). If an additional
response (see paragraph 3.2.1.2 or 3.2.2), the GLO MUST verify SignedData and/or EnvelopedData encapsulates the response (see
the outer signature and/or decrypt the outer layer prior to paragraph 3.2.1.2 or 3.2.2), the GLO MUST verify the outer
verifying the signature on the inner most SignedData. signature and/or decrypt the outer layer prior to verifying
the signature on the inner most SignedData.
a - If the signatures do not verify, the prospective member MUST 4.a - If the signatures do not verify, the prospective member MUST
return a response indicating CMCFailInfo.badMessageCheck. return a cMCStatusInfo response indicating cMCStatus.failed
and otherInfo.failInfo.badMessageCheck.
Turner 33 4.b - If the signatures do verify, the prospective member has been
b - If the signatures do verify, the prospective member has been
added to the GL. added to the GL.
c - If the prospective member received a GLFailInfo, for any Turner 36
4.c - If the prospective member received a glFailInfo, for any
reason, the prospective member MAY reattempt to add reason, the prospective member MAY reattempt to add
themselves to the GL using the information provided in the themselves to the GL using the information provided in the
GLFailInfo response. glFailInfo response.
4.3.2 Prospective Member Initiated Additions 4.3.2 Prospective Member Initiated Additions
The process for prospective member initiated GLAddMembers requests The process for prospective member initiated glAddMember requests is
is as follows: as follows:
1 - The prospective GL member sends a 1 - The prospective GL member sends a
SignedData.PKIData.controlSequence.GLAddMembers request to the SignedData.PKIData.controlSequence.glAddMember request to the
GLA (A in Figure 5). The prospective GL member MUST include: GLA (A in Figure 5). The prospective GL member MUST include:
the GL name in glName, the member's name in the GL name in glName, their name in glMember.glMemberName,
glMembers.glMemberName, their encryption certificate in their address in glMember.glMemberAddress, and their
glMembers.certificates.membersPKC. The prospective GL member encryption certificate in glMember.certificates.membersPKC.
MAY also include the GL identifier in glIdentifier, if known, The prospective GL member MAY also include any attribute
any attribute certificates associated with their encryption certificates associated with their encryption certificate in
certificate in glMembers.certificates.membersAC, and the glMember.certificates.membersAC, and the certification path
certification path associated with their encryption and associated with their encryption and attribute certificates in
attribute certificates in glMember.certificates.certificationPath.
glMembers.certificates.certificationPath
a - The prospective GL member MAY optionally apply 1.a - The prospective GL member MAY optionally apply
confidentiality to the request by encapsulating the confidentiality to the request by encapsulating the
SignedData.PKIData in an EnvelopedData (see paragraph SignedData.PKIData in an EnvelopedData (see paragraph
3.2.1.2). 3.2.1.2).
b - The prospective GL member MAY also optionally apply another 1.b - The prospective GL member MAY also optionally apply another
SignedData over the EnvelopedData (see paragraph 3.2.1.2). SignedData over the EnvelopedData (see paragraph 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 2 in paragraph 4.3.1. per 2 in paragraph 4.3.1.
3 - Upon receipt of the forwarded request, the GLO verifies the 3 - Upon receipt of the forwarded request, the GLO verifies the
prospective GL member's signature on the inner most prospective GL member's signature on the inner most
SignedData.PKIData and the GLA's signature on the outer layer. SignedData.PKIData and the GLA's signature on the outer layer.
If an EnvelopedData encapsulates the inner most layer (see If an EnvelopedData encapsulates the inner most layer (see
paragraph 3.2.1.2 or 3.2.2), the GLO MUST decrypt the outer paragraph 3.2.1.2 or 3.2.2), the GLO MUST decrypt the outer
layer prior to verifying the signature on the inner most layer prior to verifying the signature on the inner most
SignedData. SignedData.
a - If the signature(s) does(do) not verify, the GLO MUST return 3.a - If the signature(s) does(do) not verify, the GLO MUST return
a response indicating CMCFailInfo.badMessageCheck. a cMCStatusInfo response indicating cMCStatus.failed and
otherInfo.failInfo.badMessageCheck.
b - If the signature(s) does(do) verify, the GLO MUST check to 3.b - If the signature(s) does(do) verify, the GLO MUST check to
make sure one of the names in the certificate used to sign make sure one of the names in the certificate used to sign
the request matches the name in glMembers.glMemberName. the request matches the name in glMember.glMemberName.
Turner 34 3.b.1 - If the names do not match, the GLO MAY send a
1 - If the names do not match, the GLO may send a message SignedData.PKIResponse.controlSequence message back to the
back, which is out of scope, to the prospective member,
depending on policy, to indicate that GL members can only Turner 37
add themselves lists. This stops people from adding prospective member with cMCStatusInfo.cMCStatus.failed
indicating why the prospective member was denied in
cMCStausInfo.statusString. This stops people from adding
people to GLs without their permission. people to GLs without their permission.
2 - If the names do match, the GLO determines whether the 3.b.2 - If the names do match, the GLO determines whether the
prospective member is allowed to be added. The mechanism prospective member is allowed to be added. The mechanism
is beyond the scope of this document; however, the GLO is beyond the scope of this document; however, the GLO
should check to see that the glMembers.glMemberName is not should check to see that the glMember.glMemberName is not
already on the GL. already on the GL.
a - If the GLO determines the prospective member is not 3.b.2.a - If the GLO determines the prospective member is not
allowed to join the GL, the GLO MAY return a message, allowed to join the GL, the GLO MAY return a
which is beyond the scope of this document, to indicate SignedData.PKIResponse.controlSequence message back to
why the prospective member is not allowed to join. the prospective member with
cMCStatusInfo.cMCtatus.failed indicating why the
prospective member was denied in cMCStatus.statusString.
b - If GLO determines the prospective member is allowed to 3.b.2.b - If GLO determines the prospective member is allowed to
join the GL, the GLO MUST verify the member's encryption join the GL, the GLO MUST verify the member's encryption
certificate. certificate.
1 - If the member's certificate does not verify, the GLO 3.b.2.b.1 - If the member's certificate does not verify, the GLO
MAY return a message, which is out of scope, to the MAY return a SignedData.PKIResponse.controlSequence
prospective member indicating that their encryption back to the prospective member with
certificate is not valid. cMCStatusInfo.cMCtatus.failed indicating that the
member's encryption certificate did not verify in
cMCStatus.statusString. If the GLO does not return a
cMCStatusInfo response, the GLO MUST send a
SignedData.PKIData.controlSequence.glProvideCert
message to the prospective member requesting a new
encryption certificate (see paragraph 4.10).
2 - If the member's certificate does verify, the GLO 3.b.2.b.2 - If the member's certificate does verify, the GLO
reforms GLAddMembers request (the prospective member's resubmits the glAddMember request (see paragraph
signature is discarded and the GLO applies their own 3.2.5) to the GLA (1 in Figure 5).
signature) to the GLA (1 in Figure 5) by including:
the GL name in glName, the member's name in
glMembers.glMemberName, the member's encryption
certificate in glMembers.certificates.membersPKC. The
GLO MAY also include the GL identifier in
glIdentifier, if known, any attribute certificates
associated with the member's encryption certificate in
glMembers.certificates.membersAC, and the
certification path associated with the member's
encryption and attribute certificates in
glMembers.certificates.certificationPath.
a - The GLO MUST apply confidentiality to the new 3.b.2.b.2.a - The GLO MUST apply confidentiality to the new
GLAddMember request by encapsulating the GLAddMember request by encapsulating the
SignedData.PKIData in an EnvelopedData if the SignedData.PKIData in an EnvelopedData if the
initial request was encapsulated in an EnvelopedData initial request was encapsulated in an EnvelopedData
(see paragraph 3.2.1.2). (see paragraph 3.2.1.2).
b - The GLO MAY also optionally apply another SignedData 3.b.2.b.2.b - The GLO MAY also optionally apply another SignedData
over the EnvelopedData (see paragraph 3.2.1.2). over the EnvelopedData (see paragraph 3.2.1.2).
4 - Processing continues as in 2 of paragraph 4.3.1. 4 - Processing continues as in 2 of paragraph 4.3.1.
Turner 35 Turner 38
4.4 Delete Members From GL 4.4 Delete Members From GL
To delete members from GLs, either the GLO or prospective non- To delete members from GLs, either the GLO or prospective non-
members use the GLDeleteMembers request. There are however different members use the glDeleteMember request. The GLA processes GLO and
scenarios that should be supported. Either the GLO or prospective prospective non-GL member requests differently. The GLO can submit
members may submit the GLDeleteMembers request to the GLA, but the the request at any time to delete members from the GL, and the GLA,
GLA processes the requests differently. The GLO can submit the once it has verified the request came from a registered GLO, should
request at any time to delete members from the GL, and the GLA, once delete the member. If a prospective member sends the request, the
it has verified the request came from the GLO should delete the GLA needs to determine how the GL is administered. When the GLO
member. If a prospective member sends the request, the GLA needs to initially configured the GL, they set the GL to be unmanaged,
determine how the GL is administered. When the GLO initially managed, or closed (see paragraph 3.1.1). In the unmanaged case, the
configured the GL, they set the GL to be unmanaged, managed, or GLA merely processes the member's request. For the managed case, the
closed (see paragraph 3.1.1). In the unmanaged case, the GLA merely GLA forwards the requests from the prospective members to the GLO
processes the member's request. For the managed case, the GLA for review. Where there are multiple GLOs for a GL, which GLO the
forwards the requests from the prospective members to the GLO. Where request is forwarded to is beyond the scope of this document. The
there are multiple GLOs for a GL, which GLO the request is forwarded GLO reviews the request and either rejects it or submits a reformed
to is beyond the scope of this document. In the closed case, the GLA request to the GLA. In the closed case, the GLA will not accept
will not accept requests from prospective members. The following requests from prospective members. The following paragraphs describe
paragraphs describe the processing required by the GLO, GLA, and the processing for the GLO(s), GLA, and prospective non-GL members
prospective non-GL members depending on where the request depending on where the request originated, either from a GLO or from
originated, either from the GLO or from prospective members. Figure prospective non-members. Figure 6 depicts the protocol interactions
6 depicts the protocol interactions for the three options. Note that for the three options. Note that the error messages are not
the error messages are not depicted. depicted.
+-----+ 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 be If the member is not removed from the GL, they will continue to
able to receive and decrypt data protected with the shared KEK and receive and be able to decrypt data protected with the shared KEK
will continue to receive shared KEK rekeys. For unmanaged lists, and will continue to receive rekeys. For unmanaged lists, there is
there is no point to a group rekey because there is no guarantee no point to a group rekey because there is no guarantee that the
that the member requesting to be removed has not already added member requesting to be removed has not already added themselves
themselves back on the list under a different name. For managed and back on the GL under a different name. For managed and closed GLs,
closed GLs, the GLO MUST take steps to ensure the member being the GLO MUST take steps to ensure the member being deleted is not on
deleted is not on the list twice. After ensuring this, the managed the GL twice. After ensuring this, managed and closed GLs MUST be
GL MUST be rekeyed to maintain the secrecy of the group. If the GLO rekeyed to maintain the secrecy of the group. If the GLO is sure the
is sure the member has been deleted the group rekey mechanism MAY be member has been deleted the group rekey mechanism MUST be used to
used to distribute the new key (see paragraphs 4.5 and 5). distribute the new key (see paragraphs 4.5 and 5).
Turner 36 Turner 39
4.4.1 GLO Initiated Deletions 4.4.1 GLO Initiated Deletions
The process for GLO initiated GLDeleteMembers requests is as The process for GLO initiated glDeleteMember requests is as follows:
follows:
1 - The GLO collects the names and pertinent information for the 1 - The GLO collects the pertinent information for the member(s)
members to be deleted (this MAY be done through an out of to be deleted (this MAY be done through an out of bands
bands means). The GLO then sends a means). The GLO then sends a
SignedData.PKIData.controlSequence.GLDeleteMembers request to SignedData.PKIData.controlSequence with a separate
the GLA (1 in Figure 6). The GLO MUST include: the GL name in glDeleteMember request for each member to the GLA (1 in Figure
glName and the member's name in glMembersToDelete. The GLO MAY 6). The GLO MUST include: the GL name in glName and the
omit the glIdentifier if it is unknown. If the GL from which member's name in glMemberToDelete. If the GL from which the
the member is being deleted in a closed or managed GL, the GLO member is being deleted in a closed or managed GL, the GLO
MUST also generate a GLRekey request and include it with the MUST also generate a glRekey request and include it with the
GLDeleteMember request (see paragraph 4.5). glDeletemember request (see paragraph 4.5).
a - The GLO MAY optionally apply confidentiality to the request 1.a - The GLO MAY optionally apply confidentiality to the request
by encapsulating the SignedData.PKIData in an EnvelopedData by encapsulating the SignedData.PKIData in an EnvelopedData
(see paragraph 3.2.1.2). (see paragraph 3.2.1.2).
b - The GLO MAY also optionally apply another SignedData over 1.b - The GLO MAY also optionally apply another SignedData over
the EnvelopedData (see paragraph 3.2.1.2). the EnvelopedData (see paragraph 3.2.1.2).
2 - Upon receipt of the request, the GLA verifies the signature on 2 - Upon receipt of the request, the GLA verifies the signature on
the inner most SignedData.PKIData. If an additional SignedData the inner most SignedData.PKIData. If an additional SignedData
and/or EnvelopedData encapsulates the request (see paragraph and/or EnvelopedData encapsulates the request (see paragraph
3.2.1.2 or 3.2.2), the GLA MUST verify the outer signature 3.2.1.2 or 3.2.2), the GLA MUST verify the outer signature
and/or decrypt the outer layer prior to verifying the and/or decrypt the outer layer prior to verifying the
signature on the inner most SignedData. signature on the inner most SignedData.
a - If the signature(s) does(do) not verify, the GLA MUST return 2.a - If the signature(s) does(do) not verify, the GLA MUST return
a response indicating CMCFailInfo.badMessageCheck. a cMCStatusInfo response indicating cMCStatus.failed and
otherInfo.failInfo.badMessageCheck.
b - If the signature(s) does(do) verify, the GLA MUST make sure
the GL is supported by the GLA by checking either that the
glName is supported (in the case the glIdentifier is
omitted) or that the combination of glName and glIdentifier
matches a glName and glIdentifier stored on the GLA.
1 - If the glIdentifier is omitted and the glName is not
supported by the GLA, the GLA MUST return a response
indicating GLFailInfo.errorCode.invalidGLName.
2 - If the glName and glIdentifier are present and do not 2.b - If the signature(s) does(do) verify, the GLA MUST make sure
match a GL stored on the GLA, the GLA MUST return a the GL is supported by the GLA by checking that the glName
response indicating matches a glName stored on the GLA.
GLFailInfo.errorCode.invalidGLNameGLIdentifierCombination.
3 - If the glIdentifier is omitted and the glName is supported 2.b.1 - If the glName is not supported by the GLA, the GLA MUST
by the GLA or if the glIdentifier/glName combination is return a response indicating
glFailInfo.errorCode.invalidGLName.
Turner 37 2.b.2 - If the glName is supported by the GLA, the GLA MUST check
supported by the GLA, the GLA MUST check to see if the to see if the glMemberName is present on the GL.
glMemberName is present on the GL.
a - If the glMemberName is not present on the GL, the GLA 2.b.2.a - If the glMemberName is not present on the GL, the GLA
MUST return a response indicating MUST return a response indicating
GLFailInfo.errorCode.notAMember. glFailInfo.errorCode.notAMember.
b - If the glMemberName is not already on the GL, the GLA 2.b.2.b - If the glMemberName is already on the GL, the GLA MUST
MUST check how the GL is administered. check how the GL is administered.
1 - If the GL is closed, the GLA MUST check that GLO Turner 40
signed the request by checking that one of the names 2.b.2.b.1 - If the GL is closed, the GLA MUST check that the
in the digital signature certificate used to sign the registered GLO signed the request by checking that one
request matches one of the registered GLOs. of the names in the digital signature certificate used
to sign the request matches the registered GLO.
a - If the names do not match, the GLA MUST return a 2.b.2.b.1.a - If the names do not match, the GLA MUST return a
response indicating response indicating
GLFailInfo.errorCode.noGLONameMatch. glFailInfo.errorCode.noGLONameMatch.
b - If the names do match, the GLA MUST return to all 2.b.2.b.1.b - If the names do match, the GLA MUST return a
GLOs a GLSucessInfo indicating the glName, the glSuccessInfo indicating the glName, the
corresponding glIdentifier, an corresponding glIdentifier, an
action.actionCode.deletedMember, and action.actionCode.deletedMember, and
action.glMemberName (2 in Figure 5). The response action.glMemberName (2 in Figure 5). The GLA also
MUST be constructed as in paragraph 3.2.3. The GLA takes administrative actions, which are beyond the
also takes administrative actions, which are beyond scope of this document, to delete the member with
the scope of this document, to delete the member the GL stored on the GLA. The GLA MUST also rekey
with the GL stored on the GLA. The GLA will also group as described in paragraph 5.
rekey group as described in paragraph 5.
1 - The GLA MUST apply confidentiality to the response 2.b.2.b.1.b.1 - The GLA MUST apply confidentiality to the response
by encapsulating the SignedData.PKIData in an by encapsulating the SignedData.PKIData in an
EnvelopedData if the request was encapsulated in EnvelopedData if the request was encapsulated in
an EnvelopedData (see paragraph 3.2.1.2). an EnvelopedData (see paragraph 3.2.1.2).
2 - The GLA MAY also optionally apply another 2.b.2.b.1.b.2 - The GLA MAY also optionally apply another
SignedData over the EnvelopedData (see paragraph SignedData over the EnvelopedData (see paragraph
3.2.1.2). 3.2.1.2).
2 - If the GL is managed, the GLA MUST check that either 2.b.2.b.2 - If the GL is managed, the GLA MUST check that either a
the GLO or the prospective member signed the request. registered GLO or the prospective member signed the
For the GLO, one of the names in the certificate used request. For GLOs, one of the names in the certificate
to sign the request MUST match one of the registered used to sign the request MUST match a registered GLO.
GLOs. For the prospective member, the name in For the prospective member, the name in
glMembers.glMemberName MUST match one of the names in glMember.glMemberName MUST match one of the names in
the certificate used to sign the request. the certificate used to sign the request.
a _ If the signer is neither a registered GLO or the 2.b.2.b.2.a - If the signer is neither a registered GLO nor the
prospective GL member, the GLA MUST return a prospective GL member, the GLA MUST return a
response indicating GLFailInfo.errorCode.noSpam. response indicating glFailInfo.errorCode.noSpam.
Turner 38 2.b.2.b.2.b - If the signer is a registered GLO, the GLA MUST
b - If the signer is the GLO, the GLA MUST return to all return a glSuccessInfo to the GLO indicating the
GLOs a GLSucessInfo indicating the glName, the glName, the corresponding glIdentifier, an
corresponding glIdentifier, an
action.actionCode.deletedMember, and action.actionCode.deletedMember, and
action.glMemberName (2 in Figure 6). The response action.glMemberName (2 in Figure 6). The GLA also
MUST be constructed as in paragraph 3.2.3. The GLA takes administrative actions, which are beyond the
also takes administrative actions, which are beyond scope of this document, to delete the member with
the scope of this document, to delete the member the GL stored on the GLA. The GLA will also rekey
with the GL stored on the GLA. The GLA will also group as described in paragraph 5.
rekey group as described in paragraph 5.
1 - The GLA MUST apply confidentiality to the response 2.b.2.b.2.b.1 - The GLA MUST apply confidentiality to the response
by encapsulating the SignedData.PKIData in an by encapsulating the SignedData.PKIData in an
Turner 41
EnvelopedData if the request was encapsulated in EnvelopedData if the request was encapsulated in
an EnvelopedData (see paragraph 3.2.1.2). an EnvelopedData (see paragraph 3.2.1.2).
2 - The GLA MAY also optionally apply another 2.b.2.b.2.b.2 - The GLA MAY also optionally apply another
SignedData over the EnvelopedData (see paragraph SignedData over the EnvelopedData (see paragraph
3.2.1.2). 3.2.1.2).
c - If the signer is the prospective member, the GLA 2.b.2.b.2.c - If the signer is the prospective member, the GLA
forwards the GLDeleteMembers request (see paragraph forwards the glDeleteMember request (see paragraph
3.2.3) to the GLO (B{A} in Figure 6). Which GLO the 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 request is forwarded to is beyond the scope of this
document. Further processing of the forwarded document. Further processing of the forwarded
request by the GLO is addressed in 3 of paragraph request by GLOs is addressed in 3 of paragraph
4.4.2. 4.4.2.
1 - The GLA MUST apply confidentiality to the 2.b.2.b.2.c.1 - The GLA MUST apply confidentiality to the
forwarded request by encapsulating the forwarded request by encapsulating the
SignedData.PKIData in an EnvelopedData if the SignedData.PKIData in an EnvelopedData if the
request was encapsulated in an EnvelopedData (see request was encapsulated in an EnvelopedData (see
paragraph 3.2.1.2). paragraph 3.2.1.2).
2 - The GLA MAY also optionally apply another 2.b.2.b.2.c.2 - The GLA MAY also optionally apply another
SignedData over the EnvelopedData (see paragraph SignedData over the EnvelopedData (see paragraph
3.2.1.2). 3.2.1.2).
3 - If the GL is unmanaged, the GLA MUST check that either 2.b.2.b.3 - If the GL is unmanaged, the GLA MUST check that either
the GLO or the prospective member signed the request. a registered GLO or the prospective member signed the
For the GLO, one of the names in the certificate used request. For GLOs, one of the names in the certificate
to sign the request MUST match one of the registered used to sign the request MUST match the name of a
GLOs. For the prospective member, the name in registered GLO. For the prospective member, the name
glMembers.glMemberName MUST match one of the names in in glMember.glMemberName MUST match one of the names
the certificate used to sign the request. in the certificate used to sign the request.
a - If the signer is not the GLO or the prospective 2.b.2.b.3.a - If the signer is neither the GLO nor the prospective
member, the GLA MUST return a response indicating member, the GLA MUST return a response indicating
GLFailInfo.errorCode.noSpam. glFailInfo.errorCode.noSpam.
b - If the signer is either the GLO or the member, the
GLA MUST return a GLSucessInfo indicating the
Turner 39 2.b.2.b.3.b - If the signer is either a registered GLO or the
glName, the corresponding glIdentifier, an member, the GLA MUST return a glSuccessInfo
action.actionCode.deletedMember, and indicating the glName, the corresponding
action.glMemberName to the GLO (2 in Figure 6) if glIdentifier, an action.actionCode.deletedMember,
the GLO signed the request and to the GL member (3 and action.glMemberName to the GLO (2 in Figure 6)
in Figure 6) if the GL member signed the request. if the GLO signed the request and to the GL member
The response MUST be constructed as in paragraph (3 in Figure 6) if the GL member signed the request.
3.2.3. The GLA also takes administrative actions, The GLA also takes administrative actions, which are
which are beyond the scope of this document, to beyond the scope of this document, to delete the
delete the member with the GL stored on the GLA. member with the GL stored on the GLA.
1 - The GLA MUST apply confidentiality to the response 2.b.2.b.3.b.1 - The GLA MUST apply confidentiality to the response
by encapsulating the SignedData.PKIData in an by encapsulating the SignedData.PKIData in an
EnvelopedData if the request was encapsulated in an
EnvelopedData (see paragraph 3.2.1.2).
2 - The GLA MAY also optionally apply another Turner 42
EnvelopedData if the request was encapsulated in
an EnvelopedData (see paragraph 3.2.1.2).
2.b.2.b.3.b.2 - The GLA MAY also optionally apply another
SignedData over the EnvelopedData (see paragraph SignedData over the EnvelopedData (see paragraph
3.2.1.2). 3.2.1.2).
3 - Upon receipt of the GLSuccessInfo or GLFailInfo response, the 3 - Upon receipt of the glSuccessInfo or glFailInfo response, the
GLO verifies the GLA's signatures. If an additional SignedData GLO verifies the GLA's signatures. If an additional SignedData
and/or EnvelopedData encapsulates the response (see paragraph and/or EnvelopedData encapsulates the response (see paragraph
3.2.1.2 or 3.2.2), the GLO MUST verify the outer signature 3.2.1.2 or 3.2.2), the GLO MUST verify the outer signature
and/or decrypt the outer layer prior to verifying the and/or decrypt the outer layer prior to verifying the
signature on the inner most SignedData. signature on the inner most SignedData.
a - If the signature(s) does(do) not verify, the GLO MUST return 3.a - If the signature(s) does(do) not verify, the GLO MUST return
a response indicating CMCFailInfo.badMessageCheck. a cMCStatusInfo response indicating cMCStatus.failed and
otherInfo.failInfo.badMessageCheck.
b - If the signature(s) does(do) verify, the GLO has deleted the 3.b - If the signature(s) does(do) verify and the response is
member from the GL. glSuccessInfo, the GLO has deleted the member from the GL.
If member was deleted from a managed list and the original
request was signed by the member, the GLO MUST send a
cMCStatusInfo.cMCStatus.success to the GL member.
c - If the GLO received a GLFailInfo, for any reason, the GLO 3.c - If the GLO received a glFailInfo, for any reason, the GLO
may reattempt to delete the member from the GL using the may reattempt to delete the member from the GL using the
information provided in the GLFailInfo response. information provided in the glFailInfo response.
4 - Upon receipt of the GLSuccessInfo or GLFailInfo response, the 4 - Upon receipt of the glSuccessInfo, glFailInfo, or cMCStatus
prospective member verifies the GLA's signature(s). If an response, the prospective member verifies the GLA's
additional SignedData and/or EnvelopedData encapsulates the signature(s) or GLO's signature(s). If an additional
response (see paragraph 3.2.1.2 or 3.2.2), the GLO MUST verify SignedData and/or EnvelopedData encapsulates the response (see
the outer signature and/or decrypt the outer layer prior to paragraph 3.2.1.2 or 3.2.2), the GLO MUST verify the outer
verifying the signature on the inner most SignedData. signature and/or decrypt the outer layer prior to verifying
the signature on the inner most SignedData.
a - If the signature(s) does(do) not verify, the prospective 4.a - If the signature(s) does(do) not verify, the prospective
member MUST return a response indicating member MUST return a cMCStatusInfo response indicating
CMCFailInfo.badMessageCheck. cMCStatus.failed and otherInfo.failInfo.badMessageCheck.
b - If the signature(s) does(do) verify, the prospective member 4.b - If the signature(s) does(do) verify, the prospective member
has been deleted from the GL. has been deleted from the GL.
c - If the prospective member received a GLFailInfo, for any 4.c - If the prospective member received a glFailInfo, for any
reason, the prospective member MAY reattempt to delete reason, the prospective member MAY reattempt to delete
Turner 40
themselves from the GL using the information provided in the themselves from the GL using the information provided in the
GLFailInfo response. glFailInfo response.
Turner 43
4.4.2 Member Initiated Deletions 4.4.2 Member Initiated Deletions
The process for prospective non-member initiated GLDeleteMembers The process for prospective non-member initiated glDeleteMember
requests is as follows: requests is as follows:
1 - The prospective non-GL member sends a 1 - The prospective non-GL member sends a
SignedData.PKIData.controlSequence.GLDeleteMembers request to SignedData.PKIData.controlSequence.glDeleteMember request to
the GLA (A in Figure 5). The prospective non-GL member MUST the GLA (A in Figure 6). The prospective non-GL member MUST
include: the GL name in glName and their name in include: the GL name in glName and their name in
glMembersToDelete. The prospective non-GL member MAY omit the glMemberToDelete.
glIdentifier if it is unknown.
a - The prospective non-GL member MAY optionally apply 1.a - The prospective non-GL member MAY optionally apply
confidentiality to the request by encapsulating the confidentiality to the request by encapsulating the
SignedData.PKIData in an EnvelopedData (see paragraph SignedData.PKIData in an EnvelopedData (see paragraph
3.2.1.2). 3.2.1.2).
b - The prospective non-GL member MAY also optionally apply 1.b - The prospective non-GL member MAY also optionally apply
another SignedData over the EnvelopedData (see paragraph another SignedData over the EnvelopedData (see paragraph
3.2.1.2). 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 2 in paragraph 4.4.1. per 2 in paragraph 4.4.1.
3 - Upon receipt of the forwarded request, the GLO verifies the 3 - Upon receipt of the forwarded request, the GLO verifies the
prospective GL member's signature on the inner most prospective non-member's signature on the inner most
SignedData.PKIData and the GLA's signature on the outer layer. SignedData.PKIData and the GLA's signature on the outer layer.
If an EnvelopedData encapsulates the inner most layer (see If an EnvelopedData encapsulates the inner most layer (see
paragraph 3.2.1.2 or 3.2.2), the GLO MUST decrypt the outer paragraph 3.2.1.2 or 3.2.2), the GLO MUST decrypt the outer
layer prior to verifying the signature on the inner most layer prior to verifying the signature on the inner most
SignedData. SignedData.
a - If the signature(s) does(do) not verify, the GLO MUST return 3.a - If the signature(s) does(do) not verify, the GLO MUST return
a response indicating CMCFailInfo.badMessageCheck. a cMCStatusInfo response indicating cMCStatus.failed and
otherInfo.failInfo.badMessageCheck.
b - If the signature(s) does(do) verify, the GLO MUST check to 3.b - If the signature(s) does(do) verify, the GLO MUST check to
make sure the name in one of the certificates used to sign make sure one of the names in the certificates used to sign
the request is the entity indicated in glMembersToDelete. the request matches the name in glMemberToDelete.
1 - If the names do not match, the GLO may send a message 3.b.1 - If the names do not match, the GLO MAY send a
back, which is out of scope, to the prospective member, SignedData.PKIResponse.controlSequence message back to the
depending on policy, to indicate that GL members can only prospective member with cMCStatusInfo.cMCtatus.failed
add themselves lists. This stops people from adding indicating why the prospective member was denied in
cMCStatusInfo.statusString. This stops people from adding
people to GLs without their permission. people to GLs without their permission.
2 - If the names do match, the GLO deletes the member from the 3.b.2 - If the names do match, the GLO resubmits the
GL by sending the reformed GLDeleteMembers request (the glDeleteMember request (see paragraph 3.2.5) to the GLA (1
prospective non-GL member's signature is stripped off and in Figure 6). The GLO MUST make sure the glMemberName is
already on the list and only on the list once. The GLO
Turner 41 MUST also generate a glRekey request and include it with
the GLO signs it) to the GLA (1 in Figure 6). The GLO MUST the GLDeleteMember request (see paragraph 4.5).
make sure the glMemberName is already on the list and only
on the list once. The GLO MUST also generate a GLRekey
request and include it with the GLDeleteMember request
(see paragraph 4.5).
a - The GLO MUST apply confidentiality to the new Turner 44
3.b.2.a - The GLO MUST apply confidentiality to the new
GLDeleteMember request by encapsulating the GLDeleteMember request by encapsulating the
SignedData.PKIData in an EnvelopedData if the initial SignedData.PKIData in an EnvelopedData if the initial
request was encapsulated in an EnvelopedData (see request was encapsulated in an EnvelopedData (see
paragraph 3.2.1.2). paragraph 3.2.1.2).
b - The GLO MAY also optionally apply another SignedData 3.b.2.b - The GLO MAY also optionally apply another SignedData
over the EnvelopedData (see paragraph 3.2.1.2). over the EnvelopedData (see paragraph 3.2.1.2).
4 - Further processing is as in 2 of paragraph 4.4.1. 4 - Further processing is as in 2 of paragraph 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
are as follows: are as follows:
- 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 GLDeleteMembers case, the PKIData.controlSequence containing the glDeleteMember
should contain a GLRekey request. should 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 GLDeleteMembers could PKIData.controlSequence containing the glDeleteMember could also
also contain a GLRekey request or an out of bands means could be contain a glRekey request or an out of bands means could be used
used to tell the GLA to rekey the GL. Rekeying of unmanaged GLs to tell the GLA to rekey the GL. Rekeying of unmanaged GLs when
when members are deleted is not advised. members are deleted is not advised.
- When the current shared KEK has been compromised. The GLA will - When the current shared KEK has been compromised.
automatically perform an rekey without waiting for approval from
the GLO.
- When the current shared KEK is about to expire. - When the current shared KEK is about to expire.
- 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 paragraph 5. glKey message as specified in paragraph 5.
If the generationCounter (see paragraph 3.1.1) is set to a value If the generationCounter (see paragraph 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 should request a rekey 1 duration To be on the safe side, the GLO should request a rekey one (1)
before the last shared KEK expires. duration before the last shared KEK expires.
Turner 42
The GLA and GLO are the only entities allowed to initiate a GL The GLA and GLO are the only entities allowed to initiate a GL
rekey. The GLO indicated whether they are going control rekeys or rekey. The GLO indicated whether they are going control rekeys or
whether the GLA is going to control rekeys when the assigned the whether the GLA is going to control rekeys when the assigned the
shared KEK to GL (see paragraph 3.1.1). The GLO MAY initiate a GL shared KEK to GL (see paragraph 3.1.1). The GLO MAY initiate a GL
rekey at any time. The GLA MAY be configured to automatically rekey rekey at any time. The GLA MAY be configured to automatically rekey
the GL prior to the expiration of the shared KEK (the length of time the GL prior to the expiration of the shared KEK (the length of time
Turner 45
before the expiration is an implementation decision). Figure 7 before the expiration is an implementation decision). Figure 7
depicts the protocol interactions to request a GL rekey. Note that depicts the protocol interactions to request a GL rekey. Note that
error messages are not depicted. error messages are not depicted.
+-----+ 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 MUST include the request to the GLA (1 in Figure 7). The GLO MUST include the
glName and the glIdentifier. The GLO MAY include change the glName. If glAdministration and glKeyNewAttributes are omitted
glOwner, glAdministration, glDistributionMethod, and then there is no change from the previously registered GL
glKeyAttributes. If glOwner, glAdministration, values for these fields. If the GLO wants to force a rekey for
glDistributionMethod, and glKeyAttributes are omitted then all outstanding shared KEKs the
there is no change from the previously registered GL values glNewKeyAttributes.generationCounter MUST be set to zero (0)
for these fields. If the GLO wants to force a rekey for all
outstanding shared KEKs the glKeyAttributes.generationCounter
MUST be set to zero (0)
a - The GLO MAY optionally apply confidentiality to the request 1.a - The GLO MAY optionally apply confidentiality to the request
by encapsulating the SignedData.PKIData in an EnvelopedData by encapsulating the SignedData.PKIData in an EnvelopedData
(see paragraph 3.2.1.2). (see paragraph 3.2.1.2).
b - The GLO MAY also optionally apply another SignedData over 1.b - The GLO MAY also optionally apply another SignedData over
the EnvelopedData (see paragraph 3.2.1.2). the EnvelopedData (see paragraph 3.2.1.2).
2 - Upon receipt of the request, the GLA verifies the signature on 2 - Upon receipt of the request, the GLA verifies the signature on
the inner most SignedData.PKIData. If an additional SignedData the inner most SignedData.PKIData. If an additional SignedData
and/or EnvelopedData encapsulates the request (see paragraph and/or EnvelopedData encapsulates the request (see paragraph
3.2.1.2 or 3.2.2), the GLA MUST verify the outer signature 3.2.1.2 or 3.2.2), the GLA MUST verify the outer signature
and/or decrypt the outer layer prior to verifying the and/or decrypt the outer layer prior to verifying the
signature on the inner most SignedData. signature on the inner most SignedData.
a - If the signature(s) does(do) not verify, the GLA MUST return 2.a - If the signature(s) does(do) not verify, the GLA MUST return
a response indicating CMCFailInfo.badMessageCheck. a cMCStatusInfo response indicating cMCStatus.failed and
otherInfo.failInfo.badMessageCheck.
b - If the signature(s) does(do) verify, the GLA MUST make sure 2.b - If the signature(s) does(do) verify, the GLA MUST make sure
the GL is supported by the GLA by checking that that the the GL is supported by the GLA by checking that the glName
matches a glName stored on the GLA.
Turner 43 2.b.1 - If the glName present does not match a GL stored on the
combination of glName and glIdentifier matches a glName and GLA, the GLA MUST return a response indicating
glIdentifier combination stored on the GLA. glFailInfo.errorCode.invalidGLName.
1 - If the glName and glIdentifier present do not match a GL 2.b.2 - If the glName present does match a GL stored on the GLA,
stored on the GLA, the GLA MUST return a response the GLA MUST check that a registered GLO signed the
indicating
GLFailInfo.errorCode.invalidGLNameGLIdentifierCombination.
2 - If the glName and glIdentifier present do match a GL Turner 46
stored on the GLA, the GLA MUST check that a registered request by checking that one of the names in the
GLO signed the request by checking that one of the names certificate used to sign the request is a registered GLO.
in the certificate used to sign the request is a
registered GLO.
a - If the names do not match, the GLA MUST return a 2.b.2.a - If the names do not match, the GLA MUST return a
response indicating GLFailInfo.errorCode.noGLONameMatch. response indicating glFailInfo.errorCode.noGLONameMatch.
b - If all the names do match, the GLA MUST return to all 2.b.2.b - If the names do match, the GLA MUST check the
GLOs a GLSucessInfo indicating the glName, the new glNewKeyAttribute values.
glIdentifier, and an action.actionCode.rekeyedGL (2 in
Figure 7). The GLA also uses the GLKey message to
distribute the rekey shared KEK (see paragraph 5).
1 - The GLA MUST apply confidentiality to response by 2.b.2.b.1 - If the new value for requestedAlgorithm is not
supported, the GLA MUST return a response indicating
glFailInfo.errorCode.unsupportedAlgorithm
2.b.2.b.2 - If the new value duration is not supportable,
determining this is beyond the scope this document,
the GLA MUST return a response indicating
glFailInfo.errorCode.unsupportedDuration.
2.b.2.b.3 - If the GL is not supportable for other reasons, which
the GLA does not wish to disclose, the GLA MUST return
a response indicating
glFailInfo.errorCode.unspecified.
2.b.2.b.4 - If the new requestedAlgorithm and duration are
supportable or the glNewKeyAttributes was omitted, the
GLA MUST return a glSuccessInfo to the GLO indicating
the glName, the new glIdentifier, and an
action.actionCode.rekeyedGL (2 in Figure 7). The GLA
also uses the glKey message to distribute the rekey
shared KEK (see paragraph 5).
2.b.2.b.4.a - The GLA MUST apply confidentiality to response by
encapsulating the SignedData.PKIData in an encapsulating the SignedData.PKIData in an
EnvelopedData if the request was encapsulated in an EnvelopedData if the request was encapsulated in an
EnvelopedData (see paragraph 3.2.1.2). EnvelopedData (see paragraph 3.2.1.2).
2 - The GLA MAY also optionally apply another SignedData 2.b.2.b.4.b - The GLA MAY also optionally apply another SignedData
over the EnvelopedData (see paragraph 3.2.1.2). over the EnvelopedData (see paragraph 3.2.1.2).
3 - Upon receipt of the GLSuccessInfo or GLFailInfo response, the 3 - Upon receipt of the glSuccessInfo or glFailInfo response, the
GLO verifies the GLA's signature(s). If an additional GLO verifies the GLA's signature(s). If an additional
SignedData and/or EnvelopedData encapsulates the forwarded SignedData and/or EnvelopedData encapsulates the forwarded
response (see paragraph 3.2.1.2 or 3.2.2), the GLO MUST verify response (see paragraph 3.2.1.2 or 3.2.2), the GLO MUST verify
the outer signature and/or decrypt the forwarded response the outer signature and/or decrypt the forwarded response
prior to verifying the signature on the inner most SignedData. prior to verifying the signature on the inner most SignedData.
a - If the signature(s) does(do) not verify, the GLO MUST return 3.a - If the signature(s) does(do) not verify, the GLO MUST return
a response indicating CMCFailInfo.badMessageCheck. a cMCStatusInfo response indicating cMCStatus.failed and
otherInfo.failInfo.badMessageCheck.
b - If the signatures verifies, the GLO has successfully rekeyed 3.b - If the signatures verifies and the response is
the GL. glSuccessInfo, the GLO has successfully rekeyed the GL.
c - If the GLO received a GLFailInfo, for any reason, the GLO Turner 47
3.c - If the GLO received a glFailInfo, for any reason, the GLO
may reattempt to rekey the GL using the information provided may reattempt to rekey the GL using the information provided
in the GLFailInfo response. in the glFailInfo response.
Turner 44
4.5.2 GLA Initiated Rekey Requests 4.5.2 GLA Initiated Rekey Requests
If the GLA is in charge of rekeying the GL or if a GLKCompromise If the GLA is in charge of rekeying the GL the GLA will
message has been properly processed (see paragraph 4.7) the GLA will automatically issue a glKey message (see paragraph 5). In addition
automatically issue a GLKey message (see paragraph 5). In addition the GLA will generate a glSuccessInfo to indicate to the GL that a
the GLA will generate a GLSuccessInfo to indicate to the GL that a
successful rekey has occurred. The process for GLA initiated rekey successful rekey has occurred. The process for GLA initiated rekey
is as follows: is as follows:
1 _ The GLA MUST generate for all GLOs a 1 - The GLA MUST generate for all GLOs a
SignedData.PKIData.controlSequence.GLSucessInfo indicating the SignedData.PKIData.controlSequence.glSuccessInfo indicating
glName, the new glIdentifier, and actionCode.rekeyedGL (A in the glName, the new glIdentifier, and actionCode.rekeyedGL (A
Figure 7). in Figure 7). glMemberName and glOwnerName are omitted.
a - The GLA MAY optionally apply confidentiality to the request 1.a - The GLA MAY optionally apply confidentiality to the request
by encapsulating the SignedData.PKIData in an EnvelopedData by encapsulating the SignedData.PKIData in an EnvelopedData
(see paragraph 3.2.1.2). (see paragraph 3.2.1.2).
b - The GLA MAY also optionally apply another SignedData over 1.b - The GLA MAY also optionally apply another SignedData over
the EnvelopedData (see paragraph 3.2.1.2). the EnvelopedData (see paragraph 3.2.1.2).
2 - Upon receipt of the GLSuccessInfo response, the GLO verifies 2 - Upon receipt of the glSuccessInfo response, the GLO verifies
the GLA's signature(s). If an additional SignedData and/or the GLA's signature(s). If an additional SignedData and/or
EnvelopedData encapsulates the forwarded response (see EnvelopedData encapsulates the forwarded response (see
paragraph 3.2.1.2 or 3.2.2), the GLO MUST verify the outer paragraph 3.2.1.2 or 3.2.2), the GLO MUST verify the outer
signature and/or decrypt the outer layer prior to verifying signature and/or decrypt the outer layer prior to verifying
the signature on the inner most SignedData. the signature on the inner most SignedData.
a - If the signatures do not verify, the GLO MUST return a 2.a - If the signatures do not verify, the GLO MUST return a
response indicating CMCFailInfo.badMessageCheck. cMCStatusInfo response indicating cMCStatus.failed and
otherInfo.failInfo.badMessageCheck.
b - If the signatures verifies, the GLO knows the GLA has 2.b - If the signatures verifies and the response is
successfully rekeyed the GL. glSuccessInfo, the GLO knows the GLA has successfully
rekeyed the GL.
4.6 Change GLO 4.6 Change GLO
Management of managed and closed GLs can become difficult for one Management of managed and closed GLs can become difficult for one
GLO if the GL membership grows large. To support distributing the GLO if the GL membership grows large. To support distributing the
workload, GLAs support having GL be managed by multiple GLOs. The workload, GLAs support having GLs be managed by multiple GLOs. The
GLAddOwners and GLRemoveOwners messages are designed to support glAddOwner and glRemoveOwner messages are designed to support adding
adding and removing registered GLOs. Figure depicts the protocol and removing registered GLOs. Figure 8 depicts the protocol
interactions to send GLAddOwners and GLRemoveOwners messages and the interactions to send glAddOwner and glRemoveOwner messages and the
resulting response messages. resulting response messages.
Turner 48
+-----+ 1 2 +-----+ +-----+ 1 2 +-----+
| GLA | <-------> | GLO | | GLA | <-------> | GLO |
+-----+ +-----+ +-----+ +-----+
Figure 8 _ GLO Add & Delete Owners Figure 8 - GLO Add & Delete Owners
Turner 45 The process for glAddOwner and glDeleteOwner is as follows:
The process for GLAddOwners and GLDeleteOwners is as follows:
1 - The GLO sends a SignedData.PKIData.controlSequence.GLAddOwners 1 - The GLO sends a SignedData.PKIData.controlSequence.glAddOwner
or GLRemoveOwners request to the GLA (1 in Figure 8). The GLO or glRemoveOwner request to the GLA (1 in Figure 8). The GLO
MUST include: the GL name in glName, the GLO(s) in glOwner. MUST include: the GL name in glName, the GLO's name in
The GLO MAY also include the glIdentifier. glOwnerName, and the GLO's address in glOwnerAddress.
a - The GLO MAY optionally apply confidentiality to the request 1.a - The GLO MAY optionally apply confidentiality to the request
by encapsulating the SignedData.PKIData in an EnvelopedData by encapsulating the SignedData.PKIData in an EnvelopedData
(see paragraph 3.2.1.2). (see paragraph 3.2.1.2).
b - The GLO MAY also optionally apply another SignedData over 1.b - The GLO MAY also optionally apply another SignedData over
the EnvelopedData (see paragraph 3.2.1.2). the EnvelopedData (see paragraph 3.2.1.2).
2 _ Upon receipt of the GLAddOwners or GLRemoveOwners request, the 2 - Upon receipt of the glAddOwner or glRemoveOwner request, the
GLA verifies the GLO's signature(s). If an additional GLA verifies the GLO's signature(s). If an additional
SignedData and/or EnvelopedData encapsulates the request (see SignedData and/or EnvelopedData encapsulates the request (see
paragraph 3.2.1.2 or 3.2.2), the GLA MUST verify the outer paragraph 3.2.1.2 or 3.2.2), the GLA MUST verify the outer
signature and/or decrypt the outer layer prior to verifying signature and/or decrypt the outer layer prior to verifying
the signature on the inner most SignedData. the signature on the inner most SignedData.
a - If the signature(s) does(do) not verify, the GLA MUST return 2.a - If the signature(s) does(do) not verify, the GLA MUST return
a response indicating CMCFailInfo.badMessageCheck. a cMCStatusInfo response indicating cMCStatus.failed and
otherInfo.failInfo.badMessageCheck.
b - If the signature(s) does(do) verify, the GLA MUST make sure
the GL is supported by checking either that the glName is
supported (in the case the glIdentifier is omitted) or that
the combination of glName and glIdentifier matches a glName
and glIdentifier combination stored on the GLA.
1 - If the glIdentifier is omitted and the glName is not 2.b - If the signature(s) does(do) verify, the GLA MUST make sure
supported by the GLA, the GLA MUST return a response the GL is supported by checking that the glName matches a
indicating GLFailInfo.errorCode.invalidGLName. glName stored on the GLA.
2 - If the glName and glIdentifier are present and do not 2.b.1 - If the glName is not supported by the GLA, the GLA MUST
match a GL stored on the GLA, the GLA MUST return a return a response indicating
response indicating glFailInfo.errorCode.invalidGLName.
GLFailInfo.errorCode.invalidGLNameGLIdentifierCombination.
3 - If the glIdentifier is omitted and the glName is supported 2.b.2 - If the glName is supported by the GLA, the GLA MUST ensure
by the GLA or if the glIdentifier/glName combination is a registered GLO signed the glAddOwner or glRemoveOwner
supported by the GLA, the GLA MUST ensure a registered GLO request by checking that one of the names present in the
signed the GLAddOwners or GLRemoveOwners request by digital signature certificate used to sign the glAddOwner
checking if the name present in the digital signature or glDeleteOwner request matches the name of a registered
certificate used to sign the GLDelete request matches one GLO.
of the registered GLOs.
a - If the names do not match, the GLA MUST return a 2.b.2.a - If the names do not match, the GLA MUST return a
response indicating GLFailInfo.errorCode.noGLONameMatch. response indicating glFailInfo.errorCode.noGLONameMatch.
b - If the names do match, the GLA MUST return to all GLOs a 2.b.2.b - If the names do match, the GLA MUST return a
GLSucessInfo indicating the glName, the corresponding glSuccessInfo indicating the glName, the corresponding
Turner 46 Turner 49
glIdentifier, an action.actionCode.addedGLO or glIdentifier (for glAddOwner), an
removedGLO, and the respective GLO name in glOwnerName action.actionCode.addedGLO or removedGLO, and the
(2 in Figure 4). The GLA MUST also take administrative respective GLO name in glOwnerName (2 in Figure 4). The
actions to associate the new glOwner name with the GL in GLA MUST also take administrative actions to associate
the case of GLAddOwners or to disassociate the old the new glOwnerName with the GL in the case of
glOwner name with the GL in the cased of GLRemoveOwners. glAddOwner or to disassociate the old glOwnerName with
the GL in the cased of glRemoveOwner.
1 - The GLA MUST apply confidentiality to the response by 2.b.2.b.1 - The GLA MUST apply 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 paragraph 3.2.1.2). EnvelopedData (see paragraph 3.2.1.2).
2 - The GLA MAY also optionally apply another SignedData 2.b.2.b.2 - The GLA MAY also optionally apply another SignedData
over the EnvelopedData (see paragraph 3.2.1.2). over the EnvelopedData (see paragraph 3.2.1.2).
a - The GLO MAY optionally apply confidentiality to the request 3 - Upon receipt of the glSuccessInfo or glFailInfo response, the
by encapsulating the SignedData.PKIData in an EnvelopedData GLO verifies the GLA's signature(s). If an additional
(see paragraph 3.2.1.2). SignedData and/or EnvelopedData encapsulates the response (see
paragraph 3.2.1.2 or 3.2.2), the GLO MUST verify the outer
b - The GLO MAY also optionally apply another SignedData over signature and/or decrypt the outer layer prior to verifying
the EnvelopedData (see paragraph 3.2.1.2). the signature on the inner most SignedData.
3 - Upon receipt of the GLSuccessInfo or GLFailInfo response, the
GLO verifies the GLA's signature(s). If an additional SignedData
and/or EnvelopedData encapsulates the response (see paragraph
3.2.1.2 or 3.2.2), the GLO MUST verify the outer signature
and/or decrypt the outer layer prior to verifying the signature
on the inner most SignedData.
a - If the signature(s) does(do) not verify, the GLO MUST return a 3.a - If the signature(s) does(do) not verify, the GLO MUST return
response indicating CMCFailInfo.badMessageCheck. a cMCStatusInfo response indicating cMCStatus.failed and
otherInfo.failInfo.badMessageCheck.
b - If the signatures do verify and the response was 3.b - If the signatures do verify and the response was
GLSuccessInfo, the GLO has successfully added or removed the glSuccessInfo, the GLO has successfully added or removed the
GLO. GLO.
c - If the signatures do verify and the response was GLFailInfo, 3.c - If the signatures do verify and the response was glFailInfo,
the GLO MAY reattempt to add or delete the GLO using the the GLO MAY reattempt to add or delete the GLO using the
information provided in the GLFailInfo response. information provided in the glFailInfo response.
4.7 Indicate KEK Compromise 4.7 Indicate KEK Compromise
The will be times when the shared KEK is compromised. The GL members The will be times when the shared KEK is compromised. GL members and
use the GLKCompromise message to tell the GLA that the shared KEK GLOs use glkCompromise to tell the GLA that the shared KEK has been
has been compromised. Figure 9 depicts the protocol interactions for compromised. Figure 9 depicts the protocol interactions for GL Key
GL Key Compromise. Compromise.
Turner 47 Turner 50
+-----+ 2 3 +----------+ +-----+ 2{1} 4 +----------+
| GLO | <--------+ +-------> | Member 1 | | GLO | <----------+ +-------> | Member 1 |
+-----+ | | +----------+ +-----+ 5,3{1} | | +----------+
+-----+ ---------+ | 3 +----------+ +-----+ <----------+ | 4 +----------+
| GLA | 1 +-------> | ... | | GLA | 1 +-------> | ... |
+-----+ <-------------+ +----------+ +-----+ <---------------+ +----------+
| 3 +----------+ | 4 +----------+
+-------> | Member n | +-------> | Member n |
+----------+ +----------+
Figure 9 - GL Key Compromise Figure 9 - GL Key Compromise
The process for GLKCompromise is as follows: 4.7.1 GL Member Initiated KEK Compromise Message
The process for GL member initiated glkCompromise messages is as
follows:
1 - The GL member sends a 1 - The GL member sends a
SignedData.PKIData.controlSequence.GLKCompromise request to SignedData.PKIData.controlSequence.glkCompromise request to
the GLA (1 in Figure 9). The GL member MUST include glName and the GLA (1 in Figure 9). The GL member MUST include the GL's
MAY include glIdentifier. name in GeneralName.
a - The GL member MAY optionally apply confidentiality to the 1.a - The GL member MAY optionally apply confidentiality to the
request by encapsulating the SignedData.PKIData in an request by encapsulating the SignedData.PKIData in an
EnvelopedData (see paragraph 3.2.1.2). EnvelopedData (see paragraph 3.2.1.2). The glkCompromise
MUST NOT be included in an EnvelopedData generated with the
compromised shared KEK.
b - The GL member MAY also optionally apply another SignedData 1.b - The GL member MAY also optionally apply another SignedData
over the EnvelopedData (see paragraph 3.2.1.2). over the EnvelopedData (see paragraph 3.2.1.2).
2 _ Upon receipt of the GLKCompromise requst, the GLA verifies the 2 - Upon receipt of the glkCompromise requst, the GLA verifies the
GL member's signature(s). If an additional SignedData and/or GL member's signature(s). If an additional SignedData and/or
EnvelopedData encapsulates the request (see paragraph 3.2.1.2 EnvelopedData encapsulates the request (see paragraph 3.2.1.2
or 3.2.2), the GLA MUST verify the outer signature and/or or 3.2.2), the GLA MUST verify the outer signature and/or
decrypt the outer layer prior to verifying the signature on decrypt the outer layer prior to verifying the signature on
the inner most SignedData. the inner most SignedData.
a - If the signature(s) does(do) not verify, the GLA MUST return 2.a - If the signature(s) does(do) not verify, the GLA MUST return
a response indicating CMCFailInfo.badMessageCheck. a cMCStatusInfo response indicating cMCStatus.failed and
otherInfo.failInfo.badMessageCheck.
b - If the signature(s) does(do) verify, the GLA MUST make sure 2.b - If the signature(s) does(do) verify, the GLA MUST make sure
the GL is supported by checking either that the glName is the GL is supported by checking that the indicated GL name
supported (in the case the glIdentifier is omitted) or that matches a glName stored on the GLA.
the combination of glName and glIdentifier matches a glName
and glIdentifier combination stored on the GLA.
1 - If the glIdentifier is omitted and the glName is not 2.b.1 - If the glName is not supported by the GLA, the GLA MUST
supported by the GLA, the GLA MUST return a response return a response indicating
indicating GLFailInfo.errorCode.invalidGLName. glFailInfo.errorCode.invalidGLName.
2 - If the glName and glIdentifier are present and do not 2.b.2 - If the glName is supported by the GLA, the GLA MUST check
match a GL stored on the GLA, the GLA MUST return a who signed the request. For GLOs, one of the names in the
response indicating
GLFailInfo.errorCode.invalidGLNameGLIdentifierCombination.
Turner 48 Turner 51
3 - If the glIdentifier is omitted and the glName is supported certificate used to sign the request MUST match a
by the GLA or if the glIdentifier/glName combination is registered GLO. For the prospective member, the name in
supported by the GLA, the GLA MUST ensure the GL member is glMember.glMemberName MUST match one of the names in the
on the GL. certificate used to sign the request.
a - If one of the names in the certificate used to sign the 2.b.2.a - If the GLO signed the request, the GLA MUST generate a
GLKCompromise is not present on the GL, the GLA MUST glKey message as described in paragraph 5 to rekey the
return a response indicating GL (4 in Figure 9).
GLFailInfo.errorCode.noSpam.
b - If one of the names in the certificate used to sign the 2.b.2.b - If anyone else signed the request, the GLA MUST forward
GLKCompromise is present on the GL, the GLA MUST: the glkCompromise message (see paragraph 3.2.3) to the
GLO (2{1} in Figure 9). If there is more than one GLO,
to which GLO the request is forwarded is beyond the
scope of this document. Further processing by the GLO is
discussed in paragraph 4.7.2.
1 _ Generate a PKIData.cmsSequence for all GLOs (2 in 4.7.2 GLO Initiated KEK Compromise Message
Figure 9) containing the original GLKCompromise
message and a PKIResponse.GLSuccessInfo indicating the
glName, new glIdentifier, and an action.actionCode of
rekeyedGL.
2 _ Generate a GLKey message as described in paragraph The process for GLO initiated glkCompromise messages is as follows:
5.1.2 to rekey the GL (3 in Figure 9)
1 - The GLO either:
1.a - Generates the glkCompromise message itself by sending a
SignedData.PKIData.controlSequence.glkCompromise request to
the GLA (5 in Figure 9). The GLO MUST include the name of
the GL in GeneralName.
1.a.1 - The GLO MAY optionally apply confidentiality to the
request by encapsulating the SignedData.PKIData in an
EnvelopedData (see paragraph 3.2.1.2). The glkCompromise
MUST NOT be included in an EnvelopedData generated with
the compromised shared KEK.
1.a.2 - The GLO MAY also optionally apply another SignedData over
the EnvelopedData (see paragraph 3.2.1.2).
1.b - Verifies the GLA's and GL member's signatures on the
forwarded glkCompromise message. If an additional SignedData
and/or EnvelopedData encapsulates the request (see paragraph
3.2.1.2 or 3.2.2), the GLO MUST verify the outer signature
and/or decrypt the outer layer prior to verifying the
signature on the inner most SignedData.
1.b.1 - If the signatures do not verify, the GLO MUST return a
cMCStatusInfo response indicating cMCStatus.failed and
otherInfo.failInfo.badMessageCheck.
1.b.2 - If the signatures do verify, the GLO MUST determine
whether to forward the glkCompromise message back to the
GLA (3{1} in Figure 9). Further processing by the GLA is
in 2 of paragraph 4.7.1. The GLO MAY also return a the
Turner 52
prospective member with cMCStatusInfo.cMCtatus.success
indicating that the glkCompromise message was successfully
received.
4.8 Request KEK Refresh 4.8 Request KEK Refresh
The will be times when the GL members have misplaced their shared There will be times when GL members have misplaced their shared KEK.
KEK. In this the shared KEK is not compromised and a rekey of the The shared KEK is not compromised and a rekey of the entire GL is
entire GL is not necessary. The GL members use the GLKRefresh not necessary. GL members use the glkRefresh message to request that
message to request that the shared KEK(s) be redistributed to them. the shared KEK(s) be redistributed to them. Figure 10 depicts the
Figure 10 depicts the protocol interactions for GL Key Refresh. protocol interactions for GL Key Refresh.
2 +----------+ +-----+ 1 2 +----------+
+-------> | Member 1 | | GLA | <---+-------> | Member |
| +----------+ +-----+ +----------+
+-----+ 1 | 2 +----------+
| GLA | <---+-------> | ... |
+-----+ | +----------+
| 2 +----------+
+-------> | Member n |
+----------+
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 (1 in Figure 10). The GL member MUST include glName and GLA (1 in Figure 10). The GL member MUST include name of the
MAY include glIdentifier. GL in GeneralName.
Turner 49 1.a - The GL member MAY optionally apply confidentiality to the
a - The GL member MAY optionally apply confidentiality to the
request by encapsulating the SignedData.PKIData in an request by encapsulating the SignedData.PKIData in an
EnvelopedData (see paragraph 3.2.1.2). EnvelopedData (see paragraph 3.2.1.2).
b - The GL member MAY also optionally apply another SignedData 1.b - The GL member MAY also optionally apply another SignedData
over the EnvelopedData (see paragraph 3.2.1.2). over the EnvelopedData (see paragraph 3.2.1.2).
2 _ Upon receipt of the GLKRefresh request, the GLA verifies the 2 - Upon receipt of the glkRefresh request, the GLA verifies the
GL member's signature(s). If an additional SignedData and/or GL member's signature(s). If an additional SignedData and/or
EnvelopedData encapsulates the request (see paragraph 3.2.1.2 EnvelopedData encapsulates the request (see paragraph 3.2.1.2
or 3.2.2), the GLA MUST verify the outer signature and/or or 3.2.2), the GLA MUST verify the outer signature and/or
decrypt the outer layer prior to verifying the signature on decrypt the outer layer prior to verifying the signature on
the inner most SignedData. the inner most SignedData.
a - If the signature(s) does(do) not verify, the GLA MUST return 2.a - If the signature(s) does(do) not verify, the GLA MUST return
a response indicating CMCFailInfo.badMessageCheck. a cMCStatusInfo response indicating cMCStatus.failed and
otherInfo.failInfo.badMessageCheck.
b - If the signature(s) does(do) verify, the GLA MUST make sure
the GL is supported by checking either that the glName is
supported (in the case the glIdentifier is omitted) or that
the combination of glName and glIdentifier matches a glName
and glIdentifier combination stored on the GLA.
1 - If the glIdentifier is omitted and the glName is not 2.b - If the signature(s) does(do) verify, the GLA MUST make sure
supported by the GLA, the GLA MUST return a response the GL is supported by checking that the GL's GeneralName
indicating GLFailInfo.errorCode.invalidGLName. matches a glName stored on the GLA.
2 - If the glName and glIdentifier are present and do not 2.b.1 - If the GL's name is not supported by the GLA, the GLA MUST
match a GL stored on the GLA, the GLA MUST return a return a response indicating
response indicating glFailInfo.errorCode.invalidGLName.
GLFailInfo.errorCode.invalidGLNameGLIdentifierCombination.
3 - If the glIdentifier is omitted and the glName is supported Turner 53
by the GLA or if the glIdentifier/glName combination is 2.b.2 - If the glName is supported by the GLA, the GLA MUST ensure
supported by the GLA, the GLA MUST ensure the GL member is the GL member is on the GL.
on the GL.
a - If the glMemberName is not present on the GL, the GLA 2.b.2.a - If the glMemberName is not present on the GL, the GLA
MUST return a response indicating MUST return a response indicating
GLFailInfo.errorCode.noSpam. glFailInfo.errorCode.noSpam.
b - If the glMemberName is present on the GL, the GLA MUST 2.b.2.b - If the glMemberName is present on the GL, the GLA MUST
return a GLKey message (2 in Figure 10) as described in return a glKey message (2 in Figure 10) as described in
paragraph 5.1.3. paragraph 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 There will be certain times when a GLO is having trouble setting up
a GLO because they do not know the algorithm(s) or distribution a GLO because they do not know the algorithm(s) or some other
method(s) the GLA supports. The GLAQueryRequest and GLAQueryResponse characteristic that the GLA supports. There may also be times when
message have been defined to support the GLO determining this the prospective GL members or GL members need to know something
about the GLA (these requests are not defined in the document). The
Turner 50 glaQueryRequest and glaQueryResponse message have been defined to
information. Figure 11 depicts the protocol interactions for support determining this information. Figure 11 depicts the protocol
GLAQueryRequest and GLAQueryResponse. interactions for glaQueryRequest and glaQueryResponse.
+-----+ 1 2 +-----+ +-----+ 1 2 +------------------+
| GLA | <-------> | GLO | | GLA | <-------> | GLO or GL Member |
+-----+ +-----+ +-----+ +------------------+
Figure 11 - GLA Query Request & Response Figure 11 - GLA Query Request & Response
The process for GLAQueryRequest and GLAQueryResponse is as follows: The process for glaQueryRequest and glaQueryResponse is as follows:
1 - The GLO 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 GLA (1 in Figure 11). The GLO indicates whether they are the GLA (1 in Figure 11). The GLO, GL member, or prospective
interested in determining what algorithms the GLA supports or GL member indicates the information they are interested in
what distributionMethods the GLA support or both. receiving from the GLA.
a - The GLO MAY optionally apply confidentiality to the request 1.a - The GLO, GL member, or prospective GL member MAY optionally
by encapsulating the SignedData.PKIData in an EnvelopedData apply confidentiality to the request by encapsulating the
(see paragraph 3.2.1.2). SignedData.PKIData in an EnvelopedData (see paragraph
3.2.1.2).
b - The GLO MAY also optionally apply another SignedData over 1.b - The GLO, GL member, or prospective GL member MAY also
the EnvelopedData (see paragraph 3.2.1.2). optionally apply another SignedData over the EnvelopedData
(see paragraph 3.2.1.2).
2 _ Upon receipt of the GLQueryRequest, the GLA determines if it 2 - Upon receipt of the glaQueryRequest, the GLA determines if it
accepts GLAQueryRequests. accepts glaQueryRequest messages.
a - If the GLA does not accept GLAQueryRequests, the GLA MUST Turner 54
return a response indicating GLFailInfo.unspecified. 2.a - If the GLA does not accept glaQueryRequest messages, the GLA
MUST return a cMCStatusInfo response indicating
cMCStatus.noSupport and any other information in
statusString.
b - If the GLA does accept GLAQueryReuests, the GLA MUST verify 2.b - If the GLA does accept GLAQueryReuests, the GLA MUST verify
the GLO's signature(s). If an additional SignedData and/or the GLO's, GL member's, or prospective GL member's
signature(s). If an additional SignedData and/or
EnvelopedData encapsulates the request (see paragraph EnvelopedData encapsulates the request (see paragraph
3.2.1.2 or 3.2.2), the GLA MUST verify the outer signature 3.2.1.2 or 3.2.2), the GLA MUST verify the outer signature
and/or decrypt the outer layer prior to verifying the and/or decrypt the outer layer prior to verifying the
signature on the inner most SignedData. signature on the inner most SignedData.
1 - If the signature(s) does(do) not verify, the GLA MUST 2.b.1 - If the signature(s) does(do) not verify, the GLA MUST
return a response indicating CMCFailInfo.badMessageCheck. return a cMCStatusInfo response indicating
cMCStatus.failed and otherInfo.failInfo.badMessageCheck.
2 - If the signature(s) does(do) verify, the GLA MUST return a 2.b.2 - If the signature(s) does(do) verify, the GLA MUST return a
GLAQueryResponse (2 in Figure 11) indicating the glaQueryResponse (2 in Figure 11) indicating the the
supportedAlgorithms, the distributionMethod, or both. requested information if the glaRequestType is supported
or return a cMCStatusInfo response indicating
cMCStatus.noSupport if the glaRequestType is not
supported.
a - The GLA MUST apply confidentiality to the response by 2.b.2.a - The GLA MUST apply 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 paragraph 3.2.1.2). EnvelopedData (see paragraph 3.2.1.2).
b - The GLA MAY also optionally apply another SignedData 2.b.2.b - The GLA MAY also optionally apply another SignedData
over the EnvelopedData (see paragraph 3.2.1.2). over the EnvelopedData (see paragraph 3.2.1.2).
Turner 51 3 - Upon receipt of the glaQueryResponse, the GLO, GL member, or
3 - Upon receipt of the GLAQueryResponse, the GLO verifies the prospective GL member verifies the GLA's signature(s). If an
GLA's signature(s). If an additional SignedData and/or additional SignedData and/or EnvelopedData encapsulates the
response (see paragraph 3.2.1.2 or 3.2.2), the GLO, GL member,
or prospective GL member MUST verify the outer signature
and/or decrypt the outer layer prior to verifying the
signature on the inner most SignedData.
3.a - If the signature(s) does(do) not verify, the GLO, GL member,
or prospective GL member MUST return a cMCStatusInfo
response indicating cMCStatus.failed and
otherInfo.failInfo.badMessageCheck.
3.b - If the signatures do verify and the response was
glaQueryResponse, the GLO, GL member, or prospective GL
member may use the information contained therein.
Turner 55
4.10 Update Member Certificate
When the GLO generates a glAddMember request, when the GLA generates
a glKey message, or when the GLA processes a glAddMember there may
be instances when GL member's certificate has expired or is invalid.
In these instances the GLO or GLA may request that the GL member
provide a new certificate to avoid the GLA from being unable to
generate a glKey message for the GL member. There may also be times
when the GL member knows their certificate is about to expire or has
been revoked and they will not be able to receive GL rekeys.
4.10.1 GLO and GLA Initiated Update Member Certificate
The process for GLO initiated glUpdateCert is as follows:
1 - The GLO or GLA sends a
SignedData.PKIData.controlSequence.glProvideCert request to
the GL member. The GLO or GLA indicates the GL name in glName
and the GL member's name in glMemberName.
1.a - The GLO or GLA MAY optionally apply confidentiality to the
request by encapsulating the SignedData.PKIData in an
EnvelopedData (see paragraph 3.2.1.2). If the GL member's
PKC has been revoked, the GLO or GLA MUST NOT use it to
generate the EnvelopedData that encapsulates the
glProvideCert request.
1.b - The GLO or GLA MAY also optionally apply another SignedData
over the EnvelopedData (see paragraph 3.2.1.2).
2 - Upon receipt of the glProvideCert message, the GL member
verifies the GLO's or GLA's signature(s). If an additional
SignedData and/or EnvelopedData encapsulates the response (see
paragraph 3.2.1.2 or 3.2.2), the GL member MUST verify the
outer signature and/or decrypt the outer layer prior to
verifying the signature on the inner most SignedData.
2.a - If the signature(s) does(do) not verify, the GL member MUST
return a cMCStatusInfo response indicating cMCStatus.failed
and otherInfo.failInfo.badMessageCheck.
2.b - If the signature(s) does(do) verify, the GL member generates
a Signed.PKIResponse.controlSequence.glUpdateCert that MUST
include the GL name in glName, the member's name in
glMember.glMemberName, their encryption certificate in
glMember.certificates.membersPKC. The GL member MAY also
include any attribute certificates associated with their
encryption certificate in glMember.certificates.membersAC,
and the certification path associated with their encryption
and attribute certificates in
glMember.certificates.certificationPath.
Turner 56
2.a - The GL member MAY optionally apply confidentiality to the
request by encapsulating the SignedData.PKIResponse in an
EnvelopedData (see paragraph 3.2.1.2). If the GL member's
PKC has been revoked, the GL member MUST NOT use it to
generate the EnvelopedData that encapsulates the
glProvideCert request.
2.b - The GL member MAY also optionally apply another SignedData
over the EnvelopedData (see paragraph 3.2.1.2).
3 - Upon receipt of the glUpdateCert message, the GLO or GLA
verifies the GL member's signature(s). If an additional
SignedData and/or EnvelopedData encapsulates the response (see
paragraph 3.2.1.2 or 3.2.2), the GL member MUST verify the
outer signature and/or decrypt the outer layer prior to
verifying the signature on the inner most SignedData.
3.a - If the signature(s) does(do) not verify, the GLO or GLA MUST
return a cMCStatusInfo response indicating cMCStatus.failed
and otherInfo.failInfo.badMessageCheck.
3.b - If the signature(s) does(do) verify, the GLO or GLA MUST
verify the member's encryption certificate.
3.b.1 - If the member's encryption certificate does not verify,
the GLO MAY return either another glProvideCert request or
a cMCStatusInfo with cMCStatus.failed and the reason why
in cMCStatus.statusString. glProvideCert should be
returned only a certain number of times because if the GL
member does not have a valid certificate they will never
be able to return one.
3.b.2 - If the member's encryption certificate does not verify,
the GLA MAY return another glProvideCert request to the GL
member or a cMCStatusInfo with cMCStatus.failed and the
reason why in cMCStatus.statusString to the GLO.
glProvideCert should be returned only a certain number of
times because if the GL member does not have a valid
certificate they will never be able to return one.
3.b.3 - If the member's encryption certificate does verify, the
GLO or GLA will use it in subsequent glAddMember requests
and glKey messages associated with the GL member.
4.10.2 GL Member Initiated Update Member Certificate
The process for an unsolicited GL member glUpdateCert is as follows:
1 - The GL member sends a
Signed.PKIData.controlSequence.glUpdateCert that MUST include
the GL name in glName, the member's name in
Turner 57
glMember.glMemberName, their encryption certificate in
glMember.certificates.membersPKC. The GL member MAY also
include any attribute certificates associated with their
encryption certificate in glMember.certificates.membersAC, and
the certification path associated with their encryption and
attribute certificates in
glMember.certificates.certificationPath.
1.a - The GL member MAY optionally apply confidentiality to the
request by encapsulating the SignedData.PKIData in an
EnvelopedData (see paragraph 3.2.1.2). If the GL member's
PKC has been revoked, the GLO or GLA MUST NOT use it to
generate the EnvelopedData that encapsulates the
glProvideCert request.
1.b - The GL member MAY also optionally apply another SignedData
over the EnvelopedData (see paragraph 3.2.1.2).
2 - Upon receipt of the glUpdateCert message, the GLA verifies the
GL member's signature(s). If an additional SignedData and/or
EnvelopedData encapsulates the response (see paragraph 3.2.1.2 EnvelopedData encapsulates the response (see paragraph 3.2.1.2
or 3.2.2), the GLO MUST verify the outer signature and/or or 3.2.2), the GLA MUST verify the outer signature and/or
decrypt the outer layer prior to verifying the signature on decrypt the outer layer prior to verifying the signature on
the inner most SignedData. the inner most SignedData.
a - If the signature(s) does(do) not verify, the GLO MUST return 2.a - If the signature(s) does(do) not verify, the GLA MUST return
a response indicating CMCFailInfo.badMessageCheck. a cMCStatusInfo response indicating cMCStatus.failed and
otherInfo.failInfo.badMessageCheck.
b - If the signatures do verify and the response was 2.b - If the signature(s) does(do) verify, the GLA MUST verify the
GLAQueryResponse, the GLO may use the information contained member's encryption certificate.
therein to attempt to setup a GL or modify an existing GL.
2.b.1 - If the member's encryption certificate does not verify,
the GLA MAY return another glProvideCert request to the GL
member or a cMCStatusInfo with cMCStatus.failed and the
reason why in cMCStatus.statusString to the GLO.
glProvideCert should be returned only a certain number of
times because if the GL member does not have a valid
certificate they will never be able to return one.
2.b.2 - If the member's encryption certificate does verify, the
GLA will use it in subsequent glAddMember requests and
glKey messages associated with the GL member. The GLA MUST
also forward the glUpdateCert message to the GLO.
5 Distribution Message 5 Distribution Message
The GLA uses the GLKey message to distribute new, shared KEK(s) The GLA uses the glKey message to distribute new, shared KEK(s)
after receiving GLAddMembers, GLDeleteMembers (for closed and after receiving glAddMember, glDeleteMember (for closed and managed
managed GLs), GLRekey, GLKCompromise, or GLKRefresh requests and GLs), glRekey, glkCompromise, or glkRefresh requests and returning a
returning a GLSucessInfo response for the respective request. Figure glSuccessInfo response for the respective request. Figure 12 depicts
12 depicts the protocol interactions to send out GLKey messages. The
procedures defined in this paragraph MUST be implemented. Turner 58
the protocol interactions to send out glKey messages. The procedures
defined in this paragraph MUST be implemented.
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.recipientsMutuallyAware set If the GL was setup with GLKeyAttributes.recipientsMutuallyAware set
to FALSE, a separate GLKey message MUST be sent to each GL member so to FALSE, a separate glKey message MUST be sent to each GL member so
as to not divulge information about the other GL members. as to not 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:
- GLAddMembers request,
- GLKComrpomise indicate, - glAddMember request,
- GLKRefresh request, - glkComrpomise indication,
- GLDeleteMembers request with the the GL's glAdministration set - glkRefresh request,
to managed or closed, - glDeleteMember request with the the GL's glAdministration set to
- GLKRekey request with generationCounter set to zero (0) managed or closed,
- glRekey request with generationCounter set to zero (0)
The GLA MUST use either the kari (see paragraph 12.3.2 of CMS [2]) The GLA MUST use either the kari (see paragraph 12.3.2 of CMS [2])
or ktri (see paragraph 12.3.1 of CMS [2]) choice in or ktri (see paragraph 12.3.1 of CMS [2]) choice in
GLKey.glkWrapped.RecipientInfo to ensure only the intended glKey.glkWrapped.RecipientInfo to ensure only the intended
recipients receive the shared KEK. The GLA MUST support the kari
Turner 52 choice.
recipients receive the shared KEK. The GLA MUST support the
RecipientInfo.kari 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 with generationCounter greater than zero (0) or when the GLA
controls rekeys, the GLA MAY use the kari, ktri, or kekri (see controls rekeys, the GLA MAY use the kari, ktri, or kekri (see
paragraph 12.3.3 of CMS [2]) in GLKey.glkWrapped.RecipientInfo to paragraph 12.3.3 of CMS [2]) in glKey.glkWrapped.RecipientInfo to
ensure only the intended recipients receive the shared KEK. The GLA ensure only the intended recipients receive the shared KEK. The GLA
MUST support the RecipientInfo.kari choice. MUST support the RecipientInfo.kari 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 1 - The GLA MUST send a SignedData.PKIData.controlSequence.glKey
to each member by including: glName, glIdentifier, glkWrapped, to each member by including: glName, glIdentifier, glkWrapped,
glkAlgorithm, glkNotBefore, and glkNotAfter. glkAlgorithm, glkNotBefore, and glkNotAfter. If the GLA can
not generate a glKey message for the GL member because the GL
member's PKC has expired or is invalid, the GLA MAY send a
**Need to be more detailed on how the values are derived as it Turner 59
depends on why and when the GLKey message is generated** glUpdateCert to the GL member requesting a new certificate be
provided (see paragraph 4.10). The number of glKey messages
generated for the GL is described in paragraph 3.1.16.
a - The GLA MAY optionally apply another confidentiality layer 1.a - The GLA MAY optionally apply another confidentiality layer
to the message by encapsulating the SignedData.PKIData in to the message by encapsulating the SignedData.PKIData in
another EnvelopedData (see paragraph 3.2.1.2). another EnvelopedData (see paragraph 3.2.1.2).
b - The GLA MAY also optionally apply another SignedData over 1.b - The GLA MAY also optionally apply another SignedData over
the EnvelopedData.SignedData.PKIData (see paragraph the EnvelopedData.SignedData.PKIData (see paragraph
3.2.1.2). 3.2.1.2).
2 - Upon receipt of the message, the GL members MUST verify the 2 - Upon receipt of the message, the GL members MUST verify the
signature over the inner most SignedData.PKIData. If an signature over the inner most SignedData.PKIData. If an
additional SignedData and/or EnvelopedData encapsulates the additional SignedData and/or EnvelopedData encapsulates the
message (see paragraph 3.2.1.2 or 3.2.2), the GL Member MUST message (see paragraph 3.2.1.2 or 3.2.2), the GL Member MUST
verify the outer signature and/or decrypt the outer layer verify the outer signature and/or decrypt the outer layer
prior to verifying the signature on the prior to verifying the signature on the
SignedData.PKIData.controlSequence.GLKey. SignedData.PKIData.controlSequence.glKey.
a - If the signature(s) does(do) not verify, the GL member MUST 2.a - If the signature(s) does(do) not verify, the GL member MUST
return a response indicating CMCFailInfo.badMessageCheck. return a cMCStatusInfo response indicating cMCStatus.failed
and otherInfo.failInfo.badMessageCheck.
b - If the signature(s) does(do) verify, the GL member process 2.b - If the signature(s) does(do) verify, the GL member process
the RecipientInfos according to CMS [2]. Once unwrapped the the RecipientInfos according to CMS [2]. Once unwrapped the
GL member should store the shared KEK in a safe place. When GL 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. associated.
6 Key Wrapping 6 Algorithms
In the mechanisms described in paragraphs 5, the group key being This section lists the algorithms that must be implemented.
distributed, in an EnvelopedData, MUST be protected by a key of Additional algorithms that should be implemented are also included.
equal or greater length (i.e., if a RC2 128-bit key is being
Turner 53 6.1 KEK Generation Algorithm
distributed a key of 128-bits or greater must be used to protect the
key).
7 Algorithms The shared KEK MUST be generated according to the security
considerations paragraph in CMS [2].
Triple-DES is mandatory other are optional. 6.2 Shared KEK Wrap Algorithm
8 Transport In the mechanisms described in paragraphs 5, the shared KEK being
distributed in glkWrapped MUST be protected by a key of equal or
greater length (i.e., if a RC2 128-bit key is being distributed a
key of 128-bits or greater must be used to protect the key).
SMTP must be supported. The algorithm object identifiers included in glkWrapped are as
specified in 12.3 of CMS [2].
9 Using the Group Key Turner 60
[Put in here how this can be used with SMIME MLAs.] 6.3 Shared KEK Algorithm
10 Schema Requirements The shared KEK distributed and indicated in glkAlgorithm MUST
support the symmetric key-encryption algorithms as specified in
paragraph 12.3.3 of CMS [2]
[I think we need to specify some MAYs for support of object classes, 7 Transport
etc. to support location of the GL and GLO in a repository. There
are really two choices for the GL mhsDistributionList from RFC 1274
and addresslist from an Internet-Draft in the LDAPEXT WG. The only
reason I can think of not using the one from RFC 1274 is that a MUST
CONTAIN is mhsORAddress and we're should support SMTP. addressList
(in the ID) doesn't have mhsORAddress as a must contain. The Owner
in the both object classes though has the syntax directoryName. We
might have to roll attribute for the Owner because I think it should
probably have the GeneralName syntax instead of just directoryName.]
[We can also define attributes that can be used to store the group SMTP [7] MUST be supported. All other transport mechanisms MAY be
key encrypted for an individual group member and for the encrypted supported.
object. Does anyone think this is useful/needed?]
11 Security Considerations 8 Using the Group Key
TBSL
9 Security Considerations
Don't have too many GLOs because they could start willie nillie Don't have too many GLOs because they could start willie nillie
adding people you don't like. adding people you don't like.
Need to rekey closed and managed GLs if a member is deleted. Need to rekey closed and managed GLs if a member is deleted.
GL members have to store some kind of information about who GL members have to store some kind of information about who
distributed the shared KEK to them so that they can make sure distributed the shared KEK to them so that they can make sure
subsequent rekeys are originated from the same entity. subsequent rekeys are originated from the same entity.
Need to make sure you don't make the key size too small and duration Need to make sure you don't make the key size too small and duration
long because people will have more time to attack the key. long because people will have more time to attack the key.
Need to make sure you don't make the generationCounter to large Need to make sure you don't make the generationCounter to large
because then people can attack the last key. because then people can attack the last key. If there are 14 keys
outstanding each with a year's duration attackers might be able
Turner 54 determine the 14th key.
12 References 10 References
1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP
9, RFC 2026, October 1996. 9, RFC 2026, October 1996.
2 Housley, R., "Cryptographic Message Syntax," RFC 2630, June 1999. 2 Housley, R., "Cryptographic Message Syntax," RFC 2630, June 1999.
3 Myers, M., Liu, X., Schadd, J., Weinsten, J., "Certificate 3 Myers, M., Liu, X., Schadd, J., Weinsten, J., "Certificate
Management Message over CMS," draft-ietf-pkix-cmc-05.txt, July Management Message over CMS," draft-ietf-pkix-cmc-05.txt, July
1999. 1999.
Turner 61
4 Bradner, S., "Key words for use in RFCs to Indicate Requirement 4 Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
5 Housley, R., Ford, W., Polk, W. and D. Solo, "Internet X.509 5 Ramsdale, B., "S/MIME Version 3 Message Specification," RFC 2633,
June 1999.
6 Housley, R., Ford, W., Polk, W. and D. Solo, "Internet X.509
Public Key Infrastructure: Certificate and CRL Profile", RFC Public Key Infrastructure: Certificate and CRL Profile", RFC
2459, January 1999. 2459, January 1999.
13 Acknowledgements 7 Postel, j., "Simple Mail Transport Protocol," RFC 821, August
1982.
11 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 draft. background and review required to write this draft.
14 Author's Addresses 12 Author's Addresses
Sean Turner Sean Turner
IECA, Inc. IECA, Inc.
9010 Edgepark Road 9010 Edgepark Road
Vienna, VA 22182 Vienna, VA 22182
Phone: +1.703.628.3180 Phone: +1.703.628.3180
Email: turners@ieca.com Email: turners@ieca.com
Expires January 14, 2001 Expires April 2001
Turner 55 Turner 62
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/