idnits 2.17.1 draft-ietf-smime-symkeydist-03.txt: -(394): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(399): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(726): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(856): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(875): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(886): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(914): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(933): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1353): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1557): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1736): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1910): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1990): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(2275): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(2791): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(2794): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(2908): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(3197): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. == There are 94 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([2], [3]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 311 has weird spacing: '...esponse id-...' == Line 2677 has weird spacing: '...hecking that ...' == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: 2.b.2.c - Else the names do match, the GLA MUST return a glSuccessInfo indicating the glName, and an action.actionCode.deletedGL (2 in Figure 4). glMemberName and glOwnerName MUST be omitted. The GLA MUST not accept further requests for member additions, member deletions, or group rekeys for this GL. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 2, 2001) is 8453 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '1' on line 3360 looks like a reference -- Missing reference section? '2' on line 3434 looks like a reference -- Missing reference section? '3' on line 3362 looks like a reference -- Missing reference section? '4' on line 3363 looks like a reference -- Missing reference section? '0' on line 3359 looks like a reference -- Missing reference section? '5' on line 3411 looks like a reference -- Missing reference section? '6' on line 1285 looks like a reference -- Missing reference section? '7' on line 3164 looks like a reference Summary: 5 errors (**), 0 flaws (~~), 5 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 SMIME Working Group S. Turner 2 Internet Draft IECA 3 Document: draft-ietf-smime-symkeydist-03.txt March 2, 2001 4 Expires: September 2, 2001 6 S/MIME Symmetric Key Distribution 8 Status of this Memo 10 This document is an Internet-Draft and is in full conformance with 11 all provisions of Section 10 of RFC2026 [1]. 13 This document is an Internet-Draft. Internet-Drafts are working 14 documents of the Internet Engineering Task Force (IETF), its areas, 15 and its working groups. Note that other groups may also distribute 16 working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six 19 months and may be updated, replaced, or obsoleted by other documents 20 at any time. It is inappropriate to use Internet-Drafts as reference 21 material or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 This draft is being discussed on the 'ietf-smime' mailing list. To 30 subscribe, send a message to ietf-smime-request@imc.org with the 31 single word subscribe in the body of the message. There is a Web 32 site for the mailing list at . 34 Abstract 36 This document describes a mechanism to manage (i.e., setup, 37 distribute, and rekey) keys used with symmetric cryptographic 38 algorithms. Also defined herein is a mechanism to organize users 39 into groups to support distribution of encrypted content using 40 symmetric cryptographic algorithms. The mechanism uses the 41 Cryptographic Message Syntax (CMS) protocol [2] and Certificate 42 Management Message over CMS (CMC) protocol [3] to manage the 43 symmetric keys. Any member of the group can then later use this 44 distributed shared key to decrypt other CMS encrypted objects with 45 the symmetric key. This mechanism has been developed to support 46 S/MIME Mail List Agents (MLAs). 48 Conventions used in this document 50 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 51 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 52 document are to be interpreted as described in RFC-2119 [4]. 54 1. INTRODUCTION....................................................3 55 1.1 APPLICABILITY TO E-MAIL........................................4 56 1.2 APPLICABILITY TO REPOSITORIES..................................4 57 2. ARCHITECTURE....................................................5 58 3. PROTOCOL INTERACTIONS...........................................6 59 3.1 CONTROL ATTRIBUTES.............................................7 60 3.1.1 GL USE KEK...................................................8 61 3.1.2 DELETE GL...................................................11 62 3.1.3 ADD GL MEMBER...............................................11 63 3.1.4 DELETE GL MEMBER............................................12 64 3.1.5 REKEY GL....................................................13 65 3.1.6 ADD GL OWNER................................................14 66 3.1.7 REMOVE GL OWNER.............................................14 67 3.1.8 GL KEY COMPROMISE...........................................14 68 3.1.9 GL KEY REFRESH..............................................15 69 3.1.10 GL SUCCESS INFORMATION.....................................15 70 3.1.11 GL FAIL INFORMATION........................................16 71 3.1.12 GLA QUERY REQUEST..........................................18 72 3.1.13 GLA QUERY RESPONSE.........................................18 73 3.1.14 PROVIDE CERT...............................................19 74 3.1.15 UPDATE CERT................................................20 75 3.1.16 GL KEY.....................................................21 76 3.2 USE OF CMC, CMS, AND PKIX.....................................22 77 3.2.1 PROTECTION LAYERS...........................................22 78 3.2.1.1 MINIMUM PROTECTION........................................23 79 3.2.1.2 ADDITIONAL PROTECTION.....................................23 80 3.2.2 COMBINING REQUESTS AND RESPONSES............................23 81 3.2.3 GLA GENERATED MESSAGES......................................25 82 3.2.4 CMC CONTROL ATTRIBUTES......................................26 83 3.2.5 RESUBMITTED GL MEMBER MESSAGES..............................27 84 3.2.6 PKIX........................................................28 85 4 ADMINISTRATIVE MESSAGES.........................................28 86 4.1 ASSIGN KEK TO GL..............................................28 87 4.2 DELETE GL FROM GLA............................................31 88 4.3 ADD MEMBERS TO GL.............................................33 89 4.3.1 GLO INITIATED ADDITIONS.....................................34 90 4.3.2 PROSPECTIVE MEMBER INITIATED ADDITIONS......................40 91 4.4 DELETE MEMBERS FROM GL........................................42 92 4.4.1 GLO INITIATED DELETIONS.....................................43 93 4.4.2 MEMBER INITIATED DELETIONS..................................47 94 4.5 REQUEST REKEY OF GL...........................................48 95 4.5.1 GLO INITIATED REKEY REQUESTS................................49 96 4.5.2 GLA INITIATED REKEY REQUESTS................................51 97 4.6 CHANGE GLO....................................................52 98 4.7 INDICATE KEK COMPROMISE.......................................54 99 4.7.1 GL MEMBER INITIATED KEK COMPROMISE MESSAGE..................55 100 4.7.2 GLO INITIATED KEK COMPROMISE MESSAGE........................56 101 4.8 REQUEST KEK REFRESH...........................................57 102 4.9 GLA QUERY REQUEST AND RESPONSE................................58 103 4.10 UPDATE MEMBER CERTIFICATE....................................60 104 4.10.1 GLO AND GLA INITIATED UPDATE MEMBER CERTIFICATE............60 105 4.10.2 GL MEMBER INITIATED UPDATE MEMBER CERTIFICATE..............62 106 5 DISTRIBUTION MESSAGE............................................63 107 5.1 DISTRIBUTION PROCESS..........................................64 108 6 ALGORITHMS......................................................64 109 6.1 KEK GENERATION ALGORITHM......................................65 110 6.2 SHARED KEK WRAP ALGORITHM.....................................65 111 6.3 SHARED KEK ALGORITHM..........................................65 112 7 TRANSPORT.......................................................65 113 8 USING THE GROUP KEY.............................................65 114 9 SECURITY CONSIDERATIONS.........................................66 115 10 REFERENCES.....................................................66 116 11 ACKNOWLEDGEMENTS...............................................66 117 12 AUTHOR'S ADDRESSES.............................................67 119 1. Introduction 121 With the ever-expanding use of secure electronic communications 122 (e.g., S/MIME [2]), users require a mechanism to distribute 123 encrypted data to multiple recipients (i.e., a group of users). 124 There are essentially two ways to encrypt the data for recipients: 125 using asymmetric algorithms with public key certificates (PKCs) or 126 symmetric algorithms with symmetric keys. 128 With asymmetric algorithms, the originator forms an originator- 129 determined content-encryption key (CEK) and encrypts the content, 130 using a symmetric algorithm. Then, using an asymmetric algorithm and 131 the recipient's PKCs, the originator generates per-recipient 132 information that either (a) encrypts the CEK for a particular 133 recipient (ktri ReipientInfo CHOICE), or (b) transfers sufficient 134 parameters to enable a particular recipient to independently 135 generate the same KEK (kari RecipientInfo CHOICE). If the group is 136 large, the amount of per-recipient information required may take 137 quite some time to generate, not to mention the time required to 138 collect and validate the PKCs for each of the recipients. Each 139 recipient identifies their per-recipient information and uses the 140 private key associated with the public key of their PKC to decrypt 141 the CEK and hence gain access to the encrypted content. 143 With symmetric algorithms, the origination process is the same as 144 with asymmetric algorithms except for what encrypts the CEK. Instead 145 of using PKCs, the originator uses a previously distributed secret 146 key-encryption key (KEK) to encrypt the CEK (kekri RecipientInfo 147 CHOICE). Only one copy of the encrypted CEK is required because all 148 the recipients already have the shared KEK needed to decrypt the CEK 149 and hence gain access to the encrypted content. 151 The security provided by the shared KEK is only as good as the sum 152 of the techniques employed by each member of the group to keep the 153 KEK secret from nonmembers. These techniques are beyond the scope of 154 this document. Only the members of the list and the key manager 155 should have the KEK in order to maintain the secrecy of the group. 156 Access control to the information protected by the KEK is determined 157 by the entity that encrypts the information, as all members of the 158 group have access. If the entity that is performing the encryption 159 wants to ensure some subset of the group does not gain access to the 160 information either a different KEK should be used (shared with this 161 smaller group) or asymmetric algorithms should be used. 163 1.1 Applicability to E-mail 165 One primary audience for this distribution mechanism is e-mail. 166 Distribution lists sometimes referred to as mail lists, have been 167 defined to support distribution of messages to recipients subscribed 168 to the mail list. There are two models for how the mail list can be 169 used. If the originator is a member of the mail list, the originator 170 sends messages encrypted with the shared KEK to the mail list (e.g., 171 listserv or majordomo) and the message is distributed to the mail 172 list members. If the originator is not a member of the mail list 173 (does not have the shared KEK), the originator sends the message 174 (encrypted for the MLA) to the mail list agent (MLA) and the MLA 175 then forms the shared KEK needed to encrypt the message. In either 176 case the recipients of the mail list use the previously distributed- 177 shared KEK to decrypt the message. 179 1.2 Applicability to Repositories 181 Objects can also be distributed via a repository (e.g., Light Weight 182 Directory Protocol (LDAP) servers, X.500 Directory System Agents 183 (DSAs), Web-based servers). If an object is stored in a repository 184 encrypted with a symmetric key algorithm, any one with the shared 185 KEK and access to that object can then decrypt that object. The 186 encrypted object and the encrypted, shared KEK can be stored in the 187 repository. 189 2. Architecture 191 Figure 1 depicts the architecture to support symmetric key 192 distribution. The Group List Agent (GLA) supports two distinct 193 functions with two different agents: 195 - The Key Management Agent (KMA) which is responsible for 196 generating the shared KEKs. 198 - The Group Management Agent (GMA) which is responsible for 199 managing the Group List (GL) to which the shared KEKs are 200 distributed. 202 +----------------------------------------------+ 203 | Group List Agent | +-------+ 204 | +------------+ + -----------------------+ | | Group | 205 | | Key | | Group Management Agent | |<-->| List | 206 | | Management |<-->| +------------+ | | | Owner | 207 | | Agent | | | Group List | | | +-------+ 208 | +------------+ | +------------+ | | 209 | | / | \ | | 210 | +------------------------+ | 211 +----------------------------------------------+ 212 / | \ 213 +----------+ +---------+ +----------+ 214 | Member 1 | | ... | | Member n | 215 +----------+ +---------+ +----------+ 217 Figure 1 - Key Distribution Architecture 219 A GLA may support multiple KMAs. A GLA in general supports only one 220 GMA, but the GMA may support multiple GLs. Multiple KMAs may support 221 a GMA in the same fashion as GLAs support multiple KMAs. Assigning a 222 particular KMA to a GL is beyond the scope of this document. 224 Modeling real world GL implementations shows that there are very 225 restrictive GLs, where a human determines GL membership, and very 226 open GLs, where there are no restrictions on GL membership. To 227 support this spectrum, the mechanism described herein supports both 228 managed (i.e., where access control is applied) and unmanaged (i.e., 229 where no access control is applied) GLs. The access control 230 mechanism for managed lists is beyond the scope of this document. 232 In either case, the GL must initially be constructed by an entity 233 hereafter called the Group List Owner (GLO). There may be multiple 234 entities who 'own' the GL and who are allowed to make changes the 235 GL�s properties or membership. The GLO determines if the GL will be 236 managed or unmanaged and is the only entity that may delete the GL. 237 GLO(s) may or may not be GL members. 239 Though Figure 1 depicts the GLA as encompassing both the KMA and GMA 240 functions, the two functions could be supported by the same entity 241 or they could be supported by two different entities. If two 242 entities are used, they could be located on one or two platforms. 243 There is however a close relationship between the KMA and GMA 244 functions. If the GMA stores all information pertaining to the GLs 245 and the KMA merely generates keys, a corrupted GMA could cause 246 havoc. To protect against a corrupted GMA, the KMA would be forced 247 to double check the requests it receives to ensure the GMA did not 248 tamper with them. These duplicative checks blur the functionality of 249 the two components together. For this reason, the interactions 250 between the KMA and GMA are beyond the scope of this document. 251 Proprietary mechanisms may be used to separate the functions by 252 strengthening the trust relationship between the two entities. 253 Henceforth, the distinction between the two agents is omitted; the 254 term GLA will be used to address both functions. It should be noted 255 that corrupt GLA can always cause havoc. 257 3. Protocol Interactions 259 There are existing mechanisms (e.g., listserv and majordomo) to 260 support managing GLs; however, this document does not address 261 securing these mechanisms, as they are not standardized. Instead, it 262 defines protocol interactions, as depicted in Figure 2, used by the 263 GL members, GLA, and GLO to manage GLs and distribute shared KEKs. 264 The interactions have been divided into administration messages and 265 distribution messages. The administrative messages are the request 266 and response messages needed to setup the GL, delete the GL, add 267 members to the GL, delete members of the GL, and request a group 268 rekey, etc. The distribution messages are the messages that 269 distribute the shared KEKs. The following sections describe the 270 ASN.1 for both the administration and distribution messages. Section 271 4 describes how to use the administration messages and section 5 272 describes how to use the distribution messages. 274 +-----+ +----------+ 275 | GLO | <---+ +----> | Member 1 | 276 +-----+ | | +----------+ 277 | | 278 +-----+ <------+ | +----------+ 279 | GLA | <-------------+----> | ... | 280 +-----+ | +----------+ 281 | 282 | +----------+ 283 +----> | Member n | 284 +----------+ 286 Figure 2 - Protocol Interactions 287 3.1 Control Attributes 289 The messages are based on including control attributes in CMC's 290 PKIData for requests and CMC's ResponseBody0 for responses. The 291 content-types PKIData and PKIResponse are then encapsulated in CMS's 292 SignedData or EnvelopedData, or a combination of the two (see 293 section 3.2). The following are the control attributes defined in 294 this document: 296 Control 297 Attribute OID Syntax 298 ------------------- ----------- ----------------- 299 glUseKEK id-skd 1 GLUseKEK 300 glDelete id-skd 2 GeneralName 301 glAddMember id-skd 3 GLAddMember 302 glDeleteMember id-skd 4 GLDeleteMember 303 glRekey id-skd 5 GLRekey 304 glAddOwner id-skd 6 GLOwnerAdministration 305 glRemoveOwner id-skd 7 GLOwnerAdministration 306 glkCompromise id-skd 8 GeneralName 307 glkRefresh id-skd 9 GLKRefresh 308 glSuccessInfo id-skd 10 GLSuccessInfo 309 glFailInfo id-skd 11 GLFailInfo 310 glaQueryRequest id-skd 12 GLAQueryRequest 311 glaQueryResponse id-skd 13 GLAQueryResponse 312 glProvideCert id-skd 14 GLManageCert 313 glUpdateCert id-skd 15 GLManageCert 314 glKey id-skd 16 GLKey 316 In the following conformance tables, the column headings have the 317 following meanings: O for originate, R for receive, F for forward. 318 There are three types of implementations: GLOs, GLAs, and GL 319 members. The GLO is an optional component hence all of the messages 320 for it are optional and the GLO forwarding messages to it or the GL 321 member. The first table includes messages that MUST be implemented 322 in order to be considered conformant to this document. The second 323 table includes messages that MAY be implemented in order to be 324 considered conformant to this document. 326 Required 327 Implementation Requirement | Control 328 GLO | GLA | GL Member | Attribute 329 O R |O R F | O R | 330 -------- |------------------ |--------- |---------- 331 MAY - |MUST - MAY | - MUST |glProvideCert 332 MAY MAY | - MUST MAY | MUST - |glUpdateCert 333 - - |MUST - - | - MUST |glKey 334 - MAY |MUST - - | - MUST |glSucessInfo 335 - MAY |MUST - - | - MUST |glFailInfo 337 Optional 338 Implementation Requirement | Control 339 GLO | GLA | GL Member | Attribute 340 O R |O R F | O R | 341 -------- |------------------ |--------- |---------- 342 MAY - | - MAY - | - - |glUseKEK 343 MAY - | - MAY - | - - |glDelete 344 MAY MAY | - MUST MAY | MUST - |glAddMember 345 MAY MAY | - MUST MAY | MUST - |glDeleteMember 346 MAY - | - MAY - | - - |glRekey 347 MAY - | - MAY - | - - |glAddOwner 348 MAY - | - MAY - | - - |glRemoveOwner 349 MAY MAY | - MUST MAY | MUST - |glkCompromise 350 MAY - | - MUST - | MUST - |glkRefresh 351 MAY - | - SHOULD - | MAY - |glaQueryRequest 352 - MAY |SHOULD - - | - MAY |glaQueryResponse 354 glSuccessInfo, glFailInfo, glaQueryResponse, and gloResponse are 355 responses and go into the PKIResponse content-type, all other 356 control attributes are included in requests and go into the PKIData 357 content-type. The exception is glUpdateCert which may be included in 358 either PKIData or PKIResponse. 360 3.1.1 GL USE KEK 362 The GLO uses glUseKEK to request that a shared KEK be assigned to a 363 GL. glUseKEK messages MUST be signed by the GLO. The glUseKEK 364 control attribute shall have the syntax GLUseKEK: 366 GLUseKEK ::= SEQUENCE { 367 glInfo GLInfo, 368 glOwnerInfo SEQUENCE SIZE (1..MAX) OF GLOwnerInfo, 369 glAdministration GLAdministration DEFAULT (1), 370 glKeyAttributes GLKeyAttributes OPTIONAL } 371 GLInfo ::= SEQUENCE { 372 glName GeneralName, 373 glAddress GeneralName } 375 GLOwnerInfo ::= SEQUENCE { 376 glOwnerName GeneralName, 377 glOwnerAddress GeneralName } 379 GLAdministration ::= INTEGER { 380 unmanaged (0), 381 managed (1), 382 closed (2) } 384 GLKeyAttributes ::= SEQUENCE { 385 rekeyControlledByGLO [0] BOOLEAN DEFAULT FALSE, 386 recipientsNotMutuallyAware [1] BOOLEAN DEFAULT TRUE, 387 duration [2] INTEGER DEAULT (0), 388 generationCounter [3] INTEGER DEFAULT (2), 389 requestedAlgorithm [4] AlgorithmIdentifier 390 DEFAULT (id-alg-CMS3DESwrap) } 392 The fields in GLUseKEK have the following meaning: 394 - glInfo indicates the GL�s name in glName and the GL�s address in 395 glAddress. In some instances the glName and glAddress may be the 396 same, but this is not always the case. Both the name and address 397 MUST be unique for a given GLA. 399 - glOwnerInfo indicates the GL owner�s name in glOwnerName and the 400 GL owner�s address in glOwnerAddress. One of the names in 401 glOwnerName MUST match one of the names in the certificate used 402 to sign this SignedData.PKIData creating the GL (i.e., the 403 immediate signer). 405 - glAdministration indicates how the GL should be administered. 406 The default is for the list to be managed. Three values are 407 supported for glAdministration: 409 - Unmanaged - When the GLO sets glAdministration to unmanaged, 410 they are allowing prospective members to request being added 411 and deleted from the GL without GLO intervention. 413 - Managed - When the GLO sets glAdministration to managed, they 414 are allowing prospective members to request being added to and 415 deleted from the GL, but the request is redirected by the GLA 416 to GLO for review. The GLO makes the determination as to 417 whether to honor the request. 419 - Closed - When the GLO sets glAdministration to closed, they 420 are not allowing prospective members to request being added to 421 or deleted from the GL. The GLA will only accept glAddMember 422 and glDeleteMember requests from the GLO. It is GL policy as 423 to whether to forward the request on to the GLO. 425 - glKeyAttributes indicates the attributes the GLO wants the GLA 426 to assign to the shared KEK. If this field is omitted, GL rekeys 427 will be controlled by the GLA, the recipients are allowed to 428 know about one another, the algorithm will Triple-DES (see 429 paragrpah 7), the shared KEK will be valid for a calendar month 430 (i.e., first of the month until the last day of the month), and 431 two shared KEKs will be distributed initially. The fields in 432 glKeyAttributes have the following meaning: 434 - rekeyControlledByGLO indicates whether the GL rekey messages 435 will be generated by the GLO or by the GLA. The default is for 436 the GLA to control rekeys. If GL rekey is controlled by the 437 GLA, the GL will continue to be rekeyed until the GLO deletes 438 the GL or changes the GL rekey to be GLO controlled. 440 - recipientsNotMutuallyAware indicates that the GLO wants the 441 GLA to distribute the shared KEK individually for each of the 442 GL members (i.e., a separate glKey message is sent to each 443 recipient). The default is for separate glKey message to not 444 be required. 446 NOTE: This supports lists where one member does not know the 447 identities of the other members. For example, a list is 448 configured granting submit permissions to only one member. All 449 other members are 'listening.' The security policy of the list 450 does not allow the members to know who else is on the list. If 451 a glKey is constructed for all of the GL members, information 452 about each of the members may be derived from the information 453 in RecipientInfos. To make sure the glkey message does not 454 divulge information about the other recipients, a separate 455 glKey message would be sent to each GL member. 457 - duration indicates the length of time (in days) during which 458 the shared KEK is considered valid. The value zero (0) 459 indicates that the shared KEK is valid for a calendar month at 460 UTC Zulu time zone. For example if the duration is zero (0), 461 if the GL shared KEK is requested on July 24, the first key 462 will be valid until the end of July and the next key will be 463 valid for the entire month of August. If the value is not zero 464 (0), the shared KEK will be valid for the number of days 465 indicated by the value. For example, if the value of duration 466 is seven (7) and the shared KEK is requested on Monday but not 467 generated until Tuesday (2359); the shared KEKs will be valid 468 from Tuesday (2359) to Tuesday (2359). The exact time of the 469 day is determined when the key is generated. 471 - generationCounter indicates the number of keys the GLO wants 472 the GLA to distribute. To ensure uninterrupted function of the 473 GL two (2) shared KEKs at a minimum MUST be initially 474 distributed. The second shared KEK is distributed with the 475 first shared KEK, so that when the first shared KEK is no 476 longer valid the second key can be used. If the GLA controls 477 rekey then it also indicates the number of shared KEKs the GLO 478 wants outstanding at any one time. See sections 4.5 and 5 for 479 more on rekey. 481 - requestedAlgorithm indicates the algorithm and any parameters 482 the GLO wants the GLA to use with the shared KEK. The 483 parameters are conveyed via the SMIMECapabilities attribute 484 see MSG {x}. See section 7 for more on algorithms. 486 3.1.2 Delete GL 488 GLOs use glDelete to request that a GL be deleted from the GLA. The 489 glDelete control attribute shall have the syntax GeneralName. The 490 name of the GL to be deleted is included in GeneralName. The 491 glDelete message MUST be signed by the GLO. 493 3.1.3 Add GL Member 495 GLOs use glAddMember to request addition of new members and 496 prospective GL members use glAddMember to request being added to the 497 GL. The glAddMember message must be signed by either the GLO or the 498 prospective GL member. The glAddMember control attribute shall have 499 the syntax GLAddMember: 501 GLAddMember ::= SEQUENCE { 502 glName GeneralName, 503 glMember GLMember } 505 GLMember ::= SEQUENCE { 506 glMemberName GeneralName, 507 glMemberAddress GeneralName OPTIONAL, 508 certificates Certificates OPTIONAL } 510 Certificates ::= SEQUENCE { 511 pKC Certificate OPTIONAL, 512 -- See X.509 513 aC SEQUENCE SIZE (1.. MAX) OF 514 AttributeCertificate OPTIONAL, 515 -- See X.509 516 certificationPath CertificateSet OPTIONAL } 517 -- From CMS [2] 519 CertificateSet ::= SET SIZE (1..MAX) OF CertificateChoices 520 CertificateChoices ::= CHOICE { 521 certificate Certificate, 522 -- See X.509 523 extendedCertificate [0] IMPLICIT ExtendedCertificate, 524 -- Obsolete 525 attrCert [1] IMPLICIT AttributeCertificate } 526 -- See X.509 and X9.57 528 The fields in GLAddMembers have the following meaning: 530 - glName indicates the name of the GL to which the member should 531 be added. 533 - glMember indicates the particulars for the GL member. Both of 534 the following fields must be unique for a given GL: 536 - glMemberName indicates the name of the GL member. 538 - glMemberAddress indicates the GL member�s address. It MUST be 539 included. 541 Note: In some instances the glMemberName and glMemberAddress 542 may be the same, but this is not always the case. 544 - certificates MUST be included. It contains the following three 545 fields: 547 - certificates.pKC includes the member's encryption 548 certificate that will be used to at least initially encrypt 549 the shared KEK for that member. If the message is generated 550 by a prospective GL member, the pKC MUST be included. If the 551 message is generated by a GLO, the pKC SHOULD be included. 553 - certificates.aC MAY be included to convey any attribute 554 certificate associated with the member�s encryption 555 certificate. 557 - certificates.certificationPath MAY also be included to 558 convey the certification path corresponding to the member's 559 encryption and any non-member attribute certificates are 560 placed in attrCert. The certification path is optional 561 because it may already be included elsewhere in the message 562 (e.g., in the outer CMS layer). 564 3.1.4 Delete GL Member 566 GLOs use glDeleteMember to request deletion of GL members and GL 567 members use glDeleteMember to request being removed from the GL. The 568 glDeleteMember message must be signed by either the GLO or the 569 prospective GL member. The glDeleteMember control attribute shall 570 have the syntax GLDeleteMember: 572 GLDeleteMember ::= SEQUENCE { 573 glName GeneralName, 574 glMemberToDelete GeneralName } 576 The fields in GLDeleteMembers have the following meaning: 578 - glName indicates the name of the GL from which the member should 579 be removed. 581 - glMemberToDelete indicates the name of the member to be deleted. 583 3.1.5 Rekey GL 585 GLOs use the glRekey to request a GL rekey. The glRekey message MUST 586 be signed by the GLO. The glRekey control attribute shall have the 587 syntax GLRekey: 589 GLRekey ::= SEQUENCE { 590 glName GeneralName, 591 glAdministration GLAdministration OPTIONAL, 592 glNewKeyAttributes GLNewKeyAttributes OPTIONAL, 593 glRekeyAllGLKeys BOOLEAN OPTIONAL } 595 GLNewKeyAttributes ::= SEQUENCE { 596 rekeyControlledByGLO [0] BOOLEAN OPTIONAL, 597 recipientsNotMutuallyAware [1] BOOLEAN OPTIONAL, 598 duration [2] INTEGER OPTIONAL, 599 generationCounter [3] INTEGER OPTIONAL, 600 requestedAlgorithm [4] AlgorithmIdentifier OPTIONAL } 602 The fields in GLRekey have the following meaning: 604 - glName indicates the name of the GL to be rekeyed. 606 - glAdministration indicates if there is any change to how the GL 607 should be administered. See section 3.1.1 for the three options. 608 This field is only included if there is a change from the 609 previously registered administered. 611 - glNewKeyAttributes indicates whether the rekey of the GLO is 612 controlled by the GLA or GL, what algorithm and parameters the 613 GLO wishes to use, the duration of the key, and how many 614 outstanding keys should be issued. The field is only included if 615 there is a change from the previously registered 616 glKeyAttributes. 618 - glRekeyAllGLKeys indicates whether the GLO wants all of the 619 outstanding GL�s shared KEKs rekeyed. If it is set to TRUE then 620 all outstanding KEKs MUST be issued. If it is set to FALSE then 621 all outstanding KEKs need not be resissued. 623 3.1.6 Add GL Owner 625 GLOs use the glAddOwner to request that a new GLO be allowed to 626 administer the GL. The glAddOwner message MUST be signed a 627 registered GLO. The glAddOwner control attribute shall have the 628 syntax GLOwnerAdministration: 630 GLOwnerAdministration ::= SEQUENCE { 631 glName GeneralName, 632 glOwnerInfo GLOwnerInfo } 634 The fields in GLAddOwners have the following meaning: 636 - glName indicates the name of the GL to which the new GLO should 637 be associated. 639 - glOwnerInfo indicates the name and address of the new GLO. 641 3.1.7 Remove GL Owner 643 GLOs use the glRemoveOwner to request that a GLO be disassociated 644 with the GL. The glRemoveOwner message MUST be signed by a 645 registered GLO. The glRemoveOwner control attribute shall have the 646 syntax GLOwnerAdministration: 648 GLOwnerAdministration ::= SEQUENCE { 649 glName GeneralName, 650 glOwnerInfo GLOwnerInfo } 652 The fields in GLRemoveOwners have the following meaning: 654 - glName indicates the name of the GL to which the GLO should be 655 disassociated. 657 - glOwnerInfo indicates the name and address of the GLO to be 658 removed. 660 3.1.8 GL Key Compromise 662 GL members and GLOs use glkCompromise to indicate that the shared 663 KEK possessed has been compromised. The glKeyCompromise control 664 attribute shall have the syntax GeneralName. The name of the GL to 665 which the compromised key is associated with is included in 666 GeneralName. This message is always redirected by the GLA to the GLO 667 for further action. The glkCompromise MUST NOT be included in an 668 EnvelopedData generated with the compromised shared KEK. 670 3.1.9 GL Key Refresh 672 GL members use the glkRefresh to request that the shared KEK be 673 redistributed to them. The glkRefresh control attribute shall have 674 the syntax GLKRefresh. 676 GLKRefresh ::= { 677 glName GeneralName, 678 dates SEQUENCE (1..MAX) OF Date } 680 Date ::= { 681 start GeneralizedTime, 682 end GeneralizedTime OPTIONAL } 684 The fields in GLKRefresh have the following meaning: 686 - glName indicates the name of the GL for which the GL member 687 wants shared KEKs. 689 - dates indicates a date range for keys the GL member wants. The 690 start field indicates the first date the GL member wants and the end 691 field indicates the last date. The end date MAY be omitted to 692 indicate the GL member wants all keys from the specified start date 693 to the current date. It should be noted that a procedural mechanism 694 will be needed to restrict users from accessing messages that they 695 are not allowed to access. 697 3.1.10 GL Success Information 699 The GLA uses glSuccessInfo to indicate a successful result of an 700 administrative message. A separate glSuccessInfo is returned for 701 each action (e.g., if there are four successful glAddMember requests 702 then four glSuccessInfo responses are generated). The glSuccessInfo 703 message MUST be signed by the GLA. The glSucessInfo control 704 attribute shall have the syntax GLSucessInfo: 706 GLSuccessInfo ::= SEQUENCE { 707 glInfo GLInfo, 708 glIdentifier GLIdentifier, 709 action Action } 711 Action ::= SEQUENCE { 712 actionCode ActionCode, 713 glMemberName [0] GeneralName OPTIONAL, 714 glOwnerName [1] GeneralName OPTIONAL } 715 ActionCode ::= INTEGER { 716 assignedKEK (0), 717 deletedGL (1), 718 addedMember (2), 719 deletedMember (3), 720 rekeyedGL (4), 721 addedGLO (5), 722 removedGLO (6) } 724 The fields in GLSuccessInfo have the following meaning: 726 - glInfo indicates the GL�s name in glName and the GL�s address in 727 glAddress. 729 - glIdentifier identifies GL�s unique shared KEK. 731 - action indicates the successfully performed action. 732 action.actionCode indicates whether the shared KEK was assigned 733 to the GL, whether the GL was deleted, whether a member was 734 added to a GL, whether a member was deleted from a GL, whether 735 the GL was rekeyed, whether a new GLO was added, and whether a 736 GLO was removed. If members were added to a GL or deleted from a 737 GL the members MUST be indicated in glMemberName and glOwnerName 738 MUST be omitted. If a GLO was added to a GL or deleted from a 739 GL, the GLO MUST be indicated in glOwnerName and glMemberName 740 MUST be omitted. If a shared KEK was assigned to a GL or a GL 741 was deleted both glOwnerName and glMemberName MUST be omitted. 743 3.1.11 GL Fail Information 745 The GLA uses glFailInfo to indicate that there was a problem 746 performing a requested action. A separate glFailInfo is returned for 747 each action (e.g., if there are four denied glAddMember requests 748 then four glFailInfo responses are generated). The glFailInfo 749 message MUST be signed by the GLA. The glFailInfo control attribute 750 shall have the syntax GLFailInfo: 752 GLFailInfo ::= SEQUENCE { 753 glName GeneralName, 754 error Error } 756 Error ::= SEQUENCE { 757 errorCode ErrorCode, 758 glMemberName [0] GeneralName OPTIONAL, 759 glOwnerName [1] GeneralName OPTIONAL } 760 ErrorCode ::= INTEGER { 761 unspecified (0), 762 closedGL (1) 763 unsupportedDuration (2) 764 noGLACertificate (3), 765 invalidCert (4), 766 unsupportedAlgorithm (5), 767 noGLONameMatch (6), 768 invalidGLName (7), 769 nameAlreadyInUse (8), 770 noSpam (9), 771 deniedAccess (10), 772 alreadyAMember (11), 773 notAMember (12), 774 alreadyAnOwner (13) 775 notAnOwner (14) } 777 The fields in GLFailInfo have the following meaning: 779 - glName indicates the name of the GL to which the error 780 corresponds. 782 - error indicates the reason why the GLA was unable to perform the 783 request. It also indicates the GL member or GLO to which the 784 error corresponds. If members were not added to a GL or deleted 785 from a GL the members MUST be indicated in glMemberName. If a 786 GLO was not added to a GL or deleted from a GL, the GLO MUST be 787 indicated in glOwnerName. The errors are returned under the 788 following conditions: 790 - unspecified indicates that the GLA is unable or unwilling to 791 perform the requested action and does not want to indicate 792 why. 794 - closedGL indicates that members can only be added or deleted 795 by the GLO. 797 - unsupportedDuration indicates the GLA does not support 798 generating keys that are valid for the requested duration. 800 - noGLACertificate indicates that the GLA does not have a valid 801 certificate. 803 - invalidCert indicates the member's encryption certificate was 804 not verifiable (i.e., signature did not validate, 805 certificate�s serial number present on a CRL, etc.). 807 - unsupportedAlgorithm indicates the GLA does not support the 808 requested algorithm. 810 - noGLONameMatch indicates that one of the names in the 811 certificate used to sign a request does not match the name of 812 a registered GLO. 814 - invalidGLName indicates the GLA does not support the glName 815 present in the request. 817 - nameAlreadyInUse indicates the glName is already assigned on 818 the GLA. 820 - noSpam indicates the prospective GL member did not sign the 821 request (i.e., if the name in glMember.glMemberName does not 822 match one of the names in the certificate used to sign the 823 request). 825 - alreadyAMember indicates the prospective GL member is already 826 a GL member. 828 - notAMember indicates the prospective non-GL member is not a GL 829 member. 831 - alreadyAnOwner indicates the prospective GLO is already a GLO. 833 - notAnOwner indicates the prospective non-GLO is not a GLO. 835 3.1.12 GLA Query Request 837 GLOs and GL members use the glaQueryRequest to ascertain information 838 about the GLA. The glaQueryRequest control attribute shall have the 839 syntax GLAQueryRequest: 841 GLAQueryRequest ::= SEQUENCE { 842 glaRequestType OBJECT IDENTIFIER, 843 glaRequestValue ANY DEFINED BY glaResponseType } 845 One request type is defined herein to support the GLO in determining 846 the algorithms supported by the GLA: 848 id-rt-algorithmSupported { id-tbd } 850 There is no value defined for id-rt-algorithmSupported. Including 851 the id-rt-algorithmSupport indicates that the GLO wishes to know the 852 algorithms that the GLA supports. 854 3.1.13 GLA Query Response 856 GLA�s return the glaQueryResponse after receiving a GLAQueryRequest. 857 The glaQueryResponse MUST be signed by a GLA. The glaQueryResponse 858 control attribute shall have the syntax GLAQueryResponse: 860 GLAQueryResponse ::= SEQUENCE { 861 glaResponseType OBJECT IDENTIFIER, 862 glaResponseValue ANY DEFINED BY glaResponseType } 864 One response type is defined herein for the GLA to indicate the 865 algorithms it supports: 867 smimeCapabilities OBJECT IDENTIFIER ::= 868 {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 15} 869 -- Identifies the algorithms supported by the GLA (see MsgSpec [5]) 871 3.1.14 Provide Cert 873 GLAs and GLOs use glProvideCert to request that a GL member provide 874 an updated or new encryption certificate. The glProvideCert message 875 MUST be signed by either GLA or GLO. If the GL member�s PKC has been 876 revoked, the GLO or GLA MUST NOT use it to generate the 877 EnvelopedData that encapsulates the glProvideCert request. The 878 glProvideCert control attribute shall have the syntax GLManageCert: 880 GLManageCert ::= SEQUENCE { 881 glName GeneralName, 882 glMember GLMember } 884 The fields in GLManageCert have the following meaning: 886 - glName indicates the name of the GL to which the GL member�s new 887 certificate should be associated. 889 - glMember indicates particulars for the GL member: 891 - glMemberName indicates the GL member�s name. 893 - glMemberAddress indicates the GL member�s address. It MAY be 894 omitted. 896 - certificates SHOULD be omitted. 898 3.1.15 Update Cert 900 GL members and GLOs use glUpdateCert to provide a new certificate 901 for the GL. GL members may generate a glUpdateCert unsolicited or as 902 a result of a glProvideCert message. GL members MUST sign the 903 glUpdateCert. If the GL member�s encryption certificate has been 904 revoked, the GL member MUST NOT use it to generate the EnvelopedData 905 that encapsulates the glUpdateCert request or response. The 906 glUpdateCert control attribute shall have the syntax GLManageCert: 908 GLManageCert ::= SEQUENCE { 909 glName GeneralName, 910 glMember GLMember } 912 The fields in GLManageCert have the following meaning: 914 - glName indicates the name of the GL to which the GL member�s new 915 certificate should be associated. 917 - glMember indicates the particulars for the GL member: 919 - glMemberName indicates the GL member�s name 921 - glMemberAddress indicates the GL member�s address. It MAY be 922 omitted. 924 - certificates MAY be omitted if the GLManageCert message is 925 sent to request the GL members certificate; else it MUST be 926 included. It includes the following three fields: 928 - certificates.pKC includes the member's encryption 929 certificate that will be used to encrypt the shared KEK for that 930 member. 932 - certificates.aC MAY be included to convey any attribute 933 certificate associated with the member�s encryption certificate. 935 - certificates.certificationPath MAY also be included to 936 convey the certification path corresponding to the member's 937 encryption and attribute certificates. The certification path is 938 optional because it may already be included elsewhere in the 939 message (e.g., in the outer CMS layer). 941 3.1.16 GL Key 943 The GLA uses glKey to distribute the shared KEK. The glKey message 944 MUST be signed by the GLA. The glKey control attribute shall have 945 the syntax GLKey: 947 GLKey ::= SEQUENCE { 948 glName GeneralName, 949 glIdentifier OCTET STRING, 950 glkWrapped RecipientInfos, -- See CMS [2] 951 glkAlgorithm AlgorithmIdentifier, 952 glkNotBefore GeneralizedTime, 953 glkNotAfter GeneralizedTime } 955 The fields in GLKey have the following meaning: 957 - glName is the name of the GL. 959 - glIdentifier is the key identifier of the shared KEK. When GL 960 members use the shared KEK to encrypt data objects for other GL 961 members, they place the glIdentifier in 962 RecipientInfo.kekri.kekid.keyIdentifier field. There are many 963 ways to do this here are two options are provided to generate a 964 unique key identifier. The first choice concatenates the GLA�s 965 subject name from the digital signature certificate used to sign 966 the glKey message and counter. The second choice concatenates 967 the GLA�s subjectKeyIdentifier, from the digital signature 968 certificate used to sign the glKey message, and a counter. 970 - glkWrapped is the GL's wrapped shared KEK. The RecipientInfos 971 shall be generated as specified in section 6.2 of CMS [2]. The 972 ktri RecipientInfo choice MUST be supported. The key in the 973 EncryptedKey field (i.e., the distributed shared KEK) MUST be 974 generated according to the section concerning random number 975 generation in the security considerations of CMS [2]. 977 - glkAlgorithm identifies the algorithm the shared KEK is used 978 with. The parameters are conveyed via the SMIMECapabilities 979 attribute see MSG {x}. 981 - glkNotBefore indicates the date at which the shared KEK is 982 considered valid. GeneralizedTime values MUST be expressed UTC 983 (Zulu) and MUST include seconds (i.e., times are 984 YYYYMMDDHHMMSSZ), even where the number of seconds is zero. 985 GeneralizedTime values MUST NOT include fractional seconds. 987 - glkNotAfter indicates the date after which the shared KEK is 988 considered invalid. GeneralizedTime values MUST be expressed UTC 989 (Zulu) and MUST include seconds (i.e., times are 990 YYYYMMDDHHMMSSZ), even where the number of seconds is zero. 991 GeneralizedTime values MUST NOT include fractional seconds. 993 If the glKey message is in response to a glUseKEK message: 995 - The GLA MUST generate separate glKey messages for each recipient 996 if glUseKEK.glKeyAttributes.recipientsNotMutuallyAware is set to 997 FALSE. For each recipient you want to generate a message that 998 contains that recipient�s key (i.e., one message with one 999 attribute). 1001 - The GLA MUST generate X number of glKey messages, where X is the 1002 value in glUseKEK.glKeyAttributes.generationCounter. 1004 If the glKey message is in response to a glRekey message: 1006 - The GLA MUST generate separate glKey messages for each recipient 1007 if glRekey.glNewKeyAttributes.recipientsNotMutuallyAware is set 1008 to FALSE. 1010 - The GLA MUST generate X number of glKey messages, where X is the 1011 value in glUseKEK.glKeyAttributes.generationCounter. 1013 - The GLA MUST generate X number of glKey messages, where X is the 1014 number of outstanding shared KEKs for the GL if glRekeyAllGLKeys 1015 is set to TRUE. 1017 If the glKey message was not in response to a glRekey or glUseKEK 1018 (e.g., where the GLA controls rekey): 1020 - The GLA MUST generate separate glKey messages for each recipient 1021 if glUseKEK.glNewKeyAttributes.recipientsNotMutuallyAware that 1022 set up the GL was set to FALSE. 1024 - The GLA MAY generate X glKey messages prior to the duration on 1025 the last outstanding shared KEK expiring, where X is the 1026 generationCounter minus one (1). Other distribution mechanisms 1027 may also be supported to support this functionality. 1029 3.2 Use of CMC, CMS, and PKIX 1031 The following sections outline the use of CMC, CMS, and PKIX. 1033 3.2.1 Protection Layers 1035 The following sections outline the protection required for the 1036 control attributes defined herein. 1038 3.2.1.1 Minimum Protection 1040 At a minimum, a SignedData MUST protect each request and response 1041 encapsulated in PKIData and PKIResponse. The following is a 1042 depiction of the minimum wrappings: 1044 Minimum Protection 1045 ------------------ 1046 SignedData 1047 PKIData or PKIResponse 1048 controlSequence 1050 Prior to taking any action on any request or response SignedData(s) 1051 MUST be processed according to CMS [2]. 1053 3.2.1.2 Additional Protection 1055 An additional EnvelopedData MAY also be used to provide 1056 confidentiality of the request and response. An additional 1057 SignedData MAY also be added to provide authentication and integrity 1058 of the encapsulated EnvelopedData. The following is a depiction of 1059 the optional additional wrappings: 1061 Confidentiality Protection A&I of Confidentiality Protection 1062 -------------------------- --------------------------------- 1063 EnvelopedData SignedData 1064 SignedData EnvelopedData 1065 PKIData or PKIResponse SignedData 1066 controlSequence PKIData or PKIResponse 1067 controlSequence 1069 If an incoming message was encrypted, the confidentiality of the 1070 message MUST be preserved. All EnvelopedData objects MUST be 1071 processed as specified in CMS [2]. 1073 If the GLO or GL member applies confidentiality to a request, the 1074 EnvelopedData MUST be encrypted for the GLA. If the GLA is to 1075 forward the GL member request to the GLO, the GLA decrypts the 1076 EnvelopedData, strips the confidentiality layer off, and applies its 1077 own confidentiality layer for the GLO. 1079 3.2.2 Combining Requests and Responses 1081 Multiple requests and response corresponding to a GL MAY be included 1082 in one PKIData.controlSequence or PKIResponse.controlSequence. 1083 Requests and responses for multiple GLs MAY be combined in one 1084 PKIData or PKIResponse by using PKIData.cmsSequence and 1085 PKIResponse.cmsSequence. A separate cmsSequence MUST be used for 1086 different GLs (i.e., requests corresponding to two different GLs are 1087 included in different cmsSequences). The following is a diagram 1088 depicting multiple requests and responses combined in one PKIData 1089 and PKIResponse: 1091 Multiple Request and Response 1092 Request Response 1093 ------- -------- 1094 SignedData SignedData 1095 PKIData PKIResponse 1096 cmsSequence cmsSequence 1097 SignedData SignedData 1098 PKIData PKIResponse 1099 controlSequence controlSequence 1100 One or more requests One or more responses 1101 corresponding to one GL. corresponding to one GL. 1102 SignedData SignedData 1103 PKIData PKIResponse 1104 controlSequence controlSequence 1105 One or more requests One or more responses 1106 corresponding to another GL. corresponding to another GL. 1108 When applying confidentiality to multiple requests and responses, 1109 all of the requests/response MAY be included in one EnvelopedData. 1110 The following is a depiction: 1112 Confidentiality of Multiple Requests and Responses 1113 Wrapped Together 1114 ---------------- 1115 EnvelopedData 1116 SignedData 1117 PKIData 1118 cmsSequence 1119 SignedData 1120 PKIResponse 1121 controlSequence 1122 Zero or more requests 1123 corresponding to one GL. 1124 SignedData 1125 PKIData 1126 controlSequence 1127 Zero or more requests 1128 corresponding to one GL. 1130 Certain combinations of requests in one PKIData.controlSequence and 1131 one PKIResponse.controlSequence are not allowed. The invalid 1132 combinations listed here MUST NOT be generated: 1134 Invalid Combinations 1135 --------------------------- 1136 glUseKEK & glDeleteMember 1137 glUseKEK & glRekey 1138 glUseKEK & glDelete 1139 glDelete & glAddMember 1140 glDelete & glDeleteMember 1141 glDelete & glRekey 1142 glDelete & glAddOwner 1143 glDelete & glRemoveOwner 1145 To avoid unnecessary errors, certain requests and responses should 1146 be processed prior to others. The following is the priority of 1147 message processing, if not listed it is an implementation decision 1148 as to which to process first: glUseKEK before glAddMember, glRekey 1149 before glAddMember, and glDeleteMember before glRekey. It should be 1150 noted that there is a priority but it does not imply an order. 1152 3.2.3 GLA Generated Messages 1154 When the GLA generates a glSuccessInfo, it generates one for each 1155 request. action.actionCode values of assignedKEK, deletedGL, 1156 rekeyedGL, addedGLO, and deletedGLO are not returned to GL members. 1157 Likewise, when the GLA generates glFailInfo it generates one each 1158 request. error values of unsupportedDuration, 1159 unsupportedDeliveryMethod, unsupportedAlgorithm, noGLONameMatch, 1160 nameAlreadyInUse, alreadyAnOwner, notAnOwner are not returned to GL 1161 members. 1163 If GLKeyAttributes.recipientsNotMutuallyAware is set to FALSE, a 1164 separate PKIResponse.glSucessInfo, PKIResponse.glFailInfo, and 1165 PKIData.glKey MUST be generated for each recipient. It is valid to 1166 send one message with multiple attributes to the same recipient. 1168 If the GL has multiple GLOs, the GLA MUST send the glSuccessInfo and 1169 glFailInfo messages to the requesting GLO. The mechanism to 1170 determine which GLO made the request is beyond the scope of this 1171 document. 1173 If a GL is managed and the GLA receives a glAddMember, 1174 glDeleteMember, or glkCompromise message, the GLA redirects the 1175 request to the GLO for review. An additional, SignedData MUST be 1176 applied to the redirected request as follows: 1178 GLA Forwarded Requests 1179 ---------------------- 1180 SignedData 1181 PKIData 1182 cmsSequence 1183 PKIData 1184 controlSequence 1186 3.2.4 CMC Control Attributes 1188 Certain control attributes defined in CMC [3] are allowed; they are 1189 as follows: cMCStatusInfo, transactionId, senderNonce, 1190 recipientNonce, and queryPending. 1192 cMCStatusInfo is used by GLAs to indicate to GLOs and GL members 1193 whether a request was or was not successfully completed. If the 1194 request was successful, the GLA returns a cMCStatusInfo response 1195 with cMCStatus.success and optionally other pertinent information in 1196 stutsString. If the response was not successful, the GLA returns a 1197 cMCStatusInfo response with cMCStatus.failed and optionally other 1198 pertinent information in statusString. 1200 When the GL is managed and the GLO has reviewed GL member initiated 1201 glAddMember, glDeleteMember, and glkComrpomise requests, the GLO 1202 uses cMCStatusInfo to indicate the success or failure of the 1203 request. If the request is allowed, cMCStatus.success is returned 1204 and statusString is optionally returned to convey additional 1205 information. If the request is denied, cMCStatus.failed is returned 1206 and statusString is optionally returned to convey additional 1207 information. 1209 cMCStatusInfo is used by GLOs, GLAs, and GL members to indicate that 1210 signature verification failed. If the signature failed to verify, 1211 the cMCStatusInfo control attribute MUST be returned indicating 1212 cMCStatus.failed and otherInfo.failInfo.badMessageCheck. If the 1213 signature over the outermost PKIData failed, the bodyList value is 1214 zero (0). If the signature over any other PKIData failed the 1215 bodyList value is the bodyPartId value from the request or response. 1217 cMCStatusInfo is also used by GLOs and GLAs to indicate that a 1218 request could not be performed immediately. If the request could not 1219 be processed immediately by the GLA or GLO, the cMCStatusInfo 1220 control attribute MUST be returned indicating cMCStatus.pending and 1221 otherInfo.pendInfo. When requests are redirected to the GLO for 1222 approval (for managed lists), the GLA MUST NOT return a 1223 cMCStatusInfo indicating query pending. 1225 cMCStatusInfo is also used by GLAs to indicate that a 1226 glaQueryRequest is not supported. If the glaQueryRequest is not 1227 supported, the cMCStatusInfo control attribute MUST be returned 1228 indicating cMCStatus.noSupport and statusString is optionally 1229 returned to convey additional information. 1231 transactionId MAY be included by GLOs, GLAs, or GL members to 1232 identify a given transaction. All subsequent requests and responses 1233 related to the original request MUST include the same transactionId 1234 control attribute. If GL members include a transactionId and the 1235 request is redirected to the GLO, the GLA MAY include an additional 1236 transactionId in the outer PKIData. If the GLA included an 1237 additional transactionId in the outer PKIData, when the GLO 1238 generates a cMCStatusInfo response it generates one for the GLA with 1239 the GLA�s transactionId and one for the GL member with the GL 1240 member�s transactionId. 1242 The use of nonces (see section 5.6 of [3]) can be used to provide 1243 application-level replay prevention. If the originating message 1244 includes a senderNonce, the response to the message MUST include the 1245 received senderNonce value as the recipientNonce and a new value as 1246 a the senderNonce value in the response. 1248 If a GLA aggratates multiple messages together or forwards a message 1249 to a GLO, the GLA can optionally generate a new nonce value and 1250 include that in the wrapping message. When the response comes back 1251 from the GLO, the GLA builds a response to the originator(s) of the 1252 message(s) and deals with each of the nonce values from the 1253 originating messages. 1255 The following is the implementation requirement for the CMC control 1256 attributes: 1258 Implementation Requirement | Control 1259 GLO | GLA | GL Member |Attribute 1260 O R | O R F | O R | 1261 --------- | ----------------- |--------- | ---------- 1262 MUST MUST | MUST MUST - | MUSTMUST | cMCStatus 1263 MAY MAY | MAY MAY - | MAY MAY | transactionId 1264 MAY MAY | MAY MAY - | MAY MAY | senderNonce 1265 MAY MAY | MAY MAY - | MAY MAY | recepientNonce 1267 3.2.5 Resubmitted GL Member Messages 1269 When the GL is managed, the GLA forwards the GL member requests to 1270 the GLO for GLO approval by creating a new request message 1271 containing the GL member request(s) as a cmsSequence item. If the 1272 GLO approves the request it can either add a new layer of wrapping 1273 and send it back to the GLA or create a new message sends it to the 1274 GLA. (Note in this case there are now 3 layers of PKIData messages 1275 with appropriate signing layers.) 1277 3.2.6 PKIX 1279 Signatures, certificates, and CRLs are verified according to PKIX 1280 [6]. 1282 Name matching is performed according to PKIX [6]. 1284 All distinguished name forms must follow the UTF8String convention 1285 noted in PKIX [6]. 1287 A certificate per-GL would be issued to the GLA. 1289 GL policy may mandate that the GL member�s address be included in 1290 the GL member�s certificate. 1292 4 Administrative Messages 1294 There are a number of administrative messages that must be performed 1295 to manage a GL. The following sections describe each of messages' 1296 request and response combinations in detail. The procedures defined 1297 in this section are not prescriptive. 1299 4.1 Assign KEK To GL 1301 Prior to generating a group key, a GL MUST be setup and a shared KEK 1302 assigned to the GL. Figure 3 depicts the protocol interactions to 1303 setup and assign a shared KEK. Note that error messages are not 1304 depicted in Figure 3. 1306 +-----+ 1 2 +-----+ 1307 | GLA | <-------> | GLO | 1308 +-----+ +-----+ 1310 Figure 3 - Create Group List 1312 The process is as follows: 1314 1 - The GLO is the entity responsible for requesting the creation 1315 of the GL. The GLO sends a 1316 SignedData.PKIData.controlSequence.glUseKEK request to the GLA 1317 (1 in Figure 3). The GLO MUST include: glName, glAddress, 1318 glOwnerName, glOwnerAddress, and glAdministration. The GLO MAY 1319 also include their preferences for the shared KEK in 1320 glKeyAttributes by indicating whether the GLO controls the 1321 rekey in rekeyControlledByGLO, whether separate glKey messages 1322 should be sent to each recipient in 1323 recipientsNotMutuallyAware, the requested algorithm to be used 1324 with the shared KEK in requestedAlgorithm, the duration of the 1325 shared KEK, and how many shared KEKs should be initially 1326 distributed in generationCounter. 1328 1.a - If the GLO knows of members to be added to the GL, the 1329 glAddMember request(s) MAY be included in the same 1330 controlSequence as the glUseKEK request (see section 3.2.2). 1331 The GLO MUST indicate the same glName in the glAddMember 1332 request as in glUseKEK.glInfo.glName. Further glAddMember 1333 procedures are covered in section 4.3. 1335 1.b - The GLO MAY optionally apply confidentiality to the request 1336 by encapsulating the SignedData.PKIData in an EnvelopedData 1337 (see section 3.2.1.2). 1339 1.c - The GLO MAY also optionally apply another SignedData over 1340 the EnvelopedData (see section 3.2.1.2). 1342 2 - Upon receipt of the request, the GLA verifies the signature on 1343 the inner most SignedData.PKIData. If an additional SignedData 1344 and/or EnvelopedData encapsulates the request (see sections 1345 3.2.1.2 and 3.2.2), the GLA MUST verify the outer signature(s) 1346 and/or decrypt the outer layer(S) prior to verifying the 1347 signature on the inner most SignedData. 1349 2.a - If the signatures do not verify, the GLA MUST return a 1350 cMCStatusInfo response indicating cMCStatus.failed and 1351 otherInfo.failInfo.badMessageCheck. 1353 2.b � Else if the signatures do verify but the GLA does not have a 1354 valid certificate, the GLA MUST return a 1355 glFailInfo.errorCode.noValidGLACertificate. Instead of 1356 immediately returning the error code, the GLA MAY attempt to 1357 get a certificate, possibly using CMC [3]. 1359 2.c - Else the signatures do verify and the GLA does have a valid 1360 certificate, the GLA MUST check that one of the names in the 1361 certificate used to sign the request matches one of the 1362 names in glUseKEK.glOwnerInfo.glOwnerName. 1364 2.c.1 - If the names do not match, the GLA MUST return a response 1365 indicating glFailInfo.errorCode.noGLONameMatch. 1367 2.c.2 - Else names do all match, the GLA MUST check that the 1368 glName and glAddress is not already in use. The GLA MUST 1369 also check any glAddMember included within the 1370 controlSequence with this glUseKEK. Further processing of 1371 the glAddMember is covered in section 4.3. 1373 2.c.2.a - If the glName is already in use the GLA MUST return a 1374 response indicating 1375 glFailInfo.errorCode.nameAlreadyInUse. 1377 2.c.2.b - Else the requestedAlgorithm is not supported, the GLA 1378 MUST return a response indicating 1379 glFailInfo.errorCode.unsupportedAlgorithm. 1381 2.c.2.c - Else the duration is not supportable, determining this 1382 is beyond the scope of this document, the GLA MUST 1383 return a response indicating 1384 glFailInfo.errorCode.unsupportedDuration. 1386 2.c.2.d - Else the GL is not supportable for other reasons, which 1387 the GLA does not wish to disclose, the GLA MUST return a 1388 response indicating glFailInfo.errorCode.unspecified. 1390 2.c.2.e - Else the glName is not already in use, the duration is 1391 supportable, and the requestedAlgorithm is supported, 1392 the GLA MUST return a glSuccessInfo indicating the 1393 glName, the corresponding glIdentifier, and an 1394 action.actionCode.assignedKEK (2 in Figure 3). The GLA 1395 also takes administrative actions, which are beyond the 1396 scope of this document, to store the glName, glAddress, 1397 glKeyAttributes, glOwnerName, and glOwnerAddress. The 1398 GLA also sends a glKey message as described in section 1399 5. 1401 2.c.2.e.1 - The GLA MUST apply confidentiality to the response by 1402 encapsulating the SignedData.PKIResponse in an 1403 EnvelopedData if the request was encapsulated in an 1404 EnvelopedData (see section 3.2.1.2). 1406 2.c.2.e.2 - The GLA MAY also optionally apply another SignedData 1407 over the EnvelopedData (see section 3.2.1.2). 1409 3 - Upon receipt of the glSuccessInfo or glFailInfo responses, the 1410 GLO verifies the GLA's signature(s). If an additional 1411 SignedData and/or EnvelopedData encapsulates the response (see 1412 section 3.2.1.2 or 3.2.2), the GLO MUST verify the outer 1413 signature and/or decrypt the outer layer prior to verifying 1414 the signature on the inner most SignedData. 1416 3.a - If the signatures do not verify, the GLO MUST return a 1417 cMCStatusInfo response indicating cMCStatus.failed and 1418 otherInfo.failInfo.badMessageCheck. 1420 3.b - Else the signatures do verify, the GLO MUST check that one 1421 of the names in the certificate used to sign the response 1422 matches the name of the GL. 1424 3.b.1 � If the GL�s name does not match the name present in the 1425 certificate used to sign the message, the GLO should not 1426 believe the response. 1428 3.b.2 � Else the GL�s name does match the name present in the 1429 certificate and: 1431 3.b.2.a - If the signatures do verify and the response was 1432 glSuccessInfo, the GLO has successfully created the GL. 1434 3.b.2.b - Else the signatures do verify and the response was 1435 glFailInfo, the GLO MAY reattempt to create the GL using 1436 the information provided in the glFailInfo response. The 1437 GLO may also use the glaQueryRequest to determine the 1438 algorithms and other characteristics supported by the GLA 1439 (see section 4.9). 1441 4.2 Delete GL From GLA 1443 From time to time, there are instances when a GL is no longer 1444 needed. In this case the GLO must delete the GL. Figure 4 depicts 1445 that protocol interactions to delete a GL. 1447 +-----+ 1 2 +-----+ 1448 | GLA | <-------> | GLO | 1449 +-----+ +-----+ 1451 Figure 4 - Delete Group List 1453 The process is as follows: 1455 1 - The GLO is the entity responsible for requesting the deletion 1456 of the GL. The GLO sends a 1457 SignedData.PKIData.controlSequence.glDelete request to the GLA 1458 (1 in Figure 4). The name of the GL to be deleted MUST be 1459 included in GeneralName. 1461 1.a - The GLO MAY optionally apply confidentiality to the request 1462 by encapsulating the SignedData.PKIData in an EnvelopedData 1463 (see section 3.2.1.2). 1465 1.b - The GLO MAY also optionally apply another SignedData over 1466 the EnvelopedData (see section 3.2.1.2). 1468 2 - Upon receipt of the request the GLA verifies the signature on 1469 the inner most SignedData.PKIData. If an additional SignedData 1470 and/or EnvelopedData encapsulates the request (see section 1471 3.2.1.2 or 3.2.2), the GLA MUST verify the outer signature 1472 and/or decrypt the outer layer prior to verifying the 1473 signature on the inner most SignedData. 1475 2.a - If the signatures do not verify, the GLA MUST return a 1476 cMCStatusInfo response indicating cMCStatus.failed and 1477 otherInfo.failInfo.badMessageCheck. 1479 2.b - Else the signatures do verify, the GLA MUST make sure the GL 1480 is supported by checking the GL�s Name matches a glName 1481 stored on the GLA. 1483 2.b.1 - If the glName is not supported by the GLA, the GLA MUST 1484 return a response indicating 1485 glFailInfo.errorCode.invalidGLName. 1487 2.b.2 - Else the glName is supported by the GLA, the GLA MUST 1488 ensure a registered GLO signed the glDelete request by 1489 checking if one of the names present in the digital 1490 signature certificate used to sign the glDelete request 1491 matches a registered GLO. 1493 2.b.2.a - If the names do not match, the GLA MUST return a 1494 response indicating glFailInfo.errorCode.noGLONameMatch. 1496 2.b.2.b - Else the names do match but the GL is not deletable for 1497 other reasons, which the GLA does not wish to disclose, 1498 the GLA MUST return a response indicating 1499 glFailInfo.errorCode.unspecified. Actions beyond the 1500 scope of this document must then be taken to delete the 1501 GL from the GLA. 1503 2.b.2.c - Else the names do match, the GLA MUST return a 1504 glSuccessInfo indicating the glName, and an 1505 action.actionCode.deletedGL (2 in Figure 4). 1506 glMemberName and glOwnerName MUST be omitted. The GLA 1507 MUST not accept further requests for member additions, 1508 member deletions, or group rekeys for this GL. 1510 2.b.2.c.1 - The GLA MUST apply confidentiality to the response by 1511 encapsulating the SignedData.PKIResponse in an 1512 EnvelopedData if the request was encapsulated in an 1513 EnvelopedData (see section 3.2.1.2). 1515 2.b.2.c.2 - The GLA MAY also optionally apply another SignedData 1516 over the EnvelopedData (see section 3.2.1.2). 1518 3 - Upon receipt of the glSuccessInfo or glFailInfo response, the 1519 GLO verifies the GLA's signature(s). If an additional 1520 SignedData and/or EnvelopedData encapsulates the response (see 1521 section 3.2.1.2 or 3.2.2), the GLO MUST verify the outer 1522 signature and/or decrypt the outer layer prior to verifying 1523 the signature on the inner most SignedData. 1525 3.a - If the signatures do not verify, the GLO MUST return a 1526 cMCStatusInfo response indicating cMCStatus.failed and 1527 otherInfo.failInfo.badMessageCheck. 1529 3.b - Else the signatures do verify, the GLO MUST check that one 1530 of the names in the certificate used to sign the response 1531 matches the name of the GL. 1533 3.b.1 � If the GL�s name does not match the name present in the 1534 certificate used to sign the message, the GLO should not 1535 believe the response. 1537 3.b.2 � Else the GL�s name does match the name present in the 1538 certificate and: 1540 3.b.2.a - If the signatures do verify and the response was 1541 glSuccessInfo, the GLO has successfully deleted the GL. 1543 3.b.2.b - Else the signatures do verify and the response was 1544 glFailInfo, the GLO MAY reattempt to delete the GL using 1545 the information provided in the glFailInfo response. 1547 4.3 Add Members To GL 1549 To add members to GLs, either the GLO or prospective members use the 1550 glAddMember request. The GLA processes GLO and prospective GL member 1551 requests differently though. GLOs can submit the request at any time 1552 to add members to the GL, and the GLA, once it has verified the 1553 request came from a registered GLO, should process it. If a 1554 prospective member sends the request, the GLA needs to determine how 1555 the GL is administered. When the GLO initially configured the GL, 1556 they set the GL to be unmanaged, managed, or closed (see section 1557 3.1.1). In the unmanaged case, the GLA merely processes the member�s 1558 request. For the managed case, the GLA forwards the requests from 1559 the prospective members to the GLO for review. Where there are 1560 multiple GLOs for a GL, which GLO the request is forwarded to is 1561 beyond the scope of this document. The GLO reviews the request and 1562 either rejects it or submits a reformed request to the GLA. In the 1563 closed case, the GLA will not accept requests from prospective 1564 members. The following sections describe the processing for the 1565 GLO(s), GLA, and prospective GL members depending on where the 1566 glAddMeber request originated, either from a GLO or from prospective 1567 members. Figure 5 depicts the protocol interactions for the three 1568 options. Note that the error messages are not depicted. 1570 +-----+ 2,B{A} 3 +----------+ 1571 | GLO | <--------+ +-------> | Member 1 | 1572 +-----+ | | +----------+ 1573 1 | | 1574 +-----+ <--------+ | 3 +----------+ 1575 | GLA | A +-------> | ... | 1576 +-----+ <-------------+ +----------+ 1577 | 1578 | 3 +----------+ 1579 +-------> | Member n | 1580 +----------+ 1582 Figure 5 - Member Addition 1584 An important decision that needs to be made on a group by group 1585 basis is whether to rekey the group every time a new member is 1586 added. Typically, unmanaged GLs should not be rekeyed when a new 1587 member is added, as the overhead associated with rekeying the group 1588 becomes prohibitive, as the group becomes large. However, managed 1589 and closed GLs MAY be rekeyed to maintain the secrecy of the group. 1590 An option to rekeying managed or closed GLs when a member is added 1591 is to generate a new GL with a different group key. Group rekeying 1592 is discussed in sections 4.5 and 5. 1594 4.3.1 GLO Initiated Additions 1596 The process for GLO initiated glAddMember requests is as follows: 1598 1 - The GLO collects the pertinent information for the member(s) 1599 to be added (this may be done through an out of bands means). 1600 The GLO then sends a SignedData.PKIData.controlSequence with a 1601 separate glAddMember request for each member to the GLA (1 in 1602 Figure 5). The GLO MUST include: the GL name in glName, the 1603 member's name in glMember.glMemberName, the member�s address 1604 in glMember.glMemberAddress, and the member's encryption 1605 certificate in glMember.certificates.pKC. The GLO MAY also 1606 include any attribute certificates associated with the 1607 member�s encryption certificate in glMember.certificates.aC, 1608 and the certification path associated with the member�s 1609 encryption and attribute certificates in 1610 glMember.certificates.certificationPath. 1612 1.a - The GLO MAY optionally apply confidentiality to the request 1613 by encapsulating the SignedData.PKIData in an EnvelopedData 1614 (see section 3.2.1.2). 1616 1.b - The GLO MAY also optionally apply another SignedData over 1617 the EnvelopedData (see section 3.2.1.2). 1619 2 - Upon receipt of the request, the GLA verifies the signature on 1620 the inner most SignedData.PKIData. If an additional SignedData 1621 and/or EnvelopedData encapsulates the request (see section 1622 3.2.1.2 or 3.2.2), the GLA MUST verify the outer signature 1623 and/or decrypt the outer layer prior to verifying the 1624 signature on the inner most SignedData. 1626 2.a - If the signatures do not verify, the GLA MUST return a 1627 cMCStatusInfo response indicating cMCStatus.failed and 1628 otherInfo.failInfo.badMessageCheck. 1630 2.b - Else the signatures do verify, the glAddMember request is 1631 included in a controlSequence with the glUseKEK request, and 1632 the processing in section 4.1 item 2.e is successfully 1633 completed the GLA MUST return a glSuccessInfo indicating the 1634 glName, the corresponding glIdentifier, an 1635 action.actionCode.addedMember, and action.glMemberName (2 in 1636 Figure 5). 1638 2.b.1 - The GLA MUST apply confidentiality to the response by 1639 encapsulating the SignedData.PKIData in an EnvelopedData 1640 if the request was encapsulated in an EnvelopedData (see 1641 section 3.2.1.2). 1643 2.b.2 - The GLA MAY also optionally apply another SignedData over 1644 the EnvelopedData (see section 3.2.1.2). 1646 2.c - Else the signatures do verify and the GLAddMember request is 1647 not included in a controlSequence with the GLCreate request, 1648 the GLA MUST make sure the GL is supported by checking that 1649 the glName matches a glName stored on the GLA. 1651 2.c.1 - If the glName is not supported by the GLA, the GLA MUST 1652 return a response indicating 1653 glFailInfo.errorCode.invalidGLName. 1655 2.c.2 - Else the glName is supported by the GLA, the GLA MUST 1656 check to see if the glMemberName is present on the GL. 1658 2.c.2.a - If the glMemberName is present on the GL, the GLA MUST 1659 return a response indicating 1660 glFailInfo.errorCode.alreadyAMember. 1662 2.c.2.b - Else the glMemberName is not present on the GL, the GLA 1663 MUST check how the GL is administered. 1665 2.c.2.b.1 - If the GL is closed, the GLA MUST check that a 1666 registered GLO signed the request by checking that one 1667 of the names in the digital signature certificate used 1668 to sign the request matches a registered GLO. 1670 2.c.2.b.1.a - If the names do not match, the GLA MUST return a 1671 response indicating 1672 glFailInfo.errorCode.noGLONameMatch. 1674 2.c.2.b.1.b - Else the names do match, the GLA MUST verify the 1675 member's encryption certificate. 1677 2.c.2.b.1.b.1 - If the member's encryption certificate does not 1678 verify, the GLA MAY return a response indicating 1679 glFailInfo.errorCode.invalidCert to the GLO. If 1680 the GLA does not return a glFailInfo response, the 1681 GLA MUST issue a glProvideCert request (see 1682 section 4.10). 1684 2.c.2.b.1.b.2 - Else the member's certificate does verify, the GLA 1685 MUST return a glSuccessInfo to the GLO indicating 1686 the glName, the corresponding glIdentifier, an 1687 action.actionCode.addedMember, and 1688 action.glMemberName (2 in Figure 5). The GLA also 1689 takes administrative actions, which are beyond the 1690 scope of this document, to add the member to the 1691 GL stored on the GLA. The GLA MUST also distribute 1692 the shared KEK to the member via the mechanism 1693 described in section 5. 1695 2.c.2.b.1.b.2.a - The GLA MUST apply confidentiality to the 1696 response by encapsulating the SignedData.PKIData 1697 in an EnvelopedData if the request was 1698 encapsulated in an EnvelopedData (see section 1699 3.2.1.2). 1701 2.c.2.b.1.b.2.b - The GLA MAY also optionally apply another 1702 SignedData over the EnvelopedData (see section 1703 3.2.1.2). 1705 2.c.2.b.2 - Else the GL is managed, the GLA MUST check that either 1706 a registered GLO or the prospective member signed the 1707 request. For GLOs, one of the names in the certificate 1708 used to sign the request MUST match a registered GLO. 1709 For the prospective member, the name in 1710 glMember.glMemberName MUST match one of the names in 1711 the certificate used to sign the request. 1713 2.c.2.b.2.a - If the signer is neither a registered GLO nor the 1714 prospective GL member, the GLA MUST return a 1715 response indicating glFailInfo.errorCode.noSpam. 1717 2.c.2.b.2.b - Else the signer is a registered GLO, the GLA MUST 1718 verify the member's encryption certificate. 1720 2.c.2.b.2.b.1 - If the member's certificate does not verify, the 1721 GLA MAY return a response indicating 1722 glFailInfo.errorCode.invalidCert. If the GLA does 1723 not return a glFailInfo response, the GLA MUST 1724 issue a glProvideCert request (see section 4.10). 1726 2.c.2.b.2.b.2 - Else the member's certificate does verify, the GLA 1727 MUST return glSuccessInfo indicating the glName, 1728 the corresponding glIdentifier, an 1729 action.actionCode.addedMember, and 1730 action.glMemberName to the GLO (2 in Figure 5). 1731 The GLA also takes administrative actions, which 1732 are beyond the scope of this document, to add the 1733 member to the GL stored on the GLA. The GLA MUST 1734 also distribute the shared KEK to the member via 1735 the mechanism described in section 5. The GL 1736 policy may mandate that the GL member�s address be 1737 included in the GL member�s certificate. 1739 2.c.2.b.2.b.2.a - The GLA MUST apply confidentiality to the 1740 response by encapsulating the SignedData.PKIData 1741 in an EnvelopedData if the request was 1742 encapsulated in an EnvelopedData (see section 1743 3.2.1.2). 1745 2.c.2.b.2.b.2.b - The GLA MAY also optionally apply another 1746 SignedData over the EnvelopedData (see section 1747 3.2.1.2). 1749 2.c.2.b.2.c - Else the signer is the prospective member, the GLA 1750 MUST forward the glAddMember request (see section 1751 3.2.3) to a registered GLO (B{A} in Figure 5). If 1752 there is more than one registered GLO, the GLO to 1753 which the request is forwarded to is beyond the 1754 scope of this document. Further processing of the 1755 forwarded request by GLOs is addressed in 3 of 1756 section 4.3.2. 1758 2.c.2.b.2.c.1 - The GLA MUST apply confidentiality to the 1759 forwarded request by encapsulating the 1760 SignedData.PKIData in an EnvelopedData if the 1761 original request was encapsulated in an 1762 EnvelopedData (see section 3.2.1.2). 1764 2.c.2.b.2.c.2 - The GLA MAY also optionally apply another 1765 SignedData over the EnvelopedData (see section 1766 3.2.1.2). 1768 2.c.2.b.3 - Else the GL is unmanaged, the GLA MUST check that 1769 either a registered GLO or the prospective member 1770 signed the request. For GLOs, one of the names in the 1771 certificate used to sign the request MUST match the 1772 name of a registered GLO. For the prospective member, 1773 the name in glMember.glMemberName MUST match one of 1774 the names in the certificate used to sign the request. 1776 2.c.2.b.3.a - If the signer is neither a registered GLO nor the 1777 prospective member, the GLA MUST return a response 1778 indicating glFailInfo.errorCode.noSpam. 1780 2.c.2.b.3.b - Else the signer is either a registered GLO or the 1781 prospective member, the GLA MUST verify the member's 1782 encryption certificate. 1784 2.c.2.b.3.b.1 - If the member's certificate does not verify, the 1785 GLA MAY return a response indicating 1786 glFailInfo.errorCode.invalidCert to either the GLO 1787 or the prospective member depending on where the 1788 request originated. If the GLA does not return a 1789 glFailInfo response, the GLA MUST issue a 1790 glProvideCert request (see section 4.10) to either 1791 the GLO or prospective member depending on where 1792 the request originated. 1794 2.c.2.b.3.b.2 - Else the member's certificate does verify, the GLA 1795 MUST return a glSuccessInfo indicating the glName, 1796 the corresponding glIdentifier, an 1797 action.actionCode.addedMember, and 1798 action.glMemberName to the GLO (2 in Figure 5) if 1799 the GLO signed the request and to the GL member (3 1800 in Figure 5) if the GL member signed the request. 1801 The GLA also takes administrative actions, which 1802 are beyond the scope of this document, to add the 1803 member to the GL stored on the GLA. The GLA MUST 1804 also distribute the shared KEK to the member via 1805 the mechanism described in section 5. 1807 2.c.2.b.3.b.2.a - The GLA MUST apply confidentiality to the 1808 response by encapsulating the SignedData.PKIData 1809 in an EnvelopedData if the request was 1810 encapsulated in an EnvelopedData (see section 1811 3.2.1.2). 1813 2.c.2.b.3.b.2.b - The GLA MAY also optionally apply another 1814 SignedData over the EnvelopedData (see section 1815 3.2.1.2). 1817 3 - Upon receipt of the glSuccessInfo or glFailInfo response, the 1818 GLO verifies the GLA's signature(s). If an additional 1819 SignedData and/or EnvelopedData encapsulates the response (see 1820 section 3.2.1.2 or 3.2.2), the GLO MUST verify the outer 1821 signature and/or decrypt the outer layer prior to verifying 1822 the signature on the inner most SignedData. 1824 3.a - If the signatures do not verify, the GLO MUST return a 1825 cMCStatusInfo response indicating cMCStatus.failed and 1826 otherInfo.failInfo.badMessageCheck. 1828 3.b - Else the signatures do verify, the GLO MUST check that one 1829 of the names in the certificate used to sign the response 1830 matches the name of the GL. 1832 3.b.1 � If the GL�s name does not match the name present in the 1833 certificate used to sign the message, the GLO should not 1834 believe the response. 1836 3.b.2 � Else the GL�s name does match the name present in the 1837 certificate and: 1839 3.b.2.a - If the signatures do verify and the response is 1840 glSuccessInfo, the GLO has added the member to the GL. If 1841 member was added to a managed list and the original 1842 request was signed by the member, the GLO MUST send a 1843 cMCStatusInfo.cMCStatus.success to the GL member. 1845 3.b.2.b - Else the GLO received a glFailInfo, for any reason, the 1846 GLO MAY reattempt to add the member to the GL using the 1847 information provided in the glFailInfo response. 1849 4 - Upon receipt of the glSuccessInfo, glFailInfo, or cMCStatus 1850 response, the prospective member verifies the GLA's signatures 1851 or GLO�s signatures. If an additional SignedData and/or 1852 EnvelopedData encapsulates the response (see section 3.2.1.2 1853 or 3.2.2), the GLO MUST verify the outer signature and/or 1854 decrypt the outer layer prior to verifying the signature on 1855 the inner most SignedData. 1857 4.a - If the signatures do not verify, the prospective member MUST 1858 return a cMCStatusInfo response indicating cMCStatus.failed 1859 and otherInfo.failInfo.badMessageCheck. 1861 4.b - Else the signatures do verify, the GL member MUST check that 1862 one of the names in the certificate used to sign the 1863 response matches the name of the GL. 1865 4.b.1 � If the GL�s name does not match the name present in the 1866 certificate used to sign the message, the GL member should 1867 not believe the response. 1869 4.b.2 � Else the GL�s name does match the name present in the 1870 certificate and: 1872 4.b.2.a - If the signatures do verify, the prospective member has 1873 been added to the GL. 1875 4.b.2.b - Else the prospective member received a glFailInfo, for 1876 any reason, the prospective member MAY reattempt to add 1877 themselves to the GL using the information provided in the 1878 glFailInfo response. 1880 4.3.2 Prospective Member Initiated Additions 1882 The process for prospective member initiated glAddMember requests is 1883 as follows: 1885 1 - The prospective GL member sends a 1886 SignedData.PKIData.controlSequence.glAddMember request to the 1887 GLA (A in Figure 5). The prospective GL member MUST include: 1888 the GL name in glName, their name in glMember.glMemberName, 1889 their address in glMember.glMemberAddress, and their 1890 encryption certificate in glMember.certificates.pKC. The 1891 prospective GL member MAY also include any attribute 1892 certificates associated with their encryption certificate in 1893 glMember.certificates.aC, and the certification path 1894 associated with their encryption and attribute certificates in 1895 glMember.certificates.certificationPath. 1897 1.a - The prospective GL member MAY optionally apply 1898 confidentiality to the request by encapsulating the 1899 SignedData.PKIData in an EnvelopedData (see section 1900 3.2.1.2). 1902 1.b - The prospective GL member MAY also optionally apply another 1903 SignedData over the EnvelopedData (see section 3.2.1.2). 1905 2 - Upon receipt of the request, the GLA verifies the request as 1906 per 2 in section 4.3.1. 1908 3 - Upon receipt of the forwarded request, the GLO verifies the 1909 prospective GL member�s signature on the inner most 1910 SignedData.PKIData and the GLA�s signature on the outer layer. 1911 If an EnvelopedData encapsulates the inner most layer (see 1912 section 3.2.1.2 or 3.2.2), the GLO MUST decrypt the outer 1913 layer prior to verifying the signature on the inner most 1914 SignedData. 1916 Note: For cases where the GL is closed and either a) a 1917 prospective member sends directly to the GLO or b) the GLA has 1918 mistakenly forwarded the request to the GLO, the GLO should 1919 first determine whether to honor the request. 1921 3.a - If the signatures do not verify, the GLO MUST return a 1922 cMCStatusInfo response indicating cMCStatus.failed and 1923 otherInfo.failInfo.badMessageCheck. 1925 3.b - Else the signatures do verify, the GLO MUST check to make 1926 sure one of the names in the certificate used to sign the 1927 request matches the name in glMember.glMemberName. 1929 3.b.1 - If the names do not match, the GLO MAY send a 1930 SignedData.PKIResponse.controlSequence message back to the 1931 prospective member with cMCStatusInfo.cMCStatus.failed 1932 indicating why the prospective member was denied in 1933 cMCStausInfo.statusString. This stops people from adding 1934 people to GLs without their permission. 1936 3.b.2 - Else the names do match, the GLO determines whether the 1937 prospective member is allowed to be added. The mechanism 1938 is beyond the scope of this document; however, the GLO 1939 should check to see that the glMember.glMemberName is not 1940 already on the GL. 1942 3.b.2.a - If the GLO determines the prospective member is not 1943 allowed to join the GL, the GLO MAY return a 1944 SignedData.PKIResponse.controlSequence message back to 1945 the prospective member with 1946 cMCStatusInfo.cMCtatus.failed indicating why the 1947 prospective member was denied in cMCStatus.statusString. 1949 3.b.2.b - Else GLO determines the prospective member is allowed to 1950 join the GL, the GLO MUST verify the member's encryption 1951 certificate. 1953 3.b.2.b.1 - If the member's certificate does not verify, the GLO 1954 MAY return a SignedData.PKIResponse.controlSequence 1955 back to the prospective member with 1956 cMCStatusInfo.cMCtatus.failed indicating that the 1957 member�s encryption certificate did not verify in 1958 cMCStatus.statusString. If the GLO does not return a 1959 cMCStatusInfo response, the GLO MUST send a 1960 SignedData.PKIData.controlSequence.glProvideCert 1961 message to the prospective member requesting a new 1962 encryption certificate (see section 4.10). 1964 3.b.2.b.2 - Else the member's certificate does verify, the GLO 1965 resubmits the glAddMember request (see section 3.2.5) 1966 to the GLA (1 in Figure 5). 1968 3.b.2.b.2.a - The GLO MUST apply confidentiality to the new 1969 GLAddMember request by encapsulating the 1970 SignedData.PKIData in an EnvelopedData if the 1971 initial request was encapsulated in an EnvelopedData 1972 (see section 3.2.1.2). 1974 3.b.2.b.2.b - The GLO MAY also optionally apply another SignedData 1975 over the EnvelopedData (see section 3.2.1.2). 1977 4 - Processing continues as in 2 of section 4.3.1. 1979 4.4 Delete Members From GL 1981 To delete members from GLs, either the GLO or prospective non- 1982 members use the glDeleteMember request. The GLA processes GLO and 1983 prospective non-GL member requests differently. The GLO can submit 1984 the request at any time to delete members from the GL, and the GLA, 1985 once it has verified the request came from a registered GLO, should 1986 delete the member. If a prospective member sends the request, the 1987 GLA needs to determine how the GL is administered. When the GLO 1988 initially configured the GL, they set the GL to be unmanaged, 1989 managed, or closed (see section 3.1.1). In the unmanaged case, the 1990 GLA merely processes the member�s request. For the managed case, the 1991 GLA forwards the requests from the prospective members to the GLO 1992 for review. Where there are multiple GLOs for a GL, which GLO the 1993 request is forwarded to is beyond the scope of this document. The 1994 GLO reviews the request and either rejects it or submits a reformed 1995 request to the GLA. In the closed case, the GLA will not accept 1996 requests from prospective members. The following sections describe 1997 the processing for the GLO(s), GLA, and GL members depending on 1998 where the request originated, either from a GLO or from prospective 1999 non-members. Figure 6 depicts the protocol interactions for the 2000 three options. Note that the error messages are not depicted. 2002 +-----+ 2,B{A} 3 +----------+ 2003 | GLO | <--------+ +-------> | Member 1 | 2004 +-----+ | | +----------+ 2005 1 | | 2006 +-----+ <--------+ | 3 +----------+ 2007 | GLA | A +-------> | ... | 2008 +-----+ <-------------+ +----------+ 2009 | 2010 | 3 +----------+ 2011 +-------> | Member n | 2012 +----------+ 2014 Figure 6 - Member Deletion 2016 If the member is not removed from the GL, they will continue to 2017 receive and be able to decrypt data protected with the shared KEK 2018 and will continue to receive rekeys. For unmanaged lists, there is 2019 no point to a group rekey because there is no guarantee that the 2020 member requesting to be removed has not already added themselves 2021 back on the GL under a different name. For managed and closed GLs, 2022 the GLO MUST take steps to ensure the member being deleted is not on 2023 the GL twice. After ensuring this, managed and closed GLs MUST be 2024 rekeyed to maintain the secrecy of the group. If the GLO is sure the 2025 member has been deleted the group rekey mechanism MUST be used to 2026 distribute the new key (see sections 4.5 and 5). 2028 4.4.1 GLO Initiated Deletions 2030 The process for GLO initiated glDeleteMember requests is as follows: 2032 1 - The GLO collects the pertinent information for the member(s) 2033 to be deleted (this MAY be done through an out of bands 2034 means). The GLO then sends a 2035 SignedData.PKIData.controlSequence with a separate 2036 glDeleteMember request for each member to the GLA (1 in Figure 2037 6). The GLO MUST include: the GL name in glName and the 2038 member's name in glMemberToDelete. If the GL from which the 2039 member is being deleted in a closed or managed GL, the GLO 2040 MUST also generate a glRekey request and include it with the 2041 glDeletemember request (see section 4.5). 2043 1.a - The GLO MAY optionally apply confidentiality to the request 2044 by encapsulating the SignedData.PKIData in an EnvelopedData 2045 (see section 3.2.1.2). 2047 1.b - The GLO MAY also optionally apply another SignedData over 2048 the EnvelopedData (see section 3.2.1.2). 2050 2 - Upon receipt of the request, the GLA verifies the signature on 2051 the inner most SignedData.PKIData. If an additional SignedData 2052 and/or EnvelopedData encapsulates the request (see section 2053 3.2.1.2 or 3.2.2), the GLA MUST verify the outer signature 2054 and/or decrypt the outer layer prior to verifying the 2055 signature on the inner most SignedData. 2057 2.a - If the signatures do not verify, the GLA MUST return a 2058 cMCStatusInfo response indicating cMCStatus.failed and 2059 otherInfo.failInfo.badMessageCheck. 2061 2.b - Else the signatures do verify, the GLA MUST make sure the GL 2062 is supported by the GLA by checking that the glName matches 2063 a glName stored on the GLA. 2065 2.b.1 - If the glName is not supported by the GLA, the GLA MUST 2066 return a response indicating 2067 glFailInfo.errorCode.invalidGLName. 2069 2.b.2 - Else the glName is supported by the GLA, the GLA MUST 2070 check to see if the glMemberName is present on the GL. 2072 2.b.2.a - If the glMemberName is not present on the GL, the GLA 2073 MUST return a response indicating 2074 glFailInfo.errorCode.notAMember. 2076 2.b.2.b - Else the glMemberName is already on the GL, the GLA MUST 2077 check how the GL is administered. 2079 2.b.2.b.1 - If the GL is closed, the GLA MUST check that the 2080 registered GLO signed the request by checking that one 2081 of the names in the digital signature certificate used 2082 to sign the request matches the registered GLO. 2084 2.b.2.b.1.a - If the names do not match, the GLA MUST return a 2085 response indicating glFailInfo.errorCode.closed. 2087 2.b.2.b.1.b - Else the names do match, the GLA MUST return a 2088 glSuccessInfo indicating the glName, the 2089 corresponding glIdentifier, an 2090 action.actionCode.deletedMember, and 2091 action.glMemberName (2 in Figure 5). The GLA also 2092 takes administrative actions, which are beyond the 2093 scope of this document, to delete the member with 2094 the GL stored on the GLA. Note that he GL MUST also 2095 be rekeyed as described in section 5. 2097 2.b.2.b.1.b.1 - The GLA MUST apply confidentiality to the response 2098 by encapsulating the SignedData.PKIData in an 2099 EnvelopedData if the request was encapsulated in 2100 an EnvelopedData (see section 3.2.1.2). 2102 2.b.2.b.1.b.2 - The GLA MAY also optionally apply another 2103 SignedData over the EnvelopedData (see section 2104 3.2.1.2). 2106 2.b.2.b.2 - Else the GL is managed, the GLA MUST check that either 2107 a registered GLO or the prospective member signed the 2108 request. For GLOs, one of the names in the certificate 2109 used to sign the request MUST match a registered GLO. 2110 For the prospective member, the name in 2111 glMember.glMemberName MUST match one of the names in 2112 the certificate used to sign the request. 2114 2.b.2.b.2.a - If the signer is neither a registered GLO nor the 2115 prospective GL member, the GLA MUST return a 2116 response indicating glFailInfo.errorCode.noSpam. 2118 2.b.2.b.2.b - Else the signer is a registered GLO, the GLA MUST 2119 return a glSuccessInfo to the GLO indicating the 2120 glName, the corresponding glIdentifier, an 2121 action.actionCode.deletedMember, and 2122 action.glMemberName (2 in Figure 6). The GLA also 2123 takes administrative actions, which are beyond the 2124 scope of this document, to delete the member with 2125 the GL stored on the GLA. Note that the GL will also 2126 be rekeyed as described in section 5. 2128 2.b.2.b.2.b.1 - The GLA MUST apply confidentiality to the response 2129 by encapsulating the SignedData.PKIData in an 2130 EnvelopedData if the request was encapsulated in 2131 an EnvelopedData (see section 3.2.1.2). 2133 2.b.2.b.2.b.2 - The GLA MAY also optionally apply another 2134 SignedData over the EnvelopedData (see section 2135 3.2.1.2). 2137 2.b.2.b.2.c - Else the signer is the prospective member, the GLA 2138 forwards the glDeleteMember request (see section 2139 3.2.3) to the GLO (B{A} in Figure 6). If there is 2140 more than one registered GLO, the GLO to which the 2141 request is forwarded to is beyond the scope of this 2142 document. Further processing of the forwarded 2143 request by GLOs is addressed in 3 of section 4.4.2. 2145 2.b.2.b.2.c.1 - The GLA MUST apply confidentiality to the 2146 forwarded request by encapsulating the 2147 SignedData.PKIData in an EnvelopedData if the 2148 request was encapsulated in an EnvelopedData (see 2149 section 3.2.1.2). 2151 2.b.2.b.2.c.2 - The GLA MAY also optionally apply another 2152 SignedData over the EnvelopedData (see section 2153 3.2.1.2). 2155 2.b.2.b.3 - Else the GL is unmanaged, the GLA MUST check that 2156 either a registered GLO or the prospective member 2157 signed the request. For GLOs, one of the names in the 2158 certificate used to sign the request MUST match the 2159 name of a registered GLO. For the prospective member, 2160 the name in glMember.glMemberName MUST match one of 2161 the names in the certificate used to sign the request. 2163 2.b.2.b.3.a - If the signer is neither the GLO nor the prospective 2164 member, the GLA MUST return a response indicating 2165 glFailInfo.errorCode.noSpam. 2167 2.b.2.b.3.b - Else the signer is either a registered GLO or the 2168 member, the GLA MUST return a glSuccessInfo 2169 indicating the glName, the corresponding 2170 glIdentifier, an action.actionCode.deletedMember, 2171 and action.glMemberName to the GLO (2 in Figure 6) 2172 if the GLO signed the request and to the GL member 2173 (3 in Figure 6) if the GL member signed the request. 2174 The GLA also takes administrative actions, which are 2175 beyond the scope of this document, to delete the 2176 member with the GL stored on the GLA. 2178 2.b.2.b.3.b.1 - The GLA MUST apply confidentiality to the response 2179 by encapsulating the SignedData.PKIData in an 2180 EnvelopedData if the request was encapsulated in 2181 an EnvelopedData (see section 3.2.1.2). 2183 2.b.2.b.3.b.2 - The GLA MAY also optionally apply another 2184 SignedData over the EnvelopedData (see section 2185 3.2.1.2). 2187 3 - Upon receipt of the glSuccessInfo or glFailInfo response, the 2188 GLO verifies the GLA's signatures. If an additional SignedData 2189 and/or EnvelopedData encapsulates the response (see section 2190 3.2.1.2 or 3.2.2), the GLO MUST verify the outer signature 2191 and/or decrypt the outer layer prior to verifying the 2192 signature on the inner most SignedData. 2194 3.a - If the signatures do not verify, the GLO MUST return a 2195 cMCStatusInfo response indicating cMCStatus.failed and 2196 otherInfo.failInfo.badMessageCheck. 2198 3.b - Else the signatures do verify, the GLO MUST check that one 2199 of the names in the certificate used to sign the response 2200 matches the name of the GL. 2202 3.b.1 � If the GL�s name does not match the name present in the 2203 certificate used to sign the message, the GLO should not 2204 believe the response. 2206 3.b.2 � Else the GL�s name does match the name present in the 2207 certificate and: 2209 3.b.2.a - If the signatures do verify and the response is 2210 glSuccessInfo, the GLO has deleted the member from the GL. 2211 If member was deleted from a managed list and the original 2212 request was signed by the member, the GLO MUST send a 2213 cMCStatusInfo.cMCStatus.success to the GL member. 2215 3.b.2.b - Else the GLO received a glFailInfo, for any reason, the 2216 GLO may reattempt to delete the member from the GL using 2217 the information provided in the glFailInfo response. 2219 4 - Upon receipt of the glSuccessInfo, glFailInfo, or cMCStatus 2220 response, the prospective member verifies the GLA's 2221 signature(s) or GLO�s signature(s). If an additional 2222 SignedData and/or EnvelopedData encapsulates the response (see 2223 section 3.2.1.2 or 3.2.2), the GLO MUST verify the outer 2224 signature and/or decrypt the outer layer prior to verifying 2225 the signature on the inner most SignedData. 2227 4.a - If the signatures do not verify, the prospective member MUST 2228 return a cMCStatusInfo response indicating cMCStatus.failed 2229 and otherInfo.failInfo.badMessageCheck. 2231 4.b - Else the signatures do verify, the GL member MUST check that 2232 one of the names in the certificate used to sign the 2233 response matches the name of the GL. 2235 4.b.1 � If the GL�s name does not match the name present in the 2236 certificate used to sign the message, the GL member should 2237 not believe the response. 2239 4.b.2 � Else the GL�s name does match the name present in the 2240 certificate and: 2242 4.b.2.a - If the signature(s) does(do) verify, the prospective 2243 member has been deleted from the GL. 2245 4.b.2.b - Else the prospective member received a glFailInfo, for 2246 any reason, the prospective member MAY reattempt to delete 2247 themselves from the GL using the information provided in 2248 the glFailInfo response. 2250 4.4.2 Member Initiated Deletions 2252 The process for prospective non-member initiated glDeleteMember 2253 requests is as follows: 2255 1 - The prospective non-GL member sends a 2256 SignedData.PKIData.controlSequence.glDeleteMember request to 2257 the GLA (A in Figure 6). The prospective non-GL member MUST 2258 include: the GL name in glName and their name in 2259 glMemberToDelete. 2261 1.a - The prospective non-GL member MAY optionally apply 2262 confidentiality to the request by encapsulating the 2263 SignedData.PKIData in an EnvelopedData (see section 2264 3.2.1.2). 2266 1.b - The prospective non-GL member MAY also optionally apply 2267 another SignedData over the EnvelopedData (see section 2268 3.2.1.2). 2270 2 - Upon receipt of the request, the GLA verifies the request as 2271 per 2 in section 4.4.1. 2273 3 - Upon receipt of the forwarded request, the GLO verifies the 2274 prospective non-member�s signature on the inner most 2275 SignedData.PKIData and the GLA�s signature on the outer layer. 2276 If an EnvelopedData encapsulates the inner most layer (see 2277 section 3.2.1.2 or 3.2.2), the GLO MUST decrypt the outer 2278 layer prior to verifying the signature on the inner most 2279 SignedData. 2281 Note: For cases where the GL is closed and either a) a 2282 prospective member sends directly to the GLO or b) the GLA has 2283 mistakenly forwarded the request to the GLO, the GLO should 2284 first determine whether to honor the request. 2286 3.a - If the signatures do not verify, the GLO MUST return a 2287 cMCStatusInfo response indicating cMCStatus.failed and 2288 otherInfo.failInfo.badMessageCheck. 2290 3.b - Else the signatures do verify, the GLO MUST check to make 2291 sure one of the names in the certificates used to sign the 2292 request matches the name in glMemberToDelete. 2294 3.b.1 - If the names do not match, the GLO MAY send a 2295 SignedData.PKIResponse.controlSequence message back to the 2296 prospective member with cMCStatusInfo.cMCtatus.failed 2297 indicating why the prospective member was denied in 2298 cMCStatusInfo.statusString. This stops people from adding 2299 people to GLs without their permission. 2301 3.b.2 - Else the names do match, the GLO resubmits the 2302 glDeleteMember request (see section 3.2.5) to the GLA (1 2303 in Figure 6). The GLO MUST make sure the glMemberName is 2304 already on the GL. The GLO MUST also generate a glRekey 2305 request and include it with the GLDeleteMember request 2306 (see section 4.5). 2308 3.b.2.a - The GLO MUST apply confidentiality to the new 2309 GLDeleteMember request by encapsulating the 2310 SignedData.PKIData in an EnvelopedData if the initial 2311 request was encapsulated in an EnvelopedData (see 2312 section 3.2.1.2). 2314 3.b.2.b - The GLO MAY also optionally apply another SignedData 2315 over the EnvelopedData (see section 3.2.1.2). 2317 4 - Further processing is as in 2 of section 4.4.1. 2319 4.5 Request Rekey Of GL 2321 From time to time the GL will need to be rekeyed. Some situations 2322 are as follows: 2324 - When a member is removed from a closed or managed GL. In this 2325 case, the PKIData.controlSequence containing the glDeleteMember 2326 should contain a glRekey request. 2328 - Depending on policy, when a member is removed from an unmanaged 2329 GL. If the policy is to rekey the GL, the 2330 PKIData.controlSequence containing the glDeleteMember could also 2331 contain a glRekey request or an out of bands means could be used 2332 to tell the GLA to rekey the GL. Rekeying of unmanaged GLs when 2333 members are deleted is not advised. 2335 - When the current shared KEK has been compromised. 2337 - When the current shared KEK is about to expire. 2339 - If the GLO controls the GL rekey, the GLA should not assume 2340 that a new shared KEK should be distributed, but instead wait 2341 for the glRekey message. 2343 - If the GLA controls the GL rekey, the GLA should initiate a 2344 glKey message as specified in section 5. 2346 If the generationCounter (see section 3.1.1) is set to a value 2347 greater than one (1) and the GLO controls the GL rekey, the GLO may 2348 generate a glRekey any time before the last shared KEK has expired. 2349 To be on the safe side, the GLO should request a rekey one (1) 2350 duration before the last shared KEK expires. 2352 The GLA and GLO are the only entities allowed to initiate a GL 2353 rekey. The GLO indicated whether they are going control rekeys or 2354 whether the GLA is going to control rekeys when the assigned the 2355 shared KEK to GL (see section 3.1.1). The GLO MAY initiate a GL 2356 rekey at any time. The GLA MAY be configured to automatically rekey 2357 the GL prior to the expiration of the shared KEK (the length of time 2358 before the expiration is an implementation decision). The GLA can 2359 also automatically rekey GL�s that have been compromised, but this 2360 is covered in section 5. Figure 7 depicts the protocol interactions 2361 to request a GL rekey. Note that error messages are not depicted. 2363 +-----+ 1 2,A +-----+ 2364 | GLA | <-------> | GLO | 2365 +-----+ +-----+ 2367 Figure 7 - GL Rekey Request 2369 4.5.1 GLO Initiated Rekey Requests 2371 The process for GLO initiated glRekey requests is as follows: 2373 1 - The GLO sends a SignedData.PKIData.controlSequence.glRekey 2374 request to the GLA (1 in Figure 7). The GLO MUST include the 2375 glName. If glAdministration and glKeyNewAttributes are omitted 2376 then there is no change from the previously registered GL 2377 values for these fields. If the GLO wants to force a rekey for 2378 all outstanding shared KEKs it includes the glRekeyAllGLKeys 2379 set to TRUE. 2381 1.a - The GLO MAY optionally apply confidentiality to the request 2382 by encapsulating the SignedData.PKIData in an EnvelopedData 2383 (see section 3.2.1.2). 2385 1.b - The GLO MAY also optionally apply another SignedData over 2386 the EnvelopedData (see section 3.2.1.2). 2388 2 - Upon receipt of the request, the GLA verifies the signature on 2389 the inner most SignedData.PKIData. If an additional SignedData 2390 and/or EnvelopedData encapsulates the request (see section 2391 3.2.1.2 or 3.2.2), the GLA MUST verify the outer signature 2392 and/or decrypt the outer layer prior to verifying the 2393 signature on the inner most SignedData. 2395 2.a - If the signatures do not verify, the GLA MUST return a 2396 cMCStatusInfo response indicating cMCStatus.failed and 2397 otherInfo.failInfo.badMessageCheck. 2399 2.b - Else the signatures do verify, the GLA MUST make sure the GL 2400 is supported by the GLA by checking that the glName matches 2401 a glName stored on the GLA. 2403 2.b.1 - If the glName present does not match a GL stored on the 2404 GLA, the GLA MUST return a response indicating 2405 glFailInfo.errorCode.invalidGLName. 2407 2.b.2 - Else the glName present does match a GL stored on the GLA, 2408 the GLA MUST check that a registered GLO signed the 2409 request by checking that one of the names in the 2410 certificate used to sign the request is a registered GLO. 2412 2.b.2.a - If the names do not match, the GLA MUST return a 2413 response indicating glFailInfo.errorCode.noGLONameMatch. 2415 2.b.2.b - Else the names do match, the GLA MUST check the 2416 glNewKeyAttribute values. 2418 2.b.2.b.1 - If the new value for requestedAlgorithm is not 2419 supported, the GLA MUST return a response indicating 2420 glFailInfo.errorCode.unsupportedAlgorithm 2422 2.b.2.b.2 - Else the new value duration is not supportable, 2423 determining this is beyond the scope this document, 2424 the GLA MUST return a response indicating 2425 glFailInfo.errorCode.unsupportedDuration. 2427 2.b.2.b.3 - Else the GL is not supportable for other reasons, 2428 which the GLA does not wish to disclose, the GLA MUST 2429 return a response indicating 2430 glFailInfo.errorCode.unspecified. 2432 2.b.2.b.4 - Else the new requestedAlgorithm and duration are 2433 supportable or the glNewKeyAttributes was omitted, the 2434 GLA MUST return a glSuccessInfo to the GLO indicating 2435 the glName, the new glIdentifier, and an 2436 action.actionCode.rekeyedGL (2 in Figure 7). The GLA 2437 also uses the glKey message to distribute the rekey 2438 shared KEK (see section 5). 2440 2.b.2.b.4.a - The GLA MUST apply confidentiality to response by 2441 encapsulating the SignedData.PKIData in an 2442 EnvelopedData if the request was encapsulated in an 2443 EnvelopedData (see section 3.2.1.2). 2445 2.b.2.b.4.b - The GLA MAY also optionally apply another SignedData 2446 over the EnvelopedData (see section 3.2.1.2). 2448 3 - Upon receipt of the glSuccessInfo or glFailInfo response, the 2449 GLO verifies the GLA's signature(s). If an additional 2450 SignedData and/or EnvelopedData encapsulates the forwarded 2451 response (see section 3.2.1.2 or 3.2.2), the GLO MUST verify 2452 the outer signature and/or decrypt the forwarded response 2453 prior to verifying the signature on the inner most SignedData. 2455 3.a - If the signatures do not verify, the GLO MUST return a 2456 cMCStatusInfo response indicating cMCStatus.failed and 2457 otherInfo.failInfo.badMessageCheck. 2459 3.b - Else the signatures do verify, the GLO MUST check that one 2460 of the names in the certificate used to sign the response 2461 matches the name of the GL. 2463 3.b.1 � If the GL�s name does not match the name present in the 2464 certificate used to sign the message, the GLO should not 2465 believe the response. 2467 3.b.2 � Else the GL�s name does match the name present in the 2468 certificate and: 2470 3.b.2.a - If the signatures verifies and the response is 2471 glSuccessInfo, the GLO has successfully rekeyed the GL. 2473 3.b.2.b - Else the GLO received a glFailInfo, for any reason, the 2474 GLO may reattempt to rekey the GL using the information 2475 provided in the glFailInfo response. 2477 4.5.2 GLA Initiated Rekey Requests 2479 If the GLA is in charge of rekeying the GL the GLA will 2480 automatically issue a glKey message (see section 5). In addition the 2481 GLA will generate a glSuccessInfo to indicate to the GL that a 2482 successful rekey has occurred. The process for GLA initiated rekey 2483 is as follows: 2485 1 - The GLA MUST generate for all GLOs a 2486 SignedData.PKIData.controlSequence.glSuccessInfo indicating 2487 the glName, the new glIdentifier, and actionCode.rekeyedGL (A 2488 in Figure 7). glMemberName and glOwnerName are omitted. 2490 1.a - The GLA MAY optionally apply confidentiality to the request 2491 by encapsulating the SignedData.PKIData in an EnvelopedData 2492 (see section 3.2.1.2). 2494 1.b - The GLA MAY also optionally apply another SignedData over 2495 the EnvelopedData (see section 3.2.1.2). 2497 2 - Upon receipt of the glSuccessInfo response, the GLO verifies 2498 the GLA's signature(s). If an additional SignedData and/or 2499 EnvelopedData encapsulates the forwarded response (see section 2500 3.2.1.2 or 3.2.2), the GLO MUST verify the outer signature 2501 and/or decrypt the outer layer prior to verifying the 2502 signature on the inner most SignedData. 2504 2.a - If the signatures do not verify, the GLO MUST return a 2505 cMCStatusInfo response indicating cMCStatus.failed and 2506 otherInfo.failInfo.badMessageCheck. 2508 2.b - Else the signatures do verify, the GLO MUST check that one 2509 of the names in the certificate used to sign the response 2510 matches the name of the GL. 2512 2.b.1 � If the GL�s name does not match the name present in the 2513 certificate used to sign the message, the GLO should not 2514 believe the response. 2516 2.b.2 � Else the GL�s name does match the name present in the 2517 certificate and and the response is glSuccessInfo, the GLO 2518 knows the GLA has successfully rekeyed the GL. 2520 4.6 Change GLO 2522 Management of managed and closed GLs can become difficult for one 2523 GLO if the GL membership grows large. To support distributing the 2524 workload, GLAs support having GLs be managed by multiple GLOs. The 2525 glAddOwner and glRemoveOwner messages are designed to support adding 2526 and removing registered GLOs. Figure 8 depicts the protocol 2527 interactions to send glAddOwner and glRemoveOwner messages and the 2528 resulting response messages. 2530 +-----+ 1 2 +-----+ 2531 | GLA | <-------> | GLO | 2532 +-----+ +-----+ 2534 Figure 8 - GLO Add & Delete Owners 2536 The process for glAddOwner and glDeleteOwner is as follows: 2538 1 - The GLO sends a SignedData.PKIData.controlSequence.glAddOwner 2539 or glRemoveOwner request to the GLA (1 in Figure 8). The GLO 2540 MUST include: the GL name in glName, the GLO�s name in 2541 glOwnerName, and the GLO�s address in glOwnerAddress. 2543 1.a - The GLO MAY optionally apply confidentiality to the request 2544 by encapsulating the SignedData.PKIData in an EnvelopedData 2545 (see section 3.2.1.2). 2547 1.b - The GLO MAY also optionally apply another SignedData over 2548 the EnvelopedData (see section 3.2.1.2). 2550 2 - Upon receipt of the glAddOwner or glRemoveOwner request, the 2551 GLA verifies the GLO's signature(s). If an additional 2552 SignedData and/or EnvelopedData encapsulates the request (see 2553 section 3.2.1.2 or 3.2.2), the GLA MUST verify the outer 2554 signature and/or decrypt the outer layer prior to verifying 2555 the signature on the inner most SignedData. 2557 2.a - If the signatures do not verify, the GLA MUST return a 2558 cMCStatusInfo response indicating cMCStatus.failed and 2559 otherInfo.failInfo.badMessageCheck. 2561 2.b - Else the signatures do verify, the GLA MUST make sure the GL 2562 is supported by checking that the glName matches a glName 2563 stored on the GLA. 2565 2.b.1 - If the glName is not supported by the GLA, the GLA MUST 2566 return a response indicating 2567 glFailInfo.errorCode.invalidGLName. 2569 2.b.2 - Else the glName is supported by the GLA, the GLA MUST 2570 ensure a registered GLO signed the glAddOwner or 2571 glRemoveOwner request by checking that one of the names 2572 present in the digital signature certificate used to sign 2573 the glAddOwner or glDeleteOwner request matches the name 2574 of a registered GLO. 2576 2.b.2.a - If the names do not match, the GLA MUST return a 2577 response indicating glFailInfo.errorCode.noGLONameMatch. 2579 2.b.2.b - Else the names do match, the GLA MUST return a 2580 glSuccessInfo indicating the glName, the corresponding 2581 glIdentifier (for glAddOwner), an 2582 action.actionCode.addedGLO or removedGLO, and the 2583 respective GLO name in glOwnerName (2 in Figure 4). The 2584 GLA MUST also take administrative actions to associate 2585 the new glOwnerName with the GL in the case of 2586 glAddOwner or to disassociate the old glOwnerName with 2587 the GL in the cased of glRemoveOwner. 2589 2.b.2.b.1 - The GLA MUST apply confidentiality to the response by 2590 encapsulating the SignedData.PKIResponse in an 2591 EnvelopedData if the request was encapsulated in an 2592 EnvelopedData (see section 3.2.1.2). 2594 2.b.2.b.2 - The GLA MAY also optionally apply another SignedData 2595 over the EnvelopedData (see section 3.2.1.2). 2597 3 - Upon receipt of the glSuccessInfo or glFailInfo response, the 2598 GLO verifies the GLA's signature(s). If an additional 2599 SignedData and/or EnvelopedData encapsulates the response (see 2600 section 3.2.1.2 or 3.2.2), the GLO MUST verify the outer 2601 signature and/or decrypt the outer layer prior to verifying 2602 the signature on the inner most SignedData. 2604 3.a - If the signatures do not verify, the GLO MUST return a 2605 cMCStatusInfo response indicating cMCStatus.failed and 2606 otherInfo.failInfo.badMessageCheck. 2608 3.b - Else the signatures do verify, the GLO MUST check that one 2609 of the names in the certificate used to sign the response 2610 matches the name of the GL. 2612 3.b.1 � If the GL�s name does not match the name present in the 2613 certificate used to sign the message, the GLO should not 2614 believe the response. 2616 3.b.2 � Else the GL�s name does match the name present in the 2617 certificate and: 2619 3.b.2.a - If the signatures do verify and the response was 2620 glSuccessInfo, the GLO has successfully added or removed 2621 the GLO. 2623 3.b.2.b - Else the signatures do verify and the response was 2624 glFailInfo, the GLO MAY reattempt to add or delete the GLO 2625 using the information provided in the glFailInfo response. 2627 4.7 Indicate KEK Compromise 2629 The will be times when the shared KEK is compromised. GL members and 2630 GLOs use glkCompromise to tell the GLA that the shared KEK has been 2631 compromised. Figure 9 depicts the protocol interactions for GL Key 2632 Compromise. 2634 +-----+ 2{1} 4 +----------+ 2635 | GLO | <----------+ +-------> | Member 1 | 2636 +-----+ 5,3{1} | | +----------+ 2637 +-----+ <----------+ | 4 +----------+ 2638 | GLA | 1 +-------> | ... | 2639 +-----+ <---------------+ +----------+ 2640 | 4 +----------+ 2641 +-------> | Member n | 2642 +----------+ 2644 Figure 9 - GL Key Compromise 2646 4.7.1 GL Member Initiated KEK Compromise Message 2648 The process for GL member initiated glkCompromise messages is as 2649 follows: 2651 1 - The GL member sends a 2652 SignedData.PKIData.controlSequence.glkCompromise request to 2653 the GLA (1 in Figure 9). The GL member MUST include the GL�s 2654 name in GeneralName. 2656 1.a - The GL member MAY optionally apply confidentiality to the 2657 request by encapsulating the SignedData.PKIData in an 2658 EnvelopedData (see section 3.2.1.2). The glkCompromise MUST 2659 NOT be included in an EnvelopedData generated with the 2660 compromised shared KEK. 2662 1.b - The GL member MAY also optionally apply another SignedData 2663 over the EnvelopedData (see section 3.2.1.2). 2665 2 - Upon receipt of the glkCompromise request, the GLA verifies 2666 the GL member's signature(s). If an additional SignedData 2667 and/or EnvelopedData encapsulates the request (see section 2668 3.2.1.2 or 3.2.2), the GLA MUST verify the outer signature 2669 and/or decrypt the outer layer prior to verifying the 2670 signature on the inner most SignedData. 2672 2.a - If the signatures do not verify, the GLA MUST return a 2673 cMCStatusInfo response indicating cMCStatus.failed and 2674 otherInfo.failInfo.badMessageCheck. 2676 2.b - Else the signatures do verify, the GLA MUST make sure the GL 2677 is supported by checking that the indicated GL name matches 2678 a glName stored on the GLA. 2680 2.b.1 - If the glName is not supported by the GLA, the GLA MUST 2681 return a response indicating 2682 glFailInfo.errorCode.invalidGLName. 2684 2.b.2 - Else the glName is supported by the GLA, the GLA MUST 2685 check who signed the request. For GLOs, one of the names 2686 in the certificate used to sign the request MUST match a 2687 registered GLO. For the prospective member, the name in 2688 glMember.glMemberName MUST match one of the names in the 2689 certificate used to sign the request. 2691 2.b.2.a - If the GLO signed the request, the GLA MUST generate a 2692 glKey message as described in section 5 to rekey the GL 2693 (4 in Figure 9). 2695 2.b.2.b - Else anyone else signed the request, the GLA MUST 2696 forward the glkCompromise message (see section 3.2.3) to 2697 the GLO (2{1} in Figure 9). If there is more than one 2698 GLO, to which GLO the request is forwarded is beyond the 2699 scope of this document. Further processing by the GLO is 2700 discussed in section 4.7.2. 2702 4.7.2 GLO Initiated KEK Compromise Message 2704 The process for GLO initiated glkCompromise messages is as follows: 2706 1 - The GLO either: 2708 1.a - Generates the glkCompromise message itself by sending a 2709 SignedData.PKIData.controlSequence.glkCompromise request to 2710 the GLA (5 in Figure 9). The GLO MUST include the name of 2711 the GL in GeneralName. 2713 1.a.1 - The GLO MAY optionally apply confidentiality to the 2714 request by encapsulating the SignedData.PKIData in an 2715 EnvelopedData (see section 3.2.1.2). The glkCompromise 2716 MUST NOT be included in an EnvelopedData generated with 2717 the compromised shared KEK. 2719 1.a.2 - The GLO MAY also optionally apply another SignedData over 2720 the EnvelopedData (see section 3.2.1.2). 2722 1.b - Verifies the GLA�s and GL member�s signatures on the 2723 forwarded glkCompromise message. If an additional SignedData 2724 and/or EnvelopedData encapsulates the request (see section 2725 3.2.1.2 or 3.2.2), the GLO MUST verify the outer signature 2726 and/or decrypt the outer layer prior to verifying the 2727 signature on the inner most SignedData. 2729 1.b.1 - If the signatures do not verify, the GLO MUST return a 2730 cMCStatusInfo response indicating cMCStatus.failed and 2731 otherInfo.failInfo.badMessageCheck. 2733 1.b.1.a - If the signatures do verify, the GLO MUST check the 2734 names in the certificate match the name of the signer 2735 (i.e., the name in the certificate used to sign the GL 2736 member�s request is the GL member). 2738 1.b.1.a.1 � If either name does not match, the GLO should not 2739 trust the signer and it should not forward the message 2740 to the GLA. 2742 1.b.1.a.2 � Else the names do math, the signatures do verify, the 2743 GLO MUST determine whether to forward the 2744 glkCompromise message back to the GLA (3{1} in Figure 2745 9). Further processing by the GLA is in 2 of section 2746 4.7.1. The GLO MAY also return a response to the 2747 prospective member with cMCStatusInfo.cMCtatus.success 2748 indicating that the glkCompromise message was 2749 successfully received. 2751 4.8 Request KEK Refresh 2753 There will be times when GL members have misplaced their shared KEK. 2754 The shared KEK is not compromised and a rekey of the entire GL is 2755 not necessary. GL members use the glkRefresh message to request that 2756 the shared KEK(s) be redistributed to them. Figure 10 depicts the 2757 protocol interactions for GL Key Refresh. 2759 +-----+ 1 2 +----------+ 2760 | GLA | <-----------> | Member | 2761 +-----+ +----------+ 2763 Figure 10 - GL KEK Refresh 2765 The process for glkRefresh is as follows: 2767 1 - The GL member sends a 2768 SignedData.PKIData.controlSequence.glkRefresh request to the 2769 GLA (1 in Figure 10). The GL member MUST include name of the 2770 GL in GeneralName. 2772 1.a - The GL member MAY optionally apply confidentiality to the 2773 request by encapsulating the SignedData.PKIData in an 2774 EnvelopedData (see section 3.2.1.2). 2776 1.b - The GL member MAY also optionally apply another SignedData 2777 over the EnvelopedData (see section 3.2.1.2). 2779 2 - Upon receipt of the glkRefresh request, the GLA verifies the 2780 GL member's signature(s). If an additional SignedData and/or 2781 EnvelopedData encapsulates the request (see section 3.2.1.2 or 2782 3.2.2), the GLA MUST verify the outer signature and/or decrypt 2783 the outer layer prior to verifying the signature on the inner 2784 most SignedData. 2786 2.a - If the signatures do not verify, the GLA MUST return a 2787 cMCStatusInfo response indicating cMCStatus.failed and 2788 otherInfo.failInfo.badMessageCheck. 2790 2.b - Else the signatures do verify, the GLA MUST make sure the GL 2791 is supported by checking that the GL�s GeneralName matches a 2792 glName stored on the GLA. 2794 2.b.1 - If the GL�s name is not supported by the GLA, the GLA MUST 2795 return a response indicating 2796 glFailInfo.errorCode.invalidGLName. 2798 2.b.2 - Else the glName is supported by the GLA, the GLA MUST 2799 ensure the GL member is on the GL. 2801 2.b.2.a - If the glMemberName is not present on the GL, the GLA 2802 MUST return a response indicating 2803 glFailInfo.errorCode.noSpam. 2805 2.b.2.b - Else the glMemberName is present on the GL, the GLA MUST 2806 return a glKey message (2 in Figure 10) as described in 2807 section 5. 2809 4.9 GLA Query Request and Response 2811 There will be certain times when a GLO is having trouble setting up 2812 a GL because they do not know the algorithm(s) or some other 2813 characteristic that the GLA supports. There may also be times when 2814 prospective GL members or GL members need to know something about 2815 the GLA (these requests are not defined in the document). The 2816 glaQueryRequest and glaQueryResponse message have been defined to 2817 support determining this information. Figure 11 depicts the protocol 2818 interactions for glaQueryRequest and glaQueryResponse. 2820 +-----+ 1 2 +------------------+ 2821 | GLA | <-------> | GLO or GL Member | 2822 +-----+ +------------------+ 2824 Figure 11 - GLA Query Request & Response 2826 The process for glaQueryRequest and glaQueryResponse is as follows: 2828 1 - The GLO, GL member, or prospective GL member sends a 2829 SignedData.PKIData.controlSequence.glaQueryRequest request to 2830 the GLA (1 in Figure 11). The GLO, GL member, or prospective 2831 GL member indicates the information they are interested in 2832 receiving from the GLA. 2834 1.a - The GLO, GL member, or prospective GL member MAY optionally 2835 apply confidentiality to the request by encapsulating the 2836 SignedData.PKIData in an EnvelopedData (see section 2837 3.2.1.2). 2839 1.b - The GLO, GL member, or prospective GL member MAY also 2840 optionally apply another SignedData over the EnvelopedData 2841 (see section 3.2.1.2). 2843 2 - Upon receipt of the glaQueryRequest, the GLA determines if it 2844 accepts glaQueryRequest messages. 2846 2.a - If the GLA does not accept glaQueryRequest messages, the GLA 2847 MUST return a cMCStatusInfo response indicating 2848 cMCStatus.noSupport and any other information in 2849 statusString. 2851 2.b - Else the GLA does accept GLAQueryRequests, the GLA MUST 2852 verify the GLO's, GL member�s, or prospective GL member�s 2853 signature(s). If an additional SignedData and/or 2854 EnvelopedData encapsulates the request (see section 3.2.1.2 2855 or 3.2.2), the GLA MUST verify the outer signature and/or 2856 decrypt the outer layer prior to verifying the signature on 2857 the inner most SignedData. 2859 2.b.1 - If the signatures do not verify, the GLA MUST return a 2860 cMCStatusInfo response indicating cMCStatus.failed and 2861 otherInfo.failInfo.badMessageCheck. 2863 2.b.2 - Else the signatures do verify, the GLA MUST return a 2864 glaQueryResponse (2 in Figure 11) with the correct 2865 response if the glaRequestType is supported or return a 2866 cMCStatusInfo response indicating cMCStatus.noSupport if 2867 the glaRequestType is not supported. 2869 2.b.2.a - The GLA MUST apply confidentiality to the response by 2870 encapsulating the SignedData.PKIResponse in an 2871 EnvelopedData if the request was encapsulated in an 2872 EnvelopedData (see section 3.2.1.2). 2874 2.b.2.b - The GLA MAY also optionally apply another SignedData 2875 over the EnvelopedData (see section 3.2.1.2). 2877 3 - Upon receipt of the glaQueryResponse, the GLO, GL member, or 2878 prospective GL member verifies the GLA's signature(s). If an 2879 additional SignedData and/or EnvelopedData encapsulates the 2880 response (see section 3.2.1.2 or 3.2.2), the GLO, GL member, 2881 or prospective GL member MUST verify the outer signature 2882 and/or decrypt the outer layer prior to verifying the 2883 signature on the inner most SignedData. 2885 3.a - If the signatures do not verify, the GLO, GL member, or 2886 prospective GL member MUST return a cMCStatusInfo response 2887 indicating cMCStatus.failed and 2888 otherInfo.failInfo.badMessageCheck. 2890 3.b - Else the signatures do verify, the GLO, GL member, or 2891 prospective GL member MUST check that one of the names in 2892 the certificate used to sign the response matches the name 2893 of the GL. 2895 3.b.1 � If the GL�s name does not match the name present in the 2896 certificate used to sign the message, the GLO should not 2897 believe the response. 2899 3.b.2 - Else the GL�s name does match the name present in the 2900 certificate and the response was glaQueryResponse, the GLO, 2901 GL member, or prospective GL member may use the information 2902 contained therein. 2904 4.10 Update Member Certificate 2906 When the GLO generates a glAddMember request, when the GLA generates 2907 a glKey message, or when the GLA processes a glAddMember there may 2908 be instances when GL member�s certificate has expired or is invalid. 2909 In these instances the GLO or GLA may request that the GL member 2910 provide a new certificate to avoid the GLA from being unable to 2911 generate a glKey message for the GL member. There may also be times 2912 when the GL member knows their certificate is about to expire or has 2913 been revoked and they will not be able to receive GL rekeys. 2915 4.10.1 GLO and GLA Initiated Update Member Certificate 2917 The process for GLO initiated glUpdateCert is as follows: 2919 1 - The GLO or GLA sends a 2920 SignedData.PKIData.controlSequence.glProvideCert request to 2921 the GL member. The GLO or GLA indicates the GL name in glName 2922 and the GL member�s name in glMemberName. 2924 1.a - The GLO or GLA MAY optionally apply confidentiality to the 2925 request by encapsulating the SignedData.PKIData in an 2926 EnvelopedData (see section 3.2.1.2). If the GL member�s PKC 2927 has been revoked, the GLO or GLA MUST NOT use it to generate 2928 the EnvelopedData that encapsulates the glProvideCert 2929 request. 2931 1.b - The GLO or GLA MAY also optionally apply another SignedData 2932 over the EnvelopedData (see section 3.2.1.2). 2934 2 - Upon receipt of the glProvideCert message, the GL member 2935 verifies the GLO�s or GLA�s signature(s). If an additional 2936 SignedData and/or EnvelopedData encapsulates the response (see 2937 section 3.2.1.2 or 3.2.2), the GL member MUST verify the outer 2938 signature and/or decrypt the outer layer prior to verifying 2939 the signature on the inner most SignedData. 2941 2.a - If the signatures do not verify, the GL member MUST return a 2942 cMCStatusInfo response indicating cMCStatus.failed and 2943 otherInfo.failInfo.badMessageCheck. 2945 2.b - Else the signatures do verify, the GL member generates a 2946 Signed.PKIResponse.controlSequence.glUpdateCert that MUST 2947 include the GL name in glName, the member's name in 2948 glMember.glMemberName, their encryption certificate in 2949 glMember.certificates.pKC. The GL member MAY also include 2950 any attribute certificates associated with their encryption 2951 certificate in glMember.certificates.aC, and the 2952 certification path associated with their encryption and 2953 attribute certificates in 2954 glMember.certificates.certificationPath. 2956 2.a - The GL member MAY optionally apply confidentiality to the 2957 request by encapsulating the SignedData.PKIResponse in an 2958 EnvelopedData (see section 3.2.1.2). If the GL member�s PKC 2959 has been revoked, the GL member MUST NOT use it to generate 2960 the EnvelopedData that encapsulates the glProvideCert 2961 request. 2963 2.b - The GL member MAY also optionally apply another SignedData 2964 over the EnvelopedData (see section 3.2.1.2). 2966 3 - Upon receipt of the glUpdateCert message, the GLO or GLA 2967 verifies the GL member�s signature(s). If an additional 2968 SignedData and/or EnvelopedData encapsulates the response (see 2969 section 3.2.1.2 or 3.2.2), the GL member MUST verify the outer 2970 signature and/or decrypt the outer layer prior to verifying 2971 the signature on the inner most SignedData. 2973 3.a - If the signatures do not verify, the GLO or GLA MUST return 2974 a cMCStatusInfo response indicating cMCStatus.failed and 2975 otherInfo.failInfo.badMessageCheck. 2977 3.b - Else the signatures do verify, the GLO or GLA MUST verify 2978 the member�s encryption certificate. 2980 3.b.1 - If the member�s encryption certificate does not verify, 2981 the GLO MAY return either another glProvideCert request or 2982 a cMCStatusInfo with cMCStatus.failed and the reason why 2983 in cMCStatus.statusString. glProvideCert should be 2984 returned only a certain number of times because if the GL 2985 member does not have a valid certificate they will never 2986 be able to return one. 2988 3.b.2 - Else the member�s encryption certificate does not verify, 2989 the GLA MAY return another glProvideCert request to the GL 2990 member or a cMCStatusInfo with cMCStatus.failed and the 2991 reason why in cMCStatus.statusString to the GLO. 2992 glProvideCert should be returned only a certain number of 2993 times because if the GL member does not have a valid 2994 certificate they will never be able to return one. 2996 3.b.3 - Else the member�s encryption certificate does verify, the 2997 GLO or GLA will use it in subsequent glAddMember requests 2998 and glKey messages associated with the GL member. 3000 4.10.2 GL Member Initiated Update Member Certificate 3002 The process for an unsolicited GL member glUpdateCert is as follows: 3004 1 - The GL member sends a 3005 Signed.PKIData.controlSequence.glUpdateCert that MUST include 3006 the GL name in glName, the member's name in 3007 glMember.glMemberName, their encryption certificate in 3008 glMember.certificates.pKC. The GL member MAY also include any 3009 attribute certificates associated with their encryption 3010 certificate in glMember.certificates.aC, and the certification 3011 path associated with their encryption and attribute 3012 certificates in glMember.certificates.certificationPath. 3014 1.a - The GL member MAY optionally apply confidentiality to the 3015 request by encapsulating the SignedData.PKIData in an 3016 EnvelopedData (see section 3.2.1.2). If the GL member�s PKC 3017 has been revoked, the GLO or GLA MUST NOT use it to generate 3018 the EnvelopedData that encapsulates the glProvideCert 3019 request. 3021 1.b - The GL member MAY also optionally apply another SignedData 3022 over the EnvelopedData (see section 3.2.1.2). 3024 2 - Upon receipt of the glUpdateCert message, the GLA verifies the 3025 GL member�s signature(s). If an additional SignedData and/or 3026 EnvelopedData encapsulates the response (see section 3.2.1.2 3027 or 3.2.2), the GLA MUST verify the outer signature and/or 3028 decrypt the outer layer prior to verifying the signature on 3029 the inner most SignedData. 3031 2.a - If the signatures do not verify, the GLA MUST return a 3032 cMCStatusInfo response indicating cMCStatus.failed and 3033 otherInfo.failInfo.badMessageCheck. 3035 2.b - Else the signatures do verify, the GLA MUST verify the 3036 member�s encryption certificate. 3038 2.b.1 - If the member�s encryption certificate does not verify, 3039 the GLA MAY return another glProvideCert request to the GL 3040 member or a cMCStatusInfo with cMCStatus.failed and the 3041 reason why in cMCStatus.statusString to the GLO. 3042 glProvideCert should be returned only a certain number of 3043 times because if the GL member does not have a valid 3044 certificate they will never be able to return one. 3046 2.b.2 - Else the member�s encryption certificate does verify, the 3047 GLA will use it in subsequent glAddMember requests and 3048 glKey messages associated with the GL member. The GLA MUST 3049 also forward the glUpdateCert message to the GLO. 3051 5 Distribution Message 3053 The GLA uses the glKey message to distribute new, shared KEK(s) 3054 after receiving glAddMember, glDeleteMember (for closed and managed 3055 GLs), glRekey, glkCompromise, or glkRefresh requests and returning a 3056 glSuccessInfo response for the respective request. Figure 12 depicts 3057 the protocol interactions to send out glKey messages. The procedures 3058 defined in this section MUST be implemented. 3060 1 +----------+ 3061 +-------> | Member 1 | 3062 | +----------+ 3063 +-----+ | 1 +----------+ 3064 | GLA | ----+-------> | ... | 3065 +-----+ | +----------+ 3066 | 1 +----------+ 3067 +-------> | Member n | 3068 +----------+ 3070 Figure 12 - GL Key Distribution 3072 If the GL was setup with GLKeyAttributes.recipientsNotMutuallyAware 3073 set to FALSE, a separate glKey message MUST be sent to each GL 3074 member so as to not divulge information about the other GL members. 3076 When the glKey message is generated as a result of a: 3078 - glAddMember request, 3079 - glkComrpomise indication, 3080 - glkRefresh request, 3081 - glDeleteMember request with the GL�s glAdministration set to 3082 managed or closed, 3083 - glRekey request with generationCounter set to zero (0) 3085 The GLA MUST use either the kari (see section 12.3.2 of CMS [2]) or 3086 ktri (see section 12.3.1 of CMS [2]) choice in 3087 glKey.glkWrapped.RecipientInfo to ensure only the intended 3088 recipients receive the shared KEK. The GLA MUST support the ktri 3089 choice. 3091 When the glKey message is generated as a result of a glRekey request 3092 with generationCounter greater than zero (0) or when the GLA 3093 controls rekeys, the GLA MAY use the kari, ktri, or kekri (see 3094 section 12.3.3 of CMS [2]) in glKey.glkWrapped.RecipientInfo to 3095 ensure only the intended recipients receive the shared KEK. The GLA 3096 MUST support the RecipientInfo.ktri choice. 3098 5.1 Distribution Process 3100 When a glKey message is generated the process is as follows: 3102 1 - The GLA MUST send a SignedData.PKIData.controlSequence.glKey 3103 to each member by including: glName, glIdentifier, glkWrapped, 3104 glkAlgorithm, glkNotBefore, and glkNotAfter. If the GLA can 3105 not generate a glKey message for the GL member because the GL 3106 member�s PKC has expired or is invalid, the GLA MAY send a 3107 glUpdateCert to the GL member requesting a new certificate be 3108 provided (see section 4.10). The number of glKey messages 3109 generated for the GL is described in section 3.1.16. 3111 1.a - The GLA MAY optionally apply another confidentiality layer 3112 to the message by encapsulating the SignedData.PKIData in 3113 another EnvelopedData (see section 3.2.1.2). 3115 1.b - The GLA MAY also optionally apply another SignedData over 3116 the EnvelopedData.SignedData.PKIData (see section 3.2.1.2). 3118 2 - Upon receipt of the message, the GL members MUST verify the 3119 signature over the inner most SignedData.PKIData. If an 3120 additional SignedData and/or EnvelopedData encapsulates the 3121 message (see section 3.2.1.2 or 3.2.2), the GL Member MUST 3122 verify the outer signature and/or decrypt the outer layer 3123 prior to verifying the signature on the 3124 SignedData.PKIData.controlSequence.glKey. 3126 2.a - If the signatures do not verify, the GL member MUST return a 3127 cMCStatusInfo response indicating cMCStatus.failed and 3128 otherInfo.failInfo.badMessageCheck. 3130 2.b - Else the signatures do verify, the GL member process the 3131 RecipientInfos according to CMS [2]. Once unwrapped the GL 3132 member should store the shared KEK in a safe place. When 3133 stored, the glName, glIdentifier, and shared KEK should be 3134 associated. 3136 6 Algorithms 3138 This section lists the algorithms that must be implemented. 3139 Additional algorithms that should be implemented are also included. 3141 6.1 KEK Generation Algorithm 3143 The shared KEK MUST be generated according to the security 3144 considerations section in CMS [2]. 3146 6.2 Shared KEK Wrap Algorithm 3148 In the mechanisms described in sections 5, the shared KEK being 3149 distributed in glkWrapped MUST be protected by a key of equal or 3150 greater length (i.e., if a RC2 128-bit key is being distributed a 3151 key of 128-bits or greater must be used to protect the key). 3153 The algorithm object identifiers included in glkWrapped are as 3154 specified in 12.3 of CMS [2]. 3156 6.3 Shared KEK Algorithm 3158 The shared KEK distributed and indicated in glkAlgorithm MUST 3159 support the symmetric key-encryption algorithms as specified in 3160 section 12.3.3 of CMS [2] 3162 7 Transport 3164 SMTP [7] MUST be supported. All other transport mechanisms MAY be 3165 supported. 3167 8 Using the Group Key 3169 This document was written with three specific scenarios in mind. Two 3170 to support mail list agents and one for general message 3171 distribution. Scenario 1 depicts the originator sending a public key 3172 (PK) protected message to a MLA who then uses the shared KEK (S) to 3173 redistribute the message to the members of the list. Scenario 2 3174 depicts the originator sending a shared KEK protected message to a 3175 MLA who then redistributes the message to the members of the list 3176 (the MLA only adds additional recipients). Scenario 3 shows an 3177 originator sending a shared KEK protected message to a group of 3178 recipients without using the MLA. 3180 +----> +----> +----> 3181 PK +-----+ S | S +-----+ S | S | 3182 ----> | MLA | --+----> ----> | MLA | --+----> ----+----> 3183 +-----+ | +-----+ | | 3184 +----> +----> +----> 3186 Scenario 1 Scenario 2 Scenario 3 3187 9 Security Considerations 3189 Only have GLOs that are trusted. 3191 Need to rekey closed and managed GLs if a member is deleted. 3193 GL members have to store some kind of information about who 3194 distributed the shared KEK to them so that they can make sure 3195 subsequent rekeys are originated from the same entity. 3197 Need to make sure you don�t make the key size too small and duration 3198 long because people will have more time to attack the key. 3200 Need to make sure you don�t make the generationCounter to large 3201 because people can attack the last key. If there are 14 keys 3202 outstanding each with a year�s duration attackers might be able 3203 determine the 14th key. 3205 10 References 3207 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 3208 9, RFC 2026, October 1996. 3210 2 Housley, R., "Cryptographic Message Syntax," RFC 2630, June 1999. 3212 3 Myers, M., Liu, X., Schaad, J., Weinsten, J., "Certificate 3213 Management Message over CMS," draft-ietf-pkix-cmc-05.txt, July 3214 1999. 3216 4 Bradner, S., "Key words for use in RFCs to Indicate Requirement 3217 Levels", BCP 14, RFC 2119, March 1997. 3219 5 Ramsdale, B., "S/MIME Version 3 Message Specification," RFC 2633, 3220 June 1999. 3222 6 Housley, R., Ford, W., Polk, W. and D. Solo, "Internet X.509 3223 Public Key Infrastructure: Certificate and CRL Profile", RFC 3224 2459, January 1999. 3226 7 Postel, j., "Simple Mail Transport Protocol," RFC 821, August 3227 1982. 3229 11 Acknowledgements 3231 Thanks to Russ Housley and Jim Schaad for providing much of the 3232 background and review required to write this draft. 3234 12 Author's Addresses 3236 Sean Turner 3237 IECA, Inc. 3238 9010 Edgepark Road 3239 Vienna, VA 22182 3240 Phone: +1.703.628.3180 3241 Email: turners@ieca.com 3242 Annex A: ASN.1 Module 3244 SMIMESymmetricKeyDistribution 3245 { TBD } 3247 DEFINITIONS IMPLICIT TAGS ::= 3248 BEGIN 3250 -- EXPORTS All -- 3251 -- The types and values defined in this module are exported for use 3252 -- in the other ASN.1 modules. Other applications may use them for 3253 -- their own purposes. 3255 IMPORTS 3257 -- Directory Authentication Framework (X.509) 3258 AlgorithmIdentifier, AttributeCertificate, Certificate, 3259 FROM AuthenticationFramework { joint-iso-itu-t ds(5) 3260 module(1) authenticationFramework(7) 3 } 3262 -- PKIX Part 1 - Implicit 3263 GeneralName 3264 FROM PKIX1Implicit88 {iso(1) identified-organization(3) dod(6) 3265 internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) 3266 id-pkix1-implicit-88(2)} 3268 -- Cryptographic Message Syntax 3269 RecipientInfos, id-alg-CMS3DESWrap 3270 FROM CryptographicMessageSyntax { iso(1) member-body(2) us(840) 3271 rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) modules(0) 3272 cms(1)}; 3274 -- This defines the GL Use KEK control attribute 3276 id-skd-glUseKEK OBJECT IDENTIFIER ::= { id-skd 1} 3278 GLUseKEK ::= SEQUENCE { 3279 glInfo GLInfo, 3280 glOwnerInfo SEQUENCE SIZE (1..MAX) OF GLOwnerInfo, 3281 glAdministration GLAdministration DEFAULT (1), 3282 glKeyAttributes GLKeyAttributes OPTIONAL } 3284 GLInfo ::= SEQUENCE { 3285 glName GeneralName, 3286 glAddress GeneralName } 3288 GLOwnerInfo ::= SEQUENCE { 3289 glOwnerName GeneralName, 3290 glOwnerAddress GeneralName } 3291 GLAdministration ::= INTEGER { 3292 unmanaged (0), 3293 managed (1), 3294 closed (2) } 3296 GLKeyAttributes ::= SEQUENCE { 3297 rekeyControlledByGLO [0] BOOLEAN DEFAULT FALSE, 3298 recipientsNotMutuallyAware [1] BOOLEAN DEFAULT TRUE, 3299 duration [2] INTEGER DEAULT (0), 3300 generationCounter [3] INTEGER DEFAULT (2), 3301 requestedAlgorithm [4] AlgorithmIdentifier 3302 DEFAULT (id-alg-CMS3DESwrap) } 3304 -- This defines the Delete GL control attribute. 3305 -- It has the simple type GeneralName. 3307 id-skd-glDelete OBJECT IDENTIFIER ::= { id-skd 2} 3309 -- This defines the Add GL Member control attribute 3311 id-skd-glAddMember OBJECT IDENTIFIER ::= { id-skd 3} 3313 GLAddMember ::= SEQUENCE { 3314 glName GeneralName, 3315 glMember GLMember } 3317 GLMember ::= SEQUENCE { 3318 glMemberName GeneralName, 3319 glMemberAddress GeneralName OPTIONAL, 3320 certificates Certificates OPTIONAL } 3322 Certificates ::= SEQUENCE { 3323 pKC Certificate OPTIONAL, 3324 -- See X.509 3325 aC SEQUENCE SIZE (1.. MAX) OF 3326 AttributeCertificate OPTIONAL, 3327 -- See X.509 3328 certificationPath CertificateSet OPTIONAL } 3329 -- From CMS [2] 3331 CertificateSet ::= SET SIZE (1..MAX) OF CertificateChoices 3333 CertificateChoices ::= CHOICE { 3334 certificate Certificate, 3335 -- See X.509 3336 extendedCertificate [0] IMPLICIT ExtendedCertificate, 3337 -- Obsolete 3338 attrCert [1] IMPLICIT AttributeCertificate } 3339 -- See X.509 and X9.57 3340 -- This defines the Delete GL Member control attribute 3342 id-skd-glDeleteMember OBJECT IDENTIFIER ::= { id-skd 4} 3344 GLDeleteMember ::= SEQUENCE { 3345 glName GeneralName, 3346 glMemberToDelete GeneralName } 3348 -- This defines the Delete GL Member control attribute 3350 id-skd-glRekey OBJECT IDENTIFIER ::= { id-skd 5} 3352 GLRekey ::= SEQUENCE { 3353 glName GeneralName, 3354 glAdministration GLAdministration OPTIONAL, 3355 glNewKeyAttributes GLNewKeyAttributes OPTIONAL, 3356 glRekeyAllGLKeys BOOLEAN OPTIONAL } 3358 GLNewKeyAttributes ::= SEQUENCE { 3359 rekeyControlledByGLO [0] BOOLEAN OPTIONAL, 3360 recipientsNotMutuallyAware [1] BOOLEAN OPTIONAL, 3361 duration [2] INTEGER OPTIONAL, 3362 generationCounter [3] INTEGER OPTIONAL, 3363 requestedAlgorithm [4] AlgorithmIdentifier OPTIONAL } 3365 -- This defines the Add and Delete GL Owner control attributes 3367 id-skd-glAddOwner OBJECT IDENTIFIER ::= { id-skd 6} 3368 id-skd-glRemoveOwner OBJECT IDENTIFIER ::= { id-skd 7} 3370 GLOwnerAdministration ::= SEQUENCE { 3371 glName GeneralName, 3372 glOwnerInfo GLOwnerInfo } 3374 -- This defines the GL Key Compromise control attribute. 3375 -- It has the simple type GeneralName. 3377 id-skd-glKeyCompromise OBJECT IDENTIFIER ::= { id-skd 8} 3379 -- This defines the GL Key Refresh control attribute. 3381 id-skd-glkRefresh OBJECT IDENTIFIER ::= { id-skd 9} 3383 GLKRefresh ::= { 3384 glName GeneralName, 3385 dates SEQUENCE (1..MAX) OF Date } 3387 Date ::= { 3388 start GeneralizedTime, 3389 end GeneralizedTime OPTIONAL } 3390 -- This defines the GLA Query Request control attribute. 3392 id-skd-glaQueryRequest OBJECT IDENTIFIER ::= { id-skd X} 3394 GLAQueryRequest ::= SEQUENCE { 3395 glaRequestType OBJECT IDENTIFIER, 3396 glaRequestValue ANY DEFINED BY glaResponseType } 3398 -- This defines the Algorithm Request 3400 id-rt-algorithmSupported { id-tbd } 3402 -- This defines the GLA Query Response control attribute. 3404 id-skd-glaQueryResponse OBJECT IDENTIFIER ::= { id-skd X} 3406 GLAQueryResponse ::= SEQUENCE { 3407 glaResponseType OBJECT IDENTIFIER, 3408 glaResponseValue ANY DEFINED BY glaResponseType } 3410 -- Note that the response for algorithmSupported request is the 3411 -- smimeCapabilities attribute as defined in MsgSpec [5]. 3413 -- This defines the control attribute to request an updated 3414 -- certificate to the GLA. 3416 id-skd-glProvideCert OBJECT IDENTIFIER ::= { id-skd X} 3418 GLManageCert ::= SEQUENCE { 3419 glName GeneralName, 3420 glMember GLMember } 3422 -- This defines the control attribute to return an updated 3423 -- certificate to the GLA. It has the type GLManageCert. 3425 id-skd-glManageCert OBJECT IDENTIFIER ::= { id-skd X} 3427 -- This defines the control attribute to distribute the GL shared 3428 -- KEK. 3430 id-skd-glKey OBJECT IDENTIFIER ::= { id-skd X} 3431 GLKey ::= SEQUENCE { 3432 glName GeneralName, 3433 glIdentifier OCTET STRING, 3434 glkWrapped RecipientInfos, -- See CMS [2] 3435 glkAlgorithm AlgorithmIdentifier, 3436 glkNotBefore GeneralizedTime, 3437 glkNotAfter GeneralizedTime } 3439 END -- SMIMESymmetricKeyDistribution 3441 September 2, 2001