draft-ietf-smime-symkeydist-02.txt   draft-ietf-smime-symkeydist-03.txt 
SMIME Working Group S. Turner SMIME Working Group S. Turner
Internet Draft IECA Internet Draft IECA
Document: draft-ietf-smime-symkeydist-02.txt October 31, 2000 Document: draft-ietf-smime-symkeydist-03.txt March 2, 2001
Expires: April 2001 Expires: September 2, 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 64 skipping to change at line 64
"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
2. ARCHITECTURE....................................................5 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...................................................8
3.1.2 GL DELETE...................................................10 3.1.2 DELETE GL...................................................11
3.1.3 GL ADD MEMBER...............................................10 3.1.3 ADD GL MEMBER...............................................11
3.1.4 GL DELETE MEMBERS...........................................11 3.1.4 DELETE GL MEMBER............................................12
3.1.5 GL REKEY....................................................12 3.1.5 REKEY GL....................................................13
3.1.6 GL ADD OWNER................................................13 3.1.6 ADD GL OWNER................................................14
3.1.7 GL REMOVE OWNER.............................................13 3.1.7 REMOVE GL OWNER.............................................14
3.1.8 GL KEY COMPROMISE...........................................14 3.1.8 GL KEY COMPROMISE...........................................14
3.1.9 GL KEY REFRESH..............................................14 3.1.9 GL KEY REFRESH..............................................15
3.1.10 GL SUCCESS INFORMATION.....................................14 3.1.10 GL SUCCESS INFORMATION.....................................15
3.1.11 GL FAIL INFORMATION........................................15 3.1.11 GL FAIL INFORMATION........................................16
3.1.12 GLA QUERY REQUEST..........................................17 3.1.12 GLA QUERY REQUEST..........................................18
3.1.13 GLA QUERY RESPONSE.........................................17 3.1.13 GLA QUERY RESPONSE.........................................18
3.1.14 GL PROVIDE CERT............................................17 3.1.14 PROVIDE CERT...............................................19
3.1.15 GL UPDATE CERT.............................................18 3.1.15 UPDATE CERT................................................20
3.1.16 GL KEY.....................................................19 3.1.16 GL KEY.....................................................21
3.2 USE OF CMC, CMS, AND PKIX.....................................20 3.2 USE OF CMC, CMS, AND PKIX.....................................22
3.2.1 PROTECTION LAYERS...........................................20 3.2.1 PROTECTION LAYERS...........................................22
3.2.1.1 MINIMUM PROTECTION........................................21 3.2.1.1 MINIMUM PROTECTION........................................23
3.2.1.2 ADDITIONAL PROTECTION.....................................21 3.2.1.2 ADDITIONAL PROTECTION.....................................23
3.2.2 COMBINING REQUESTS AND RESPONSES............................21 3.2.2 COMBINING REQUESTS AND RESPONSES............................23
3.2.3 GLA GENERATED MESSAGES......................................23 3.2.3 GLA GENERATED MESSAGES......................................25
3.2.4 CMC CONTROL ATTRIBUTES......................................24 3.2.4 CMC CONTROL ATTRIBUTES......................................26
3.2.5 RESUBMITTED GL MEMBER MESSAGES..............................26 3.2.5 RESUBMITTED GL MEMBER MESSAGES..............................27
3.2.6 PKIX........................................................26 3.2.6 PKIX........................................................28
4 ADMINISTRATIVE MESSAGES.........................................26 4 ADMINISTRATIVE MESSAGES.........................................28
4.1 ASSIGN KEK TO GL..............................................26 4.1 ASSIGN KEK TO GL..............................................28
4.2 DELETE GL FROM GLA............................................29 4.2 DELETE GL FROM GLA............................................31
4.3 ADD MEMBERS TO GL.............................................31 4.3 ADD MEMBERS TO GL.............................................33
4.3.1 GLO INITIATED ADDITIONS.....................................32 4.3.1 GLO INITIATED ADDITIONS.....................................34
4.3.2 PROSPECTIVE MEMBER INITIATED ADDITIONS......................37 4.3.2 PROSPECTIVE MEMBER INITIATED ADDITIONS......................40
4.4 DELETE MEMBERS FROM GL........................................39 4.4 DELETE MEMBERS FROM GL........................................42
4.4.1 GLO INITIATED DELETIONS.....................................40 4.4.1 GLO INITIATED DELETIONS.....................................43
4.4.2 MEMBER INITIATED DELETIONS..................................44 4.4.2 MEMBER INITIATED DELETIONS..................................47
4.5 REQUEST REKEY OF GL...........................................45 4.5 REQUEST REKEY OF GL...........................................48
4.5.1 GLO INITIATED REKEY REQUESTS................................46 4.5.1 GLO INITIATED REKEY REQUESTS................................49
4.5.2 GLA INITIATED REKEY REQUESTS................................48 4.5.2 GLA INITIATED REKEY REQUESTS................................51
4.6 CHANGE GLO....................................................48 4.6 CHANGE GLO....................................................52
4.7 INDICATE KEK COMPROMISE.......................................50 4.7 INDICATE KEK COMPROMISE.......................................54
4.7.1 GL MEMBER INITIATED KEK COMPROMISE MESSAGE..................51 4.7.1 GL MEMBER INITIATED KEK COMPROMISE MESSAGE..................55
Turner 2 Turner 2
4.7.2 GLO INITIATED KEK COMPROMISE MESSAGE........................52 4.7.2 GLO INITIATED KEK COMPROMISE MESSAGE........................56
4.8 REQUEST KEK REFRESH...........................................53 4.8 REQUEST KEK REFRESH...........................................57
4.9 GLA QUERY REQUEST AND RESPONSE................................54 4.9 GLA QUERY REQUEST AND RESPONSE................................58
4.10 UPDATE MEMBER CERTIFICATE....................................56 4.10 UPDATE MEMBER CERTIFICATE....................................60
4.10.1 GLO AND GLA INITIATED UPDATE MEMBER CERTIFICATE............56 4.10.1 GLO AND GLA INITIATED UPDATE MEMBER CERTIFICATE............60
4.10.2 GL MEMBER INITIATED UPDATE MEMBER CERTIFICATE..............57 4.10.2 GL MEMBER INITIATED UPDATE MEMBER CERTIFICATE..............62
5 DISTRIBUTION MESSAGE............................................58 5 DISTRIBUTION MESSAGE............................................63
5.1 DISTRIBUTION PROCESS..........................................59 5.1 DISTRIBUTION PROCESS..........................................64
6 ALGORITHMS......................................................60 6 ALGORITHMS......................................................64
6.1 KEK GENERATION ALGORITHM......................................60 6.1 KEK GENERATION ALGORITHM......................................65
6.2 SHARED KEK WRAP ALGORITHM.....................................60 6.2 SHARED KEK WRAP ALGORITHM.....................................65
6.3 SHARED KEK ALGORITHM..........................................61 6.3 SHARED KEK ALGORITHM..........................................65
7 TRANSPORT.......................................................61 7 TRANSPORT.......................................................65
8 USING THE GROUP KEY.............................................61 8 USING THE GROUP KEY.............................................65
9 SECURITY CONSIDERATIONS.........................................61 9 SECURITY CONSIDERATIONS.........................................66
10 REFERENCES.....................................................61 10 REFERENCES.....................................................66
11 ACKNOWLEDGEMENTS...............................................62 11 ACKNOWLEDGEMENTS...............................................66
12 AUTHOR'S ADDRESSES.............................................62 12 AUTHOR'S ADDRESSES.............................................67
1. Introduction 1. Introduction
With the ever-expanding use of secure electronic communications With the ever-expanding use of secure electronic communications
(e.g., S/MIME [2]), users require a mechanism to distribute (e.g., S/MIME [2]), users require a mechanism to distribute
encrypted data to multiple recipients (i.e., a group of users). encrypted data to multiple recipients (i.e., a group of users).
There are essentially two ways to encrypt the data for recipients: There are essentially two ways to encrypt the data for recipients:
using asymmetric algorithms with public key certificates (PKCs) or using asymmetric algorithms with public key certificates (PKCs) or
symmetric algorithms with symmetric keys. symmetric algorithms with symmetric keys.
skipping to change at line 243 skipping to change at line 243
restrictive GLs, where a human determines GL membership, and very restrictive GLs, where a human determines GL membership, and very
open GLs, where there are no restrictions on GL membership. To open GLs, where there are no restrictions on GL membership. To
support this spectrum, the mechanism described herein supports both support this spectrum, the mechanism described herein supports both
managed (i.e., where access control is applied) and unmanaged (i.e., managed (i.e., where access control is applied) and unmanaged (i.e.,
where no access control is applied) GLs. The access control where no access control is applied) GLs. The access control
mechanism for managed lists is beyond the scope of this document. mechanism for managed lists is beyond the scope of this document.
In either case, the GL must initially be constructed by an entity In either case, the GL must initially be constructed by an entity
hereafter called the Group List Owner (GLO). There may be multiple hereafter called the Group List Owner (GLO). There may be multiple
entities who 'own' the GL and who are allowed to make changes the entities who 'own' the GL and who are allowed to make changes the
GL's properties or membership. The GLO determines if the GL will be GLĘs properties or membership. The GLO determines if the GL will be
managed or unmanaged and is the only entity that may delete the GL. managed or unmanaged and is the only entity that may delete the GL.
GLO(s) may or may not be GL members. GLO(s) may or may not be GL members.
Turner 5 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
skipping to change at line 278 skipping to change at line 278
There are existing mechanisms (e.g., listserv and majordomo) to There are existing mechanisms (e.g., listserv and majordomo) to
support managing GLs; however, this document does not address support managing GLs; however, this document does not address
securing these mechanisms, as they are not standardized. Instead, it securing these mechanisms, as they are not standardized. Instead, it
defines protocol interactions, as depicted in Figure 2, used by the defines protocol interactions, as depicted in Figure 2, used by the
GL members, GLA, and GLO to manage GLs and distribute shared KEKs. GL members, GLA, and GLO to manage GLs and distribute shared KEKs.
The interactions have been divided into administration messages and The interactions have been divided into administration messages and
distribution messages. The administrative messages are the request distribution messages. The administrative messages are the request
and response messages needed to setup the GL, delete the GL, add and response messages needed to setup the GL, delete the GL, add
members to the GL, delete members of the GL, and request a group members to the GL, delete members of the GL, and request a group
rekey, etc. The distribution messages are the messages that rekey, etc. The distribution messages are the messages that
distribute the shared KEKs. The following paragraphs describe the distribute the shared KEKs. The following sections describe the
ASN.1 for both the administration and distribution messages. ASN.1 for both the administration and distribution messages. Section
Paragraph 4 describes how to use the administration messages and 4 describes how to use the administration messages and section 5
paragraph 5 describes how to use the distribution messages. describes how to use the distribution messages.
+-----+ +----------+ +-----+ +----------+
| GLO | <---+ +----> | Member 1 | | GLO | <---+ +----> | Member 1 |
+-----+ | | +----------+ +-----+ | | +----------+
| | | |
+-----+ <------+ | +----------+ +-----+ <------+ | +----------+
| GLA | <-------------+----> | ... | | GLA | <-------------+----> | ... |
+-----+ | +----------+ +-----+ | +----------+
| |
| +----------+ | +----------+
skipping to change at line 305 skipping to change at line 305
Figure 2 - Protocol Interactions Figure 2 - Protocol Interactions
Turner 6 Turner 6
3.1 Control Attributes 3.1 Control Attributes
The messages are based on including control attributes in CMC's The messages are based on including control attributes in CMC's
PKIData for requests and CMC's ResponseBody0 for responses. The PKIData for requests and CMC's ResponseBody0 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
paragraph 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
glAddMember id-skd 3 glAddMember glAddMember id-skd 3 GLAddMember
glDeleteMember id-skd 4 GLDeleteMember glDeleteMember id-skd 4 GLDeleteMember
glRekey id-skd 5 GLRekey glRekey id-skd 5 GLRekey
glAddOwner id-skd 6 GLOwnerAdministration glAddOwner id-skd 6 GLOwnerAdministration
glRemoveOwner id-skd 7 GLOwnerAdministration glRemoveOwner id-skd 7 GLOwnerAdministration
glkCompromise id-skd 8 GeneralName glkCompromise id-skd 8 GeneralName
glkRefresh id-skd 9 GeneralName glkRefresh id-skd 9 GLKRefresh
glSuccessInfo id-skd 10 GLSuccessInfo glSuccessInfo id-skd 10 GLSuccessInfo
glFailInfo id-skd 11 GLFailInfo glFailInfo id-skd 11 GLFailInfo
glaQueryRequest id-skd 12 GLAQueryRequest glaQueryRequest id-skd 12 GLAQueryRequest
glaQueryResponse id-skd 13 GLAQueryResponse glaQueryResponse id-skd 13 GLAQueryResponse
glProvideCert id-skd 14 GLProvideCert glProvideCert id-skd 14 GLManageCert
glUpdateCert id-skd 15 GLUpdateCert glUpdateCert id-skd 15 GLManageCert
glKey id-skd 16 GLKey glKey id-skd 16 GLKey
The following are the implementation requirements for the control In the following conformance tables, the column headings have the
attributes defined herein: following meanings: O for originate, R for receive, F for forward.
There are three types of implementations: GLOs, GLAs, and GL
members. The GLO is an optional component hence all of the messages
for it are optional and the GLO forwarding messages to it or the GL
member. The first table includes messages that MUST be implemented
in order to be considered conformant to this document. The second
table includes messages that MAY be implemented in order to be
considered conformant to this document.
Turner 7
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 N/A | N/A MAY N/A | N/A N/A | glUseKEK MAY - |MUST - MAY | - MUST |glProvideCert
MAY N/A | N/A MAY N/A | N/A N/A | glDelete MAY MAY | - MUST MAY | MUST - |glUpdateCert
MAY MAY | N/A MUST MAY | N/A MUST | glAddMember - - |MUST - - | - MUST |glKey
MAY MAY | N/A MUST MAY | N/A MUST | glDeleteMember - MAY |MUST - - | - MUST |glSucessInfo
MAY N/A | N/A MAY N/A | N/A N/A | glRekey - MAY |MUST - - | - MUST |glFailInfo
MAY N/A | N/A MAY N/A | N/A N/A | glAddOwner
MAY N/A | N/A MAY N/A | N/A N/A | glRemoveOwner Optional
MAY MAY | N/A MUST MAY | MUST N/A | glkCompromise Implementation Requirement | Control
MAY N/A | N/A MUST N/A | MUST N/A | glkRefresh GLO | GLA | GL Member | Attribute
N/A MAY | MUST N/A N/A | N/A MUST | glSucessInfo O R |O R F | O R |
N/A MAY | MUST N/A N/A | N/A MUST | glFailInfo -------- |------------------ |--------- |----------
MAY N/A | N/A SHOULD N/A | MAY MAY | glaQueryRequest MAY - | - MAY - | - - |glUseKEK
N/A MAY | SHOULD N/A N/A | MAY MAY | glaQueryResponse MAY - | - MAY - | - - |glDelete
MAY N/A | MUST N/A MAY | N/A MUST | glProvideCert MAY MAY | - MUST MAY | MUST - |glAddMember
N/A MAY | N/A MUST MAY | MUST N/A | glUpdateCert MAY MAY | - MUST MAY | MUST - |glDeleteMember
N/A N/A | MUST N/A N/A | N/A MUST | glKey MAY - | - MAY - | - - |glRekey
MAY - | - MAY - | - - |glAddOwner
MAY - | - MAY - | - - |glRemoveOwner
MAY MAY | - MUST MAY | MUST - |glkCompromise
MAY - | - MUST - | MUST - |glkRefresh
MAY - | - SHOULD - | MAY - |glaQueryRequest
- MAY |SHOULD - - | - MAY |glaQueryResponse
Turner 7
glSuccessInfo, glFailInfo, glaQueryResponse, and gloResponse are glSuccessInfo, glFailInfo, glaQueryResponse, and gloResponse are
responses and go into the PKIResponse content-type, all other responses and go into the PKIResponse content-type, all other
control attributes are included in requests and go into the PKIData control attributes are included in requests and go into the PKIData
content-type. The exception is glUpdateCert which may be included in content-type. The exception is glUpdateCert which may be included in
either PKIData or PKIResponse. either PKIData or PKIResponse.
3.1.1 GL USE KEK 3.1.1 GL USE KEK
The GLO uses glUseKEK to request that a shared KEK be assigned to a The GLO uses glUseKEK to request that a shared KEK be assigned to a
GL. 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 shall have 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 [0] GLKeyAttributes OPTIONAL } glKeyAttributes GLKeyAttributes OPTIONAL }
Turner 8
GLInfo ::= SEQUENCE { GLInfo ::= SEQUENCE {
glName GeneralName, glName GeneralName,
glAddress GeneralName } glAddress GeneralName }
GLOwnerInfo ::= SEQUENCE { GLOwnerInfo ::= SEQUENCE {
glOwnerName GeneralName, glOwnerName GeneralName,
glOwnerAddress GeneralName } glOwnerAddress GeneralName }
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,
recipientMutuallyAware [1] BOOLEAN DEFAULT TRUE, recipientsNotMutuallyAware [1] BOOLEAN DEFAULT TRUE,
duration [2] INTEGER DEAULT (0), duration [2] INTEGER DEAULT (0),
generationCounter [3] INTEGER DEFAULT (2), generationCounter [3] INTEGER DEFAULT (2),
requestedAlgorithm [4] AlgorithmIdentifier requestedAlgorithm [4] AlgorithmIdentifier
DEFAULT (id-alg-CMS3DESwrap) OPTIONAL DEFAULT (id-alg-CMS3DESwrap) }
}
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 GLĘs name in glName and the GLĘs address in
glAddress. In some instances the glName and glAddress may be the glAddress. In some instances the glName and glAddress may be the
same, but this is not always the case. The name and address MUST same, but this is not always the case. Both the name and address
be unique for a given GLA. MUST be unique for a given GLA.
- glOwnerInfo indicates the GL owner's name in glOwnerName and the
GL owner's address in glOwnerAddress. One of the names in
Turner 8 - glOwnerInfo indicates the GL ownerĘs name in glOwnerName and the
GL ownerĘs address in glOwnerAddress. One of the names in
glOwnerName MUST match one of the names in the certificate used glOwnerName MUST match one of the names in the certificate used
to sign this SignedData.PKIData creating the GL (i.e., the to sign this SignedData.PKIData creating the GL (i.e., the
immediate signer). Multiple GLOs MAY be indicated if immediate signer).
glAdministration is set to managed or closed.
- glAdministration indicates how the GL should be administered. - glAdministration indicates how the GL should be administered.
The default is for the list to be 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 being added
and deleted from the GL without GLO intervention. They are and deleted from the GL without GLO intervention.
also indicating that only one GLO may be associated at any one
time with the GL.
- Managed - When the GLO sets glAdministration to managed, they - Managed - When the GLO sets glAdministration to managed, they
are allowing prospective members to request being added to and are allowing prospective members to request being added to and
deleted from the GL, but the request is redirected by the GLA deleted 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 being added to
or deleted from the GL. The GLA will only accept glAddMember or deleted from the GL. The GLA will only accept glAddMember
and glDeleteMember requests from the GLO.
Turner 9
and glDeleteMember requests from the GLO. It is GL policy as
to whether to forward the request on to 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 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
the GLA to control rekeys. If GL rekey is controlled by the the GLA to control rekeys. If GL rekey is controlled by the
GLA, the GL will continue to be rekeyed until the GLO deletes GLA, the GL will continue to be rekeyed until the GLO deletes
the GL or changes the GL rekey to be GLO controlled. the GL or changes the GL rekey to be GLO controlled.
- recipientsMutuallyAware indicates that the GLO wants the GLA - recipientsNotMutuallyAware indicates that the GLO wants the
to distribute the shared KEK individually for each of the GL GLA to distribute the shared KEK individually for each of the
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.
NOTE: This supports lists where one member does not know the NOTE: This supports lists where one member does not know the
identities of the other members. For example, a list is identities of the other members. For example, a list is
configured granting submit permissions to only one member. All configured granting submit permissions to only one member. All
other members are 'listening.' The security policy of the list other members are 'listening.' The security policy of the list
does not allow the members to know who else is on the list. If does not allow the members to know who else is on the list. If
Turner 9
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. indicates that the shared KEK is valid for a calendar month at
For example if the duration is zero (0), if the GL shared KEK UTC Zulu time zone. For example if the duration is zero (0),
is requested on July 24, the first key will be valid until the if the GL shared KEK is requested on July 24, the first key
end of July and the next key will be valid for the entire will be valid until the end of July and the next key will be
month of August. If the value is not zero (0), the shared KEK valid for the entire month of August. If the value is not zero
will be valid for the number of days indicated by the value. (0), the shared KEK will be valid for the number of days
For example, if the value of duration is seven (7) and the indicated by the value. For example, if the value of duration
shared KEK is requested on Monday but not generated until is seven (7) and the shared KEK is requested on Monday but not
Tuesday (2359); the shared KEKs will be valid from Tuesday generated until Tuesday (2359); the shared KEKs will be valid
(2359) to Tuesday (2359). The exact time of the day is from Tuesday (2359) to Tuesday (2359). The exact time of the
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
Turner 10
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 paragraphs 4.5 and 5 wants outstanding at any one time. See sections 4.5 and 5 for
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 to generate the shared KEK. See the GLO wants the GLA to use with the shared KEK. The
paragraph 7 for more on algorithms. parameters are conveyed via the SMIMECapabilities attribute
see MSG {x}. See section 7 for more on algorithms.
3.1.2 GL Delete 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 shall have the syntax GeneralName. The
name of the GL to be deleted is included in GeneralName. The name of the GL to be deleted is included in GeneralName. The
glDelete message MUST be signed by the GLO. glDelete message MUST be signed by the GLO.
3.1.3 GL Add Member 3.1.3 Add GL Member
GLOs use glAddMember to request addition of new members and GLOs use glAddMember to request addition of new members and
prospective GL members use glAddMember to request being added to the prospective GL members use glAddMember to request being added to the
GL. The glAddMember message must be signed by either the GLO or the GL. The glAddMember message must be signed by either the GLO or the
prospective GL member. The glAddMember control attribute shall have prospective GL member. The glAddMember control attribute shall have
the syntax GLAddMember: the syntax GLAddMember:
Turner 10
GLAddMember ::= SEQUENCE { GLAddMember ::= SEQUENCE {
glName GeneralName, glName GeneralName,
glMember GLMember } glMember GLMember }
GLMember ::= SEQUENCE { GLMember ::= SEQUENCE {
glMemberName GeneralName, glMemberName GeneralName,
glMemberAddress GeneralName, glMemberAddress GeneralName OPTIONAL,
certificates Certificates } certificates Certificates OPTIONAL }
Certificates ::= SEQUENCE { Certificates ::= SEQUENCE {
membersPKC Certificate, pKC Certificate OPTIONAL,
-- See X.509 -- See X.509
membersAC SEQUENCE OF AttributeCertificate OPTIONAL, aC SEQUENCE SIZE (1.. MAX) OF
AttributeCertificate OPTIONAL,
-- See X.509 -- See X.509
certificationPath CertificateSet OPTIONAL } certificationPath CertificateSet OPTIONAL }
-- From CMS [2] -- From CMS [2]
CertificateSet ::= SET OF CertificateChoices CertificateSet ::= SET SIZE (1..MAX) OF CertificateChoices
Turner 11
CertificateChoices ::= CHOICE { CertificateChoices ::= CHOICE {
certificate Certificate, -- See X.509 certificate Certificate,
-- See X.509
extendedCertificate [0] IMPLICIT ExtendedCertificate, extendedCertificate [0] IMPLICIT ExtendedCertificate,
-- Obsolete -- Obsolete
attrCert [1] IMPLICIT AttributeCertificate } attrCert [1] IMPLICIT AttributeCertificate }
-- See X.509 and X9.57 -- See X.509 and X9.57
The fields in GLAddMembers have the following meaning: The fields in GLAddMembers have the following meaning:
- glName indicates the name of the GL to which the member should - glName indicates the name of the GL to which the member should
be added. be added.
- glMember indicates the particulars for the GL member. - glMember indicates the particulars for the GL member. Both of
glMemberName indicates the name of the GL member and the following fields must be unique for a given GL:
glMemberAddress indicates the GL member's address. In some
instances the glMemberName and glMemberAddress may be the same, - glMemberName indicates the name of the GL member.
but this is not always the case. certificates.membersPKC
includes the member's encryption certificate that will be used - glMemberAddress indicates the GL memberĘs address. It MUST be
to at least initially encrypt the shared KEK for that member. included.
certificates.membersAC MAY be included to convey any attribute
certificate associated with the member's encryption certificate. Note: In some instances the glMemberName and glMemberAddress
certificates.certificationPath MAY also be included to convey may be the same, but this is not always the case.
the certification path corresponding to the member's encryption
and attribute certificates. The certification path is optional - certificates MUST be included. It contains the following three
fields:
- certificates.pKC includes the member's encryption
certificate that will be used to at least initially encrypt
the shared KEK for that member. If the message is generated
by a prospective GL member, the pKC MUST be included. If the
message is generated by a GLO, the pKC SHOULD be included.
- certificates.aC MAY be included to convey any attribute
certificate associated with the memberĘs encryption
certificate.
- certificates.certificationPath MAY also be included to
convey the certification path corresponding to the member's
encryption and any non-member attribute certificates are
placed in attrCert. The certification path is optional
because it may already be included elsewhere in the message because it may already be included elsewhere in the message
(e.g., in the outer CMS layer). (e.g., in the outer CMS layer).
3.1.4 GL Delete Members 3.1.4 Delete GL Member
GLOs use glDeleteMember to request deletion of GL members and GLOs use glDeleteMember to request deletion of GL members and GL
prospective non-GL members use glDeleteMember to request being members use glDeleteMember to request being removed from the GL. The
glDeleteMember message must be signed by either the GLO or the
Turner 11 Turner 12
removed from the GL. The glDeleteMember message must be signed by prospective GL member. The glDeleteMember control attribute shall
either the GLO or the prospective GL member. The glDeleteMember have the syntax GLDeleteMember:
control attribute shall have the 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.
3.1.5 GL Rekey 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 shall have the
syntax GLRekey: syntax GLRekey:
GLRekey ::= SEQUENCE { GLRekey ::= SEQUENCE {
glName GeneralName, glName GeneralName,
glAdministration GLAdministration OPTIONAL, glAdministration GLAdministration OPTIONAL,
glNewKeyAttributes GLNewKeyAttributes OPTIONAL } glNewKeyAttributes GLNewKeyAttributes OPTIONAL,
glRekeyAllGLKeys BOOLEAN OPTIONAL }
GLNewKeyAttributes ::= SEQUENCE { GLNewKeyAttributes ::= SEQUENCE {
rekeyControlledByGLO [0] BOOLEAN OPTIONAL, rekeyControlledByGLO [0] BOOLEAN OPTIONAL,
recipientMutuallyAware [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 paragraph 3.1.1 for the three should be administered. See section 3.1.1 for the three options.
options. This field is only included if there is a change from This field is only included if there is a change from the
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 should be issued. The field is only included if
there is a change from the previously registered there is a change from the previously registered
glKeyAttributes. If the value zero (0) is specified in glKeyAttributes.
generationCounter the GLO is indicating that it wants all of the
Turner 12 Turner 13
outstanding GL shared KEKs rekeyed. For example, suppose the GLO - glRekeyAllGLKeys indicates whether the GLO wants all of the
used the glUseKEK with duration set to two (2) and the glRekey outstanding GLĘs shared KEKs rekeyed. If it is set to TRUE then
message is sent during the first duration with generationCounter all outstanding KEKs MUST be issued. If it is set to FALSE then
set to zero (0). The GLA would know to generate a glKey message all outstanding KEKs need not be resissued.
to replace both the shared KEK currently being used and the
shared KEK for the second duration.
3.1.6 GL Add 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. In addition, a registered GLO may use the request administer the GL. The glAddOwner message MUST be signed a
to update their certificate on the GLA. In this case, the new GLO registered GLO. The glAddOwner control attribute shall have the
certificate is signed by the old GLO certificate. The glAddOwner syntax GLOwnerAdministration:
message MUST be signed a registered GLO. The glAddOwner control
attribute shall have the syntax 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 and address of the new GLO. - glOwnerInfo indicates the name and address of the new GLO.
3.1.7 GL Remove 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 a registered with the GL. The glRemoveOwner message MUST be signed by a
GLO. Unmanaged GLs may only have one GLO. If the GLA processes a registered GLO. The glRemoveOwner control attribute shall have the
glRemoveOwner for an unmanaged GL, only one GLO shall be associated syntax GLOwnerAdministration:
with the GL at any given time. The glRemoveOwner control attribute
shall have the syntax GLOwnerAdministration:
GLOwnerAdministration ::= SEQUENCE { GLOwnerAdministration ::= SEQUENCE {
glName GeneralName, glName GeneralName,
glOwnerInfo GLOwnerInfo } glOwnerInfo GLOwnerInfo }
The fields in GLRemoveOwners have the following meaning: The fields in GLRemoveOwners have the following meaning:
- glName indicates the name of the GL to which the GLO should be - glName indicates the name of the GL to which the GLO should be
disassociated. disassociated.
- glOwnerInfo indicates the name and address of the GLO to be - glOwnerInfo indicates the name and address of the GLO to be
removed. removed.
Turner 13
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 shall have the syntax GeneralName. The name of the GL to
which the compromised key is associated with is included in which the compromised key is associated with is included in
GeneralName. This message is always redirected by the GLA to the GLO GeneralName. This message is always redirected by the GLA to the GLO
Turner 14
for further action. The glkCompromise MUST NOT be included in an for further action. The glkCompromise MUST NOT be included in an
EnvelopedData generated with the compromised shared KEK. EnvelopedData generated with the compromised shared KEK.
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 glKeyRefresh control attribute shall have redistributed to them. The glkRefresh control attribute shall have
the syntax GeneralName. The GL member includes the GL's name in the syntax GLKRefresh.
GeneralName.
GLKRefresh ::= {
glName GeneralName,
dates SEQUENCE (1..MAX) OF Date }
Date ::= {
start GeneralizedTime,
end GeneralizedTime OPTIONAL }
The fields in GLKRefresh have the following meaning:
- glName indicates the name of the GL for which the GL member
wants shared KEKs.
- dates indicates a date range for keys the GL member wants. 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 to
indicate the GL member wants all keys from the specified start date
to the current date. It should be noted that a procedural mechanism
will be needed to restrict users from accessing messages that they
are not allowed to access.
3.1.10 GL Success Information 3.1.10 GL Success Information
The GLA uses glSuccessInfo to indicate a successful result of an The GLA uses glSuccessInfo to indicate a successful result of an
administrative message. A separate glSuccessInfo is returned for administrative message. A separate glSuccessInfo is returned for
each action (e.g., if there are four successful glAddMember requests each action (e.g., if there are four successful glAddMember requests
then four glSuccessInfo responses are generated). The glSuccessInfo then four glSuccessInfo responses are generated). The glSuccessInfo
message MUST be signed by the GLA. The glSucessInfo control message MUST be signed by the GLA. The glSucessInfo control
attribute shall have the syntax GLSucessInfo: attribute shall have the syntax GLSucessInfo:
GLSuccessInfo ::= SEQUENCE { GLSuccessInfo ::= SEQUENCE {
glInfo GLInfo, glInfo GLInfo,
glIdentifier GLIdentifier, glIdentifier GLIdentifier,
action Action } action Action }
Action ::= SEQUENCE { Action ::= SEQUENCE {
actionCode ActionCode, actionCode ActionCode,
glMemberName [0] GeneralName OPTIONAL, glMemberName [0] GeneralName OPTIONAL,
glOwnerName [1] GeneralName OPTIONAL } glOwnerName [1] GeneralName OPTIONAL }
Turner 15
ActionCode ::= INTEGER { ActionCode ::= INTEGER {
assignedKEK (0), assignedKEK (0),
deletedGL (1), deletedGL (1),
addedMember (2), addedMember (2),
deletedMember (3), deletedMember (3),
rekeyedGL (4), rekeyedGL (4),
addedGLO (5), addedGLO (5),
removedGLO (6) } removedGLO (6) }
The fields in GLSuccessInfo have the following meaning: The fields in GLSuccessInfo have the following meaning:
- glInfo indicates the GL's name in glName and the GL's address in - glInfo indicates the GLĘs name in glName and the GLĘs address in
glAddress. glAddress.
Turner 14 - glIdentifier identifies GLĘs unique shared KEK.
- glIdentifier identifies GL's unique shared KEK.
- action indicates the successfully performed action. - action indicates the successfully performed action.
action.actionCode indicates whether the shared KEK was assigned action.actionCode indicates whether the shared KEK was assigned
to the GL, whether the GL was deleted, whether a member was to the GL, whether the GL was deleted, whether a member was
added to a GL, whether a member was deleted from a GL, whether added to a GL, whether a member was deleted from a GL, whether
the GL was rekeyed, whether a new GLO was added, and whether a the GL was rekeyed, whether a new GLO was added, and whether a
GLO was removed. If members were added to a GL or deleted from a GLO was removed. If members were added to a GL or deleted from a
GL the members MUST be indicated in glMemberName and glOwnerName GL the members MUST be indicated in glMemberName and glOwnerName
MUST be omitted. If a GLO was added to a GL or deleted from a MUST be omitted. If a GLO was added to a GL or deleted from a
GL, the GLO MUST be indicated in glOwnerName and glMemberName GL, the GLO MUST be indicated in glOwnerName and glMemberName
MUST be omitted. If a shared KEK was assigned to a GL or a GL MUST be omitted. If a shared KEK was assigned to a GL or a GL
was deleted both glOwnerName and glMember MUST be omitted. was deleted both glOwnerName and glMemberName MUST be omitted.
3.1.11 GL Fail Information 3.1.11 GL Fail Information
The GLA uses glFailInfo to indicate that there was a problem The GLA uses glFailInfo to indicate that there was a problem
performing a requested action. A separate glFailInfo is returned for performing a requested action. A separate glFailInfo is returned for
each action (e.g., if there are four denied glAddMember requests each action (e.g., if there are four denied glAddMember requests
then four glFailInfo responses are generated). The glFailInfo then four glFailInfo responses are generated). The glFailInfo
message MUST be signed by the GLA. The glFailInfo control attribute message MUST be signed by the GLA. The glFailInfo control attribute
shall have the syntax GLFailInfo: shall have the syntax GLFailInfo:
GLFailInfo ::= SEQUENCE { GLFailInfo ::= SEQUENCE {
glName GeneralName, glName GeneralName,
error Error } error Error }
Error ::= SEQUENCE { Error ::= SEQUENCE {
errorCode ErrorCode, errorCode ErrorCode,
glMemberName [0] GeneralName OPTIONAL, glMemberName [0] GeneralName OPTIONAL,
glOwnerName [1] GeneralName OPTIONAL } glOwnerName [1] GeneralName OPTIONAL }
Turner 16
ErrorCode ::= INTEGER { ErrorCode ::= 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),
onlyOneGLOAllowed (8), nameAlreadyInUse (8),
nameAlreadyInUse (9), noSpam (9),
noSpam (10), deniedAccess (10),
deniedAccess (11), alreadyAMember (11),
alreadyAMember (12), notAMember (12),
notAMember (13), alreadyAnOwner (13)
alreadyAnOwner (14) notAnOwner (14) }
notAnOwner (15) }
Turner 15
The fields in GLFailInfo have the following meaning: The fields in GLFailInfo have the following meaning:
- glName indicates the name of the GL to which the error - glName indicates the name of the GL to which the error
corresponds. corresponds.
- error indicates the reason why the GLA was unable to perform the - error indicates the reason why the GLA was unable to perform the
request. It also indicates the GL member or GLO to which the request. It also indicates the GL member or GLO to which the
error corresponds. If members were not added to a GL or deleted error corresponds. If members were not added to a GL or deleted
from a GL the members MUST be indicated in glMemberName. If a from a GL the members MUST be indicated in glMemberName. If a
GLO was not added to a GL or deleted from a GL, the GLO MUST be GLO was not added to a GL or deleted from a GL, the GLO MUST be
skipping to change at line 791 skipping to change at line 835
by the GLO. by the GLO.
- unsupportedDuration indicates the GLA does not support - unsupportedDuration indicates the GLA does not support
generating keys that are valid for the requested duration. generating keys that are valid for the requested duration.
- 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, not verifiable (i.e., signature did not validate,
certificate's serial number present on a CRL, etc.). certificateĘs serial number present on a CRL, etc.).
- unsupportedAlgorithm indicates the GLA does not support the - unsupportedAlgorithm indicates the GLA does not support the
requested algorithm. requested algorithm.
Turner 17
- 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 certificate used to sign a request does not match the name of
a registered GLO. a 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 - nameAlreadyInUse indicates the glName is already assigned on
the GLA. the GLA.
- noSpam indicates the prospective GL member did not sign the - noSpam indicates the prospective GL member did not sign the
request (i.e., if the name in 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 in the certificate used to sign the
request). request).
- alreadyAMember indicates the prospective GL member is already - alreadyAMember indicates the prospective GL member is already
a GL member. a GL member.
Turner 16
- notAMember indicates the prospective non-GL member is not a GL - notAMember indicates the prospective non-GL member is not a GL
member. member.
- alreadyAnOwner indicates the prospective GLO is already a GLO. - alreadyAnOwner indicates the prospective GLO is already a GLO.
- notAnOwner indicates the prospective non-GLO is not a GLO. - notAnOwner indicates the prospective non-GLO is not a GLO.
3.1.12 GLA Query Request 3.1.12 GLA Query Request
GLOs and GL members use the glaQueryRequest to ascertain information GLOs and GL members use the glaQueryRequest to ascertain information
skipping to change at line 843 skipping to change at line 887
the algorithms supported by the GLA: the algorithms supported by the GLA:
id-rt-algorithmSupported { id-tbd } id-rt-algorithmSupported { id-tbd }
There is no value defined for id-rt-algorithmSupported. Including There is no value defined for id-rt-algorithmSupported. Including
the id-rt-algorithmSupport indicates that the GLO wishes to know the the id-rt-algorithmSupport indicates that the GLO wishes to know the
algorithms that the GLA supports. algorithms that the GLA supports.
3.1.13 GLA Query Response 3.1.13 GLA Query Response
GLA's return the glaQueryResponse after receiving a GLAQueryRequest. GLAĘs 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 shall have the syntax GLAQueryResponse:
Turner 18
GLAQueryResponse ::= SEQUENCE { GLAQueryResponse ::= SEQUENCE {
glaResponseType OBJECT IDENTIFIER, glaResponseType OBJECT IDENTIFIER,
glaResponseValue ANY DEFINED BY glaResponseType } glaResponseValue ANY DEFINED BY glaResponseType }
One response type is defined herein for the GLA to indicate the One response type is defined herein for the GLA to indicate the
algorithms it supports: algorithms it supports:
smimeCapabilities OBJECT IDENTIFIER ::= smimeCapabilities OBJECT IDENTIFIER ::=
{iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 15} {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 15}
-- Identifies the algorithms supported by the GLA (see MsgSpec [5]) -- Identifies the algorithms supported by the GLA (see MsgSpec [5])
3.1.14 GL Provide Cert 3.1.14 Provide Cert
GLAs and GLOs use glProvideCert to request that a GL member provide GLAs and GLOs use glProvideCert to request that a GL member provide
an updated or new encryption certificate. The glProvideCert message an updated or new encryption certificate. The glProvideCert message
MUST be signed by either GLA or GLO. If the GL member's PKC has been MUST be signed by either GLA or GLO. If the GL memberĘs PKC has been
Turner 17
revoked, the GLO or GLA MUST NOT use it to generate the 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 GLProvideCert: glProvideCert control attribute shall have the syntax GLManageCert:
GLProvideCert ::= SEQUENCE { GLManageCert ::= SEQUENCE {
glName GeneralName, glName GeneralName,
glMemberName GeneralName} glMember GLMember }
The fields in GLProvideCert 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.
- glMemberName indicates name of the GL member. - glMember indicates particulars for the GL member:
3.1.15 GL Update Cert - glMemberName indicates the GL memberĘs name.
GL members use glUpdateCert to provide a new certificate for the GL. - glMemberAddress indicates the GL memberĘs address. It MAY be
GL members may generate a glUpdateCert unsolicited or as a result of omitted.
a glProvideCert message. GL members MUST sign the glUpdateCert. If
the GL member's encryption certificate has been revoked, the GL
member MUST NOT use it to generate the EnvelopedData that
encapsulates the glUpdateCert request or response. The glUpdateCert
control attribute shall have the syntax GLUpdateCert:
GLUpdateCert ::= SEQUENCE { - certificates SHOULD be omitted.
Turner 19
3.1.15 Update Cert
GL members and GLOs use glUpdateCert to provide a new certificate
for the GL. GL members may generate a glUpdateCert unsolicited or as
a result of a glProvideCert message. GL members MUST sign the
glUpdateCert. If the GL memberĘs encryption certificate has been
revoked, the GL member MUST NOT use it to generate the EnvelopedData
that encapsulates the glUpdateCert request or response. The
glUpdateCert control attribute shall have the syntax GLManageCert:
GLManageCert ::= SEQUENCE {
glName GeneralName, glName GeneralName,
glMember GLMember } glMember GLMember }
The fields in GLUpdateCert 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.
- glMemberCert indicates the particulars for the GL member. - glMember indicates the particulars for the GL member:
glMemberName indicates the GL member's name and glMemberAddress
indicates the GL member's address. certificates.membersPKC
includes the member's encryption certificate that will be used
to encrypt the shared KEK for that member.
certificates.membersAC MAY be included to convey any attribute
certificate associated with the member's encryption certificate.
certificates.certificationPath MAY also be included to convey
the certification path corresponding to the member's encryption
and attribute certificates. The certification path is optional
because it may already be included elsewhere in the message
(e.g., in the outer CMS layer).
Turner 18 - glMemberName indicates the GL memberĘs name
- glMemberAddress indicates the GL memberĘs address. It MAY be
omitted.
- certificates MAY be omitted if the GLManageCert message is
sent to request the GL members certificate; else it MUST be
included. It includes the following three fields:
- certificates.pKC includes the member's encryption
certificate that will be used to encrypt the shared KEK for that
member.
- certificates.aC MAY be included to convey any attribute
certificate associated with the memberĘs encryption certificate.
- certificates.certificationPath MAY also be included to
convey the certification path corresponding to the member's
encryption and attribute certificates. The certification path is
optional because it may already be included elsewhere in the
message (e.g., in the outer CMS layer).
Turner 20
3.1.16 GL Key 3.1.16 GL Key
The GLA uses glKey to distribute the shared KEK. The glKey message The GLA uses glKey to distribute the shared KEK. The glKey message
MUST be signed by the GLA. The glKey control attribute shall have MUST be signed by the GLA. The glKey control attribute shall have
the syntax GLKey: the syntax GLKey:
GLKey ::= SEQUENCE { GLKey ::= SEQUENCE {
glName GeneralName, glName GeneralName,
glIdentifier OCTET STRING, glIdentifier OCTET STRING,
skipping to change at line 935 skipping to change at line 998
glkNotBefore GeneralizedTime, glkNotBefore GeneralizedTime,
glkNotAfter GeneralizedTime } glkNotAfter GeneralizedTime }
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. When GL - glIdentifier is the key identifier of the shared KEK. When GL
members use the shared KEK to encrypt data objects for other GL members use the shared KEK to encrypt data objects for other GL
members, they place the glIdentifier in members, they place the glIdentifier in
RecipientInfo.kekri.kekid.keyIdentifier field. Two options are RecipientInfo.kekri.kekid.keyIdentifier field. There are many
provided to generate a unique key identifier. The first choice ways to do this here are two options are provided to generate a
concatenates the GLA's subject name from the digital signature unique key identifier. The first choice concatenates the GLAĘs
certificate used to sign the glKey message and counter. The subject name from the digital signature certificate used to sign
second choice concatenates the GLA's subjectKeyIdentifier, from the glKey message and counter. The second choice concatenates
the digital signature certificate used to sign the glKey the GLAĘs subjectKeyIdentifier, from the digital signature
message, and a counter. The second choice must be supported. certificate used to sign the glKey message, and a counter.
- glkWrapped is the GL's wrapped shared KEK. The RecipientInfos - glkWrapped is the GL's wrapped shared KEK. The RecipientInfos
shall be generated as specified in paragraph 6.2 of CMS [2]. The shall be generated as specified in section 6.2 of CMS [2]. The
kari RecipientInfo choice MUST be supported. The EncryptedKey ktri RecipientInfo choice MUST be supported. The key in the
field, which is the shared KEK, MUST be generated according to EncryptedKey field (i.e., the distributed shared KEK) MUST be
the paragraph concerning random number generation in the generated according to the section concerning random number
security considerations of CMS [2]. 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. with. The parameters are conveyed via the SMIMECapabilities
attribute see MSG {x}.
- 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 UTC
(Zulu) and MUST include seconds (i.e., times are (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 UTC
(Zulu) and MUST include seconds (i.e., times are (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.
Turner 19 Turner 21
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.recipientMutuallyAware is set to if glUseKEK.glKeyAttributes.recipientsNotMutuallyAware is set to
FALSE. FALSE. For each recipient you want to generate a message that
contains that recipientĘs key (i.e., one message with one
attribute).
- The GLA MUST generate X number of glKey messages, where X is the - The GLA MUST generate X number of glKey messages, where X is the
value in glUseKEK.glKeyAttributes.generationCounter. value in glUseKEK.glKeyAttributes.generationCounter.
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.recipientMutuallyAware is set to if glRekey.glNewKeyAttributes.recipientsNotMutuallyAware is set
FALSE. to FALSE.
- The GLA MUST generate X number of glKey messages, where X is the - The GLA MUST generate X number of glKey messages, where X is the
value in glUseKEK.glKeyAttributes.generationCounter. If the value in glUseKEK.glKeyAttributes.generationCounter.
value is zero (0), the GLA MUST generate X number of glKey
messages, where X is the number of outstanding shared KEKs for - The GLA MUST generate X number of glKey messages, where X is the
the GL (e.g., if there are two outstanding shared KEK and the number of outstanding shared KEKs for the GL if glRekeyAllGLKeys
generationCounter for the glUseKEK message was set to three then is set to TRUE.
two glKey messages are generated).
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.recipientMutuallyAware that set if glUseKEK.glNewKeyAttributes.recipientsNotMutuallyAware that
up the GL was set to FALSE. set up the GL was set to FALSE.
- The GLA MUST generate X glKey messages prior to the duration on - The GLA MAY generate X glKey messages prior to the duration on
the last outstanding shared KEK expiring, where X is the the last outstanding shared KEK expiring, where X is the
generationCounter minus one (1). generationCounter minus one (1). Other distribution mechanisms
may also be supported to support this functionality.
3.2 Use of CMC, CMS, and PKIX 3.2 Use of CMC, CMS, and PKIX
The following paragraphs outline the use of CMC, CMS, and PKIX. The following sections outline the use of CMC, CMS, and PKIX.
3.2.1 Protection Layers 3.2.1 Protection Layers
The following paragraphs outline the protection required for the The following sections outline the protection required for the
control attributes defined herein. control attributes defined herein.
Turner 20 Turner 22
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 1042 skipping to change at line 1108
the optional additional wrappings: the optional additional wrappings:
Confidentiality Protection A&I of Confidentiality Protection Confidentiality Protection A&I 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 corresponding outgoing If an incoming message was encrypted, the confidentiality of the
message MUST also be encrypted. All EnvelopedData objects MUST be message MUST be preserved. All EnvelopedData objects MUST be
processed as specified in CMS [2]. processed as specified in CMS [2].
If the GLO or GL member applies confidentiality to a request, the If the GLO or GL member applies confidentiality to a request, the
EnvelopedData MUST be encrypted for the GLA. If the GLA is to EnvelopedData MUST be encrypted for the GLA. If the GLA is to
forward the GL member request to the GLO, the GLA decrypts the forward the GL member request to the GLO, the GLA decrypts the
EnvelopedData, strips the confidentiality layer off, and applies its EnvelopedData, strips the confidentiality layer off, and applies its
own confidentiality layer for the GLO. own confidentiality layer for the GLO.
3.2.2 Combining Requests and Responses 3.2.2 Combining Requests and Responses
Mutlipe 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
Turner 21 Turner 23
different GLs (i.e., requests corresponding to two different GLs are different GLs (i.e., requests corresponding to two different GLs are
included in different cmsSequences). The following is a diagram included in different cmsSequences). The following is a diagram
depicting multiple requests and responses combined in one PKIData depicting multiple requests and responses combined in one PKIData
and PKIResponse: and PKIResponse:
Multiple Request and Response Multiple Request and Response
Request Response Request Response
------- -------- ------- --------
SignedData SignedData SignedData SignedData
PKIData PKIResponse PKIData PKIResponse
cmsSequence cmsSequence cmsSequence cmsSequence
SignedData SignedData SignedData SignedData
PKIData PKIResponse PKIData PKIResponse
controlSequence controlSequence controlSequence controlSequence
Zero or more requests Zero or more responses 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
Zero or more requests Zero or more responses One or more requests One or more responses
corresponding to another GL. corresponding to another GL. corresponding to another GL. corresponding to another GL.
When applying confidentiality to multiple requests and responses, 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
skipping to change at line 1105 skipping to change at line 1171
PKIResponse PKIResponse
controlSequence controlSequence
Zero or more requests Zero or more requests
corresponding to one GL. corresponding to one GL.
SignedData SignedData
PKIData PKIData
controlSequence controlSequence
Zero or more requests Zero or more requests
corresponding to one GL. corresponding to one GL.
Turner 22 Turner 24
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
glFailInfo & glKey
To avoid unnecessary errors, certain requests and responses should To avoid unnecessary errors, certain requests and responses should
be processed prior to others. The following is the priority of be processed prior to others. The following is the priority of
message processing, if not listed it is an implementation decision message processing, if not listed it is an implementation decision
as to which to process first: glUseKEK before glAddMember, glRekey as to which to process first: glUseKEK before glAddMember, glRekey
before glAddMember, and glDeleteMember before glRekey. before glAddMember, and glDeleteMember before glRekey. It should be
noted that there is a priority but it does not imply an order.
3.2.3 GLA Generated Messages 3.2.3 GLA Generated Messages
When the GLA generates a glSuccessInfo, it generates one for each When the GLA generates a glSuccessInfo, it generates one for each
request. action.actionCode values of assignedKEK, deletedGL, request. action.actionCode values of assignedKEK, deletedGL,
rekeyedGL, addedGLO, and deletedGLO are not returned to GL members. rekeyedGL, addedGLO, and deletedGLO are not returned to GL members.
Likewise, when the GLA generates glFailInfo it generates one each Likewise, when the GLA generates glFailInfo it generates one each
request. error values of unsupportedDuration, request. error values of unsupportedDuration,
unsupportedDeliveryMethod, unsupportedAlgorithm, noGLONameMatch, unsupportedDeliveryMethod, unsupportedAlgorithm, noGLONameMatch,
nameAlreadyInUse, alreadyAnOwner, notAnOwner are not returned to GL nameAlreadyInUse, alreadyAnOwner, notAnOwner are not returned to GL
members. members.
If GLKeyAttributes.recipientMutuallyAware is set to FALSE, a If GLKeyAttributes.recipientsNotMutuallyAware is set to FALSE, a
separate PKIResponse.glSucessInfo, PKIResponse.glFailInfo, and separate PKIResponse.glSucessInfo, PKIResponse.glFailInfo, and
PKIData.glKey MUST be generated for each recipient. PKIData.glKey MUST be generated for each recipient. It is valid to
send one message with multiple attributes to the same recipient.
If the GL has multiple GLOs, the GLA MUST send the glSuccessInfo and If the GL has multiple GLOs, the GLA MUST send the glSuccessInfo and
glFailInfo messages to the requesting GLO. The mechanism another GLO glFailInfo messages to the requesting GLO. The mechanism to
to determine which GLO made the request is beyond the scope of this determine which GLO made the request is beyond the scope of this
document. document.
Turner 23 Turner 25
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
skipping to change at line 1193 skipping to change at line 1260
information. information.
cMCStatusInfo is used by GLOs, GLAs, and GL members to indicate that cMCStatusInfo is used by GLOs, GLAs, and GL members to indicate that
signature verification failed. If the signature failed to verify, signature verification failed. If the signature failed to verify,
the cMCStatusInfo control attribute MUST be returned indicating the cMCStatusInfo 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.
[Not sure the above is completely correct.]
cMCStatusInfo is also used by GLOs and GLAs to indicate that a cMCStatusInfo 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 cMCStatusInfo be processed immediately by the GLA or GLO, the cMCStatusInfo
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
Turner 24
approval (for managed lists), the GLA MUST NOT return a approval (for managed lists), the GLA MUST NOT return a
cMCStatusInfo indicating query pending. cMCStatusInfo indicating query pending.
Turner 26
cMCStatusInfo is also used by GLAs to indicate that a cMCStatusInfo is also used by GLAs to indicate that a
glaQueryRequest is not supported. If the glaQueryRequest is not glaQueryRequest is not supported. If the glaQueryRequest is not
supported, the cMCStatusInfo control attribute MUST be returned supported, the cMCStatusInfo 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.
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 cMCStatusInfo response it generates one for the GLA with generates a cMCStatusInfo response it generates one for the GLA with
the GLA's transactionId and one for the GL member with the GL the GLAĘs transactionId and one for the GL member with the GL
member's transactionId. memberĘs transactionId.
senderNonce and recipientNonce (see paragraph 5.6 of [3]) MAY be
used to provide application-level replay prevention. Originating
messages include only a value for senderNonce. If a message includes
a senderNonce, the response MUST include the transmitted value of
the previously received senderNonce as recipientNonce and include a
new value for senderNonce. If GL members include a senderNonce and
the request is redirected to the GLO, the GLA MAY include an
additional senderNonce in the outer PKIData. If the GLA included an
additional senderNonce in the outer PKIData, when the GLO generates
the response:
- It generates one for the GLA by including the senderNonce from The use of nonces (see section 5.6 of [3]) can be used to provide
the GLA as the recipientNonce and includes a new value for application-level replay prevention. If the originating message
senderNonce includes a senderNonce, the response to the message MUST include the
received senderNonce value as the recipientNonce and a new value as
a the senderNonce value in the response.
- It generates one for the GL member by including the senderNonce If a GLA aggratates multiple messages together or forwards a message
from the GL member as the recipientNonce and includes a new to a GLO, the GLA can optionally generate a new nonce value and
value for senderNonce. The value of this senderNonce MUST be include that in the wrapping message. When the response comes back
different than the value in the senderNonce returned to the GLA. 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
originating messages.
The following is the implementation requirement for the CMC control The following is the implementation requirement for the CMC control
attributes: attributes:
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 N/A | MUST MUST | cMCStatus MUST MUST | MUST MUST - | MUSTMUST | cMCStatus
MAY MAY | MAY MAY N/A | MAY MAY | transactionId MAY MAY | MAY MAY - | MAY MAY | transactionId
MAY MAY | MAY MAY N/A | MAY MAY | senderNonce MAY MAY | MAY MAY - | MAY MAY | senderNonce
MAY MAY | MAY MAY N/A | MAY MAY | recepientNonce MAY MAY | MAY MAY - | MAY MAY | recepientNonce
Turner 25
3.2.5 Resubmitted GL Member Messages 3.2.5 Resubmitted GL Member Messages
When the GL is managed the GLA forwards GL member requests to the When the GL is managed, the GLA forwards the GL member requests to
GLO for GLO approval. If the GLO approves the request it reforms the the GLO for GLO approval by creating a new request message
glAddMember, glDeleteMember, or glkCompromise message by stripping containing the GL member request(s) as a cmsSequence item. If the
of the GL member's signature and resigning the request. 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
Turner 27
GLA. (Note in this case there are now 3 layers of PKIData messages
with appropriate signing layers.)
3.2.6 PKIX 3.2.6 PKIX
Signatures, certificates, and CRLs are verified according to PKIX Signatures, certificates, and CRLs are verified according to PKIX
[6]. [6].
Name matching is performed according to PKIX [6]. Name matching is performed according to PKIX [6].
All distinguished name forms must follow the UTF8String convention
noted in PKIX [6].
A certificate per-GL would be issued to the GLA.
GL policy may mandate that the GL memberĘs address be included in
the GL 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 of messages'
request and response combinations in detail. The procedures defined request and response combinations in detail. The procedures defined
in this paragraph are not prescriptive. in 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 MUST be setup and a shared KEK
assigned to the GL. Figure 3 depicts the protocol interactions to assigned to the GL. Figure 3 depicts the protocol interactions to
setup and assign a shared KEK. Note that error messages are not 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 |
skipping to change at line 1300 skipping to change at line 1368
The process is as follows: The process is as follows:
1 - The GLO is the entity responsible for requesting the creation 1 - The GLO is the entity responsible for requesting the creation
of the GL. The GLO sends a of the GL. The GLO sends a
SignedData.PKIData.controlSequence.glUseKEK request to the GLA SignedData.PKIData.controlSequence.glUseKEK request to the GLA
(1 in Figure 3). The GLO MUST include: glName, 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 recipientMutuallyAware,
the requested algorithm to be used with the shared KEK in
requestedAlgorithm, the duration of the shared KEK, and how
Turner 26 Turner 28
many shared KEKs should be initially distributed in should be sent to each recipient in
generationCounter. recipientsNotMutuallyAware, the requested algorithm to be used
with the shared KEK in requestedAlgorithm, the duration of the
shared KEK, and how many shared KEKs should be initially
distributed in generationCounter.
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 MAY be included in the same glAddMember request(s) MAY be included in the same
controlSequence as the glUseKEK request (see paragraph controlSequence as the glUseKEK request (see section 3.2.2).
3.2.2). The GLO MUST indicate the same glName in the The GLO MUST indicate the same glName in the glAddMember
glAddMember request as in glUseKEK.glInfo.glName. Further request as in glUseKEK.glInfo.glName. Further glAddMember
glAddMember procedures are covered in paragraph 4.3. procedures are covered in section 4.3.
1.b - The GLO MAY optionally apply confidentiality to the request 1.b - The GLO MAY optionally apply confidentiality to the request
by encapsulating the SignedData.PKIData in an EnvelopedData by encapsulating the SignedData.PKIData in an EnvelopedData
(see paragraph 3.2.1.2). (see section 3.2.1.2).
1.c - The GLO MAY also optionally apply another SignedData over 1.c - The GLO MAY also optionally apply another SignedData over
the EnvelopedData (see paragraph 3.2.1.2). the EnvelopedData (see 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 paragraphs 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 MUST verify 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 signature(s) does(do) not verify, the GLA MUST return 2.a - If the signatures do not verify, the GLA MUST return a
a cMCStatusInfo response indicating cMCStatus.failed and cMCStatusInfo response indicating cMCStatus.failed and
otherInfo.failInfo.badMessageCheck. otherInfo.failInfo.badMessageCheck.
2.b - If the signature(s) does(do) verify but the GLA does not 2.b ū Else if the signatures do verify but the GLA does not have a
have a valid certificate, the GLA MUST return a valid certificate, the GLA MUST return a
glFailInfo.errorCode.noValidGLACertificate. glFailInfo.errorCode.noValidGLACertificate. Instead of
immediately returning the error code, the GLA MAY attempt to
get a certificate, possibly using CMC [3].
2.c - If the signature(s) does(do) verify and the GLA does have a 2.c - Else the signatures do verify and the GLA does have a valid
valid certificate, the GLA MUST check that one of the names certificate, the GLA MUST check that one of the names in the
in the certificate used to sign the request matches one of certificate used to sign the request matches one of the
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 2.c.1 - If the names do not match, the GLA MUST return a response
indicating glFailInfo.errorCode.noGLONameMatch. indicating glFailInfo.errorCode.noGLONameMatch.
2.c.2 - If names do all match, the GLA MUST ensure the requested Turner 29
glName is not already in use. The GLA MUST also check any 2.c.2 - Else names do all match, the GLA MUST check that the
glAddMember included within the controlSequence with this glName and glAddress is not already in use. The GLA MUST
glUseKEK. Further processing of the glAddMember is covered also check any glAddMember included within the
in paragraph 4.3. controlSequence with this glUseKEK. Further processing of
the glAddMember 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 MUST return a
response indicating response indicating
glFailInfo.errorCode.nameAlreadyInUse. glFailInfo.errorCode.nameAlreadyInUse.
Turner 27 2.c.2.b - Else the requestedAlgorithm is not supported, the GLA
2.c.2.b - If the requestedAlgorithm is not supported, the GLA MUST MUST return a response indicating
return a response indicating
glFailInfo.errorCode.unsupportedAlgorithm. glFailInfo.errorCode.unsupportedAlgorithm.
2.c.2.c - If the duration is not supportable, determining this is 2.c.2.c - Else the duration is not supportable, determining this
beyond the scope of this document, the GLA MUST return a is beyond the scope of this document, the GLA MUST
response indicating return a response indicating
glFailInfo.errorCode.unsupportedDuration. glFailInfo.errorCode.unsupportedDuration.
2.c.2.d - If the glAdministration is set to closed (0) and there 2.c.2.d - Else the GL is not supportable for other reasons, which
is more than one GLO in glOwner, the GLA MUST return a
response indicating
glFailInfo.errorCode.onlyOneGLOAllowed.
2.c.2.e - If the GL is not supportable for other reasons, which
the GLA does not wish to disclose, the GLA MUST return a the GLA does not wish to disclose, the GLA MUST return a
response indicating glFailInfo.errorCode.unspecified. response indicating glFailInfo.errorCode.unspecified.
2.c.2.f - If the glName is not already in use, the duration is 2.c.2.e - Else the glName is not already in use, the duration is
supportable, and the requestedAlgorithm is supported, supportable, and the requestedAlgorithm is supported,
the GLA MUST return a glSuccessInfo indicating the the GLA MUST return a glSuccessInfo indicating the
glName, the corresponding glIdentifier, and an glName, the corresponding glIdentifier, and an
action.actionCode.assignedKEK (2 in Figure 3). The GLA action.actionCode.assignedKEK (2 in Figure 3). The GLA
also takes administrative actions, which are beyond the also takes administrative actions, which are beyond the
scope of 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 paragraph GLA also sends a glKey message as described in section
5. 5.
2.c.2.f.1 - The GLA MUST apply confidentiality to the response by 2.c.2.e.1 - The GLA MUST apply confidentiality to the response by
encapsulating the SignedData.PKIResponse in an encapsulating the SignedData.PKIResponse in an
EnvelopedData if the request was encapsulated in an EnvelopedData if the request was encapsulated in an
EnvelopedData (see paragraph 3.2.1.2). EnvelopedData (see section 3.2.1.2).
2.c.2.f.2 - The GLA MAY also optionally apply another SignedData 2.c.2.e.2 - The GLA MAY also optionally apply another SignedData
over the EnvelopedData (see paragraph 3.2.1.2). over the EnvelopedData (see section 3.2.1.2).
3 - Upon receipt of the glSuccessInfo or glFailInfo responses, the 3 - Upon receipt of the glSuccessInfo or glFailInfo responses, the
GLO verifies the GLA's signature(s). If an additional GLO verifies the GLA's signature(s). If an additional
SignedData and/or EnvelopedData encapsulates the response (see SignedData and/or EnvelopedData encapsulates the response (see
paragraph 3.2.1.2 or 3.2.2), the GLO MUST verify the outer section 3.2.1.2 or 3.2.2), the GLO MUST verify the outer
signature and/or decrypt the outer layer prior to verifying 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 MUST return a 3.a - If the signatures do not verify, the GLO MUST return a
cMCStatusInfo response indicating cMCStatus.failed and cMCStatusInfo response indicating cMCStatus.failed and
otherInfo.failInfo.badMessageCheck. otherInfo.failInfo.badMessageCheck.
3.b - If the signatures do verify and the response was Turner 30
3.b - Else the signatures do verify, the GLO MUST check that one
of the names in the certificate used to sign the response
matches the name of the GL.
3.b.1 ū If the GLĘs name does not match the name present in the
certificate used to sign the message, the GLO should not
believe the response.
3.b.2 ū Else the GLĘs name does match the name present in the
certificate and:
3.b.2.a - If the signatures do verify and the response was
glSuccessInfo, the GLO has successfully created the GL. glSuccessInfo, the GLO has successfully created the GL.
Turner 28 3.b.2.b - Else the signatures do verify and the response was
3.c - If the signatures do verify and the response was glFailInfo, glFailInfo, the GLO MAY reattempt to create the GL using
the GLO MAY reattempt to create the GL using the information the information provided in the glFailInfo response. The
provided in the glFailInfo response. The GLO may also use GLO may also use the glaQueryRequest to determine the
the glaQueryRequest to determine the algorithms and other algorithms and other characteristics supported by the GLA
characteristics supported by the GLA (see paragraph 4.9). (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 must delete the GL. Figure 4 depicts
that protocol interactions to delete a GL. that protocol interactions to delete a GL.
+-----+ 1 2 +-----+ +-----+ 1 2 +-----+
| GLA | <-------> | GLO | | GLA | <-------> | GLO |
+-----+ +-----+ +-----+ +-----+
skipping to change at line 1436 skipping to change at line 1513
The process is as follows: The process is as follows:
1 - The GLO is the entity responsible for requesting the deletion 1 - The GLO is the entity responsible for requesting the deletion
of the GL. The GLO sends a of the GL. The GLO sends a
SignedData.PKIData.controlSequence.glDelete request to the GLA SignedData.PKIData.controlSequence.glDelete request to the GLA
(1 in Figure 4). The name of the GL to be deleted MUST be (1 in Figure 4). The name of the GL to be deleted MUST be
included in GeneralName. included in GeneralName.
1.a - The GLO MAY optionally apply confidentiality to the request 1.a - The GLO MAY optionally apply confidentiality to the request
by encapsulating the SignedData.PKIData in an EnvelopedData by encapsulating the SignedData.PKIData in an EnvelopedData
(see paragraph 3.2.1.2). (see section 3.2.1.2).
1.b - The GLO MAY also optionally apply another SignedData over 1.b - The GLO MAY also optionally apply another SignedData over
the EnvelopedData (see paragraph 3.2.1.2). the EnvelopedData (see section 3.2.1.2).
Turner 31
2 - Upon receipt of the request the GLA verifies the signature on 2 - Upon receipt of the request the GLA verifies the signature on
the inner most SignedData.PKIData. If an additional SignedData the inner most SignedData.PKIData. If an additional SignedData
and/or EnvelopedData encapsulates the request (see paragraph and/or EnvelopedData encapsulates the request (see 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 MUST verify the outer signature
and/or decrypt the outer layer prior to verifying the and/or decrypt the outer layer prior to verifying the
signature on the inner most SignedData. signature on the inner most SignedData.
2.a - If the signature(s) does(do) not verify, the GLA MUST return 2.a - If the signatures do not verify, the GLA MUST return a
a cMCStatusInfo response indicating cMCStatus.failed and cMCStatusInfo response indicating cMCStatus.failed and
otherInfo.failInfo.badMessageCheck. otherInfo.failInfo.badMessageCheck.
2.b - If the signature(s) does(do) verify, the GLA MUST make sure 2.b - Else the signatures do verify, the GLA MUST make sure the GL
the GL is supported by checking the GL's Name matches a is supported by checking the GLĘs Name matches a glName
glName stored on the GLA. stored on the GLA.
Turner 29
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 MUST
return a response indicating return a response indicating
glFailInfo.errorCode.invalidGLName. glFailInfo.errorCode.invalidGLName.
2.b.2 - If the glName is supported by the GLA, the GLA MUST ensure 2.b.2 - Else the glName is supported by the GLA, the GLA MUST
a registered GLO signed the glDelete request by checking ensure a registered GLO signed the glDelete request by
if one of the names present in the digital signature checking if one of the names present in the digital
certificate used to sign the glDelete request matches a signature certificate used to sign the glDelete request
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 MUST return a
response indicating glFailInfo.errorCode.noGLONameMatch. response indicating glFailInfo.errorCode.noGLONameMatch.
2.b.2.b - If the names do match but the GL is not deletable for 2.b.2.b - Else the names do match but the GL is not deletable for
other reasons, which the GLA does not wish to disclose, other reasons, which the GLA does not wish to disclose,
the GLA MUST return a response indicating the GLA MUST return a response indicating
glFailInfo.errorCode.unspecified. Actions beyond the glFailInfo.errorCode.unspecified. Actions beyond the
scope of this document must then be taken to delete the scope of this document must then be taken to delete the
GL from the GLA. GL from the GLA.
2.b.2.c - If the names do match, the GLA MUST return a 2.b.2.c - Else the names do match, the GLA MUST return a
glSuccessInfo indicating the glName, and an glSuccessInfo indicating the glName, and an
action.actionCode.deletedGL (2 in Figure 4). action.actionCode.deletedGL (2 in Figure 4).
glMemberName and glOwnerName MUST be omitted. The GLA glMemberName and glOwnerName MUST be omitted. The GLA
MUST not accept further requests for member additions, MUST not accept further requests for member additions,
member deletions, or group rekeys for this GL. member deletions, or group rekeys for this GL.
2.b.2.c.1 - The GLA MUST apply confidentiality to the response by 2.b.2.c.1 - The GLA MUST apply confidentiality to the response by
encapsulating the SignedData.PKIResponse in an encapsulating the SignedData.PKIResponse in an
EnvelopedData if the request was encapsulated in an EnvelopedData if the request was encapsulated in an
EnvelopedData (see paragraph 3.2.1.2). EnvelopedData (see 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 also optionally apply another SignedData
over the EnvelopedData (see paragraph 3.2.1.2). over the EnvelopedData (see section 3.2.1.2).
3 - Upon receipt of the glSuccessInfo or glFailInfo response, the 3 - Upon receipt of the glSuccessInfo or glFailInfo response, the
GLO verifies the GLA's signature(s). If an additional GLO verifies the GLA's signature(s). If an additional
Turner 32
SignedData and/or EnvelopedData encapsulates the response (see SignedData and/or EnvelopedData encapsulates the response (see
paragraph 3.2.1.2 or 3.2.2), the GLO MUST verify the outer section 3.2.1.2 or 3.2.2), the GLO MUST verify the outer
signature and/or decrypt the outer layer prior to verifying 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 signature(s) does(do) not verify, the GLO MUST return 3.a - If the signatures do not verify, the GLO MUST return a
a cMCStatusInfo response indicating cMCStatus.failed and cMCStatusInfo response indicating cMCStatus.failed and
otherInfo.failInfo.badMessageCheck. otherInfo.failInfo.badMessageCheck.
3.b - If the signatures do verify and the response was 3.b - Else the signatures do verify, the GLO MUST check that one
glSuccessInfo, the GLO has successfully deleted the GL. of the names in the certificate used to sign the response
matches the name of the GL.
3.c - If the signatures do verify and the response was glFailInfo, 3.b.1 ū If the GLĘs name does not match the name present in the
the GLO MAY reattempt to delete the GL using the information certificate used to sign the message, the GLO should not
provided in the glFailInfo response. believe the response.
Turner 30 3.b.2 ū Else the GLĘs name does match the name present in the
certificate and:
3.b.2.a - If the signatures do verify and the response was
glSuccessInfo, the GLO has successfully deleted the GL.
3.b.2.b - Else the signatures do verify and the response was
glFailInfo, the GLO MAY reattempt to delete the GL using
the information provided in the glFailInfo 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 paragraph 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
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
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 paragraphs 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.
Turner 33
+-----+ 2,B{A} 3 +----------+ +-----+ 2,B{A} 3 +----------+
| GLO | <--------+ +-------> | Member 1 | | GLO | <--------+ +-------> | Member 1 |
+-----+ | | +----------+ +-----+ | | +----------+
1 | | 1 | |
+-----+ <--------+ | 3 +----------+ +-----+ <--------+ | 3 +----------+
| GLA | A +-------> | ... | | GLA | A +-------> | ... |
+-----+ <-------------+ +----------+ +-----+ <-------------+ +----------+
| |
| 3 +----------+ | 3 +----------+
+-------> | Member n | +-------> | Member n |
+----------+ +----------+
Figure 5 - Member Addition Figure 5 - Member Addition
An important decision that needs to be made on a group by group An important decision that needs to be made on a group by group
basis is whether to rekey the group every time a new member is basis is whether to rekey the group every time a new member is
added. Typically, unmanaged GLs should not be rekeyed when a new added. Typically, unmanaged GLs should not be rekeyed when a new
member is added, as the overhead associated with rekeying the group member is added, as the overhead associated with rekeying the group
becomes prohibitive, as the group becomes large. However, managed becomes prohibitive, as the group becomes large. However, managed
and closed GLs MUST be rekeyed to maintain the secrecy of the group. and closed GLs MAY be rekeyed to maintain the secrecy of the group.
An option to rekeying managed or closed GLs when a member is added An option to rekeying managed or closed GLs when a member is added
is to generate a new GL with a different group key. Group rekeying is to generate a new GL with a different group key. Group rekeying
is discussed in paragraphs 4.5 and 5. is discussed in sections 4.5 and 5.
Turner 31
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 MUST include: 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.membersPKC. The GLO MAY certificate in glMember.certificates.pKC. The GLO MAY also
also include any attribute certificates associated with the include any attribute certificates associated with the
member's encryption certificate in memberĘs encryption certificate in glMember.certificates.aC,
glMember.certificates.membersAC, and the certification path and the certification path associated with the memberĘs
associated with the member's encryption and attribute encryption and attribute certificates in
certificates in glMember.certificates.certificationPath. glMember.certificates.certificationPath.
1.a - The GLO MAY optionally apply confidentiality to the request 1.a - The GLO MAY optionally apply confidentiality to the request
by encapsulating the SignedData.PKIData in an EnvelopedData by encapsulating the SignedData.PKIData in an EnvelopedData
(see paragraph 3.2.1.2). (see section 3.2.1.2).
1.b - The GLO MAY also optionally apply another SignedData over 1.b - The GLO MAY also optionally apply another SignedData over
the EnvelopedData (see paragraph 3.2.1.2). the EnvelopedData (see 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 paragraph
Turner 34
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 MUST verify the outer signature
and/or decrypt the outer layer prior to verifying the and/or decrypt the outer layer prior to verifying the
signature on the inner most SignedData. signature on the inner most SignedData.
2.a - If the signature(s) does(do) not verify, the GLA MUST return 2.a - If the signatures do not verify, the GLA MUST return a
a cMCStatusInfo response indicating cMCStatus.failed and cMCStatusInfo response indicating cMCStatus.failed and
otherInfo.failInfo.badMessageCheck. otherInfo.failInfo.badMessageCheck.
2.b - If the signature(s) does(do) verify, the glAddMember request 2.b - Else the signatures do verify, the glAddMember request is
is included in a controlSequence with the glUseKEK request, included in a controlSequence with the glUseKEK request, and
and the processing in paragraph 4.1 item 2.e is successfully the processing in section 4.1 item 2.e is successfully
completed the GLA MUST return a glSuccessInfo indicating the completed the GLA MUST return a glSuccessInfo indicating the
glName, the corresponding glIdentifier, an glName, the corresponding glIdentifier, an
action.actionCode.addedMember, and action.glMemberName (2 in action.actionCode.addedMember, and action.glMemberName (2 in
Figure 5). Figure 5).
2.b.1 - The GLA MUST apply confidentiality to the response by 2.b.1 - The GLA MUST apply confidentiality to the response by
encapsulating the SignedData.PKIData in an EnvelopedData encapsulating the SignedData.PKIData in an EnvelopedData
if the request was encapsulated in an EnvelopedData (see if the request was encapsulated in an EnvelopedData (see
paragraph 3.2.1.2). section 3.2.1.2).
2.b.2 - The GLA MAY also optionally apply another SignedData over 2.b.2 - The GLA MAY also optionally apply another SignedData over
the EnvelopedData (see paragraph 3.2.1.2). the EnvelopedData (see section 3.2.1.2).
Turner 32 2.c - Else the signatures do verify and the GLAddMember request is
2.c - If the signature(s) does(do) verify and the GLAddMember not included in a controlSequence with the GLCreate request,
request is not included in a controlSequence with the the GLA MUST make sure the GL is supported by checking that
GLCreate request, the GLA MUST make sure the GL is supported the glName matches a glName stored on the GLA.
by checking that the glName matches a glName stored on the
GLA.
2.c.1 - If the glName is not supported by the GLA, the GLA MUST 2.c.1 - If the glName is not supported by the GLA, the GLA MUST
return a response indicating return a response indicating
glFailInfo.errorCode.invalidGLName. glFailInfo.errorCode.invalidGLName.
2.c.2 - If the glName is supported by the GLA, the GLA MUST check 2.c.2 - Else the glName is supported by the GLA, the GLA MUST
to see if the glMemberName is present on the GL. check 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 MUST
return a response indicating return a response indicating
glFailInfo.errorCode.alreadyAMember. glFailInfo.errorCode.alreadyAMember.
2.c.2.b - If the glMemberName is not present on the GL, the GLA 2.c.2.b - Else the glMemberName is not present on the GL, the GLA
MUST check 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 MUST check that a
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 a registered GLO. to 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 MUST return a
response indicating response indicating
glFailInfo.errorCode.noGLONameMatch. glFailInfo.errorCode.noGLONameMatch.
2.c.2.b.1.b - If the names do match, the GLA MUST verify the Turner 35
2.c.2.b.1.b - Else the names do match, the GLA MUST verify 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 does not
verify, the GLA MAY return a response indicating verify, the GLA MAY return a response indicating
glFailInfo.errorCode.invalidCert to the GLO. If glFailInfo.errorCode.invalidCert to the GLO. If
the GLA does not return a glFailInfo response, the the GLA does not return a glFailInfo response, the
GLA MUST issue a glProvideCert request (see GLA MUST issue a glProvideCert request (see
paragraph 4.10). section 4.10).
2.c.2.b.1.b.2 - If the member's certificate does verify, the GLA 2.c.2.b.1.b.2 - Else the member's certificate does verify, the GLA
MUST return a glSuccessInfo to the GLO indicating MUST return a glSuccessInfo to the GLO indicating
the glName, the corresponding glIdentifier, an the glName, the corresponding glIdentifier, an
action.actionCode.addedMember, and action.actionCode.addedMember, and
action.glMemberName (2 in Figure 5). The GLA also action.glMemberName (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 MUST also distribute
the shared KEK to the member via the mechanism the shared KEK to the member via the mechanism
described in paragraph 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 MUST apply confidentiality to the
response by encapsulating the SignedData.PKIData response by encapsulating the SignedData.PKIData
Turner 33
in an EnvelopedData if the request was in an EnvelopedData if the request was
encapsulated in an EnvelopedData (see paragraph encapsulated in an EnvelopedData (see 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 MAY also optionally apply another
SignedData over the EnvelopedData (see paragraph SignedData over the EnvelopedData (see section
3.2.1.2). 3.2.1.2).
2.c.2.b.2 - If the GL is managed, the GLA MUST check that either a 2.c.2.b.2 - Else the GL is managed, the GLA MUST check that either
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 MUST match a registered GLO.
For the prospective member, the name in For the prospective member, the name in
glMember.glMemberName MUST match one of the names in glMember.glMemberName MUST match one of the names in
the certificate used to sign the request. the certificate used to sign the request.
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 MUST return a
response indicating glFailInfo.errorCode.noSpam. response indicating glFailInfo.errorCode.noSpam.
2.c.2.b.2.b - If the signer is a registered GLO, the GLA MUST 2.c.2.b.2.b - Else the signer is a registered GLO, the GLA MUST
verify the member's encryption certificate. verify 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 does not verify, the
GLA MAY return a response indicating GLA MAY return a response indicating
glFailInfo.errorCode.invalidCert. If the GLA does glFailInfo.errorCode.invalidCert. If the GLA does
not return a glFailInfo response, the GLA MUST not return a glFailInfo response, the GLA MUST
issue a glProvideCert request (see paragraph issue a glProvideCert request (see section 4.10).
4.10).
2.c.2.b.2.b.2 - If the member's certificate does verify, the GLA Turner 36
2.c.2.b.2.b.2 - Else the member's certificate does verify, the GLA
MUST return glSuccessInfo indicating the glName, MUST return glSuccessInfo indicating the glName,
the corresponding glIdentifier, an the corresponding glIdentifier, an
action.actionCode.addedMember, and action.actionCode.addedMember, and
action.glMemberName to the GLO (2 in Figure 5). action.glMemberName to the GLO (2 in Figure 5).
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 MUST
also distribute the shared KEK to the member via also distribute the shared KEK to the member via
the mechanism described in paragraph 5. the mechanism described in section 5. The GL
policy may mandate that the GL memberĘs address be
included in the GL memberĘs certificate.
2.c.2.b.2.b.2.a - The GLA MUST apply confidentiality to the 2.c.2.b.2.b.2.a - The GLA MUST apply confidentiality to the
response by encapsulating the SignedData.PKIData response by encapsulating the SignedData.PKIData
in an EnvelopedData if the request was in an EnvelopedData if the request was
encapsulated in an EnvelopedData (see paragraph encapsulated in an EnvelopedData (see 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 MAY also optionally apply another
SignedData over the EnvelopedData (see paragraph SignedData over the EnvelopedData (see section
3.2.1.2). 3.2.1.2).
Turner 34 2.c.2.b.2.c - Else the signer is the prospective member, the GLA
2.c.2.b.2.c - If the signer is the prospective member, the GLA MUST forward the glAddMember request (see section
MUST forward the glAddMember request (see paragraph
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
paragraph 4.3.2. section 4.3.2.
2.c.2.b.2.c.1 - The GLA MUST apply confidentiality to the 2.c.2.b.2.c.1 - The GLA MUST apply confidentiality to the
forwarded request by encapsulating the forwarded request by encapsulating the
SignedData.PKIData in an EnvelopedData if the SignedData.PKIData in an EnvelopedData if the
original request was encapsulated in an original request was encapsulated in an
EnvelopedData (see paragraph 3.2.1.2). EnvelopedData (see section 3.2.1.2).
2.c.2.b.2.c.2 - The GLA MAY also optionally apply another 2.c.2.b.2.c.2 - The GLA MAY also optionally apply another
SignedData over the EnvelopedData (see paragraph SignedData over the EnvelopedData (see section
3.2.1.2). 3.2.1.2).
2.c.2.b.3 - If the GL is unmanaged, the GLA MUST check that either 2.c.2.b.3 - Else the GL is unmanaged, the GLA MUST check that
a registered GLO or the prospective member signed the either a registered GLO or the prospective member
request. For GLOs, one of the names in the certificate signed the request. For GLOs, one of the names in the
used to sign the request MUST match the name of a certificate used to sign the request MUST match the
registered GLO. For the prospective member, the name name of a registered GLO. For the prospective member,
in glMember.glMemberName MUST match one of the names the name in glMember.glMemberName MUST match one of
in the certificate used to sign the request. the names in the certificate used to sign the request.
Turner 37
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 MUST return a response
indicating glFailInfo.errorCode.noSpam. indicating glFailInfo.errorCode.noSpam.
2.c.2.b.3.b - If the signer is either a registered GLO or the 2.c.2.b.3.b - Else the signer is either a registered GLO or the
prospective member, the GLA MUST verify the member's prospective member, the GLA MUST verify 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 does not verify, the
GLA MAY return a response indicating GLA MAY return a response indicating
glFailInfo.errorCode.invalidCert to either the GLO glFailInfo.errorCode.invalidCert to either the GLO
or the prospective member depending on where the or the prospective member depending on where the
request originated. If the GLA does not return a request originated. If the GLA does not return a
glFailInfo response, the GLA MUST issue a glFailInfo response, the GLA MUST issue a
glProvideCert request (see paragraph 4.10) to glProvideCert request (see section 4.10) to either
either the GLO or prospective member depending on the GLO or prospective member depending on where
where the request originated. the request originated.
2.c.2.b.3.b.2 - If the member's certificate does verify, the GLA 2.c.2.b.3.b.2 - Else the member's certificate does verify, the GLA
MUST return a glSuccessInfo indicating the glName, MUST return a glSuccessInfo indicating the glName,
the corresponding glIdentifier, an the corresponding glIdentifier, an
action.actionCode.addedMember, and action.actionCode.addedMember, and
action.glMemberName to the GLO (2 in Figure 5) if action.glMemberName to the GLO (2 in Figure 5) if
the GLO signed the request and to the GL member (3 the GLO signed the request and to the GL member (3
in Figure 5) if the GL member signed the request. in Figure 5) if the GL member signed the request.
Turner 35
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 MUST
also distribute the shared KEK to the member via also distribute the shared KEK to the member via
the mechanism described in paragraph 5. the mechanism described in section 5.
2.c.2.b.3.b.2.a - The GLA MUST apply confidentiality to the 2.c.2.b.3.b.2.a - The GLA MUST apply confidentiality to the
response by encapsulating the SignedData.PKIData response by encapsulating the SignedData.PKIData
in an EnvelopedData if the request was in an EnvelopedData if the request was
encapsulated in an EnvelopedData (see paragraph encapsulated in an EnvelopedData (see section
3.2.1.2). 3.2.1.2).
2.c.2.b.3.b.2.b - The GLA MAY also optionally apply another 2.c.2.b.3.b.2.b - The GLA MAY also optionally apply another
SignedData over the EnvelopedData (see paragraph SignedData over the EnvelopedData (see section
3.2.1.2). 3.2.1.2).
3 - Upon receipt of the glSuccessInfo or glFailInfo response, the 3 - Upon receipt of the glSuccessInfo or glFailInfo response, the
GLO verifies the GLA's signature(s). If an additional GLO verifies the GLA's signature(s). If an additional
SignedData and/or EnvelopedData encapsulates the response (see SignedData and/or EnvelopedData encapsulates the response (see
paragraph 3.2.1.2 or 3.2.2), the GLO MUST verify the outer section 3.2.1.2 or 3.2.2), the GLO MUST verify the outer
signature and/or decrypt the outer layer prior to verifying 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 signature(s) does (do) not verify, the GLO MUST 3.a - If the signatures do not verify, the GLO MUST return a
return a cMCStatusInfo response indicating cMCStatus.failed cMCStatusInfo response indicating cMCStatus.failed and
and otherInfo.failInfo.badMessageCheck. otherInfo.failInfo.badMessageCheck.
3.b - If the signature(s) does(do) verify and the response is Turner 38
3.b - Else the signatures do verify, the GLO MUST check that one
of the names in the certificate used to sign the response
matches the name of the GL.
3.b.1 ū If the GLĘs name does not match the name present in the
certificate used to sign the message, the GLO should not
believe the response.
3.b.2 ū Else the GLĘs name does match the name present in the
certificate and:
3.b.2.a - If the signatures do verify and the response is
glSuccessInfo, the GLO has added the member to the GL. If glSuccessInfo, the GLO has added the member to the GL. If
member was added to a managed list and the original request member was added to a managed list and the original
was signed by the member, the GLO MUST send a request was signed by the member, the GLO MUST send a
cMCStatusInfo.cMCStatus.success to the GL member. cMCStatusInfo.cMCStatus.success to the GL member.
3.c - If the GLO received a glFailInfo, for any reason, the GLO 3.b.2.b - Else the GLO received a glFailInfo, for any reason, the
MAY reattempt to add the member to the GL using the GLO MAY reattempt to add the member to the GL using the
information provided in the glFailInfo response. information provided in the glFailInfo response.
4 - Upon receipt of the glSuccessInfo, glFailInfo, or cMCStatus 4 - Upon receipt of the glSuccessInfo, glFailInfo, or cMCStatus
response, the prospective member verifies the GLA's response, the prospective member verifies the GLA's signatures
signature(s) or GLO's signature(s). If an additional or GLOĘs signatures. If an additional SignedData and/or
SignedData and/or EnvelopedData encapsulates the response (see EnvelopedData encapsulates the response (see section 3.2.1.2
paragraph 3.2.1.2 or 3.2.2), the GLO MUST verify the outer or 3.2.2), the GLO MUST verify 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.
4.a - If the signatures do not verify, the prospective member MUST 4.a - If the signatures do not verify, the prospective member MUST
return a cMCStatusInfo response indicating cMCStatus.failed return a cMCStatusInfo response indicating cMCStatus.failed
and otherInfo.failInfo.badMessageCheck. and otherInfo.failInfo.badMessageCheck.
4.b - If the signatures do verify, the prospective member has been 4.b - Else the signatures do verify, the GL member MUST check that
added to the GL. one of the names in the certificate used to sign the
response matches the name of the GL.
Turner 36 4.b.1 ū If the GLĘs name does not match the name present in the
4.c - If the prospective member received a glFailInfo, for any certificate used to sign the message, the GL member should
reason, the prospective member MAY reattempt to add not believe the response.
4.b.2 ū Else the GLĘs name does match the name present in the
certificate and:
4.b.2.a - If the signatures do verify, the prospective member has
been added to the GL.
4.b.2.b - Else the prospective member received a glFailInfo, for
any reason, the prospective member MAY reattempt to add
themselves to the GL using the information provided in the themselves to the GL using the information provided in the
glFailInfo response. glFailInfo response.
Turner 39
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 MUST include:
the GL name in glName, their name in glMember.glMemberName, the GL name in glName, their name in glMember.glMemberName,
their address in glMember.glMemberAddress, and their their address in glMember.glMemberAddress, and their
encryption certificate in glMember.certificates.membersPKC. encryption certificate in glMember.certificates.pKC. The
The prospective GL member MAY also include any attribute prospective GL member MAY also include any attribute
certificates associated with their encryption certificate in certificates associated with their encryption certificate in
glMember.certificates.membersAC, and the certification path glMember.certificates.aC, and the certification path
associated with their encryption and attribute certificates in associated with their encryption and attribute certificates in
glMember.certificates.certificationPath. glMember.certificates.certificationPath.
1.a - The prospective GL member MAY optionally apply 1.a - The prospective GL member MAY optionally apply
confidentiality to the request by encapsulating the confidentiality to the request by encapsulating the
SignedData.PKIData in an EnvelopedData (see paragraph SignedData.PKIData in an EnvelopedData (see 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 also optionally apply another
SignedData over the EnvelopedData (see paragraph 3.2.1.2). SignedData over the EnvelopedData (see section 3.2.1.2).
2 - Upon receipt of the request, the GLA verifies the request as 2 - Upon receipt of the request, the GLA verifies the request as
per 2 in paragraph 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Ęs signature on the inner most
SignedData.PKIData and the GLA's signature on the outer layer. SignedData.PKIData and the GLAĘs signature on the outer layer.
If an EnvelopedData encapsulates the inner most layer (see If an EnvelopedData encapsulates the inner most layer (see
paragraph 3.2.1.2 or 3.2.2), the GLO MUST decrypt the outer 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 layer prior to verifying the signature on the inner most
SignedData. SignedData.
3.a - If the signature(s) does(do) not verify, the GLO MUST return Note: For cases where the GL is closed and either a) a
a cMCStatusInfo response indicating cMCStatus.failed and prospective member sends directly to the GLO or b) the GLA has
mistakenly forwarded the request to the GLO, the GLO should
first determine whether to honor the request.
3.a - If the signatures do not verify, the GLO MUST return a
cMCStatusInfo response indicating cMCStatus.failed and
otherInfo.failInfo.badMessageCheck. otherInfo.failInfo.badMessageCheck.
3.b - If the signature(s) does(do) verify, the GLO MUST check to 3.b - Else the signatures do verify, the GLO MUST check to make
make sure one of the names in the certificate used to sign sure one of the names in the certificate used to sign the
the request matches the name in glMember.glMemberName. request matches the name in glMember.glMemberName.
3.b.1 - If the names do not match, the GLO MAY send a 3.b.1 - If the names do not match, the GLO MAY send a
SignedData.PKIResponse.controlSequence message back to the SignedData.PKIResponse.controlSequence message back to the
Turner 37 Turner 40
prospective member with cMCStatusInfo.cMCStatus.failed prospective member with cMCStatusInfo.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.b.2 - If the names do match, the GLO determines whether the 3.b.2 - Else the names do match, the GLO determines whether the
prospective member is allowed to be added. The mechanism prospective member is allowed to be added. The mechanism
is beyond the scope of this document; however, the GLO is beyond the scope of this document; however, the GLO
should check to see that the glMember.glMemberName is not should check to see that the glMember.glMemberName is not
already on the GL. already on the GL.
3.b.2.a - If the GLO determines the prospective member is not 3.b.2.a - If the GLO determines the prospective member is not
allowed to join the GL, the GLO MAY return a allowed to join the GL, the GLO MAY return a
SignedData.PKIResponse.controlSequence message back to SignedData.PKIResponse.controlSequence message back to
the prospective member with the prospective member with
cMCStatusInfo.cMCtatus.failed indicating why the cMCStatusInfo.cMCtatus.failed indicating why the
prospective member was denied in cMCStatus.statusString. prospective member was denied in cMCStatus.statusString.
3.b.2.b - If GLO determines the prospective member is allowed to 3.b.2.b - Else GLO determines the prospective member is allowed to
join the GL, the GLO MUST verify the member's encryption join the GL, the GLO MUST verify the member's encryption
certificate. certificate.
3.b.2.b.1 - If the member's certificate does not verify, the GLO 3.b.2.b.1 - If the member's certificate does not verify, the GLO
MAY return a SignedData.PKIResponse.controlSequence MAY return a SignedData.PKIResponse.controlSequence
back to the prospective member with back to the prospective member with
cMCStatusInfo.cMCtatus.failed indicating that the cMCStatusInfo.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
cMCStatusInfo response, the GLO MUST send a cMCStatusInfo response, the GLO MUST send 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 paragraph 4.10). encryption certificate (see section 4.10).
3.b.2.b.2 - If the member's certificate does verify, the GLO 3.b.2.b.2 - Else the member's certificate does verify, the GLO
resubmits the glAddMember request (see paragraph resubmits the glAddMember request (see section 3.2.5)
3.2.5) to the GLA (1 in Figure 5). to the GLA (1 in Figure 5).
3.b.2.b.2.a - The GLO MUST apply confidentiality to the new 3.b.2.b.2.a - The GLO MUST apply confidentiality to the new
GLAddMember request by encapsulating the GLAddMember request by encapsulating the
SignedData.PKIData in an EnvelopedData if the SignedData.PKIData in an EnvelopedData if the
initial request was encapsulated in an EnvelopedData initial request was encapsulated in an EnvelopedData
(see paragraph 3.2.1.2). (see section 3.2.1.2).
3.b.2.b.2.b - The GLO MAY also optionally apply another SignedData 3.b.2.b.2.b - The GLO MAY also optionally apply another SignedData
over the EnvelopedData (see paragraph 3.2.1.2). over the EnvelopedData (see section 3.2.1.2).
4 - Processing continues as in 2 of paragraph 4.3.1. 4 - Processing continues as in 2 of section 4.3.1.
Turner 38 Turner 41
4.4 Delete Members From GL 4.4 Delete Members From GL
To delete members from GLs, either the GLO or prospective non- To delete members from GLs, either the GLO or prospective non-
members use the glDeleteMember request. The GLA processes GLO and members use the glDeleteMember request. The GLA processes GLO and
prospective non-GL member requests differently. The GLO can submit prospective non-GL member requests differently. The GLO can submit
the request at any time to delete members from the GL, and the GLA, the request at any time to delete members from the GL, and the GLA,
once it has verified the request came from a registered GLO, should once it has verified the request came from a registered GLO, should
delete the member. If a prospective member sends the request, the delete the member. If a prospective 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 paragraph 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 prospective members to the GLO
for review. Where there are multiple GLOs for a GL, which GLO the for review. Where there are multiple GLOs for a GL, which GLO the
request is forwarded to is beyond the scope of this document. The request is forwarded to is beyond the scope of this document. The
GLO reviews the request and either rejects it or submits a reformed GLO reviews the request and either rejects it or submits a reformed
request to the GLA. In the closed case, the GLA will not accept request to the GLA. In the closed case, the GLA will not accept
requests from prospective members. The following paragraphs describe requests from prospective members. The following sections describe
the processing for the GLO(s), GLA, and prospective non-GL members the processing for the GLO(s), GLA, and GL members depending on
depending on where the request originated, either from a GLO or from where the request originated, either from a GLO or from prospective
prospective non-members. Figure 6 depicts the protocol interactions non-members. Figure 6 depicts the protocol interactions for the
for the three options. Note that the error messages are not three options. Note that the error messages are not depicted.
depicted.
+-----+ 2,B{A} 3 +----------+ +-----+ 2,B{A} 3 +----------+
| GLO | <--------+ +-------> | Member 1 | | GLO | <--------+ +-------> | Member 1 |
+-----+ | | +----------+ +-----+ | | +----------+
1 | | 1 | |
+-----+ <--------+ | 3 +----------+ +-----+ <--------+ | 3 +----------+
| GLA | A +-------> | ... | | GLA | A +-------> | ... |
+-----+ <-------------+ +----------+ +-----+ <-------------+ +----------+
| |
| 3 +----------+ | 3 +----------+
skipping to change at line 1978 skipping to change at line 2092
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 MUST take steps to ensure the member being deleted is not on 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 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 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 member has been deleted the group rekey mechanism MUST be used to
distribute the new key (see paragraphs 4.5 and 5). distribute the new key (see sections 4.5 and 5).
Turner 39 Turner 42
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 MAY 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 paragraph 4.5). glDeletemember request (see section 4.5).
1.a - The GLO MAY optionally apply confidentiality to the request 1.a - The GLO MAY optionally apply confidentiality to the request
by encapsulating the SignedData.PKIData in an EnvelopedData by encapsulating the SignedData.PKIData in an EnvelopedData
(see paragraph 3.2.1.2). (see section 3.2.1.2).
1.b - The GLO MAY also optionally apply another SignedData over 1.b - The GLO MAY also optionally apply another SignedData over
the EnvelopedData (see paragraph 3.2.1.2). the EnvelopedData (see 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 paragraph 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 MUST verify the outer signature
and/or decrypt the outer layer prior to verifying the and/or decrypt the outer layer prior to verifying the
signature on the inner most SignedData. signature on the inner most SignedData.
2.a - If the signature(s) does(do) not verify, the GLA MUST return 2.a - If the signatures do not verify, the GLA MUST return a
a cMCStatusInfo response indicating cMCStatus.failed and cMCStatusInfo response indicating cMCStatus.failed and
otherInfo.failInfo.badMessageCheck. otherInfo.failInfo.badMessageCheck.
2.b - If the signature(s) does(do) verify, the GLA MUST make sure 2.b - Else the signatures do verify, the GLA MUST make sure the GL
the GL is supported by the GLA by checking that the glName is supported by the GLA by checking that the glName matches
matches a glName stored on the GLA. a 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 MUST
return a response indicating return a response indicating
glFailInfo.errorCode.invalidGLName. glFailInfo.errorCode.invalidGLName.
2.b.2 - If the glName is supported by the GLA, the GLA MUST check 2.b.2 - Else the glName is supported by the GLA, the GLA MUST
to see if the glMemberName is present on the GL. check to see if the glMemberName is present 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 MUST return a response indicating
glFailInfo.errorCode.notAMember. glFailInfo.errorCode.notAMember.
2.b.2.b - If the glMemberName is already on the GL, the GLA MUST 2.b.2.b - Else the glMemberName is already on the GL, the GLA MUST
check how the GL is administered. check how the GL is administered.
Turner 40 Turner 43
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 MUST check 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 MUST return a
response indicating response indicating glFailInfo.errorCode.closed.
glFailInfo.errorCode.noGLONameMatch.
2.b.2.b.1.b - If the names do match, the GLA MUST return a 2.b.2.b.1.b - Else the names do match, the GLA MUST return a
glSuccessInfo indicating the glName, the glSuccessInfo indicating the glName, the
corresponding glIdentifier, an corresponding glIdentifier, an
action.actionCode.deletedMember, and action.actionCode.deletedMember, and
action.glMemberName (2 in Figure 5). The GLA also action.glMemberName (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 delete the member with scope of this document, to delete the member with
the GL stored on the GLA. The GLA MUST also rekey the GL stored on the GLA. Note that he GL MUST also
group as described in paragraph 5. 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 MUST apply confidentiality to the response
by encapsulating the SignedData.PKIData in an by encapsulating the SignedData.PKIData in an
EnvelopedData if the request was encapsulated in EnvelopedData if the request was encapsulated in
an EnvelopedData (see paragraph 3.2.1.2). an EnvelopedData (see 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 MAY also optionally apply another
SignedData over the EnvelopedData (see paragraph SignedData over the EnvelopedData (see section
3.2.1.2). 3.2.1.2).
2.b.2.b.2 - If the GL is managed, the GLA MUST check that either a 2.b.2.b.2 - Else the GL is managed, the GLA MUST check that either
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 MUST match a registered GLO.
For the prospective member, the name in For the prospective member, the name in
glMember.glMemberName MUST match one of the names in glMember.glMemberName MUST match one of the names in
the certificate used to sign the request. the certificate used to sign the request.
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 MUST return a
response indicating glFailInfo.errorCode.noSpam. response indicating glFailInfo.errorCode.noSpam.
2.b.2.b.2.b - If the signer is a registered GLO, the GLA MUST 2.b.2.b.2.b - Else the signer is a registered GLO, the GLA MUST
return a glSuccessInfo to the GLO indicating the return a glSuccessInfo to the GLO indicating the
glName, the corresponding glIdentifier, an glName, the corresponding glIdentifier, an
action.actionCode.deletedMember, and action.actionCode.deletedMember, and
action.glMemberName (2 in Figure 6). The GLA also action.glMemberName (2 in Figure 6). The GLA also
takes administrative actions, which are beyond the takes administrative actions, which are beyond the
scope of this document, to delete the member with scope of this document, to delete the member with
the GL stored on the GLA. The GLA will also rekey the GL stored on the GLA. Note that the GL will also
group as described in paragraph 5. be rekeyed as 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 MUST apply confidentiality to the response
by encapsulating the SignedData.PKIData in an by encapsulating the SignedData.PKIData in an
Turner 41 Turner 44
EnvelopedData if the request was encapsulated in EnvelopedData if the request was encapsulated in
an EnvelopedData (see paragraph 3.2.1.2). an EnvelopedData (see 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 MAY also optionally apply another
SignedData over the EnvelopedData (see paragraph SignedData over the EnvelopedData (see section
3.2.1.2). 3.2.1.2).
2.b.2.b.2.c - If the signer is the prospective member, the GLA 2.b.2.b.2.c - Else the signer is the prospective member, the GLA
forwards the glDeleteMember request (see paragraph 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 paragraph request by GLOs is addressed in 3 of section 4.4.2.
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 MUST apply confidentiality to the
forwarded request by encapsulating the forwarded request by encapsulating the
SignedData.PKIData in an EnvelopedData if the SignedData.PKIData in an EnvelopedData if the
request was encapsulated in an EnvelopedData (see request was encapsulated in an EnvelopedData (see
paragraph 3.2.1.2). 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 MAY also optionally apply another
SignedData over the EnvelopedData (see paragraph SignedData over the EnvelopedData (see section
3.2.1.2). 3.2.1.2).
2.b.2.b.3 - If the GL is unmanaged, the GLA MUST check that either 2.b.2.b.3 - Else the GL is unmanaged, the GLA MUST check that
a registered GLO or the prospective member signed the either a registered GLO or the prospective member
request. For GLOs, one of the names in the certificate signed the request. For GLOs, one of the names in the
used to sign the request MUST match the name of a certificate used to sign the request MUST match the
registered GLO. For the prospective member, the name name of a registered GLO. For the prospective member,
in glMember.glMemberName MUST match one of the names the name in glMember.glMemberName MUST match one of
in the certificate used to sign the request. 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 MUST return a response indicating
glFailInfo.errorCode.noSpam. glFailInfo.errorCode.noSpam.
2.b.2.b.3.b - If the signer is either a registered GLO or the 2.b.2.b.3.b - Else the signer is either a registered GLO or the
member, the GLA MUST return a glSuccessInfo member, the GLA MUST return a glSuccessInfo
indicating the glName, the corresponding indicating the glName, the corresponding
glIdentifier, an action.actionCode.deletedMember, glIdentifier, an action.actionCode.deletedMember,
and action.glMemberName to the GLO (2 in Figure 6) and action.glMemberName to the GLO (2 in Figure 6)
if the GLO signed the request and to the GL member if the GLO signed the request and to the GL member
(3 in Figure 6) if the GL member signed the request. (3 in Figure 6) if the GL member signed the request.
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. member with the GL stored on 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 MUST apply confidentiality to the response
by encapsulating the SignedData.PKIData in an by encapsulating the SignedData.PKIData in an
Turner 42
EnvelopedData if the request was encapsulated in EnvelopedData if the request was encapsulated in
an EnvelopedData (see paragraph 3.2.1.2). an EnvelopedData (see section 3.2.1.2).
Turner 45
2.b.2.b.3.b.2 - The GLA MAY also optionally apply another 2.b.2.b.3.b.2 - The GLA MAY also optionally apply another
SignedData over the EnvelopedData (see paragraph SignedData over the EnvelopedData (see section
3.2.1.2). 3.2.1.2).
3 - Upon receipt of the glSuccessInfo or glFailInfo response, the 3 - Upon receipt of the glSuccessInfo or glFailInfo response, the
GLO verifies the GLA's signatures. If an additional SignedData GLO verifies the GLA's signatures. If an additional SignedData
and/or EnvelopedData encapsulates the response (see paragraph and/or EnvelopedData encapsulates the response (see 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 MUST verify the outer signature
and/or decrypt the outer layer prior to verifying the and/or decrypt the outer layer prior to verifying the
signature on the inner most SignedData. signature on the inner most SignedData.
3.a - If the signature(s) does(do) not verify, the GLO MUST return 3.a - If the signatures do not verify, the GLO MUST return a
a cMCStatusInfo response indicating cMCStatus.failed and cMCStatusInfo response indicating cMCStatus.failed and
otherInfo.failInfo.badMessageCheck. otherInfo.failInfo.badMessageCheck.
3.b - If the signature(s) does(do) verify and the response is 3.b - Else the signatures do verify, the GLO MUST check that one
of the names in the certificate used to sign the response
matches the name of the GL.
3.b.1 ū If the GLĘs name does not match the name present in the
certificate used to sign the message, the GLO should not
believe the response.
3.b.2 ū Else the GLĘs name does match the name present in the
certificate and:
3.b.2.a - If the signatures do verify and the response is
glSuccessInfo, the GLO has deleted the member from the GL. glSuccessInfo, the GLO has deleted the member from the GL.
If member was deleted from a managed list and the original If member was deleted from a managed list and the original
request was signed by the member, the GLO MUST send a request was signed by the member, the GLO MUST send a
cMCStatusInfo.cMCStatus.success to the GL member. cMCStatusInfo.cMCStatus.success to the GL member.
3.c - If the GLO received a glFailInfo, for any reason, the GLO 3.b.2.b - Else the GLO received a glFailInfo, for any reason, the
may reattempt to delete the member from the GL using the GLO may reattempt to delete the member from the GL using
information provided in the glFailInfo response. the information provided in the glFailInfo response.
4 - Upon receipt of the glSuccessInfo, glFailInfo, or cMCStatus 4 - Upon receipt of the glSuccessInfo, glFailInfo, or cMCStatus
response, the prospective member verifies the GLA's response, the prospective member verifies the GLA's
signature(s) or GLO's signature(s). If an additional signature(s) or GLOĘs signature(s). If an additional
SignedData and/or EnvelopedData encapsulates the response (see SignedData and/or EnvelopedData encapsulates the response (see
paragraph 3.2.1.2 or 3.2.2), the GLO MUST verify the outer section 3.2.1.2 or 3.2.2), the GLO MUST verify the outer
signature and/or decrypt the outer layer prior to verifying signature and/or decrypt the outer layer prior to verifying
the signature on the inner most SignedData. the signature on the inner most SignedData.
4.a - If the signature(s) does(do) not verify, the prospective 4.a - If the signatures do not verify, the prospective member MUST
member MUST return a cMCStatusInfo response indicating return a cMCStatusInfo response indicating cMCStatus.failed
cMCStatus.failed and otherInfo.failInfo.badMessageCheck. and otherInfo.failInfo.badMessageCheck.
4.b - If the signature(s) does(do) verify, the prospective member 4.b - Else the signatures do verify, the GL member MUST check that
has been deleted from the GL. one of the names in the certificate used to sign the
response matches the name of the GL.
4.c - If the prospective member received a glFailInfo, for any Turner 46
reason, the prospective member MAY reattempt to delete 4.b.1 ū If the GLĘs name does not match the name present in the
themselves from the GL using the information provided in the certificate used to sign the message, the GL member should
glFailInfo response. not believe the response.
Turner 43 4.b.2 ū Else the GLĘs name does match the name present in the
certificate and:
4.b.2.a - If the signature(s) does(do) verify, the prospective
member has been deleted from the GL.
4.b.2.b - Else the prospective member received a glFailInfo, for
any reason, the prospective member MAY reattempt to delete
themselves from the GL using the information provided in
the glFailInfo response.
4.4.2 Member Initiated Deletions 4.4.2 Member Initiated Deletions
The process for prospective non-member initiated glDeleteMember The process for prospective non-member initiated glDeleteMember
requests is as follows: requests is as follows:
1 - The prospective non-GL member sends a 1 - The prospective non-GL member sends a
SignedData.PKIData.controlSequence.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 prospective non-GL member MUST
include: the GL name in glName and their name in include: the GL name in glName and their name in
glMemberToDelete. glMemberToDelete.
1.a - The prospective non-GL member MAY optionally apply 1.a - The prospective non-GL member MAY optionally apply
confidentiality to the request by encapsulating the confidentiality to the request by encapsulating the
SignedData.PKIData in an EnvelopedData (see paragraph SignedData.PKIData in an EnvelopedData (see section
3.2.1.2). 3.2.1.2).
1.b - The prospective non-GL member MAY also optionally apply 1.b - The prospective non-GL member MAY also optionally apply
another SignedData over the EnvelopedData (see paragraph another SignedData over the EnvelopedData (see 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 paragraph 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 prospective non-memberĘs signature on the inner most
SignedData.PKIData and the GLA's signature on the outer layer. SignedData.PKIData and the GLAĘs signature on the outer layer.
If an EnvelopedData encapsulates the inner most layer (see If an EnvelopedData encapsulates the inner most layer (see
paragraph 3.2.1.2 or 3.2.2), the GLO MUST decrypt the outer 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 layer prior to verifying the signature on the inner most
SignedData. SignedData.
3.a - If the signature(s) does(do) not verify, the GLO MUST return Note: For cases where the GL is closed and either a) a
a cMCStatusInfo response indicating cMCStatus.failed and prospective member sends directly to the GLO or b) the GLA has
mistakenly forwarded the request to the GLO, the GLO should
first determine whether to honor the request.
Turner 47
3.a - If the signatures do not verify, the GLO MUST return a
cMCStatusInfo response indicating cMCStatus.failed and
otherInfo.failInfo.badMessageCheck. otherInfo.failInfo.badMessageCheck.
3.b - If the signature(s) does(do) verify, the GLO MUST check to 3.b - Else the signatures do verify, the GLO MUST check to make
make sure one of the names in the certificates used to sign sure one of the names in the certificates used to sign the
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 do not match, the GLO MAY send a
SignedData.PKIResponse.controlSequence message back to the SignedData.PKIResponse.controlSequence message back to the
prospective member with cMCStatusInfo.cMCtatus.failed prospective member with cMCStatusInfo.cMCtatus.failed
indicating why the prospective member was denied in indicating why the prospective member was denied in
cMCStatusInfo.statusString. This stops people from adding cMCStatusInfo.statusString. This stops people from adding
people to GLs without their permission. people to GLs without their permission.
3.b.2 - If the names do match, the GLO resubmits the 3.b.2 - Else the names do match, the GLO resubmits the
glDeleteMember request (see paragraph 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 MUST make sure the glMemberName is
already on the list and only on the list once. The GLO already on the GL. The GLO MUST also generate a glRekey
MUST also generate a glRekey request and include it with request and include it with the GLDeleteMember request
the GLDeleteMember request (see paragraph 4.5). (see section 4.5).
Turner 44
3.b.2.a - The GLO MUST apply confidentiality to the new 3.b.2.a - The GLO MUST apply confidentiality to the new
GLDeleteMember request by encapsulating the GLDeleteMember request by encapsulating the
SignedData.PKIData in an EnvelopedData if the initial SignedData.PKIData in an EnvelopedData if the initial
request was encapsulated in an EnvelopedData (see request was encapsulated in an EnvelopedData (see
paragraph 3.2.1.2). section 3.2.1.2).
3.b.2.b - The GLO MAY also optionally apply another SignedData 3.b.2.b - The GLO MAY also optionally apply another SignedData
over the EnvelopedData (see paragraph 3.2.1.2). over the EnvelopedData (see section 3.2.1.2).
4 - Further processing is as in 2 of paragraph 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: are as follows:
- When a member is removed from a closed or managed GL. In this - When a member is removed from a closed or managed GL. In this
case, the PKIData.controlSequence containing the glDeleteMember case, the PKIData.controlSequence containing the glDeleteMember
should contain a glRekey request. should contain a glRekey request.
- Depending on policy, when a member is removed from an unmanaged - Depending on policy, when a member is removed from an unmanaged
GL. If the policy is to rekey the GL, the GL. If the policy is to rekey the GL, the
PKIData.controlSequence containing the 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.
Turner 48
- When the current shared KEK is about to expire. - When the current shared KEK is about to expire.
- If the GLO controls the GL rekey, the GLA should not assume - If the GLO controls the GL rekey, the GLA should not assume
that a new shared KEK should be distributed, but instead wait that a new shared KEK should be distributed, but instead wait
for the glRekey message. for the glRekey message.
- If the GLA controls the GL rekey, the GLA should initiate a - If the GLA controls the GL rekey, the GLA should initiate a
glKey message as specified in paragraph 5. glKey message as specified in section 5.
If the generationCounter (see paragraph 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 should 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 control rekeys or
whether the GLA is going to control rekeys when the assigned the whether the GLA is going to control rekeys when the assigned the
shared KEK to GL (see paragraph 3.1.1). The GLO MAY initiate a GL shared KEK to GL (see section 3.1.1). The GLO MAY initiate a GL
rekey at any time. The GLA MAY be configured to automatically rekey rekey at any time. The GLA MAY be configured to automatically rekey
the GL prior to the expiration of the shared KEK (the length of time the GL prior to the expiration of the shared KEK (the length of time
before the expiration is an implementation decision). The GLA can
Turner 45 also automatically rekey GLĘs that have been compromised, but this
before the expiration is an implementation decision). Figure 7 is covered in section 5. Figure 7 depicts the protocol interactions
depicts the protocol interactions to request a GL rekey. Note that to request a GL rekey. Note that error messages are not depicted.
error messages are not depicted.
+-----+ 1 2,A +-----+ +-----+ 1 2,A +-----+
| GLA | <-------> | GLO | | GLA | <-------> | GLO |
+-----+ +-----+ +-----+ +-----+
Figure 7 - GL Rekey Request Figure 7 - GL Rekey Request
4.5.1 GLO Initiated Rekey Requests 4.5.1 GLO Initiated Rekey Requests
The process for GLO initiated glRekey requests is as follows: The process for GLO initiated glRekey requests is as follows:
1 - The GLO sends a SignedData.PKIData.controlSequence.glRekey 1 - The GLO sends a SignedData.PKIData.controlSequence.glRekey
request to the GLA (1 in Figure 7). The GLO MUST include the request to the GLA (1 in Figure 7). The GLO MUST include the
glName. 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
all outstanding shared KEKs the all outstanding shared KEKs it includes the glRekeyAllGLKeys
glNewKeyAttributes.generationCounter MUST be set to zero (0) set to TRUE.
1.a - The GLO MAY optionally apply confidentiality to the request 1.a - The GLO MAY optionally apply confidentiality to the request
by encapsulating the SignedData.PKIData in an EnvelopedData by encapsulating the SignedData.PKIData in an EnvelopedData
(see paragraph 3.2.1.2). (see section 3.2.1.2).
1.b - The GLO MAY also optionally apply another SignedData over 1.b - The GLO MAY also optionally apply another SignedData over
the EnvelopedData (see paragraph 3.2.1.2). the EnvelopedData (see section 3.2.1.2).
Turner 49
2 - Upon receipt of the request, the GLA verifies the signature on 2 - Upon receipt of the request, the GLA verifies the signature on
the inner most SignedData.PKIData. If an additional SignedData the inner most SignedData.PKIData. If an additional SignedData
and/or EnvelopedData encapsulates the request (see paragraph and/or EnvelopedData encapsulates the request (see 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 MUST verify the outer signature
and/or decrypt the outer layer prior to verifying the and/or decrypt the outer layer prior to verifying the
signature on the inner most SignedData. signature on the inner most SignedData.
2.a - If the signature(s) does(do) not verify, the GLA MUST return 2.a - If the signatures do not verify, the GLA MUST return a
a cMCStatusInfo response indicating cMCStatus.failed and cMCStatusInfo response indicating cMCStatus.failed and
otherInfo.failInfo.badMessageCheck. otherInfo.failInfo.badMessageCheck.
2.b - If the signature(s) does(do) verify, the GLA MUST make sure 2.b - Else the signatures do verify, the GLA MUST make sure the GL
the GL is supported by the GLA by checking that the glName is supported by the GLA by checking that the glName matches
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 MUST return a response indicating
glFailInfo.errorCode.invalidGLName. glFailInfo.errorCode.invalidGLName.
2.b.2 - If the glName present does match a GL stored on the GLA, 2.b.2 - Else the glName present does match a GL stored on the GLA,
the GLA MUST check that a registered GLO signed the the GLA MUST check that a registered GLO signed the
Turner 46
request by checking that one of the names in the request by checking that one of the names in the
certificate used to sign the request is a registered GLO. certificate used to 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 MUST return a
response indicating glFailInfo.errorCode.noGLONameMatch. response indicating glFailInfo.errorCode.noGLONameMatch.
2.b.2.b - If the names do match, the GLA MUST check the 2.b.2.b - Else the names do match, the GLA MUST check 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 MUST return a response indicating
glFailInfo.errorCode.unsupportedAlgorithm glFailInfo.errorCode.unsupportedAlgorithm
2.b.2.b.2 - 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 MUST return a response indicating
glFailInfo.errorCode.unsupportedDuration. glFailInfo.errorCode.unsupportedDuration.
2.b.2.b.3 - If the GL is not supportable for other reasons, which 2.b.2.b.3 - Else the GL is not supportable for other reasons,
the GLA does not wish to disclose, the GLA MUST return which the GLA does not wish to disclose, the GLA MUST
a response indicating return a response indicating
glFailInfo.errorCode.unspecified. glFailInfo.errorCode.unspecified.
2.b.2.b.4 - If the new requestedAlgorithm and duration are 2.b.2.b.4 - Else the new requestedAlgorithm and duration are
supportable or the glNewKeyAttributes was omitted, the supportable or the glNewKeyAttributes was omitted, the
GLA MUST return a glSuccessInfo to the GLO indicating GLA MUST return a glSuccessInfo to the GLO indicating
the glName, the new glIdentifier, and an the glName, the new glIdentifier, and an
action.actionCode.rekeyedGL (2 in Figure 7). The GLA action.actionCode.rekeyedGL (2 in Figure 7). The GLA
also uses the glKey message to distribute the rekey also uses the glKey message to distribute the rekey
shared KEK (see paragraph 5). shared KEK (see section 5).
Turner 50
2.b.2.b.4.a - The GLA MUST apply confidentiality to response by 2.b.2.b.4.a - The GLA MUST apply confidentiality to response by
encapsulating the SignedData.PKIData in an encapsulating the SignedData.PKIData in an
EnvelopedData if the request was encapsulated in an EnvelopedData if the request was encapsulated in an
EnvelopedData (see paragraph 3.2.1.2). EnvelopedData (see 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 MAY also optionally apply another SignedData
over the EnvelopedData (see paragraph 3.2.1.2). over the EnvelopedData (see section 3.2.1.2).
3 - Upon receipt of the glSuccessInfo or glFailInfo response, the 3 - Upon receipt of the glSuccessInfo or glFailInfo response, the
GLO verifies the GLA's signature(s). If an additional GLO verifies the GLA's signature(s). If an additional
SignedData and/or EnvelopedData encapsulates the forwarded SignedData and/or EnvelopedData encapsulates the forwarded
response (see paragraph 3.2.1.2 or 3.2.2), the GLO MUST verify response (see section 3.2.1.2 or 3.2.2), the GLO MUST verify
the outer signature and/or decrypt the forwarded response the outer signature and/or decrypt the forwarded response
prior to verifying the signature on the inner most SignedData. prior to verifying the signature on the inner most SignedData.
3.a - If the signature(s) does(do) not verify, the GLO MUST return 3.a - If the signatures do not verify, the GLO MUST return a
a cMCStatusInfo response indicating cMCStatus.failed and cMCStatusInfo response indicating cMCStatus.failed and
otherInfo.failInfo.badMessageCheck. otherInfo.failInfo.badMessageCheck.
3.b - If the signatures verifies and the response is 3.b - Else the signatures do verify, the GLO MUST check that one
of the names in the certificate used to sign the response
matches the name of the GL.
3.b.1 ū If the GLĘs name does not match the name present in the
certificate used to sign the message, the GLO should not
believe the response.
3.b.2 ū Else the GLĘs name does match the name present in the
certificate and:
3.b.2.a - If the signatures verifies and the response is
glSuccessInfo, the GLO has successfully rekeyed the GL. glSuccessInfo, the GLO has successfully rekeyed the GL.
Turner 47 3.b.2.b - Else the GLO received a glFailInfo, for any reason, the
3.c - If the GLO received a glFailInfo, for any reason, the GLO GLO may reattempt to rekey the GL using the information
may reattempt to rekey the GL using the information provided provided in the glFailInfo response.
in the glFailInfo response.
4.5.2 GLA Initiated Rekey Requests 4.5.2 GLA Initiated Rekey Requests
If the GLA is in charge of rekeying the GL the GLA will If the GLA is in charge of rekeying the GL the GLA will
automatically issue a glKey message (see paragraph 5). In addition automatically issue a glKey message (see section 5). In addition the
the GLA will generate a glSuccessInfo to indicate to the GL that a GLA will generate a glSuccessInfo to indicate to the GL that a
successful rekey has occurred. The process for GLA initiated rekey successful rekey has occurred. The process for GLA initiated rekey
is as follows: is as follows:
1 - The GLA MUST generate for all GLOs a 1 - The GLA MUST generate for all GLOs a
SignedData.PKIData.controlSequence.glSuccessInfo indicating SignedData.PKIData.controlSequence.glSuccessInfo indicating
the glName, the new glIdentifier, and actionCode.rekeyedGL (A the glName, the new glIdentifier, and actionCode.rekeyedGL (A
in Figure 7). glMemberName and glOwnerName are omitted. in Figure 7). glMemberName and glOwnerName are omitted.
Turner 51
1.a - The GLA MAY optionally apply confidentiality to the request 1.a - The GLA MAY optionally apply confidentiality to the request
by encapsulating the SignedData.PKIData in an EnvelopedData by encapsulating the SignedData.PKIData in an EnvelopedData
(see paragraph 3.2.1.2). (see 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 (see paragraph 3.2.1.2). the EnvelopedData (see section 3.2.1.2).
2 - Upon receipt of the glSuccessInfo response, the GLO verifies 2 - Upon receipt of the glSuccessInfo response, the GLO verifies
the GLA's signature(s). If an additional SignedData and/or the GLA's signature(s). If an additional SignedData and/or
EnvelopedData encapsulates the forwarded response (see EnvelopedData encapsulates the forwarded response (see section
paragraph 3.2.1.2 or 3.2.2), the GLO MUST verify the outer 3.2.1.2 or 3.2.2), the GLO MUST verify the outer signature
signature and/or decrypt the outer layer prior to verifying and/or decrypt the outer layer prior to verifying the
the signature on the inner most SignedData. signature on the inner most SignedData.
2.a - If the signatures do not verify, the GLO MUST return a 2.a - If the signatures do not verify, the GLO MUST return a
cMCStatusInfo response indicating cMCStatus.failed and cMCStatusInfo response indicating cMCStatus.failed and
otherInfo.failInfo.badMessageCheck. otherInfo.failInfo.badMessageCheck.
2.b - If the signatures verifies and the response is 2.b - Else the signatures do verify, the GLO MUST check that one
glSuccessInfo, the GLO knows the GLA has successfully of the names in the certificate used to sign the response
rekeyed the GL. matches the name of the GL.
2.b.1 ū If the GLĘs name does not match the name present in the
certificate used to sign the message, the GLO should not
believe the response.
2.b.2 ū Else the GLĘs name does match the name present in the
certificate and and the response is glSuccessInfo, the GLO
knows the GLA has successfully rekeyed the GL.
4.6 Change GLO 4.6 Change GLO
Management of managed and closed GLs can become difficult for one Management of managed and closed GLs can become difficult for one
GLO if the GL membership grows large. To support distributing the GLO if the GL membership grows large. To support distributing the
workload, GLAs support having GLs be managed by multiple GLOs. The workload, GLAs support having GLs be managed by multiple GLOs. The
glAddOwner and glRemoveOwner messages are designed to support adding glAddOwner and glRemoveOwner messages are designed to support adding
and removing registered GLOs. Figure 8 depicts the protocol and removing registered GLOs. Figure 8 depicts the protocol
interactions to send glAddOwner and glRemoveOwner messages and the interactions to send glAddOwner and glRemoveOwner messages and the
resulting response messages. resulting response messages.
Turner 48
+-----+ 1 2 +-----+ +-----+ 1 2 +-----+
| GLA | <-------> | GLO | | GLA | <-------> | GLO |
+-----+ +-----+ +-----+ +-----+
Figure 8 - GLO Add & Delete Owners Figure 8 - GLO Add & Delete Owners
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
glOwnerName, and the GLO's address in glOwnerAddress. Turner 52
MUST include: the GL name in glName, the GLOĘs name in
glOwnerName, and the GLOĘs address in glOwnerAddress.
1.a - The GLO MAY optionally apply confidentiality to the request 1.a - The GLO MAY optionally apply confidentiality to the request
by encapsulating the SignedData.PKIData in an EnvelopedData by encapsulating the SignedData.PKIData in an EnvelopedData
(see paragraph 3.2.1.2). (see section 3.2.1.2).
1.b - The GLO MAY also optionally apply another SignedData over 1.b - The GLO MAY also optionally apply another SignedData over
the EnvelopedData (see paragraph 3.2.1.2). the EnvelopedData (see 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's signature(s). If an additional
SignedData and/or EnvelopedData encapsulates the request (see SignedData and/or EnvelopedData encapsulates the request (see
paragraph 3.2.1.2 or 3.2.2), the GLA MUST verify the outer section 3.2.1.2 or 3.2.2), the GLA MUST verify the outer
signature and/or decrypt the outer layer prior to verifying signature and/or decrypt the outer layer prior to verifying
the signature on the inner most SignedData. the signature on the inner most SignedData.
2.a - If the signature(s) does(do) not verify, the GLA MUST return 2.a - If the signatures do not verify, the GLA MUST return a
a cMCStatusInfo response indicating cMCStatus.failed and cMCStatusInfo response indicating cMCStatus.failed and
otherInfo.failInfo.badMessageCheck. otherInfo.failInfo.badMessageCheck.
2.b - If the signature(s) does(do) verify, the GLA MUST make sure 2.b - Else the signatures do verify, the GLA MUST make sure the GL
the GL is supported by checking that the glName matches a is supported by checking that the glName matches a glName
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 MUST
return a response indicating return a response indicating
glFailInfo.errorCode.invalidGLName. glFailInfo.errorCode.invalidGLName.
2.b.2 - If the glName is supported by the GLA, the GLA MUST ensure 2.b.2 - Else the glName is supported by the GLA, the GLA MUST
a registered GLO signed the glAddOwner or glRemoveOwner ensure a registered GLO signed the glAddOwner or
request by checking that one of the names present in the glRemoveOwner request by checking that one of the names
digital signature certificate used to sign the glAddOwner present in the digital signature certificate used to sign
or glDeleteOwner request matches the name of a registered the glAddOwner or glDeleteOwner request matches the name
GLO. of 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 MUST return a
response indicating glFailInfo.errorCode.noGLONameMatch. response indicating glFailInfo.errorCode.noGLONameMatch.
2.b.2.b - If the names do match, the GLA MUST return a 2.b.2.b - Else the names do match, the GLA MUST return a
glSuccessInfo indicating the glName, the corresponding glSuccessInfo indicating the glName, the corresponding
Turner 49
glIdentifier (for glAddOwner), an glIdentifier (for glAddOwner), an
action.actionCode.addedGLO or removedGLO, and the action.actionCode.addedGLO or removedGLO, and the
respective GLO name in glOwnerName (2 in Figure 4). The respective GLO name in glOwnerName (2 in Figure 4). The
GLA MUST also take administrative actions to associate GLA MUST also take administrative actions to associate
the new glOwnerName with the GL in the case of the new glOwnerName with the GL in the case of
glAddOwner or to disassociate the old glOwnerName with glAddOwner or to disassociate the old glOwnerName with
the GL in the cased of glRemoveOwner. the GL in the cased of glRemoveOwner.
2.b.2.b.1 - The GLA MUST apply confidentiality to the response by 2.b.2.b.1 - The GLA MUST apply confidentiality to the response by
encapsulating the SignedData.PKIResponse in an encapsulating the SignedData.PKIResponse in an
Turner 53
EnvelopedData if the request was encapsulated in an EnvelopedData if the request was encapsulated in an
EnvelopedData (see paragraph 3.2.1.2). EnvelopedData (see 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 MAY also optionally apply another SignedData
over the EnvelopedData (see paragraph 3.2.1.2). over the EnvelopedData (see section 3.2.1.2).
3 - Upon receipt of the glSuccessInfo or glFailInfo response, the 3 - Upon receipt of the glSuccessInfo or glFailInfo response, the
GLO verifies the GLA's signature(s). If an additional GLO verifies the GLA's signature(s). If an additional
SignedData and/or EnvelopedData encapsulates the response (see SignedData and/or EnvelopedData encapsulates the response (see
paragraph 3.2.1.2 or 3.2.2), the GLO MUST verify the outer section 3.2.1.2 or 3.2.2), the GLO MUST verify the outer
signature and/or decrypt the outer layer prior to verifying 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 signature(s) does(do) not verify, the GLO MUST return 3.a - If the signatures do not verify, the GLO MUST return a
a cMCStatusInfo response indicating cMCStatus.failed and cMCStatusInfo response indicating cMCStatus.failed and
otherInfo.failInfo.badMessageCheck. otherInfo.failInfo.badMessageCheck.
3.b - If the signatures do verify and the response was 3.b - Else the signatures do verify, the GLO MUST check that one
glSuccessInfo, the GLO has successfully added or removed the of the names in the certificate used to sign the response
GLO. matches the name of the GL.
3.c - If the signatures do verify and the response was glFailInfo, 3.b.1 ū If the GLĘs name does not match the name present in the
the GLO MAY reattempt to add or delete the GLO using the certificate used to sign the message, the GLO should not
information provided in the glFailInfo response. believe the response.
3.b.2 ū Else the GLĘs name does match the name present in the
certificate and:
3.b.2.a - If the signatures do verify and the response was
glSuccessInfo, the GLO has successfully added or removed
the GLO.
3.b.2.b - Else the signatures do verify and the response was
glFailInfo, the GLO MAY reattempt to add or delete the GLO
using the information provided in the glFailInfo response.
4.7 Indicate KEK Compromise 4.7 Indicate KEK Compromise
The will be times when the shared KEK is compromised. GL members and The will be times when the shared KEK is compromised. GL members and
GLOs use glkCompromise to tell the GLA that the shared KEK has been GLOs use glkCompromise to tell the GLA that the shared KEK has been
compromised. Figure 9 depicts the protocol interactions for GL Key compromised. Figure 9 depicts the protocol interactions for GL Key
Compromise. Compromise.
Turner 50 Turner 54
+-----+ 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 MUST include the GLĘs
name in GeneralName. name in GeneralName.
1.a - The GL member MAY optionally apply confidentiality to the 1.a - The GL member MAY optionally apply confidentiality to the
request by encapsulating the SignedData.PKIData in an request by encapsulating the SignedData.PKIData in an
EnvelopedData (see paragraph 3.2.1.2). The glkCompromise EnvelopedData (see section 3.2.1.2). The glkCompromise MUST
MUST NOT be included in an EnvelopedData generated with the NOT 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 MAY also optionally apply another SignedData
over the EnvelopedData (see paragraph 3.2.1.2). over the EnvelopedData (see section 3.2.1.2).
2 - Upon receipt of the glkCompromise requst, the GLA verifies the 2 - Upon receipt of the glkCompromise request, the GLA verifies
GL member's signature(s). If an additional SignedData and/or the GL member's signature(s). If an additional SignedData
EnvelopedData encapsulates the request (see paragraph 3.2.1.2 and/or EnvelopedData encapsulates the request (see section
or 3.2.2), the GLA MUST verify the outer signature and/or 3.2.1.2 or 3.2.2), the GLA MUST verify the outer signature
decrypt the outer layer prior to verifying the signature on and/or decrypt the outer layer prior to verifying the
the inner most SignedData. signature on the inner most SignedData.
2.a - If the signature(s) does(do) not verify, the GLA MUST return 2.a - If the signatures do not verify, the GLA MUST return a
a cMCStatusInfo response indicating cMCStatus.failed and cMCStatusInfo response indicating cMCStatus.failed and
otherInfo.failInfo.badMessageCheck. otherInfo.failInfo.badMessageCheck.
2.b - If the signature(s) does(do) verify, the GLA MUST make sure 2.b - Else the signatures do verify, the GLA MUST make sure the GL
the GL is supported by checking that the indicated GL name is supported by checking that the indicated GL name matches
matches a glName stored on the GLA. a 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 MUST
return a response indicating return a response indicating
glFailInfo.errorCode.invalidGLName. glFailInfo.errorCode.invalidGLName.
2.b.2 - If the glName is supported by the GLA, the GLA MUST check 2.b.2 - Else the glName is supported by the GLA, the GLA MUST
who signed the request. For GLOs, one of the names in the check who signed the request. For GLOs, one of the names
Turner 51 Turner 55
certificate used to sign the request MUST match a in the certificate used to sign the request MUST match a
registered GLO. For the prospective member, the name in registered GLO. For the prospective member, the name in
glMember.glMemberName MUST match one of the names in the glMember.glMemberName MUST match one of the names in the
certificate used to sign the request. 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 MUST generate a
glKey message as described in paragraph 5 to rekey the glKey message as described in section 5 to rekey the GL
GL (4 in Figure 9). (4 in Figure 9).
2.b.2.b - If anyone else signed the request, the GLA MUST forward 2.b.2.b - Else anyone else signed the request, the GLA MUST
the glkCompromise message (see paragraph 3.2.3) to the forward the glkCompromise message (see section 3.2.3) to
GLO (2{1} in Figure 9). If there is more than one GLO, the GLO (2{1} in Figure 9). If there is more than one
to which GLO the request is forwarded is beyond the GLO, to which GLO the request is forwarded is beyond the
scope of this document. Further processing by the GLO is scope of this document. Further processing by the GLO is
discussed in paragraph 4.7.2. 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 MUST include the name of
the GL in GeneralName. the GL in GeneralName.
1.a.1 - The GLO MAY optionally apply confidentiality to the 1.a.1 - The GLO MAY optionally apply confidentiality to the
request by encapsulating the SignedData.PKIData in an request by encapsulating the SignedData.PKIData in an
EnvelopedData (see paragraph 3.2.1.2). The glkCompromise EnvelopedData (see section 3.2.1.2). The glkCompromise
MUST NOT be included in an EnvelopedData generated with MUST NOT be included in an EnvelopedData generated with
the compromised shared KEK. the compromised shared KEK.
1.a.2 - The GLO MAY also optionally apply another SignedData over 1.a.2 - The GLO MAY also optionally apply another SignedData over
the EnvelopedData (see paragraph 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 - Verifies the GLAĘs and GL memberĘs signatures on the
forwarded glkCompromise message. If an additional SignedData forwarded glkCompromise message. If an additional SignedData
and/or EnvelopedData encapsulates the request (see paragraph 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 MUST verify the outer signature
and/or decrypt the outer layer prior to verifying the and/or decrypt the outer layer prior to verifying the
signature on the inner most SignedData. signature on the inner most SignedData.
1.b.1 - If the signatures do not verify, the GLO MUST return a 1.b.1 - If the signatures do not verify, the GLO MUST return a
cMCStatusInfo response indicating cMCStatus.failed and cMCStatusInfo response indicating cMCStatus.failed and
otherInfo.failInfo.badMessageCheck. otherInfo.failInfo.badMessageCheck.
1.b.2 - If the signatures do verify, the GLO MUST determine 1.b.1.a - If the signatures do verify, the GLO MUST check the
whether to forward the glkCompromise message back to the names in the certificate match the name of the signer
GLA (3{1} in Figure 9). Further processing by the GLA is (i.e., the name in the certificate used to sign the GL
in 2 of paragraph 4.7.1. The GLO MAY also return a the memberĘs request is the GL member).
Turner 52 Turner 56
1.b.1.a.1 ū If either name does not match, the GLO should not
trust the signer and it should not forward the message
to the GLA.
1.b.1.a.2 ū Else the names do math, the signatures do verify, the
GLO MUST determine whether to forward the
glkCompromise message back to the GLA (3{1} in Figure
9). Further processing by the GLA is in 2 of section
4.7.1. The GLO MAY also return a response to the
prospective member with cMCStatusInfo.cMCtatus.success prospective member with cMCStatusInfo.cMCtatus.success
indicating that the glkCompromise message was successfully indicating that the glkCompromise message was
received. 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 misplaced their shared KEK.
The shared KEK is not compromised and a rekey of the entire GL is The shared KEK is not compromised and a rekey of the entire GL is
not necessary. GL members use the glkRefresh message to request that not necessary. GL members use the glkRefresh message to request that
the shared KEK(s) be redistributed to them. Figure 10 depicts the the shared KEK(s) be redistributed to them. Figure 10 depicts the
protocol interactions for GL Key Refresh. 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 MUST include name of the
GL in GeneralName. GL in GeneralName.
1.a - The GL member MAY optionally apply confidentiality to the 1.a - The GL member MAY optionally apply confidentiality to the
request by encapsulating the SignedData.PKIData in an request by encapsulating the SignedData.PKIData in an
EnvelopedData (see paragraph 3.2.1.2). EnvelopedData (see section 3.2.1.2).
1.b - The GL member MAY also optionally apply another SignedData 1.b - The GL member MAY also optionally apply another SignedData
over the EnvelopedData (see paragraph 3.2.1.2). over the EnvelopedData (see section 3.2.1.2).
2 - Upon receipt of the glkRefresh request, the GLA verifies the 2 - Upon receipt of the glkRefresh request, the GLA verifies the
GL member's signature(s). If an additional SignedData and/or GL member's signature(s). If an additional SignedData and/or
EnvelopedData encapsulates the request (see paragraph 3.2.1.2 EnvelopedData encapsulates the request (see section 3.2.1.2 or
or 3.2.2), the GLA MUST verify the outer signature and/or 3.2.2), the GLA MUST verify 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.
2.a - If the signature(s) does(do) not verify, the GLA MUST return Turner 57
a cMCStatusInfo response indicating cMCStatus.failed and 2.a - If the signatures do not verify, the GLA MUST return a
cMCStatusInfo response indicating cMCStatus.failed and
otherInfo.failInfo.badMessageCheck. otherInfo.failInfo.badMessageCheck.
2.b - If the signature(s) does(do) verify, the GLA MUST make sure 2.b - Else the signatures do verify, the GLA MUST make sure the GL
the GL is supported by checking that the GL's GeneralName is supported by checking that the GLĘs GeneralName matches a
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 GLĘs name is not supported by the GLA, the GLA MUST
return a response indicating return a response indicating
glFailInfo.errorCode.invalidGLName. glFailInfo.errorCode.invalidGLName.
Turner 53 2.b.2 - Else the glName is supported by the GLA, the GLA MUST
2.b.2 - If the glName is supported by the GLA, the GLA MUST ensure ensure the GL member is on the GL.
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 MUST return a response indicating
glFailInfo.errorCode.noSpam. glFailInfo.errorCode.noSpam.
2.b.2.b - If the glMemberName is present on the GL, the GLA MUST 2.b.2.b - Else the glMemberName is present on the GL, the GLA MUST
return a glKey message (2 in Figure 10) as described in return a glKey message (2 in Figure 10) as described in
paragraph 5. 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 GLO 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 may also be times when
the prospective GL members or GL members need to know something prospective GL members or GL members need to know something about
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
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
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 MAY optionally
apply confidentiality to the request by encapsulating the apply confidentiality to the request by encapsulating the
SignedData.PKIData in an EnvelopedData (see paragraph
Turner 58
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 MAY also
optionally apply another SignedData over the EnvelopedData optionally apply another SignedData over the EnvelopedData
(see paragraph 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.
Turner 54
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 cMCStatusInfo response indicating MUST return a cMCStatusInfo response indicating
cMCStatus.noSupport and any other information in cMCStatus.noSupport and any other information in
statusString. statusString.
2.b - If the GLA does accept GLAQueryReuests, the GLA MUST verify 2.b - Else the GLA does accept GLAQueryRequests, the GLA MUST
the GLO's, GL member's, or prospective GL member's verify the GLO's, GL memberĘs, or prospective GL memberĘs
signature(s). If an additional SignedData and/or signature(s). If an additional SignedData and/or
EnvelopedData encapsulates the request (see paragraph EnvelopedData encapsulates the request (see section 3.2.1.2
3.2.1.2 or 3.2.2), the GLA MUST verify the outer signature or 3.2.2), the GLA MUST verify 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.b.1 - If the signature(s) does(do) not verify, the GLA MUST 2.b.1 - If the signatures do not verify, the GLA MUST return a
return a cMCStatusInfo response indicating cMCStatusInfo response indicating cMCStatus.failed and
cMCStatus.failed and otherInfo.failInfo.badMessageCheck. otherInfo.failInfo.badMessageCheck.
2.b.2 - If the signature(s) does(do) verify, the GLA MUST return a 2.b.2 - Else the signatures do verify, the GLA MUST return a
glaQueryResponse (2 in Figure 11) indicating the the glaQueryResponse (2 in Figure 11) with the correct
requested information if the glaRequestType is supported response if the glaRequestType is supported or return a
or return a cMCStatusInfo response indicating cMCStatusInfo response indicating cMCStatus.noSupport if
cMCStatus.noSupport if the glaRequestType is not the glaRequestType is not supported.
supported.
2.b.2.a - The GLA MUST apply confidentiality to the response by 2.b.2.a - The GLA MUST apply confidentiality to the response by
encapsulating the SignedData.PKIResponse in an encapsulating the SignedData.PKIResponse in an
EnvelopedData if the request was encapsulated in an EnvelopedData if the request was encapsulated in an
EnvelopedData (see paragraph 3.2.1.2). EnvelopedData (see section 3.2.1.2).
2.b.2.b - The GLA MAY also optionally apply another SignedData 2.b.2.b - The GLA MAY also optionally apply another SignedData
over the EnvelopedData (see paragraph 3.2.1.2). over the EnvelopedData (see section 3.2.1.2).
3 - Upon receipt of the glaQueryResponse, the GLO, GL member, or 3 - Upon receipt of the glaQueryResponse, the GLO, GL member, or
prospective GL member verifies the GLA's signature(s). If an prospective GL member verifies the GLA's signature(s). If an
additional SignedData and/or EnvelopedData encapsulates the additional SignedData and/or EnvelopedData encapsulates the
response (see paragraph 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 MUST verify the outer signature
and/or decrypt the outer layer prior to verifying the and/or decrypt the outer layer prior to verifying the
signature on the inner most SignedData. signature on the inner most SignedData.
3.a - If the signature(s) does(do) not verify, the GLO, GL member, 3.a - If the signatures do not verify, the GLO, GL member, or
or prospective GL member MUST return a cMCStatusInfo prospective GL member MUST return a cMCStatusInfo response
response indicating cMCStatus.failed and
Turner 59
indicating cMCStatus.failed and
otherInfo.failInfo.badMessageCheck. otherInfo.failInfo.badMessageCheck.
3.b - If the signatures do verify and the response was 3.b - Else the signatures do verify, the GLO, GL member, or
glaQueryResponse, the GLO, GL member, or prospective GL prospective GL member MUST check that one of the names in
member may use the information contained therein. the certificate used to sign the response matches the name
of the GL.
Turner 55 3.b.1 ū If the GLĘs name does not match the name present in the
certificate used to sign the message, the GLO should not
believe the response.
3.b.2 - Else the GLĘs name does match the name present in the
certificate and the response was glaQueryResponse, the GLO,
GL member, or prospective GL member may use the information
contained therein.
4.10 Update Member Certificate 4.10 Update Member Certificate
When the GLO generates a glAddMember request, when the GLA generates When the GLO generates a glAddMember request, when the GLA generates
a glKey message, or when the GLA processes a glAddMember there may a glKey message, or when the GLA processes a glAddMember there may
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 may also be times
when the GL member knows their certificate is about to expire or has when the GL member knows their certificate is about to expire or has
been revoked and they will not be able to receive GL rekeys. 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Ęs name in glMemberName.
1.a - The GLO or GLA MAY optionally apply confidentiality to the 1.a - The GLO or GLA MAY optionally apply confidentiality to the
request by encapsulating the SignedData.PKIData in an request by encapsulating the SignedData.PKIData in an
EnvelopedData (see paragraph 3.2.1.2). If the GL member's EnvelopedData (see section 3.2.1.2). If the GL memberĘs PKC
PKC has been revoked, the GLO or GLA MUST NOT use it to has been revoked, the GLO or GLA MUST NOT use it to generate
generate the EnvelopedData that encapsulates the the EnvelopedData that encapsulates the glProvideCert
glProvideCert request. request.
1.b - The GLO or GLA MAY also optionally apply another SignedData 1.b - The GLO or GLA MAY also optionally apply another SignedData
over the EnvelopedData (see paragraph 3.2.1.2). over the EnvelopedData (see section 3.2.1.2).
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Ęs or GLAĘs signature(s). If an additional
SignedData and/or EnvelopedData encapsulates the response (see SignedData and/or EnvelopedData encapsulates the response (see
paragraph 3.2.1.2 or 3.2.2), the GL member MUST verify the section 3.2.1.2 or 3.2.2), the GL member MUST verify the outer
outer signature and/or decrypt the outer layer prior to
verifying the signature on the inner most SignedData.
2.a - If the signature(s) does(do) not verify, the GL member MUST Turner 60
return a cMCStatusInfo response indicating cMCStatus.failed signature and/or decrypt the outer layer prior to verifying
and otherInfo.failInfo.badMessageCheck. the signature on the inner most SignedData.
2.b - If the signature(s) does(do) verify, the GL member generates 2.a - If the signatures do not verify, the GL member MUST return a
a Signed.PKIResponse.controlSequence.glUpdateCert that MUST cMCStatusInfo response indicating cMCStatus.failed and
otherInfo.failInfo.badMessageCheck.
2.b - Else the signatures do verify, the GL member generates a
Signed.PKIResponse.controlSequence.glUpdateCert that MUST
include the GL name in glName, the member's name in include the GL name in glName, the member's name in
glMember.glMemberName, their encryption certificate in glMember.glMemberName, their encryption certificate in
glMember.certificates.membersPKC. The GL member MAY also glMember.certificates.pKC. The GL member MAY also include
include any attribute certificates associated with their any attribute certificates associated with their encryption
encryption certificate in glMember.certificates.membersAC, certificate in glMember.certificates.aC, and the
and the certification path associated with their encryption certification path associated with their encryption and
and attribute certificates in attribute certificates in
glMember.certificates.certificationPath. glMember.certificates.certificationPath.
Turner 56
2.a - The GL member MAY optionally apply confidentiality to the 2.a - The GL member MAY optionally apply confidentiality to the
request by encapsulating the SignedData.PKIResponse in an request by encapsulating the SignedData.PKIResponse in an
EnvelopedData (see paragraph 3.2.1.2). If the GL member's EnvelopedData (see section 3.2.1.2). If the GL memberĘs PKC
PKC has been revoked, the GL member MUST NOT use it to has been revoked, the GL member MUST NOT use it to generate
generate the EnvelopedData that encapsulates the the EnvelopedData that encapsulates the glProvideCert
glProvideCert request. request.
2.b - The GL member MAY also optionally apply another SignedData 2.b - The GL member MAY also optionally apply another SignedData
over the EnvelopedData (see paragraph 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Ęs signature(s). If an additional
SignedData and/or EnvelopedData encapsulates the response (see SignedData and/or EnvelopedData encapsulates the response (see
paragraph 3.2.1.2 or 3.2.2), the GL member MUST verify the section 3.2.1.2 or 3.2.2), the GL member MUST verify the outer
outer signature and/or decrypt the outer layer prior to signature and/or decrypt the outer layer prior to verifying
verifying the signature on the inner most SignedData. the signature on the inner most SignedData.
3.a - If the signature(s) does(do) not verify, the GLO or GLA MUST 3.a - If the signatures do not verify, the GLO or GLA MUST return
return a cMCStatusInfo response indicating cMCStatus.failed a cMCStatusInfo response indicating cMCStatus.failed and
and otherInfo.failInfo.badMessageCheck. otherInfo.failInfo.badMessageCheck.
3.b - If the signature(s) does(do) verify, the GLO or GLA MUST 3.b - Else the signatures do verify, the GLO or GLA MUST verify
verify the member's encryption certificate. the memberĘs encryption certificate.
3.b.1 - If the member's encryption certificate does not verify, 3.b.1 - If the memberĘs encryption certificate does not verify,
the GLO MAY return either another glProvideCert request or the GLO MAY return either another glProvideCert request or
a cMCStatusInfo with cMCStatus.failed and the reason why a cMCStatusInfo 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
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 - If the member's encryption certificate does not verify, 3.b.2 - Else the memberĘs encryption certificate does not verify,
the GLA MAY return another glProvideCert request to the GL the GLA MAY return another glProvideCert request to the GL
Turner 61
member or a cMCStatusInfo with cMCStatus.failed and the member or a cMCStatusInfo 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 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 - If the member's encryption certificate does verify, the 3.b.3 - Else the memberĘs encryption certificate does verify, 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 MUST include
the GL name in glName, the member's name in the GL name in glName, the member's name in
Turner 57
glMember.glMemberName, their encryption certificate in glMember.glMemberName, their encryption certificate in
glMember.certificates.membersPKC. The GL member MAY also glMember.certificates.pKC. The GL member MAY also include any
include any attribute certificates associated with their attribute certificates associated with their encryption
encryption certificate in glMember.certificates.membersAC, and certificate in glMember.certificates.aC, and the certification
the certification path associated with their encryption and path associated with their encryption and attribute
attribute certificates in certificates in glMember.certificates.certificationPath.
glMember.certificates.certificationPath.
1.a - The GL member MAY optionally apply confidentiality to the 1.a - The GL member MAY optionally apply confidentiality to the
request by encapsulating the SignedData.PKIData in an request by encapsulating the SignedData.PKIData in an
EnvelopedData (see paragraph 3.2.1.2). If the GL member's EnvelopedData (see section 3.2.1.2). If the GL memberĘs PKC
PKC has been revoked, the GLO or GLA MUST NOT use it to has been revoked, the GLO or GLA MUST NOT use it to generate
generate the EnvelopedData that encapsulates the the EnvelopedData that encapsulates the glProvideCert
glProvideCert request. request.
1.b - The GL member MAY also optionally apply another SignedData 1.b - The GL member MAY also optionally apply another SignedData
over the EnvelopedData (see paragraph 3.2.1.2). over the EnvelopedData (see 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Ęs signature(s). If an additional SignedData and/or
EnvelopedData encapsulates the response (see paragraph 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 MUST verify the outer signature and/or
decrypt the outer layer prior to verifying the signature on decrypt the outer layer prior to verifying the signature on
the inner most SignedData. the inner most SignedData.
2.a - If the signature(s) does(do) not verify, the GLA MUST return 2.a - If the signatures do not verify, the GLA MUST return a
a cMCStatusInfo response indicating cMCStatus.failed and cMCStatusInfo response indicating cMCStatus.failed and
otherInfo.failInfo.badMessageCheck. otherInfo.failInfo.badMessageCheck.
2.b - If the signature(s) does(do) verify, the GLA MUST verify the 2.b - Else the signatures do verify, the GLA MUST verify the
member's encryption certificate. 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 does not verify,
the GLA MAY return another glProvideCert request to the GL the GLA MAY return another glProvideCert request to the GL
member or a cMCStatusInfo with cMCStatus.failed and the member or a cMCStatusInfo with cMCStatus.failed and the
Turner 62
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 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.
2.b.2 - If the member's encryption certificate does verify, the 2.b.2 - Else the memberĘs encryption certificate does verify, 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 MUST
also forward the glUpdateCert message to the GLO. also forward the glUpdateCert message to the GLO.
5 Distribution Message 5 Distribution Message
The GLA uses the glKey message to distribute new, shared KEK(s) The GLA uses the glKey message to distribute new, shared KEK(s)
after receiving 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
glSuccessInfo response for the respective request. Figure 12 depicts glSuccessInfo response for the respective request. Figure 12 depicts
Turner 58
the protocol interactions to send out glKey messages. The procedures the protocol interactions to send out glKey messages. The procedures
defined in this paragraph MUST be implemented. defined in this section MUST be implemented.
1 +----------+ 1 +----------+
+-------> | Member 1 | +-------> | Member 1 |
| +----------+ | +----------+
+-----+ | 1 +----------+ +-----+ | 1 +----------+
| GLA | ----+-------> | ... | | GLA | ----+-------> | ... |
+-----+ | +----------+ +-----+ | +----------+
| 1 +----------+ | 1 +----------+
+-------> | Member n | +-------> | Member n |
+----------+ +----------+
Figure 12 - GL Key Distribution Figure 12 - GL Key Distribution
If the GL was setup with GLKeyAttributes.recipientsMutuallyAware set If the GL was setup with GLKeyAttributes.recipientsNotMutuallyAware
to FALSE, a separate glKey message MUST be sent to each GL member so set to FALSE, a separate glKey message MUST be sent to each GL
as to not divulge information about the other GL members. member so as to not divulge information about the other GL members.
When the glKey message is generated as a result of a: When the glKey message is generated as a result of a:
- glAddMember request, - glAddMember request,
- glkComrpomise indication, - glkComrpomise indication,
- glkRefresh request, - glkRefresh request,
- glDeleteMember request with the the GL's glAdministration set to - glDeleteMember request with the GLĘs glAdministration set to
managed or closed, managed or closed,
- glRekey request with generationCounter set to zero (0) - glRekey request with generationCounter set to zero (0)
The GLA MUST use either the kari (see paragraph 12.3.2 of CMS [2]) The GLA MUST use either the kari (see section 12.3.2 of CMS [2]) or
or ktri (see paragraph 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 kari recipients receive the shared KEK. The GLA MUST support the ktri
choice. choice.
Turner 63
When the glKey message is generated as a result of a glRekey request When the glKey message is generated as a result of a glRekey request
with generationCounter greater than zero (0) or when the GLA with generationCounter greater than zero (0) or when the GLA
controls rekeys, the GLA MAY use the kari, ktri, or kekri (see controls rekeys, the GLA MAY use the kari, ktri, or kekri (see
paragraph 12.3.3 of CMS [2]) in glKey.glkWrapped.RecipientInfo to section 12.3.3 of CMS [2]) in glKey.glkWrapped.RecipientInfo to
ensure only the intended recipients receive the shared KEK. The GLA ensure only the intended recipients receive the shared KEK. The GLA
MUST support the RecipientInfo.kari choice. MUST support the RecipientInfo.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 invalid, the GLA MAY send a
Turner 59
glUpdateCert to the GL member requesting a new certificate be glUpdateCert to the GL member requesting a new certificate be
provided (see paragraph 4.10). The number of glKey messages provided (see section 4.10). The number of glKey messages
generated for the GL is described in paragraph 3.1.16. 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 paragraph 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 paragraph the EnvelopedData.SignedData.PKIData (see section 3.2.1.2).
3.2.1.2).
2 - Upon receipt of the message, the GL members MUST verify the 2 - Upon receipt of the message, the GL members MUST verify the
signature over the inner most SignedData.PKIData. If an signature over the inner most SignedData.PKIData. If an
additional SignedData and/or EnvelopedData encapsulates the additional SignedData and/or EnvelopedData encapsulates the
message (see paragraph 3.2.1.2 or 3.2.2), the GL Member MUST message (see 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 signature(s) does(do) not verify, the GL member MUST 2.a - If the signatures do not verify, the GL member MUST return a
return a cMCStatusInfo response indicating cMCStatus.failed cMCStatusInfo response indicating cMCStatus.failed and
and otherInfo.failInfo.badMessageCheck. otherInfo.failInfo.badMessageCheck.
2.b - If the signature(s) does(do) verify, the GL member process 2.b - Else the signatures do verify, the GL member process the
the RecipientInfos according to CMS [2]. Once unwrapped the RecipientInfos according to CMS [2]. Once unwrapped the GL
GL member should store the shared KEK in a safe place. When member should store the shared KEK in a safe place. When
stored, the glName, glIdentifier, and shared KEK should be stored, the glName, glIdentifier, and shared KEK should be
associated. associated.
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.
Turner 64
6.1 KEK Generation Algorithm 6.1 KEK Generation Algorithm
The shared KEK MUST be generated according to the security The shared KEK MUST be generated according to the security
considerations paragraph in CMS [2]. considerations section in CMS [2].
6.2 Shared KEK Wrap Algorithm 6.2 Shared KEK Wrap Algorithm
In the mechanisms described in paragraphs 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 12.3 of CMS [2]. specified in 12.3 of CMS [2].
Turner 60
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
paragraph 12.3.3 of CMS [2] section 12.3.3 of CMS [2]
7 Transport 7 Transport
SMTP [7] MUST be supported. All other transport mechanisms MAY be SMTP [7] MUST be supported. All other transport mechanisms MAY be
supported. supported.
8 Using the Group Key 8 Using the Group Key
TBSL 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
(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.
+----> +----> +---->
PK +-----+ S | S +-----+ S | S |
----> | MLA | --+----> ----> | MLA | --+----> ----+---->
+-----+ | +-----+ | |
+----> +----> +---->
Scenario 1 Scenario 2 Scenario 3
Turner 65
9 Security Considerations 9 Security Considerations
Don't have too many GLOs because they could start willie nillie Only have GLOs that are trusted.
adding people you don't like.
Need to rekey closed and managed GLs if a member is deleted. Need to rekey closed and managed GLs if a member is deleted.
GL members have to store some kind of information about who GL members have to store some kind of information about who
distributed the shared KEK to them so that they can make sure distributed the shared KEK to them so that they can make sure
subsequent rekeys are originated from the same entity. subsequent rekeys are originated from the same entity.
Need to make sure you don't make the key size too small and duration Need to make sure you donĘt make the key size too small and duration
long because people will have more time to attack the key. long because people will have more time to attack the key.
Need to make sure you don't make the generationCounter to large Need to make sure you donĘt make the generationCounter to large
because then people can attack the last key. If there are 14 keys because people can attack the last key. If there are 14 keys
outstanding each with a year's duration attackers might be able outstanding each with a yearĘs duration attackers might be able
determine the 14th key. determine the 14th key.
10 References 10 References
1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP
9, RFC 2026, October 1996. 9, RFC 2026, October 1996.
2 Housley, R., "Cryptographic Message Syntax," RFC 2630, June 1999. 2 Housley, R., "Cryptographic Message Syntax," RFC 2630, June 1999.
3 Myers, M., Liu, X., Schadd, J., Weinsten, J., "Certificate 3 Myers, M., Liu, X., Schaad, J., Weinsten, J., "Certificate
Management Message over CMS," draft-ietf-pkix-cmc-05.txt, July Management Message over CMS," draft-ietf-pkix-cmc-05.txt, July
1999. 1999.
Turner 61
4 Bradner, S., "Key words for use in RFCs to Indicate Requirement 4 Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
5 Ramsdale, B., "S/MIME Version 3 Message Specification," RFC 2633, 5 Ramsdale, B., "S/MIME Version 3 Message Specification," RFC 2633,
June 1999. June 1999.
6 Housley, R., Ford, W., Polk, W. and D. Solo, "Internet X.509 6 Housley, R., Ford, W., Polk, W. and D. Solo, "Internet X.509
Public Key Infrastructure: Certificate and CRL Profile", RFC Public Key Infrastructure: Certificate and CRL Profile", RFC
2459, January 1999. 2459, January 1999.
7 Postel, j., "Simple Mail Transport Protocol," RFC 821, August 7 Postel, j., "Simple Mail Transport Protocol," RFC 821, August
1982. 1982.
11 Acknowledgements 11 Acknowledgements
Thanks to Russ Housley and Jim Schaad for providing much of the Thanks to Russ Housley and Jim Schaad for providing much of the
background and review required to write this draft. background and review required to write this draft.
Turner 66
12 Author's Addresses 12 Author's Addresses
Sean Turner Sean Turner
IECA, Inc. IECA, Inc.
9010 Edgepark Road 9010 Edgepark Road
Vienna, VA 22182 Vienna, VA 22182
Phone: +1.703.628.3180 Phone: +1.703.628.3180
Email: turners@ieca.com Email: turners@ieca.com
Expires April 2001 Turner 67
Annex A: ASN.1 Module
Turner 62 SMIMESymmetricKeyDistribution
{ TBD }
DEFINITIONS IMPLICIT TAGS ::=
BEGIN
-- EXPORTS All --
-- The types and values defined in this module are exported for use
-- in the other ASN.1 modules. Other applications may use them for
-- their own purposes.
IMPORTS
-- Directory Authentication Framework (X.509)
AlgorithmIdentifier, AttributeCertificate, Certificate,
FROM AuthenticationFramework { joint-iso-itu-t ds(5)
module(1) authenticationFramework(7) 3 }
-- PKIX Part 1 - Implicit
GeneralName
FROM PKIX1Implicit88 {iso(1) identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
id-pkix1-implicit-88(2)}
-- Cryptographic Message Syntax
RecipientInfos, id-alg-CMS3DESWrap
FROM CryptographicMessageSyntax { iso(1) member-body(2) us(840)
rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) modules(0)
cms(1)};
-- This defines the GL Use KEK control attribute
id-skd-glUseKEK OBJECT IDENTIFIER ::= { id-skd 1}
GLUseKEK ::= SEQUENCE {
glInfo GLInfo,
glOwnerInfo SEQUENCE SIZE (1..MAX) OF GLOwnerInfo,
glAdministration GLAdministration DEFAULT (1),
glKeyAttributes GLKeyAttributes OPTIONAL }
GLInfo ::= SEQUENCE {
glName GeneralName,
glAddress GeneralName }
GLOwnerInfo ::= SEQUENCE {
glOwnerName GeneralName,
glOwnerAddress GeneralName }
Turner 68
GLAdministration ::= INTEGER {
unmanaged (0),
managed (1),
closed (2) }
GLKeyAttributes ::= SEQUENCE {
rekeyControlledByGLO [0] BOOLEAN DEFAULT FALSE,
recipientsNotMutuallyAware [1] BOOLEAN DEFAULT TRUE,
duration [2] INTEGER DEAULT (0),
generationCounter [3] INTEGER DEFAULT (2),
requestedAlgorithm [4] AlgorithmIdentifier
DEFAULT (id-alg-CMS3DESwrap) }
-- This defines the Delete GL control attribute.
-- It has the simple type GeneralName.
id-skd-glDelete OBJECT IDENTIFIER ::= { id-skd 2}
-- This defines the Add GL Member control attribute
id-skd-glAddMember OBJECT IDENTIFIER ::= { id-skd 3}
GLAddMember ::= SEQUENCE {
glName GeneralName,
glMember GLMember }
GLMember ::= SEQUENCE {
glMemberName GeneralName,
glMemberAddress GeneralName OPTIONAL,
certificates Certificates OPTIONAL }
Certificates ::= SEQUENCE {
pKC Certificate OPTIONAL,
-- See X.509
aC SEQUENCE SIZE (1.. MAX) OF
AttributeCertificate OPTIONAL,
-- See X.509
certificationPath CertificateSet OPTIONAL }
-- From CMS [2]
CertificateSet ::= SET SIZE (1..MAX) OF CertificateChoices
CertificateChoices ::= CHOICE {
certificate Certificate,
-- See X.509
extendedCertificate [0] IMPLICIT ExtendedCertificate,
-- Obsolete
attrCert [1] IMPLICIT AttributeCertificate }
-- See X.509 and X9.57
Turner 69
-- This defines the Delete GL Member control attribute
id-skd-glDeleteMember OBJECT IDENTIFIER ::= { id-skd 4}
GLDeleteMember ::= SEQUENCE {
glName GeneralName,
glMemberToDelete GeneralName }
-- This defines the Delete GL Member control attribute
id-skd-glRekey OBJECT IDENTIFIER ::= { id-skd 5}
GLRekey ::= SEQUENCE {
glName GeneralName,
glAdministration GLAdministration OPTIONAL,
glNewKeyAttributes GLNewKeyAttributes OPTIONAL,
glRekeyAllGLKeys BOOLEAN OPTIONAL }
GLNewKeyAttributes ::= SEQUENCE {
rekeyControlledByGLO [0] BOOLEAN OPTIONAL,
recipientsNotMutuallyAware [1] BOOLEAN OPTIONAL,
duration [2] INTEGER OPTIONAL,
generationCounter [3] INTEGER OPTIONAL,
requestedAlgorithm [4] AlgorithmIdentifier OPTIONAL }
-- This defines the Add and Delete GL Owner control attributes
id-skd-glAddOwner OBJECT IDENTIFIER ::= { id-skd 6}
id-skd-glRemoveOwner OBJECT IDENTIFIER ::= { id-skd 7}
GLOwnerAdministration ::= SEQUENCE {
glName GeneralName,
glOwnerInfo GLOwnerInfo }
-- This defines the GL Key Compromise control attribute.
-- It has the simple type GeneralName.
id-skd-glKeyCompromise OBJECT IDENTIFIER ::= { id-skd 8}
-- This defines the GL Key Refresh control attribute.
id-skd-glkRefresh OBJECT IDENTIFIER ::= { id-skd 9}
GLKRefresh ::= {
glName GeneralName,
dates SEQUENCE (1..MAX) OF Date }
Date ::= {
start GeneralizedTime,
end GeneralizedTime OPTIONAL }
Turner 70
-- This defines the GLA Query Request control attribute.
id-skd-glaQueryRequest OBJECT IDENTIFIER ::= { id-skd X}
GLAQueryRequest ::= SEQUENCE {
glaRequestType OBJECT IDENTIFIER,
glaRequestValue ANY DEFINED BY glaResponseType }
-- This defines the Algorithm Request
id-rt-algorithmSupported { id-tbd }
-- This defines the GLA Query Response control attribute.
id-skd-glaQueryResponse OBJECT IDENTIFIER ::= { id-skd X}
GLAQueryResponse ::= SEQUENCE {
glaResponseType OBJECT IDENTIFIER,
glaResponseValue ANY DEFINED BY glaResponseType }
-- Note that the response for algorithmSupported request is the
-- smimeCapabilities attribute as defined in MsgSpec [5].
-- This defines the control attribute to request an updated
-- certificate to the GLA.
id-skd-glProvideCert OBJECT IDENTIFIER ::= { id-skd X}
GLManageCert ::= SEQUENCE {
glName GeneralName,
glMember GLMember }
-- This defines the control attribute to return an updated
-- certificate to the GLA. It has the type GLManageCert.
id-skd-glManageCert OBJECT IDENTIFIER ::= { id-skd X}
-- This defines the control attribute to distribute the GL shared
-- KEK.
id-skd-glKey OBJECT IDENTIFIER ::= { id-skd X}
Turner 71
GLKey ::= SEQUENCE {
glName GeneralName,
glIdentifier OCTET STRING,
glkWrapped RecipientInfos, -- See CMS [2]
glkAlgorithm AlgorithmIdentifier,
glkNotBefore GeneralizedTime,
glkNotAfter GeneralizedTime }
END -- SMIMESymmetricKeyDistribution
September 2, 2001
Turner 72
 End of changes. 

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