draft-ietf-smime-symkeydist-04.txt   draft-ietf-smime-symkeydist-05.txt 
SMIME Working Group S. Turner SMIME Working Group S. Turner
Internet Draft IECA Internet Draft IECA
Document: draft-ietf-smime-symkeydist-04.txt April 30, 2001 Document: draft-ietf-smime-symkeydist-05.txt July 2001
Expires: October 30, 2001 Expires: December 20, 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 60 skipping to change at line 60
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 this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 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
1.3 USING THE GROUP KEY............................................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...................................................8 3.1.1 GL USE KEK...................................................9
3.1.2 DELETE GL...................................................12 3.1.2 DELETE GL...................................................12
3.1.3 ADD GL MEMBER...............................................12 3.1.3 ADD GL MEMBER...............................................12
3.1.4 DELETE GL MEMBER............................................13 3.1.4 DELETE GL MEMBER............................................14
3.1.5 REKEY GL....................................................14 3.1.5 REKEY GL....................................................14
3.1.6 ADD GL OWNER................................................15 3.1.6 ADD GL OWNER................................................15
3.1.7 REMOVE GL OWNER.............................................15 3.1.7 REMOVE GL OWNER.............................................15
3.1.8 GL KEY COMPROMISE...........................................15 3.1.8 GL KEY COMPROMISE...........................................16
3.1.9 GL KEY REFRESH..............................................16 3.1.9 GL KEY REFRESH..............................................16
3.1.10 GLA QUERY REQUEST AND RESPONSE.............................16 3.1.10 GLA QUERY REQUEST AND RESPONSE.............................17
3.1.10.1 GLA QUERY REQUEST........................................16 3.1.10.1 GLA QUERY REQUEST........................................17
3.1.10.2 GLA QUERY RESPONSE.......................................17 3.1.10.2 GLA QUERY RESPONSE.......................................17
3.1.10.3 REQUEST AND RESPONSE TYPES...............................17 3.1.10.3 REQUEST AND RESPONSE TYPES...............................17
3.1.12 PROVIDE CERT...............................................17 3.1.12 PROVIDE CERT...............................................18
3.1.13 UPDATE CERT................................................18 3.1.13 UPDATE CERT................................................18
3.1.14 GL KEY.....................................................19 3.1.14 GL KEY.....................................................19
3.2 USE OF CMC, CMS, AND PKIX.....................................21 3.2 USE OF CMC, CMS, AND PKIX.....................................21
3.2.1 PROTECTION LAYERS...........................................21 3.2.1 PROTECTION LAYERS...........................................21
3.2.1.1 MINIMUM PROTECTION........................................21 3.2.1.1 MINIMUM PROTECTION........................................22
3.2.1.2 ADDITIONAL PROTECTION.....................................21 3.2.1.2 ADDITIONAL PROTECTION.....................................22
3.2.2 COMBINING REQUESTS AND RESPONSES............................22 3.2.2 COMBINING REQUESTS AND RESPONSES............................23
3.2.3 GLA GENERATED MESSAGES......................................23 3.2.3 GLA GENERATED MESSAGES......................................24
3.2.4 CMC CONTROL ATTRIBUTES......................................24 3.2.4 CMC CONTROL ATTRIBUTES......................................25
3.2.4.1 USING CMCSTATUSINFOEX.....................................24 3.2.4.1 USING CMCSTATUSINFOEX.....................................25
3.2.4.2 USING TRANSACTIONID.......................................27 3.2.4.2 USING TRANSACTIONID.......................................28
3.2.4.3 USING NONCES..............................................27 3.2.4.3 USING NONCES..............................................28
3.2.4.4 CMC ATTRIBUTE SUPPORT REQUIREMENTS........................27 3.2.4.4 CMC ATTRIBUTE SUPPORT REQUIREMENTS........................28
3.2.5 RESUBMITTED GL MEMBER MESSAGES..............................28 3.2.5 RESUBMITTED GL MEMBER MESSAGES..............................29
3.2.6 PKIX........................................................28 3.2.6 PKIX CERTIFICATE AND CRL PROFILE............................29
4 ADMINISTRATIVE MESSAGES.........................................28 4 ADMINISTRATIVE MESSAGES.........................................29
4.1 ASSIGN KEK TO GL..............................................28 4.1 ASSIGN KEK TO GL..............................................29
4.2 DELETE GL FROM GLA............................................31 4.2 DELETE GL FROM GLA............................................32
4.3 ADD MEMBERS TO GL.............................................33 4.3 ADD MEMBERS TO GL.............................................34
4.3.1 GLO INITIATED ADDITIONS.....................................34 4.3.1 GLO INITIATED ADDITIONS.....................................35
4.3.2 PROSPECTIVE MEMBER INITIATED ADDITIONS......................40 4.3.2 PROSPECTIVE MEMBER INITIATED ADDITIONS......................41
4.4 DELETE MEMBERS FROM GL........................................42 4.4 DELETE MEMBERS FROM GL........................................43
4.4.1 GLO INITIATED DELETIONS.....................................43 4.4.1 GLO INITIATED DELETIONS.....................................44
4.4.2 MEMBER INITIATED DELETIONS..................................47 4.4.2 MEMBER INITIATED DELETIONS..................................48
4.5 REQUEST REKEY OF GL...........................................48 4.5 REQUEST REKEY OF GL...........................................49
4.5.1 GLO INITIATED REKEY REQUESTS................................49
4.5.2 GLA INITIATED REKEY REQUESTS................................52
Turner 2 Turner 2
4.6 CHANGE GLO....................................................52 4.5.1 GLO INITIATED REKEY REQUESTS................................50
4.5.2 GLA INITIATED REKEY REQUESTS................................53
4.6 CHANGE GLO....................................................53
4.7 INDICATE KEK COMPROMISE.......................................55 4.7 INDICATE KEK COMPROMISE.......................................55
4.7.1 GL MEMBER INITIATED KEK COMPROMISE MESSAGE..................55 4.7.1 GL MEMBER INITIATED KEK COMPROMISE MESSAGE..................56
4.7.2 GLO INITIATED KEK COMPROMISE MESSAGE........................56 4.7.2 GLO INITIATED KEK COMPROMISE MESSAGE........................57
4.8 REQUEST KEK REFRESH...........................................57 4.8 REQUEST KEK REFRESH...........................................58
4.9 GLA QUERY REQUEST AND RESPONSE................................58 4.9 GLA QUERY REQUEST AND RESPONSE................................59
4.10 UPDATE MEMBER CERTIFICATE....................................60 4.10 UPDATE MEMBER CERTIFICATE....................................61
4.10.1 GLO AND GLA INITIATED UPDATE MEMBER CERTIFICATE............60 4.10.1 GLO AND GLA INITIATED UPDATE MEMBER CERTIFICATE............61
4.10.2 GL MEMBER INITIATED UPDATE MEMBER CERTIFICATE..............62 4.10.2 GL MEMBER INITIATED UPDATE MEMBER CERTIFICATE..............63
5 DISTRIBUTION MESSAGE............................................63 5 DISTRIBUTION MESSAGE............................................64
5.1 DISTRIBUTION PROCESS..........................................64 5.1 DISTRIBUTION PROCESS..........................................65
6 ALGORITHMS......................................................65 6 ALGORITHMS......................................................66
6.1 KEK GENERATION ALGORITHM......................................65 6.1 KEK GENERATION ALGORITHM......................................66
6.2 SHARED KEK WRAP ALGORITHM.....................................65 6.2 SHARED KEK WRAP ALGORITHM.....................................66
6.3 SHARED KEK ALGORITHM..........................................65 6.3 SHARED KEK ALGORITHM..........................................66
7 TRANSPORT.......................................................65 7 MESSAGE TRANSPORT...............................................67
8 USING THE GROUP KEY.............................................65 8 SECURITY CONSIDERATIONS.........................................67
9 SECURITY CONSIDERATIONS.........................................66 9 REFERENCES......................................................67
10 REFERENCES.....................................................66 10 ACKNOWLEDGEMENTS...............................................68
11 ACKNOWLEDGEMENTS...............................................67 11 AUTHOR'S ADDRESSES.............................................69
12 AUTHOR'S ADDRESSES.............................................67 ANNEX A: ASN.1 MODULE.............................................70
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.
With asymmetric algorithms, the originator forms an originator- With asymmetric algorithms, the originator forms an originator-
determined content-encryption key (CEK) and encrypts the content, determined content-encryption key (CEK) and encrypts the content,
using a symmetric algorithm. Then, using an asymmetric algorithm and using a symmetric algorithm. Then, using an asymmetric algorithm and
the recipient's PKCs, the originator generates per-recipient the recipient's PKCs, the originator generates per-recipient
information that either (a) encrypts the CEK for a particular information that either (a) encrypts the CEK for a particular
recipient (ktri ReipientInfo CHOICE), or (b) transfers sufficient recipient (ktri ReipientInfo CHOICE), or (b) transfers sufficient
parameters to enable a particular recipient to independently parameters to enable a particular recipient to independently
generate the same KEK (kari RecipientInfo CHOICE). If the group is generate the same KEK (kari RecipientInfo CHOICE). If the group is
large, the amount of per-recipient information required may take large, processing of the per-recipient information may take quite
quite some time to generate, not to mention the time required to some time, not to mention the time required to collect and validate
collect and validate the PKCs for each of the recipients. Each the PKCs for each of the recipients. Each recipient identifies their
recipient identifies their per-recipient information and uses the per-recipient information and uses the private key associated with
private key associated with the public key of their PKC to decrypt the public key of their PKC to decrypt the CEK and hence gain access
the CEK and hence gain access to the encrypted content. to the encrypted content.
With symmetric algorithms, the origination process is the same as With symmetric algorithms, the origination process is slightly
with asymmetric algorithms except for what encrypts the CEK. Instead different. Instead of using PKCs, the originator uses a previously
of using PKCs, the originator uses a previously distributed secret distributed secret key-encryption key (KEK) to encrypt the CEK
key-encryption key (KEK) to encrypt the CEK (kekri RecipientInfo
CHOICE). Only one copy of the encrypted CEK is required because all
Turner 3 Turner 3
the recipients already have the shared KEK needed to decrypt the CEK (kekri RecipientInfo CHOICE). Only one copy of the encrypted CEK is
and hence gain access to the encrypted content. required because all the recipients already have the shared KEK
needed to decrypt the CEK and hence gain access to the encrypted
content.
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 confidentiality. Access
Access control to the information protected by the KEK is determined control to the information protected by the KEK is determined by the
by the entity that encrypts the information, as all members of the entity that encrypts the information, as all members of the group
group have access. If the entity that is performing the encryption have access. If the entity that is performing the encryption wants
wants to ensure some subset of the group does not gain access to the to ensure some subset of the group does not gain access to the
information either a different KEK should be used (shared with this information either a different KEK should be used (shared only with
smaller group) or asymmetric algorithms should be used. this 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, support the
defined to support distribution of messages to recipients subscribed distribution of messages to recipients subscribed to the mail list.
to the mail list. There are two models for how the mail list can be There are two models for how the mail list can be used. If the
used. If the originator is a member of the mail list, the originator originator is a member of the mail list, the originator sends
sends messages encrypted with the shared KEK to the mail list (e.g., messages encrypted with the shared KEK to the mail list (e.g.,
listserv or majordomo) and the message is distributed to the mail listserv or majordomo) and the message is distributed to the mail
list members. If the originator is not a member of the mail list list members. If the originator is not a member of the mail list
(does not have the shared KEK), the originator sends the message (does not have the shared KEK), the originator sends the message
(encrypted for the MLA) to the mail list agent (MLA) and the MLA (encrypted for the MLA) to the mail list agent (MLA), and then the
then forms the shared KEK needed to encrypt the message. In either MLA uses the shared KEK to encrypt the message for the members. In
case the recipients of the mail list use the previously distributed- either case the recipients of the mail list use the previously
shared KEK to decrypt the message. distributed-shared KEK to decrypt the message.
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.
1.3 Using the Group Key
This document was written with three specific scenarios in mind: two
supporting mail list agents and one for general message
distribution. Scenario 1 depicts the originator sending a public key
(PK) protected message to a MLA who then uses the shared KEK (S) to
Turner 4 Turner 4
redistribute the message to the members of the list. Scenario 2
depicts the originator sending a shared KEK protected message to a
MLA who then redistributes the message to the members of the list
(the MLA only adds additional recipients). Scenario 3 shows an
originator sending a shared KEK protected message to a group of
recipients without an intermediate MLA.
+----> +----> +---->
PK +-----+ S | S +-----+ S | S |
----> | MLA | --+----> ----> | MLA | --+----> ----+---->
+-----+ | +-----+ | |
+----> +----> +---->
Scenario 1 Scenario 2 Scenario 3
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
skipping to change at line 235 skipping to change at line 259
| Member 1 | | ... | | Member n | | Member 1 | | ... | | Member n |
+----------+ +---------+ +----------+ +----------+ +---------+ +----------+
Figure 1 - Key Distribution Architecture Figure 1 - Key Distribution Architecture
A GLA may support multiple KMAs. A GLA in general supports only one A GLA may support multiple KMAs. A GLA in general supports only one
GMA, but the GMA may support multiple GLs. Multiple KMAs may support GMA, but the GMA may support multiple GLs. Multiple KMAs may support
a GMA in the same fashion as GLAs support multiple KMAs. Assigning a a GMA in the same fashion as GLAs support multiple KMAs. Assigning a
particular KMA to a GL is beyond the scope of this document. particular KMA to a GL is beyond the scope of this document.
Turner 5
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.
Note: If the distribution for the list is performed by an entity
other than the originator (e.g., an MLA distributing a mail
message), this entity can also enforce access control rules.
In either case, the GL must initially be constructed by an entity In either case, the GL must initially be constructed by an entity
hereafter called the Group List Owner (GLO). There may be multiple hereafter called the Group List Owner (GLO). There may be multiple
entities who 'own' the GL and who are allowed to make changes the entities who 'own' the GL and who are allowed to make changes to the
GLĘs properties or membership. The GLO determines if the GL will be GLĘs properties or membership. The GLO determines if the GL will be
managed or unmanaged and is the only entity that may delete the GL. managed or unmanaged and is the only entity that may delete the GL.
GLO(s) may or may not be GL members. GLO(s) may also setup lists GLO(s) may or may not be GL members. GLO(s) may also setup lists
that are closed, where the GLO solely determines GL membership. that are closed, where the GLO solely determines GL membership.
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
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 not discussed
term GLA will be used to address both functions. It should be noted further; the term GLA will be used to address both functions. It
that corrupt GLA can always cause havoc. 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 manage GLs; however, this document does not address securing these
securing these mechanisms, as they are not standardized. Instead, it mechanisms, as they are not standardized. Instead, it defines
defines protocol interactions, as depicted in Figure 2, used by the protocol interactions, as depicted in Figure 2, used by the GL
GL members, GLA, and GLO(s) to manage GLs and distribute shared members, GLA, and GLO(s) to manage GLs and distribute shared KEKs.
KEKs. The interactions have been divided into administration The interactions have been divided into administration messages and
messages and distribution messages. The administrative messages are distribution messages. The administrative messages are the request
the request and response messages needed to setup the GL, delete the and response messages needed to setup the GL, delete the GL, add
GL, add members to the GL, delete members of the GL, and request a members to the GL, delete members of the GL, request a group rekey,
group rekey, etc. The distribution messages are the messages that add owners to the GL, remove owners of the GL, indicate a group key
distribute the shared KEKs. The following sections describe the compromise, refresh a group key, interrogate the GLA, and update
ASN.1 for both the administration and distribution messages. Section memberĘs and ownerĘs public key certificates. The distribution
4 describes how to use the administration messages and section 5
describes how to use the distribution messages. Turner 6
messages are the messages that distribute the shared KEKs. The
following sections describe the ASN.1 for both the administration
and distribution messages. Section 4 describes how to use the
administration messages, and section 5 describes how to use the
distribution messages.
+-----+ +----------+ +-----+ +----------+
| GLO | <---+ +----> | Member 1 | | GLO | <---+ +----> | Member 1 |
+-----+ | | +----------+ +-----+ | | +----------+
| | | |
+-----+ <------+ | +----------+ +-----+ <------+ | +----------+
| GLA | <-------------+----> | ... | | GLA | <-------------+----> | ... |
+-----+ | +----------+ +-----+ | +----------+
| |
| +----------+ | +----------+
+----> | Member n | +----> | Member n |
+----------+ +----------+
Figure 2 - Protocol Interactions Figure 2 - Protocol Interactions
Turner 6
3.1 Control Attributes 3.1 Control Attributes
The messages are based on including control attributes in CMC's To avoid creating an entirely new protocol, the Certificate
PKIData for requests and CMC's ResponseBody for responses. The Management Messages over CMS (CMC) protocol was chosen as the
foundation of this protocol. The main reason for the choice was the
layering aspect provided by CMC where one or more control attributes
are included in message, protected with CMS, to request or respond
to a desired action. The CMC PKIData structure is used for requests,
and the CMC ResponseBody structure is used for responses. The
content-types PKIData and PKIResponse are then encapsulated in CMS's content-types PKIData and PKIResponse are then encapsulated in CMS's
SignedData or EnvelopedData, or a combination of the two (see SignedData or EnvelopedData, or a combination of the two (see
section 3.2). The following are the control attributes defined in section 3.2). The following are the control attributes defined in
this document: this document:
Control Control
Attribute OID Syntax Attribute OID Syntax
------------------- ----------- ----------------- ------------------- ----------- -----------------
glUseKEK id-skd 1 GLUseKEK glUseKEK id-skd 1 GLUseKEK
glDelete id-skd 2 GeneralName glDelete id-skd 2 GeneralName
skipping to change at line 330 skipping to change at line 365
glAddOwner id-skd 6 GLOwnerAdministration glAddOwner id-skd 6 GLOwnerAdministration
glRemoveOwner id-skd 7 GLOwnerAdministration glRemoveOwner id-skd 7 GLOwnerAdministration
glkCompromise id-skd 8 GeneralName glkCompromise id-skd 8 GeneralName
glkRefresh id-skd 9 GLKRefresh glkRefresh id-skd 9 GLKRefresh
glaQueryRequest id-skd 11 GLAQueryRequest glaQueryRequest id-skd 11 GLAQueryRequest
glaQueryResponse id-skd 12 GLAQueryResponse glaQueryResponse id-skd 12 GLAQueryResponse
glProvideCert id-skd 13 GLManageCert glProvideCert id-skd 13 GLManageCert
glUpdateCert id-skd 14 GLManageCert glUpdateCert id-skd 14 GLManageCert
glKey id-skd 15 GLKey glKey id-skd 15 GLKey
Turner 7
In the following conformance tables, the column headings have the In the following conformance tables, the column headings have the
following meanings: O for originate, R for receive, and F for following meanings: O for originate, R for receive, and F for
forward. There are three types of implementations: GLOs, GLAs, and forward. There are three types of implementations: GLOs, GLAs, and
GL members. The GLO is an optional component hence all GLO O and R GL members. The GLO is an optional component hence all GLO O and GLO
messages are optional and GLA F messages are optional. The first R messages are optional, and GLA F messages are optional. The first
table includes messages that MUST be implemented in order to be table includes messages that conformant implementions MUST support.
considered conformant to this document. The second table includes The second table includes messages that MAY be implemented. The
messages that MAY be implemented in order to be considered second table should be interpreted as follows: if the control
conformant to this document. Note that ō-ō mean not applicable. attribute is implemented by a component then it must be implemented
as indicated. For example, if a GLA is implemented that supports the
glAddMember control attribute, then it MUST support receiving the
glAddMember message. Note that ō-ō means not applicable.
Required Required
Implementation Requirement | Control Implementation Requirement | Control
GLO | GLA | GL Member | Attribute GLO | GLA | GL Member | Attribute
O R | O R F | O R | O R | O R F | O R |
------- | ----------------- | --------- | ---------- ------- | ----------------- | --------- | ----------
MAY - | MUST - MAY | - MUST | glProvideCert MAY - | MUST - MAY | - MUST | glProvideCert
MAY MAY | - MUST MAY | MUST - | glUpdateCert MAY MAY | - MUST MAY | MUST - | glUpdateCert
- - | MUST - - | - MUST | glKey - - | MUST - - | - MUST | glKey
Turner 7
Optional Optional
Implementation Requirement | Control Implementation Requirement | Control
GLO | GLA | GL Member | Attribute GLO | GLA | GL Member | Attribute
O R | O R F | O R | O R | O R F | O R |
------- | ----------------- | --------- | ---------- ------- | ----------------- | --------- | ----------
MAY - | - MAY - | - - | glUseKEK MAY - | - MAY - | - - | glUseKEK
MAY - | - MAY - | - - | glDelete MAY - | - MAY - | - - | glDelete
MAY MAY | - MUST MAY | MUST - | glAddMember MAY MAY | - MUST MAY | MUST - | glAddMember
MAY MAY | - MUST MAY | MUST - | glDeleteMember MAY MAY | - MUST MAY | MUST - | glDeleteMember
MAY - | - MAY - | - - | glRekey MAY - | - MAY - | - - | glRekey
MAY - | - MAY - | - - | glAddOwner MAY - | - MAY - | - - | glAddOwner
MAY - | - MAY - | - - | glRemoveOwner MAY - | - MAY - | - - | glRemoveOwner
MAY MAY | - MUST MAY | MUST - | glkCompromise MAY MAY | - MUST MAY | MUST - | glkCompromise
MAY - | - MUST - | MUST - | glkRefresh MAY - | - MUST - | MUST - | glkRefresh
MAY - | - SHOULD - | MAY - | glaQueryRequest MAY - | - SHOULD - | MAY - | glaQueryRequest
- MAY | SHOULD - - | - MAY | glaQueryResponse - MAY | SHOULD - - | - MAY | glaQueryResponse
glaQueryResponse, and gloResponse are responses and go into the glaQueryResponse and gloResponse are carried in the CMC PKIResponse
PKIResponse content-type, all other control attributes are included content-type, all other control attributes are carried in the CMC
in requests and go into the PKIData content-type. The exception is PKIData content-type. The exception is glUpdateCert which can be
glUpdateCert which may be included in either PKIData or PKIResponse. carried in either PKIData or PKIResponse.
Success and failure messages use CMC (see paragraph 3.2.4). Success and failure messages use CMC (see section 3.2.4).
Turner 8
3.1.1 GL USE KEK 3.1.1 GL USE KEK
The GLO uses glUseKEK to request that a shared KEK be assigned to a The GLO uses glUseKEK to request that a shared KEK be assigned to a
GL. glUseKEK messages MUST be signed by the GLO. The glUseKEK GL. glUseKEK messages MUST be signed by the GLO. The glUseKEK
control attribute shall have the syntax GLUseKEK: control attribute has the syntax GLUseKEK:
GLUseKEK ::= SEQUENCE { GLUseKEK ::= SEQUENCE {
glInfo GLInfo, glInfo GLInfo,
glOwnerInfo SEQUENCE SIZE (1..MAX) OF GLOwnerInfo, glOwnerInfo SEQUENCE SIZE (1..MAX) OF GLOwnerInfo,
glAdministration GLAdministration DEFAULT 1, glAdministration GLAdministration DEFAULT 1,
glKeyAttributes GLKeyAttributes OPTIONAL } glKeyAttributes GLKeyAttributes OPTIONAL }
GLInfo ::= SEQUENCE { GLInfo ::= SEQUENCE {
glName GeneralName, glName GeneralName,
glAddress GeneralName } glAddress GeneralName }
GLOwnerInfo ::= SEQUENCE { GLOwnerInfo ::= SEQUENCE {
glOwnerName GeneralName, glOwnerName GeneralName,
glOwnerAddress GeneralName, glOwnerAddress GeneralName,
certificate Certificates OPTIONAL } certificate Certificates OPTIONAL }
Turner 8
Certificates ::= SEQUENCE { Certificates ::= SEQUENCE {
pKC [0] Certificate OPTIONAL, pKC [0] Certificate OPTIONAL,
-- See PKIX [5] -- See PKIX [5]
aC [1] SEQUENCE SIZE (1.. MAX) OF aC [1] SEQUENCE SIZE (1.. MAX) OF
AttributeCertificate OPTIONAL, AttributeCertificate OPTIONAL,
-- See ACPROF [6] -- See ACPROF [6]
certificationPath [2] CertificateSet OPTIONAL } certPath [2] CertificateSet OPTIONAL }
-- From CMS [2] -- From CMS [2]
-- CertificateSet and CertificateChoices are included only -- CertificateSet and CertificateChoices are included only
-- for illustrative purposes as they are imported from CMS [2]. -- for illustrative purposes as they are imported from CMS [2].
CertificateSet ::= SET SIZE (1..MAX) OF CertificateChoices CertificateSet ::= SET SIZE (1..MAX) OF CertificateChoices
CertificateChoices ::= CHOICE { -- CertificateChoices supports X.509 public key certificates in
certificate Certificate, -- certificates and v2 attribute certificates in v2AttrCert.
-- See PKIX [5]
extendedCertificate [0] IMPLICIT ExtendedCertificate,
-- Obsolete
attrCert [1] IMPLICIT AttributeCertificate }
-- See ACPROF [6]
GLAdministration ::= INTEGER { GLAdministration ::= INTEGER {
unmanaged (0), unmanaged (0),
managed (1), managed (1),
closed (2) } closed (2) }
GLKeyAttributes ::= SEQUENCE { GLKeyAttributes ::= SEQUENCE {
rekeyControlledByGLO [0] BOOLEAN DEFAULT FALSE, rekeyControlledByGLO [0] BOOLEAN DEFAULT FALSE,
recipientsNotMutuallyAware [1] BOOLEAN DEFAULT TRUE, recipientsNotMutuallyAware [1] BOOLEAN DEFAULT TRUE,
duration [2] INTEGER DEFAULT 0, duration [2] INTEGER DEFAULT 0,
generationCounter [3] INTEGER DEFAULT 2, generationCounter [3] INTEGER DEFAULT 2,
requestedAlgorithm [4] AlgorithmIdentifier requestedAlgorithm [4] AlgorithmIdentifier
DEFAULT id-alg-CMS3DESwrap } DEFAULT id-alg-CMS3DESwrap }
Turner 9
The fields in GLUseKEK have the following meaning: The fields in GLUseKEK have the following meaning:
- glInfo indicates the GLĘs name in glName and the GLĘs address in - glInfo indicates the name of the GL in glName and the address of
glAddress. In some instances the glName and glAddress may be the the GL in glAddress. The glName and glAddress can be the same,
same, but this is not always the case. Both the name and address but this is not always the case. Both the name and address MUST
MUST be unique for a given GLA. be unique for a given GLA.
- glOwnerInfo indicates: - glOwnerInfo indicates:
- glOwnerName indicates the GL ownerĘs name. - glOwnerName indicates the name of the owner of the GL.
- glOwnerAddress indicates the GL ownerĘs address. One of the - glOwnerAddress indicates the address of the owner of the GL.
names in glOwnerName MUST match one of the names in the One of the names in glOwnerName MUST match one of the names in
certificate used to sign this SignedData.PKIData creating the the certificate (either the subject distinguished name or one
GL (i.e., the immediate signer). of the subject alternative names) used to sign this
SignedData.PKIData creating the GL (i.e., the immediate
signer).
Turner 9
- certificates MAY be included. It contains the following three - certificates MAY be included. It contains the following three
fields: fields:
- certificates.pKC includes the GLO's encryption certificate - certificates.pKC includes the encryption certificate for the
that will be used to at least initially encrypt the shared GLO. It will be used, at least initially, to encrypt the
KEK for that member. If the message is generated by a GLO shared KEK for that member. If the message is generated by a
and they are adding another GLO (i.e., the name in one of GLO and they are adding another GLO (i.e., the name in one
the certificates used to sign this message does not match of the certificates used to sign this message does not match
the name in glOwnerName), the pKC for the other GLO MUST be the name in glOwnerName), the pKC for the other GLO MUST be
included. Else, the pKC MAY be included. included. Otherwise, the pKC MAY be included.
- certificates.aC MAY be included to convey any attribute - certificates.aC MAY be included to convey any attribute
certificate associated with the GLOĘs encryption certificate certificate (see AC Profile [6]) associated with the
included in certificates.pKC. encryption certificate of the GLO included in
certificates.pKC.
- certificates.certificationPath MAY also be included to - certificates.certPath MAY also be included to convey
convey the certification path corresponding to the GLO's certificates that might aid the recipient in constructing
encryption and any non-GLO attribute certificates are placed valid certification paths for the certificate provided in
in attrCert. The certification path is optional because it certificates.pKC and the attribute certificates provided in
may already be included elsewhere in the message (e.g., in certificates.aC. Theses certificates are optional because
the outer CMS layer). they might already be included elsewhere in the message
(e.g., in the outer CMS layer).
- glAdministration indicates how the GL should be administered. - glAdministration indicates how the GL ought to be administered.
The default is for the list to be managed. Three values are The default is for the list to be managed. Three values are
supported for glAdministration: 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 addition and
and deleted from the GL without GLO intervention. deletion from the GL without GLO intervention.
- 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 to and are allowing prospective members to request addition and
deleted from the GL, but the request is redirected by the GLA
Turner 10
deletion from the GL, but the request is redirected by the GLA
to GLO for review. The GLO makes the determination as to to GLO for review. The GLO makes 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 to are not allowing prospective members to request addition or
or deleted from the GL. The GLA will only accept glAddMember deletion from the GL. The GLA will only accept glAddMember and
and glDeleteMember requests from the GLO. glDeleteMember requests from the GLO.
- 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 this field is omitted, GL rekeys to assign to the shared KEK. If this field is omitted, GL rekeys
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 Triple-DES (see know about one another, the algorithm will be Triple-DES (see
paragrpah 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
Turner 10
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.
- recipientsNotMutuallyAware indicates that the GLO wants the - recipientsNotMutuallyAware indicates that the GLO wants the
GLA to distribute the shared KEK individually for each of the GLA to distribute the shared KEK individually for each of the
GL members (i.e., a separate glKey message is sent to each GL 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.
skipping to change at line 525 skipping to change at line 563
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 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 at indicates that the shared KEK is valid for a calendar month in
UTC Zulu time zone. For example if the duration is zero (0), the UTC Zulu time zone. For example if the duration is zero
if the GL shared KEK is requested on July 24, the first key (0), if the GL shared KEK is requested on July 24, the first
will be valid until the end of July and the next key will be key will be valid until the end of July and the next key will
valid for the entire month of August. If the value is not zero be valid for the entire month of August. If the value is not
(0), the shared KEK will be valid for the number of days zero (0), the shared KEK will be valid for the number of days
indicated by the value. For example, if the value of duration indicated by the value. For example, if the value of duration
is seven (7) and the shared KEK is requested on Monday but not is seven (7) and the shared KEK is requested on Monday but not
generated until Tuesday (2359); the shared KEKs will be valid generated until Tuesday (2359); the shared KEKs will be valid
Turner 11
from Tuesday (2359) to Tuesday (2359). The exact time of the from Tuesday (2359) to Tuesday (2359). The exact time of the
day is determined when the key is generated. day is 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. If the GLA controls longer valid the second key can be used. If the GLA controls
rekey then it also indicates the number of shared KEKs the GLO rekey then it also indicates the number of shared KEKs the GLO
wants outstanding at any one time. See sections 4.5 and 5 for wants outstanding at any one time. See sections 4.5 and 5 for
more on rekey. more on rekey.
- requestedAlgorithm indicates the algorithm and any parameters - requestedAlgorithm indicates the algorithm and any parameters
the GLO wants the GLA to use with the shared KEK. The the GLO wants the GLA to use with the shared KEK. The
parameters are conveyed via the SMIMECapabilities attribute parameters are conveyed via the SMIMECapabilities attribute
see MSG [7]. See section 6 for more on algorithms. (see MSG [7]). See section 6 for more on algorithms.
Turner 11
3.1.2 Delete GL 3.1.2 Delete GL
GLOs use glDelete to request that a GL be deleted from the GLA. The GLOs use glDelete to request that a GL be deleted from the GLA. The
glDelete control attribute shall have the syntax GeneralName. The glDelete control attribute has the syntax GeneralName. The glDelete
name of the GL to be deleted is included in GeneralName. The message MUST be signed by the GLO. The name of the GL to be deleted
glDelete message MUST be signed by the GLO. is included in GeneralName:
DeleteGL ::= GeneralName
3.1.3 Add GL Member 3.1.3 Add GL Member
GLOs use glAddMember to request addition of new members and GLOs use the glAddMember to request addition of new members, and
prospective GL members use glAddMember to request being added to the prospective GL members use the glAddMember to request their own
GL. The glAddMember message MUST be signed by either the GLO or the addition to the GL. The glAddMember message MUST be signed by either
prospective GL member. The glAddMember control attribute shall have the GLO or the prospective GL member. The glAddMember control
the syntax GLAddMember: attribute has the syntax GLAddMember:
GLAddMember ::= SEQUENCE { GLAddMember ::= SEQUENCE {
glName GeneralName, glName GeneralName,
glMember GLMember } glMember GLMember }
GLMember ::= SEQUENCE { GLMember ::= SEQUENCE {
glMemberName GeneralName, glMemberName GeneralName,
glMemberAddress GeneralName OPTIONAL, glMemberAddress GeneralName OPTIONAL,
certificates Certificates OPTIONAL } certificates Certificates OPTIONAL }
Turner 12
Certificates ::= SEQUENCE { Certificates ::= SEQUENCE {
pKC [0] Certificate OPTIONAL, pKC [0] Certificate OPTIONAL,
-- See PKIX [5] -- See PKIX [5]
aC [1] SEQUENCE SIZE (1.. MAX) OF aC [1] SEQUENCE SIZE (1.. MAX) OF
AttributeCertificate OPTIONAL, AttributeCertificate OPTIONAL,
-- See ACPROF [6] -- See ACPROF [6]
certificationPath [2] CertificateSet OPTIONAL } certPath [2] CertificateSet OPTIONAL }
-- From CMS [2] -- From CMS [2]
-- CertificateSet and CertificateChoices are included only -- CertificateSet and CertificateChoices are included only
-- for illustrative purposes as they are imported from CMS [2]. -- for illustrative purposes as they are imported from CMS [2].
CertificateSet ::= SET SIZE (1..MAX) OF CertificateChoices CertificateSet ::= SET SIZE (1..MAX) OF CertificateChoices
CertificateChoices ::= CHOICE { -- CertificateChoices supports X.509 public key certificates in
certificate Certificate, -- certificates and v2 attribute certificates in v2AttrCert.
-- See X.509
extendedCertificate [0] IMPLICIT ExtendedCertificate,
-- Obsolete
attrCert [1] IMPLICIT AttributeCertificate }
-- 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.
Turner 12
- glMember indicates the particulars for the GL member. Both of - glMember indicates the particulars for the GL member. Both of
the following fields must be unique for a given GL: the following fields must be unique for a given GL:
- glMemberName indicates the name of the GL member. - glMemberName indicates the name of the GL member.
- glMemberAddress indicates the GL memberĘs address. It MUST be - glMemberAddress indicates the GL memberĘs address. It MUST be
included. included.
Note: In some instances the glMemberName and glMemberAddress Note: In some instances the glMemberName and glMemberAddress
may be the same, but this is not always the case. may be the same, but this is not always the case.
- certificates MUST be included. It contains the following three - certificates MUST be included. It contains the following three
fields: fields:
- certificates.pKC includes the member's encryption - certificates.pKC includes the member's encryption
certificate that will be used to at least initially encrypt certificate. It will be used, at least initially, to encrypt
the shared KEK for that member. If the message is generated the shared KEK for that member. If the message is generated
by a prospective GL member, the pKC MUST be included. If the by a prospective GL member, the pKC MUST be included. If the
message is generated by a GLO, the pKC SHOULD be included. message is generated by a GLO, the pKC SHOULD be included.
- certificates.aC MAY be included to convey any attribute - certificates.aC MAY be included to convey any attribute
certificate associated with the memberĘs encryption certificate (see AC Profile [6]) associated with the
certificate. memberĘs encryption certificate.
- certificates.certificationPath MAY also be included to - certificates.certPath MAY also be included to convey
convey the certification path corresponding to the member's certificates that might aid the recipient in constructing
encryption and any non-member attribute certificates are valid certification paths for the certificate provided in
placed in attrCert. The certification path is optional certificates.pKC and the attribute certificates provided in
because it may already be included elsewhere in the message certificates.aC. These certificates are optional because
Turner 13
they might already be included elsewhere in the message
(e.g., in the outer CMS layer). (e.g., in the outer CMS layer).
3.1.4 Delete GL Member 3.1.4 Delete GL Member
GLOs use glDeleteMember to request deletion of GL members and GL GLOs use the glDeleteMember to request deletion of GL members, and
members use glDeleteMember to request being removed from the GL. The GL members use the glDeleteMember to request their own removal from
glDeleteMember message MUST be signed by either the GLO or the the GL. The glDeleteMember message MUST be signed by either the GLO
prospective GL member. The glDeleteMember control attribute shall or the GL member. The glDeleteMember control attribute has the
have the syntax GLDeleteMember: syntax GLDeleteMember:
GLDeleteMember ::= SEQUENCE { GLDeleteMember ::= SEQUENCE {
glName GeneralName, glName GeneralName,
glMemberToDelete GeneralName } glMemberToDelete GeneralName }
The fields in GLDeleteMembers have the following meaning: The fields in GLDeleteMembers have the following meaning:
- glName indicates the name of the GL from which the member should - glName indicates the name of the GL from which the member should
be removed. be removed.
- glMemberToDelete indicates the name of the member to be deleted. - glMemberToDelete indicates the name of the member to be deleted.
Turner 13
3.1.5 Rekey GL 3.1.5 Rekey GL
GLOs use the glRekey to request a GL rekey. The glRekey message MUST GLOs use the glRekey to request a GL rekey. The glRekey message MUST
be signed by the GLO. The glRekey control attribute shall have the be signed by the GLO. The glRekey control attribute has the syntax
syntax GLRekey: GLRekey:
GLRekey ::= SEQUENCE { GLRekey ::= SEQUENCE {
glName GeneralName, glName GeneralName,
glAdministration GLAdministration OPTIONAL, glAdministration GLAdministration OPTIONAL,
glNewKeyAttributes GLNewKeyAttributes OPTIONAL, glNewKeyAttributes GLNewKeyAttributes OPTIONAL,
glRekeyAllGLKeys BOOLEAN OPTIONAL } glRekeyAllGLKeys BOOLEAN OPTIONAL }
GLNewKeyAttributes ::= SEQUENCE { GLNewKeyAttributes ::= SEQUENCE {
rekeyControlledByGLO [0] BOOLEAN OPTIONAL, rekeyControlledByGLO [0] BOOLEAN OPTIONAL,
recipientsNotMutuallyAware [1] BOOLEAN OPTIONAL, recipientsNotMutuallyAware [1] BOOLEAN OPTIONAL,
duration [2] INTEGER OPTIONAL, duration [2] INTEGER OPTIONAL,
generationCounter [3] INTEGER OPTIONAL, generationCounter [3] INTEGER OPTIONAL,
requestedAlgorithm [4] AlgorithmIdentifier OPTIONAL } requestedAlgorithm [4] AlgorithmIdentifier OPTIONAL }
The fields in GLRekey have the following meaning: The fields in GLRekey have the following meaning:
- glName indicates the name of the GL to be rekeyed. - glName indicates the name of the GL to be rekeyed.
- glAdministration indicates if there is any change to how the GL - glAdministration indicates if there is any change to how the GL
should be administered. See section 3.1.1 for the three options. should be administered. See section 3.1.1 for the three options.
Turner 14
This field is only included if there is a change from the This field is only included if there is a change from the
previously registered administered. previously registered administered.
- glNewKeyAttributes indicates whether the rekey of the GLO is - glNewKeyAttributes indicates whether the rekey of the GLO is
controlled by the GLA or GL, what algorithm and parameters the controlled by the GLA or GL, what algorithm and parameters the
GLO wishes to use, the duration of the key, and how many 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 will 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. glKeyAttributes.
- glRekeyAllGLKeys indicates whether the GLO wants all of the - glRekeyAllGLKeys indicates whether the GLO wants all of the
outstanding GLĘs shared KEKs rekeyed. If it is set to TRUE then outstanding GLĘs shared KEKs rekeyed. If it is set to TRUE then
all outstanding KEKs MUST be issued. If it is set to FALSE then all outstanding KEKs MUST be issued. If it is set to FALSE then
all outstanding KEKs need not be resissued. all outstanding KEKs need not be resissued.
Turner 14
3.1.6 Add GL Owner 3.1.6 Add GL Owner
GLOs use the glAddOwner to request that a new GLO be allowed to GLOs use the glAddOwner to request that a new GLO be allowed to
administer the GL. The glAddOwner message MUST be signed a administer the GL. The glAddOwner message MUST be signed by a
registered GLO. The glAddOwner control attribute shall have the registered GLO. The glAddOwner control attribute has the syntax
syntax GLOwnerAdministration: GLOwnerAdministration:
GLOwnerAdministration ::= SEQUENCE { GLOwnerAdministration ::= SEQUENCE {
glName GeneralName, glName GeneralName,
glOwnerInfo GLOwnerInfo } glOwnerInfo GLOwnerInfo }
The fields in GLAddOwners have the following meaning: The fields in GLAddOwners have the following meaning:
- glName indicates the name of the GL to which the new GLO should - glName indicates the name of the GL to which the new GLO should
be associated. be associated.
- glOwnerInfo indicates the name, address, and certificates of the - glOwnerInfo indicates the name, address, and certificates of the
new GLO. As this message includes names of new GLOs, the new GLO. As this message includes names of new GLOs, the
certificates.pKC MUST be included and it MUST include the new certificates.pKC MUST be included, and it MUST include the
GLOĘs encryption certificate. encryption certificate of the new GLO.
3.1.7 Remove GL Owner 3.1.7 Remove GL Owner
GLOs use the glRemoveOwner to request that a GLO be disassociated GLOs use the glRemoveOwner to request that a GLO be disassociated
with the GL. The glRemoveOwner message MUST be signed by a with the GL. The glRemoveOwner message MUST be signed by a
registered GLO. The glRemoveOwner control attribute shall have the registered GLO. The glRemoveOwner control attribute has the syntax
syntax GLOwnerAdministration: GLOwnerAdministration:
GLOwnerAdministration ::= SEQUENCE { GLOwnerAdministration ::= SEQUENCE {
glName GeneralName, glName GeneralName,
glOwnerInfo GLOwnerInfo } glOwnerInfo GLOwnerInfo }
Turner 15
The fields in GLRemoveOwners have the following meaning: The fields in GLRemoveOwners have the following meaning:
- glName indicates the name of the GL to which the GLO should be - glName indicates the name of the GL to which the GLO should be
disassociated. disassociated.
- glOwnerInfo indicates the name and address of the GLO to be - glOwnerInfo indicates the name and address of the GLO to be
removed. The certificates field SHOULD be omitted, as it will be removed. The certificates field SHOULD be omitted, as it will be
ignored. ignored.
3.1.8 GL Key Compromise 3.1.8 GL Key Compromise
GL members and GLOs use glkCompromise to indicate that the shared GL members and GLOs use glkCompromise to indicate that the shared
KEK possessed has been compromised. The glKeyCompromise control KEK possessed has been compromised. The glKeyCompromise control
attribute shall have the syntax GeneralName. The name of the GL to attribute has the syntax GeneralName. This message is always
which the compromised key is associated with is included in redirected by the GLA to the GLO for further action. The
GeneralName. This message is always redirected by the GLA to the GLO glkCompromise MAY be included in an EnvelopedData generated with the
for further action. The glkCompromise MUST NOT be included in an compromised shared KEK. The name of the GL to which the compromised
EnvelopedData generated with the compromised shared KEK. key is associated with is included in GeneralName:
Turner 15 GLKCompromise ::= GeneralName
3.1.9 GL Key Refresh 3.1.9 GL Key Refresh
GL members use the glkRefresh to request that the shared KEK be GL members use the glkRefresh to request that the shared KEK be
redistributed to them. The glkRefresh control attribute shall have redistributed to them. The glkRefresh control attribute has the
the syntax GLKRefresh. syntax GLKRefresh.
GLKRefresh ::= SEQUENCE { GLKRefresh ::= SEQUENCE {
glName GeneralName, glName GeneralName,
dates SEQUENCE SIZE (1..MAX) OF Date } dates SEQUENCE SIZE (1..MAX) OF Date }
Date ::= SEQUENCE { Date ::= SEQUENCE {
start GeneralizedTime, start GeneralizedTime,
end GeneralizedTime OPTIONAL } end GeneralizedTime OPTIONAL }
The fields in GLKRefresh have the following meaning: The fields in GLKRefresh have the following meaning:
- glName indicates the name of the GL for which the GL member - glName indicates the name of the GL for which the GL member
wants shared KEKs. wants shared KEKs.
- dates indicates a date range for keys the GL member wants. The - dates indicates a date range for keys the GL member wants. The
start field indicates the first date the GL member wants and the start field indicates the first date the GL member wants and the
end field indicates the last date. The end date MAY be omitted end field indicates the last date. The end date MAY be omitted
to indicate the GL member wants all keys from the specified to indicate the GL member wants all keys from the specified
start date to the current date. It should be noted that a start date to the current date. Note that a procedural mechanism
procedural mechanism will be needed to restrict users from is needed to restrict users from accessing messages that they
accessing messages that they are not allowed to access. are not allowed to access.
Turner 16
3.1.10 GLA Query Request and Response 3.1.10 GLA Query Request and Response
There are situations where GLOs and GL members may need to determine There are situations where GLOs and GL members may need to determine
some information from the GLA about the GL. GLOs and GL members use some information from the GLA about the GL. GLOs and GL members use
the glaQueryRequest, defined in paragraph 3.1.10.1, to request the glaQueryRequest, defined in section 3.1.10.1, to request
information and GLAs use the glaQueryResponse, defined in paragraph information and GLAs use the glaQueryResponse, defined in section
3.1.10.2, to return the requested information. Paragraph 3.1.10.3 3.1.10.2, to return the requested information. Section 3.1.10.3
includes one request and response type and value; others may be includes one request and response type and value; others may be
defined in additional documents. defined in additional documents.
3.1.10.1 GLA Query Request 3.1.10.1 GLA Query Request
GLOs and GL members use the glaQueryRequest to ascertain information GLOs and GL members use the glaQueryRequest to ascertain information
about the GLA. The glaQueryRequest control attribute shall have the about the GLA. The glaQueryRequest control attribute has the syntax
syntax GLAQueryRequest: GLAQueryRequest:
GLAQueryRequest ::= SEQUENCE { GLAQueryRequest ::= SEQUENCE {
glaRequestType OBJECT IDENTIFIER, glaRequestType OBJECT IDENTIFIER,
glaRequestValue ANY DEFINED BY glaRequestType } glaRequestValue ANY DEFINED BY glaRequestType }
Turner 16
3.1.10.2 GLA Query Response 3.1.10.2 GLA Query Response
GLAĘs return the glaQueryResponse after receiving a GLAQueryRequest. GLAs return the glaQueryResponse after receiving a GLAQueryRequest.
The glaQueryResponse MUST be signed by a GLA. The glaQueryResponse The glaQueryResponse MUST be signed by a GLA. The glaQueryResponse
control attribute shall have the syntax GLAQueryResponse: control attribute has the syntax GLAQueryResponse:
GLAQueryResponse ::= SEQUENCE { GLAQueryResponse ::= SEQUENCE {
glaResponseType OBJECT IDENTIFIER, glaResponseType OBJECT IDENTIFIER,
glaResponseValue ANY DEFINED BY glaResponseType } glaResponseValue ANY DEFINED BY glaResponseType }
3.1.10.3 Request and Response Types 3.1.10.3 Request and Response Types
Request and Responses are reqistered as a pair under the following Request and Responses are registered as a pair under the following
object identifier arc: object identifier arc:
id-cmc-glaRR OBJECT IDENTIFIER ::= { id-cmc 99 } id-cmc-glaRR OBJECT IDENTIFIER ::= { id-cmc 99 }
This document defines one request/response pair for GL members and This document defines one request/response pair for GL members and
GLOĘs to query the GLA as to which algorithm it supports. The GLOs to query the GLA for the list of algorithm it supports. The
following object identifier is included in the glaQueryType field: following object identifier (OID) is included in the glaQueryType
field:
id-cmc-gla-skdAlgRequest OBJECT IDENTIFIER ::={ id-cmc-glaRR 1 } id-cmc-gla-skdAlgRequest OBJECT IDENTIFIER ::={ id-cmc-glaRR 1 }
There is no glaQueryValue for thie query. SKDAlgRequest ::= NULL
Turner 17
If the GLA supports GLAQueryRequest and GLAQueryResponse messages, If the GLA supports GLAQueryRequest and GLAQueryResponse messages,
the GLA may return the following oid in the glaQueryType field: the GLA may return the following OID in the glaQueryType field:
id-cmc-gla-skdAlgResponse OBJECT IDENTIFIER ::= { id-cmc-glaRR 2 } id-cmc-gla-skdAlgResponse OBJECT IDENTIFIER ::= { id-cmc-glaRR 2 }
The glaQueryValue has the form of the smimeCapabilities attributes The glaQueryValue has the form of the smimeCapabilities attributes
as defined in MsgSpec [7]. as defined in MSG [7].
3.1.12 Provide Cert 3.1.12 Provide Cert
GLAs and GLOs use glProvideCert to request that a GL member provide GLAs and GLOs use the glProvideCert to request that a GL member
an updated or new encryption certificate. The glProvideCert message provide an updated or new encryption certificate. The glProvideCert
MUST be signed by either GLA or GLO. If the GL memberĘs PKC has been message MUST be signed by either GLA or GLO. If the GL memberĘs PKC
revoked, the GLO or GLA MUST NOT use it to generate the has been revoked, the GLO or GLA MUST NOT use it to generate the
EnvelopedData that encapsulates the glProvideCert request. The EnvelopedData that encapsulates the glProvideCert request. The
glProvideCert control attribute shall have the syntax GLManageCert: glProvideCert control attribute has the syntax GLManageCert:
GLManageCert ::= SEQUENCE { GLManageCert ::= SEQUENCE {
glName GeneralName, glName GeneralName,
glMember GLMember } glMember GLMember }
Turner 17
The fields in GLManageCert have the following meaning: The fields in GLManageCert have the following meaning:
- glName indicates the name of the GL to which the GL memberĘs new - glName indicates the name of the GL to which the GL memberĘs new
certificate should be associated. certificate is to be associated.
- glMember indicates particulars for the GL member: - glMember indicates particulars for the GL member:
- glMemberName indicates the GL memberĘs name. - glMemberName indicates the GL memberĘs name.
- glMemberAddress indicates the GL memberĘs address. It MAY be - glMemberAddress indicates the GL memberĘs address. It MAY be
omitted. omitted.
- certificates SHOULD be omitted. - certificates SHOULD be omitted.
3.1.13 Update Cert 3.1.13 Update Cert
GL members and GLOs use glUpdateCert to provide a new certificate GL members and GLOs use the glUpdateCert to provide a new
for the GL. GL members may generate a glUpdateCert unsolicited or as certificate for the GL. GL members can generate an unsolicited
a result of a glProvideCert message. GL members MUST sign the glUpdateCert or generate a response glUpdateCert as a result of
receiveing a glProvideCert message. GL members MUST sign the
glUpdateCert. If the GL memberĘs encryption certificate has been glUpdateCert. If the GL memberĘs encryption certificate has been
revoked, the GL member MUST NOT use it to generate the EnvelopedData revoked, the GL member MUST NOT use it to generate the EnvelopedData
that encapsulates the glUpdateCert request or response. The that encapsulates the glUpdateCert request or response. The
glUpdateCert control attribute shall have the syntax GLManageCert: glUpdateCert control attribute has the syntax GLManageCert:
GLManageCert ::= SEQUENCE { GLManageCert ::= SEQUENCE {
glName GeneralName, glName GeneralName,
glMember GLMember } glMember GLMember }
Turner 18
The fields in GLManageCert have the following meaning: The fields in GLManageCert have the following meaning:
- glName indicates the name of the GL to which the GL memberĘs new - glName indicates the name of the GL to which the GL memberĘs new
certificate should be associated. certificate should be associated.
- glMember indicates the particulars for the GL member: - glMember indicates the particulars for the GL member:
- glMemberName indicates the GL memberĘs name - glMemberName indicates the GL memberĘs name
- glMemberAddress indicates the GL memberĘs address. It MAY be - glMemberAddress indicates the GL memberĘs address. It MAY be
omitted. omitted.
- certificates MAY be omitted if the GLManageCert message is - certificates MAY be omitted if the GLManageCert message is
sent to request the GL members certificate; else it MUST be sent to request the GL memberĘs certificate; otherwise, it
included. It includes the following three fields: MUST be included. It includes the following three fields:
- certificates.pKC includes the member's encryption - certificates.pKC includes the member's encryption
certificate that will be used to encrypt the shared KEK for certificate that will be used to encrypt the shared KEK for
that member. that member.
Turner 18 - certificates.aC MAY be included to convey one or more
- certificates.aC MAY be included to convey any attribute attribute certificate associated with the memberĘs
certificate associated with the memberĘs encryption encryption certificate.
certificate.
- certificates.certificationPath MAY also be included to - certificates.certPath MAY also be included to convey
convey the certification path corresponding to the member's certificates that might aid the recipient in constructing
encryption and attribute certificates. The certification valid certification paths for the certificate provided in
path is optional because it may already be included certificates.pKC and the attribute certificates provided in
elsewhere in the message (e.g., in the outer CMS layer). certificates.aC. These certificates is optional because they
might already be included elsewhere in the message (e.g., in
the outer CMS layer).
3.1.14 GL Key 3.1.14 GL Key
The GLA uses glKey to distribute the shared KEK. The glKey message The GLA uses the glKey to distribute the shared KEK. The glKey
MUST be signed by the GLA. The glKey control attribute shall have message MUST be signed by the GLA. The glKey control attribute has
the syntax GLKey: the syntax GLKey:
GLKey ::= SEQUENCE { GLKey ::= SEQUENCE {
glName GeneralName, glName GeneralName,
glIdentifier KEKIdentifier, -- See CMS [2] glIdentifier KEKIdentifier, -- See CMS [2]
glkWrapped RecipientInfos, -- See CMS [2] glkWrapped RecipientInfos, -- See CMS [2]
glkAlgorithm AlgorithmIdentifier, glkAlgorithm AlgorithmIdentifier,
glkNotBefore GeneralizedTime, glkNotBefore GeneralizedTime,
glkNotAfter GeneralizedTime } glkNotAfter GeneralizedTime }
Turner 19
-- KEKIdentifier is included only for illustrative purposes as -- KEKIdentifier is included only for illustrative purposes as
-- it is imported from CMS [2]. -- it is imported from CMS [2].
KEKIdentifier ::= SEQUENCE { KEKIdentifier ::= SEQUENCE {
keyIdentifier OCTET STRING, keyIdentifier OCTET STRING,
date GeneralizedTime OPTIONAL, date GeneralizedTime OPTIONAL,
other OtherKeyAttribute OPTIONAL } other OtherKeyAttribute OPTIONAL }
The fields in GLKey have the following meaning: The fields in GLKey have the following meaning:
- glName is the name of the GL. - glName is the name of the GL.
- glIdentifier is the key identifier of the shared KEK. See - glIdentifier is the key identifier of the shared KEK. See
paragraph 6.2.3 of CMS [2] for a description of the subfields. paragraph 6.2.3 of CMS [2] for a description of the subfields.
- glkWrapped is the GL's wrapped shared KEK. The RecipientInfos - glkWrapped is the wrapped shared KEK for the GL for a particular
shall be generated as specified in section 6.2 of CMS [2]. The duration. The RecipientInfos MUST be generated as specified in
ktri RecipientInfo choice MUST be supported. The key in the section 6.2 of CMS [2]. The ktri RecipientInfo choice MUST be
EncryptedKey field (i.e., the distributed shared KEK) MUST be supported. The key in the EncryptedKey field (i.e., the
generated according to the section concerning random number distributed shared KEK) MUST be generated according to the
generation in the security considerations of CMS [2]. section concerning random number generation in the security
considerations of CMS [2].
- glkAlgorithm identifies the algorithm the shared KEK is used - glkAlgorithm identifies the algorithm the shared KEK is used
with. Since no encrypted data content is being conveyed at this with. Since no encrypted data content is being conveyed at this
point, the parameters encoded with the algorithm should be the point, the parameters encoded with the algorithm should be the
structure defined for smimeCapabilities rather than encrypted
Turner 19
structure defined for SMIMECapabilities rather than encrypted
content. content.
- glkNotBefore indicates the date at which the shared KEK is - glkNotBefore indicates the date at which the shared KEK is
considered valid. GeneralizedTime values MUST be expressed UTC considered valid. GeneralizedTime values MUST be expressed in
(Zulu) and MUST include seconds (i.e., times are UTC (Zulu) and MUST include seconds (i.e., times are
YYYYMMDDHHMMSSZ), even where the number of seconds is zero. YYYYMMDDHHMMSSZ), even where the number of seconds is zero.
GeneralizedTime values MUST NOT include fractional seconds. GeneralizedTime values MUST NOT include fractional seconds.
- glkNotAfter indicates the date after which the shared KEK is - glkNotAfter indicates the date after which the shared KEK is
considered invalid. GeneralizedTime values MUST be expressed UTC considered invalid. GeneralizedTime values MUST be expressed in
(Zulu) and MUST include seconds (i.e., times are UTC (Zulu) and MUST include seconds (i.e., times are
YYYYMMDDHHMMSSZ), even where the number of seconds is zero. YYYYMMDDHHMMSSZ), even where the number of seconds is zero.
GeneralizedTime values MUST NOT include fractional seconds. GeneralizedTime values MUST NOT include fractional seconds.
If the glKey message is in response to a glUseKEK message: If the glKey message is in response to a glUseKEK message:
- The GLA MUST generate separate glKey messages for each recipient - The GLA MUST generate separate glKey messages for each recipient
if glUseKEK.glKeyAttributes.recipientsNotMutuallyAware is set to if glUseKEK.glKeyAttributes.recipientsNotMutuallyAware is set to
FALSE. For each recipient you want to generate a message that FALSE. For each recipient you want to generate a message that
contains that recipientĘs key (i.e., one message with one contains that recipientĘs key (i.e., one message with one
attribute). attribute).
- The GLA MUST generate X number of glKey messages, where X is the Turner 20
value in glUseKEK.glKeyAttributes.generationCounter. - The GLA MUST generate the requested number of glKey messages.
The value in glUseKEK.glKeyAttributes.generationCounter
indicates the number of glKey messages requested.
If the glKey message is in response to a glRekey message: If the glKey message is in response to a glRekey message:
- The GLA MUST generate separate glKey messages for each recipient - The GLA MUST generate separate glKey messages for each recipient
if glRekey.glNewKeyAttributes.recipientsNotMutuallyAware is set if glRekey.glNewKeyAttributes.recipientsNotMutuallyAware is set
to FALSE. to FALSE.
- The GLA MUST generate X number of glKey messages, where X is the - The GLA MUST generate the requested number of glKey messages.
value in glUseKEK.glKeyAttributes.generationCounter. The value in glUseKEK.glKeyAttributes.generationCounter
indicates the number of glKey messages requested.
- The GLA MUST generate X number of glKey messages, where X is the - The GLA MUST generate one glKey messagefor each outstanding
number of outstanding shared KEKs for the GL if glRekeyAllGLKeys shared KEKs for the GL when glRekeyAllGLKeys is set to TRUE.
is set to TRUE.
If the glKey message was not in response to a glRekey or glUseKEK If the glKey message was not in response to a glRekey or glUseKEK
(e.g., where the GLA controls rekey): (e.g., where the GLA controls rekey):
- The GLA MUST generate separate glKey messages for each recipient - The GLA MUST generate separate glKey messages for each recipient
if glUseKEK.glNewKeyAttributes.recipientsNotMutuallyAware that when glUseKEK.glNewKeyAttributes.recipientsNotMutuallyAware that
set up the GL was set to FALSE. set up the GL was set to FALSE.
- The GLA MAY generate X glKey messages prior to the duration on - The GLA MAY generate glKey messages prior to the duration on the
the last outstanding shared KEK expiring, where X is the last outstanding shared KEK expiring, where the number of glKey
generationCounter minus one (1). Other distribution mechanisms messages generated is generationCounter minus one (1). Other
may also be supported to support this functionality. distribution mechanisms can also be supported to support this
functionality.
Turner 20
3.2 Use of CMC, CMS, and PKIX 3.2 Use of CMC, CMS, and PKIX
The following sections outline the use of CMC, CMS, and PKIX. The following sections outline the use of CMC, CMS, and the PKIX
certificate and CRL profile.
3.2.1 Protection Layers 3.2.1 Protection Layers
The following sections outline the protection required for the The following sections outline the protection required for the
control attributes defined herein. control attributes defined in this document.
Note: There are multiple ways to encapsulate SignedData and
EnvelopedData. The first is to use a MIME wrapper around each
ContentInfo, as specified in MSG [7]. The second is to not use a
MIME wrapper around each ContentInfo, as specified in Transporting
S/MIME Objects in X.400 [8].
Turner 21
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
skipping to change at line 1034 skipping to change at line 1085
MUST be processed according to CMS [2]. MUST be processed according to CMS [2].
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 Authentication and Integrity
-------------------------- --------------------------------- Confidentiality Protection of Confidentiality Protection
-------------------------- -----------------------------
EnvelopedData SignedData EnvelopedData SignedData
SignedData EnvelopedData SignedData EnvelopedData
PKIData or PKIResponse SignedData PKIData or PKIResponse SignedData
controlSequence PKIData or PKIResponse controlSequence PKIData or PKIResponse
controlSequence controlSequence
If an incoming message was encrypted, the confidentiality of the If an incoming message is encrypted, the confidentiality of the
message MUST be preserved. All EnvelopedData objects MUST be message MUST be preserved. All EnvelopedData objects MUST be
processed as specified in CMS [2]. If a SignedData is added over an processed as specified in CMS [2]. If a SignedData is added over an
EnvelopedData, a ContentHints attribute SHOULD be added. See EnvelopedData, a ContentHints attribute SHOULD be added. See
paragraph 2.9 of Extended Security Services for S/MIME [8]. paragraph 2.9 of Extended Security Services for S/MIME [9].
Turner 21
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 to EnvelopedData MUST include the GLA as a recipient. If the GLA
forward the GL member request to the GLO, the GLA decrypts the forwards the GL member request to the GLO, then the GLA MUST decrypt
EnvelopedData, strips the confidentiality layer off, and applies its the EnvelopedData content, strip the confidentiality layer, and
own confidentiality layer for the GLO. apply its own confidentiality layer as an EnvelopedData with the GLO
as a recipient.
Turner 22
3.2.2 Combining Requests and Responses 3.2.2 Combining Requests and Responses
Multiple requests and response corresponding to a GL MAY be included Multiple requests and response corresponding to a GL MAY be included
in one PKIData.controlSequence or PKIResponse.controlSequence. in one PKIData.controlSequence or PKIResponse.controlSequence.
Requests and responses for multiple GLs MAY be combined in one Requests and responses for multiple GLs MAY be combined in one
PKIData or PKIResponse by using PKIData.cmsSequence and PKIData or PKIResponse by using PKIData.cmsSequence and
PKIResponse.cmsSequence. A separate cmsSequence MUST be used for PKIResponse.cmsSequence. A separate cmsSequence MUST be used for
different GLs (i.e., requests corresponding to two different GLs are different GLs. That is, requests corresponding to two different GLs
included in different cmsSequences). The following is a diagram are included in different cmsSequences. The following is a diagram
depicting multiple requests and responses combined in one PKIData depicting multiple requests and responses combined in one PKIData
and PKIResponse: and PKIResponse:
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
One or more requests One or more responses One or more requests One or more responses
corresponding to one GL. corresponding to one GL. corresponding to one GL corresponding to one GL
SignedData SignedData SignedData SignedData
PKIData PKIResponse PKIData PKIResponse
controlSequence controlSequence controlSequence controlSequence
One or more requests One or more responses One or more requests One or more responses
corresponding to another GL. corresponding to another GL. corresponding to another GL corresponding to another GL
Turner 22
When applying confidentiality to multiple requests and responses, When applying confidentiality to multiple requests and responses,
all of the requests/response MAY be included in one EnvelopedData. all of the requests/response MAY be included in one EnvelopedData.
The following is a depiction: The following is a depiction:
Confidentiality of Multiple Requests and Responses Confidentiality of Multiple Requests and Responses
Wrapped Together Wrapped Together
---------------- ----------------
EnvelopedData EnvelopedData
SignedData SignedData
PKIData PKIData
cmsSequence cmsSequence
SignedData SignedData
PKIResponse PKIResponse
controlSequence controlSequence
One or more requests One or more requests
corresponding to one GL. corresponding to one GL
SignedData SignedData
PKIData PKIData
controlSequence controlSequence
One or more requests One or more requests
corresponding to one GL. corresponding to one GL
Turner 23
Certain combinations of requests in one PKIData.controlSequence and Certain combinations of requests in one PKIData.controlSequence and
one PKIResponse.controlSequence are not allowed. The invalid one PKIResponse.controlSequence are not allowed. The invalid
combinations listed here MUST NOT be generated: combinations listed here MUST NOT be generated:
Invalid Combinations Invalid Combinations
--------------------------- ---------------------------
glUseKEK & glDeleteMember glUseKEK & glDeleteMember
glUseKEK & glRekey glUseKEK & glRekey
glUseKEK & glDelete glUseKEK & glDelete
glDelete & glAddMember glDelete & glAddMember
glDelete & glDeleteMember glDelete & glDeleteMember
glDelete & glRekey glDelete & glRekey
glDelete & glAddOwner glDelete & glAddOwner
glDelete & glRemoveOwner glDelete & glRemoveOwner
To avoid unnecessary errors, certain requests and responses should 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 glAddMember, glRekey as to which to process first: glUseKEK before glAddMember, glRekey
before glAddMember, and glDeleteMember before glRekey. It should be before glAddMember, and glDeleteMember before glRekey. Note that
noted that there is a priority but it does not imply an order. there is a processing priority but it does not imply an ordering
within the content.
3.2.3 GLA Generated Messages 3.2.3 GLA Generated Messages
When the GLA generates a success or fail message, it generates one When the GLA generates a success or fail message, it generates one
for each request. Likewise, when the GLA generates a failure message for each request. SKDFailInfo values of unsupportedDuration,
it generates one for each request. SKDFailInfo values of unsupportedDeliveryMethod, unsupportedAlgorithm, noGLONameMatch,
nameAlreadyInUse, alreadyAnOwner, notAnOwner are not returned to GL
Turner 23 members.
unsupportedDuration, unsupportedDeliveryMethod,
unsupportedAlgorithm, noGLONameMatch, nameAlreadyInUse,
alreadyAnOwner, notAnOwner are not returned to GL members.
If GLKeyAttributes.recipientsNotMutuallyAware is set to FALSE, a If GLKeyAttributes.recipientsNotMutuallyAware is set to FALSE, a
separate PKIResponse.cMCStatusInfoEx, PKIResponse.cMCStatusInfoEx, separate PKIResponse.cMCStatusInfoExand PKIData.glKey MUST be
and PKIData.glKey MUST be generated for each recipient. It is valid generated for each recipient. However, it is valid to send one
to send one message with multiple attributes to the same recipient. message with multiple attributes to the same recipient.
If the GL has multiple GLOs, the GLA MUST send cMCStatusInfoEx If the GL has multiple GLOs, the GLA MUST send cMCStatusInfoEx
messages to the requesting GLO. The mechanism to determine which GLO messages to the requesting GLO. The mechanism to determine which GLO
made the request is beyond the scope of this document. made the request is beyond the scope of this document.
Turner 24
If a GL is managed and the GLA receives a glAddMember, If a GL is managed and the GLA receives a glAddMember,
glDeleteMember, or glkCompromise message, the GLA redirects the glDeleteMember, or glkCompromise message, the GLA redirects the
request to the GLO for review. An additional, SignedData MUST be request to the GLO for review. An additional, SignedData MUST be
applied to the redirected request as follows: applied to the redirected request as follows:
GLA Forwarded Requests GLA Forwarded Requests
---------------------- ----------------------
SignedData SignedData
PKIData PKIData
cmsSequence cmsSequence
SignedData
PKIData PKIData
controlSequence controlSequence
3.2.4 CMC Control Attributes 3.2.4 CMC Control Attributes
Certain control attributes defined in CMC [3] are allowed; they are Certain control attributes defined in CMC [3] are allowed; they are
as follows: cMCStatusInfoEx transactionId, senderNonce, as follows: cMCStatusInfoEx transactionId, senderNonce,
recipientNonce, and queryPending. recipientNonce, and queryPending.
3.2.4.1 Using cMCStatusInfoEx 3.2.4.1 Using cMCStatusInfoEx
cMCStatusInfoEx is used by GLAs to indicate to GLOs and GL members cMCStatusInfoEx is used by GLAs to indicate to GLOs and GL members
that a request was unsuccessful. Two classes of failure codes are that a request was unsuccessful. Two classes of failure codes are
used within this document. Errors from the CMCFailInfo list, found used within this document. Errors from the CMCFailInfo list, found
in section 5.1.4 of CMC, are encoded as defined in CMC. Error codes in section 5.1.4 of CMC, are encoded as defined in CMC. Error codes
defined in this document are encoded using the ExtendedFailInfo defined in this document are encoded using the ExtendedFailInfo
field of the cmcStatusInfoEx structure. If the same failure code field of the cmcStatusInfoEx structure. If the same failure code
applies to multiple commands, a single cmcStatusInfoEx structure can applies to multiple commands, a single cmcStatusInfoEx structure can
be used with multiple items in cMCStatusInfoEx.bodyList. The GLA may be used with multiple items in cMCStatusInfoEx.bodyList. The GLA MAY
also return other pertinent information in statusString. The also return other pertinent information in statusString. The
SKDFailInfo object identifier and value is: SKDFailInfo object identifier and value are:
id-cet-skdFailInfo OBJECT IDENTIFIER ::= { iso(1) id-cet-skdFailInfo OBJECT IDENTIFIER ::= { iso(1)
identified-organization(3) dod(6) internet(1) security(5) identified-organization(3) dod(6) internet(1) security(5)
mechanisms(5) pkix(7) cet(15) skdFailInfo(1) } mechanisms(5) pkix(7) cet(15) skdFailInfo(1) }
Turner 24 Turner 25
SKDFailInfo ::= INTEGER { SKDFailInfo ::= INTEGER {
unspecified (0), unspecified (0),
closedGL (1), closedGL (1),
unsupportedDuration (2), unsupportedDuration (2),
noGLACertificate (3), noGLACertificate (3),
invalidCert (4), invalidCert (4),
unsupportedAlgorithm (5), unsupportedAlgorithm (5),
noGLONameMatch (6), noGLONameMatch (6),
invalidGLName (7), invalidGLName (7),
nameAlreadyInUse (8), nameAlreadyInUse (8),
noSpam (9), noSpam (9),
deniedAccess (10), deniedAccess (10),
alreadyAMember (11), alreadyAMember (11),
notAMember (12), notAMember (12),
alreadyAnOwner (13), alreadyAnOwner (13),
notAnOwner (14) } notAnOwner (14) }
The values have the following meaning: The values have the following meaning:
- unspecified indicates that the GLA is unable or unwilling to - unspecified indicates that the GLA is unable or unwilling to
perform the requested action and does not want to indicate why. perform the requested action and does not want to indicate the
reason.
- closedGL indicates that members can only be added or deleted by - closedGL indicates that members can only be added or deleted by
the GLO. the GLO.
- unsupportedDuration indicates the GLA does not support - 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.
- noGLACertificate indicates that the GLA does not have a valid - noGLACertificate indicates that the GLA does not have a valid
certificate. certificate.
- invalidCert indicates the member's encryption certificate was - invalidCert indicates the member's encryption certificate was
not verifiable (i.e., signature did not validate, certificateĘs not verifiable (i.e., signature did not validate, certificateĘs
serial number present on a CRL, etc.). serial number present on a CRL, expired, etc.).
- unsupportedAlgorithm indicates the GLA does not support the - unsupportedAlgorithm indicates the GLA does not support the
requested algorithm. requested algorithm.
- noGLONameMatch indicates that one of the names in the - noGLONameMatch indicates that one of the names in the
certificate used to sign a request does not match the name of a certificate used to sign a request does not match the name of a
registered GLO. registered GLO.
- 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.
- nameAlreadyInUse indicates the glName is already assigned on the - nameAlreadyInUse indicates the glName is already assigned on the
GLA. 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 glMember.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 (either the subject distinguished name or
request).
Turner 26
one of the subject alternative names) in the certificate used to
sign the request).
Turner 25
- alreadyAMember indicates the prospective GL member is already a - alreadyAMember indicates the prospective GL member is already a
GL member. GL member.
- notAMember indicates the prospective non-GL member is not a GL - notAMember indicates the prospective GL member to be deleted is
member. not presently a GL member.
- alreadyAnOwner indicates the prospective GLO is already a GLO. - alreadyAnOwner indicates the prospective GLO is already a GLO.
- notAnOwner indicates the prospective non-GLO is not a GLO. - notAnOwner indicates the prospective GLO to be deleted is not
presently a GLO.
cMCStatusInfoEx is used by GLAs to indicate to GLOs and GL members cMCStatusInfoEx is used by GLAs to indicate to GLOs and GL members
that a request was successfully completed. If the request was that a request was successfully completed. If the request was
successful, the GLA returns a cMCStatusInfoEx response with successful, the GLA returns a cMCStatusInfoEx response with
cMCStatus.success and optionally other pertinent information in cMCStatus.success and optionally other pertinent information in
stutsString. statusString.
When the GL is managed and the GLO has reviewed GL member initiated When the GL is managed and the GLO has reviewed GL member initiated
glAddMember, glDeleteMember, and glkComrpomise requests, the GLO glAddMember, glDeleteMember, and glkComrpomise requests, the GLO
uses cMCStatusInfoEx to indicate the success or failure of the uses cMCStatusInfoEx to indicate the success or failure of the
request. If the request is allowed, cMCStatus.success is returned request. If the request is allowed, cMCStatus.success is returned
and statusString is optionally returned to convey additional and statusString is optionally returned to convey additional
information. If the request is denied, cMCStatus.failed is returned information. If the request is denied, cMCStatus.failed is returned
and statusString is optionally returned to convey additional and statusString is optionally returned to convey additional
information. Additionally, the appropriate SKDFailInfo can be information. Additionally, the appropriate SKDFailInfo can be
included in cMCStatusInfoEx.extendedFailInfo. included in cMCStatusInfoEx.extendedFailInfo.
cMCStatusInfoEx is used by GLOs, GLAs, and GL members to indicate cMCStatusInfoEx is used by GLOs, GLAs, and GL members to indicate
that signature verification failed. If the signature failed to that signature verification failed. If the signature failed to
verify over any control attibute except a cMCStatusInfoEx, a verify over any control attibute except a cMCStatusInfoEx, a
cMCStatusInfoEx control attribute MUST be returned indicating cMCStatusInfoEx control attribute MUST be returned indicating
cMCStatus.failed and otherInfo.failInfo.badMessageCheck. If the cMCStatus.failed and otherInfo.failInfo.badMessageCheck. If the
signature over the outermost PKIData failed, the bodyList value is signature over the outermost PKIData failed, the bodyList value is
zero (0). If the signature over any other PKIData failed the zero (0). If the signature over any other PKIData failed the
bodyList value is the bodyPartId value from the request or response. bodyList value is the bodyPartId value from the request or response.
GLOs and GL members who receive cMCStatusInfoEx messages whose
signatures are invalid SHOULD generate a new request to avoid
badMessageCheck message loops.
cMCStatusInfoEx is also used by GLOs and GLAs to indicate that a cMCStatusInfoEx is also used by GLOs and GLAs to indicate that a
request could not be performed immediately. If the request could not request could not be performed immediately. If the request could not
be processed immediately by the GLA or GLO, the cMCStatusInfoEx be processed immediately by the GLA or GLO, the cMCStatusInfoEx
control attribute MUST be returned indicating cMCStatus.pending and control attribute MUST be returned indicating cMCStatus.pending and
otherInfo.pendInfo. When requests are redirected to the GLO for otherInfo.pendInfo. When requests are redirected to the GLO for
approval (for managed lists), the GLA MUST NOT return a approval (for managed lists), the GLA MUST NOT return a
cMCStatusInfoEx indicating query pending. cMCStatusInfoEx indicating query pending.
cMCStatusInfoEx is also used by GLAs to indicate that a cMCStatusInfoEx is also used by GLAs to indicate that a
glaQueryRequest is not supported. If the glaQueryRequest is not glaQueryRequest is not supported. If the glaQueryRequest is not
Turner 27
supported, the cMCStatusInfoEx control attribute MUST be returned supported, the cMCStatusInfoEx control attribute MUST be returned
indicating cMCStatus.noSupport and statusString is optionally indicating cMCStatus.noSupport and statusString is optionally
returned to convey additional information. returned to convey additional information.
Turner 26
3.2.4.2 Using transactionId 3.2.4.2 Using transactionId
transactionId MAY be included by GLOs, GLAs, or GL members to transactionId MAY be included by GLOs, GLAs, or GL members to
identify a given transaction. All subsequent requests and responses identify a given transaction. All subsequent requests and responses
related to the original request MUST include the same transactionId related to the original request MUST include the same transactionId
control attribute. If GL members include a transactionId and the control attribute. If GL members include a transactionId and the
request is redirected to the GLO, the GLA MAY include an additional request is redirected to the GLO, the GLA MAY include an additional
transactionId in the outer PKIData. If the GLA included an transactionId in the outer PKIData. If the GLA included an
additional transactionId in the outer PKIData, when the GLO additional transactionId in the outer PKIData, when the GLO
generates a cMCStatusInfoEx response it generates one for the GLA generates a cMCStatusInfoEx response it generates one for the GLA
skipping to change at line 1313 skipping to change at line 1374
3.2.4.3 Using nonces 3.2.4.3 Using nonces
The use of nonces (see section 5.6 of [3]) can be used to provide The use of nonces (see section 5.6 of [3]) can be used to provide
application-level replay prevention. If the originating message application-level replay prevention. If the originating message
includes a senderNonce, the response to the message MUST include the includes a senderNonce, the response to the message MUST include the
received senderNonce value as the recipientNonce and a new value as received senderNonce value as the recipientNonce and a new value as
the senderNonce value in the response. the senderNonce value in the response.
If a GLA aggratates multiple messages together or forwards a message If a GLA aggratates multiple messages together or forwards a message
to a GLO, the GLA can optionally generate a new nonce value and to a GLO, the GLA MAY optionally generate a new nonce value and
include that in the wrapping message. When the response comes back include that in the wrapping message. When the response comes back
from the GLO, the GLA builds a response to the originator(s) of the from the GLO, the GLA builds a response to the originator(s) of the
message(s) and deals with each of the nonce values from the message(s) and deals with each of the nonce values from the
originating messages. originating messages.
3.2.4.4 CMC Attribute Support Requirements 3.2.4.4 CMC Attribute Support Requirements
The following are the implementation requirements for CMC control The following are the implementation requirements for CMC control
attributes for an implementation be considered conformant to this attributes for an implementation be considered conformant to this
specification: specification:
skipping to change at line 1336 skipping to change at line 1397
Implementation Requirement | Control Implementation Requirement | Control
GLO | GLA | GL Member | Attribute GLO | GLA | GL Member | Attribute
O R | O R F | O R | O R | O R F | O R |
--------- | ------------- | --------- | ---------- --------- | ------------- | --------- | ----------
MUST MUST | MUST MUST - | MUST MUST | cMCStatusinfoEx MUST MUST | MUST MUST - | MUST MUST | cMCStatusinfoEx
MAY MAY | MAY MAY - | MAY MAY | transactionId MAY MAY | MAY MAY - | MAY MAY | transactionId
MAY MAY | MAY MAY - | MAY MAY | senderNonce MAY MAY | MAY MAY - | MAY MAY | senderNonce
MAY MAY | MAY MAY - | MAY MAY | recepientNonce MAY MAY | MAY MAY - | MAY MAY | recepientNonce
MUST MUST | MUST MUST - | MUST MUST | SKDFailInfo MUST MUST | MUST MUST - | MUST MUST | SKDFailInfo
Turner 27 Turner 28
3.2.5 Resubmitted GL Member Messages 3.2.5 Resubmitted GL Member Messages
When the GL is managed, the GLA forwards the GL member requests to When the GL is managed, the GLA forwards the GL member requests to
the GLO for GLO approval by creating a new request message the GLO for GLO approval by creating a new request message
containing the GL member request(s) as a cmsSequence item. If the containing the GL member request(s) as a cmsSequence item. If the
GLO approves the request it can either add a new layer of wrapping GLO approves the request it can either add a new layer of wrapping
and send it back to the GLA or create a new message sends it to the and send it back to the GLA or create a new message and send it to
GLA. (Note in this case there are now 3 layers of PKIData messages the GLA. (Note in this case there are now 3 layers of PKIData
with appropriate signing layers.) messages with appropriate signing layers.)
3.2.6 PKIX 3.2.6 PKIX Certificate and CRL Profile
Signatures, certificates, and CRLs are verified according to PKIX Signatures, certificates, and CRLs are verified according to the
[5]. PKIX profile [5].
Name matching is performed according to PKIX [5]. Name matching is performed according to the PKIX profile [5].
All distinguished name forms must follow the UTF8String convention All distinguished name forms must follow the UTF8String convention
noted in PKIX [5]. noted in the PKIX profile [5].
A certificate per-GL would be issued to the GLA. A certificate per-GL would be issued to the GLA.
GL policy may mandate that the GL memberĘs address be included in GL policy may mandate that the GL memberĘs address be included in
the GL memberĘs certificate. the GL memberĘs certificate.
4 Administrative Messages 4 Administrative Messages
There are a number of administrative messages that must be performed There are a number of administrative messages that must be performed
to manage a GL. The following sections describe each of messages' to manage a GL. The following sections describe each request and
request and response combinations in detail. The procedures defined response message combination in detail. The procedures defined in
in this section are not prescriptive. this section are not prescriptive.
4.1 Assign KEK To GL 4.1 Assign KEK To GL
Prior to generating a group key, a GL MUST be setup and a shared KEK Prior to generating a group key, a GL needs to be setup and a shared
assigned to the GL. Figure 3 depicts the protocol interactions to KEK assigned to the GL. Figure 3 depicts the protocol interactions
setup and assign a shared KEK. Note that error messages are not to setup and assign a shared KEK. Note that error messages are not
depicted in Figure 3. depicted in Figure 3.
+-----+ 1 2 +-----+ +-----+ 1 2 +-----+
| GLA | <-------> | GLO | | GLA | <-------> | GLO |
+-----+ +-----+ +-----+ +-----+
Figure 3 - Create Group List Figure 3 - Create Group List
Turner 29
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
Turner 28
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, glAddress, (1 in Figure 3). The GLO MUST include: glName, glAddress,
glOwnerName, glOwnerAddress, and glAdministration. The GLO MAY glOwnerName, glOwnerAddress, and glAdministration. The GLO MAY
also include their preferences for the shared KEK in also include their preferences for the shared KEK in
glKeyAttributes by indicating whether the GLO controls the glKeyAttributes by indicating whether the GLO controls the
rekey in rekeyControlledByGLO, whether separate glKey messages rekey in rekeyControlledByGLO, whether separate glKey messages
should be sent to each recipient in should be sent to each recipient in
recipientsNotMutuallyAware, the requested algorithm to be used recipientsNotMutuallyAware, the requested algorithm to be used
with the shared KEK in requestedAlgorithm, the duration of the with the shared KEK in requestedAlgorithm, the duration of the
shared KEK, and how many shared KEKs should be initially shared KEK, and how many shared KEKs should be initially
distributed in generationCounter. distributed in generationCounter.
1.a - If the GLO knows of members to be added to the GL, the 1.a - If the GLO knows of members to be added to the GL, the
glAddMember request(s) MAY be included in the same glAddMember request(s) MAY be included in the same
controlSequence as the glUseKEK request (see section 3.2.2). controlSequence as the glUseKEK request (see section 3.2.2).
The GLO MUST indicate the same glName in the glAddMember The GLO indicates the same glName in the glAddMember request
request as in glUseKEK.glInfo.glName. Further glAddMember as in glUseKEK.glInfo.glName. Further glAddMember procedures
procedures are covered in section 4.3. are covered in section 4.3.
1.b - The GLO MAY optionally apply confidentiality to the request 1.b - The GLO can apply confidentiality to the request by
by encapsulating the SignedData.PKIData in an EnvelopedData encapsulating the SignedData.PKIData in an EnvelopedData
(see section 3.2.1.2). (see section 3.2.1.2).
1.c - The GLO MAY also optionally apply another SignedData over 1.c - The GLO can also optionally apply another SignedData over
the EnvelopedData (see section 3.2.1.2). the EnvelopedData (see section 3.2.1.2).
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 sections and/or EnvelopedData encapsulates the request (see sections
3.2.1.2 and 3.2.2), the GLA MUST verify the outer signature(s) 3.2.1.2 and 3.2.2), the GLA verifies the outer signature(s)
and/or decrypt the outer layer(S) 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.
2.a - If the signatures do not verify, the GLA MUST return a 2.a - If the signatures do not verify, the GLA returns a
cMCStatusInfoEx response indicating cMCStatus.failed and cMCStatusInfoEx response indicating cMCStatus.failed and
otherInfo.failInfo.badMessageCheck. otherInfo.failInfo.badMessageCheck.
2.b ū Else if the signatures do verify but the GLA does not have a 2.b ū Else if the signatures do verify but the GLA does not have a
valid certificate, the GLA MUST return a cMCStatusInfoEx valid certificate, the GLA returns a cMCStatusInfoEx with
with cMCStatus.failed and cMCStatus.failed and otherInfo.extendedFailInfo.SKDFailInfo
otherInfo.extendedFailInfo.SKDFailInfo value of value of noValidGLACertificate. Instead of immediately
noValidGLACertificate. Instead of immediately returning the returning the error code, the GLA attempts to get a
error code, the GLA MAY attempt to get a certificate, certificate, possibly using CMC [3].
possibly using CMC [3].
2.c - Else the signatures do verify and the GLA does have a valid 2.c - Else the signatures are valid and the GLA does have a valid
certificate, the GLA MUST check that one of the names in the certificate, the GLA checks that one of the names in the
certificate used to sign the request matches one of the certificate used to sign the request matches one of the
names in glUseKEK.glOwnerInfo.glOwnerName. names in glUseKEK.glOwnerInfo.glOwnerName.
2.c.1 - If the names do not match, the GLA MUST return a response Turner 30
2.c.1 - If the names do not match, the GLA returns a response
indicating cMCStatusInfoEx with cMCStatus.failed and indicating cMCStatusInfoEx with cMCStatus.failed and
Turner 29
otherInfo.extendedFailInfo.SKDFailInfo value of otherInfo.extendedFailInfo.SKDFailInfo value of
noGLONameMatch. noGLONameMatch.
2.c.2 - Else names do all match, the GLA MUST check that the 2.c.2 - Else if the names all match, the GLA checks that the
glName and glAddress is not already in use. The GLA MUST glName and glAddress is not already in use. The GLA also
also check any glAddMember included within the checks any glAddMember included within the controlSequence
controlSequence with this glUseKEK. Further processing of with this glUseKEK. Further processing of the glAddMember
the glAddMember is covered in section 4.3. is covered in section 4.3.
2.c.2.a - If the glName is already in use the GLA MUST return a 2.c.2.a - If the glName is already in use the GLA returns a
response indicating cMCStatusInfoEx with response indicating cMCStatusInfoEx with
cMCStatus.failed and cMCStatus.failed and
otherInfo.extendedFailInfo.SKDFailInfo value of otherInfo.extendedFailInfo.SKDFailInfo value of
nameAlreadyInUse. nameAlreadyInUse.
2.c.2.b - Else the requestedAlgorithm is not supported, the GLA 2.c.2.b - Else if the requestedAlgorithm is not supported, the GLA
MUST return a response indicating cMCStatusInfoEx with returns a response indicating cMCStatusInfoEx with
cMCStatus.failed and cMCStatus.failed and
otherInfo.extendedFailInfo.SKDFailInfo value of otherInfo.extendedFailInfo.SKDFailInfo value of
unsupportedAlgorithm. unsupportedAlgorithm.
2.c.2.c - Else the duration is not supportable, determining this 2.c.2.c - Else if the duration cannot be supported, determining
is beyond the scope of this document, the GLA MUST this is beyond the scope of this document, the GLA
return a response indicating cMCStatusInfoEx with returns a response indicating cMCStatusInfoEx with
cMCStatus.failed and cMCStatus.failed and
otherInfo.extendedFailInfo.SKDFailInfo value of otherInfo.extendedFailInfo.SKDFailInfo value of
unsupportedDuration. unsupportedDuration.
2.c.2.d - Else the GL is not supportable for other reasons, which 2.c.2.d - Else if the GL cannot be supported for other reasons,
the GLA does not wish to disclose, the GLA MUST return a which the GLA does not wish to disclose, the GLA returns
response indicating cMCStatusInfoEx with a response indicating cMCStatusInfoEx with
cMCStatus.failed and cMCStatus.failed and
otherInfo.extendedFailInfo.SKDFailInfo value of otherInfo.extendedFailInfo.SKDFailInfo value of
unspecified. unspecified.
2.c.2.e - Else the glName is not already in use, the duration is 2.c.2.e - Else if the glName is not already in use, the duration
supportable, and the requestedAlgorithm is supported, can be supported, and the requestedAlgorithm is
the GLA MUST return a cMCStatusInfoEx indicating supported, the GLA MUST return a cMCStatusInfoEx
cMCStatus.success (2 in Figure 3). The GLA also takes indicating cMCStatus.success (2 in Figure 3). The GLA
administrative actions, which are beyond the scope of also takes administrative actions, which are beyond the
this document, to store the glName, glAddress, scope of this document, to store the glName, glAddress,
glKeyAttributes, glOwnerName, and glOwnerAddress. The glKeyAttributes, glOwnerName, and glOwnerAddress. The
GLA also sends a glKey message as described in section GLA also sends a glKey message as described in section
5. 5.
2.c.2.e.1 - The GLA MUST apply confidentiality to the response by 2.c.2.e.1 - The GLA can 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 section 3.2.1.2). EnvelopedData (see section 3.2.1.2).
2.c.2.e.2 - The GLA MAY also optionally apply another SignedData Turner 31
2.c.2.e.2 - The GLA can also optionally apply another SignedData
over the EnvelopedData (see section 3.2.1.2). over the EnvelopedData (see section 3.2.1.2).
Turner 30
3 - Upon receipt of the cMCStatusInfoEx responses, the GLO 3 - Upon receipt of the cMCStatusInfoEx responses, the GLO
verifies the GLA's signature(s). If an additional SignedData verifies the GLA signature(s). If an additional SignedData
and/or EnvelopedData encapsulates the response (see section and/or EnvelopedData encapsulates the response (see section
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 verifies the outer signature and/or
and/or decrypt the outer layer prior to verifying the decrypt the outer layer prior to verifying the signature on
signature on the inner most SignedData. the inner most SignedData.
3.a - Else the signatures do verify, the GLO MUST check that one 3.a - If the signatures do verify, the GLO MUST check that one of
of the names in the certificate used to sign the response the names in the certificate used to sign the response
matches the name of the GL. matches the name of the GL.
3.a.1 ū If the GLĘs name does not match the name present in the 3.a.1 ū If the name of the GL does not match the name present in
certificate used to sign the message, the GLO should not the certificate used to sign the message, the GLO should
believe the response. not believe the response.
3.a.2 ū Else the GLĘs name does match the name present in the 3.a.2 ū Else if the name of the GL does match the name present in
certificate and: the certificate and:
3.a.2.a - If the signatures do verify and the response was 3.a.2.a - If the signatures do verify and the response was
cMCStatusInfoEx indicating cMCStatus.success, the GLO cMCStatusInfoEx indicating cMCStatus.success, the GLO
has successfully created the GL. has successfully created the GL.
3.a.2.b - Else the signatures do verify and the response was 3.a.2.b - Else if the signatures are valid and the response is
cMCStatusInfoEx.cMCStatus.failed for any reason, the GLO cMCStatusInfoEx.cMCStatus.failed with any reason, the
MAY reattempt to create the GL using the information GLO can reattempt to create the GL using the information
provided in the response. The GLO may also use the provided in the response. The GLO can also use the
glaQueryRequest to determine the algorithms and other glaQueryRequest to determine the algorithms and other
characteristics supported by the GLA (see section 4.9). characteristics supported by the GLA (see section 4.9).
4.2 Delete GL From GLA 4.2 Delete GL From GLA
From time to time, there are instances when a GL is no longer 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 deletes the GL. Figure 4 depicts that
that protocol interactions to delete a GL. 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 responsible for requesting the deletion of the GL.
of the GL. The GLO sends a The GLO sends a SignedData.PKIData.controlSequence.glDelete
SignedData.PKIData.controlSequence.glDelete request to the GLA
(1 in Figure 4). The name of the GL to be deleted MUST be
included in GeneralName.
Turner 31 Turner 32
1.a - The GLO MAY optionally apply confidentiality to the request request to the GLA (1 in Figure 4). The name of the GL to be
deleted is included in GeneralName.
1.a - The GLO can optionally apply confidentiality to the request
by encapsulating the SignedData.PKIData in an EnvelopedData by encapsulating the SignedData.PKIData in an EnvelopedData
(see section 3.2.1.2). (see section 3.2.1.2).
1.b - The GLO MAY also optionally apply another SignedData over 1.b - The GLO MAY can also optionally apply another SignedData
the EnvelopedData (see section 3.2.1.2). over the EnvelopedData (see section 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 section and/or EnvelopedData encapsulates the request (see section
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 verifies the outer signature and/or
and/or decrypt the outer layer prior to verifying the decrypt the outer layer prior to verifying the signature on
signature on the inner most SignedData. the inner most SignedData.
2.a - If the signatures do not verify, the GLA MUST return a 2.a - If the signatures cannot be verified, the GLA returns a
cMCStatusInfoEx response indicating cMCStatus.failed and cMCStatusInfoEx response indicating cMCStatus.failed and
otherInfo.failInfo.badMessageCheck. otherInfo.failInfo.badMessageCheck.
2.b - Else the signatures do verify, the GLA MUST make sure the GL 2.b - Else if the signatures verify, the GLA makes sure the GL is
is supported by checking the GLĘs Name matches a glName supported by checking the name of the GL matches a glName
stored on the GLA. stored on the GLA.
2.b.1 - If the glName is not supported by the GLA, the GLA MUST 2.b.1 - If the glName is not supported by the GLA, the GLA returns
return a response indicating cMCStatusInfoEx with a response indicating cMCStatusInfoEx with
cMCStatus.failed and cMCStatus.failed and
otherInfo.extendedFailInfo.SKDFailInfo value of otherInfo.extendedFailInfo.SKDFailInfo value of
invalidGLName. invalidGLName.
2.b.2 - Else the glName is supported by the GLA, the GLA MUST 2.b.2 - Else if the glName is supported by the GLA, the GLA
ensure a registered GLO signed the glDelete request by ensures a registered GLO signed the glDelete request by
checking if one of the names present in the digital checking if one of the names present in the digital
signature certificate used to sign the glDelete request signature certificate used to sign the glDelete request
matches a registered GLO. matches a registered GLO.
2.b.2.a - If the names do not match, the GLA MUST return a 2.b.2.a - If the names do not match, the GLA returns a response
response indicating cMCStatusInfoEx with indicating cMCStatusInfoEx with cMCStatus.failed and
cMCStatus.failed and
otherInfo.extendedFailInfo.SKDFailInfo value of otherInfo.extendedFailInfo.SKDFailInfo value of
noGLONameMatch. noGLONameMatch.
2.b.2.b - Else the names do match but the GL is not deletable for 2.b.2.b - Else if the names do match, but the GL cannot be deleted
other reasons, which the GLA does not wish to disclose, for other reasons, which the GLA does not wish to
the GLA MUST return a response indicating disclose, the GLA returns a response indicating
cMCStatusInfoEx with cMCStatus.failed and cMCStatusInfoEx with cMCStatus.failed and
otherInfo.extendedFailInfo.SKDFailInfo value of otherInfo.extendedFailInfo.SKDFailInfo value of
unspecified. Actions beyond the scope of this document unspecified. Actions beyond the scope of this document
must then be taken to delete the GL from the GLA. must then be taken to delete the GL from the GLA.
2.b.2.c - Else the names do match, the GLA MUST return a 2.b.2.c - Else if the names do match, the GLA returns a
cMCStatusInfoEx indicating cMCStatus.success (2 in cMCStatusInfoEx indicating cMCStatus.success (2 in
Figure 4). The GLA MUST not accept further requests for
Turner 32 Turner 33
Figure 4). The GLA ought not accept further requests for
member additions, member deletions, or group rekeys for member additions, member deletions, or group rekeys for
this GL. this GL.
2.b.2.c.1 - The GLA MUST apply confidentiality to the response by 2.b.2.c.1 - The GLA can 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 section 3.2.1.2). EnvelopedData (see section 3.2.1.2).
2.b.2.c.2 - The GLA MAY also optionally apply another SignedData 2.b.2.c.2 - The GLA MAY can also optionally apply another
over the EnvelopedData (see section 3.2.1.2). SignedData over the EnvelopedData (see section
3.2.1.2).
3 - Upon receipt of the cMCStatusInfoEx response, the GLO verifies 3 - Upon receipt of the cMCStatusInfoEx response, the GLO verifies
the GLA's signature(s). If an additional SignedData and/or the GLA signature(s). If an additional SignedData and/or
EnvelopedData encapsulates the response (see section 3.2.1.2 EnvelopedData encapsulates the response (see section 3.2.1.2
or 3.2.2), the GLO MUST verify the outer signature and/or or 3.2.2), the GLO verifies the outer signature and/or decrypt
decrypt the outer layer prior to verifying the signature on the outer layer prior to verifying the signature on the inner
the inner most SignedData. most SignedData.
3.a - Else the signatures do verify, the GLO MUST check that one 3.a - If the signatures verify, the GLO checks that one of the
of the names in the certificate used to sign the response names in the certificate used to sign the response matches
matches the name of the GL. the name of the GL.
3.a.1 ū If the GLĘs name does not match the name present in the 3.a.1 ū If the name of the GL does not match the name present in
certificate used to sign the message, the GLO should not the certificate used to sign the message, the GLO should
believe the response. not believe the response.
3.a.2 ū Else the GLĘs name does match the name present in the 3.a.2 ū Else if the name of the GL does match the name present in
certificate and: the certificate and:
3.a.2.a - If the signatures do verify and the response was 3.a.2.a - If the signatures verify and the response was
cMCStatusInfoEx indicating cMCStatus.success, the GLO cMCStatusInfoEx indicating cMCStatus.success, the GLO
has successfully deleted the GL. has successfully deleted the GL.
3.a.2.b - Else the signatures do verify and the response was 3.a.2.b - Else if the signatures do verify and the response was
cMCStatusInfoEx.cMCStatus.failed for any reason, the GLO cMCStatusInfoEx.cMCStatus.failed with any reason, the
MAY reattempt to delete the GL using the information GLO can reattempt to delete the GL using the information
provided in the response. provided in the response.
4.3 Add Members To GL 4.3 Add Members To GL
To add members to GLs, either the GLO or prospective members use the To add members to GLs, either the GLO or prospective members use the
glAddMember request. The GLA processes GLO and prospective GL member glAddMember request. The GLA processes GLO and prospective GL member
requests differently though. GLOs can submit the request at any time requests differently though. GLOs can submit the request at any time
to add members to the GL, and the GLA, once it has verified the to add members to the GL, and the GLA, once it has verified the
request came from a registered GLO, should process it. If a request came from a registered GLO, should process it. If a
prospective member sends the request, the GLA needs to determine how prospective member sends the request, the GLA needs to determine how
the GL is administered. When the GLO initially configured the GL, the GL is administered. When the GLO initially configured the GL,
they set the GL to be unmanaged, managed, or closed (see section they set the GL to be unmanaged, managed, or closed (see section
3.1.1). In the unmanaged case, the GLA merely processes the memberĘs 3.1.1). In the unmanaged case, the GLA merely processes the memberĘs
Turner 34
request. For the managed case, the GLA forwards the requests from request. For the managed case, the GLA forwards the requests from
the prospective members to the GLO for review. Where there are the prospective members to the GLO for review. Where there are
Turner 33
multiple GLOs for a GL, which GLO the request is forwarded to is multiple GLOs for a GL, which GLO the request is forwarded to is
beyond the scope of this document. The GLO reviews the request and beyond the scope of this document. The GLO reviews the request and
either rejects it or submits a reformed request to the GLA. In the either rejects it or submits a reformed request to the GLA. In the
closed case, the GLA will not accept requests from prospective closed case, the GLA will not accept requests from prospective
members. The following sections describe the processing for the members. The following sections describe the processing for the
GLO(s), GLA, and prospective GL members depending on where the GLO(s), GLA, and prospective GL members depending on where the
glAddMeber request originated, either from a GLO or from prospective glAddMeber request originated, either from a GLO or from prospective
members. Figure 5 depicts the protocol interactions for the three members. Figure 5 depicts the protocol interactions for the three
options. Note that the error messages are not depicted. options. Note that the error messages are not depicted.
skipping to change at line 1682 skipping to change at line 1740
+-------> | 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
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 MAY be rekeyed to maintain the secrecy of the group. and closed GLs can be rekeyed to maintain the confidentiality of the
An option to rekeying managed or closed GLs when a member is added traffic sent by group members. An option to rekeying managed or
is to generate a new GL with a different group key. Group rekeying closed GLs when a member is added is to generate a new GL with a
is discussed in sections 4.5 and 5. different group key. Group rekeying is discussed in sections 4.5 and
5.
4.3.1 GLO Initiated Additions 4.3.1 GLO Initiated Additions
The process for GLO initiated glAddMember requests is as follows: The process for GLO initiated glAddMember requests is as follows:
1 - The GLO collects the pertinent information for the member(s) 1 - The GLO collects the pertinent information for the member(s)
to be added (this may be done through an out of bands means). to be added (this may be done through an out of bands means).
The GLO then sends a SignedData.PKIData.controlSequence with a The GLO then sends a SignedData.PKIData.controlSequence with a
separate glAddMember request for each member to the GLA (1 in separate glAddMember request for each member to the GLA (1 in
Figure 5). The GLO MUST include: the GL name in glName, the Figure 5). The GLO includes: the GL name in glName, the
member's name in glMember.glMemberName, the memberĘs address member's name in glMember.glMemberName, the memberĘs address
in glMember.glMemberAddress, and the member's encryption in glMember.glMemberAddress, and the member's encryption
certificate in glMember.certificates.pKC. The GLO MAY also certificate in glMember.certificates.pKC. The GLO can also
include any attribute certificates associated with the include any attribute certificates associated with the
memberĘs encryption certificate in glMember.certificates.aC, memberĘs encryption certificate in glMember.certificates.aC,
Turner 35
and the certification path associated with the memberĘs and the certification path associated with the memberĘs
encryption and attribute certificates in encryption and attribute certificates in
glMember.certificates.certificationPath. glMember.certificates.certPath.
Turner 34 1.a - The GLO can 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 section 3.2.1.2). (see section 3.2.1.2).
1.b - The GLO MAY also optionally apply another SignedData over 1.b - The GLO can also optionally apply another SignedData over
the EnvelopedData (see section 3.2.1.2). the EnvelopedData (see section 3.2.1.2).
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 section and/or EnvelopedData encapsulates the request (see section
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 verifies the outer signature and/or
and/or decrypt the outer layer prior to verifying the decrypt the outer layer prior to verifying the signature on
signature on the inner most SignedData. the inner most SignedData.
2.a - If the signatures do not verify, the GLA MUST return a 2.a - If the signatures cannot be verified, the GLA returns a
cMCStatusInfoEx response indicating cMCStatus.failed and cMCStatusInfoEx response indicating cMCStatus.failed and
otherInfo.failInfo.badMessageCheck. otherInfo.failInfo.badMessageCheck.
2.b - Else the signatures do verify, the glAddMember request is 2.b - Else if the signatures verify, the glAddMember request is
included in a controlSequence with the glUseKEK request, and included in a controlSequence with the glUseKEK request, and
the processing in section 4.1 item 2.e is successfully the processing in section 4.1 item 2.e is successfully
completed the GLA MUST return a cMCStatusInfoEx indicating completed the GLA returns a cMCStatusInfoEx indicating
cMCStatus.success (2 in Figure 5). cMCStatus.success (2 in Figure 5).
2.b.1 - The GLA MUST apply confidentiality to the response by 2.b.1 - The GLA can 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
section 3.2.1.2). section 3.2.1.2).
2.b.2 - The GLA MAY also optionally apply another SignedData over 2.b.2 - The GLA can also optionally apply another SignedData over
the EnvelopedData (see section 3.2.1.2). the EnvelopedData (see section 3.2.1.2).
2.c - Else the signatures do verify and the GLAddMember request is 2.c - Else if the signatures verify and the GLAddMember request is
not included in a controlSequence with the GLCreate request, not included in a controlSequence with the GLCreate request,
the GLA MUST make sure the GL is supported by checking that the GLA makes sure the GL is supported by checking that the
the glName matches a glName stored on the GLA. glName matches a glName stored on the GLA.
2.c.1 - If the glName is not supported by the GLA, the GLA MUST 2.c.1 - If the glName is not supported by the GLA, the GLA returns
return a response indicating cMCStatusInfoEx with a response indicating cMCStatusInfoEx with
cMCStatus.failed and cMCStatus.failed and
otherInfo.extendedFailInfo.SKDFailInfo value of otherInfo.extendedFailInfo.SKDFailInfo value of
invalidGLName. invalidGLName.
2.c.2 - Else the glName is supported by the GLA, the GLA MUST 2.c.2 - Else if the glName is supported by the GLA, the GLA checks
check to see if the glMemberName is present on the GL. to see if the glMemberName is present on the GL.
2.c.2.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
return a response indicating cMCStatusInfoEx with returns a response indicating cMCStatusInfoEx with
Turner 36
cMCStatus.failed and cMCStatus.failed and
otherInfo.extendedFailInfo.SKDFailInfo value of otherInfo.extendedFailInfo.SKDFailInfo value of
alreadyAMember. alreadyAMember.
Turner 35 2.c.2.b - Else if the glMemberName is not present on the GL, the
2.c.2.b - Else the glMemberName is not present on the GL, the GLA GLA checks how the GL is administered.
MUST check how the GL is administered.
2.c.2.b.1 - If the GL is closed, the GLA MUST check that a 2.c.2.b.1 - If the GL is closed, the GLA checks that a registered
registered GLO signed the request by checking that one GLO signed the request by checking that one of the
of the names in the digital signature certificate used names in the digital signature certificate used to
to sign the request matches a registered GLO. sign the request matches a registered GLO.
2.c.2.b.1.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 returns a
response indicating cMCStatusInfoEx with response indicating cMCStatusInfoEx with
cMCStatus.failed and cMCStatus.failed and
otherInfo.extendedFailInfo.SKDFailInfo value of otherInfo.extendedFailInfo.SKDFailInfo value of
noGLONameMatch. noGLONameMatch.
2.c.2.b.1.b - Else the names do match, the GLA MUST verify the 2.c.2.b.1.b - Else if the names match, the GLA verifies the
member's encryption certificate. member's encryption certificate.
2.c.2.b.1.b.1 - If the member's encryption certificate does not 2.c.2.b.1.b.1 - If the member's encryption certificate cannot be
verify, the GLA MAY return a response indicating verified, the GLA can return a response indicating
cMCStatusInfoEx with cMCStatus.failed and cMCStatusInfoEx with cMCStatus.failed and
otherInfo.extendedFailInfo.SKDFailInfo value of otherInfo.extendedFailInfo.SKDFailInfo value of
invalidCert to the GLO. If the GLA does not return invalidCert to the GLO. If the GLA does not return
a cMCStatusInfoEx.cMCStatus.failed response, the a cMCStatusInfoEx.cMCStatus.failed response, the
GLA MUST issue a glProvideCert request (see GLA issues a glProvideCert request (see section
section 4.10). 4.10).
2.c.2.b.1.b.2 - Else the member's certificate does verify, the GLA 2.c.2.b.1.b.2 - Else if the member's certificate verifies, the GLA
MUST return a cMCStatusInfoEx indicating returns a cMCStatusInfoEx indicating
cMCStatus.success (2 in Figure 5). The GLA also cMCStatus.success (2 in Figure 5). The GLA also
takes administrative actions, which are beyond the takes administrative actions, which are beyond the
scope of this document, to add the member to the scope of this document, to add the member to the
GL stored on the GLA. The GLA MUST also distribute GL stored on the GLA. The GLA also distributes the
the shared KEK to the member via the mechanism shared KEK to the member via the mechanism
described in section 5. described in section 5.
2.c.2.b.1.b.2.a - The GLA MUST apply confidentiality to the 2.c.2.b.1.b.2.a - The GLA applies confidentiality to the response
response by encapsulating the SignedData.PKIData by encapsulating the SignedData.PKIData in an
in an EnvelopedData if the request was EnvelopedData if the request was encapsulated in
encapsulated in an EnvelopedData (see section an EnvelopedData (see section 3.2.1.2).
3.2.1.2).
2.c.2.b.1.b.2.b - The GLA MAY also optionally apply another 2.c.2.b.1.b.2.b - The GLA can also optionally apply another
SignedData over the EnvelopedData (see section SignedData over the EnvelopedData (see section
3.2.1.2). 3.2.1.2).
2.c.2.b.2 - Else the GL is managed, the GLA MUST check that either 2.c.2.b.2 - Else if the GL is managed, the GLA checks that either
a registered GLO or the prospective member signed the a registered GLO or the prospective member signed the
request. For GLOs, one of the names in the certificate request. For GLOs, one of the names in the certificate
used to sign the request MUST match a registered GLO. used to sign the request needs to match a registered
For the prospective member, the name in
Turner 36 Turner 37
glMember.glMemberName MUST match one of the names in GLO. For the prospective member, the name in
the certificate used to sign the request. glMember.glMemberName needs to match one of the names
in the certificate used to sign the request.
2.c.2.b.2.a - If the signer is neither a registered GLO nor the 2.c.2.b.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 returns a response
response indicating cMCStatusInfoEx with indicating cMCStatusInfoEx with cMCStatus.failed and
cMCStatus.failed and
otherInfo.extendedFailInfo.SKDFailInfo value of otherInfo.extendedFailInfo.SKDFailInfo value of
noSpam. noSpam.
2.c.2.b.2.b - Else the signer is a registered GLO, the GLA MUST 2.c.2.b.2.b ū Else if the signer is a registered GLO, the GLA
verify the member's encryption certificate. verifies the member's encryption certificate.
2.c.2.b.2.b.1 - If the member's certificate does not verify, the 2.c.2.b.2.b.1 - If the member's certificate cannot be verified,
GLA MAY return a response indicating the GLA can return a response indicating
cMCStatusInfoEx with cMCStatus.failed and cMCStatusInfoEx with cMCStatus.failed and
otherInfo.extendedFailInfo.SKDFailInfo value of otherInfo.extendedFailInfo.SKDFailInfo value of
invalidCert. If the GLA does not return a invalidCert. If the GLA does not return a
cMCStatus.failed response, the GLA MUST issue a cMCStatus.failed response, the GLA MUST issue a
glProvideCert request (see section 4.10). glProvideCert request (see section 4.10).
2.c.2.b.2.b.2 - Else the member's certificate does verify, the GLA 2.c.2.b.2.b.2 - Else if the member's certificate verifies, the GLA
MUST return a cMCStatusInfoEx indicating MUST return a cMCStatusInfoEx indicating
cMCStatus.success to the GLO (2 in Figure 5). The cMCStatus.success to the GLO (2 in Figure 5). The
GLA also takes administrative actions, which are GLA also takes administrative actions, which are
beyond the scope of this document, to add the beyond the scope of this document, to add the
member to the GL stored on the GLA. The GLA MUST member to the GL stored on the GLA. The GLA also
also distribute the shared KEK to the member via distributes the shared KEK to the member via the
the mechanism described in section 5. The GL mechanism described in section 5. The GL policy
policy may mandate that the GL memberĘs address be may mandate that the GL memberĘs address be
included in the GL memberĘs certificate. included in the GL memberĘs certificate.
2.c.2.b.2.b.2.a - The GLA MUST apply confidentiality to the 2.c.2.b.2.b.2.a - The GLA applies confidentiality to the response
response by encapsulating the SignedData.PKIData by encapsulating the SignedData.PKIData in an
in an EnvelopedData if the request was EnvelopedData if the request was encapsulated in
encapsulated in an EnvelopedData (see section an EnvelopedData (see section 3.2.1.2).
3.2.1.2).
2.c.2.b.2.b.2.b - The GLA MAY also optionally apply another 2.c.2.b.2.b.2.b - The GLA can also optionally apply another
SignedData over the EnvelopedData (see section SignedData over the EnvelopedData (see section
3.2.1.2). 3.2.1.2).
2.c.2.b.2.c - Else the signer is the prospective member, the GLA 2.c.2.b.2.c - Else if the signer is the prospective member, the
MUST forward the glAddMember request (see section GLA forwards the glAddMember request (see section
3.2.3) to a registered GLO (B{A} in Figure 5). If 3.2.3) to a registered GLO (B{A} in Figure 5). If
there is more than one registered GLO, the GLO to there is more than one registered GLO, the GLO to
which the request is forwarded to is beyond the which the request is forwarded to is beyond the
scope of this document. Further processing of the scope of this document. Further processing of the
forwarded request by GLOs is addressed in 3 of forwarded request by GLOs is addressed in 3 of
section 4.3.2. section 4.3.2.
Turner 37 2.c.2.b.2.c.1 - The GLA applies confidentiality to the forwarded
2.c.2.b.2.c.1 - The GLA MUST apply confidentiality to the request by encapsulating the SignedData.PKIData in
forwarded request by encapsulating the
SignedData.PKIData in an EnvelopedData if the
original request was encapsulated in an
EnvelopedData (see section 3.2.1.2).
2.c.2.b.2.c.2 - The GLA MAY also optionally apply another Turner 38
an EnvelopedData if the original request was
encapsulated in an EnvelopedData (see section
3.2.1.2).
2.c.2.b.2.c.2 - The GLA can also optionally apply another
SignedData over the EnvelopedData (see section SignedData over the EnvelopedData (see section
3.2.1.2). 3.2.1.2).
2.c.2.b.3 - Else the GL is unmanaged, the GLA MUST check that 2.c.2.b.3 - Else if the GL is unmanaged, the GLA checks that
either a registered GLO or the prospective member either a registered GLO or the prospective member
signed the request. For GLOs, one of the names in the signed the request. For GLOs, one of the names in the
certificate used to sign the request MUST match the certificate used to sign the request needs tp match
name of a registered GLO. For the prospective member, the name of a registered GLO. For the prospective
the name in glMember.glMemberName MUST match one of member, the name in glMember.glMemberName needs to
the names in the certificate used to sign the request. match one of the names in the certificate used to sign
the request.
2.c.2.b.3.a - If the signer is neither a registered GLO nor the 2.c.2.b.3.a - If the signer is neither a registered GLO nor the
prospective member, the GLA MUST return a response prospective member, the GLA returns a response
indicating cMCStatusInfoEx with cMCStatus.failed and indicating cMCStatusInfoEx with cMCStatus.failed and
otherInfo.extendedFailInfo.SKDFailInfo value of otherInfo.extendedFailInfo.SKDFailInfo value of
noSpam. noSpam.
2.c.2.b.3.b - Else the signer is either a registered GLO or the 2.c.2.b.3.b - Else if the signer is either a registered GLO or the
prospective member, the GLA MUST verify the member's prospective member, the GLA verifies the member's
encryption certificate. encryption certificate.
2.c.2.b.3.b.1 - If the member's certificate does not verify, the 2.c.2.b.3.b.1 - If the member's certificate cannot be verified,
GLA MAY return a response indicating the GLA can return a response indicating
cMCStatusInfoEx with cMCStatus.failed and cMCStatusInfoEx with cMCStatus.failed and
otherInfo.extendedFailInfo.SKDFailInfo value of otherInfo.extendedFailInfo.SKDFailInfo value of
invalidCert to either the GLO or the prospective invalidCert to either the GLO or the prospective
member depending on where the request originated. member depending on where the request originated.
If the GLA does not return a cMCStatus.failed If the GLA does not return a cMCStatus.failed
response, the GLA MUST issue a glProvideCert response, the GLA issues a glProvideCert request
request (see section 4.10) to either the GLO or (see section 4.10) to either the GLO or
prospective member depending on where the request prospective member depending on where the request
originated. originated.
2.c.2.b.3.b.2 - Else the member's certificate does verify, the GLA 2.c.2.b.3.b.2 - Else if the member's certificate verifies, the GLA
MUST return a cMCStatusInfoEx indicating returns a cMCStatusInfoEx indicating
cMCStatus.success to the GLO (2 in Figure 5) if cMCStatus.success 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 GLA also takes administrative actions, which The GLA also takes administrative actions, which
are beyond the scope of this document, to add the are beyond the scope of this document, to add the
member to the GL stored on the GLA. The GLA MUST member to the GL stored on the GLA. The GLA also
also distribute the shared KEK to the member via distributes the shared KEK to the member via the
the mechanism described in section 5. mechanism described in section 5.
Turner 38 2.c.2.b.3.b.2.a - The GLA applies confidentiality to the response
2.c.2.b.3.b.2.a - The GLA MUST apply confidentiality to the by encapsulating the SignedData.PKIData in an
response by encapsulating the SignedData.PKIData
in an EnvelopedData if the request was
encapsulated in an EnvelopedData (see section
3.2.1.2).
2.c.2.b.3.b.2.b - The GLA MAY also optionally apply another Turner 39
EnvelopedData if the request was encapsulated in
an EnvelopedData (see section 3.2.1.2).
2.c.2.b.3.b.2.b - The GLA can also optionally apply another
SignedData over the EnvelopedData (see section SignedData over the EnvelopedData (see section
3.2.1.2). 3.2.1.2).
3 - Upon receipt of the cMCStatusInfoEx response, the GLO verifies 3 - Upon receipt of the cMCStatusInfoEx response, the GLO verifies
the GLA's signature(s). If an additional SignedData and/or the GLA signature(s). If an additional SignedData and/or
EnvelopedData encapsulates the response (see section 3.2.1.2 EnvelopedData encapsulates the response (see section 3.2.1.2
or 3.2.2), the GLO MUST verify the outer signature and/or or 3.2.2), the GLO verifies the outer signature and/or decrypt
decrypt the outer layer prior to verifying the signature on the outer layer prior to verifying the signature on the inner
the inner most SignedData. most SignedData.
3.a - Else the signatures do verify, the GLO MUST check that one 3.a - If the signatures verify, the GLO checks that one of the
of the names in the certificate used to sign the response names in the certificate used to sign the response matches
matches the name of the GL. the name of the GL.
3.a.1 ū If the GLĘs name does not match the name present in the 3.a.1 ū If the name of the GL does not match the name present in
certificate used to sign the message, the GLO should not the certificate used to sign the message, the GLO should
believe the response. not believe the response.
3.a.2 ū Else the GLĘs name does match the name present in the 3.a.2 ū Else if the name of the GL matches the name present in the
certificate and: certificate and:
3.a.2.a - If the signatures do verify and the response is 3.a.2.a - If the signatures verify and the response is
cMCStatusInfoEx indicating cMCStatus.success, the GLA cMCStatusInfoEx indicating cMCStatus.success, the GLA
has added the member to the GL. If member was added to a has added the member to the GL. If member was added to a
managed list and the original request was signed by the managed list and the original request was signed by the
member, the GLO MUST send a member, the GLO sends a
cMCStatusInfoEx.cMCStatus.success to the GL member. cMCStatusInfoEx.cMCStatus.success to the GL member.
3.a.2.b - Else the GLO received a cMCStatusInfoEx.cMCStatus.failed 3.a.2.b - Else if the GLO received a
for any reason, the GLO MAY reattempt to add the member cMCStatusInfoEx.cMCStatus.failed with any reason, the
to the GL using the information provided in the GLO can reattempt to add the member to the GL using the
response. information provided in the response.
4 - Upon receipt of the cMCStatusInfoEx response, the prospective 4 - Upon receipt of the cMCStatusInfoEx response, the prospective
member verifies the GLA's signatures or GLOĘs signatures. If member verifies the GLA signatures or GLO signatures. If an
an additional SignedData and/or EnvelopedData encapsulates the additional SignedData and/or EnvelopedData encapsulates the
response (see section 3.2.1.2 or 3.2.2), the GLO MUST verify response (see section 3.2.1.2 or 3.2.2), the GLO verifies the
the outer signature and/or decrypt the outer layer prior to outer signature and/or decrypt the outer layer prior to
verifying the signature on the inner most SignedData. verifying the signature on the inner most SignedData.
4.a - Else the signatures do verify, the GL member MUST check that 4.a - If the signatures verify, the GL member checks that one of
one of the names in the certificate used to sign the the names in the certificate used to sign the response
response matches the name of the GL. matches the name of the GL.
Turner 39 4.a.1 ū If the name of the GL does not match the name present in
4.a.1 ū If the GLĘs name does not match the name present in the the certificate used to sign the message, the GL member
certificate used to sign the message, the GL member should should not believe the response.
not believe the response.
4.a.2 ū Else the GLĘs name does match the name present in the Turner 40
4.a.2 ū Else if the name of the GL matches the name present in the
certificate and: certificate and:
4.a.2.a - If the signatures do verify, the prospective member has 4.a.2.a - If the signatures verify, the prospective member has
been added to the GL. been added to the GL.
4.a.2.b - Else the prospective member received a 4.a.2.b - Else if the prospective member received a
cMCStatusInfoEx.cMCStatus.failed, for any reason, the cMCStatusInfoEx.cMCStatus.failed, for any reason, the
prospective member MAY reattempt to add themselves to prospective member MAY reattempt to add themselves to
the GL using the information provided in the response. the GL using the information provided in the response.
4.3.2 Prospective Member Initiated Additions 4.3.2 Prospective Member Initiated Additions
The process for prospective member initiated glAddMember requests is The process for prospective member initiated glAddMember requests is
as follows: as follows:
1 - The prospective GL member sends a 1 - The prospective GL member sends a
SignedData.PKIData.controlSequence.glAddMember request to the SignedData.PKIData.controlSequence.glAddMember request to the
GLA (A in Figure 5). The prospective GL member MUST include: GLA (A in Figure 5). The prospective GL member includes: the
the GL name in glName, their name in glMember.glMemberName, GL name in glName, their name in glMember.glMemberName, their
their address in glMember.glMemberAddress, and their address in glMember.glMemberAddress, and their encryption
encryption certificate in glMember.certificates.pKC. The certificate in glMember.certificates.pKC. The prospective GL
prospective GL member MAY also include any attribute member can also include any attribute certificates associated
certificates associated with their encryption certificate in with their encryption certificate in glMember.certificates.aC,
glMember.certificates.aC, and the certification path and the certification path associated with their encryption
associated with their encryption and attribute certificates in and attribute certificates in glMember.certificates.certPath.
glMember.certificates.certificationPath.
1.a - The prospective GL member MAY optionally apply 1.a - The prospective GL member can optionally apply
confidentiality to the request by encapsulating the confidentiality to the request by encapsulating the
SignedData.PKIData in an EnvelopedData (see section SignedData.PKIData in an EnvelopedData (see section
3.2.1.2). 3.2.1.2).
1.b - The prospective GL member MAY also optionally apply another 1.b - The prospective GL member MAY can also optionally apply
SignedData over the EnvelopedData (see section 3.2.1.2). another SignedData over the EnvelopedData (see section
3.2.1.2).
2 - Upon receipt of the request, the GLA verifies the request as 2 - Upon receipt of the request, the GLA verifies the request as
per 2 in section 4.3.1. per 2 in section 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 signature on the inner most
SignedData.PKIData and the GLAĘs signature on the outer layer. SignedData.PKIData and the GLA signature on the outer layer.
If an EnvelopedData encapsulates the inner most layer (see If an EnvelopedData encapsulates the inner most layer (see
section 3.2.1.2 or 3.2.2), the GLO MUST decrypt the outer section 3.2.1.2 or 3.2.2), the GLO decrypts the outer layer
layer prior to verifying the signature on the inner most prior to verifying the signature on the inner most SignedData.
SignedData.
Turner 40
Note: For cases where the GL is closed and either a) a Note: For cases where the GL is closed and either a) a
prospective member sends directly to the GLO or b) the GLA has prospective member sends directly to the GLO or b) the GLA has
mistakenly forwarded the request to the GLO, the GLO should mistakenly forwarded the request to the GLO, the GLO should
first determine whether to honor the request. first determine whether to honor the request.
3.a - Else the signatures do verify, the GLO MUST check to make Turner 41
sure one of the names in the certificate used to sign the 3.a - If the signatures verify, the GLO checks to make sure one of
request matches the name in glMember.glMemberName. the names in the certificate used to sign the request
matches the name in glMember.glMemberName.
3.a.1 - If the names do not match, the GLO MAY send a 3.a.1 - If the names do not match, the GLO sends a
SignedData.PKIResponse.controlSequence message back to the SignedData.PKIResponse.controlSequence message back to the
prospective member with cMCStatusInfoEx.cMCStatus.failed prospective member with cMCStatusInfoEx.cMCStatus.failed
indicating why the prospective member was denied in indicating why the prospective member was denied in
cMCStausInfo.statusString. This stops people from adding cMCStausInfo.statusString. This stops people from adding
people to GLs without their permission. people to GLs without their permission.
3.a.2 - Else the names do match, the GLO determines whether the 3.a.2 - Else if the names 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 glMember.glMemberName is not should check to see that the glMember.glMemberName is not
already on the GL. already on the GL.
3.a.2.a - If the GLO determines the prospective member is not 3.a.2.a - If the GLO determines the prospective member is not
allowed to join the GL, the GLO MAY return a allowed to join the GL, the GLO can return a
SignedData.PKIResponse.controlSequence message back to SignedData.PKIResponse.controlSequence message back to
the prospective member with the prospective member with
cMCStatusInfoEx.cMCtatus.failed indicating why the cMCStatusInfoEx.cMCtatus.failed indicating why the
prospective member was denied in cMCStatus.statusString. prospective member was denied in cMCStatus.statusString.
3.a.2.b - Else GLO determines the prospective member is allowed to 3.a.2.b - Else if GLO determines the prospective member is allowed
join the GL, the GLO MUST verify the member's encryption to join the GL, the GLO verifies the member's encryption
certificate. certificate.
3.a.2.b.1 - If the member's certificate does not verify, the GLO 3.a.2.b.1 - If the member's certificate cannot be verified, the
MAY return a SignedData.PKIResponse.controlSequence GLO returns a SignedData.PKIResponse.controlSequence
back to the prospective member with back to the prospective member with
cMCStatusInfoEx.cMCtatus.failed indicating that the cMCStatusInfoEx.cMCtatus.failed indicating that the
memberĘs encryption certificate did not verify in memberĘs encryption certificate did not verify in
cMCStatus.statusString. If the GLO does not return a cMCStatus.statusString. If the GLO does not return a
cMCStatusInfoEx response, the GLO MUST send a cMCStatusInfoEx response, the GLO sends a
SignedData.PKIData.controlSequence.glProvideCert SignedData.PKIData.controlSequence.glProvideCert
message to the prospective member requesting a new message to the prospective member requesting a new
encryption certificate (see section 4.10). encryption certificate (see section 4.10).
3.a.2.b.2 - Else the member's certificate does verify, the GLO 3.a.2.b.2 - Else if the member's certificate verifies, the GLO
resubmits the glAddMember request (see section 3.2.5) resubmits the glAddMember request (see section 3.2.5)
to the GLA (1 in Figure 5). to the GLA (1 in Figure 5).
3.a.2.b.2.a - The GLO MUST apply confidentiality to the new 3.a.2.b.2.a - The GLO applies 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
Turner 41
initial request was encapsulated in an EnvelopedData initial request was encapsulated in an EnvelopedData
(see section 3.2.1.2). (see section 3.2.1.2).
3.a.2.b.2.b - The GLO MAY also optionally apply another SignedData 3.a.2.b.2.b - The GLO can also optionally apply another SignedData
over the EnvelopedData (see section 3.2.1.2). over the EnvelopedData (see section 3.2.1.2).
Turner 42
4 - Processing continues as in 2 of section 4.3.1. 4 - Processing continues as in 2 of section 4.3.1.
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 members to be removed
members use the glDeleteMember request. The GLA processes GLO and use the glDeleteMember request. The GLA processes GLO and members
prospective non-GL member requests differently. The GLO can submit requesting their own removal make requests differently. The GLO can
the request at any time to delete members from the GL, and the GLA, submit the request at any time to delete members from the GL, and
once it has verified the request came from a registered GLO, should the GLA, once it has verified the request came from a registered
delete the member. If a prospective member sends the request, the GLO, should delete the member. If a member sends the request, the
GLA needs to determine how the GL is administered. When the GLO GLA needs to determine how the GL is administered. When the GLO
initially configured the GL, they set the GL to be unmanaged, initially configured the GL, they set the GL to be unmanaged,
managed, or closed (see section 3.1.1). In the unmanaged case, the managed, or closed (see section 3.1.1). In the unmanaged case, the
GLA merely processes the memberĘs request. For the managed case, the GLA merely processes the memberĘs request. For the managed case, the
GLA forwards the requests from the prospective members to the GLO GLA forwards the requests from the member to the GLO for review.
for review. Where there are multiple GLOs for a GL, which GLO the Where there are multiple GLOs for a GL, which GLO the request is
request is forwarded to is beyond the scope of this document. The forwarded to is beyond the scope of this document. The GLO reviews
GLO reviews the request and either rejects it or submits a reformed the request and either rejects it or submits a reformed request to
request to the GLA. In the closed case, the GLA will not accept the GLA. In the closed case, the GLA will not accept requests from
requests from prospective members. The following sections describe members. The following sections describe the processing for the
the processing for the GLO(s), GLA, and GL members depending on GLO(s), GLA, and GL members depending on where the request
where the request originated, either from a GLO or from prospective originated, either from a GLO or from members wanting to be removed.
non-members. Figure 6 depicts the protocol interactions for the Figure 6 depicts the protocol interactions for the three options.
three options. Note that the error messages are not depicted. 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 +----------+
skipping to change at line 2123 skipping to change at line 2181
+----------+ +----------+
Figure 6 - Member Deletion Figure 6 - Member Deletion
If the member is not removed from the GL, they will continue to If the member is not removed from the GL, they will continue to
receive and be able to decrypt data protected with the shared KEK receive and be able to decrypt data protected with the shared KEK
and will continue to receive rekeys. For unmanaged lists, there is and will continue to receive rekeys. For unmanaged lists, there is
no point to a group rekey because there is no guarantee that the no point to a group rekey because there is no guarantee that the
member requesting to be removed has not already added themselves member requesting to be removed has not already added themselves
back on the GL under a different name. For managed and closed GLs, back on the GL under a different name. For managed and closed GLs,
the GLO needs to take steps to ensure the member being deleted is
not on the GL twice. After ensuring this, managed and closed GLs can
be rekeyed to maintain the confidentiality of the traffic sent by
group members. If the GLO is sure the member has been deleted the
group rekey mechanism can be used to distribute the new key (see
sections 4.5 and 5).
Turner 42 Turner 43
the GLO MUST take steps to ensure the member being deleted is not on
the GL twice. After ensuring this, managed and closed GLs MUST be
rekeyed to maintain the secrecy of the group. If the GLO is sure the
member has been deleted the group rekey mechanism MUST be used to
distribute the new key (see sections 4.5 and 5).
4.4.1 GLO Initiated Deletions 4.4.1 GLO Initiated Deletions
The process for GLO initiated glDeleteMember requests is as follows: The process for GLO initiated glDeleteMember requests is as follows:
1 - The GLO collects the pertinent information for the member(s) 1 - The GLO collects the pertinent information for the member(s)
to be deleted (this MAY be done through an out of bands to be deleted (this can be done through an out of bands
means). The GLO then sends a means). The GLO then sends a
SignedData.PKIData.controlSequence with a separate SignedData.PKIData.controlSequence with a separate
glDeleteMember request for each member to the GLA (1 in Figure glDeleteMember request for each member to the GLA (1 in Figure
6). The GLO MUST include: the GL name in glName and the 6). The GLO MUST include: the GL name in glName and the
member's name in glMemberToDelete. If the GL from which the member's name in glMemberToDelete. If the GL from which the
member is being deleted in a closed or managed GL, the GLO 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 section 4.5). glDeletemember request (see section 4.5).
1.a - The GLO MAY optionally apply confidentiality to the request 1.a - The GLO can optionally apply confidentiality to the request
by encapsulating the SignedData.PKIData in an EnvelopedData by encapsulating the SignedData.PKIData in an EnvelopedData
(see section 3.2.1.2). (see section 3.2.1.2).
1.b - The GLO MAY also optionally apply another SignedData over 1.b - The GLO can also optionally apply another SignedData over
the EnvelopedData (see section 3.2.1.2). the EnvelopedData (see section 3.2.1.2).
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 section and/or EnvelopedData encapsulates the request (see section
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 verifies the outer signature and/or
and/or decrypt the outer layer prior to verifying the decrypt the outer layer prior to verifying the signature on
signature on the inner most SignedData. the inner most SignedData.
2.a - If the signatures do not verify, the GLA MUST return a 2.a - If the signatures cannot be verified, the GLA returns a
cMCStatusInfoEx response indicating cMCStatus.failed and cMCStatusInfoEx response indicating cMCStatus.failed and
otherInfo.failInfo.badMessageCheck. otherInfo.failInfo.badMessageCheck.
2.b - Else the signatures do verify, the GLA MUST make sure the GL 2.b - Else if the signatures verify, the GLA makes sure the GL is
is supported by the GLA by checking that the glName matches supported by the GLA by checking that the glName matches a
a glName stored on the GLA. glName stored on the GLA.
2.b.1 - If the glName is not supported by the GLA, the GLA MUST 2.b.1 - If the glName is not supported by the GLA, the GLA returns
return a response indicating cMCStatusInfoEx with a response indicating cMCStatusInfoEx with
cMCStatus.failed and cMCStatus.failed and
otherInfo.extendedFailInfo.SKDFailInfo value of otherInfo.extendedFailInfo.SKDFailInfo value of
invalidGLName. invalidGLName.
2.b.2 - Else the glName is supported by the GLA, the GLA MUST 2.b.2 - Else if the glName is supported by the GLA, the GLA checks
check to see if the glMemberName is present on the GL. to see if the glMemberName is present on the GL.
Turner 43
2.b.2.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 cMCStatusInfoEx with returns a response indicating cMCStatusInfoEx with
cMCStatus.failed and cMCStatus.failed and
Turner 44
otherInfo.extendedFailInfo.SKDFailInfo value of otherInfo.extendedFailInfo.SKDFailInfo value of
notAMember. notAMember.
2.b.2.b - Else the glMemberName is already on the GL, the GLA MUST 2.b.2.b - Else if the glMemberName is already on the GL, the GLA
check how the GL is administered. checks how the GL is administered.
2.b.2.b.1 - If the GL is closed, the GLA MUST check that the 2.b.2.b.1 - If the GL is closed, the GLA checks that the
registered GLO signed the request by checking that one registered GLO signed the request by checking that one
of the names in the digital signature certificate used of the names in the digital signature certificate used
to sign the request matches the registered GLO. to sign the request matches the registered GLO.
2.b.2.b.1.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 returns a
response indicating cMCStatusInfoEx with response indicating cMCStatusInfoEx with
cMCStatus.failed and cMCStatus.failed and
otherInfo.extendedFailInfo.SKDFailInfo value of otherInfo.extendedFailInfo.SKDFailInfo value of
closedGL. closedGL.
2.b.2.b.1.b - Else the names do match, the GLA MUST return a 2.b.2.b.1.b - Else if the names do match, the GLA returns a
cMCStatusInfoEx.cMCStatus.success (2 in Figure 5). cMCStatusInfoEx.cMCStatus.success (2 in Figure 5).
The GLA also takes administrative actions, which are The GLA also takes administrative actions, which are
beyond the scope of this document, to delete the beyond the scope of this document, to delete the
member with the GL stored on the GLA. Note that he member with the GL stored on the GLA. Note that he
GL MUST also be rekeyed as described in section 5. GL also needs to be rekeyed as described in section
5.
2.b.2.b.1.b.1 - The GLA MUST apply confidentiality to the response 2.b.2.b.1.b.1 - The GLA applies confidentiality to the response by
by encapsulating the SignedData.PKIData in an encapsulating the SignedData.PKIData in an
EnvelopedData if the request was encapsulated in EnvelopedData if the request was encapsulated in
an EnvelopedData (see section 3.2.1.2). an EnvelopedData (see section 3.2.1.2).
2.b.2.b.1.b.2 - The GLA MAY also optionally apply another 2.b.2.b.1.b.2 - The GLA can also optionally apply another
SignedData over the EnvelopedData (see section SignedData over the EnvelopedData (see section
3.2.1.2). 3.2.1.2).
2.b.2.b.2 - Else the GL is managed, the GLA MUST check that either 2.b.2.b.2 - Else if the GL is managed, the GLA checks that either
a registered GLO or the prospective member signed the a registered GLO or the prospective member signed the
request. For GLOs, one of the names in the certificate request. For GLOs, one of the names in the certificate
used to sign the request MUST match a registered GLO. used to sign the request needs to match a registered
For the prospective member, the name in GLO. For the prospective member, the name in
glMember.glMemberName MUST match one of the names in glMember.glMemberName needs to match one of the names
the certificate used to sign the request. in the certificate used to sign the request.
2.b.2.b.2.a - If the signer is neither a registered GLO nor 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 returns a response
response indicating cMCStatusInfoEx with indicating cMCStatusInfoEx with cMCStatus.failed and
cMCStatus.failed and
otherInfo.extendedFailInfo.SKDFailInfo value of otherInfo.extendedFailInfo.SKDFailInfo value of
noSpam. noSpam.
Turner 44 2.b.2.b.2.b - Else if the signer is a registered GLO, the GLA
2.b.2.b.2.b - Else the signer is a registered GLO, the GLA MUST returns a cMCStatusInfoEx.cMCStatus.success (2 in
return a cMCStatusInfoEx.cMCStatus.success (2 in
Figure 6). The GLA also takes administrative Figure 6). The GLA also takes administrative
actions, which are beyond the scope of this actions, which are beyond the scope of this
Turner 45
document, to delete the member with the GL stored on document, to delete the member with the GL stored on
the GLA. Note that the GL will also be rekeyed as the GLA. Note that the GL will also be rekeyed as
described in section 5. described in section 5.
2.b.2.b.2.b.1 - The GLA MUST apply confidentiality to the response 2.b.2.b.2.b.1 - The GLA applies confidentiality to the response by
by encapsulating the SignedData.PKIData in an encapsulating the SignedData.PKIData in an
EnvelopedData if the request was encapsulated in EnvelopedData if the request was encapsulated in
an EnvelopedData (see section 3.2.1.2). an EnvelopedData (see section 3.2.1.2).
2.b.2.b.2.b.2 - The GLA MAY also optionally apply another 2.b.2.b.2.b.2 - The GLA can also optionally apply another
SignedData over the EnvelopedData (see section SignedData over the EnvelopedData (see section
3.2.1.2). 3.2.1.2).
2.b.2.b.2.c - Else the signer is the prospective member, the GLA 2.b.2.b.2.c - Else if the signer is the prospective member, the
forwards the glDeleteMember request (see section GLA forwards the glDeleteMember request (see section
3.2.3) to the GLO (B{A} in Figure 6). If there is 3.2.3) to the GLO (B{A} in Figure 6). If there is
more than one registered GLO, the GLO to which the 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 GLOs is addressed in 3 of section 4.4.2. request by GLOs is addressed in 3 of section 4.4.2.
2.b.2.b.2.c.1 - The GLA MUST apply confidentiality to the 2.b.2.b.2.c.1 - The GLA applies confidentiality to the forwarded
forwarded request by encapsulating the request by encapsulating the SignedData.PKIData in
SignedData.PKIData in an EnvelopedData if the an EnvelopedData if the request was encapsulated
request was encapsulated in an EnvelopedData (see in an EnvelopedData (see section 3.2.1.2).
section 3.2.1.2).
2.b.2.b.2.c.2 - The GLA MAY also optionally apply another 2.b.2.b.2.c.2 - The GLA can also optionally apply another
SignedData over the EnvelopedData (see section SignedData over the EnvelopedData (see section
3.2.1.2). 3.2.1.2).
2.b.2.b.3 - Else the GL is unmanaged, the GLA MUST check that 2.b.2.b.3 - Else if the GL is unmanaged, the GLA checks that
either a registered GLO or the prospective member either a registered GLO or the prospective member
signed the request. For GLOs, one of the names in the signed the request. For GLOs, one of the names in the
certificate used to sign the request MUST match the certificate used to sign the request needs to match
name of a registered GLO. For the prospective member, the name of a registered GLO. For the prospective
the name in glMember.glMemberName MUST match one of member, the name in glMember.glMemberName needs to
the names in the certificate used to sign the request. match one of the names in the certificate used to sign
the request.
2.b.2.b.3.a - If the signer is neither the GLO nor 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 returns a response indicating
cMCStatusInfoEx with cMCStatus.failed and cMCStatusInfoEx with cMCStatus.failed and
otherInfo.extendedFailInfo.SKDFailInfo value of otherInfo.extendedFailInfo.SKDFailInfo value of
noSpam. noSpam.
2.b.2.b.3.b - Else the signer is either a registered GLO or the 2.b.2.b.3.b - Else if the signer is either a registered GLO or the
member, the GLA MUST return a member, the GLA returns a
cMCStatusInfoEx.cMCStatus.success to the GLO (2 in cMCStatusInfoEx.cMCStatus.success to the GLO (2 in
Turner 45
Figure 6) if the GLO signed the request and to the Figure 6) if the GLO signed the request and to the
GL member (3 in Figure 6) if the GL member signed GL member (3 in Figure 6) if the GL member signed
the request. The GLA also takes administrative the request. The GLA also takes administrative
actions, which are beyond the scope of this actions, which are beyond the scope of this
Turner 46
document, to delete the member with the GL stored on document, to delete the member with the GL stored on
the GLA. the GLA.
2.b.2.b.3.b.1 - The GLA MUST apply confidentiality to the response 2.b.2.b.3.b.1 - The GLA applies confidentiality to the response by
by encapsulating the SignedData.PKIData in an encapsulating the SignedData.PKIData in an
EnvelopedData if the request was encapsulated in EnvelopedData if the request was encapsulated in
an EnvelopedData (see section 3.2.1.2). an EnvelopedData (see section 3.2.1.2).
2.b.2.b.3.b.2 - The GLA MAY also optionally apply another 2.b.2.b.3.b.2 - The GLA can also optionally apply another
SignedData over the EnvelopedData (see section SignedData over the EnvelopedData (see section
3.2.1.2). 3.2.1.2).
3 - Upon receipt of the cMCStatusInfoEx response, the GLO verifies 3 - Upon receipt of the cMCStatusInfoEx response, the GLO verifies
the GLA's signatures. If an additional SignedData and/or the GLA signatures. If an additional SignedData and/or
EnvelopedData encapsulates the response (see section 3.2.1.2 EnvelopedData encapsulates the response (see section 3.2.1.2
or 3.2.2), the GLO MUST verify the outer signature and/or or 3.2.2), the GLO verifies the outer signature and/or decrypt
decrypt the outer layer prior to verifying the signature on the outer layer prior to verifying the signature on the inner
the inner most SignedData. most SignedData.
3.a - If the signatures do not verify, the GLO MUST return a
response indicating cMCStatus.failed and
otherInfo.failInfo.badMessageCheck.
3.b - Else the signatures do verify, the GLO MUST check that one 3.a - If the signatures do verify, the GLO checks that one of the
of the names in the certificate used to sign the response names in the certificate used to sign the response matches
matches the name of the GL. the name of the GL.
3.b.1 ū If the GLĘs name does not match the name present in the 3.a.1 ū If the name of the GL does not match the name present in
certificate used to sign the message, the GLO should not the certificate used to sign the message, the GLO should
believe the response. not believe the response.
3.b.2 ū Else the GLĘs name does match the name present in the 3.a.2 ū Else if the name of the GL matches the name present in the
certificate and: certificate and:
3.b.2.a - If the signatures do verify and the response is 3.a.2.a - If the signatures verify and the response is
cMCStatusInfoEx.cMCStatus.success, the GLO has deleted cMCStatusInfoEx.cMCStatus.success, the GLO has deleted
the member from the GL. If member was deleted from a the member from the GL. If member was deleted from a
managed list and the original request was signed by the managed list and the original request was signed by the
member, the GLO MUST send a member, the GLO sends a
cMCStatusInfoEx.cMCStatus.success to the GL member. cMCStatusInfoEx.cMCStatus.success to the GL member.
3.b.2.b - Else the GLO received a cMCStatusInfoEx.cMCStatus.failed 3.a.2.b - Else if the GLO received a
for any reason, the GLO may reattempt to delete the cMCStatusInfoEx.cMCStatus.failed with any reason, the
member from the GL using the information provided in the GLO may reattempt to delete the member from the GL using
response. the information provided in the response.
4 - Upon receipt of the cMCStatusInfoEx response, the prospective
member verifies the GLA's signature(s) or GLOĘs signature(s).
Turner 46 4 - Upon receipt of the cMCStatusInfoEx response, the member
If an additional SignedData and/or EnvelopedData encapsulates verifies the GLA signature(s) or GLO signature(s). If an
the response (see section 3.2.1.2 or 3.2.2), the GLO MUST additional SignedData and/or EnvelopedData encapsulates the
verify the outer signature and/or decrypt the outer layer response (see section 3.2.1.2 or 3.2.2), the GLO verifies the
prior to verifying the signature on the inner most SignedData. outer signature and/or decrypt the outer layer prior to
verifying the signature on the inner most SignedData.
4.a - Else the signatures do verify, the GL member MUST check that 4.a - If the signatures verify, the GL member checks that one of
one of the names in the certificate used to sign the the names in the certificate used to sign the response
response matches the name of the GL. matches the name of the GL.
4.a.1 ū If the GLĘs name does not match the name present in the Turner 47
certificate used to sign the message, the GL member should 4.a.1 ū If the name of the GL does not match the name present in
not believe the response. the certificate used to sign the message, the GL member
should not believe the response.
4.a.2 ū Else the GLĘs name does match the name present in the 4.a.2 ū Else if the name of the GL matches the name present in the
certificate and: certificate and:
4.a.2.a - If the signature(s) does(do) verify, the prospective 4.a.2.a - If the signature(s) verify, the member has been deleted
member has been deleted from the GL. from the GL.
4.a.2.b - Else the prospective member received a 4.a.2.b - Else if the member received a
cMCStatusInfoEx.cMCStatus.failed for any reason, the cMCStatusInfoEx.cMCStatus.failed with any reason, the
prospective member MAY reattempt to delete themselves member can reattempt to delete themselves from the GL
from the GL using the information provided in the using the information provided in the response.
response.
4.4.2 Member Initiated Deletions 4.4.2 Member Initiated Deletions
The process for prospective non-member initiated glDeleteMember The process for member initiated deletion of their own membership
requests is as follows: using the glDeleteMember requests is as follows:
1 - The prospective non-GL member sends a 1 - The member sends a
SignedData.PKIData.controlSequence.glDeleteMember request to SignedData.PKIData.controlSequence.glDeleteMember request to
the GLA (A in Figure 6). The prospective non-GL member MUST the GLA (A in Figure 6). The member includes: the name of the
include: the GL name in glName and their name in GL in glName and their own name in glMemberToDelete.
glMemberToDelete.
1.a - The prospective non-GL member MAY optionally apply 1.a - The member can optionally apply confidentiality to the
confidentiality to the request by encapsulating the request by encapsulating the SignedData.PKIData in an
SignedData.PKIData in an EnvelopedData (see section EnvelopedData (see section 3.2.1.2).
3.2.1.2).
1.b - The prospective non-GL member MAY also optionally apply 1.b - The member can also optionally apply another SignedData over
another SignedData over the EnvelopedData (see section the EnvelopedData (see section 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 section 4.4.1. per 2 in section 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 non-memberĘs signature on the inner most member signature on the inner most SignedData.PKIData and the
SignedData.PKIData and the GLAĘs signature on the outer layer. GLA signature on the outer layer. If an EnvelopedData
encapsulates the inner most layer (see section 3.2.1.2 or
Turner 47 3.2.2), the GLO decrypts the outer layer prior to verifying
If an EnvelopedData encapsulates the inner most layer (see the signature on the inner most SignedData.
section 3.2.1.2 or 3.2.2), the GLO MUST decrypt the outer
layer prior to verifying the signature on the inner most
SignedData.
Note: For cases where the GL is closed and either a) a Note: For cases where the GL is closed and either (a) a
prospective member sends directly to the GLO or b) the GLA has prospective member sends directly to the GLO or (b) the GLA
mistakenly forwarded the request to the GLO, the GLO should has mistakenly forwarded the request to the GLO, the GLO
first determine whether to honor the request. should first determine whether to honor the request.
3.a - If the signatures do not verify, the GLO MUST return a 3.a - If the signatures cannot be verified, the GLO returns a
cMCStatusInfoEx response indicating cMCStatus.failed and cMCStatusInfoEx response indicating cMCStatus.failed and
otherInfo.failInfo.badMessageCheck. otherInfo.failInfo.badMessageCheck.
3.b - Else the signatures do verify, the GLO MUST check to make Turner 48
sure one of the names in the certificates used to sign the 3.b - Else if the signatures verify, the GLO checks to make sure
one of the names in the certificates used to sign the
request matches the name in glMemberToDelete. request matches the name in glMemberToDelete.
3.b.1 - If the names do not match, the GLO MAY send a 3.b.1 - If the names match, the GLO sends a
SignedData.PKIResponse.controlSequence message back to the SignedData.PKIResponse.controlSequence message back to the
prospective member with cMCStatusInfoEx.cMCtatus.failed prospective member with cMCStatusInfoEx.cMCtatus.failed
indicating why the prospective member was denied in indicating why the prospective member was denied in
cMCStatusInfoEx.statusString. This stops people from cMCStatusInfoEx.statusString. This stops people from
adding people to GLs without their permission. adding people to GLs without their permission.
3.b.2 - Else the names do match, the GLO resubmits the 3.b.2 - Else if the names match, the GLO resubmits the
glDeleteMember request (see section 3.2.5) to the GLA (1 glDeleteMember request (see section 3.2.5) to the GLA (1
in Figure 6). The GLO MUST make sure the glMemberName is in Figure 6). The GLO makes sure the glMemberName is
already on the GL. The GLO MUST also generate a glRekey already on the GL. The GLO also generates a glRekey
request and include it with the GLDeleteMember request request and include it with the GLDeleteMember request
(see section 4.5). (see section 4.5).
3.b.2.a - The GLO MUST apply confidentiality to the new 3.b.2.a - The GLO applies 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
section 3.2.1.2). section 3.2.1.2).
3.b.2.b - The GLO MAY also optionally apply another SignedData 3.b.2.b - The GLO can also optionally apply another SignedData
over the EnvelopedData (see section 3.2.1.2). over the EnvelopedData (see section 3.2.1.2).
4 - Further processing is as in 2 of section 4.4.1. 4 - Further processing is as in 2 of section 4.4.1.
4.5 Request Rekey Of GL 4.5 Request Rekey Of GL
From time to time the GL will need to be rekeyed. Some situations From time to time, the GL will need to be rekeyed. Some situations
are as follows: follow:
- When a member is removed from a closed or managed GL. In this - When a member is removed from a closed or managed GL. In this
case, the PKIData.controlSequence containing the glDeleteMember case, the PKIData.controlSequence containing the glDeleteMember
should contain a glRekey request. ought to contain a glRekey request.
Turner 48
- Depending on policy, when a member is removed from an unmanaged - Depending on policy, when a member is removed from an unmanaged
GL. If the policy is to rekey the GL, the GL. If the policy is to rekey the GL, the
PKIData.controlSequence containing the glDeleteMember could also PKIData.controlSequence containing the glDeleteMember could also
contain a glRekey request or an out of bands means could be used contain a glRekey request or an out of bands means could be used
to tell the GLA to rekey the GL. Rekeying of unmanaged GLs when to tell the GLA to rekey the GL. Rekeying of unmanaged GLs when
members are deleted is not advised. members are deleted is not advised.
- When the current shared KEK has been compromised. - When the current shared KEK has been compromised.
- When the current shared KEK is about to expire. - When the current shared KEK is about to expire. Consider two
cases:
Turner 49
- If the GLO controls the GL rekey, the GLA should not assume - If the GLO controls the GL rekey, the GLA should not assume
that a new shared KEK should be distributed, but instead wait that a new shared KEK should be distributed, but instead wait
for the glRekey message. for the glRekey message.
- If the GLA controls the GL rekey, the GLA should initiate a - If the GLA controls the GL rekey, the GLA should initiate a
glKey message as specified in section 5. glKey message as specified in section 5.
If the generationCounter (see section 3.1.1) is set to a value If the generationCounter (see section 3.1.1) is set to a value
greater than one (1) and the GLO controls the GL rekey, the GLO may greater than one (1) and the GLO controls the GL rekey, the GLO may
generate a glRekey any time before the last shared KEK has expired. generate a glRekey any time before the last shared KEK has expired.
To be on the safe side, the GLO should request a rekey one (1) To be on the safe side, the GLO ought to request a rekey one (1)
duration before the last shared KEK expires. duration before the last shared KEK expires.
The GLA and GLO are the only entities allowed to initiate a GL 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 to control rekeys or
whether the GLA is going to control rekeys when the assigned the whether the GLA is going to control rekeys when they assigned the
shared KEK to GL (see section 3.1.1). The GLO MAY initiate a GL shared KEK to GL (see section 3.1.1). The GLO initiates a GL rekey
rekey at any time. The GLA MAY be configured to automatically rekey at any time. The GLA can be configured to automatically rekey the GL
the GL prior to the expiration of the shared KEK (the length of time prior to the expiration of the shared KEK (the length of time before
before the expiration is an implementation decision). The GLA can the expiration is an implementation decision). The GLA can also
also automatically rekey GLĘs that have been compromised, but this automatically rekey GLs that have been compromised, but this is
is covered in section 5. Figure 7 depicts the protocol interactions covered in section 5. Figure 7 depicts the protocol interactions to
to request a GL rekey. Note that error messages are not depicted. request a GL rekey. Note that 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 includes the
glName. If glAdministration and glKeyNewAttributes are omitted glName. If glAdministration and glKeyNewAttributes are omitted
then there is no change from the previously registered GL then there is no change from the previously registered GL
values for these fields. If the GLO wants to force a rekey for values for these fields. If the GLO wants to force a rekey for
Turner 49
all outstanding shared KEKs it includes the glRekeyAllGLKeys all outstanding shared KEKs it includes the glRekeyAllGLKeys
set to TRUE. set to TRUE.
1.a - The GLO MAY optionally apply confidentiality to the request 1.a - The GLO can optionally apply confidentiality to the request
by encapsulating the SignedData.PKIData in an EnvelopedData by encapsulating the SignedData.PKIData in an EnvelopedData
(see section 3.2.1.2). (see section 3.2.1.2).
1.b - The GLO MAY also optionally apply another SignedData over 1.b - The GLO can also optionally apply another SignedData over
the EnvelopedData (see section 3.2.1.2). the EnvelopedData (see section 3.2.1.2).
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
Turner 50
and/or EnvelopedData encapsulates the request (see section and/or EnvelopedData encapsulates the request (see section
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 verifies the outer signature and/or
and/or decrypt the outer layer prior to verifying the decrypt the outer layer prior to verifying the signature on
signature on the inner most SignedData. the inner most SignedData.
2.a - If the signatures do not verify, the GLA MUST return a 2.a - If the signatures do not verify, the GLA returns a
cMCStatusInfoEx response indicating cMCStatus.failed and cMCStatusInfoEx response indicating cMCStatus.failed and
otherInfo.failInfo.badMessageCheck. otherInfo.failInfo.badMessageCheck.
2.b - Else the signatures do verify, the GLA MUST make sure the GL 2.b - Else if the signatures do verify, the GLA makes sure the GL
is supported by the GLA by checking that the glName matches is supported by the GLA by checking that the glName matches
a glName stored on the GLA. a glName stored on the GLA.
2.b.1 - If the glName present does not match a GL stored on the 2.b.1 - If the glName present does not match a GL stored on the
GLA, the GLA MUST return a response indicating GLA, the GLA returns a response indicating cMCStatusInfoEx
cMCStatusInfoEx with cMCStatus.failed and with cMCStatus.failed and
otherInfo.extendedFailInfo.SKDFailInfo value of otherInfo.extendedFailInfo.SKDFailInfo value of
invalidGLName. invalidGLName.
2.b.2 - Else the glName present does match a GL stored on the GLA, 2.b.2 - Else if the glName present matches a GL stored on the GLA,
the GLA MUST check that a registered GLO signed the the GLA checks that a registered GLO signed the request by
request by checking that one of the names in the checking that one of the names in the certificate used to
certificate used to sign the request is a registered GLO. sign the request is a registered GLO.
2.b.2.a - If the names do not match, the GLA MUST return a 2.b.2.a - If the names do not match, the GLA returns a response
response indicating cMCStatusInfoEx with indicating cMCStatusInfoEx with cMCStatus.failed and
cMCStatus.failed and
otherInfo.extendedFailInfo.SKDFailInfo value of otherInfo.extendedFailInfo.SKDFailInfo value of
noGLONameMatch. noGLONameMatch.
2.b.2.b - Else the names do match, the GLA MUST check the 2.b.2.b - Else if the names match, the GLA checks the
glNewKeyAttribute values. glNewKeyAttribute values.
2.b.2.b.1 - If the new value for requestedAlgorithm is not 2.b.2.b.1 - If the new value for requestedAlgorithm is not
supported, the GLA MUST return a response indicating supported, the GLA returns a response indicating
cMCStatusInfoEx with cMCStatus.failed and cMCStatusInfoEx with cMCStatus.failed and
otherInfo.extendedFailInfo.SKDFailInfo value of otherInfo.extendedFailInfo.SKDFailInfo value of
unsupportedAlgorithm unsupportedAlgorithm.
Turner 50 2.b.2.b.2 - Else if the new value duration is not supportable,
2.b.2.b.2 - Else the new value duration is not supportable,
determining this is beyond the scope this document, determining this is beyond the scope this document,
the GLA MUST return a response indicating the GLA returns a response indicating cMCStatusInfoEx
cMCStatusInfoEx with cMCStatus.failed and with cMCStatus.failed and
otherInfo.extendedFailInfo.SKDFailInfo value of otherInfo.extendedFailInfo.SKDFailInfo value of
unsupportedDuration. unsupportedDuration.
2.b.2.b.3 - Else the GL is not supportable for other reasons, 2.b.2.b.3 - Else if the GL is not supportable for other reasons,
which the GLA does not wish to disclose, the GLA MUST which the GLA does not wish to disclose, the GLA
return a response indicating cMCStatusInfoEx with returns a response indicating cMCStatusInfoEx with
cMCStatus.failed and cMCStatus.failed and
otherInfo.extendedFailInfo.SKDFailInfo value of otherInfo.extendedFailInfo.SKDFailInfo value of
unspecified. unspecified.
2.b.2.b.4 - Else the new requestedAlgorithm and duration are Turner 51
2.b.2.b.4 - Else if the new requestedAlgorithm and duration are
supportable or the glNewKeyAttributes was omitted, the supportable or the glNewKeyAttributes was omitted, the
GLA MUST return a cMCStatusInfoEx.cMCStatus.success (2 GLA returns a cMCStatusInfoEx.cMCStatus.success (2 in
in Figure 7). The GLA also uses the glKey message to Figure 7). The GLA also uses the glKey message to
distribute the rekey shared KEK (see section 5). distribute the rekey shared KEK (see section 5).
2.b.2.b.4.a - The GLA MUST apply confidentiality to response by 2.b.2.b.4.a - The GLA applies 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 section 3.2.1.2). EnvelopedData (see section 3.2.1.2).
2.b.2.b.4.b - The GLA MAY also optionally apply another SignedData 2.b.2.b.4.b - The GLA can also optionally apply another SignedData
over the EnvelopedData (see section 3.2.1.2). over the EnvelopedData (see section 3.2.1.2).
3 - Upon receipt of the cMCStatusInfoEx response, the GLO verifies 3 - Upon receipt of the cMCStatusInfoEx response, the GLO verifies
the GLA's signature(s). If an additional SignedData and/or the GLA signature(s). If an additional SignedData and/or
EnvelopedData encapsulates the forwarded response (see section EnvelopedData encapsulates the forwarded response (see section
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 verifies the outer signature and/or
and/or decrypt the forwarded response prior to verifying the decrypt the forwarded response prior to verifying the
signature on the inner most SignedData. signature on the inner most SignedData.
3.a - Else the signatures do verify, the GLO MUST check that one 3.a - If the signatures verify, the GLO checks that one of the
of the names in the certificate used to sign the response names in the certificate used to sign the response matches
matches the name of the GL. the name of the GL.
3.a.1 ū If the GLĘs name does not match the name present in the 3.a.1 ū If the name of the GL does not match the name present in
certificate used to sign the message, the GLO should not the certificate used to sign the message, the GLO should
believe the response. not believe the response.
3.a.2 ū Else the GLĘs name does match the name present in the 3.a.2 ū Else if the name of the GL matches the name present in the
certificate and: certificate and:
3.a.2.a - If the signatures verifies and the response is 3.a.2.a - If the signatures verify and the response is
cMCStatusInfoEx.cMCStatus.success, the GLO has cMCStatusInfoEx.cMCStatus.success, the GLO has
successfully rekeyed the GL. successfully rekeyed the GL.
Turner 51 3.a.2.b ū Else if the GLO received a
3.a.2.b - Else the GLO received a cMCStatusInfoEx.cMCStatus.failed cMCStatusInfoEx.cMCStatus.failed with any reason, the
for any reason, the GLO may reattempt to rekey the GL GLO can reattempt to rekey the GL using the information
using the information provided in the response. provided in the response.
Turner 52
4.5.2 GLA Initiated Rekey Requests 4.5.2 GLA Initiated Rekey Requests
If the GLA is in charge of rekeying the GL the GLA will If the GLA is in charge of rekeying the GL the GLA will
automatically issue a glKey message (see section 5). In addition the automatically issue a glKey message (see section 5). In addition the
GLA will generate a cMCStatusInfoEx to indicate to the GL that a GLA will generate a cMCStatusInfoEx 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 generates for all GLOs a
SignedData.PKIData.controlSequence.cMCStatusInfoEx.cMCStatus.s SignedData.PKIData.controlSequence.cMCStatusInfoEx.cMCStatus.s
uccess (A in Figure 7). uccess (A in Figure 7).
1.a - The GLA MAY optionally apply confidentiality to the request 1.a - The GLA can optionally apply confidentiality to the request
by encapsulating the SignedData.PKIData in an EnvelopedData by encapsulating the SignedData.PKIData in an EnvelopedData
(see section 3.2.1.2). (see section 3.2.1.2).
1.b - The GLA MAY also optionally apply another SignedData over 1.b - The GLA can also optionally apply another SignedData over
the EnvelopedData (see section 3.2.1.2). the EnvelopedData (see section 3.2.1.2).
2 - Upon receipt of the cMCStatusInfoEx.cMCStatus.success 2 - Upon receipt of the cMCStatusInfoEx.cMCStatus.success
response, the GLO verifies the GLA's signature(s). If an response, the GLO verifies the GLA signature(s). If an
additional SignedData and/or EnvelopedData encapsulates the additional SignedData and/or EnvelopedData encapsulates the
forwarded response (see section 3.2.1.2 or 3.2.2), the GLO forwarded response (see section 3.2.1.2 or 3.2.2), the GLO
MUST verify the outer signature and/or decrypt the outer layer MUST verify the outer signature and/or decrypt the outer layer
prior to verifying the signature on the inner most SignedData. prior to verifying the signature on the inner most SignedData.
2.a - Else the signatures do verify, the GLO MUST check that one 2.a - If the signatures verify, the GLO checks that one of the
of the names in the certificate used to sign the response names in the certificate used to sign the response matches
matches the name of the GL. the name of the GL.
2.a.1 ū If the GLĘs name does not match the name present in the 2.a.1 ū If the name of the GL does not match the name present in
certificate used to sign the message, the GLO should not the certificate used to sign the message, the GLO ought
believe the response. not believe the response.
2.a.2 ū Else the GLĘs name does match the name present in the 2.a.2 ū Else if the name of the GL does match the name present in
certificate and and the response is the certificate and and the response is
cMCStatusInfoEx.cMCStatus.success, the GLO knows the GLA cMCStatusInfoEx.cMCStatus.success, the GLO knows the GLA
has successfully rekeyed the GL. has successfully rekeyed the GL.
4.6 Change GLO 4.6 Change GLO
Management of managed and closed GLs can become difficult for one 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 GLs be managed by multiple GLOs. The workload, GLAs support having GLs be managed by multiple GLOs. The
glAddOwner and glRemoveOwner messages are designed to support adding glAddOwner and glRemoveOwner messages are designed to support adding
and removing registered GLOs. Figure 8 depicts the protocol and removing registered GLOs. Figure 8 depicts the protocol
Turner 52
interactions to send glAddOwner and glRemoveOwner messages and the interactions to send glAddOwner and glRemoveOwner messages and the
resulting response messages. resulting response messages.
Turner 53
+-----+ 1 2 +-----+ +-----+ 1 2 +-----+
| GLA | <-------> | GLO | | GLA | <-------> | GLO |
+-----+ +-----+ +-----+ +-----+
Figure 8 - GLO Add & Delete Owners Figure 8 - GLO Add & Delete Owners
The process for glAddOwner and glDeleteOwner is as follows: The process for glAddOwner and glDeleteOwner is as follows:
1 - The GLO sends a SignedData.PKIData.controlSequence.glAddOwner 1 - The GLO sends a SignedData.PKIData.controlSequence.glAddOwner
or glRemoveOwner 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 name in includes: the GL name in glName, the name and address of the
glOwnerName, and the GLOĘs address in glOwnerAddress. GLO in glOwnerName and glOwnerAddress, respectively.
1.a - The GLO MAY optionally apply confidentiality to the request 1.a - The GLO can optionally apply confidentiality to the request
by encapsulating the SignedData.PKIData in an EnvelopedData by encapsulating the SignedData.PKIData in an EnvelopedData
(see section 3.2.1.2). (see section 3.2.1.2).
1.b - The GLO MAY also optionally apply another SignedData over 1.b - The GLO can also optionally apply another SignedData over
the EnvelopedData (see section 3.2.1.2). the EnvelopedData (see section 3.2.1.2).
2 - Upon receipt of the glAddOwner or glRemoveOwner 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 signature(s). If an additional SignedData
SignedData and/or EnvelopedData encapsulates the request (see and/or EnvelopedData encapsulates the request (see section
section 3.2.1.2 or 3.2.2), the GLA MUST verify the outer 3.2.1.2 or 3.2.2), the GLA verifies the outer signature and/or
signature and/or decrypt the outer layer prior to verifying decrypt the outer layer prior to verifying the signature on
the signature on the inner most SignedData. the inner most SignedData.
2.a - If the signatures do not verify, the GLA MUST return a 2.a - If the signatures cannot verified, the GLA returns a
cMCStatusInfoEx response indicating cMCStatus.failed and cMCStatusInfoEx response indicating cMCStatus.failed and
otherInfo.failInfo.badMessageCheck. otherInfo.failInfo.badMessageCheck.
2.b - Else the signatures do verify, the GLA MUST make sure the GL 2.b - Else if the signatures verify, the GLA makes sure the GL is
is supported by checking that the glName matches a glName supported by checking that the glName matches a glName
stored on the GLA. stored on the GLA.
2.b.1 - If the glName is not supported by the GLA, the GLA MUST 2.b.1 - If the glName is not supported by the GLA, the GLA returns
return a response indicating cMCStatusInfoEx with a response indicating cMCStatusInfoEx with
cMCStatus.failed and cMCStatus.failed and
otherInfo.extendedFailInfo.SKDFailInfo value of otherInfo.extendedFailInfo.SKDFailInfo value of
invalidGLName. invalidGLName.
2.b.2 - Else the glName is supported by the GLA, the GLA MUST 2.b.2 - Else if the glName is supported by the GLA, the GLA
ensure a registered GLO signed the glAddOwner or ensures a registered GLO signed the glAddOwner or
glRemoveOwner request by checking that one of the names glRemoveOwner request by checking that one of the names
present in the digital signature certificate used to sign present in the digital signature certificate used to sign
the glAddOwner or glDeleteOwner request matches the name the glAddOwner or glDeleteOwner request matches the name
of a registered GLO. of a registered GLO.
Turner 53 2.b.2.a - If the names do not match, the GLA returns a response
2.b.2.a - If the names do not match, the GLA MUST return a indicating cMCStatusInfoEx with cMCStatus.failed and
response indicating cMCStatusInfoEx with
cMCStatus.failed and
otherInfo.extendedFailInfo.SKDFailInfo value of otherInfo.extendedFailInfo.SKDFailInfo value of
noGLONameMatch. noGLONameMatch.
2.b.2.b - Else the names do match, the GLA MUST return a Turner 54
2.b.2.b - Else if the names match, the GLA returns a
cMCStatusInfoEx.cMCStatus.success (2 in Figure 4). The cMCStatusInfoEx.cMCStatus.success (2 in Figure 4). The
GLA MUST also take administrative actions to associate GLA also takes administrative actions to associate the
the new glOwnerName with the GL in the case of new glOwnerName with the GL in the case of glAddOwner or
glAddOwner or to disassociate the old glOwnerName with to disassociate the old glOwnerName with the GL in the
the GL in the cased of glRemoveOwner. cased of glRemoveOwner.
2.b.2.b.1 - The GLA MUST apply confidentiality to the response by 2.b.2.b.1 - The GLA applies confidentiality to the response by
encapsulating the SignedData.PKIResponse in an encapsulating the SignedData.PKIResponse in an
EnvelopedData if the request was encapsulated in an EnvelopedData if the request was encapsulated in an
EnvelopedData (see section 3.2.1.2). EnvelopedData (see section 3.2.1.2).
2.b.2.b.2 - The GLA MAY also optionally apply another SignedData 2.b.2.b.2 - The GLA can also optionally apply another SignedData
over the EnvelopedData (see section 3.2.1.2). over the EnvelopedData (see section 3.2.1.2).
3 - Upon receipt of the cMCStatusInfoEx response, the GLO verifies 3 - Upon receipt of the cMCStatusInfoEx 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 response (see section 3.2.1.2 EnvelopedData encapsulates the response (see section 3.2.1.2
or 3.2.2), the GLO MUST verify the outer signature and/or or 3.2.2), the GLO verifies the outer signature and/or decrypt
decrypt the outer layer prior to verifying the signature on the outer layer prior to verifying the signature on the inner
the inner most SignedData. most SignedData.
3.a - Else the signatures do verify, the GLO MUST check that one 3.a - If the signatures verify, the GLO checks that one of the
of the names in the certificate used to sign the response names in the certificate used to sign the response matches
matches the name of the GL. the name of the GL.
3.a.1 ū If the GLĘs name does not match the name present in the 3.a.1 ū If the name of GL does not match the name present in the
certificate used to sign the message, the GLO should not certificate used to sign the message, the GLO should not
believe the response. believe the response.
3.a.2 ū Else the GLĘs name does match the name present in the 3.a.2 ū Else if the name of the GL does match the name present in
certificate and: the certificate and:
3.a.2.a - If the signatures do verify and the response was 3.a.2.a - If the signatures verify and the response was
cMCStatusInfoEx.cMCStatus.success, the GLO has cMCStatusInfoEx.cMCStatus.success, the GLO has
successfully added or removed the GLO. successfully added or removed the GLO.
3.a.2.b - Else the signatures do verify and the response was 3.a.2.b - Else if the signatures verify and the response was
cMCStatusInfoEx.cMCStatus.failed for any reason, the GLO cMCStatusInfoEx.cMCStatus.failed with any reason, the
MAY reattempt to add or delete the GLO using the GLO can reattempt to add or delete the GLO using the
information provided in the response. information provided in the response.
Turner 54
4.7 Indicate KEK Compromise 4.7 Indicate KEK Compromise
The will be times when the shared KEK is compromised. GL members and There will be times when the shared KEK is compromised. GL members
GLOs use glkCompromise to tell the GLA that the shared KEK has been and GLOs use glkCompromise to tell the GLA that the shared KEK has
compromised. Figure 9 depicts the protocol interactions for GL Key been compromised. Figure 9 depicts the protocol interactions for GL
Compromise. Key Compromise.
Turner 55
+-----+ 2{1} 4 +----------+ +-----+ 2{1} 4 +----------+
| GLO | <----------+ +-------> | Member 1 | | GLO | <----------+ +-------> | Member 1 |
+-----+ 5,3{1} | | +----------+ +-----+ 5,3{1} | | +----------+
+-----+ <----------+ | 4 +----------+ +-----+ <----------+ | 4 +----------+
| GLA | 1 +-------> | ... | | GLA | 1 +-------> | ... |
+-----+ <---------------+ +----------+ +-----+ <---------------+ +----------+
| 4 +----------+ | 4 +----------+
+-------> | Member n | +-------> | Member n |
+----------+ +----------+
Figure 9 - GL Key Compromise Figure 9 - GL Key Compromise
4.7.1 GL Member Initiated KEK Compromise Message 4.7.1 GL Member Initiated KEK Compromise Message
The process for GL member initiated glkCompromise messages is as The process for GL member initiated glkCompromise messages is as
follows: follows:
1 - The GL member sends a 1 - The GL member sends a
SignedData.PKIData.controlSequence.glkCompromise request to SignedData.PKIData.controlSequence.glkCompromise request to
the GLA (1 in Figure 9). The GL member MUST include the GLĘs the GLA (1 in Figure 9). The GL member includes the name of
name in GeneralName. the GL in GeneralName.
1.a - The GL member MAY optionally apply confidentiality to the 1.a - The GL member can optionally apply confidentiality to the
request by encapsulating the SignedData.PKIData in an request by encapsulating the SignedData.PKIData in an
EnvelopedData (see section 3.2.1.2). The glkCompromise MUST EnvelopedData (see section 3.2.1.2). The glkCompromise can
NOT be included in an EnvelopedData generated with the be included in an EnvelopedData generated with the
compromised shared KEK. compromised shared KEK.
1.b - The GL member MAY also optionally apply another SignedData 1.b - The GL member can also optionally apply another SignedData
over the EnvelopedData (see section 3.2.1.2). over the EnvelopedData (see section 3.2.1.2).
2 - Upon receipt of the glkCompromise request, the GLA verifies 2 - Upon receipt of the glkCompromise request, the GLA verifies
the GL member's signature(s). If an additional SignedData the GL member signature(s). If an additional SignedData and/or
and/or EnvelopedData encapsulates the request (see section EnvelopedData encapsulates the request (see section 3.2.1.2 or
3.2.1.2 or 3.2.2), the GLA MUST verify the outer signature 3.2.2), the GLA verifies the outer signature and/or decrypt
and/or decrypt the outer layer prior to verifying the the outer layer prior to verifying the signature on the inner
signature on the inner most SignedData. most SignedData.
2.a - If the signatures do not verify, the GLA MUST return a 2.a - If the signatures cannotbe verified, the GLA returns a
cMCStatusInfoEx response indicating cMCStatus.failed and cMCStatusInfoEx response indicating cMCStatus.failed and
otherInfo.failInfo.badMessageCheck. otherInfo.failInfo.badMessageCheck.
2.b - Else the signatures do verify, the GLA MUST make sure the GL 2.b - Else if the signatures verify, the GLA makes sure the GL is
is supported by checking that the indicated GL name matches supported by checking that the indicated GL name matches a
a glName stored on the GLA. glName stored on the GLA.
Turner 55 2.b.1 - If the glName is not supported by the GLA, the GLA returns
2.b.1 - If the glName is not supported by the GLA, the GLA MUST a response indicating cMCStatusInfoEx with
return a response indicating cMCStatusInfoEx with
cMCStatus.failed and cMCStatus.failed and
otherInfo.extendedFailInfo.SKDFailInfo value of otherInfo.extendedFailInfo.SKDFailInfo value of
invalidGLName. invalidGLName.
2.b.2 - Else the glName is supported by the GLA, the GLA MUST Turner 56
check who signed the request. For GLOs, one of the names 2.b.2 - Else if the glName is supported by the GLA, the GLA checks
in the certificate used to sign the request MUST match a who signed the request. For GLOs, one of the names in the
registered GLO. For the prospective member, the name in certificate used to sign the request needs to match a
glMember.glMemberName MUST match one of the names in the registered GLO. For the member, the name in
certificate used to sign the request. glMember.glMemberName needs to match one of the names in
the certificate used to sign the request.
2.b.2.a - If the GLO signed the request, the GLA MUST generate a 2.b.2.a - If the GLO signed the request, the GLA generates a glKey
glKey message as described in section 5 to rekey the GL message as described in section 5 to rekey the GL (4 in
(4 in Figure 9). Figure 9).
2.b.2.b - Else anyone else signed the request, the GLA MUST 2.b.2.b - Else if someone other than the GLO signed the request,
forward the glkCompromise message (see section 3.2.3) to the GLA forwards the glkCompromise message (see section
the GLO (2{1} in Figure 9). If there is more than one 3.2.3) to the GLO (2{1} in Figure 9). If there is more
GLO, to which GLO the request is forwarded is beyond the than one GLO, to which GLO the request is forwarded is
scope of this document. Further processing by the GLO is beyond the scope of this document. Further processing by
discussed in section 4.7.2. the GLO is discussed in section 4.7.2.
4.7.2 GLO Initiated KEK Compromise Message 4.7.2 GLO Initiated KEK Compromise Message
The process for GLO initiated glkCompromise messages is as follows: The process for GLO initiated glkCompromise messages is as follows:
1 - The GLO either: 1 - The GLO either:
1.a - Generates the glkCompromise message itself by sending a 1.a - Generates the glkCompromise message itself by sending a
SignedData.PKIData.controlSequence.glkCompromise request to SignedData.PKIData.controlSequence.glkCompromise request to
the GLA (5 in Figure 9). The GLO MUST include the name of the GLA (5 in Figure 9). The GLO includes the name of the GL
the GL in GeneralName. in GeneralName.
1.a.1 - The GLO MAY optionally apply confidentiality to the 1.a.1 - The GLO can optionally apply confidentiality to the
request by encapsulating the SignedData.PKIData in an request by encapsulating the SignedData.PKIData in an
EnvelopedData (see section 3.2.1.2). The glkCompromise EnvelopedData (see section 3.2.1.2). The glkCompromise can
MUST NOT be included in an EnvelopedData generated with be included in an EnvelopedData generated with the
the compromised shared KEK. compromised shared KEK.
1.a.2 - The GLO MAY also optionally apply another SignedData over 1.a.2 - The GLO can also optionally apply another SignedData over
the EnvelopedData (see section 3.2.1.2). the EnvelopedData (see section 3.2.1.2).
1.b - Verifies the GLAĘs and GL memberĘs signatures on the 1.b ū Otherwise, verifies the GLA and GL member signatures on the
forwarded glkCompromise message. If an additional SignedData forwarded glkCompromise message. If an additional SignedData
and/or EnvelopedData encapsulates the request (see section and/or EnvelopedData encapsulates the request (see section
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 verifies 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.
Turner 56 1.b.1 - If the signatures cannot be verified, the GLO returns a
1.b.1 - If the signatures do not verify, the GLO MUST return a
cMCStatusInfoEx response indicating cMCStatus.failed and cMCStatusInfoEx response indicating cMCStatus.failed and
otherInfo.failInfo.badMessageCheck. otherInfo.failInfo.badMessageCheck.
1.b.1.a - If the signatures do verify, the GLO MUST check the 1.b.1.a - If the signatures verify, the GLO checks the names in
names in the certificate match the name of the signer the certificate match the name of the signer (i.e., the
(i.e., the name in the certificate used to sign the GL
memberĘs request is the GL member).
1.b.1.a.1 ū If either name does not match, the GLO should not Turner 57
trust the signer and it should not forward the message name in the certificate used to sign the GL memberĘs
to the GLA. request is the GL member).
1.b.1.a.2 ū Else the names do match, the signatures do verify, the 1.b.1.a.1 ū If either name does not match, the GLO ought not trust
GLO MUST determine whether to forward the the signer and it ought not forward the message to the
glkCompromise message back to the GLA (3{1} in Figure GLA.
9). Further processing by the GLA is in 2 of section
4.7.1. The GLO MAY also return a response to the 1.b.1.a.2 ū Else if the names match and the signatures verify, the
prospective member with GLO determines whether to forward the glkCompromise
cMCStatusInfoEx.cMCtatus.success indicating that the message back to the GLA (3{1} in Figure 9). Further
glkCompromise message was successfully received. processing by the GLA is in 2 of section 4.7.1. The
GLO can also return a response to the prospective
member with cMCStatusInfoEx.cMCtatus.success
indicating that the glkCompromise message was
successfully received.
4.8 Request KEK Refresh 4.8 Request KEK Refresh
There will be times when GL members have misplaced their shared KEK. There will be times when GL members have unrecoverably lost their
The shared KEK is not compromised and a rekey of the entire GL is shared KEK. The shared KEK is not compromised and a rekey of the
not necessary. GL members use the glkRefresh message to request that entire GL is not necessary. GL members use the glkRefresh message to
the shared KEK(s) be redistributed to them. Figure 10 depicts the request that the shared KEK(s) be redistributed to them. Figure 10
protocol interactions for GL Key Refresh. depicts the protocol interactions for GL Key Refresh.
+-----+ 1 2 +----------+ +-----+ 1 2 +----------+
| GLA | <-----------> | Member | | GLA | <-----------> | Member |
+-----+ +----------+ +-----+ +----------+
Figure 10 - GL KEK Refresh Figure 10 - GL KEK Refresh
The process for glkRefresh is as follows: The process for glkRefresh is as follows:
1 - The GL member sends a 1 - The GL member sends a
SignedData.PKIData.controlSequence.glkRefresh request to the SignedData.PKIData.controlSequence.glkRefresh request to the
GLA (1 in Figure 10). The GL member MUST include name of the GLA (1 in Figure 10). The GL member includes name of the GL in
GL in GeneralName. GeneralName.
1.a - The GL member MAY optionally apply confidentiality to the 1.a - The GL member can optionally apply confidentiality to the
request by encapsulating the SignedData.PKIData in an request by encapsulating the SignedData.PKIData in an
EnvelopedData (see section 3.2.1.2). EnvelopedData (see section 3.2.1.2).
1.b - The GL member MAY also optionally apply another SignedData 1.b - The GL member can also optionally apply another SignedData
over the EnvelopedData (see section 3.2.1.2). over the EnvelopedData (see section 3.2.1.2).
Turner 57
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 signature(s). If an additional SignedData and/or
EnvelopedData encapsulates the request (see section 3.2.1.2 or EnvelopedData encapsulates the request (see section 3.2.1.2 or
3.2.2), the GLA MUST verify the outer signature and/or decrypt 3.2.2), the GLA verifies the outer signature and/or decrypt
the outer layer prior to verifying the signature on the inner the outer layer prior to verifying the signature on the inner
most SignedData. most SignedData.
2.a - If the signatures do not verify, the GLA MUST return a Turner 58
2.a - If the signatures cannot be verified, the GLA returns a
cMCStatusInfoEx response indicating cMCStatus.failed and cMCStatusInfoEx response indicating cMCStatus.failed and
otherInfo.failInfo.badMessageCheck. otherInfo.failInfo.badMessageCheck.
2.b - Else the signatures do verify, the GLA MUST make sure the GL 2.b - Else if the signatures verify, the GLA makes sure the GL is
is supported by checking that the GLĘs GeneralName matches a supported by checking that the GLGeneralName matches a
glName stored on the GLA. glName stored on the GLA.
2.b.1 - If the GLĘs name is not supported by the GLA, the GLA MUST 2.b.1 - If the name of the GL is not supported by the GLA, the GLA
return a response indicating cMCStatusInfoEx with returns a response indicating cMCStatusInfoEx with
cMCStatus.failed and cMCStatus.failed and
otherInfo.extendedFailInfo.SKDFailInfo value of otherInfo.extendedFailInfo.SKDFailInfo value of
invalidGLName. invalidGLName.
2.b.2 - Else the glName is supported by the GLA, the GLA MUST 2.b.2 ū Else if the glName is supported by the GLA, the GLA
ensure the GL member is on the GL. ensures the GL member is on the GL.
2.b.2.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 cMCStatusInfoEx with returns a response indicating cMCStatusInfoEx with
cMCStatus.failed and cMCStatus.failed and
otherInfo.extendedFailInfo.SKDFailInfo value of noSpam. otherInfo.extendedFailInfo.SKDFailInfo value of noSpam.
2.b.2.b - Else the glMemberName is present on the GL, the GLA MUST 2.b.2.b - Else if the glMemberName is present on the GL, the GLA
return a cMCStatusInfoEx.cMCStatus.success and a glKey returns a cMCStatusInfoEx.cMCStatus.success and a glKey
message (2 in Figure 10) as described in section 5. message (2 in Figure 10) as described in section 5.
4.9 GLA Query Request and Response 4.9 GLA Query Request and Response
There will be certain times when a GLO is having trouble setting up There will be certain times when a GLO is having trouble setting up
a GL because they do not know the algorithm(s) or some other a GL because they do not know the algorithm(s) or some other
characteristic that the GLA supports. There may also be times when characteristic that the GLA supports. There can also be times when
prospective GL members or GL members need to know something about prospective GL members or GL members need to know something about
the GLA (these requests are not defined in the document). The the GLA (these requests are not defined in the document). The
glaQueryRequest and glaQueryResponse message have been defined to glaQueryRequest and glaQueryResponse message have been defined to
support determining this information. Figure 11 depicts the protocol support determining this information. Figure 11 depicts the protocol
interactions for glaQueryRequest and glaQueryResponse. interactions for glaQueryRequest and glaQueryResponse.
+-----+ 1 2 +------------------+ +-----+ 1 2 +------------------+
| GLA | <-------> | GLO or GL Member | | GLA | <-------> | GLO or GL Member |
+-----+ +------------------+ +-----+ +------------------+
Figure 11 - GLA Query Request & Response Figure 11 - GLA Query Request & Response
Turner 58
The process for glaQueryRequest and glaQueryResponse is as follows: The process for glaQueryRequest and glaQueryResponse is as follows:
1 - The GLO, GL member, or prospective GL member sends a 1 - The GLO, GL member, or prospective GL member sends a
SignedData.PKIData.controlSequence.glaQueryRequest request to SignedData.PKIData.controlSequence.glaQueryRequest request to
the GLA (1 in Figure 11). The GLO, GL member, or prospective the GLA (1 in Figure 11). The GLO, GL member, or prospective
Turner 59
GL member indicates the information they are interested in GL member indicates the information they are interested in
receiving from the GLA. receiving from the GLA.
1.a - The GLO, GL member, or prospective GL member MAY optionally 1.a - The GLO, GL member, or prospective GL member can optionally
apply confidentiality to the request by encapsulating the apply confidentiality to the request by encapsulating the
SignedData.PKIData in an EnvelopedData (see section SignedData.PKIData in an EnvelopedData (see section
3.2.1.2). 3.2.1.2).
1.b - The GLO, GL member, or prospective GL member MAY also 1.b - The GLO, GL member, or prospective GL member can also
optionally apply another SignedData over the EnvelopedData optionally apply another SignedData over the EnvelopedData
(see section 3.2.1.2). (see section 3.2.1.2).
2 - Upon receipt of the glaQueryRequest, the GLA determines if it 2 - Upon receipt of the glaQueryRequest, the GLA determines if it
accepts glaQueryRequest messages. accepts glaQueryRequest messages.
2.a - If the GLA does not accept glaQueryRequest messages, the GLA 2.a - If the GLA does not accept glaQueryRequest messages, the GLA
MUST return a cMCStatusInfoEx response indicating returns a cMCStatusInfoEx response indicating
cMCStatus.noSupport and any other information in cMCStatus.noSupport and any other information in
statusString. statusString.
2.b - Else the GLA does accept GLAQueryRequests, the GLA MUST 2.b - Else if the GLA does accept GLAQueryRequests, the GLA
verify the GLO's, GL memberĘs, or prospective GL memberĘs verifies the GLO, GL member, or prospective GL member
signature(s). If an additional SignedData and/or signature(s). If an additional SignedData and/or
EnvelopedData encapsulates the request (see section 3.2.1.2 EnvelopedData encapsulates the request (see section 3.2.1.2
or 3.2.2), the GLA MUST verify the outer signature and/or or 3.2.2), the GLA verifies 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.
2.b.1 - If the signatures do not verify, the GLA MUST return a 2.b.1 - If the signatures cannot be verified, the GLA returns a
cMCStatusInfoEx response indicating cMCStatus.failed and cMCStatusInfoEx response indicating cMCStatus.failed and
otherInfo.failInfo.badMessageCheck. otherInfo.failInfo.badMessageCheck.
2.b.2 - Else the signatures do verify, the GLA MUST return a 2.b.2 - Else if the signatures verify, the GLA returns a
glaQueryResponse (2 in Figure 11) with the correct glaQueryResponse (2 in Figure 11) with the correct
response if the glaRequestType is supported or return a response if the glaRequestType is supported or return a
cMCStatusInfoEx response indicating cMCStatus.noSupport if cMCStatusInfoEx response indicating cMCStatus.noSupport if
the glaRequestType is not supported. the glaRequestType is not supported.
2.b.2.a - The GLA MUST apply confidentiality to the response by 2.b.2.a - The GLA applies confidentiality to the response by
encapsulating the SignedData.PKIResponse in an encapsulating the SignedData.PKIResponse in an
EnvelopedData if the request was encapsulated in an EnvelopedData if the request was encapsulated in an
EnvelopedData (see section 3.2.1.2). EnvelopedData (see section 3.2.1.2).
2.b.2.b - The GLA MAY also optionally apply another SignedData 2.b.2.b - The GLA can also optionally apply another SignedData
over the EnvelopedData (see section 3.2.1.2). over the EnvelopedData (see section 3.2.1.2).
Turner 59
3 - Upon receipt of the glaQueryResponse, the GLO, GL member, or 3 - Upon receipt of the glaQueryResponse, the GLO, GL member, or
prospective GL member verifies the GLA's signature(s). If an prospective GL member verifies the GLA signature(s). If an
additional SignedData and/or EnvelopedData encapsulates the additional SignedData and/or EnvelopedData encapsulates the
response (see section 3.2.1.2 or 3.2.2), the GLO, GL member, response (see section 3.2.1.2 or 3.2.2), the GLO, GL member,
or prospective GL member MUST verify the outer signature or prospective GL member verifies the outer signature and/or
and/or decrypt the outer layer prior to verifying the
signature on the inner most SignedData. Turner 60
decrypt the outer layer prior to verifying the signature on
the inner most SignedData.
3.a - If the signatures do not verify, the GLO, GL member, or 3.a - If the signatures do not verify, the GLO, GL member, or
prospective GL member MUST return a cMCStatusInfoEx response prospective GL member returns a cMCStatusInfoEx response
indicating cMCStatus.failed and indicating cMCStatus.failed and
otherInfo.failInfo.badMessageCheck. otherInfo.failInfo.badMessageCheck.
3.b - Else the signatures do verify, the GLO, GL member, or 3.b - Else if the signatures verify, then the GLO, GL member, or
prospective GL member MUST check that one of the names in prospective GL member checks that one of the names in the
the certificate used to sign the response matches the name certificate used to sign the response matches the name of
of the GL. the GL.
3.b.1 ū If the GLĘs name does not match the name present in the 3.b.1 ū If the name of the GL does not match the name present in
certificate used to sign the message, the GLO should not the certificate used to sign the message, the GLO ought
believe the response. not believe the response.
3.b.2 - Else the GLĘs name does match the name present in the 3.b.2 - Else if the name of the GL matches the name present in the
certificate and the response was glaQueryResponse, the GLO, certificate and the response was glaQueryResponse, then
GL member, or prospective GL member may use the information the GLO, GL member, or prospective GL member may use the
contained therein. information contained therein.
4.10 Update Member Certificate 4.10 Update Member Certificate
When the GLO generates a glAddMember request, when the GLA generates When the GLO generates a glAddMember request, when the GLA generates
a glKey message, or when the GLA processes a glAddMember there may a glKey message, or when the GLA processes a glAddMember there can
be instances when GL memberĘs certificate has expired or is invalid. 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 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 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 generate a glKey message for the GL member. There might also be
when the GL member knows their certificate is about to expire or has times when the GL member knows their certificate is about to expire
been revoked and they will not be able to receive GL rekeys. or has been revoked and they will not be able to receive GL rekeys.
4.10.1 GLO and GLA Initiated Update Member Certificate 4.10.1 GLO and GLA Initiated Update Member Certificate
The process for GLO initiated glUpdateCert is as follows: The process for GLO initiated glUpdateCert is as follows:
1 - The GLO or GLA sends a 1 - The GLO or GLA sends a
SignedData.PKIData.controlSequence.glProvideCert request to SignedData.PKIData.controlSequence.glProvideCert request to
the GL member. The GLO or GLA indicates the GL name in glName the GL member. The GLO or GLA indicates the GL name in glName
and the GL memberĘs name in glMemberName. and the GL member name in glMemberName.
1.a - The GLO or GLA MAY optionally apply confidentiality to the 1.a - The GLO or GLA can optionally apply confidentiality to the
request by encapsulating the SignedData.PKIData in an request by encapsulating the SignedData.PKIData in an
EnvelopedData (see section 3.2.1.2). If the GL memberĘs PKC EnvelopedData (see section 3.2.1.2). If the GL memberĘs PKC
has been revoked, the GLO or GLA MUST NOT use it to generate has been revoked, the GLO or GLA ought not use it to
generate the EnvelopedData that encapsulates the
Turner 60 glProvideCert request.
the EnvelopedData that encapsulates the glProvideCert
request.
1.b - The GLO or GLA MAY also optionally apply another SignedData 1.b - The GLO or GLA can also optionally apply another SignedData
over the EnvelopedData (see section 3.2.1.2). over the EnvelopedData (see section 3.2.1.2).
Turner 61
2 - Upon receipt of the glProvideCert message, the GL member 2 - Upon receipt of the glProvideCert message, the GL member
verifies the GLOĘs or GLAĘs signature(s). If an additional verifies the GLO or GLA signature(s). If an additional
SignedData and/or EnvelopedData encapsulates the response (see SignedData and/or EnvelopedData encapsulates the response (see
section 3.2.1.2 or 3.2.2), the GL member MUST verify the outer section 3.2.1.2 or 3.2.2), the GL member verifies 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.
2.a - If the signatures do not verify, the GL member MUST return a 2.a - If the signatures cannot be verified, the GL member returns
cMCStatusInfoEx response indicating cMCStatus.failed and a cMCStatusInfoEx response indicating cMCStatus.failed and
otherInfo.failInfo.badMessageCheck. otherInfo.failInfo.badMessageCheck.
2.b - Else the signatures do verify, the GL member generates a 2.b - Else if the signatures verify, the GL member generates a
Signed.PKIResponse.controlSequence.glUpdateCert that MUST Signed.PKIResponse.controlSequence.glUpdateCert that
include the GL name in glName, the member's name in includes the GL name in glName, the member name in
glMember.glMemberName, their encryption certificate in glMember.glMemberName, their encryption certificate in
glMember.certificates.pKC. The GL member MAY also include glMember.certificates.pKC. The GL member can also include
any attribute certificates associated with their encryption any attribute certificates associated with their encryption
certificate in glMember.certificates.aC, and the certificate in glMember.certificates.aC, and the
certification path associated with their encryption and certification path associated with their encryption and
attribute certificates in attribute certificates in glMember.certificates.certPath.
glMember.certificates.certificationPath.
2.a - The GL member MAY optionally apply confidentiality to the 2.a - The GL member can optionally apply confidentiality to the
request by encapsulating the SignedData.PKIResponse in an request by encapsulating the SignedData.PKIResponse in an
EnvelopedData (see section 3.2.1.2). If the GL memberĘs PKC EnvelopedData (see section 3.2.1.2). If the GL memberĘs PKC
has been revoked, the GL member MUST NOT use it to generate has been revoked, the GL member ought not use it to generate
the EnvelopedData that encapsulates the glProvideCert the EnvelopedData that encapsulates the glProvideCert
request. request.
2.b - The GL member MAY also optionally apply another SignedData 2.b - The GL member can also optionally apply another SignedData
over the EnvelopedData (see section 3.2.1.2). over the EnvelopedData (see section 3.2.1.2).
3 - Upon receipt of the glUpdateCert message, the GLO or GLA 3 - Upon receipt of the glUpdateCert message, the GLO or GLA
verifies the GL memberĘs signature(s). If an additional verifies the GL member signature(s). If an additional
SignedData and/or EnvelopedData encapsulates the response (see SignedData and/or EnvelopedData encapsulates the response (see
section 3.2.1.2 or 3.2.2), the GL member MUST verify the outer section 3.2.1.2 or 3.2.2), the GL member verifies 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.
3.a - If the signatures do not verify, the GLO or GLA MUST return 3.a - If the signatures cannot be verified, the GLO or GLA returns
a cMCStatusInfoEx response indicating cMCStatus.failed and a cMCStatusInfoEx response indicating cMCStatus.failed and
otherInfo.failInfo.badMessageCheck. otherInfo.failInfo.badMessageCheck.
3.b - Else the signatures do verify, the GLO or GLA MUST verify 3.b - Else if the signatures verify, the GLO or GLA verifies the
the memberĘs encryption certificate. memberĘs encryption certificate.
Turner 61 3.b.1 - If the memberĘs encryption certificate cannot be verified,
3.b.1 - If the memberĘs encryption certificate does not verify, the GLO returns either another glProvideCert request or a
the GLO MAY return either another glProvideCert request or cMCStatusInfoEx with cMCStatus.failed and the reason why
a cMCStatusInfoEx with cMCStatus.failed and the reason why
in cMCStatus.statusString. glProvideCert should be in cMCStatus.statusString. glProvideCert should be
returned only a certain number of times because if the GL returned only a certain number of times because if the GL
Turner 62
member does not have a valid certificate they will never member does not have a valid certificate they will never
be able to return one. be able to return one.
3.b.2 - Else the memberĘs encryption certificate does not verify, 3.b.2 - Else if the memberĘs encryption certificate cannot be
the GLA MAY return another glProvideCert request to the GL verified, the GLA returns another glProvideCert request to
member or a cMCStatusInfoEx with cMCStatus.failed and the the GL member or a cMCStatusInfoEx with cMCStatus.failed
reason why in cMCStatus.statusString to the GLO. and the reason why in cMCStatus.statusString to the GLO.
glProvideCert should be returned only a certain number of glProvideCert should be returned only a certain number of
times because if the GL member does not have a valid times because if the GL member does not have a valid
certificate they will never be able to return one. certificate they will never be able to return one.
3.b.3 - Else the memberĘs encryption certificate does verify, the 3.b.3 - Else if the memberĘs encryption certificate verifies, the
GLO or GLA will use it in subsequent glAddMember requests GLO or GLA will use it in subsequent glAddMember requests
and glKey messages associated with the GL member. and glKey messages associated with the GL member.
4.10.2 GL Member Initiated Update Member Certificate 4.10.2 GL Member Initiated Update Member Certificate
The process for an unsolicited GL member glUpdateCert is as follows: The process for an unsolicited GL member glUpdateCert is as follows:
1 - The GL member sends a 1 - The GL member sends a
Signed.PKIData.controlSequence.glUpdateCert that MUST include Signed.PKIData.controlSequence.glUpdateCert that includes the
the GL name in glName, the member's name in GL name in glName, the member name in glMember.glMemberName,
glMember.glMemberName, their encryption certificate in their encryption certificate in glMember.certificates.pKC. The
glMember.certificates.pKC. The GL member MAY also include any GL member can also include any attribute certificates
attribute certificates associated with their encryption associated with their encryption certificate in
certificate in glMember.certificates.aC, and the certification glMember.certificates.aC, and the certification path
path associated with their encryption and attribute associated with their encryption and attribute certificates in
certificates in glMember.certificates.certificationPath. glMember.certificates.certPath.
1.a - The GL member MAY optionally apply confidentiality to the 1.a - The GL member can optionally apply confidentiality to the
request by encapsulating the SignedData.PKIData in an request by encapsulating the SignedData.PKIData in an
EnvelopedData (see section 3.2.1.2). If the GL memberĘs PKC EnvelopedData (see section 3.2.1.2). If the GL memberĘs PKC
has been revoked, the GLO or GLA MUST NOT use it to generate has been revoked, the GLO or GLA ought not use it to
the EnvelopedData that encapsulates the glProvideCert generate the EnvelopedData that encapsulates the
request. glProvideCert request.
1.b - The GL member MAY also optionally apply another SignedData 1.b - The GL member can also optionally apply another SignedData
over the EnvelopedData (see section 3.2.1.2). over the EnvelopedData (see section 3.2.1.2).
2 - Upon receipt of the glUpdateCert message, the GLA verifies the 2 - Upon receipt of the glUpdateCert message, the GLA verifies the
GL memberĘs signature(s). If an additional SignedData and/or GL member signature(s). If an additional SignedData and/or
EnvelopedData encapsulates the response (see section 3.2.1.2 EnvelopedData encapsulates the response (see section 3.2.1.2
or 3.2.2), the GLA MUST verify the outer signature and/or or 3.2.2), the GLA verifies the outer signature and/or decrypt
decrypt the outer layer prior to verifying the signature on the outer layer prior to verifying the signature on the inner
the inner most SignedData. most SignedData.
Turner 62 2.a - If the signatures cannot be verified, the GLA returns a
2.a - If the signatures do not verify, the GLA MUST return a
cMCStatusInfoEx response indicating cMCStatus.failed and cMCStatusInfoEx response indicating cMCStatus.failed and
otherInfo.failInfo.badMessageCheck. otherInfo.failInfo.badMessageCheck.
2.b - Else the signatures do verify, the GLA MUST verify the Turner 63
memberĘs encryption certificate. 2.b - Else if the signatures verify, the GLA verifies the memberĘs
encryption certificate.
2.b.1 - If the memberĘs encryption certificate does not verify, 2.b.1 - If the memberĘs encryption certificate cannot be verified,
the GLA MAY return another glProvideCert request to the GL the GLA returns another glProvideCert request to the GL
member or a cMCStatusInfoEx with cMCStatus.failed and the member or a cMCStatusInfoEx with cMCStatus.failed and the
reason why in cMCStatus.statusString to the GLO. reason why in cMCStatus.statusString to the GLO.
glProvideCert should be returned only a certain number of glProvideCert ought not be returned indefinitely; if the
times because if the GL member does not have a valid GL member does not have a valid certificate they will
certificate they will never be able to return one. never be able to return one.
2.b.2 - Else the memberĘs encryption certificate does verify, the 2.b.2 - Else if the memberĘs encryption certificate verifies, the
GLA will use it in subsequent glAddMember requests and GLA will use it in subsequent glAddMember requests and
glKey messages associated with the GL member. The GLA MUST glKey messages associated with the GL member. The GLA also
also forward the glUpdateCert message to the GLO. forwards the glUpdateCert message to the GLO.
5 Distribution Message 5 Distribution Message
The GLA uses the glKey message to distribute new, shared KEK(s) The GLA uses the glKey message to distribute new, shared KEK(s)
after receiving glAddMember, glDeleteMember (for closed and managed after receiving glAddMember, glDeleteMember (for closed and managed
GLs), glRekey, glkCompromise, or glkRefresh requests and returning a GLs), glRekey, glkCompromise, or glkRefresh requests and returning a
cMCStatusInfoEx response for the respective request. Figure 12 cMCStatusInfoEx response for the respective request. Figure 12
depicts the protocol interactions to send out glKey messages. The depicts the protocol interactions to send out glKey messages. Unlike
procedures defined in this section MUST be implemented. the procedures defined for the administrative messages, the
procedures defined in this section MUST be implemented by GLAs for
origination and by GL members on reception.
1 +----------+ 1 +----------+
+-------> | Member 1 | +-------> | Member 1 |
| +----------+ | +----------+
+-----+ | 1 +----------+ +-----+ | 1 +----------+
| GLA | ----+-------> | ... | | GLA | ----+-------> | ... |
+-----+ | +----------+ +-----+ | +----------+
| 1 +----------+ | 1 +----------+
+-------> | Member n | +-------> | Member n |
+----------+ +----------+
Figure 12 - GL Key Distribution Figure 12 - GL Key Distribution
If the GL was setup with GLKeyAttributes.recipientsNotMutuallyAware If the GL was setup with GLKeyAttributes.recipientsNotMutuallyAware
set to FALSE, a separate glKey message MUST be sent to each GL set to FALSE, a separate glKey message MUST be sent to each GL
member so as to not divulge information about the other GL members. member so as to not divulge information about the other GL members.
Turner 64
When the glKey message is generated as a result of a: When the glKey message is generated as a result of a:
- glAddMember request, - glAddMember request,
- glkComrpomise indication, - glkComrpomise indication,
- glkRefresh request, - glkRefresh request,
Turner 63
- glDeleteMember request with the GLĘs glAdministration set to - glDeleteMember request with the GLĘs glAdministration set to
managed or closed, managed or closed, and
- glRekey request with generationCounter set to zero (0) - glRekey request with generationCounter set to zero (0).
The GLA MUST use either the kari (see section 12.3.2 of CMS [2]) or The GLA MUST use either the kari (see section 12.3.2 of CMS [2]) or
ktri (see section 12.3.1 of CMS [2]) choice in ktri (see section 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 ktri recipients receive the shared KEK. The GLA MUST support the ktri
choice. 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
skipping to change at line 3248 skipping to change at line 3300
MUST support the RecipientInfo.ktri choice. MUST support the RecipientInfo.ktri choice.
5.1 Distribution Process 5.1 Distribution Process
When a glKey message is generated the process is as follows: When a glKey message is generated the process is as follows:
1 - The GLA MUST send a SignedData.PKIData.controlSequence.glKey 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. If the GLA can glkAlgorithm, glkNotBefore, and glkNotAfter. If the GLA can
not generate a glKey message for the GL member because the GL 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 memberĘs PKC has expired or is otherwise invalid, the GLA MAY
glUpdateCert to the GL member requesting a new certificate be send a glUpdateCert to the GL member requesting a new
provided (see section 4.10). The number of glKey messages certificate be provided (see section 4.10). The number of
generated for the GL is described in section 3.1.16. glKey messages generated for the GL is described in section
3.1.16.
1.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 section 3.2.1.2). another EnvelopedData (see section 3.2.1.2).
1.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 section 3.2.1.2). the EnvelopedData.SignedData.PKIData (see section 3.2.1.2).
2 - Upon receipt of the glKey message, the GL members MUST verify 2 - Upon receipt of the glKey message, the GL members MUST verify
the signature over the inner most SignedData.PKIData. If an the 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 section 3.2.1.2 or 3.2.2), the GL Member MUST message (see section 3.2.1.2 or 3.2.2), the GL Member MUST
verify the outer signature and/or decrypt the outer layer 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.
2.a - If the signatures do not verify, the GL member MUST return a Turner 65
cMCStatusInfoEx response indicating cMCStatus.failed and 2.a - If the signatures cannot be verified, the GL member MUST
otherInfo.failInfo.badMessageCheck. return a cMCStatusInfoEx response indicating
cMCStatus.failed and otherInfo.failInfo.badMessageCheck.
2.b - Else the signatures do verify, the GL member process the 2.b - Else if the signatures verify, the GL member process the
RecipientInfos according to CMS [2]. Once unwrapped the GL RecipientInfos according to CMS [2]. Once unwrapped the GL
Turner 64
member should store the shared KEK in a safe place. When member should store the shared KEK in a safe place. When
stored, the glName, glIdentifier, and shared KEK should be stored, the glName, glIdentifier, and shared KEK should be
associated. Additionally, the GL member MUST return a associated. Additionally, the GL member MUST return a
cMCStatusInfoEx indicating cMCStatus.success to tell the GLA cMCStatusInfoEx indicating cMCStatus.success to tell the GLA
the key received. the KEK was received.
6 Algorithms 6 Algorithms
This section lists the algorithms that must be implemented. This section lists the algorithms that MUST be implemented.
Additional algorithms that should be implemented are also included. Additional algorithms that SHOULD be implemented are also included.
Further algorithms MAY also be implemented.
6.1 KEK Generation Algorithm 6.1 KEK Generation Algorithm
The shared KEK MUST be generated according to the security Implementations MUST randomly generate content-encryption keys,
considerations section in AlgSpec [9]. message-authentication keys, initialization vectors (IVs), and
padding. Also, the generation of public/private key pairs relies on
a random numbers. The use of inadequate pseudo-random number
generators (PRNGs) to generate cryptographic keys can result in
little or no security. An attacker may find it much easier to
reproduce the PRNG environment that produced the keys, searching the
resulting small set of possibilities, rather than brute force
searching the whole key space. The generation of quality random
numbers is difficult. RFC 1750 [10] offers important guidance in
this area, and Appendix 3 of FIPS Pub 186 [11] provides one quality
PRNG technique.
6.2 Shared KEK Wrap Algorithm 6.2 Shared KEK Wrap Algorithm
In the mechanisms described in sections 5, the shared KEK being In the mechanisms described in sections 5, the shared KEK being
distributed in glkWrapped MUST be protected by a key of equal or distributed in glkWrapped MUST be protected by a key of equal or
greater length (i.e., if a RC2 128-bit key is being distributed a 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). key of 128-bits or greater must be used to protect the key).
The algorithm object identifiers included in glkWrapped are as The algorithm object identifiers included in glkWrapped are as
specified in AlgSpec [9]. specified in AlgSpec [12].
6.3 Shared KEK Algorithm 6.3 Shared KEK Algorithm
The shared KEK distributed and indicated in glkAlgorithm MUST The shared KEK distributed and indicated in glkAlgorithm MUST
support the symmetric key-encryption algorithms as specified in support the symmetric key-encryption algorithms as specified in
section AlgSpec [9]. section AlgSpec [12].
7 Transport
SMTP [10] MUST be supported. All other transport mechanisms MAY be
supported.
8 Using the Group Key
This document was written with three specific scenarios in mind. Two
to support mail list agents and one for general message
distribution. Scenario 1 depicts the originator sending a public key
(PK) protected message to a MLA who then uses the shared KEK (S) to
redistribute the message to the members of the list. Scenario 2
depicts the originator sending a shared KEK protected message to a
MLA who then redistributes the message to the members of the list
Turner 65 Turner 66
(the MLA only adds additional recipients). Scenario 3 shows an
originator sending a shared KEK protected message to a group of
recipients without using the MLA.
+----> +----> +----> 7 Message Transport
PK +-----+ S | S +-----+ S | S |
----> | MLA | --+----> ----> | MLA | --+----> ----+---->
+-----+ | +-----+ | |
+----> +----> +---->
Scenario 1 Scenario 2 Scenario 3 SMTP [13] MUST be supported. Other transport mechanisms MAY also be
supported.
9 Security Considerations 8 Security Considerations
Only have GLOs that are trusted. As GLOs control setting up and tearing down the GL, rekeying the GL,
and can control member additions and deletions, GLOs play an
important role in the management of the GL, and only ōtrustedö GLOs
should be used.
Need to rekey closed and managed GLs if a member is deleted. If a member is deleted or removed from a closed or a managed GL, the
GL needs to be rekeyed. If the GL is not rekeyed after a member is
removed or deleted, the member still posses the group key and will
be able to continue to decrypt any messages that can be obtained.
GL members have to store some kind of information about who Members who store KEKs MUST associate the name of the GLA that
distributed the shared KEK to them so that they can make sure distributed the key so that the members can make sure subsequent
subsequent rekeys are originated from the same entity. rekeys are originated from the same entity.
Need to make sure you donĘt make the key size too small and duration When generating keys, care should be taken to ensure that the key
long because people will have more time to attack the key. size is not too small and duration too long because people will have
more time to attack the key. Key size should be selected to
adequately protect sensitive business communications.
Need to make sure you donĘt make the generationCounter to large GLOs and GLAs need to make sure that the generationCounter and
because people can attack the last key. If there are 14 keys duration are not too large. For example, if the GLO indicates that
outstanding each with a yearĘs duration attackers might be able the generationCounter is 14 and the duration is one year, then 14
determine the 14th key. keys are generated each with a validity period of a year. An
attacker will have at least 13 years to attack the final key.
Assume that two or more parties have a shared KEK, and the shared Assume that two or more parties have a shared KEK, and the shared
KEK is used to encrypt a second KEK for confidential distribution to KEK is used to encrypt a second KEK for confidential distribution to
those parties. The second KEK might be used to encrypt a third KEK; those parties. The second KEK might be used to encrypt a third KEK;
the third KEK might be used to encrypt a fourth KEK; and so on. If the third KEK might be used to encrypt a fourth KEK; and so on. If
any of the KEKs in such a chain is compromised, all of the any of the KEKs in such a chain is compromised, all of the
subordinate KEKs in the chain MUST also be considered compromised. subsequent KEKs in the chain MUST also be considered compromised.
10 References 9 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," draft-ietf-smime- 2 Housley, R., "Cryptographic Message Syntax," draft-ietf-smime-
rfc2630bis-00.txt, April 2001. rfc2630bis-01.txt, April 2001.
Turner 67
3 Myers, M., Liu, X., Schaad, J., Weinsten, J., "Certificate 3 Myers, M., Liu, X., Schaad, J., Weinsten, J., "Certificate
Management Message over CMS," draft-ietf-pkix-2797-bis-00.txt, Management Message over CMS," draft-ietf-pkix-2797-bis-00.txt,
April 2001. April 2001.
Turner 66
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 Housley, R., Ford, W., Polk, W. and D. Solo, "Internet X.509
Public Key Infrastructure: Certificate and CRL Profile", draft- Public Key Infrastructure: Certificate and CRL Profile", draft-
ietf-pkix-new-part1-06.txt, 8 March 2001. ietf-pkix-new-part1-06.txt, 8 March 2001.
6 Farrell, S., Housley, R., ōAn Internet Attribute Certificate 6 Farrell, S., Housley, R., ōAn Internet Attribute Certificate
Profile for Authorizationö, draft-ietf-pkix-acx.509prof-06.txt, Profile for Authorizationö, draft-ietf-pkix-acx.509prof-06.txt,
10 January 2001. 10 January 2001.
7 Ramsdale, B., "S/MIME Version 3 Message Specification," TBD. 7 Ramsdale, B., "S/MIME Version 3 Message Specification," TBD.
8 Hoffman, P., ōExtended Security Services for S/MIMEö, RFC 2634, 8 Hoffman, P., and C. Bonatti, ōTransporting S/MIME Objects in
X.400ö, draft-ietf-smime-x400transport-02.txt, May 2000.
9 Hoffman, P., ōExtended Security Services for S/MIMEö, RFC 2634,
June 1999. June 1999.
9 Housley, R., ōCryptographic Message Syntax (CMS) Algorithmsö, 10 Eastlake, D., Crocker, S. and J. Schiller, "Randomness
draft-ietf-smime-cmsalg-00.txt, Apil 2001. Recommendations for Security", RFC 1750, December 1994.
10 Postel, j., "Simple Mail Transport Protocol," RFC 821, August 11 National Institute of Standards and Technology. FIPS Pub 186:
Digital Signature Standard. 19 May 1994.
12 Housley, R., ōCryptographic Message Syntax (CMS) Algorithmsö,
draft-ietf-smime-cmsalg-01.txt, July 2001.
13 Postel, j., "Simple Mail Transport Protocol," RFC 821, August
1982. 1982.
11 Acknowledgements 10 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 document.
12 Author's Addresses Turner 68
11 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
Turner 67 Turner 69
Annex A: ASN.1 Module Annex A: ASN.1 Module
SMIMESymmetricKeyDistribution SMIMESymmetricKeyDistribution
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
smime(16) modules(0) symkeydist(12) } smime(16) modules(0) symkeydist(12) }
DEFINITIONS IMPLICIT TAGS ::= DEFINITIONS IMPLICIT TAGS ::=
BEGIN BEGIN
-- EXPORTS All -- -- EXPORTS All --
skipping to change at line 3443 skipping to change at line 3506
-- PKIX Part 1 - Explicit -- PKIX Part 1 - Explicit
AlgorithmIdentifier, Certificate AlgorithmIdentifier, Certificate
FROM PKIX1Explicit88 { iso(1) identified-organization(3) dod(6) FROM PKIX1Explicit88 { iso(1) identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
id-pkix1-explicit(18) } id-pkix1-explicit(18) }
-- Cryptographic Message Syntax -- Cryptographic Message Syntax
RecipientInfos, id-alg-CMS3DESwrap, KEKIdentifier, RecipientInfos, id-alg-CMS3DESwrap, KEKIdentifier,
CertificateSet CertificateSet
FROM CryptographicMessageSyntax {iso(1) member-body(2) us(840) FROM CryptographicMessageSyntax {iso(1) member-body(2) us(840)
rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) modules(0) cms(1)} rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) modules(0)
cms-2001(14)}
-- Attribute Certificate Profile -- Attribute Certificate Profile
AttributeCertificate FROM AttributeCertificate FROM
PKIXAttributeCertificate { iso(1) identified-organization(3) PKIXAttributeCertificate { iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7) dod(6) internet(1) security(5) mechanisms(5) pkix(7)
id-mod(0) id-mod-attribute-cert(12)}; id-mod(0) id-mod-attribute-cert(12)};
-- This defines the GL symmetric key distribution object identifier -- This defines the GL symmetric key distribution object identifier
-- arc. -- arc.
id-skd OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) id-skd OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) skd(8) } rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) skd(8) }
-- This defines the GL Use KEK control attribute -- This defines the GL Use KEK control attribute
id-skd-glUseKEK OBJECT IDENTIFIER ::= { id-skd 1} id-skd-glUseKEK OBJECT IDENTIFIER ::= { id-skd 1}
Turner 68 Turner 70
GLUseKEK ::= SEQUENCE { GLUseKEK ::= SEQUENCE {
glInfo GLInfo, glInfo GLInfo,
glOwnerInfo SEQUENCE SIZE (1..MAX) OF GLOwnerInfo, glOwnerInfo SEQUENCE SIZE (1..MAX) OF GLOwnerInfo,
glAdministration GLAdministration DEFAULT 1, glAdministration GLAdministration DEFAULT 1,
glKeyAttributes GLKeyAttributes OPTIONAL } glKeyAttributes GLKeyAttributes OPTIONAL }
GLInfo ::= SEQUENCE { GLInfo ::= SEQUENCE {
glName GeneralName, glName GeneralName,
glAddress GeneralName } glAddress GeneralName }
skipping to change at line 3495 skipping to change at line 3559
duration [2] INTEGER DEFAULT 0, duration [2] INTEGER DEFAULT 0,
generationCounter [3] INTEGER DEFAULT 2, generationCounter [3] INTEGER DEFAULT 2,
requestedAlgorithm [4] AlgorithmIdentifier requestedAlgorithm [4] AlgorithmIdentifier
DEFAULT id-alg-CMS3DESwrap } DEFAULT id-alg-CMS3DESwrap }
-- This defines the Delete GL control attribute. -- This defines the Delete GL control attribute.
-- It has the simple type GeneralName. -- It has the simple type GeneralName.
id-skd-glDelete OBJECT IDENTIFIER ::= { id-skd 2} id-skd-glDelete OBJECT IDENTIFIER ::= { id-skd 2}
DeleteGL ::= GeneralName
-- This defines the Add GL Member control attribute -- This defines the Add GL Member control attribute
id-skd-glAddMember OBJECT IDENTIFIER ::= { id-skd 3} id-skd-glAddMember OBJECT IDENTIFIER ::= { id-skd 3}
GLAddMember ::= SEQUENCE { GLAddMember ::= SEQUENCE {
glName GeneralName, glName GeneralName,
glMember GLMember } glMember GLMember }
GLMember ::= SEQUENCE { GLMember ::= SEQUENCE {
glMemberName GeneralName, glMemberName GeneralName,
glMemberAddress GeneralName OPTIONAL, glMemberAddress GeneralName OPTIONAL,
certificates Certificates OPTIONAL } certificates Certificates OPTIONAL }
Turner 69 Turner 71
Certificates ::= SEQUENCE { Certificates ::= SEQUENCE {
pKC [0] Certificate OPTIONAL, pKC [0] Certificate OPTIONAL,
-- See PKIX [5] -- See PKIX [5]
aC [1] SEQUENCE SIZE (1.. MAX) OF aC [1] SEQUENCE SIZE (1.. MAX) OF
AttributeCertificate OPTIONAL, AttributeCertificate OPTIONAL,
-- See ACPROF [6] -- See ACPROF [6]
certificationPath [2] CertificateSet OPTIONAL } certPath [2] CertificateSet OPTIONAL }
-- From CMS [2] -- From CMS [2]
-- This defines the Delete GL Member control attribute -- This defines the Delete GL Member control attribute
id-skd-glDeleteMember OBJECT IDENTIFIER ::= { id-skd 4} id-skd-glDeleteMember OBJECT IDENTIFIER ::= { id-skd 4}
GLDeleteMember ::= SEQUENCE { GLDeleteMember ::= SEQUENCE {
glName GeneralName, glName GeneralName,
glMemberToDelete GeneralName } glMemberToDelete GeneralName }
skipping to change at line 3557 skipping to change at line 3623
GLOwnerAdministration ::= SEQUENCE { GLOwnerAdministration ::= SEQUENCE {
glName GeneralName, glName GeneralName,
glOwnerInfo GLOwnerInfo } glOwnerInfo GLOwnerInfo }
-- This defines the GL Key Compromise control attribute. -- This defines the GL Key Compromise control attribute.
-- It has the simple type GeneralName. -- It has the simple type GeneralName.
id-skd-glKeyCompromise OBJECT IDENTIFIER ::= { id-skd 8} id-skd-glKeyCompromise OBJECT IDENTIFIER ::= { id-skd 8}
GLKCompromise ::= GeneralName
Turner 72
-- This defines the GL Key Refresh control attribute. -- This defines the GL Key Refresh control attribute.
id-skd-glkRefresh OBJECT IDENTIFIER ::= { id-skd 9} id-skd-glkRefresh OBJECT IDENTIFIER ::= { id-skd 9}
Turner 70
GLKRefresh ::= SEQUENCE { GLKRefresh ::= SEQUENCE {
glName GeneralName, glName GeneralName,
dates SEQUENCE SIZE (1..MAX) OF Date } dates SEQUENCE SIZE (1..MAX) OF Date }
Date ::= SEQUENCE { Date ::= SEQUENCE {
start GeneralizedTime, start GeneralizedTime,
end GeneralizedTime OPTIONAL } end GeneralizedTime OPTIONAL }
-- This defines the GLA Query Request control attribute. -- This defines the GLA Query Request control attribute.
skipping to change at line 3597 skipping to change at line 3665
-- glaRequestType/glaResponseType. -- glaRequestType/glaResponseType.
id-cmc-glaRR OBJECT IDENTIFIER ::= { iso(1) identified- id-cmc-glaRR OBJECT IDENTIFIER ::= { iso(1) identified-
organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7)
cmc(7) glaRR(99) } cmc(7) glaRR(99) }
-- This defines the Algorithm Request -- This defines the Algorithm Request
id-cmc-gla-skdAlgRequest OBJECT IDENTIFIER ::= { id-cmc-glaRR 1 } id-cmc-gla-skdAlgRequest OBJECT IDENTIFIER ::= { id-cmc-glaRR 1 }
SKDAlgRequest ::= NULL
-- This defines the Algorithm Response -- This defines the Algorithm Response
id-cmc-gla-skdAlgResponse OBJECT IDENTIFIER ::= { id-cmc-glaRR 2 } id-cmc-gla-skdAlgResponse OBJECT IDENTIFIER ::= { id-cmc-glaRR 2 }
-- Note that the response for algorithmSupported request is the -- Note that the response for algorithmSupported request is the
-- smimeCapabilities attribute as defined in MsgSpec [7]. -- smimeCapabilities attribute as defined in MsgSpec [7].
Turner 73
-- This defines the control attribute to request an updated -- This defines the control attribute to request an updated
-- certificate to the GLA. -- certificate to the GLA.
id-skd-glProvideCert OBJECT IDENTIFIER ::= { id-skd 13} id-skd-glProvideCert OBJECT IDENTIFIER ::= { id-skd 13}
GLManageCert ::= SEQUENCE { GLManageCert ::= SEQUENCE {
glName GeneralName, glName GeneralName,
glMember GLMember } glMember GLMember }
Turner 71
-- This defines the control attribute to return an updated -- This defines the control attribute to return an updated
-- certificate to the GLA. It has the type GLManageCert. -- certificate to the GLA. It has the type GLManageCert.
id-skd-glManageCert OBJECT IDENTIFIER ::= { id-skd 14} id-skd-glManageCert OBJECT IDENTIFIER ::= { id-skd 14}
-- This defines the control attribute to distribute the GL shared -- This defines the control attribute to distribute the GL shared
-- KEK. -- KEK.
id-skd-glKey OBJECT IDENTIFIER ::= { id-skd 15} id-skd-glKey OBJECT IDENTIFIER ::= { id-skd 15}
GLKey ::= SEQUENCE { GLKey ::= SEQUENCE {
glName GeneralName, glName GeneralName,
glIdentifier KEKIdentifier, -- See CMS [2] glIdentifier KEKIdentifier, -- See CMS [2]
glkWrapped RecipientInfos, -- See CMS [2] glkWrapped RecipientInfos, -- See CMS [2]
glkAlgorithm AlgorithmIdentifier, glkAlgorithm AlgorithmIdentifier,
glkNotBefore GeneralizedTime, glkNotBefore GeneralizedTime,
glkNotAfter GeneralizedTime } glkNotAfter GeneralizedTime }
Turner 74
-- This defines the CMC error types -- This defines the CMC error types
id-cet-skdFailInfo OBJECT IDENTIFIER ::= { iso(1) id-cet-skdFailInfo OBJECT IDENTIFIER ::= { iso(1)
identified-organization(3) dod(6) internet(1) security(5) identified-organization(3) dod(6) internet(1) security(5)
mechanisms(5) pkix(7) cet(15) skdFailInfo(1) } mechanisms(5) pkix(7) cet(15) skdFailInfo(1) }
SKDFailInfo ::= INTEGER { SKDFailInfo ::= INTEGER {
unspecified (0), unspecified (0),
closedGL (1), closedGL (1),
unsupportedDuration (2), unsupportedDuration (2),
skipping to change at line 3657 skipping to change at line 3728
nameAlreadyInUse (8), nameAlreadyInUse (8),
noSpam (9), noSpam (9),
deniedAccess (10), deniedAccess (10),
alreadyAMember (11), alreadyAMember (11),
notAMember (12), notAMember (12),
alreadyAnOwner (13), alreadyAnOwner (13),
notAnOwner (14) } notAnOwner (14) }
END -- SMIMESymmetricKeyDistribution END -- SMIMESymmetricKeyDistribution
September 2, 2001 Expires 20 December 2001
Turner 72 Turner 75
 End of changes. 

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