idnits 2.17.1 draft-ietf-smime-symkeydist-01.txt: 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. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 54 longer pages, the longest (page 2) being 59 lines 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 317 has weird spacing: '...esponse id-...' == 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: c - If all the names do match, the GLA MUST return to all the GLOs a GLSucessInfo indicating the glName, the corresponding glIdentifier, and an action.actionCode.deletedGL (2 in Figure 4). 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 (July 2000) is 8686 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 877 looks like a reference -- Missing reference section? '2' on line 2680 looks like a reference -- Missing reference section? '3' on line 352 looks like a reference -- Missing reference section? '4' on line 353 looks like a reference -- Missing reference section? '0' on line 876 looks like a reference -- Missing reference section? '5' on line 1101 looks like a reference Summary: 5 errors (**), 0 flaws (~~), 4 warnings (==), 8 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-01.txt July 2000 4 Expires: January 14, 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 mechanisms use 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 Turner 1 49 Conventions used in this document 51 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 52 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 53 this document are to be interpreted as described in RFC-2119 [4]. 55 1. INTRODUCTION....................................................3 56 1.1 APPLICABILITY TO E-MAIL........................................4 57 1.2 APPLICABILITY TO REPOSITORIES..................................4 58 2. ARCHITECTURE....................................................4 59 3. PROTOCOL INTERACTIONS...........................................6 60 3.1 CONTROL ATTRIBUTES.............................................7 61 3.1.1 GL USE KEK...................................................7 62 3.1.2 GL DELETE...................................................10 63 3.1.3 GL ADD MEMBERS..............................................10 64 3.1.4 GL DELETE MEMBERS...........................................11 65 3.1.5 GL REKEY....................................................12 66 3.1.6 GL ADD OWNER................................................13 67 3.1.7 GL REMOVE OWNER.............................................13 68 3.1.8 GL KEY COMPROMISE...........................................14 69 3.1.9 GL KEY REFRESH..............................................14 70 3.1.10 GL SUCCESS INFORMATION.....................................14 71 3.1.11 GL FAIL INFORMATION........................................15 72 3.1.12 GLA QUERY REQUEST..........................................17 73 3.1.13 GLA QUERY RESPONSE.........................................18 74 3.1.14 GL KEY.....................................................18 75 3.2 USE OF CMC, CMS, AND PKIX.....................................19 76 3.2.1 PROTECTION LAYERS...........................................19 77 3.2.1.1 MINIMUM PROTECTION........................................19 78 3.2.1.2 ADDITIONAL PROTECTION.....................................20 79 3.2.2 COMBINING REQUESTS AND RESPONSES............................20 80 3.2.3 GLA GENERATED MESSAGES......................................22 81 3.2.4 CMC CONTROL ATTRIBUTES......................................23 82 3.2.5 PKIX........................................................23 83 4 ADMINISTRATIVE MESSAGES.........................................23 84 4.1 ASSIGN KEK TO GL..............................................23 85 4.2 DELETE GL FROM GLA............................................26 86 4.3 ADD MEMBERS TO GL.............................................28 87 4.3.1 GLO INITIATED ADDITIONS.....................................29 88 4.3.2 PROSPECTIVE MEMBER INITIATED ADDITIONS......................34 89 4.4 DELETE MEMBERS FROM GL........................................36 90 4.4.1 GLO INITIATED DELETIONS.....................................37 91 4.4.2 MEMBER INITIATED DELETIONS..................................41 92 4.5 REQUEST REKEY OF GL...........................................42 93 4.5.1 GLO INITIATED REKEY REQUESTS................................43 94 4.5.2 GLA INITIATED REKEY REQUESTS................................45 95 4.6 CHANGE GLO....................................................45 96 4.7 INDICATE KEK COMPROMISE.......................................47 97 4.8 REQUEST KEK REFRESH...........................................49 98 4.9 GLA QUERY REQUEST AND RESPONSE................................50 99 5 DISTRIBUTION MESSAGE............................................52 100 5.1 DISTRIBUTION PROCESS..........................................53 102 Turner 2 103 6 KEY WRAPPING....................................................53 104 7 ALGORITHMS......................................................54 105 8 TRANSPORT.......................................................54 106 9 USING THE GROUP KEY.............................................54 107 10 SCHEMA REQUIREMENTS............................................54 108 11 SECURITY CONSIDERATIONS........................................54 109 12 REFERENCES.....................................................55 110 13 ACKNOWLEDGEMENTS...............................................55 111 14 AUTHOR'S ADDRESSES.............................................55 113 1. Introduction 115 With the ever-expanding use of secure electronic communications 116 (e.g., S/MIME [2]), users require a mechanism to distribute 117 encrypted data to multiple recipients (i.e., a group of users). 118 There are essentially two ways to encrypt the data for recipients: 119 using asymmetric algorithms with public key certificates (PKCs) or 120 symmetric algorithms with symmetric keys. 122 With asymmetric algorithms, the originator forms an originator- 123 determined content-encryption key (CEK) and encrypts the content, 124 using a symmetric algorithm. Then, using an asymmetric algorithm and 125 the recipient's PKCs, the originator generates per-recipient 126 information that either (a) encrypts the CEK for a particular 127 recipient (ktri ReipientInfo CHOICE), or (b) transfers sufficient 128 parameters to enable a particular recipient to independently 129 generate the same KEK (kari RecipientInfo CHOICE). If the group is 130 large, the amount of per-recipient information required may take 131 quite some time to generate, not to mention the time required to 132 collect and validate the PKCs for each of the recipients. Each 133 recipient identifies their per-recipient information and uses the 134 private key associated with the public key of their PKC to decrypt 135 the CEK and hence gain access to the encrypted content. 137 With symmetric algorithms, the origination process is the same as 138 with asymmetric algorithms except for what encrypts the CEK. Instead 139 of using PKCs, the originator uses a previously distributed secret 140 key-encryption key (KEK) to encrypt the CEK (kekri RecipientInfo 141 CHOICE). Only one copy of the encrypted CEK is required because all 142 the recipients already have the shared KEK needed to decrypt the CEK 143 and hence gain access to the encrypted content. 145 The security provided by the shared KEK is only as good as the sum 146 of the techniques employed by each member of the group to keep the 147 KEK secret from nonmembers. These techniques are beyond the scope of 148 this document. Only the members of the list and the key manager 149 should have the KEK in order to maintain the secrecy of the group. 150 Access control to the information protected by the KEK is determined 151 by the entity that encrypts the information, as all members of the 152 group have access. If the entity that is performing the encryption 153 wants to ensure some subset of the group does not gain access to the 155 Turner 3 156 information either a different KEK should be used (shared with this 157 smaller group) or asymmetric algorithms should be used. 159 1.1 Applicability to E-mail 161 One primary audience for this distribution mechanism is e-mail. 162 Distribution lists sometimes referred to as mail lists, have been 163 defined to support distribution of messages to recipients subscribed 164 to the mail list. There are two models for how the mail list can be 165 used. If the originator is a member of the mail list, the originator 166 sends messages encrypted with the shared KEK to the mail list (e.g., 167 listserv or majordomo) and the message is distributed to the mail 168 list members. If the originator is not a member of the mail list 169 (does not have the shared KEK), the originator sends the message 170 (encrypted for the MLA) to the mail list agent (MLA) and the MLA 171 then forms the shared KEK needed to encrypt the message. In either 172 case the recipients of the mail list use the previously distributed- 173 shared KEK to decrypt the message. 175 1.2 Applicability to Repositories 177 Objects can also be distributed via a repository (e.g., Light Weight 178 Directory Protocol (LDAP) servers, X.500 Directory System Agents 179 (DSAs), Web-based servers). If an object is stored in a repository 180 encrypted with a symmetric key algorithm, any one with the shared 181 KEK and access to that object can then decrypt that object. The 182 encrypted object and the encrypted, shared KEK can be stored in the 183 repository. 185 2. Architecture 187 Figure 1 depicts the architecture to support symmetric key 188 distribution. The Group List Agent (GLA) supports two distinct 189 functions with two different agents: 191 - The Key Management Agent (KMA) which is responsible for 192 generating the shared KEKs. 194 - The Group Management Agent (GMA) which is responsible for 195 managing the Group List (GL) to which the shared KEKs are 196 distributed. 198 Turner 4 199 +----------------------------------------------+ 200 | Group List Agent | +-------+ 201 | +------------+ + -----------------------+ | | Group | 202 | | Key | | Group Management Agent | |<-->| List | 203 | | Management |<-->| +------------+ | | | Owner | 204 | | Agent | | | Group List | | | +-------+ 205 | +------------+ | +------------+ | | 206 | | / | \ | | 207 | +------------------------+ | 208 +----------------------------------------------+ 209 / | \ 210 +----------+ +---------+ +----------+ 211 | Member 1 | | ... | | Member n | 212 +----------+ +---------+ +----------+ 214 Figure 1 - Key Distribution Architecture 216 A GLA may support multiple KMAs. KMAs may be differentiated by the 217 'goodness' of the random number used to generate the shared KEK or 218 the key management technique used to distribute the shared KEK. 219 Outside the GLA, KMAs are differentiated by the digital signatures 220 they apply to the messages they generate. 222 A GLA in general supports only one GMA, but the GMA may support 223 multiple GLs. Multiple KMAs may support a GMA in the same fashion as 224 GLAs support multiple KMAs. Assigning a particular KMA to a GL is 225 beyond the scope of this document. 227 Modeling real world GL implementations shows that there are very 228 restrictive GLs, where a human determines GL membership, and very 229 open GLs, where there are no restrictions on GL membership. To 230 support this spectrum, the mechanism described herein supports both 231 managed (i.e., where access control is applied) and unmanaged (i.e., 232 where no access control is applied) GLs. The access control 233 mechanism for managed lists is beyond the scope of this document. 235 In either case, the GL must initially be constructed by an entity 236 hereafter called the Group List Owner (GLO). There may be multiple 237 entities who 'own' the GL and who are allowed to make changes the 238 GL's properties or membership. The GLO determines if the GL will be 239 managed or unmanaged and is the only entity that may delete the GL. 240 GLO(s) may or may not be GL members. 242 Though Figure 1 depicts the GLA as encompassing both the KMA and GMA 243 functions, the two functions could be supported by the same entity 244 or they could be supported by two different entities. If two 245 entities are used, they could be located on one or two platforms. 246 There is however a close relationship between the KMA and GMA 247 functions. If the GMA stores all information pertaining to the GLs 248 and the KMA merely generates keys, a corrupted GMA could cause 249 havoc. To protect against a corrupted GMA, the KMA would be forced 251 Turner 5 252 to double check the requests it receives to ensure the GMA did not 253 tamper with them. These duplicative checks blur the functionality of 254 the two components together. For this reason, the interactions 255 between the KMA and GMA are beyond the scope of this document. 256 Proprietary mechanisms may be used to separate the functions by 257 strengthening the trust relationship between the two entities. 258 Henceforth, the distinction between the two agents is omitted; the 259 term GLA will be used to address both functions. 261 3. Protocol Interactions 263 There are existing mechanisms (e.g., listserv and majordomo) to 264 support managing GLs; however, this document does not address 265 securing these mechanisms, as they are not standardized. Instead, it 266 defines protocol interactions, as depicted in Figure 2, used by the 267 GL members, GLA, and GLO to manage GLs and distribute shared KEKs. 268 The interactions have been divided into administration messages and 269 distribution messages. The administrative messages are the request 270 and response messages needed to setup the GL, delete the GL, add 271 members to the GL, delete members of the GL, and request a group 272 rekey, etc. The distribution messages are the messages that 273 distribute the shared KEKs. The following paragraphs describe the 274 ASN.1 for both the administration and distribution messages. 275 Paragraph 4 describes how to use the administration messages and 276 paragraph 5 describes how to use the distribution messages. 278 +-----+ +----------+ 279 | GLO | <---+ +----> | Member 1 | 280 +-----+ | | +----------+ 281 | | 282 +-----+ <------+ | +----------+ 283 | GLA | <-------------+----> | ... | 284 +-----+ | +----------+ 285 | 286 | +----------+ 287 +----> | Member n | 288 +----------+ 290 Figure 2 - Protocol Interactions 292 Turner 6 293 3.1 Control Attributes 295 The messages are based on including control attributes in CMC's 296 PKIData.controlSequence for requests and CMC's 297 ResponseBody.controlSequence for responses. The content-types 298 PKIData and PKIResponse are then encapsulated in CMS's SignedData or 299 EnvelopedData, or a combination of the two (see paragraph 3.2). The 300 following are the control attributes defined in this document: 302 Implementation 303 Requirement Control Attribute OID Syntax 304 -------------- ------------------ ----------- ----------------- 305 MAY glUseKEK id-skd 1 GLUseKEK 306 MAY glDelete id-skd 2 GLDelete 307 MAY glAddMembers id-skd 3 GLAddMembers 308 MAY glDeleteMembers id-skd 4 GLDeleteMembers 309 MAY glRekey id-skd 5 GLRekey 310 MAY glAddOwners id-skd 6 GLAddOwners 311 MAY glRemoveOwners id-skd 7 GLRemoveOwners 312 MAY glkCompromise id-skd 8 GLKCompromise 313 SHOULD glkRefresh id-skd 9 GLKRefresh 314 MAY glSuccessInfo id-skd 10 GLSuccessInfo 315 MAY glFailInfo id-skd 11 GLFailInfo 316 MAY glAQueryRequest id-skd 12 GLAQueryRequest 317 MAY glAQueryResponse id-skd 13 GLAQueryResponse 318 MUST glKey id-skd 14 GLKey 320 GLSuccessInfo, GLFailInfo, and GLAQueryResponse are responses and go 321 into the PKIResponse content-type, all other messages are requests 322 and go into the PKIData content-type. 324 3.1.1 GL USE KEK 326 The GLO uses GLUseKEK to request that a shared KEK be assigned to a 327 GL. 329 GLUseKEK ::= SEQUENCE { 330 glName GeneralName, 331 glOwner SEQUENCE SIZE (1..MAX) OF GeneralName, 332 glAdministration GLAdministration, 333 glDistributionMethod GLDistributionMethod, 334 glKeyAttributes [0] GLKeyAttributes OPTIONAL } 336 GLAdministration ::= INTEGER { 337 unmanaged (0), 338 managed (1), 339 closed (2) } 341 Turner 7 342 GLDistributionMethod ::= CHOICE { 343 rfc822Name [0] IA5String, 344 x400Address ORAddress, 345 directoryName Name, 346 uniformResourceIdentifier [1] IA5String } 348 GLKeyAttributes ::= SEQUENCE { 349 rekeyControlledByGLO [0] BOOLEAN DEFAULT FALSE, 350 recipientMutuallyAware [1] BOOLEAN DEFAULT TRUE, 351 duration [2] INTEGER DEAULT (0), 352 generationCounter [3] INTEGER DEFAULT {2}, 353 requestedAlgorithm [4] AlgorithmIdentifier OPTIONAL } 355 The fields in GLUseKEK have the following meaning: 357 - glName is the name of the GL. The name MUST be unique for a 358 given GLA. 360 - glOwner indicates the owner of the GL. One of the names in 361 glOwner MUST match one of the names in the certificate used to 362 sign this SignedData.PKIData creating the GL (i.e., the 363 immediate signer). Multiple GLOs MAY be indicated if 364 glAdministration is set to managed or closed. 366 - glAdministration indicates how the GL should be administered. 367 The default is for the list to be unmanaged and to accept 368 requests from prospective members. Three possibilities exist: 370 - Unmanaged - When the GLO sets glAdministration to unmanaged, 371 they are allowing prospective members to request being added 372 and deleted from the GL without GLO intervention. 374 - Managed - When the GLO sets glAdministration to managed, they 375 are allowing prospective members to request being added and 376 deleted from the GL, but the request is sent to GLO for 377 review. The requests are redirected to the GLO. The GLO makes 378 the determination as to whether to honor the request. 380 - Closed - When the GLO sets glAdministration to closed, they 381 are not allowing prospective members to request being added 382 and deleted from the GL. The GLA will only accept GLAddMembers 383 and GLDeleteMembers requests from the GLO. 385 - glDistributionMethod indicates the mechanism the GLA should 386 distribute shared KEKs. Internet mail (rfc822Name) MUST be 387 supported and X.400 (x400Address), X.500 (directoryName), and 388 web (uniformResourceIdentifier) MAY be supported (see paragraph 389 8). 391 - glKeyAttributes indicates the attributes the GLO wants the GLA 392 to assign to the shared KEK. If the field is omitted, GL rekeys 394 Turner 8 395 will be controlled by the GLA, the recipients are allowed to 396 know about one another, the algorithm will be as specified in 397 paragraph 7, the shared KEK will be valid for a calendar month 398 (i.e., first of the month until the last day of the month), and 399 two shared KEKs will be distributed initially. The fields in 400 glKeyAttributes have the following meaning: 402 - rekeyControlledByGLO indicates whether the GL rekey messages 403 will be generated by the GLO or by the GLA. The default is for 404 the GLA to control rekeys. If GL rekey is controlled by the 405 GLA, the GL will continue to be rekeyed until the GLO deletes 406 the GL or changes the GL rekey to be GLO controlled. 408 - recipientsMutuallyAware indicates that the GLO wants the GLA 409 to distribute the shared KEK individually for each of the GL 410 members (i.e., a separate GLKey message is sent to each 411 recipient). The default is for separate GLKey message to not 412 be required. 414 NOTE: This supports lists where one member does not know the 415 identities of the other members. For example, a list is 416 configured granting submit permissions to only one member. All 417 other members are 'listening.' The security policy of the list 418 does not allow the members to know who else is on the list. If 419 a GLKey is constructed for all of the GL members, information 420 about each of the members may be derived from the information 421 in RecipientInfos. To make sure the GLKey message does not 422 divulge information about the other recipients, a separate 423 GLKey message would be sent to each GL member. 425 - duration indicates the length of time (in days) during which 426 the shared KEK is considered valid. The value zero (0) 427 indicates that the shared KEK is valid for a calendar month. 428 For example if the duration is zero (0), if the GL shared KEK 429 is requested on July 24, the first key will be valid until the 430 end of July and the next key will be valid for the entire 431 month of August. If the value is not zero (0), the shared KEK 432 will be valid for the number of days indicated by the value. 433 For example, if the value of duration is seven (7) and the 434 shared KEK is requested on Monday but not generated until 435 Tuesday (2359); the shared KEKs will be valid from Tuesday 436 (2359) to Tuesday (2359). The exact time of the day is 437 determined when the key is generated. 439 - generationCounter indicates the number of keys the GLO wants 440 the GLA to distribute. To ensure uninterrupted function of the 441 GL two (2) shared KEKs at a minimum MUST be initially 442 distributed. The second shared KEK is distributed with the 443 first shared KEK, so that when the first shared KEK is no 444 longer valid the second key can be used. See paragraphs 4.5 445 and 5 for more on rekey. 447 Turner 9 448 - requestedAlgorithm indicates the algorithm and any parameters 449 the GLO wants the GLA to use to generate the shared KEK. See 450 paragraph 7 for more on algorithms. 452 3.1.2 GL Delete 454 GLOs use GLDelete to request that a GL be deleted from the GLA. 456 GLDelete ::= GLNameAndIdentifier 458 GLNameAndIdentifier ::= SEQUENCE { 459 glName GeneralName, 460 glIdentifier GLIdentifier OPTIONAL } 462 The fields in GLDelete have the following meaning: 464 - glName indicates the name of the GL to be deleted. 466 - glIdentifier indicates the identifier of the GL to be deleted. 467 It MAY be omitted if it is unknown (e.g., the GLO hasn't 468 received a GLSuccessInfo assigning the glIdentifier to the GL) 469 or has been lost by the GLO. 471 3.1.3 GL Add Members 473 GLOs use GLAddMembers to request addition of new members and 474 prospective GL members' use GLAddMembers to request being added to 475 the GL. 477 GLAddMembers ::= SEQUENCE { 478 glName GeneralName, 479 glMembers SEQUENCE SIZE (1..MAX) OF GLMember, 480 glIdentifier GLIdentifier OPTIONAL } 482 GLMember ::= SEQUENCE { 483 glMemberName GeneralName, 484 certificates Certificates } 486 Certificates ::= SEQUENCE { 487 membersPKC Certificate, 488 -- See X.509 489 membersAC SEQUENCE OF AttributeCertificate OPTIONAL, 490 -- See X.509 491 certificationPath CertificateSet OPTIONAL } 492 -- From CMS [2] 494 CertificateSet ::= SET OF CertificateChoices 496 Turner 10 497 CertificateChoices ::= CHOICE { 498 certificate Certificate, -- See X.509 499 extendedCertificate [0] IMPLICIT ExtendedCertificate, 500 -- Obsolete 501 attrCert [1] IMPLICIT AttributeCertificate } 502 -- See X.509 and X9.57 504 The fields in GLAddMembers have the following meaning: 506 - glName indicates the name of the GL to which the member should 507 be added. 509 - glMembers indicates the particulars for the GL member(s) to be 510 added to the GL. GLMemberName indicates the name of the GL 511 member. certificates.membersPKC includes the member's encryption 512 certificate that will be used to encrypt the shared KEK for that 513 member. certificates.membersAC MAY be included to convey any 514 attribute certificate associated with the member's encryption 515 certificate. certificates.certificationPath MAY also be included 516 to convey the certification path corresponding to the member's 517 encryption and attribute certificates. The certification path is 518 optional because it may already be included elsewhere in the 519 message (e.g., in the outer CMS layer). 521 - glIdentifier indicates the identifier of the GL to which the 522 member should be added. It MAY be omitted if it is unknown 523 (e.g., the GLO hasn't received a GLSuccessInfo assigning the 524 glIdentifier to the GL) or has been lost by the GLO. The 525 prospective GL member MAY omit this field. The GLO MUST omit the 526 field if the GLAddMembers associated GLUseKEK message is 527 included in the same SignedData.PKIData content-type. 529 3.1.4 GL Delete Members 531 GLOs use GLDeleteMembers to request deletion of GL members and 532 prospective non-GL members use GLDeleteMembers to request being 533 removed from the GL. 535 GLDeleteMembers ::= SEQUENCE { 536 glName GeneralName, 537 glMembersToDelete SEQUENCE SIZE (1..MAX) OF GeneralName, 538 glIdentifier GLIdentifier OPTIONAL } 540 The fields in GLDeleteMembers have the following meaning: 542 - glName indicates the name of the GL from which the member should 543 be removed. 545 Turner 11 546 - glMembersToDelete indicates the name of the member to be 547 deleted. 549 - glIdentifier indicates the identifier of the GL to which the 550 member should be deleted. The prospective non-GL member MUST 551 include the field. The GLO MAY omit this field if it is unknown 552 (e.g., the GLO hasn't received a GLSuccessInfo assigning the 553 glIdentifier to the GL) or has been lost by the GLO. 555 3.1.5 GL Rekey 557 GLOs use the GLRekey to request a GL rekey. 559 GLRekey ::= SEQUENCE { 560 glName GeneralName, 561 glIdentifier GLIdentifier, 562 glOwner SEQUENCE SIZE (0..MAX) OF GeneralName, 563 glAdministration GLAdministration OPTIONAL, 564 glDistributionMethod GLDistributionMethod OPTIONAL, 565 glKeyAttributes GLKeyAttributes OPTIONAL } 567 The fields in GLRekey have the following meaning: 569 - glName indicates the name of the GL to be rekeyed. 571 - glIdentifier identifies the shared KEK to be rekeyed. 573 - glOwner indicates the owner(s) of the GL. The field is only 574 included if there is a change from the registered GLOs. 576 - glAdministration indicates how the GL should be administered. 577 See paragraph 3.1.1 for the three options. This field is only 578 included if there is a change from the previously registered 579 administered. 581 - glDistributionMethod indicates the mechanism the shared KEK 582 should be distributed. The field is only included if there is a 583 change from the previously registered glDistributionMethod. 585 - glKeyAttributes indicates whether the rekey of the GLO is 586 controlled by the GLA or GL, what algorithm and parameters the 587 GLO wishes to use, the duration of the key, and how many 588 outstanding keys should be issued. The field is only included if 589 there is a change from the previously registered 590 glKeyAttributes. If the value zero (0) is specified in 591 generationCounter the GLO is indicating that it wants all of the 592 outstanding GL shared KEKs rekeyed. For example, suppose the GLO 593 used the GLUseKEK with duration set to two (2) and the GLRekey 594 message is sent during the first duration with generationCounter 595 set to zero (0). The GLA would know to generate a GLKey message 597 Turner 12 598 to replace both the shared KEK currently being used and the 599 shared KEK for the second duration. 601 3.1.6 GL Add Owner 603 GLOs use the GLAddOwners to request that a new GLO be allowed to 604 administer the GL. These requests are only applicable to GLs that 605 are managed (i.e., administered.managed) or closed (i.e., 606 administered.closed). 608 GLAddOwners ::= GLOwnerAdministration 610 GLOwnerAdministration ::= SEQUENCE { 611 glName GeneralName, 612 glOwner SEQUENCE SIZE (1..MAX) OF GeneralName, 613 glIdentifier GLIdentifier OPTIONAL } 615 The fields in GLAddOwners have the following meaning: 617 - glName indicates the name of the GL to which the new GLO should 618 be associated. 620 - glOwner indicates the name(s) of the new GLO(s). 622 - glIdentifier optionally indicates the identifier of the GL to 623 which the GLO should be associated. It MAY be omitted if it is 624 unknown (e.g., the GLO hasn't received a GLSuccessInfo assigning 625 the glIdentifier to the GL) or has been lost by the GLO 627 3.1.7 GL Remove Owner 629 GLOs use the GLRemoveOwners to request that a GLO be disassociated 630 with the GL. These requests are only applicable to managed GLs. 632 GLRemoveOwners ::= GLOwnerAdministration 634 The fields in GLRemoveOwners have the following meaning: 636 - glName indicates the name of the GL to which the GLO should be 637 disassociated. 639 - glOwner indicates the name of the GLO. 641 - glIdentifier optionally indicates the identifier of the GL to 642 which the GLO should be disassociated. It MAY be omitted if it 643 is unknown (e.g., the GLO hasn't received a GLSuccessInfo 644 assigning the glIdentifier to the GL) or has been lost by the 645 GLO 647 Turner 13 648 3.1.8 GL Key Compromise 650 GL members use GLKCompromise to indicate that the shared KEK they 651 possessed has been compromised. 653 GLKCompromise ::= GLNameAndIdentifier 655 The fields in GLKeyCompromise have the following meanings: 657 - glName indicates the name of the GL. 659 - glIdentifier indicates the identifier of the GL for which the 660 shared KEK is associated. The GL members MAY omit this field if 661 it is unknown. 663 3.1.9 GL Key Refresh 665 GL members use the GLKRefresh to request that the shared KEK be 666 redistributed to them. 668 GLKRefresh ::= GLNameAndIdentifier 670 The fields in GLKRefresh have to following meaning: 672 - glName indicates the name of the GL. 674 - glIdentifier indicates the identifier of the GL for which the 675 shared KEK is associated. The GL members MAY omit this field if 676 it is unknown. 678 3.1.10 GL Success Information 680 The GLA uses GLSuccessInfo to indicate a successful result of an 681 administrative message. 683 GLSuccessInfo ::= SEQUENCE { 684 glName GeneralName, 685 glIdentifier GLIdentifier, 686 action SEQUENCE SIZE (1..MAX) OF Action } 688 ** With multiple GLOs do we want to indicate which GLO asked for the 689 action to be performed? ** 691 Action ::= SEQUENCE { 692 actionCode ActionCode, 693 glMemberName [0] GeneralName OPTIONAL, 694 glOwnerName [1] GeneralName OPTIONAL } 696 Turner 14 697 ActionCode ::= INTEGER { 698 assignedKEK (0), 699 deletedGL (1), 700 addedMember (2), 701 deletedMember (3), 702 rekeyedGL (4), 703 addedGLO (5), 704 removedGLO (6) } 706 The fields in GLSuccessInfo have the following meaning: 708 - glName indicates the name of the GL. 710 - glIdentifier identifies the specific GL on the GLA (the GLA may 711 support multiple GLs). 713 - action indicates the successfully performed action. 714 action.actionCode indicates whether the shared KEK was assigned 715 to the GL, whether the GL was deleted, whether a member was 716 added or deleted to or from a specific GL, whether the GL 717 rekeyed, whether a new GLO was added, and whether a GLO was 718 deleted. If members were added or deleted from a GL the members 719 MUST be indicated in glMemberName. If a GLO was added or 720 deleted from the GL, the GLO(s) MUST be indicated in 721 glOwnerName. 723 3.1.11 GL Fail Information 725 The GLA uses GLFailInfo to indicate that there was a problem 726 performing a requested action. 728 GLFailInfo ::= SEQUENCE { 729 glName GeneralName, 730 error SEQUENCE SIZE (1..MAX) OF Error, 731 glIdentifier GLIdentifier OPTIONAL } 733 ** With multiple GLOs do we want to indicate which GLO asked for the 734 action to be performed? ** 736 Error ::= SEQUENCE { 737 errorCode ErrorCode, 738 glMemberName [0] GeneralName OPTIONAL, 739 glOwnerName [1] GeneralName OPTIONAL } 741 Turner 15 742 ErrorCode ::= INTEGER { 743 unspecified (0), 744 closedGL (1) 745 unsupportedDuration (2) 746 unsupportedDistribtuionMethod (3), 747 invalidCert (4), 748 unsupportedAlgorithm (5), 749 noGLONameMatch (6), 750 invalidGLName (7), 751 invalidGLNameGLIdentifierCombination (8), 752 nameAlreadyInUse (9), 753 noSpam (10), 754 deniedAccess (11), 755 alreadyAMember (12), 756 notAMember (13), 757 alreadyAnOwner (14) 758 notAnOwner (15) } 760 The fields in GLFailInfo have the following meaning: 762 - glName indicates the name of the GL to which the error 763 corresponds. 765 - error indicates the reason why the GLA was unable to perform the 766 request. It also indicates the GL member or GLO to which the 767 error corresponds. If the error corresponds to a GL member or 768 GLO, a separate Error sequence MUST be used for each GL member 769 or GLO. The errors are returned under the following conditions: 771 - unspecified indicates that the GLA is unable to perform the 772 requested action but is unwilling to indicate why. 774 - closedGL indicates that members can only be added or deleted 775 by the GLO. 777 - unsupportedDuration indicates the GLA does not support 778 generating keys that are valid for the requested duration. 780 - unsupportedDistribtuionMethod indicates that the GLA does not 781 support any of the requested delivery methods. 783 - invalidCert indicates the member's encryption certificate was 784 not verifiable (i.e., signature did not validate, certificate 785 present on a CRL, etc.) 787 - unsupportedAlgorithm indicates the GLA does not support the 788 requested algorithm. 790 - noGLONameMatch indicates the name in one of the certificates 791 used to sign a request does not match the name of the 792 registered GLO. 794 Turner 16 795 - invalidGLName indicates the GLA does not support the glName 796 present in the request. 798 - invalidGLNameGLIdentifierCombination indicates the GLA does 799 not support the glName and glIdentifier present in the 800 request. 802 - nameAlreadyInUse indicates the glName is already assigned on 803 the GLA. 805 - noSpam indicates the prospective GL member did not sign the 806 request (i.e., if the name in glMembers.glMemberName does not 807 match one of the names in the certificate used to sign the 808 request). 810 - alreadyAMember indicates the prospective GL member is already 811 a GL member. 813 - notAMember indicates the prospective non-GL member is not a GL 814 member. 816 - alreadyAnOwner indicates the prospective GLO is already a GLO. 818 - notAnOwner indicates the prospective non-GL member is not a 819 GLO. 821 - glIdentifier identifies the specific GL. It MAY be omitted if 822 the response is a result of a GLUseKEK request otherwise it MUST 823 be present. 825 3.1.12 GLA Query Request 827 GLOs use the GLQueryRequest to ascertain what type of GL the GLA 828 supports. 830 GLAQueryRequest ::= SEQUENCE SIZE (1..MAX) OF GLOQuestions 832 GLOQuestions ::= INTEGER { 833 supportedAlgorithms (0), 834 distributionMethods (1) } 836 The fields in GLAQueryRequest have the following meaning: 838 - supportedAlgorithms indicates the GLO would like to know the 839 algorithms the GLA supports for generating and distribution the 840 shared KEK. 842 - distributionMethod indicates the GLO would like to know the 843 distribution methods the GLA supports for distributing the 844 shared KEK. 846 Turner 17 847 3.1.13 GLA Query Response 849 GLA's return the GLAQueryResponse after receiving a GLAQueryRequest. 851 GLAQueryResponse ::= SEQUENCE { 852 supportedAlgorithms SEQUENCE OF AlgorithmIdentifier OPTIONAL, 853 distributionMethods SEQUENCE OF GLDistributionMethod OPTIONAL } 855 The fields in GLAQueryResponse have the following meaning: 857 - supportAlgorithms indicates the algorithm(s) and parameters that 858 GLA supports for generating and distributing the shared KEK. 860 - distributionMethod indicates the distribution method(s) the GLA 861 supports for distribution the shared KEK. 863 3.1.14 GL Key 865 The GLA uses GLKey to distribute the shared KEK. 867 GLKey ::= SEQUENCE { 868 glName GeneralName, 869 glIdentifier GLIdentifier, 870 glkWrapped RecipientInfos, -- See CMS [2] 871 glkAlgorithm AlgorithmIdentifier, 872 glkNotBefore GeneralizedTime, 873 glkNotAfter GeneralizedTime } 875 GLIdentifier ::= CHOICE { 876 issuerNameAndCounter [0] IssuerNameAndCounter, 877 keyIdentifierAndCounter [1] KeyIdentifierAndCounter } 879 IssuerNameAndCounter ::= SEQUENCE { 880 issuer GeneralName, 881 counter INTEGER } 883 KeyIdentifierAndCounter ::= SEQUENCE { 884 keyIdentifier SubjectKeyIdentifier, 885 counter INTEGER } 887 SubjectKeyIdentifier ::= OCTET STRING 889 The fields in GLKey have the following meaning: 891 - glName is the name of the GL. 893 - glIdentifier identifies the specific GL on the GLA (the GLA may 894 support multiple GLs). Two options are provided. The 895 issuerNameAndCounter alternative identifies the GLA's who 897 Turner 18 898 created shared KEK and a counter. The keyIdentifierAndCounter 899 choice identifies the GLA's certificate that was used to encrypt 900 the shared KEK for the GL members and a counter. In either case 901 the counter is a monotonically increasing number. The 902 keyIdentifierAndCounter choice MUST be supported. 904 - glkWrapped is the GL's wrapped shared KEK. The RecipientInfos 905 shall be generated as specified in paragraph 6.2 of CMS [2]. The 906 kari RecipientInfo choice MUST be supported. The EncryptedKey 907 field, which is the shared KEK, MUST be generated according to 908 the paragraph concerning random number generation in the 909 security considerations of CMS [2]. 911 - glkAlgorithm identifies the algorithm the shared KEK is used 912 with. 914 - glkNotBefore indicates the date at which the shared KEK is 915 considered valid. GeneralizedTime values MUST be expressed 916 Greenwich Mean Time (Zulu) and MUST include seconds (i.e., times 917 are YYYYMMDDHHMMSSZ), even where the number of seconds is zero. 918 GeneralizedTime values MUST NOT include fractional seconds. 920 - glkNotAfter indicates the date after which the shared KEK is 921 considered invalid. GeneralizedTime values MUST be expressed 922 Greenwich Mean Time (Zulu) and MUST include seconds (i.e., times 923 are YYYYMMDDHHMMSSZ), even where the number of seconds is zero. 924 GeneralizedTime values MUST NOT include fractional seconds. 926 3.2 Use of CMC, CMS, and PKIX 928 3.2.1 Protection Layers 930 3.2.1.1 Minimum Protection 932 At a minimum, a SignedData MUST protect each request and response 933 encapsulated in PKIData and PKIResponse. The following is a 934 depiction of the minimum wrappings: 936 Minimum Protection 937 ------------------ 938 SignedData 939 PKIData or PKIResponse 940 controlSequence 942 Prior to taking any action on any request or response SignedData(s) 943 MUST be processed according to CMS [2]. 945 Turner 19 946 3.2.1.2 Additional Protection 948 An additional EnvelopedData MAY also be used to provide 949 confidentiality of the request and response. An additional 950 SignedData MAY also be added to provide authentication and integrity 951 of the encapsulated EnvelopedData. The following is a depiction of 952 the optional additional wrappings: 954 Confidentiality Protection A&I of Confidentiality Protection 955 -------------------------- --------------------------------- 956 EnvelopedData SignedData 957 SignedData EnvelopedData 958 PKIData or PKIResponse SignedData 959 controlSequence PKIData or PKIResponse 960 controlSequence 962 If an incoming message was encrypted, the corresponding outgoing 963 message MUST also be encrypted. All EnvelopedData objects MUST be 964 processed as specified in CMS [2]. 966 If the GLO or GL member applies confidentiality to a request, the 967 EnvelopedData MUST be encrypted for the GLA. If the GLA is supposed 968 to forward the GL member request GLO, the GLA decrypts the 969 EnvelopedData, strips the confidentiality layer off, and applies its 970 own confidentiality layer for the GLO. 972 3.2.2 Combining Requests and Responses 974 Multiple requests and responses MAY be combined in one PKIData or 975 PKIResponse by using PKIData.cmsSequence and 976 PKIResponse.cmsSequence. A separate cmsSequence MUST be used for 977 different GLs (i.e., requests corresponding to two different GLs are 978 included in different cmsSequences). The following is a diagram 979 depicting multiple requests and responses combined in one PKIData 980 and PKIResponse: 982 Turner 20 983 Multiple Request and Response 984 Request Response 985 ------- -------- 986 SignedData SignedData 987 PKIData PKIResponse 988 cmsSequence cmsSequence 989 SignedData SignedData 990 PKIData PKIResponse 991 controlSequence controlSequence 992 Zero or more requests Zero or more responses 993 corresponding to one GL. corresponding to one GL. 994 SignedData SignedData 995 PKIData PKIResponse 996 controlSequence controlSequence 997 Zero or more requests Zero or more responses 998 corresponding to one GL. corresponding to one GL. 1000 When applying confidentiality to multiple requests and responses, 1001 either each request or response MAY be encrypted individually or all 1002 of the requests/response MAY be included in one EnvelopedData. The 1003 following is a depiction of the choices using PKIData: 1005 Confidentiality of Multiple Requests and Responses 1006 Individually Wrapped Wrapped Together 1007 -------------------- ---------------- 1008 SignedData EnvelopedData 1009 PKIData SignedData 1010 cmsSequence PKIData 1011 EnvelopedData cmsSequence 1012 SignedData SignedData 1013 PKIData PKIResponse 1014 controlSequence controlSequence 1015 Zero or more requests Zero or more requests 1016 corresponding to one GL. corresponding to one GL. 1017 EnvelopedData SignedData 1018 SignedData PKIData 1019 PKIData controlSequence 1020 controlSequence Zero or more requests 1021 Zero or more requests corresponding to one GL. 1022 corresponding to one GL. 1024 Turner 21 1025 Certain combinations of requests in one PKIData.controlSequence and 1026 one PKIResponse.controlSequence are not allowed. The invalid 1027 combinations listed here MUST NOT be generated: 1029 Invalid Combinations 1030 --------------------------- 1031 GLUseKEK & GLDeleteMembers 1032 GLUseKEK & GLRekey 1033 GLUseKEK & GLDelete 1034 GLDelete & GLAddMembers 1035 GLDelete & GLDeleteMembers 1036 GLDelete & GLRekey 1037 GLDelete & GLAddOwners 1038 GLDelete & GLRemoveOwners 1039 GLFailInfo & GLKey 1041 To avoid unnecessary errors, certain requests and responses should 1042 be processed prior to others. The following is the priority of 1043 message processing, if not listed it is an implementation decision 1044 as to which to process first: GLUseKEK before GLAddMembers, 1045 GLAddMembers before GLRekey, GLDeleteMembers before GLRekey, and 1046 GLSuccessInfo before GLKey. 1048 ** Need to think more about the priority of processing ** 1050 3.2.3 GLA Generated Messages 1052 When the GLO generates a GLSuccessInfo, it generates one for the GL 1053 member and another for the GLO, depending on the actionCode. 1054 action.actionCode values of assignedKEK, deletedGL, rekeyedGL, 1055 addedGLO, and deletedGLO are not returned to GL members. Likewise, 1056 when the GLO generates GLFailInfo it generates one for the GL member 1057 and one for the GLO, depending on the actionCode. error values of 1058 unsupportedDuration, unsupportedDeliveryMethod, 1059 unsupportedAlgorithm, noGLONameMatch, nameAlreadyInUse, 1060 alreadyAnOwner, notAnOwner are not returned to GL members. 1062 Separate GLSucessInfo, GLFailInfo, and GLKey messages MUST be 1063 generated for each recipient if GL was setup with 1064 GLKeyAttributes.recipientMutuallyAware set to FALSE. 1066 If the GL has multiple GLOs, the GLA MUST send a copy of all 1067 GLSuccessInfo and GLFailInfo messages to each GLO. 1069 If a GL is managed and the GLA receives a prospective GL member add 1070 or delete request or the GLO receives a GLFailInfo from the GL. and 1071 the GL is managed, the GLA forwards the request to the GLO for 1072 review. An additional, SignedData MUST be applied to the forwarded 1073 request as follows: 1075 Turner 22 1076 GLA Forwarded Requests 1077 ---------------------- 1078 SignedData 1079 PKIData 1080 cmsSequence 1081 PKIData 1082 controlSequence 1084 3.2.4 CMC Control Attributes 1086 ** Elaborate more ** 1088 Can use: 1090 CMCFailInfo.badMessageCheck - To indicate signature did not verify. 1092 transactionId - To track particular requests/responses. 1094 senderNonce and recipientNonce - For sequence integrity. 1096 3.2.5 PKIX 1098 Signatures, certificates, and CRLs are verified according to PKIX 1099 [5]. 1101 Name matching is performed according to PKIX [5]. 1103 4 Administrative Messages 1105 There are a number of administrative messages that must be performed 1106 to manage a GL: creating the GL, deleting the GL, adding members to 1107 the GL, deleting members from the GL, and requesting a group rekey. 1108 The following sections describe each of messages' request and 1109 response combinations in detail. The GLKRefresh procedures in 1110 paragraph 4.8 SHOULD be implemented all other procedures MAY be 1111 implemented. 1113 4.1 Assign KEK To GL 1115 Prior to generating a group key, a GL MUST be setup. Figure 3 1116 depicts the protocol interactions to setup a GL. Note that error 1117 messages are not depicted in Figure 3. 1119 +-----+ 1 2 +-----+ 1120 | GLA | <-------> | GLO | 1121 +-----+ +-----+ 1123 Figure 3 - Create Group List 1125 Turner 23 1126 The process is as follows: 1128 1 - The GLO is the entity responsible for requesting the creation 1129 of the GL. The GLO sends a 1130 SignedData.PKIData.controlSequence.GLUseKEK request to the GLA 1131 (1 in Figure 3). The GLO MUST include: glName, glOwner, 1132 glAdministration, distributionMethod. The GLO MAY also include 1133 their preferences for the shared KEK in glKeyAttributes by 1134 indicating whether the GLO controls the rekey in 1135 rekeyControlledByGLO, whether separate GLKey messages should 1136 be sent to each recipient in recipientMutuallyAware, the 1137 requested algorithm to be used with the shared KEK in 1138 requestedAlgorithm, the duration of the shared KEK, and how 1139 many shared KEKs should be initially distributed in duration 1140 and generationCounter, respectively. 1142 a - If the GLO knows of members to be added to the GL, the 1143 GLAddMembers request MAY be included in the same 1144 controlSequence as the GLUseKEK request (see paragraph 1145 3.2.2). The GLO MUST indicate the same glName in the 1146 GLAddMembers request as in GLUseKEK.glName. The GLO MUST 1147 also include the member's encryption certificate in 1148 certificate.membersPKC. The GLO MAY also include any 1149 attribute certificates associated with the member's 1150 encryption certificate in membersAC and the certification 1151 path for the member's encryption and attribute certificates. 1152 The GLO MUST omit the glIdentifier, as it is unknown at this 1153 point in the setup procedure. 1155 b - The GLO MAY optionally apply confidentiality to the request 1156 by encapsulating the SignedData.PKIData in an EnvelopedData 1157 (see paragraph 3.2.1.2). 1159 c - The GLO MAY also optionally apply another SignedData over 1160 the EnvelopedData (see paragraph 3.2.1.2). 1162 2 - Upon receipt of the request, the GLA verifies the signature on 1163 the inner most SignedData.PKIData. If an additional SignedData 1164 and/or EnvelopedData encapsulates the request (see paragraph 1165 3.2.1.2 or 3.2.2), the GLA MUST verify the outer signature 1166 and/or decrypt the outer layer prior to verifying the 1167 signature on the inner most SignedData. 1169 a - If the signature(s) does(do) not verify, the GLA MUST return 1170 a response indicating CMCFailInfo.badMessageCheck. 1172 b - If the signature(s) does(do) verify, the GLA MUST check that 1173 one of the names in the certificate used to sign the request 1174 matches the name in CreateGL.glOwner. 1176 Turner 24 1177 1 - If the names do not match, the GLA MUST return a response 1178 indicating GLFailInfo.errorCode.noGLONameMatch. 1180 2 - If names do all match, the GLA MUST ensure the combination 1181 of the requested glName is not already in use. The GLA 1182 MUST also check any GLAddMembers included within the 1183 controlSequence with this GLCreate. Further processing of 1184 the GLAddMembers is covered in paragraph 4.3. 1186 a - If the glName is already in use the GLA MUST return a 1187 response indicating 1188 GLFailInfo.errorCode.nameAlreadyInUse. 1190 b - If the requestedAlgorithm is not supported, the GLA MUST 1191 return a response indicating 1192 GLFailInfo.errorCode.unsupportedAlgorithm. 1194 c - If the duration is not supportable, determining this is 1195 beyond the scope of this document, the GLA MUST return a 1196 response indicating 1197 GLFailInfo.errorCode.unsupportedDuration. 1199 d - If the GL is not supportable for other reasons, which 1200 the GLA does not wish to disclose, the GLA MUST return a 1201 response indicating GLFailInfo.errorCode.unspecified. 1203 e - If the glName distribution is not already in use, the 1204 duration is supportable, and the requestedAlgorithm is 1205 supported, the GLA MUST return a GLSuccessInfo to all 1206 GLOs indicating the glName, the corresponding 1207 glIdentifier, and an action.actionCode.assignedKEK (2 in 1208 Figure 3). The GLA also takes administrative actions, 1209 which are beyond the scope of this document, to store 1210 the glName, distributionMethod, glOwner, and any member 1211 that has been added. 1213 1 - The GLA MUST apply confidentiality to the response by 1214 encapsulating the SignedData.PKIResponse in an 1215 EnvelopedData if the request was encapsulated in an 1216 EnvelopedData (see paragraph 3.2.1.2). 1218 2 - The GLA MAY also optionally apply another SignedData 1219 over the EnvelopedData (see paragraph 3.2.1.2). 1221 3 - Upon receipt of the GLSuccessInfo or GLFailInfo responses, the 1222 GLO verifies the GLA's signature(s). If an additional 1223 SignedData and/or EnvelopedData encapsulates the response (see 1224 paragraph 3.2.1.2 or 3.2.2), the GLO MUST verify the outer 1225 signature and/or decrypt the outer layer prior to verifying 1226 the signature on the inner most SignedData. 1228 Turner 25 1229 a - If the signatures do not verify, the GLO MUST return a 1230 response indicating CMCFailInfo.badMessageCheck. 1232 b - If the signatures do verify and the response was 1233 GLSuccessInfo, the GLO has successfully created the GL. 1235 c - If the signatures do verify and the response was GLFailInfo, 1236 the GLO MAY reattempt to create the GL using the information 1237 provided in the GLFailInfo response. The GLO may also use 1238 the GLAQueryRequest to determine the algorithms and 1239 distribution methods supported by the GLA (see paragraph 1240 4.9). 1242 4.2 Delete GL From GLA 1244 From time to time, there are instances when a GL is no longer 1245 needed. In this case the GLO must delete the GL. Figure 4 depicts 1246 that protocol interactions to delete a GL. 1248 +-----+ 1 2 +-----+ 1249 | GLA | <-------> | GLO | 1250 +-----+ +-----+ 1252 Figure 4 - Delete Group List 1254 The process is as follows: 1256 1 - The GLO is the entity responsible for requesting the deletion 1257 of the GL. The GLO sends a 1258 SignedData.PKIData.controlSequence.GLDelete request to the GLA 1259 (1 in Figure 4). The GLO MUST include the name of the GL in 1260 glName. The GLO MAY also include the GL identifier 1261 glIdentifier. 1263 b - The GLO MAY optionally apply confidentiality to the request 1264 by encapsulating the SignedData.PKIData in an EnvelopedData 1265 (see paragraph 3.2.1.2). 1267 c - The GLO MAY also optionally apply another SignedData over 1268 the EnvelopedData (see paragraph 3.2.1.2). 1270 2 - Upon receipt of the request the GLA verifies the signature on 1271 the inner most SignedData.PKIData. If an additional SignedData 1272 and/or EnvelopedData encapsulates the request (see paragraph 1273 3.2.1.2 or 3.2.2), the GLA MUST verify the outer signature 1274 and/or decrypt the outer layer prior to verifying the 1275 signature on the inner most SignedData. 1277 a - If the signature(s) does(do) not verify, the GLA MUST return 1278 a response indicating CMCFailInfo.badMessageCheck. 1280 Turner 26 1281 b - If the signature(s) does(do) verify, the GLA MUST make sure 1282 the GL is supported by checking either that the glName is 1283 supported (in the case the glIdentifier is omitted) or that 1284 the combination of glName and glIdentifier matches a glName 1285 and glIdentifier combination stored on the GLA. 1287 1 - If the glIdentifier is omitted and the glName is not 1288 supported by the GLA, the GLA MUST return a response 1289 indicating GLFailInfo.errorCode.invalidGLName. 1291 2 - If the glName and glIdentifier are present and do not 1292 match a GL stored on the GLA, the GLA MUST return a 1293 response indicating 1294 GLFailInfo.errorCode.invalidGLNameGLIdentifierCombination. 1296 3 - If the glIdentifier is omitted and the glName is supported 1297 by the GLA or if the glIdentifier/glName combination is 1298 supported by the GLA, the GLA MUST ensure a registered GLO 1299 signed the GLDelete request by checking if the name 1300 present in the digital signature certificate used to sign 1301 the GLDelete request matches one of the registered GLOs. 1303 a - If the names do not match, the GLA MUST return a 1304 response indicating GLFailInfo.errorCode.noGLONameMatch. 1306 b - If the names do match but the GL is not deletable for 1307 other reasons, which the GLA does not wish to disclose, 1308 the GLA MUST return a response indicating 1309 GLFailInfo.errorCode.unspecified. 1311 c - If all the names do match, the GLA MUST return to all 1312 the GLOs a GLSucessInfo indicating the glName, the 1313 corresponding glIdentifier, and an 1314 action.actionCode.deletedGL (2 in Figure 4). The GLA 1315 MUST not accept further requests for member additions, 1316 member deletions, or group rekeys for this GL. 1318 1 - The GLA MUST apply confidentiality to the response by 1319 encapsulating the SignedData.PKIResponse in an 1320 EnvelopedData if the request was encapsulated in an 1321 EnvelopedData (see paragraph 3.2.1.2). 1323 2 - The GLA MAY also optionally apply another SignedData 1324 over the EnvelopedData (see paragraph 3.2.1.2). 1326 3 - Upon receipt of the GLSuccessInfo or GLFailInfo response, the 1327 GLO verifies the GLA's signature(s). If an additional 1328 SignedData and/or EnvelopedData encapsulates the response (see 1329 paragraph 3.2.1.2 or 3.2.2), the GLO MUST verify the outer 1330 signature and/or decrypt the outer layer prior to verifying 1331 the signature on the inner most SignedData. 1333 Turner 27 1334 a - If the signature(s) does(do) not verify, the GLO MUST return 1335 a response indicating CMCFailInfo.badMessageCheck. 1337 b - If the signatures do verify and the response was 1338 GLSuccessInfo, the GLO has successfully deleted the GL. 1340 c - If the signatures do verify and the response was GLFailInfo, 1341 the GLO MAY reattempt to delete the GL using the information 1342 provided in the GLFailInfo response. 1344 4.3 Add Members To GL 1346 To add members to GLs, either the GLO or prospective members use the 1347 GLAddMembers request. There are however different scenarios that 1348 should be supported. Either the GLO or prospective members may 1349 submit the GLAddMembers request to the GLA, but the GLA processes 1350 the requests differently. The GLO can submit the request at any time 1351 to add members to the GL, and the GLA, once it has verified the 1352 request came from the GLO should process it. If a prospective member 1353 sends the request, the GLA needs to determine how the GL is 1354 administered. When the GLO initially configured the GL, they set the 1355 GL to be unmanaged, managed, or closed (see paragraph 3.1.1). In the 1356 unmanaged case, the GLA merely processes the member's request. For 1357 the managed case, the GLA forwards the requests from the prospective 1358 members to the GLO. Where there are multiple GLOs for a GL, which 1359 GLO the request is forwarded to is beyond the scope of this 1360 document. In the closed case, the GLA will not accept requests from 1361 prospective members. The following paragraphs describe the 1362 processing required by the GLO, GLA, and prospective GL members 1363 depending on where the request originated, either from the GLO or 1364 from prospective members. Figure 5 depicts the protocol interactions 1365 for the three options. Note that the error messages are not 1366 depicted. 1368 +-----+ 2,B{A} 3 +----------+ 1369 | GLO | <--------+ +-------> | Member 1 | 1370 +-----+ | | +----------+ 1371 1 | | 1372 +-----+ <--------+ | 3 +----------+ 1373 | GLA | A +-------> | ... | 1374 +-----+ <-------------+ +----------+ 1375 | 1376 | 3 +----------+ 1377 +-------> | Member n | 1378 +----------+ 1380 Figure 5 - Member Addition 1382 An important decision that needs to be made on a group by group 1383 basis is whether to rekey the group every time a new member is 1385 Turner 28 1386 added. Typically, unmanaged GLs should not be rekeyed when a new 1387 member is added, as the overhead associated with rekeying the group 1388 becomes prohibitive, as the group becomes large. However, managed 1389 and closed GLs MUST be rekeyed to maintain the secrecy of the group. 1390 An option to rekeying the managed GLs when a member is added is to 1391 generate a new GL with a different group key. Group rekeying is 1392 discussed in paragraphs 4.5 and 5. 1394 4.3.1 GLO Initiated Additions 1396 The process for GLO initiated GLAddMembers requests is as follows: 1398 1 - The GLO collects the names and pertinent information for the 1399 members to be added (this MAY be done through an out of bands 1400 means). The GLO then sends a 1401 SignedData.PKIData.controlSequence.GLAddMembers request to the 1402 GLA (1 in Figure 5). The GLO MUST include: the GL name in 1403 glName, the member's name in glMembers.glMemberName, the 1404 member's encryption certificate in 1405 glMembers.certificates.membersPKC. The GLO MAY also include 1406 the GL identifier in glIdentifier, if known, any attribute 1407 certificates associated with the member's encryption 1408 certificate in glMembers.certificates.membersAC, and the 1409 certification path associated with the member's encryption and 1410 attribute certificates in 1411 glMembers.certificates.certificationPath. 1413 a - The GLO MAY optionally apply confidentiality to the request 1414 by encapsulating the SignedData.PKIData in an EnvelopedData 1415 (see paragraph 3.2.1.2). 1417 b - The GLO MAY also optionally apply another SignedData over 1418 the EnvelopedData (see paragraph 3.2.1.2). 1420 2 - Upon receipt of the request, the GLA verifies the signature on 1421 the inner most SignedData.PKIData. If an additional SignedData 1422 and/or EnvelopedData encapsulates the request (see paragraph 1423 3.2.1.2 or 3.2.2), the GLA MUST verify the outer signature 1424 and/or decrypt the outer layer prior to verifying the 1425 signature on the inner most SignedData. 1427 a - If the signature(s) does(do) not verify, the GLA MUST return 1428 a response indicating CMCFailInfo.badMessageCheck. 1430 b - If the signature(s) does(do) verify, the GLAddMembers 1431 request is included in a controlSequence with the GLUseKEK 1432 request, and the processing of 2.b.2 is successfully 1433 completed the GLA MUST return to all GLOs a GLSuccessInfo 1434 indicating the glName, the corresponding glIdentifier, an 1435 action.actionCode.addedMember, and action.glMemberName (2 in 1437 Turner 29 1438 Figure 5). The response MUST be constructed as specified in 1439 paragraph 3.2.3. 1441 1 - The GLA MUST apply confidentiality to the response by 1442 encapsulating the SignedData.PKIData in an EnvelopedData 1443 if the request was encapsulated in an EnvelopedData (see 1444 paragraph 3.2.1.2). 1446 2 - The GLA MAY also optionally apply another SignedData over 1447 the EnvelopedData (see paragraph 3.2.1.2). 1449 c - If the signature(s) does(do) verify and the GLAddMember 1450 request is not included in a controlSequence with the 1451 GLCreate request, the GLA MUST make sure the GL is supported 1452 by checking either that the glName is supported (in the case 1453 the glIdentifier is omitted) or that the combination of 1454 glName and glIdentifier matches a glName and glIdentifier 1455 stored on the GLA. 1457 1 - If the glIdentifier is omitted and the glName is not 1458 supported by the GLA, the GLA MUST return a response 1459 indicating GLFailInfo.errorCode.invalidGLName. 1461 2 - If the glName and glIdentifier are present and do not 1462 match a GL stored on the GLA, the GLA MUST return a 1463 response indicating 1464 GLFailInfo.errorCode.invalidGLNameGLIdentifierCombination. 1466 3 - If the glIdentifier is omitted and the glName is supported 1467 by the GLA or if the glIdentifier/glName combination is 1468 present and supported, the GLA MUST check to see if the 1469 glMemberName is present on the GL. 1471 a - If the glMemberName is present on the GL, the GLA MUST 1472 return a response indicating 1473 GLFailInfo.errorCode.alreadyAMember. 1475 b - If the glMemberName is not present on the GL, the GLA 1476 the GLA MUST check how the GL is administered. 1478 1 - If the GL is closed, the GLA MUST check that GLO 1479 signed the request by checking that one of the names 1480 in the digital signature certificate used to sign the 1481 request matches one of the registered GLOs. 1483 a - If the names do not match, the GLA MUST return a 1484 response indicating 1485 GLFailInfo.errorCode.noGLONameMatch. 1487 b - If the names do match, the GLA MUST verify the 1488 member's encryption certificate. 1490 Turner 30 1491 1 - If the member's encryption certificate does not 1492 verify, the GLA MUST return a response indicating 1493 GLFailInfo.errorCode.invalidCert. 1495 2 - If the member's certificate does verify, the GLA 1496 MUST return to all GLOs a GLSuccessInfo indicating 1497 the glName, the corresponding glIdentifier, an 1498 action.actionCode.addedMember, and 1499 action.glMemberName (2 in Figure 5). The response 1500 MUST be constructed as in paragraph 3.2.3. The GLA 1501 also takes administrative actions, which are 1502 beyond the scope of this document, to add the 1503 member with the GL stored on the GLA. The GLA will 1504 also distribute the shared KEK to the member via 1505 the mechanism described in paragraph 5. 1507 a - The GLA MUST apply confidentiality to the 1508 response by encapsulating the SignedData.PKIData 1509 in an EnvelopedData if the request was 1510 encapsulated in an EnvelopedData (see paragraph 1511 3.2.1.2). 1513 b - The GLA MAY also optionally apply another 1514 SignedData over the EnvelopedData (see paragraph 1515 3.2.1.2). 1517 2 - If the GL is managed, the GLA MUST check that either 1518 the GLO or the prospective member signed the request. 1519 For the GLO, one of the names in the certificate used 1520 to sign the request MUST match one of the registered 1521 GLOs. For the prospective member, the name in 1522 glMembers.glMemberName MUST match one of the names in 1523 the certificate used to sign the request. 1525 a _ If the signer is neither a registered GLO or the 1526 prospective GL member, the GLA MUST return a 1527 response indicating GLFailInfo.errorCode.noSpam. 1529 b - If the signer is the GLO, the GLA MUST verify the 1530 member's encryption certificate. 1532 1 - If the member's certificate does not verify, the 1533 GLA MUST return a response indicating 1534 GLFailInfo.errorCode.invalidCert. 1536 2 - If the member's certificate does verify, the GLA 1537 MUST return to all GLOs GLSuccessInfo indicating 1538 the glName, the corresponding glIdentifier, an 1539 action.actionCode.addedMember, and 1540 action.glMemberName to the GLO (2 in Figure 5). 1541 The response MUST be constructed as in paragraph 1542 3.2.3. The GLA also takes administrative actions, 1544 Turner 31 1545 which are beyond the scope of this document, to 1546 add the member with the GL stored on the GLA. The 1547 GLA will also distribute the shared KEK to the 1548 member via the mechanism described in paragraph 5. 1550 a - The GLA MUST apply confidentiality to the 1551 response by encapsulating the SignedData.PKIData 1552 in an EnvelopedData if the request was 1553 encapsulated in an EnvelopedData (see paragraph 1554 3.2.1.2). 1556 b - The GLA MAY also optionally apply another 1557 SignedData over the EnvelopedData (see paragraph 1558 3.2.1.2). 1560 c - If the signer is the prospective member, the GLA 1561 forwards the GLAddMembers request (see paragraph 1562 3.2.3) to the GLO (B{A} in Figure 5). Which GLO the 1563 request is forwarded to is beyond the scope of this 1564 document. Further processing of the forwarded 1565 request by the GLO is addressed in 3 of paragraph 1566 4.3.2. 1568 1 - The GLA MUST apply confidentiality to the 1569 forwarded request by encapsulating the 1570 SignedData.PKIData in an EnvelopedData if the 1571 original request was encapsulated in an 1572 EnvelopedData (see paragraph 3.2.1.2). 1574 2 - The GLA MAY also optionally apply another 1575 SignedData over the EnvelopedData (see paragraph 1576 3.2.1.2). 1578 3 - If the GL is unmanaged, the GLA MUST check that either 1579 the GLO or the prospective member signed the request. 1580 For the GLO, one of the names in the certificate used 1581 to sign the request MUST match one of the registered 1582 GLOs. For the prospective member, the name in 1583 glMembers.glMemberName MUST match one of the names in 1584 the certificate used to sign the request. 1586 a - If the signer is not the GLO or the prospective 1587 member, the GLA MUST return a response indicating 1588 GLFailInfo.errorCdoe.noSpam. 1590 b - If the signer is either the GLO or the prospective 1591 member, the GLA MUST verify the member's encryption 1592 certificate. 1594 1 - If the member's certificate does not verify, the 1595 GLA MUST return a response indicating 1596 GLFailInfo.errorCode.invalidCert. 1598 Turner 32 1599 2 - If the member's certificate does verify, the GLA 1600 MUST return a GLSucessInfo indicating the glName, 1601 the corresponding glIdentifier, an 1602 action.actionCode.addedMember, and 1603 action.glMemberName to the GLO (2 in Figure 5) if 1604 the GLO signed the request and to the GL member (3 1605 in Figure 5) if the GL member signed the request. 1606 The response MUST be constructed as in paragraph 1607 3.2.3. The GLA also takes administrative actions, 1608 which are beyond the scope of this document, to 1609 add the member with the GL stored on the GLA. The 1610 GLA will also distribute the shared KEK to the 1611 member via the mechanism described in paragraph 5. 1613 a - The GLA MUST apply confidentiality to the 1614 forwarded request by encapsulating the 1615 SignedData.PKIData in an EnvelopedData if the 1616 request was encapsulated in an EnvelopedData 1617 (see paragraph 3.2.1.2). 1619 b - The GLA MAY also optionally apply another 1620 SignedData over the EnvelopedData (see paragraph 1621 3.2.1.2). 1623 3 - Upon receipt of the GLSuccessInfo or GLFailInfo response, the 1624 GLO verifies the GLA's signature(s). If an additional 1625 SignedData and/or EnvelopedData encapsulates the response (see 1626 paragraph 3.2.1.2 or 3.2.2), the GLO MUST verify the outer 1627 signature and/or decrypt the outer layer prior to verifying 1628 the signature on the inner most SignedData. 1630 a - If the signature(s) does (do) not verify, the GLO MUST 1631 return a response indicating CMCFailInfo.badMessageCheck. 1633 b - If the signature(s) does(do) verify, the GLO has added the 1634 member to the GL. 1636 c - If the GLO received a GLFailInfo, for any reason, the GLO 1637 MAY reattempt to add the member to the GL using the 1638 information provided in the GLFailInfo response. 1640 4 - Upon receipt of the GLSuccessInfo or GLFailInfo response, the 1641 prospective member verifies the GLA's signature(s). If an 1642 additional SignedData and/or EnvelopedData encapsulates the 1643 response (see paragraph 3.2.1.2 or 3.2.2), the GLO MUST verify 1644 the outer signature and/or decrypt the outer layer prior to 1645 verifying the signature on the inner most SignedData. 1647 a - If the signatures do not verify, the prospective member MUST 1648 return a response indicating CMCFailInfo.badMessageCheck. 1650 Turner 33 1651 b - If the signatures do verify, the prospective member has been 1652 added to the GL. 1654 c - If the prospective member received a GLFailInfo, for any 1655 reason, the prospective member MAY reattempt to add 1656 themselves to the GL using the information provided in the 1657 GLFailInfo response. 1659 4.3.2 Prospective Member Initiated Additions 1661 The process for prospective member initiated GLAddMembers requests 1662 is as follows: 1664 1 - The prospective GL member sends a 1665 SignedData.PKIData.controlSequence.GLAddMembers request to the 1666 GLA (A in Figure 5). The prospective GL member MUST include: 1667 the GL name in glName, the member's name in 1668 glMembers.glMemberName, their encryption certificate in 1669 glMembers.certificates.membersPKC. The prospective GL member 1670 MAY also include the GL identifier in glIdentifier, if known, 1671 any attribute certificates associated with their encryption 1672 certificate in glMembers.certificates.membersAC, and the 1673 certification path associated with their encryption and 1674 attribute certificates in 1675 glMembers.certificates.certificationPath 1677 a - The prospective GL member MAY optionally apply 1678 confidentiality to the request by encapsulating the 1679 SignedData.PKIData in an EnvelopedData (see paragraph 1680 3.2.1.2). 1682 b - The prospective GL member MAY also optionally apply another 1683 SignedData over the EnvelopedData (see paragraph 3.2.1.2). 1685 2 - Upon receipt of the request, the GLA verifies the request as 1686 per 2 in paragraph 4.3.1. 1688 3 - Upon receipt of the forwarded request, the GLO verifies the 1689 prospective GL member's signature on the inner most 1690 SignedData.PKIData and the GLA's signature on the outer layer. 1691 If an EnvelopedData encapsulates the inner most layer (see 1692 paragraph 3.2.1.2 or 3.2.2), the GLO MUST decrypt the outer 1693 layer prior to verifying the signature on the inner most 1694 SignedData. 1696 a - If the signature(s) does(do) not verify, the GLO MUST return 1697 a response indicating CMCFailInfo.badMessageCheck. 1699 b - If the signature(s) does(do) verify, the GLO MUST check to 1700 make sure one of the names in the certificate used to sign 1701 the request matches the name in glMembers.glMemberName. 1703 Turner 34 1704 1 - If the names do not match, the GLO may send a message 1705 back, which is out of scope, to the prospective member, 1706 depending on policy, to indicate that GL members can only 1707 add themselves lists. This stops people from adding 1708 people to GLs without their permission. 1710 2 - If the names do match, the GLO determines whether the 1711 prospective member is allowed to be added. The mechanism 1712 is beyond the scope of this document; however, the GLO 1713 should check to see that the glMembers.glMemberName is not 1714 already on the GL. 1716 a - If the GLO determines the prospective member is not 1717 allowed to join the GL, the GLO MAY return a message, 1718 which is beyond the scope of this document, to indicate 1719 why the prospective member is not allowed to join. 1721 b - If GLO determines the prospective member is allowed to 1722 join the GL, the GLO MUST verify the member's encryption 1723 certificate. 1725 1 - If the member's certificate does not verify, the GLO 1726 MAY return a message, which is out of scope, to the 1727 prospective member indicating that their encryption 1728 certificate is not valid. 1730 2 - If the member's certificate does verify, the GLO 1731 reforms GLAddMembers request (the prospective member's 1732 signature is discarded and the GLO applies their own 1733 signature) to the GLA (1 in Figure 5) by including: 1734 the GL name in glName, the member's name in 1735 glMembers.glMemberName, the member's encryption 1736 certificate in glMembers.certificates.membersPKC. The 1737 GLO MAY also include the GL identifier in 1738 glIdentifier, if known, any attribute certificates 1739 associated with the member's encryption certificate in 1740 glMembers.certificates.membersAC, and the 1741 certification path associated with the member's 1742 encryption and attribute certificates in 1743 glMembers.certificates.certificationPath. 1745 a - The GLO MUST apply confidentiality to the new 1746 GLAddMember request by encapsulating the 1747 SignedData.PKIData in an EnvelopedData if the 1748 initial request was encapsulated in an EnvelopedData 1749 (see paragraph 3.2.1.2). 1751 b - The GLO MAY also optionally apply another SignedData 1752 over the EnvelopedData (see paragraph 3.2.1.2). 1754 4 - Processing continues as in 2 of paragraph 4.3.1. 1756 Turner 35 1757 4.4 Delete Members From GL 1759 To delete members from GLs, either the GLO or prospective non- 1760 members use the GLDeleteMembers request. There are however different 1761 scenarios that should be supported. Either the GLO or prospective 1762 members may submit the GLDeleteMembers request to the GLA, but the 1763 GLA processes the requests differently. The GLO can submit the 1764 request at any time to delete members from the GL, and the GLA, once 1765 it has verified the request came from the GLO should delete the 1766 member. If a prospective member sends the request, the GLA needs to 1767 determine how the GL is administered. When the GLO initially 1768 configured the GL, they set the GL to be unmanaged, managed, or 1769 closed (see paragraph 3.1.1). In the unmanaged case, the GLA merely 1770 processes the member's request. For the managed case, the GLA 1771 forwards the requests from the prospective members to the GLO. Where 1772 there are multiple GLOs for a GL, which GLO the request is forwarded 1773 to is beyond the scope of this document. In the closed case, the GLA 1774 will not accept requests from prospective members. The following 1775 paragraphs describe the processing required by the GLO, GLA, and 1776 prospective non-GL members depending on where the request 1777 originated, either from the GLO or from prospective members. Figure 1778 6 depicts the protocol interactions for the three options. Note that 1779 the error messages are not depicted. 1781 +-----+ 2,B{A} 3 +----------+ 1782 | GLO | <--------+ +-------> | Member 1 | 1783 +-----+ | | +----------+ 1784 1 | | 1785 +-----+ <--------+ | 3 +----------+ 1786 | GLA | A +-------> | ... | 1787 +-----+ <-------------+ +----------+ 1788 | 1789 | 3 +----------+ 1790 +-------> | Member n | 1791 +----------+ 1793 Figure 6 - Member Deletion 1795 If the member is not removed from the GL, they will continue to be 1796 able to receive and decrypt data protected with the shared KEK and 1797 will continue to receive shared KEK rekeys. For unmanaged lists, 1798 there is no point to a group rekey because there is no guarantee 1799 that the member requesting to be removed has not already added 1800 themselves back on the list under a different name. For managed and 1801 closed GLs, the GLO MUST take steps to ensure the member being 1802 deleted is not on the list twice. After ensuring this, the managed 1803 GL MUST be rekeyed to maintain the secrecy of the group. If the GLO 1804 is sure the member has been deleted the group rekey mechanism MAY be 1805 used to distribute the new key (see paragraphs 4.5 and 5). 1807 Turner 36 1808 4.4.1 GLO Initiated Deletions 1810 The process for GLO initiated GLDeleteMembers requests is as 1811 follows: 1813 1 - The GLO collects the names and pertinent information for the 1814 members to be deleted (this MAY be done through an out of 1815 bands means). The GLO then sends a 1816 SignedData.PKIData.controlSequence.GLDeleteMembers request to 1817 the GLA (1 in Figure 6). The GLO MUST include: the GL name in 1818 glName and the member's name in glMembersToDelete. The GLO MAY 1819 omit the glIdentifier if it is unknown. If the GL from which 1820 the member is being deleted in a closed or managed GL, the GLO 1821 MUST also generate a GLRekey request and include it with the 1822 GLDeleteMember request (see paragraph 4.5). 1824 a - The GLO MAY optionally apply confidentiality to the request 1825 by encapsulating the SignedData.PKIData in an EnvelopedData 1826 (see paragraph 3.2.1.2). 1828 b - The GLO MAY also optionally apply another SignedData over 1829 the EnvelopedData (see paragraph 3.2.1.2). 1831 2 - Upon receipt of the request, the GLA verifies the signature on 1832 the inner most SignedData.PKIData. If an additional SignedData 1833 and/or EnvelopedData encapsulates the request (see paragraph 1834 3.2.1.2 or 3.2.2), the GLA MUST verify the outer signature 1835 and/or decrypt the outer layer prior to verifying the 1836 signature on the inner most SignedData. 1838 a - If the signature(s) does(do) not verify, the GLA MUST return 1839 a response indicating CMCFailInfo.badMessageCheck. 1841 b - If the signature(s) does(do) verify, the GLA MUST make sure 1842 the GL is supported by the GLA by checking either that the 1843 glName is supported (in the case the glIdentifier is 1844 omitted) or that the combination of glName and glIdentifier 1845 matches a glName and glIdentifier stored on the GLA. 1847 1 - If the glIdentifier is omitted and the glName is not 1848 supported by the GLA, the GLA MUST return a response 1849 indicating GLFailInfo.errorCode.invalidGLName. 1851 2 - If the glName and glIdentifier are present and do not 1852 match a GL stored on the GLA, the GLA MUST return a 1853 response indicating 1854 GLFailInfo.errorCode.invalidGLNameGLIdentifierCombination. 1856 3 - If the glIdentifier is omitted and the glName is supported 1857 by the GLA or if the glIdentifier/glName combination is 1859 Turner 37 1860 supported by the GLA, the GLA MUST check to see if the 1861 glMemberName is present on the GL. 1863 a - If the glMemberName is not present on the GL, the GLA 1864 MUST return a response indicating 1865 GLFailInfo.errorCode.notAMember. 1867 b - If the glMemberName is not already on the GL, the GLA 1868 MUST check how the GL is administered. 1870 1 - If the GL is closed, the GLA MUST check that GLO 1871 signed the request by checking that one of the names 1872 in the digital signature certificate used to sign the 1873 request matches one of the registered GLOs. 1875 a - If the names do not match, the GLA MUST return a 1876 response indicating 1877 GLFailInfo.errorCode.noGLONameMatch. 1879 b - If the names do match, the GLA MUST return to all 1880 GLOs a GLSucessInfo indicating the glName, the 1881 corresponding glIdentifier, an 1882 action.actionCode.deletedMember, and 1883 action.glMemberName (2 in Figure 5). The response 1884 MUST be constructed as in paragraph 3.2.3. The GLA 1885 also takes administrative actions, which are beyond 1886 the scope of this document, to delete the member 1887 with the GL stored on the GLA. The GLA will also 1888 rekey group as described in paragraph 5. 1890 1 - The GLA MUST apply confidentiality to the response 1891 by encapsulating the SignedData.PKIData in an 1892 EnvelopedData if the request was encapsulated in 1893 an EnvelopedData (see paragraph 3.2.1.2). 1895 2 - The GLA MAY also optionally apply another 1896 SignedData over the EnvelopedData (see paragraph 1897 3.2.1.2). 1899 2 - If the GL is managed, the GLA MUST check that either 1900 the GLO or the prospective member signed the request. 1901 For the GLO, one of the names in the certificate used 1902 to sign the request MUST match one of the registered 1903 GLOs. For the prospective member, the name in 1904 glMembers.glMemberName MUST match one of the names in 1905 the certificate used to sign the request. 1907 a _ If the signer is neither a registered GLO or the 1908 prospective GL member, the GLA MUST return a 1909 response indicating GLFailInfo.errorCode.noSpam. 1911 Turner 38 1912 b - If the signer is the GLO, the GLA MUST return to all 1913 GLOs a GLSucessInfo indicating the glName, the 1914 corresponding glIdentifier, an 1915 action.actionCode.deletedMember, and 1916 action.glMemberName (2 in Figure 6). The response 1917 MUST be constructed as in paragraph 3.2.3. The GLA 1918 also takes administrative actions, which are beyond 1919 the scope of this document, to delete the member 1920 with the GL stored on the GLA. The GLA will also 1921 rekey group as described in paragraph 5. 1923 1 - The GLA MUST apply confidentiality to the response 1924 by encapsulating the SignedData.PKIData in an 1925 EnvelopedData if the request was encapsulated in 1926 an EnvelopedData (see paragraph 3.2.1.2). 1928 2 - The GLA MAY also optionally apply another 1929 SignedData over the EnvelopedData (see paragraph 1930 3.2.1.2). 1932 c - If the signer is the prospective member, the GLA 1933 forwards the GLDeleteMembers request (see paragraph 1934 3.2.3) to the GLO (B{A} in Figure 6). Which GLO the 1935 request is forwarded to is beyond the scope of this 1936 document. Further processing of the forwarded 1937 request by the GLO is addressed in 3 of paragraph 1938 4.4.2. 1940 1 - The GLA MUST apply confidentiality to the 1941 forwarded request by encapsulating the 1942 SignedData.PKIData in an EnvelopedData if the 1943 request was encapsulated in an EnvelopedData (see 1944 paragraph 3.2.1.2). 1946 2 - The GLA MAY also optionally apply another 1947 SignedData over the EnvelopedData (see paragraph 1948 3.2.1.2). 1950 3 - If the GL is unmanaged, the GLA MUST check that either 1951 the GLO or the prospective member signed the request. 1952 For the GLO, one of the names in the certificate used 1953 to sign the request MUST match one of the registered 1954 GLOs. For the prospective member, the name in 1955 glMembers.glMemberName MUST match one of the names in 1956 the certificate used to sign the request. 1958 a - If the signer is not the GLO or the prospective 1959 member, the GLA MUST return a response indicating 1960 GLFailInfo.errorCode.noSpam. 1962 b - If the signer is either the GLO or the member, the 1963 GLA MUST return a GLSucessInfo indicating the 1965 Turner 39 1966 glName, the corresponding glIdentifier, an 1967 action.actionCode.deletedMember, and 1968 action.glMemberName to the GLO (2 in Figure 6) if 1969 the GLO signed the request and to the GL member (3 1970 in Figure 6) if the GL member signed the request. 1971 The response MUST be constructed as in paragraph 1972 3.2.3. The GLA also takes administrative actions, 1973 which are beyond the scope of this document, to 1974 delete the member with the GL stored on the GLA. 1976 1 - The GLA MUST apply confidentiality to the response 1977 by encapsulating the SignedData.PKIData in an 1978 EnvelopedData if the request was encapsulated in an 1979 EnvelopedData (see paragraph 3.2.1.2). 1981 2 - The GLA MAY also optionally apply another 1982 SignedData over the EnvelopedData (see paragraph 1983 3.2.1.2). 1985 3 - Upon receipt of the GLSuccessInfo or GLFailInfo response, the 1986 GLO verifies the GLA's signatures. If an additional SignedData 1987 and/or EnvelopedData encapsulates the response (see paragraph 1988 3.2.1.2 or 3.2.2), the GLO MUST verify the outer signature 1989 and/or decrypt the outer layer prior to verifying the 1990 signature on the inner most SignedData. 1992 a - If the signature(s) does(do) not verify, the GLO MUST return 1993 a response indicating CMCFailInfo.badMessageCheck. 1995 b - If the signature(s) does(do) verify, the GLO has deleted the 1996 member from the GL. 1998 c - If the GLO received a GLFailInfo, for any reason, the GLO 1999 may reattempt to delete the member from the GL using the 2000 information provided in the GLFailInfo response. 2002 4 - Upon receipt of the GLSuccessInfo or GLFailInfo response, the 2003 prospective member verifies the GLA's signature(s). If an 2004 additional SignedData and/or EnvelopedData encapsulates the 2005 response (see paragraph 3.2.1.2 or 3.2.2), the GLO MUST verify 2006 the outer signature and/or decrypt the outer layer prior to 2007 verifying the signature on the inner most SignedData. 2009 a - If the signature(s) does(do) not verify, the prospective 2010 member MUST return a response indicating 2011 CMCFailInfo.badMessageCheck. 2013 b - If the signature(s) does(do) verify, the prospective member 2014 has been deleted from the GL. 2016 c - If the prospective member received a GLFailInfo, for any 2017 reason, the prospective member MAY reattempt to delete 2019 Turner 40 2020 themselves from the GL using the information provided in the 2021 GLFailInfo response. 2023 4.4.2 Member Initiated Deletions 2025 The process for prospective non-member initiated GLDeleteMembers 2026 requests is as follows: 2028 1 - The prospective non-GL member sends a 2029 SignedData.PKIData.controlSequence.GLDeleteMembers request to 2030 the GLA (A in Figure 5). The prospective non-GL member MUST 2031 include: the GL name in glName and their name in 2032 glMembersToDelete. The prospective non-GL member MAY omit the 2033 glIdentifier if it is unknown. 2035 a - The prospective non-GL member MAY optionally apply 2036 confidentiality to the request by encapsulating the 2037 SignedData.PKIData in an EnvelopedData (see paragraph 2038 3.2.1.2). 2040 b - The prospective non-GL member MAY also optionally apply 2041 another SignedData over the EnvelopedData (see paragraph 2042 3.2.1.2). 2044 2 - Upon receipt of the request, the GLA verifies the request as 2045 per 2 in paragraph 4.4.1. 2047 3 - Upon receipt of the forwarded request, the GLO verifies the 2048 prospective GL member's signature on the inner most 2049 SignedData.PKIData and the GLA's signature on the outer layer. 2050 If an EnvelopedData encapsulates the inner most layer (see 2051 paragraph 3.2.1.2 or 3.2.2), the GLO MUST decrypt the outer 2052 layer prior to verifying the signature on the inner most 2053 SignedData. 2055 a - If the signature(s) does(do) not verify, the GLO MUST return 2056 a response indicating CMCFailInfo.badMessageCheck. 2058 b - If the signature(s) does(do) verify, the GLO MUST check to 2059 make sure the name in one of the certificates used to sign 2060 the request is the entity indicated in glMembersToDelete. 2062 1 - If the names do not match, the GLO may send a message 2063 back, which is out of scope, to the prospective member, 2064 depending on policy, to indicate that GL members can only 2065 add themselves lists. This stops people from adding 2066 people to GLs without their permission. 2068 2 - If the names do match, the GLO deletes the member from the 2069 GL by sending the reformed GLDeleteMembers request (the 2070 prospective non-GL member's signature is stripped off and 2072 Turner 41 2073 the GLO signs it) to the GLA (1 in Figure 6). The GLO MUST 2074 make sure the glMemberName is already on the list and only 2075 on the list once. The GLO MUST also generate a GLRekey 2076 request and include it with the GLDeleteMember request 2077 (see paragraph 4.5). 2079 a - The GLO MUST apply confidentiality to the new 2080 GLDeleteMember request by encapsulating the 2081 SignedData.PKIData in an EnvelopedData if the initial 2082 request was encapsulated in an EnvelopedData (see 2083 paragraph 3.2.1.2). 2085 b - The GLO MAY also optionally apply another SignedData 2086 over the EnvelopedData (see paragraph 3.2.1.2). 2088 4 - Further processing is as in 2 of paragraph 4.4.1. 2090 4.5 Request Rekey Of GL 2092 From time to time the GL will need to be rekeyed. Some situations 2093 are as follows: 2095 - When a member is removed from a closed or managed GL. In this 2096 case, the PKIData.controlSequence containing the GLDeleteMembers 2097 should contain a GLRekey request. 2099 - Depending on policy, when a member is removed from an unmanaged 2100 GL. If the policy is to rekey the GL, the 2101 PKIData.controlSequence containing the GLDeleteMembers could 2102 also contain a GLRekey request or an out of bands means could be 2103 used to tell the GLA to rekey the GL. Rekeying of unmanaged GLs 2104 when members are deleted is not advised. 2106 - When the current shared KEK has been compromised. The GLA will 2107 automatically perform an rekey without waiting for approval from 2108 the GLO. 2110 - When the current shared KEK is about to expire. 2112 - If the GLO controls the GL rekey, the GLA should not assume 2113 that a new shared KEK should be distributed, but instead wait 2114 for the GLRekey message. 2116 - If the GLA controls the GL rekey, the GLA should initiate a 2117 GLKey message as specified in paragraph 5. 2119 If the generationCounter (see paragraph 3.1.1) is set to a value 2120 greater than one (1) and the GLO controls the GL rekey, the GLO may 2121 generate a GLRekey any time before the last shared KEK has expired. 2122 To be on the safe side, the GLO should request a rekey 1 duration 2123 before the last shared KEK expires. 2125 Turner 42 2126 The GLA and GLO are the only entities allowed to initiate a GL 2127 rekey. The GLO indicated whether they are going control rekeys or 2128 whether the GLA is going to control rekeys when the assigned the 2129 shared KEK to GL (see paragraph 3.1.1). The GLO MAY initiate a GL 2130 rekey at any time. The GLA MAY be configured to automatically rekey 2131 the GL prior to the expiration of the shared KEK (the length of time 2132 before the expiration is an implementation decision). Figure 7 2133 depicts the protocol interactions to request a GL rekey. Note that 2134 error messages are not depicted. 2136 +-----+ 1 2,A +-----+ 2137 | GLA | <-------> | GLO | 2138 +-----+ +-----+ 2140 Figure 7 - GL Rekey Request 2142 4.5.1 GLO Initiated Rekey Requests 2144 The process for GLO initiated GLRekey requests is as follows: 2146 1 - The GLO sends a SignedData.PKIData.controlSequence.GLRekey 2147 request to the GLA (1 in Figure 7). The GLO MUST include the 2148 glName and the glIdentifier. The GLO MAY include change the 2149 glOwner, glAdministration, glDistributionMethod, and 2150 glKeyAttributes. If glOwner, glAdministration, 2151 glDistributionMethod, and glKeyAttributes are omitted then 2152 there is no change from the previously registered GL values 2153 for these fields. If the GLO wants to force a rekey for all 2154 outstanding shared KEKs the glKeyAttributes.generationCounter 2155 MUST be set to zero (0) 2157 a - The GLO MAY optionally apply confidentiality to the request 2158 by encapsulating the SignedData.PKIData in an EnvelopedData 2159 (see paragraph 3.2.1.2). 2161 b - The GLO MAY also optionally apply another SignedData over 2162 the EnvelopedData (see paragraph 3.2.1.2). 2164 2 - Upon receipt of the request, the GLA verifies the signature on 2165 the inner most SignedData.PKIData. If an additional SignedData 2166 and/or EnvelopedData encapsulates the request (see paragraph 2167 3.2.1.2 or 3.2.2), the GLA MUST verify the outer signature 2168 and/or decrypt the outer layer prior to verifying the 2169 signature on the inner most SignedData. 2171 a - If the signature(s) does(do) not verify, the GLA MUST return 2172 a response indicating CMCFailInfo.badMessageCheck. 2174 b - If the signature(s) does(do) verify, the GLA MUST make sure 2175 the GL is supported by the GLA by checking that that the 2177 Turner 43 2178 combination of glName and glIdentifier matches a glName and 2179 glIdentifier combination stored on the GLA. 2181 1 - If the glName and glIdentifier present do not match a GL 2182 stored on the GLA, the GLA MUST return a response 2183 indicating 2184 GLFailInfo.errorCode.invalidGLNameGLIdentifierCombination. 2186 2 - If the glName and glIdentifier present do match a GL 2187 stored on the GLA, the GLA MUST check that a registered 2188 GLO signed the request by checking that one of the names 2189 in the certificate used to sign the request is a 2190 registered GLO. 2192 a - If the names do not match, the GLA MUST return a 2193 response indicating GLFailInfo.errorCode.noGLONameMatch. 2195 b - If all the names do match, the GLA MUST return to all 2196 GLOs a GLSucessInfo indicating the glName, the new 2197 glIdentifier, and an action.actionCode.rekeyedGL (2 in 2198 Figure 7). The GLA also uses the GLKey message to 2199 distribute the rekey shared KEK (see paragraph 5). 2201 1 - The GLA MUST apply confidentiality to response by 2202 encapsulating the SignedData.PKIData in an 2203 EnvelopedData if the request was encapsulated in an 2204 EnvelopedData (see paragraph 3.2.1.2). 2206 2 - The GLA MAY also optionally apply another SignedData 2207 over the EnvelopedData (see paragraph 3.2.1.2). 2209 3 - Upon receipt of the GLSuccessInfo or GLFailInfo response, the 2210 GLO verifies the GLA's signature(s). If an additional 2211 SignedData and/or EnvelopedData encapsulates the forwarded 2212 response (see paragraph 3.2.1.2 or 3.2.2), the GLO MUST verify 2213 the outer signature and/or decrypt the forwarded response 2214 prior to verifying the signature on the inner most SignedData. 2216 a - If the signature(s) does(do) not verify, the GLO MUST return 2217 a response indicating CMCFailInfo.badMessageCheck. 2219 b - If the signatures verifies, the GLO has successfully rekeyed 2220 the GL. 2222 c - If the GLO received a GLFailInfo, for any reason, the GLO 2223 may reattempt to rekey the GL using the information provided 2224 in the GLFailInfo response. 2226 Turner 44 2227 4.5.2 GLA Initiated Rekey Requests 2229 If the GLA is in charge of rekeying the GL or if a GLKCompromise 2230 message has been properly processed (see paragraph 4.7) the GLA will 2231 automatically issue a GLKey message (see paragraph 5). In addition 2232 the GLA will generate a GLSuccessInfo to indicate to the GL that a 2233 successful rekey has occurred. The process for GLA initiated rekey 2234 is as follows: 2236 1 _ The GLA MUST generate for all GLOs a 2237 SignedData.PKIData.controlSequence.GLSucessInfo indicating the 2238 glName, the new glIdentifier, and actionCode.rekeyedGL (A in 2239 Figure 7). 2241 a - The GLA MAY optionally apply confidentiality to the request 2242 by encapsulating the SignedData.PKIData in an EnvelopedData 2243 (see paragraph 3.2.1.2). 2245 b - The GLA MAY also optionally apply another SignedData over 2246 the EnvelopedData (see paragraph 3.2.1.2). 2248 2 - Upon receipt of the GLSuccessInfo response, the GLO verifies 2249 the GLA's signature(s). If an additional SignedData and/or 2250 EnvelopedData encapsulates the forwarded response (see 2251 paragraph 3.2.1.2 or 3.2.2), the GLO MUST verify the outer 2252 signature and/or decrypt the outer layer prior to verifying 2253 the signature on the inner most SignedData. 2255 a - If the signatures do not verify, the GLO MUST return a 2256 response indicating CMCFailInfo.badMessageCheck. 2258 b - If the signatures verifies, the GLO knows the GLA has 2259 successfully rekeyed the GL. 2261 4.6 Change GLO 2263 Management of managed and closed GLs can become difficult for one 2264 GLO if the GL membership grows large. To support distributing the 2265 workload, GLAs support having GL be managed by multiple GLOs. The 2266 GLAddOwners and GLRemoveOwners messages are designed to support 2267 adding and removing registered GLOs. Figure depicts the protocol 2268 interactions to send GLAddOwners and GLRemoveOwners messages and the 2269 resulting response messages. 2271 +-----+ 1 2 +-----+ 2272 | GLA | <-------> | GLO | 2273 +-----+ +-----+ 2275 Figure 8 _ GLO Add & Delete Owners 2277 Turner 45 2278 The process for GLAddOwners and GLDeleteOwners is as follows: 2280 1 - The GLO sends a SignedData.PKIData.controlSequence.GLAddOwners 2281 or GLRemoveOwners request to the GLA (1 in Figure 8). The GLO 2282 MUST include: the GL name in glName, the GLO(s) in glOwner. 2283 The GLO MAY also include the glIdentifier. 2285 a - The GLO MAY optionally apply confidentiality to the request 2286 by encapsulating the SignedData.PKIData in an EnvelopedData 2287 (see paragraph 3.2.1.2). 2289 b - The GLO MAY also optionally apply another SignedData over 2290 the EnvelopedData (see paragraph 3.2.1.2). 2292 2 _ Upon receipt of the GLAddOwners or GLRemoveOwners request, the 2293 GLA verifies the GLO's signature(s). If an additional 2294 SignedData and/or EnvelopedData encapsulates the request (see 2295 paragraph 3.2.1.2 or 3.2.2), the GLA MUST verify the outer 2296 signature and/or decrypt the outer layer prior to verifying 2297 the signature on the inner most SignedData. 2299 a - If the signature(s) does(do) not verify, the GLA MUST return 2300 a response indicating CMCFailInfo.badMessageCheck. 2302 b - If the signature(s) does(do) verify, the GLA MUST make sure 2303 the GL is supported by checking either that the glName is 2304 supported (in the case the glIdentifier is omitted) or that 2305 the combination of glName and glIdentifier matches a glName 2306 and glIdentifier combination stored on the GLA. 2308 1 - If the glIdentifier is omitted and the glName is not 2309 supported by the GLA, the GLA MUST return a response 2310 indicating GLFailInfo.errorCode.invalidGLName. 2312 2 - If the glName and glIdentifier are present and do not 2313 match a GL stored on the GLA, the GLA MUST return a 2314 response indicating 2315 GLFailInfo.errorCode.invalidGLNameGLIdentifierCombination. 2317 3 - If the glIdentifier is omitted and the glName is supported 2318 by the GLA or if the glIdentifier/glName combination is 2319 supported by the GLA, the GLA MUST ensure a registered GLO 2320 signed the GLAddOwners or GLRemoveOwners request by 2321 checking if the name present in the digital signature 2322 certificate used to sign the GLDelete request matches one 2323 of the registered GLOs. 2325 a - If the names do not match, the GLA MUST return a 2326 response indicating GLFailInfo.errorCode.noGLONameMatch. 2328 b - If the names do match, the GLA MUST return to all GLOs a 2329 GLSucessInfo indicating the glName, the corresponding 2331 Turner 46 2332 glIdentifier, an action.actionCode.addedGLO or 2333 removedGLO, and the respective GLO name in glOwnerName 2334 (2 in Figure 4). The GLA MUST also take administrative 2335 actions to associate the new glOwner name with the GL in 2336 the case of GLAddOwners or to disassociate the old 2337 glOwner name with the GL in the cased of GLRemoveOwners. 2339 1 - The GLA MUST apply confidentiality to the response by 2340 encapsulating the SignedData.PKIResponse in an 2341 EnvelopedData if the request was encapsulated in an 2342 EnvelopedData (see paragraph 3.2.1.2). 2344 2 - The GLA MAY also optionally apply another SignedData 2345 over the EnvelopedData (see paragraph 3.2.1.2). 2347 a - The GLO MAY optionally apply confidentiality to the request 2348 by encapsulating the SignedData.PKIData in an EnvelopedData 2349 (see paragraph 3.2.1.2). 2351 b - The GLO MAY also optionally apply another SignedData over 2352 the EnvelopedData (see paragraph 3.2.1.2). 2354 3 - Upon receipt of the GLSuccessInfo or GLFailInfo response, the 2355 GLO verifies the GLA's signature(s). If an additional SignedData 2356 and/or EnvelopedData encapsulates the response (see paragraph 2357 3.2.1.2 or 3.2.2), the GLO MUST verify the outer signature 2358 and/or decrypt the outer layer prior to verifying the signature 2359 on the inner most SignedData. 2361 a - If the signature(s) does(do) not verify, the GLO MUST return a 2362 response indicating CMCFailInfo.badMessageCheck. 2364 b - If the signatures do verify and the response was 2365 GLSuccessInfo, the GLO has successfully added or removed the 2366 GLO. 2368 c - If the signatures do verify and the response was GLFailInfo, 2369 the GLO MAY reattempt to add or delete the GLO using the 2370 information provided in the GLFailInfo response. 2372 4.7 Indicate KEK Compromise 2374 The will be times when the shared KEK is compromised. The GL members 2375 use the GLKCompromise message to tell the GLA that the shared KEK 2376 has been compromised. Figure 9 depicts the protocol interactions for 2377 GL Key Compromise. 2379 Turner 47 2380 +-----+ 2 3 +----------+ 2381 | GLO | <--------+ +-------> | Member 1 | 2382 +-----+ | | +----------+ 2383 +-----+ ---------+ | 3 +----------+ 2384 | GLA | 1 +-------> | ... | 2385 +-----+ <-------------+ +----------+ 2386 | 3 +----------+ 2387 +-------> | Member n | 2388 +----------+ 2390 Figure 9 - GL Key Compromise 2392 The process for GLKCompromise is as follows: 2394 1 - The GL member sends a 2395 SignedData.PKIData.controlSequence.GLKCompromise request to 2396 the GLA (1 in Figure 9). The GL member MUST include glName and 2397 MAY include glIdentifier. 2399 a - The GL member MAY optionally apply confidentiality to the 2400 request by encapsulating the SignedData.PKIData in an 2401 EnvelopedData (see paragraph 3.2.1.2). 2403 b - The GL member MAY also optionally apply another SignedData 2404 over the EnvelopedData (see paragraph 3.2.1.2). 2406 2 _ Upon receipt of the GLKCompromise requst, the GLA verifies the 2407 GL member's signature(s). If an additional SignedData and/or 2408 EnvelopedData encapsulates the request (see paragraph 3.2.1.2 2409 or 3.2.2), the GLA MUST verify the outer signature and/or 2410 decrypt the outer layer prior to verifying the signature on 2411 the inner most SignedData. 2413 a - If the signature(s) does(do) not verify, the GLA MUST return 2414 a response indicating CMCFailInfo.badMessageCheck. 2416 b - If the signature(s) does(do) verify, the GLA MUST make sure 2417 the GL is supported by checking either that the glName is 2418 supported (in the case the glIdentifier is omitted) or that 2419 the combination of glName and glIdentifier matches a glName 2420 and glIdentifier combination stored on the GLA. 2422 1 - If the glIdentifier is omitted and the glName is not 2423 supported by the GLA, the GLA MUST return a response 2424 indicating GLFailInfo.errorCode.invalidGLName. 2426 2 - If the glName and glIdentifier are present and do not 2427 match a GL stored on the GLA, the GLA MUST return a 2428 response indicating 2429 GLFailInfo.errorCode.invalidGLNameGLIdentifierCombination. 2431 Turner 48 2432 3 - If the glIdentifier is omitted and the glName is supported 2433 by the GLA or if the glIdentifier/glName combination is 2434 supported by the GLA, the GLA MUST ensure the GL member is 2435 on the GL. 2437 a - If one of the names in the certificate used to sign the 2438 GLKCompromise is not present on the GL, the GLA MUST 2439 return a response indicating 2440 GLFailInfo.errorCode.noSpam. 2442 b - If one of the names in the certificate used to sign the 2443 GLKCompromise is present on the GL, the GLA MUST: 2445 1 _ Generate a PKIData.cmsSequence for all GLOs (2 in 2446 Figure 9) containing the original GLKCompromise 2447 message and a PKIResponse.GLSuccessInfo indicating the 2448 glName, new glIdentifier, and an action.actionCode of 2449 rekeyedGL. 2451 2 _ Generate a GLKey message as described in paragraph 2452 5.1.2 to rekey the GL (3 in Figure 9) 2454 4.8 Request KEK Refresh 2456 The will be times when the GL members have misplaced their shared 2457 KEK. In this the shared KEK is not compromised and a rekey of the 2458 entire GL is not necessary. The GL members use the GLKRefresh 2459 message to request that the shared KEK(s) be redistributed to them. 2460 Figure 10 depicts the protocol interactions for GL Key Refresh. 2462 2 +----------+ 2463 +-------> | Member 1 | 2464 | +----------+ 2465 +-----+ 1 | 2 +----------+ 2466 | GLA | <---+-------> | ... | 2467 +-----+ | +----------+ 2468 | 2 +----------+ 2469 +-------> | Member n | 2470 +----------+ 2472 Figure 10 - GL KEK Refresh 2474 The process for GLKRefresh is as follows: 2476 1 - The GL member sends a 2477 SignedData.PKIData.controlSequence.GLKRefresh request to the 2478 GLA (1 in Figure 10). The GL member MUST include glName and 2479 MAY include glIdentifier. 2481 Turner 49 2482 a - The GL member MAY optionally apply confidentiality to the 2483 request by encapsulating the SignedData.PKIData in an 2484 EnvelopedData (see paragraph 3.2.1.2). 2486 b - The GL member MAY also optionally apply another SignedData 2487 over the EnvelopedData (see paragraph 3.2.1.2). 2489 2 _ Upon receipt of the GLKRefresh request, the GLA verifies the 2490 GL member's signature(s). If an additional SignedData and/or 2491 EnvelopedData encapsulates the request (see paragraph 3.2.1.2 2492 or 3.2.2), the GLA MUST verify the outer signature and/or 2493 decrypt the outer layer prior to verifying the signature on 2494 the inner most SignedData. 2496 a - If the signature(s) does(do) not verify, the GLA MUST return 2497 a response indicating CMCFailInfo.badMessageCheck. 2499 b - If the signature(s) does(do) verify, the GLA MUST make sure 2500 the GL is supported by checking either that the glName is 2501 supported (in the case the glIdentifier is omitted) or that 2502 the combination of glName and glIdentifier matches a glName 2503 and glIdentifier combination stored on the GLA. 2505 1 - If the glIdentifier is omitted and the glName is not 2506 supported by the GLA, the GLA MUST return a response 2507 indicating GLFailInfo.errorCode.invalidGLName. 2509 2 - If the glName and glIdentifier are present and do not 2510 match a GL stored on the GLA, the GLA MUST return a 2511 response indicating 2512 GLFailInfo.errorCode.invalidGLNameGLIdentifierCombination. 2514 3 - If the glIdentifier is omitted and the glName is supported 2515 by the GLA or if the glIdentifier/glName combination is 2516 supported by the GLA, the GLA MUST ensure the GL member is 2517 on the GL. 2519 a - If the glMemberName is not present on the GL, the GLA 2520 MUST return a response indicating 2521 GLFailInfo.errorCode.noSpam. 2523 b - If the glMemberName is present on the GL, the GLA MUST 2524 return a GLKey message (2 in Figure 10) as described in 2525 paragraph 5.1.3. 2527 4.9 GLA Query Request and Response 2529 There will be certain times when a GLO is having trouble setting up 2530 a GLO because they do not know the algorithm(s) or distribution 2531 method(s) the GLA supports. The GLAQueryRequest and GLAQueryResponse 2532 message have been defined to support the GLO determining this 2534 Turner 50 2535 information. Figure 11 depicts the protocol interactions for 2536 GLAQueryRequest and GLAQueryResponse. 2538 +-----+ 1 2 +-----+ 2539 | GLA | <-------> | GLO | 2540 +-----+ +-----+ 2542 Figure 11 - GLA Query Request & Response 2544 The process for GLAQueryRequest and GLAQueryResponse is as follows: 2546 1 - The GLO sends a 2547 SignedData.PKIData.controlSequence.GLAQueryRequest request to 2548 the GLA (1 in Figure 11). The GLO indicates whether they are 2549 interested in determining what algorithms the GLA supports or 2550 what distributionMethods the GLA support or both. 2552 a - The GLO MAY optionally apply confidentiality to the request 2553 by encapsulating the SignedData.PKIData in an EnvelopedData 2554 (see paragraph 3.2.1.2). 2556 b - The GLO MAY also optionally apply another SignedData over 2557 the EnvelopedData (see paragraph 3.2.1.2). 2559 2 _ Upon receipt of the GLQueryRequest, the GLA determines if it 2560 accepts GLAQueryRequests. 2562 a - If the GLA does not accept GLAQueryRequests, the GLA MUST 2563 return a response indicating GLFailInfo.unspecified. 2565 b - If the GLA does accept GLAQueryReuests, the GLA MUST verify 2566 the GLO's signature(s). If an additional SignedData and/or 2567 EnvelopedData encapsulates the request (see paragraph 2568 3.2.1.2 or 3.2.2), the GLA MUST verify the outer signature 2569 and/or decrypt the outer layer prior to verifying the 2570 signature on the inner most SignedData. 2572 1 - If the signature(s) does(do) not verify, the GLA MUST 2573 return a response indicating CMCFailInfo.badMessageCheck. 2575 2 - If the signature(s) does(do) verify, the GLA MUST return a 2576 GLAQueryResponse (2 in Figure 11) indicating the 2577 supportedAlgorithms, the distributionMethod, or both. 2579 a - The GLA MUST apply confidentiality to the response by 2580 encapsulating the SignedData.PKIResponse in an 2581 EnvelopedData if the request was encapsulated in an 2582 EnvelopedData (see paragraph 3.2.1.2). 2584 b - The GLA MAY also optionally apply another SignedData 2585 over the EnvelopedData (see paragraph 3.2.1.2). 2587 Turner 51 2588 3 - Upon receipt of the GLAQueryResponse, the GLO verifies the 2589 GLA's signature(s). If an additional SignedData and/or 2590 EnvelopedData encapsulates the response (see paragraph 3.2.1.2 2591 or 3.2.2), the GLO MUST verify the outer signature and/or 2592 decrypt the outer layer prior to verifying the signature on 2593 the inner most SignedData. 2595 a - If the signature(s) does(do) not verify, the GLO MUST return 2596 a response indicating CMCFailInfo.badMessageCheck. 2598 b - If the signatures do verify and the response was 2599 GLAQueryResponse, the GLO may use the information contained 2600 therein to attempt to setup a GL or modify an existing GL. 2602 5 Distribution Message 2604 The GLA uses the GLKey message to distribute new, shared KEK(s) 2605 after receiving GLAddMembers, GLDeleteMembers (for closed and 2606 managed GLs), GLRekey, GLKCompromise, or GLKRefresh requests and 2607 returning a GLSucessInfo response for the respective request. Figure 2608 12 depicts the protocol interactions to send out GLKey messages. The 2609 procedures defined in this paragraph MUST be implemented. 2611 1 +----------+ 2612 +-------> | Member 1 | 2613 | +----------+ 2614 +-----+ | 1 +----------+ 2615 | GLA | ----+-------> | ... | 2616 +-----+ | +----------+ 2617 | 1 +----------+ 2618 +-------> | Member n | 2619 +----------+ 2621 Figure 12 - GL Key Distribution 2623 If the GL was setup with GLKeyAttributes.recipientsMutuallyAware set 2624 to FALSE, a separate GLKey message MUST be sent to each GL member so 2625 as to not divulge information about the other GL members. 2627 When the GLKey message is generated as a result of a: 2628 - GLAddMembers request, 2629 - GLKComrpomise indicate, 2630 - GLKRefresh request, 2631 - GLDeleteMembers request with the the GL's glAdministration set 2632 to managed or closed, 2633 - GLKRekey request with generationCounter set to zero (0) 2634 The GLA MUST use either the kari (see paragraph 12.3.2 of CMS [2]) 2635 or ktri (see paragraph 12.3.1 of CMS [2]) choice in 2636 GLKey.glkWrapped.RecipientInfo to ensure only the intended 2638 Turner 52 2639 recipients receive the shared KEK. The GLA MUST support the 2640 RecipientInfo.kari choice. 2642 When the GLKey message is generated as a result of a GLRekey request 2643 with generationCounter greater than zero (0) or when the GLA 2644 controls rekeys, the GLA MAY use the kari, ktri, or kekri (see 2645 paragraph 12.3.3 of CMS [2]) in GLKey.glkWrapped.RecipientInfo to 2646 ensure only the intended recipients receive the shared KEK. The GLA 2647 MUST support the RecipientInfo.kari choice. 2649 5.1 Distribution Process 2651 When a GLKey message is generated the process is as follows: 2653 1 _ The GLA MUST send a SignedData.PKIData.controlSequence.GLKey 2654 to each member by including: glName, glIdentifier, glkWrapped, 2655 glkAlgorithm, glkNotBefore, and glkNotAfter. 2657 **Need to be more detailed on how the values are derived as it 2658 depends on why and when the GLKey message is generated** 2660 a - The GLA MAY optionally apply another confidentiality layer 2661 to the message by encapsulating the SignedData.PKIData in 2662 another EnvelopedData (see paragraph 3.2.1.2). 2664 b - The GLA MAY also optionally apply another SignedData over 2665 the EnvelopedData.SignedData.PKIData (see paragraph 2666 3.2.1.2). 2668 2 - Upon receipt of the message, the GL members MUST verify the 2669 signature over the inner most SignedData.PKIData. If an 2670 additional SignedData and/or EnvelopedData encapsulates the 2671 message (see paragraph 3.2.1.2 or 3.2.2), the GL Member MUST 2672 verify the outer signature and/or decrypt the outer layer 2673 prior to verifying the signature on the 2674 SignedData.PKIData.controlSequence.GLKey. 2676 a - If the signature(s) does(do) not verify, the GL member MUST 2677 return a response indicating CMCFailInfo.badMessageCheck. 2679 b - If the signature(s) does(do) verify, the GL member process 2680 the RecipientInfos according to CMS [2]. Once unwrapped the 2681 GL member should store the shared KEK in a safe place. When 2682 stored, the glName, glIdentifier, and shared KEK should be 2683 associated. 2685 6 Key Wrapping 2687 In the mechanisms described in paragraphs 5, the group key being 2688 distributed, in an EnvelopedData, MUST be protected by a key of 2689 equal or greater length (i.e., if a RC2 128-bit key is being 2691 Turner 53 2692 distributed a key of 128-bits or greater must be used to protect the 2693 key). 2695 7 Algorithms 2697 Triple-DES is mandatory other are optional. 2699 8 Transport 2701 SMTP must be supported. 2703 9 Using the Group Key 2705 [Put in here how this can be used with SMIME MLAs.] 2707 10 Schema Requirements 2709 [I think we need to specify some MAYs for support of object classes, 2710 etc. to support location of the GL and GLO in a repository. There 2711 are really two choices for the GL mhsDistributionList from RFC 1274 2712 and addresslist from an Internet-Draft in the LDAPEXT WG. The only 2713 reason I can think of not using the one from RFC 1274 is that a MUST 2714 CONTAIN is mhsORAddress and we're should support SMTP. addressList 2715 (in the ID) doesn't have mhsORAddress as a must contain. The Owner 2716 in the both object classes though has the syntax directoryName. We 2717 might have to roll attribute for the Owner because I think it should 2718 probably have the GeneralName syntax instead of just directoryName.] 2720 [We can also define attributes that can be used to store the group 2721 key encrypted for an individual group member and for the encrypted 2722 object. Does anyone think this is useful/needed?] 2724 11 Security Considerations 2726 Don't have too many GLOs because they could start willie nillie 2727 adding people you don't like. 2729 Need to rekey closed and managed GLs if a member is deleted. 2731 GL members have to store some kind of information about who 2732 distributed the shared KEK to them so that they can make sure 2733 subsequent rekeys are originated from the same entity. 2735 Need to make sure you don't make the key size too small and duration 2736 long because people will have more time to attack the key. 2738 Need to make sure you don't make the generationCounter to large 2739 because then people can attack the last key. 2741 Turner 54 2742 12 References 2744 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 2745 9, RFC 2026, October 1996. 2747 2 Housley, R., "Cryptographic Message Syntax," RFC 2630, June 1999. 2749 3 Myers, M., Liu, X., Schadd, J., Weinsten, J., "Certificate 2750 Management Message over CMS," draft-ietf-pkix-cmc-05.txt, July 2751 1999. 2753 4 Bradner, S., "Key words for use in RFCs to Indicate Requirement 2754 Levels", BCP 14, RFC 2119, March 1997. 2756 5 Housley, R., Ford, W., Polk, W. and D. Solo, "Internet X.509 2757 Public Key Infrastructure: Certificate and CRL Profile", RFC 2758 2459, January 1999. 2760 13 Acknowledgements 2762 Thanks to Russ Housley and Jim Schaad for providing much of the 2763 background and review required to write this draft. 2765 14 Author's Addresses 2767 Sean Turner 2768 IECA, Inc. 2769 9010 Edgepark Road 2770 Vienna, VA 22182 2771 Phone: +1.703.628.3180 2772 Email: turners@ieca.com 2774 Expires January 14, 2001 2776 Turner 55