idnits 2.17.1 draft-ietf-smime-symkeydist-06.txt: -(919): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(951): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1537): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1765): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(2071): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(2104): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(2226): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(2460): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(2493): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(2735): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(3023): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(3027): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(3207): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(3281): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(3343): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(3346): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(3504): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(3565): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. == There are 77 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([2], [3]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 370 has weird spacing: '...esponse id-...' == Line 2813 has weird spacing: '...ame and glOwn...' -- 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 (August 2001) is 8289 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 3734 looks like a reference -- Missing reference section? '2' on line 3831 looks like a reference -- Missing reference section? '3' on line 3736 looks like a reference -- Missing reference section? '4' on line 3737 looks like a reference -- Missing reference section? '0' on line 3733 looks like a reference -- Missing reference section? '5' on line 3707 looks like a reference -- Missing reference section? '6' on line 3710 looks like a reference -- Missing reference section? '7' on line 3804 looks like a reference -- Missing reference section? '8' on line 1094 looks like a reference -- Missing reference section? '9' on line 1135 looks like a reference -- Missing reference section? '10' on line 3472 looks like a reference -- Missing reference section? '11' on line 3473 looks like a reference -- Missing reference section? '12' on line 3490 looks like a reference -- Missing reference section? '13' on line 3497 looks like a reference Summary: 5 errors (**), 0 flaws (~~), 5 warnings (==), 16 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-06.txt August 2001 4 Expires: January 20, 2001 6 CMS Symmetric Key Management and Distribution 8 Status of this Memo 10 This document is an Internet-Draft and is in full conformance with 11 all provisions of Section 10 of RFC2026 [1]. 13 This document is an Internet-Draft. Internet-Drafts are working 14 documents of the Internet Engineering Task Force (IETF), its areas, 15 and its working groups. Note that other groups may also distribute 16 working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six 19 months and may be updated, replaced, or obsoleted by other documents 20 at any time. It is inappropriate to use Internet-Drafts as reference 21 material or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 This draft is being discussed on the 'ietf-smime' mailing list. To 30 subscribe, send a message to ietf-smime-request@imc.org with the 31 single word subscribe in the body of the message. There is a Web 32 site for the mailing list at . 34 Abstract 36 This document describes a mechanism to manage (i.e., setup, 37 distribute, and rekey) keys used with symmetric cryptographic 38 algorithms. Also defined herein is a mechanism to organize users 39 into groups to support distribution of encrypted content using 40 symmetric cryptographic algorithms. The mechanism uses the 41 Cryptographic Message Syntax (CMS) protocol [2] and Certificate 42 Management Message over CMS (CMC) protocol [3] to manage the 43 symmetric keys. Any member of the group can then later use this 44 distributed shared key to decrypt other CMS encrypted objects with 45 the symmetric key. This mechanism has been developed to support 46 S/MIME Mail List Agents (MLAs). 48 Turner 1 49 And Distribution 51 Conventions used in this document 53 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 54 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 55 document are to be interpreted as described in RFC-2119 [4]. 57 1. INTRODUCTION....................................................3 58 1.1 APPLICABILITY TO E-MAIL........................................4 59 1.2 APPLICABILITY TO REPOSITORIES..................................4 60 1.3 USING THE GROUP KEY............................................4 61 2. ARCHITECTURE....................................................5 62 3. PROTOCOL INTERACTIONS...........................................6 63 3.1 CONTROL ATTRIBUTES.............................................7 64 3.1.1 GL USE KEK...................................................9 65 3.1.2 DELETE GL...................................................12 66 3.1.3 ADD GL MEMBER...............................................12 67 3.1.4 DELETE GL MEMBER............................................14 68 3.1.5 REKEY GL....................................................14 69 3.1.6 ADD GL OWNER................................................15 70 3.1.7 REMOVE GL OWNER.............................................15 71 3.1.8 GL KEY COMPROMISE...........................................16 72 3.1.9 GL KEY REFRESH..............................................16 73 3.1.10 GLA QUERY REQUEST AND RESPONSE.............................17 74 3.1.10.1 GLA QUERY REQUEST........................................17 75 3.1.10.2 GLA QUERY RESPONSE.......................................17 76 3.1.10.3 REQUEST AND RESPONSE TYPES...............................17 77 3.1.12 PROVIDE CERT...............................................18 78 3.1.13 UPDATE CERT................................................18 79 3.1.14 GL KEY.....................................................19 80 3.2 USE OF CMC, CMS, AND PKIX.....................................21 81 3.2.1 PROTECTION LAYERS...........................................21 82 3.2.1.1 MINIMUM PROTECTION........................................22 83 3.2.1.2 ADDITIONAL PROTECTION.....................................22 84 3.2.2 COMBINING REQUESTS AND RESPONSES............................23 85 3.2.3 GLA GENERATED MESSAGES......................................24 86 3.2.4 CMC CONTROL ATTRIBUTES......................................25 87 3.2.4.1 USING CMCSTATUSINFOEX.....................................25 88 3.2.4.2 USING TRANSACTIONID.......................................28 89 3.2.4.3 USING NONCES..............................................28 90 3.2.4.4 CMC ATTRIBUTE SUPPORT REQUIREMENTS........................28 91 3.2.5 RESUBMITTED GL MEMBER MESSAGES..............................29 92 3.2.6 PKIX CERTIFICATE AND CRL PROFILE............................29 93 4 ADMINISTRATIVE MESSAGES.........................................29 94 4.1 ASSIGN KEK TO GL..............................................29 95 4.2 DELETE GL FROM GLA............................................32 96 4.3 ADD MEMBERS TO GL.............................................34 97 4.3.1 GLO INITIATED ADDITIONS.....................................35 98 4.3.2 PROSPECTIVE MEMBER INITIATED ADDITIONS......................41 99 4.4 DELETE MEMBERS FROM GL........................................43 100 4.4.1 GLO INITIATED DELETIONS.....................................44 101 4.4.2 MEMBER INITIATED DELETIONS..................................48 102 4.5 REQUEST REKEY OF GL...........................................49 104 Turner 2 105 And Distribution 107 4.5.1 GLO INITIATED REKEY REQUESTS................................50 108 4.5.2 GLA INITIATED REKEY REQUESTS................................53 109 4.6 CHANGE GLO....................................................53 110 4.7 INDICATE KEK COMPROMISE.......................................55 111 4.7.1 GL MEMBER INITIATED KEK COMPROMISE MESSAGE..................56 112 4.7.2 GLO INITIATED KEK COMPROMISE MESSAGE........................57 113 4.8 REQUEST KEK REFRESH...........................................58 114 4.9 GLA QUERY REQUEST AND RESPONSE................................59 115 4.10 UPDATE MEMBER CERTIFICATE....................................61 116 4.10.1 GLO AND GLA INITIATED UPDATE MEMBER CERTIFICATE............61 117 4.10.2 GL MEMBER INITIATED UPDATE MEMBER CERTIFICATE..............63 118 5 DISTRIBUTION MESSAGE............................................64 119 5.1 DISTRIBUTION PROCESS..........................................65 120 6 ALGORITHMS......................................................66 121 6.1 KEK GENERATION ALGORITHM......................................66 122 6.2 SHARED KEK WRAP ALGORITHM.....................................66 123 6.3 SHARED KEK ALGORITHM..........................................66 124 7 MESSAGE TRANSPORT...............................................67 125 8 SECURITY CONSIDERATIONS.........................................67 126 9 REFERENCES......................................................67 127 10 ACKNOWLEDGEMENTS...............................................68 128 11 AUTHOR'S ADDRESSES.............................................69 129 ANNEX A: ASN.1 MODULE.............................................70 131 1. Introduction 133 With the ever-expanding use of secure electronic communications 134 (e.g., S/MIME [2]), users require a mechanism to distribute 135 encrypted data to multiple recipients (i.e., a group of users). 136 There are essentially two ways to encrypt the data for recipients: 137 using asymmetric algorithms with public key certificates (PKCs) or 138 symmetric algorithms with symmetric keys. 140 With asymmetric algorithms, the originator forms an originator- 141 determined content-encryption key (CEK) and encrypts the content, 142 using a symmetric algorithm. Then, using an asymmetric algorithm and 143 the recipient's PKCs, the originator generates per-recipient 144 information that either (a) encrypts the CEK for a particular 145 recipient (ktri ReipientInfo CHOICE), or (b) transfers sufficient 146 parameters to enable a particular recipient to independently 147 generate the same KEK (kari RecipientInfo CHOICE). If the group is 148 large, processing of the per-recipient information may take quite 149 some time, not to mention the time required to collect and validate 150 the PKCs for each of the recipients. Each recipient identifies their 151 per-recipient information and uses the private key associated with 152 the public key of their PKC to decrypt the CEK and hence gain access 153 to the encrypted content. 155 With symmetric algorithms, the origination process is slightly 156 different. Instead of using PKCs, the originator uses a previously 157 distributed secret key-encryption key (KEK) to encrypt the CEK 159 Turner 3 160 And Distribution 162 (kekri RecipientInfo CHOICE). Only one copy of the encrypted CEK is 163 required because all the recipients already have the shared KEK 164 needed to decrypt the CEK and hence gain access to the encrypted 165 content. 167 The security provided by the shared KEK is only as good as the sum 168 of the techniques employed by each member of the group to keep the 169 KEK secret from nonmembers. These techniques are beyond the scope of 170 this document. Only the members of the list and the key manager 171 should have the KEK in order to maintain confidentiality. Access 172 control to the information protected by the KEK is determined by the 173 entity that encrypts the information, as all members of the group 174 have access. If the entity that is performing the encryption wants 175 to ensure some subset of the group does not gain access to the 176 information either a different KEK should be used (shared only with 177 this smaller group) or asymmetric algorithms should be used. 179 1.1 Applicability to E-mail 181 One primary audience for this distribution mechanism is e-mail. 182 Distribution lists, sometimes referred to as mail lists, support the 183 distribution of messages to recipients subscribed to the mail list. 184 There are two models for how the mail list can be used. If the 185 originator is a member of the mail list, the originator sends 186 messages encrypted with the shared KEK to the mail list (e.g., 187 listserv or majordomo) and the message is distributed to the mail 188 list members. If the originator is not a member of the mail list 189 (does not have the shared KEK), the originator sends the message 190 (encrypted for the MLA) to the mail list agent (MLA), and then the 191 MLA uses the shared KEK to encrypt the message for the members. In 192 either case the recipients of the mail list use the previously 193 distributed-shared KEK to decrypt the message. 195 1.2 Applicability to Repositories 197 Objects can also be distributed via a repository (e.g., Light Weight 198 Directory Protocol (LDAP) servers, X.500 Directory System Agents 199 (DSAs), Web-based servers). If an object is stored in a repository 200 encrypted with a symmetric key algorithm, any one with the shared 201 KEK and access to that object can then decrypt that object. The 202 encrypted object and the encrypted, shared KEK can be stored in the 203 repository. 205 1.3 Using the Group Key 207 This document was written with three specific scenarios in mind: two 208 supporting mail list agents and one for general message 209 distribution. Scenario 1 depicts the originator sending a public key 210 (PK) protected message to a MLA who then uses the shared KEK (S) to 212 Turner 4 213 And Distribution 215 redistribute the message to the members of the list. Scenario 2 216 depicts the originator sending a shared KEK protected message to a 217 MLA who then redistributes the message to the members of the list 218 (the MLA only adds additional recipients). Scenario 3 shows an 219 originator sending a shared KEK protected message to a group of 220 recipients without an intermediate MLA. 222 +----> +----> +----> 223 PK +-----+ S | S +-----+ S | S | 224 ----> | MLA | --+----> ----> | MLA | --+----> ----+----> 225 +-----+ | +-----+ | | 226 +----> +----> +----> 228 Scenario 1 Scenario 2 Scenario 3 230 2. Architecture 232 Figure 1 depicts the architecture to support symmetric key 233 distribution. The Group List Agent (GLA) supports two distinct 234 functions with two different agents: 236 - The Key Management Agent (KMA) which is responsible for 237 generating the shared KEKs. 239 - The Group Management Agent (GMA) which is responsible for 240 managing the Group List (GL) to which the shared KEKs are 241 distributed. 243 +----------------------------------------------+ 244 | Group List Agent | +-------+ 245 | +------------+ + -----------------------+ | | Group | 246 | | Key | | Group Management Agent | |<-->| List | 247 | | Management |<-->| +------------+ | | | Owner | 248 | | Agent | | | Group List | | | +-------+ 249 | +------------+ | +------------+ | | 250 | | / | \ | | 251 | +------------------------+ | 252 +----------------------------------------------+ 253 / | \ 254 +----------+ +---------+ +----------+ 255 | Member 1 | | ... | | Member n | 256 +----------+ +---------+ +----------+ 258 Figure 1 - Key Distribution Architecture 260 A GLA may support multiple KMAs. A GLA in general supports only one 261 GMA, but the GMA may support multiple GLs. Multiple KMAs may support 262 a GMA in the same fashion as GLAs support multiple KMAs. Assigning a 263 particular KMA to a GL is beyond the scope of this document. 265 Turner 5 266 And Distribution 268 Modeling real world GL implementations shows that there are very 269 restrictive GLs, where a human determines GL membership, and very 270 open GLs, where there are no restrictions on GL membership. To 271 support this spectrum, the mechanism described herein supports both 272 managed (i.e., where access control is applied) and unmanaged (i.e., 273 where no access control is applied) GLs. The access control 274 mechanism for managed lists is beyond the scope of this document. 275 Note: If the distribution for the list is performed by an entity 276 other than the originator (e.g., an MLA distributing a mail 277 message), this entity can also enforce access control rules. 279 In either case, the GL must initially be constructed by an entity 280 hereafter called the Group List Owner (GLO). There may be multiple 281 entities who 'own' the GL and who are allowed to make changes to the 282 GL�s properties or membership. The GLO determines if the GL will be 283 managed or unmanaged and is the only entity that may delete the GL. 284 GLO(s) may or may not be GL members. GLO(s) may also setup lists 285 that are closed, where the GLO solely determines GL membership. 287 Though Figure 1 depicts the GLA as encompassing both the KMA and GMA 288 functions, the two functions could be supported by the same entity 289 or they could be supported by two different entities. If two 290 entities are used, they could be located on one or two platforms. 291 There is however a close relationship between the KMA and GMA 292 functions. If the GMA stores all information pertaining to the GLs 293 and the KMA merely generates keys, a corrupted GMA could cause 294 havoc. To protect against a corrupted GMA, the KMA would be forced 295 to double check the requests it receives to ensure the GMA did not 296 tamper with them. These duplicative checks blur the functionality of 297 the two components together. For this reason, the interactions 298 between the KMA and GMA are beyond the scope of this document. 299 Proprietary mechanisms may be used to separate the functions by 300 strengthening the trust relationship between the two entities. 301 Henceforth, the distinction between the two agents is not discussed 302 further; the term GLA will be used to address both functions. It 303 should be noted that corrupt GLA can always cause havoc. 305 3. Protocol Interactions 307 There are existing mechanisms (e.g., listserv and majordomo) to 308 manage GLs; however, this document does not address securing these 309 mechanisms, as they are not standardized. Instead, it defines 310 protocol interactions, as depicted in Figure 2, used by the GL 311 members, GLA, and GLO(s) to manage GLs and distribute shared KEKs. 312 The interactions have been divided into administration messages and 313 distribution messages. The administrative messages are the request 314 and response messages needed to setup the GL, delete the GL, add 315 members to the GL, delete members of the GL, request a group rekey, 316 add owners to the GL, remove owners of the GL, indicate a group key 317 compromise, refresh a group key, interrogate the GLA, and update 318 member�s and owner�s public key certificates. The distribution 320 Turner 6 321 And Distribution 323 messages are the messages that distribute the shared KEKs. The 324 following sections describe the ASN.1 for both the administration 325 and distribution messages. Section 4 describes how to use the 326 administration messages, and section 5 describes how to use the 327 distribution messages. 329 +-----+ +----------+ 330 | GLO | <---+ +----> | Member 1 | 331 +-----+ | | +----------+ 332 | | 333 +-----+ <------+ | +----------+ 334 | GLA | <-------------+----> | ... | 335 +-----+ | +----------+ 336 | 337 | +----------+ 338 +----> | Member n | 339 +----------+ 341 Figure 2 - Protocol Interactions 343 3.1 Control Attributes 345 To avoid creating an entirely new protocol, the Certificate 346 Management Messages over CMS (CMC) protocol was chosen as the 347 foundation of this protocol. The main reason for the choice was the 348 layering aspect provided by CMC where one or more control attributes 349 are included in message, protected with CMS, to request or respond 350 to a desired action. The CMC PKIData structure is used for requests, 351 and the CMC ResponseBody structure is used for responses. The 352 content-types PKIData and PKIResponse are then encapsulated in CMS's 353 SignedData or EnvelopedData, or a combination of the two (see 354 section 3.2). The following are the control attributes defined in 355 this document: 357 Control 358 Attribute OID Syntax 359 ------------------- ----------- ----------------- 360 glUseKEK id-skd 1 GLUseKEK 361 glDelete id-skd 2 GeneralName 362 glAddMember id-skd 3 GLAddMember 363 glDeleteMember id-skd 4 GLDeleteMember 364 glRekey id-skd 5 GLRekey 365 glAddOwner id-skd 6 GLOwnerAdministration 366 glRemoveOwner id-skd 7 GLOwnerAdministration 367 glkCompromise id-skd 8 GeneralName 368 glkRefresh id-skd 9 GLKRefresh 369 glaQueryRequest id-skd 11 GLAQueryRequest 370 glaQueryResponse id-skd 12 GLAQueryResponse 371 glProvideCert id-skd 13 GLManageCert 372 glUpdateCert id-skd 14 GLManageCert 373 glKey id-skd 15 GLKey 375 Turner 7 376 And Distribution 378 In the following conformance tables, the column headings have the 379 following meanings: O for originate, R for receive, and F for 380 forward. There are three types of implementations: GLOs, GLAs, and 381 GL members. The GLO is an optional component hence all GLO O and GLO 382 R messages are optional, and GLA F messages are optional. The first 383 table includes messages that conformant implementions MUST support. 384 The second table includes messages that MAY be implemented. The 385 second table should be interpreted as follows: if the control 386 attribute is implemented by a component then it must be implemented 387 as indicated. For example, if a GLA is implemented that supports the 388 glAddMember control attribute, then it MUST support receiving the 389 glAddMember message. Note that �-� means not applicable. 391 Required 392 Implementation Requirement | Control 393 GLO | GLA | GL Member | Attribute 394 O R | O R F | O R | 395 ------- | ----------------- | --------- | ---------- 396 MAY - | MUST - MAY | - MUST | glProvideCert 397 MAY MAY | - MUST MAY | MUST - | glUpdateCert 398 - - | MUST - - | - MUST | glKey 400 Optional 401 Implementation Requirement | Control 402 GLO | GLA | GL Member | Attribute 403 O R | O R F | O R | 404 ------- | ----------------- | --------- | ---------- 405 MAY - | - MAY - | - - | glUseKEK 406 MAY - | - MAY - | - - | glDelete 407 MAY MAY | - MUST MAY | MUST - | glAddMember 408 MAY MAY | - MUST MAY | MUST - | glDeleteMember 409 MAY - | - MAY - | - - | glRekey 410 MAY - | - MAY - | - - | glAddOwner 411 MAY - | - MAY - | - - | glRemoveOwner 412 MAY MAY | - MUST MAY | MUST - | glkCompromise 413 MAY - | - MUST - | MUST - | glkRefresh 414 MAY - | - SHOULD - | MAY - | glaQueryRequest 415 - MAY | SHOULD - - | - MAY | glaQueryResponse 417 glaQueryResponse and gloResponse are carried in the CMC PKIResponse 418 content-type, all other control attributes are carried in the CMC 419 PKIData content-type. The exception is glUpdateCert which can be 420 carried in either PKIData or PKIResponse. 422 Success and failure messages use CMC (see section 3.2.4). 424 Turner 8 425 And Distribution 427 3.1.1 GL USE KEK 429 The GLO uses glUseKEK to request that a shared KEK be assigned to a 430 GL. glUseKEK messages MUST be signed by the GLO. The glUseKEK 431 control attribute has the syntax GLUseKEK: 433 GLUseKEK ::= SEQUENCE { 434 glInfo GLInfo, 435 glOwnerInfo SEQUENCE SIZE (1..MAX) OF GLOwnerInfo, 436 glAdministration GLAdministration DEFAULT 1, 437 glKeyAttributes GLKeyAttributes OPTIONAL } 439 GLInfo ::= SEQUENCE { 440 glName GeneralName, 441 glAddress GeneralName } 443 GLOwnerInfo ::= SEQUENCE { 444 glOwnerName GeneralName, 445 glOwnerAddress GeneralName, 446 certificate Certificates OPTIONAL } 448 Certificates ::= SEQUENCE { 449 pKC [0] Certificate OPTIONAL, 450 -- See PKIX [5] 451 aC [1] SEQUENCE SIZE (1.. MAX) OF 452 AttributeCertificate OPTIONAL, 453 -- See ACPROF [6] 454 certPath [2] CertificateSet OPTIONAL } 455 -- From CMS [2] 457 -- CertificateSet and CertificateChoices are included only 458 -- for illustrative purposes as they are imported from CMS [2]. 460 CertificateSet ::= SET SIZE (1..MAX) OF CertificateChoices 462 -- CertificateChoices supports X.509 public key certificates in 463 -- certificates and v2 attribute certificates in v2AttrCert. 465 GLAdministration ::= INTEGER { 466 unmanaged (0), 467 managed (1), 468 closed (2) } 470 GLKeyAttributes ::= SEQUENCE { 471 rekeyControlledByGLO [0] BOOLEAN DEFAULT FALSE, 472 recipientsNotMutuallyAware [1] BOOLEAN DEFAULT TRUE, 473 duration [2] INTEGER DEFAULT 0, 474 generationCounter [3] INTEGER DEFAULT 2, 475 requestedAlgorithm [4] AlgorithmIdentifier 476 DEFAULT id-alg-CMS3DESwrap } 478 Turner 9 479 And Distribution 481 The fields in GLUseKEK have the following meaning: 483 - glInfo indicates the name of the GL in glName and the address of 484 the GL in glAddress. The glName and glAddress can be the same, 485 but this is not always the case. Both the name and address MUST 486 be unique for a given GLA. 488 - glOwnerInfo indicates: 490 - glOwnerName indicates the name of the owner of the GL. 492 - glOwnerAddress indicates the address of the owner of the GL. 493 One of the names in glOwnerName MUST match one of the names in 494 the certificate (either the subject distinguished name or one 495 of the subject alternative names) used to sign this 496 SignedData.PKIData creating the GL (i.e., the immediate 497 signer). 499 - certificates MAY be included. It contains the following three 500 fields: 502 - certificates.pKC includes the encryption certificate for the 503 GLO. It will be used, at least initially, to encrypt the 504 shared KEK for that member. If the message is generated by a 505 GLO and they are adding another GLO (i.e., the name in one 506 of the certificates used to sign this message does not match 507 the name in glOwnerName), the pKC for the other GLO MUST be 508 included. Otherwise, the pKC MAY be included. 510 - certificates.aC MAY be included to convey any attribute 511 certificate (see AC Profile [6]) associated with the 512 encryption certificate of the GLO included in 513 certificates.pKC. 515 - certificates.certPath MAY also be included to convey 516 certificates that might aid the recipient in constructing 517 valid certification paths for the certificate provided in 518 certificates.pKC and the attribute certificates provided in 519 certificates.aC. Theses certificates are optional because 520 they might already be included elsewhere in the message 521 (e.g., in the outer CMS layer). 523 - glAdministration indicates how the GL ought to be administered. 524 The default is for the list to be managed. Three values are 525 supported for glAdministration: 527 - Unmanaged - When the GLO sets glAdministration to unmanaged, 528 they are allowing prospective members to request addition and 529 deletion from the GL without GLO intervention. 531 - Managed - When the GLO sets glAdministration to managed, they 532 are allowing prospective members to request addition and 534 Turner 10 535 And Distribution 537 deletion from the GL, but the request is redirected by the GLA 538 to GLO for review. The GLO makes the determination as to 539 whether to honor the request. 541 - Closed - When the GLO sets glAdministration to closed, they 542 are not allowing prospective members to request addition or 543 deletion from the GL. The GLA will only accept glAddMember and 544 glDeleteMember requests from the GLO. 546 - glKeyAttributes indicates the attributes the GLO wants the GLA 547 to assign to the shared KEK. If this field is omitted, GL rekeys 548 will be controlled by the GLA, the recipients are allowed to 549 know about one another, the algorithm will be Triple-DES (see 550 paragrpah 7), the shared KEK will be valid for a calendar month 551 (i.e., first of the month until the last day of the month), and 552 two shared KEKs will be distributed initially. The fields in 553 glKeyAttributes have the following meaning: 555 - rekeyControlledByGLO indicates whether the GL rekey messages 556 will be generated by the GLO or by the GLA. The default is for 557 the GLA to control rekeys. If GL rekey is controlled by the 558 GLA, the GL will continue to be rekeyed until the GLO deletes 559 the GL or changes the GL rekey to be GLO controlled. 561 - recipientsNotMutuallyAware indicates that the GLO wants the 562 GLA to distribute the shared KEK individually for each of the 563 GL members (i.e., a separate glKey message is sent to each 564 recipient). The default is for separate glKey message to not 565 be required. 567 NOTE: This supports lists where one member does not know the 568 identities of the other members. For example, a list is 569 configured granting submit permissions to only one member. All 570 other members are 'listening.' The security policy of the list 571 does not allow the members to know who else is on the list. If 572 a glKey is constructed for all of the GL members, information 573 about each of the members may be derived from the information 574 in RecipientInfos. To make sure the glkey message does not 575 divulge information about the other recipients, a separate 576 glKey message would be sent to each GL member. 578 - duration indicates the length of time (in days) during which 579 the shared KEK is considered valid. The value zero (0) 580 indicates that the shared KEK is valid for a calendar month in 581 the UTC Zulu time zone. For example if the duration is zero 582 (0), if the GL shared KEK is requested on July 24, the first 583 key will be valid until the end of July and the next key will 584 be valid for the entire month of August. If the value is not 585 zero (0), the shared KEK will be valid for the number of days 586 indicated by the value. For example, if the value of duration 587 is seven (7) and the shared KEK is requested on Monday but not 588 generated until Tuesday (2359); the shared KEKs will be valid 590 Turner 11 591 And Distribution 593 from Tuesday (2359) to Tuesday (2359). The exact time of the 594 day is determined when the key is generated. 596 - generationCounter indicates the number of keys the GLO wants 597 the GLA to distribute. To ensure uninterrupted function of the 598 GL two (2) shared KEKs at a minimum MUST be initially 599 distributed. The second shared KEK is distributed with the 600 first shared KEK, so that when the first shared KEK is no 601 longer valid the second key can be used. If the GLA controls 602 rekey then it also indicates the number of shared KEKs the GLO 603 wants outstanding at any one time. See sections 4.5 and 5 for 604 more on rekey. 606 - requestedAlgorithm indicates the algorithm and any parameters 607 the GLO wants the GLA to use with the shared KEK. The 608 parameters are conveyed via the SMIMECapabilities attribute 609 (see MSG [7]). See section 6 for more on algorithms. 611 3.1.2 Delete GL 613 GLOs use glDelete to request that a GL be deleted from the GLA. The 614 glDelete control attribute has the syntax GeneralName. The glDelete 615 message MUST be signed by the GLO. The name of the GL to be deleted 616 is included in GeneralName: 618 DeleteGL ::= GeneralName 620 3.1.3 Add GL Member 622 GLOs use the glAddMember to request addition of new members, and 623 prospective GL members use the glAddMember to request their own 624 addition to the GL. The glAddMember message MUST be signed by either 625 the GLO or the prospective GL member. The glAddMember control 626 attribute has the syntax GLAddMember: 628 GLAddMember ::= SEQUENCE { 629 glName GeneralName, 630 glMember GLMember } 632 GLMember ::= SEQUENCE { 633 glMemberName GeneralName, 634 glMemberAddress GeneralName OPTIONAL, 635 certificates Certificates OPTIONAL } 637 Turner 12 638 And Distribution 640 Certificates ::= SEQUENCE { 641 pKC [0] Certificate OPTIONAL, 642 -- See PKIX [5] 643 aC [1] SEQUENCE SIZE (1.. MAX) OF 644 AttributeCertificate OPTIONAL, 645 -- See ACPROF [6] 646 certPath [2] CertificateSet OPTIONAL } 647 -- From CMS [2] 649 -- CertificateSet and CertificateChoices are included only 650 -- for illustrative purposes as they are imported from CMS [2]. 652 CertificateSet ::= SET SIZE (1..MAX) OF CertificateChoices 654 -- CertificateChoices supports X.509 public key certificates in 655 -- certificates and v2 attribute certificates in v2AttrCert. 657 The fields in GLAddMembers have the following meaning: 659 - glName indicates the name of the GL to which the member should 660 be added. 662 - glMember indicates the particulars for the GL member. Both of 663 the following fields must be unique for a given GL: 665 - glMemberName indicates the name of the GL member. 667 - glMemberAddress indicates the GL member�s address. It MUST be 668 included. 670 Note: In some instances the glMemberName and glMemberAddress 671 may be the same, but this is not always the case. 673 - certificates MUST be included. It contains the following three 674 fields: 676 - certificates.pKC includes the member's encryption 677 certificate. It will be used, at least initially, to encrypt 678 the shared KEK for that member. If the message is generated 679 by a prospective GL member, the pKC MUST be included. If the 680 message is generated by a GLO, the pKC SHOULD be included. 682 - certificates.aC MAY be included to convey any attribute 683 certificate (see AC Profile [6]) associated with the 684 member�s encryption certificate. 686 - certificates.certPath MAY also be included to convey 687 certificates that might aid the recipient in constructing 688 valid certification paths for the certificate provided in 689 certificates.pKC and the attribute certificates provided in 690 certificates.aC. These certificates are optional because 692 Turner 13 693 And Distribution 695 they might already be included elsewhere in the message 696 (e.g., in the outer CMS layer). 698 3.1.4 Delete GL Member 700 GLOs use the glDeleteMember to request deletion of GL members, and 701 GL members use the glDeleteMember to request their own removal from 702 the GL. The glDeleteMember message MUST be signed by either the GLO 703 or the GL member. The glDeleteMember control attribute has the 704 syntax GLDeleteMember: 706 GLDeleteMember ::= SEQUENCE { 707 glName GeneralName, 708 glMemberToDelete GeneralName } 710 The fields in GLDeleteMembers have the following meaning: 712 - glName indicates the name of the GL from which the member should 713 be removed. 715 - glMemberToDelete indicates the name of the member to be deleted. 717 3.1.5 Rekey GL 719 GLOs use the glRekey to request a GL rekey. The glRekey message MUST 720 be signed by the GLO. The glRekey control attribute has the syntax 721 GLRekey: 723 GLRekey ::= SEQUENCE { 724 glName GeneralName, 725 glAdministration GLAdministration OPTIONAL, 726 glNewKeyAttributes GLNewKeyAttributes OPTIONAL, 727 glRekeyAllGLKeys BOOLEAN OPTIONAL } 729 GLNewKeyAttributes ::= SEQUENCE { 730 rekeyControlledByGLO [0] BOOLEAN OPTIONAL, 731 recipientsNotMutuallyAware [1] BOOLEAN OPTIONAL, 732 duration [2] INTEGER OPTIONAL, 733 generationCounter [3] INTEGER OPTIONAL, 734 requestedAlgorithm [4] AlgorithmIdentifier OPTIONAL } 736 The fields in GLRekey have the following meaning: 738 - glName indicates the name of the GL to be rekeyed. 740 - glAdministration indicates if there is any change to how the GL 741 should be administered. See section 3.1.1 for the three options. 743 Turner 14 744 And Distribution 746 This field is only included if there is a change from the 747 previously registered administered. 749 - glNewKeyAttributes indicates whether the rekey of the GLO is 750 controlled by the GLA or GL, what algorithm and parameters the 751 GLO wishes to use, the duration of the key, and how many 752 outstanding keys will be issued. The field is only included if 753 there is a change from the previously registered 754 glKeyAttributes. 756 - glRekeyAllGLKeys indicates whether the GLO wants all of the 757 outstanding GL�s shared KEKs rekeyed. If it is set to TRUE then 758 all outstanding KEKs MUST be issued. If it is set to FALSE then 759 all outstanding KEKs need not be resissued. 761 3.1.6 Add GL Owner 763 GLOs use the glAddOwner to request that a new GLO be allowed to 764 administer the GL. The glAddOwner message MUST be signed by a 765 registered GLO. The glAddOwner control attribute has the syntax 766 GLOwnerAdministration: 768 GLOwnerAdministration ::= SEQUENCE { 769 glName GeneralName, 770 glOwnerInfo GLOwnerInfo } 772 The fields in GLAddOwners have the following meaning: 774 - glName indicates the name of the GL to which the new GLO should 775 be associated. 777 - glOwnerInfo indicates the name, address, and certificates of the 778 new GLO. As this message includes names of new GLOs, the 779 certificates.pKC MUST be included, and it MUST include the 780 encryption certificate of the new GLO. 782 3.1.7 Remove GL Owner 784 GLOs use the glRemoveOwner to request that a GLO be disassociated 785 with the GL. The glRemoveOwner message MUST be signed by a 786 registered GLO. The glRemoveOwner control attribute has the syntax 787 GLOwnerAdministration: 789 GLOwnerAdministration ::= SEQUENCE { 790 glName GeneralName, 791 glOwnerInfo GLOwnerInfo } 793 Turner 15 794 And Distribution 796 The fields in GLRemoveOwners have the following meaning: 798 - glName indicates the name of the GL to which the GLO should be 799 disassociated. 801 - glOwnerInfo indicates the name and address of the GLO to be 802 removed. The certificates field SHOULD be omitted, as it will be 803 ignored. 805 3.1.8 GL Key Compromise 807 GL members and GLOs use glkCompromise to indicate that the shared 808 KEK possessed has been compromised. The glKeyCompromise control 809 attribute has the syntax GeneralName. This message is always 810 redirected by the GLA to the GLO for further action. The 811 glkCompromise MAY be included in an EnvelopedData generated with the 812 compromised shared KEK. The name of the GL to which the compromised 813 key is associated with is included in GeneralName: 815 GLKCompromise ::= GeneralName 817 3.1.9 GL Key Refresh 819 GL members use the glkRefresh to request that the shared KEK be 820 redistributed to them. The glkRefresh control attribute has the 821 syntax GLKRefresh. 823 GLKRefresh ::= SEQUENCE { 824 glName GeneralName, 825 dates SEQUENCE SIZE (1..MAX) OF Date } 827 Date ::= SEQUENCE { 828 start GeneralizedTime, 829 end GeneralizedTime OPTIONAL } 831 The fields in GLKRefresh have the following meaning: 833 - glName indicates the name of the GL for which the GL member 834 wants shared KEKs. 836 - dates indicates a date range for keys the GL member wants. The 837 start field indicates the first date the GL member wants and the 838 end field indicates the last date. The end date MAY be omitted 839 to indicate the GL member wants all keys from the specified 840 start date to the current date. Note that a procedural mechanism 841 is needed to restrict users from accessing messages that they 842 are not allowed to access. 844 Turner 16 845 And Distribution 847 3.1.10 GLA Query Request and Response 849 There are situations where GLOs and GL members may need to determine 850 some information from the GLA about the GL. GLOs and GL members use 851 the glaQueryRequest, defined in section 3.1.10.1, to request 852 information and GLAs use the glaQueryResponse, defined in section 853 3.1.10.2, to return the requested information. Section 3.1.10.3 854 includes one request and response type and value; others may be 855 defined in additional documents. 857 3.1.10.1 GLA Query Request 859 GLOs and GL members use the glaQueryRequest to ascertain information 860 about the GLA. The glaQueryRequest control attribute has the syntax 861 GLAQueryRequest: 863 GLAQueryRequest ::= SEQUENCE { 864 glaRequestType OBJECT IDENTIFIER, 865 glaRequestValue ANY DEFINED BY glaRequestType } 867 3.1.10.2 GLA Query Response 869 GLAs return the glaQueryResponse after receiving a GLAQueryRequest. 870 The glaQueryResponse MUST be signed by a GLA. The glaQueryResponse 871 control attribute has the syntax GLAQueryResponse: 873 GLAQueryResponse ::= SEQUENCE { 874 glaResponseType OBJECT IDENTIFIER, 875 glaResponseValue ANY DEFINED BY glaResponseType } 877 3.1.10.3 Request and Response Types 879 Request and Responses are registered as a pair under the following 880 object identifier arc: 882 id-cmc-glaRR OBJECT IDENTIFIER ::= { id-cmc 99 } 884 This document defines one request/response pair for GL members and 885 GLOs to query the GLA for the list of algorithm it supports. The 886 following object identifier (OID) is included in the glaQueryType 887 field: 889 id-cmc-gla-skdAlgRequest OBJECT IDENTIFIER ::={ id-cmc-glaRR 1 } 891 SKDAlgRequest ::= NULL 893 Turner 17 894 And Distribution 896 If the GLA supports GLAQueryRequest and GLAQueryResponse messages, 897 the GLA may return the following OID in the glaQueryType field: 899 id-cmc-gla-skdAlgResponse OBJECT IDENTIFIER ::= { id-cmc-glaRR 2 } 901 The glaQueryValue has the form of the smimeCapabilities attributes 902 as defined in MSG [7]. 904 3.1.12 Provide Cert 906 GLAs and GLOs use the glProvideCert to request that a GL member 907 provide an updated or new encryption certificate. The glProvideCert 908 message MUST be signed by either GLA or GLO. If the GL member�s PKC 909 has been revoked, the GLO or GLA MUST NOT use it to generate the 910 EnvelopedData that encapsulates the glProvideCert request. The 911 glProvideCert control attribute has the syntax GLManageCert: 913 GLManageCert ::= SEQUENCE { 914 glName GeneralName, 915 glMember GLMember } 917 The fields in GLManageCert have the following meaning: 919 - glName indicates the name of the GL to which the GL member�s new 920 certificate is to be associated. 922 - glMember indicates particulars for the GL member: 924 - glMemberName indicates the GL member�s name. 926 - glMemberAddress indicates the GL member�s address. It MAY be 927 omitted. 929 - certificates SHOULD be omitted. 931 3.1.13 Update Cert 933 GL members and GLOs use the glUpdateCert to provide a new 934 certificate for the GL. GL members can generate an unsolicited 935 glUpdateCert or generate a response glUpdateCert as a result of 936 receiveing a glProvideCert message. GL members MUST sign the 937 glUpdateCert. If the GL member�s encryption certificate has been 938 revoked, the GL member MUST NOT use it to generate the EnvelopedData 939 that encapsulates the glUpdateCert request or response. The 940 glUpdateCert control attribute has the syntax GLManageCert: 942 GLManageCert ::= SEQUENCE { 943 glName GeneralName, 944 glMember GLMember } 946 Turner 18 947 And Distribution 949 The fields in GLManageCert have the following meaning: 951 - glName indicates the name of the GL to which the GL member�s new 952 certificate should be associated. 954 - glMember indicates the particulars for the GL member: 956 - glMemberName indicates the GL member�s name 958 - glMemberAddress indicates the GL member�s address. It MAY be 959 omitted. 961 - certificates MAY be omitted if the GLManageCert message is 962 sent to request the GL member�s certificate; otherwise, it 963 MUST be included. It includes the following three fields: 965 - certificates.pKC includes the member's encryption 966 certificate that will be used to encrypt the shared KEK for 967 that member. 969 - certificates.aC MAY be included to convey one or more 970 attribute certificate associated with the member�s 971 encryption certificate. 973 - certificates.certPath MAY also be included to convey 974 certificates that might aid the recipient in constructing 975 valid certification paths for the certificate provided in 976 certificates.pKC and the attribute certificates provided in 977 certificates.aC. These certificates is optional because they 978 might already be included elsewhere in the message (e.g., in 979 the outer CMS layer). 981 3.1.14 GL Key 983 The GLA uses the glKey to distribute the shared KEK. The glKey 984 message MUST be signed by the GLA. The glKey control attribute has 985 the syntax GLKey: 987 GLKey ::= SEQUENCE { 988 glName GeneralName, 989 glIdentifier KEKIdentifier, -- See CMS [2] 990 glkWrapped RecipientInfos, -- See CMS [2] 991 glkAlgorithm AlgorithmIdentifier, 992 glkNotBefore GeneralizedTime, 993 glkNotAfter GeneralizedTime } 995 Turner 19 996 And Distribution 998 -- KEKIdentifier is included only for illustrative purposes as 999 -- it is imported from CMS [2]. 1001 KEKIdentifier ::= SEQUENCE { 1002 keyIdentifier OCTET STRING, 1003 date GeneralizedTime OPTIONAL, 1004 other OtherKeyAttribute OPTIONAL } 1006 The fields in GLKey have the following meaning: 1008 - glName is the name of the GL. 1010 - glIdentifier is the key identifier of the shared KEK. See 1011 paragraph 6.2.3 of CMS [2] for a description of the subfields. 1013 - glkWrapped is the wrapped shared KEK for the GL for a particular 1014 duration. The RecipientInfos MUST be generated as specified in 1015 section 6.2 of CMS [2]. The ktri RecipientInfo choice MUST be 1016 supported. The key in the EncryptedKey field (i.e., the 1017 distributed shared KEK) MUST be generated according to the 1018 section concerning random number generation in the security 1019 considerations of CMS [2]. 1021 - glkAlgorithm identifies the algorithm the shared KEK is used 1022 with. Since no encrypted data content is being conveyed at this 1023 point, the parameters encoded with the algorithm should be the 1024 structure defined for smimeCapabilities rather than encrypted 1025 content. 1027 - glkNotBefore indicates the date at which the shared KEK is 1028 considered valid. GeneralizedTime values MUST be expressed in 1029 UTC (Zulu) and MUST include seconds (i.e., times are 1030 YYYYMMDDHHMMSSZ), even where the number of seconds is zero. 1031 GeneralizedTime values MUST NOT include fractional seconds. 1033 - glkNotAfter indicates the date after which the shared KEK is 1034 considered invalid. GeneralizedTime values MUST be expressed in 1035 UTC (Zulu) and MUST include seconds (i.e., times are 1036 YYYYMMDDHHMMSSZ), even where the number of seconds is zero. 1037 GeneralizedTime values MUST NOT include fractional seconds. 1039 If the glKey message is in response to a glUseKEK message: 1041 - The GLA MUST generate separate glKey messages for each recipient 1042 if glUseKEK.glKeyAttributes.recipientsNotMutuallyAware is set to 1043 FALSE. For each recipient you want to generate a message that 1044 contains that recipient�s key (i.e., one message with one 1045 attribute). 1047 Turner 20 1048 And Distribution 1050 - The GLA MUST generate the requested number of glKey messages. 1051 The value in glUseKEK.glKeyAttributes.generationCounter 1052 indicates the number of glKey messages requested. 1054 If the glKey message is in response to a glRekey message: 1056 - The GLA MUST generate separate glKey messages for each recipient 1057 if glRekey.glNewKeyAttributes.recipientsNotMutuallyAware is set 1058 to FALSE. 1060 - The GLA MUST generate the requested number of glKey messages. 1061 The value in glUseKEK.glKeyAttributes.generationCounter 1062 indicates the number of glKey messages requested. 1064 - The GLA MUST generate one glKey messagefor each outstanding 1065 shared KEKs for the GL when glRekeyAllGLKeys is set to TRUE. 1067 If the glKey message was not in response to a glRekey or glUseKEK 1068 (e.g., where the GLA controls rekey): 1070 - The GLA MUST generate separate glKey messages for each recipient 1071 when glUseKEK.glNewKeyAttributes.recipientsNotMutuallyAware that 1072 set up the GL was set to FALSE. 1074 - The GLA MAY generate glKey messages prior to the duration on the 1075 last outstanding shared KEK expiring, where the number of glKey 1076 messages generated is generationCounter minus one (1). Other 1077 distribution mechanisms can also be supported to support this 1078 functionality. 1080 3.2 Use of CMC, CMS, and PKIX 1082 The following sections outline the use of CMC, CMS, and the PKIX 1083 certificate and CRL profile. 1085 3.2.1 Protection Layers 1087 The following sections outline the protection required for the 1088 control attributes defined in this document. 1090 Note: There are multiple ways to encapsulate SignedData and 1091 EnvelopedData. The first is to use a MIME wrapper around each 1092 ContentInfo, as specified in MSG [7]. The second is to not use a 1093 MIME wrapper around each ContentInfo, as specified in Transporting 1094 S/MIME Objects in X.400 [8]. 1096 Turner 21 1097 And Distribution 1099 3.2.1.1 Minimum Protection 1101 At a minimum, a SignedData MUST protect each request and response 1102 encapsulated in PKIData and PKIResponse. The following is a 1103 depiction of the minimum wrappings: 1105 Minimum Protection 1106 ------------------ 1107 SignedData 1108 PKIData or PKIResponse 1109 controlSequence 1111 Prior to taking any action on any request or response SignedData(s) 1112 MUST be processed according to CMS [2]. 1114 3.2.1.2 Additional Protection 1116 An additional EnvelopedData MAY also be used to provide 1117 confidentiality of the request and response. An additional 1118 SignedData MAY also be added to provide authentication and integrity 1119 of the encapsulated EnvelopedData. The following is a depiction of 1120 the optional additional wrappings: 1122 Authentication and Integrity 1123 Confidentiality Protection of Confidentiality Protection 1124 -------------------------- ----------------------------- 1125 EnvelopedData SignedData 1126 SignedData EnvelopedData 1127 PKIData or PKIResponse SignedData 1128 controlSequence PKIData or PKIResponse 1129 controlSequence 1131 If an incoming message is encrypted, the confidentiality of the 1132 message MUST be preserved. All EnvelopedData objects MUST be 1133 processed as specified in CMS [2]. If a SignedData is added over an 1134 EnvelopedData, a ContentHints attribute SHOULD be added. See 1135 paragraph 2.9 of Extended Security Services for S/MIME [9]. 1137 If the GLO or GL member applies confidentiality to a request, the 1138 EnvelopedData MUST include the GLA as a recipient. If the GLA 1139 forwards the GL member request to the GLO, then the GLA MUST decrypt 1140 the EnvelopedData content, strip the confidentiality layer, and 1141 apply its own confidentiality layer as an EnvelopedData with the GLO 1142 as a recipient. 1144 Turner 22 1145 And Distribution 1147 3.2.2 Combining Requests and Responses 1149 Multiple requests and response corresponding to a GL MAY be included 1150 in one PKIData.controlSequence or PKIResponse.controlSequence. 1151 Requests and responses for multiple GLs MAY be combined in one 1152 PKIData or PKIResponse by using PKIData.cmsSequence and 1153 PKIResponse.cmsSequence. A separate cmsSequence MUST be used for 1154 different GLs. That is, requests corresponding to two different GLs 1155 are included in different cmsSequences. The following is a diagram 1156 depicting multiple requests and responses combined in one PKIData 1157 and PKIResponse: 1159 Multiple Request and Response 1160 Request Response 1161 ------- -------- 1162 SignedData SignedData 1163 PKIData PKIResponse 1164 cmsSequence cmsSequence 1165 SignedData SignedData 1166 PKIData PKIResponse 1167 controlSequence controlSequence 1168 One or more requests One or more responses 1169 corresponding to one GL corresponding to one GL 1170 SignedData SignedData 1171 PKIData PKIResponse 1172 controlSequence controlSequence 1173 One or more requests One or more responses 1174 corresponding to another GL corresponding to another GL 1176 When applying confidentiality to multiple requests and responses, 1177 all of the requests/response MAY be included in one EnvelopedData. 1178 The following is a depiction: 1180 Confidentiality of Multiple Requests and Responses 1181 Wrapped Together 1182 ---------------- 1183 EnvelopedData 1184 SignedData 1185 PKIData 1186 cmsSequence 1187 SignedData 1188 PKIResponse 1189 controlSequence 1190 One or more requests 1191 corresponding to one GL 1192 SignedData 1193 PKIData 1194 controlSequence 1195 One or more requests 1196 corresponding to one GL 1198 Turner 23 1199 And Distribution 1201 Certain combinations of requests in one PKIData.controlSequence and 1202 one PKIResponse.controlSequence are not allowed. The invalid 1203 combinations listed here MUST NOT be generated: 1205 Invalid Combinations 1206 --------------------------- 1207 glUseKEK & glDeleteMember 1208 glUseKEK & glRekey 1209 glUseKEK & glDelete 1210 glDelete & glAddMember 1211 glDelete & glDeleteMember 1212 glDelete & glRekey 1213 glDelete & glAddOwner 1214 glDelete & glRemoveOwner 1216 To avoid unnecessary errors, certain requests and responses SHOULD 1217 be processed prior to others. The following is the priority of 1218 message processing, if not listed it is an implementation decision 1219 as to which to process first: glUseKEK before glAddMember, glRekey 1220 before glAddMember, and glDeleteMember before glRekey. Note that 1221 there is a processing priority but it does not imply an ordering 1222 within the content. 1224 3.2.3 GLA Generated Messages 1226 When the GLA generates a success or fail message, it generates one 1227 for each request. SKDFailInfo values of unsupportedDuration, 1228 unsupportedDeliveryMethod, unsupportedAlgorithm, noGLONameMatch, 1229 nameAlreadyInUse, alreadyAnOwner, notAnOwner are not returned to GL 1230 members. 1232 If GLKeyAttributes.recipientsNotMutuallyAware is set to FALSE, a 1233 separate PKIResponse.cMCStatusInfoExand PKIData.glKey MUST be 1234 generated for each recipient. However, it is valid to send one 1235 message with multiple attributes to the same recipient. 1237 If the GL has multiple GLOs, the GLA MUST send cMCStatusInfoEx 1238 messages to the requesting GLO. The mechanism to determine which GLO 1239 made the request is beyond the scope of this document. 1241 Turner 24 1242 And Distribution 1244 If a GL is managed and the GLA receives a glAddMember, 1245 glDeleteMember, or glkCompromise message, the GLA redirects the 1246 request to the GLO for review. An additional, SignedData MUST be 1247 applied to the redirected request as follows: 1249 GLA Forwarded Requests 1250 ---------------------- 1251 SignedData 1252 PKIData 1253 cmsSequence 1254 SignedData 1255 PKIData 1256 controlSequence 1258 3.2.4 CMC Control Attributes 1260 Certain control attributes defined in CMC [3] are allowed; they are 1261 as follows: cMCStatusInfoEx transactionId, senderNonce, 1262 recipientNonce, and queryPending. 1264 3.2.4.1 Using cMCStatusInfoEx 1266 cMCStatusInfoEx is used by GLAs to indicate to GLOs and GL members 1267 that a request was unsuccessful. Two classes of failure codes are 1268 used within this document. Errors from the CMCFailInfo list, found 1269 in section 5.1.4 of CMC, are encoded as defined in CMC. Error codes 1270 defined in this document are encoded using the ExtendedFailInfo 1271 field of the cmcStatusInfoEx structure. If the same failure code 1272 applies to multiple commands, a single cmcStatusInfoEx structure can 1273 be used with multiple items in cMCStatusInfoEx.bodyList. The GLA MAY 1274 also return other pertinent information in statusString. The 1275 SKDFailInfo object identifier and value are: 1277 id-cet-skdFailInfo OBJECT IDENTIFIER ::= { iso(1) 1278 identified-organization(3) dod(6) internet(1) security(5) 1279 mechanisms(5) pkix(7) cet(15) skdFailInfo(1) } 1281 Turner 25 1282 And Distribution 1284 SKDFailInfo ::= INTEGER { 1285 unspecified (0), 1286 closedGL (1), 1287 unsupportedDuration (2), 1288 noGLACertificate (3), 1289 invalidCert (4), 1290 unsupportedAlgorithm (5), 1291 noGLONameMatch (6), 1292 invalidGLName (7), 1293 nameAlreadyInUse (8), 1294 noSpam (9), 1295 deniedAccess (10), 1296 alreadyAMember (11), 1297 notAMember (12), 1298 alreadyAnOwner (13), 1299 notAnOwner (14) } 1301 The values have the following meaning: 1303 - unspecified indicates that the GLA is unable or unwilling to 1304 perform the requested action and does not want to indicate the 1305 reason. 1307 - closedGL indicates that members can only be added or deleted by 1308 the GLO. 1310 - unsupportedDuration indicates the GLA does not support 1311 generating keys that are valid for the requested duration. 1313 - noGLACertificate indicates that the GLA does not have a valid 1314 certificate. 1316 - invalidCert indicates the member's encryption certificate was 1317 not verifiable (i.e., signature did not validate, certificate�s 1318 serial number present on a CRL, expired, etc.). 1320 - unsupportedAlgorithm indicates the GLA does not support the 1321 requested algorithm. 1323 - noGLONameMatch indicates that one of the names in the 1324 certificate used to sign a request does not match the name of a 1325 registered GLO. 1327 - invalidGLName indicates the GLA does not support the glName 1328 present in the request. 1330 - nameAlreadyInUse indicates the glName is already assigned on the 1331 GLA. 1333 - noSpam indicates the prospective GL member did not sign the 1334 request (i.e., if the name in glMember.glMemberName does not 1335 match one of the names (either the subject distinguished name or 1337 Turner 26 1338 And Distribution 1340 one of the subject alternative names) in the certificate used to 1341 sign the request). 1343 - alreadyAMember indicates the prospective GL member is already a 1344 GL member. 1346 - notAMember indicates the prospective GL member to be deleted is 1347 not presently a GL member. 1349 - alreadyAnOwner indicates the prospective GLO is already a GLO. 1351 - notAnOwner indicates the prospective GLO to be deleted is not 1352 presently a GLO. 1354 cMCStatusInfoEx is used by GLAs to indicate to GLOs and GL members 1355 that a request was successfully completed. If the request was 1356 successful, the GLA returns a cMCStatusInfoEx response with 1357 cMCStatus.success and optionally other pertinent information in 1358 statusString. 1360 When the GL is managed and the GLO has reviewed GL member initiated 1361 glAddMember, glDeleteMember, and glkComrpomise requests, the GLO 1362 uses cMCStatusInfoEx to indicate the success or failure of the 1363 request. If the request is allowed, cMCStatus.success is returned 1364 and statusString is optionally returned to convey additional 1365 information. If the request is denied, cMCStatus.failed is returned 1366 and statusString is optionally returned to convey additional 1367 information. Additionally, the appropriate SKDFailInfo can be 1368 included in cMCStatusInfoEx.extendedFailInfo. 1370 cMCStatusInfoEx is used by GLOs, GLAs, and GL members to indicate 1371 that signature verification failed. If the signature failed to 1372 verify over any control attibute except a cMCStatusInfoEx, a 1373 cMCStatusInfoEx control attribute MUST be returned indicating 1374 cMCStatus.failed and otherInfo.failInfo.badMessageCheck. If the 1375 signature over the outermost PKIData failed, the bodyList value is 1376 zero (0). If the signature over any other PKIData failed the 1377 bodyList value is the bodyPartId value from the request or response. 1378 GLOs and GL members who receive cMCStatusInfoEx messages whose 1379 signatures are invalid SHOULD generate a new request to avoid 1380 badMessageCheck message loops. 1382 cMCStatusInfoEx is also used by GLOs and GLAs to indicate that a 1383 request could not be performed immediately. If the request could not 1384 be processed immediately by the GLA or GLO, the cMCStatusInfoEx 1385 control attribute MUST be returned indicating cMCStatus.pending and 1386 otherInfo.pendInfo. When requests are redirected to the GLO for 1387 approval (for managed lists), the GLA MUST NOT return a 1388 cMCStatusInfoEx indicating query pending. 1390 cMCStatusInfoEx is also used by GLAs to indicate that a 1391 glaQueryRequest is not supported. If the glaQueryRequest is not 1393 Turner 27 1394 And Distribution 1396 supported, the cMCStatusInfoEx control attribute MUST be returned 1397 indicating cMCStatus.noSupport and statusString is optionally 1398 returned to convey additional information. 1400 3.2.4.2 Using transactionId 1402 transactionId MAY be included by GLOs, GLAs, or GL members to 1403 identify a given transaction. All subsequent requests and responses 1404 related to the original request MUST include the same transactionId 1405 control attribute. If GL members include a transactionId and the 1406 request is redirected to the GLO, the GLA MAY include an additional 1407 transactionId in the outer PKIData. If the GLA included an 1408 additional transactionId in the outer PKIData, when the GLO 1409 generates a cMCStatusInfoEx response it generates one for the GLA 1410 with the GLA�s transactionId and one for the GL member with the GL 1411 member�s transactionId. 1413 3.2.4.3 Using nonces 1415 The use of nonces (see section 5.6 of [3]) can be used to provide 1416 application-level replay prevention. If the originating message 1417 includes a senderNonce, the response to the message MUST include the 1418 received senderNonce value as the recipientNonce and a new value as 1419 the senderNonce value in the response. 1421 If a GLA aggratates multiple messages together or forwards a message 1422 to a GLO, the GLA MAY optionally generate a new nonce value and 1423 include that in the wrapping message. When the response comes back 1424 from the GLO, the GLA builds a response to the originator(s) of the 1425 message(s) and deals with each of the nonce values from the 1426 originating messages. 1428 3.2.4.4 CMC Attribute Support Requirements 1430 The following are the implementation requirements for CMC control 1431 attributes for an implementation be considered conformant to this 1432 specification: 1434 Required 1435 Implementation Requirement | Control 1436 GLO | GLA | GL Member | Attribute 1437 O R | O R F | O R | 1438 --------- | ------------- | --------- | ---------- 1439 MUST MUST | MUST MUST - | MUST MUST | cMCStatusinfoEx 1440 MAY MAY | MAY MAY - | MAY MAY | transactionId 1441 MAY MAY | MAY MAY - | MAY MAY | senderNonce 1442 MAY MAY | MAY MAY - | MAY MAY | recepientNonce 1443 MUST MUST | MUST MUST - | MUST MUST | SKDFailInfo 1445 Turner 28 1446 And Distribution 1448 3.2.5 Resubmitted GL Member Messages 1450 When the GL is managed, the GLA forwards the GL member requests to 1451 the GLO for GLO approval by creating a new request message 1452 containing the GL member request(s) as a cmsSequence item. If the 1453 GLO approves the request it can either add a new layer of wrapping 1454 and send it back to the GLA or create a new message and send it to 1455 the GLA. (Note in this case there are now 3 layers of PKIData 1456 messages with appropriate signing layers.) 1458 3.2.6 PKIX Certificate and CRL Profile 1460 Signatures, certificates, and CRLs are verified according to the 1461 PKIX profile [5]. 1463 Name matching is performed according to the PKIX profile [5]. 1465 All distinguished name forms must follow the UTF8String convention 1466 noted in the PKIX profile [5]. 1468 A certificate per-GL would be issued to the GLA. 1470 GL policy may mandate that the GL member�s address be included in 1471 the GL member�s certificate. 1473 4 Administrative Messages 1475 There are a number of administrative messages that must be performed 1476 to manage a GL. The following sections describe each request and 1477 response message combination in detail. The procedures defined in 1478 this section are not prescriptive. 1480 4.1 Assign KEK To GL 1482 Prior to generating a group key, a GL needs to be setup and a shared 1483 KEK assigned to the GL. Figure 3 depicts the protocol interactions 1484 to setup and assign a shared KEK. Note that error messages are not 1485 depicted in Figure 3. 1487 +-----+ 1 2 +-----+ 1488 | GLA | <-------> | GLO | 1489 +-----+ +-----+ 1491 Figure 3 - Create Group List 1493 Turner 29 1494 And Distribution 1496 The process is as follows: 1498 1 - The GLO is the entity responsible for requesting the creation 1499 of the GL. The GLO sends a 1500 SignedData.PKIData.controlSequence.glUseKEK request to the GLA 1501 (1 in Figure 3). The GLO MUST include: glName, glAddress, 1502 glOwnerName, glOwnerAddress, and glAdministration. The GLO MAY 1503 also include their preferences for the shared KEK in 1504 glKeyAttributes by indicating whether the GLO controls the 1505 rekey in rekeyControlledByGLO, whether separate glKey messages 1506 should be sent to each recipient in 1507 recipientsNotMutuallyAware, the requested algorithm to be used 1508 with the shared KEK in requestedAlgorithm, the duration of the 1509 shared KEK, and how many shared KEKs should be initially 1510 distributed in generationCounter. 1512 1.a - If the GLO knows of members to be added to the GL, the 1513 glAddMember request(s) MAY be included in the same 1514 controlSequence as the glUseKEK request (see section 3.2.2). 1515 The GLO indicates the same glName in the glAddMember request 1516 as in glUseKEK.glInfo.glName. Further glAddMember procedures 1517 are covered in section 4.3. 1519 1.b - The GLO can apply confidentiality to the request by 1520 encapsulating the SignedData.PKIData in an EnvelopedData 1521 (see section 3.2.1.2). 1523 1.c - The GLO can also optionally apply another SignedData over 1524 the EnvelopedData (see section 3.2.1.2). 1526 2 - Upon receipt of the request, the GLA verifies the signature on 1527 the inner most SignedData.PKIData. If an additional SignedData 1528 and/or EnvelopedData encapsulates the request (see sections 1529 3.2.1.2 and 3.2.2), the GLA verifies the outer signature(s) 1530 and/or decrypt the outer layer(S) prior to verifying the 1531 signature on the inner most SignedData. 1533 2.a - If the signatures do not verify, the GLA returns a 1534 cMCStatusInfoEx response indicating cMCStatus.failed and 1535 otherInfo.failInfo.badMessageCheck. 1537 2.b � Else if the signatures do verify but the GLA does not have a 1538 valid certificate, the GLA returns a cMCStatusInfoEx with 1539 cMCStatus.failed and otherInfo.extendedFailInfo.SKDFailInfo 1540 value of noValidGLACertificate. Instead of immediately 1541 returning the error code, the GLA attempts to get a 1542 certificate, possibly using CMC [3]. 1544 2.c - Else the signatures are valid and the GLA does have a valid 1545 certificate, the GLA checks that one of the names in the 1546 certificate used to sign the request matches one of the 1547 names in glUseKEK.glOwnerInfo.glOwnerName. 1549 Turner 30 1550 And Distribution 1552 2.c.1 - If the names do not match, the GLA returns a response 1553 indicating cMCStatusInfoEx with cMCStatus.failed and 1554 otherInfo.extendedFailInfo.SKDFailInfo value of 1555 noGLONameMatch. 1557 2.c.2 - Else if the names all match, the GLA checks that the 1558 glName and glAddress is not already in use. The GLA also 1559 checks any glAddMember included within the controlSequence 1560 with this glUseKEK. Further processing of the glAddMember 1561 is covered in section 4.3. 1563 2.c.2.a - If the glName is already in use the GLA returns a 1564 response indicating cMCStatusInfoEx with 1565 cMCStatus.failed and 1566 otherInfo.extendedFailInfo.SKDFailInfo value of 1567 nameAlreadyInUse. 1569 2.c.2.b - Else if the requestedAlgorithm is not supported, the GLA 1570 returns a response indicating cMCStatusInfoEx with 1571 cMCStatus.failed and 1572 otherInfo.extendedFailInfo.SKDFailInfo value of 1573 unsupportedAlgorithm. 1575 2.c.2.c - Else if the duration cannot be supported, determining 1576 this is beyond the scope of this document, the GLA 1577 returns a response indicating cMCStatusInfoEx with 1578 cMCStatus.failed and 1579 otherInfo.extendedFailInfo.SKDFailInfo value of 1580 unsupportedDuration. 1582 2.c.2.d - Else if the GL cannot be supported for other reasons, 1583 which the GLA does not wish to disclose, the GLA returns 1584 a response indicating cMCStatusInfoEx with 1585 cMCStatus.failed and 1586 otherInfo.extendedFailInfo.SKDFailInfo value of 1587 unspecified. 1589 2.c.2.e - Else if the glName is not already in use, the duration 1590 can be supported, and the requestedAlgorithm is 1591 supported, the GLA MUST return a cMCStatusInfoEx 1592 indicating cMCStatus.success (2 in Figure 3). The GLA 1593 also takes administrative actions, which are beyond the 1594 scope of this document, to store the glName, glAddress, 1595 glKeyAttributes, glOwnerName, and glOwnerAddress. The 1596 GLA also sends a glKey message as described in section 1597 5. 1599 2.c.2.e.1 - The GLA can apply confidentiality to the response by 1600 encapsulating the SignedData.PKIResponse in an 1601 EnvelopedData if the request was encapsulated in an 1602 EnvelopedData (see section 3.2.1.2). 1604 Turner 31 1605 And Distribution 1607 2.c.2.e.2 - The GLA can also optionally apply another SignedData 1608 over the EnvelopedData (see section 3.2.1.2). 1610 3 - Upon receipt of the cMCStatusInfoEx responses, the GLO 1611 verifies the GLA signature(s). If an additional SignedData 1612 and/or EnvelopedData encapsulates the response (see section 1613 3.2.1.2 or 3.2.2), the GLO verifies the outer signature and/or 1614 decrypt the outer layer prior to verifying the signature on 1615 the inner most SignedData. 1617 3.a - If the signatures do verify, the GLO MUST check that one of 1618 the names in the certificate used to sign the response 1619 matches the name of the GL. 1621 3.a.1 � If the name of the GL does not match the name present in 1622 the certificate used to sign the message, the GLO should 1623 not believe the response. 1625 3.a.2 � Else if the name of the GL does match the name present in 1626 the certificate and: 1628 3.a.2.a - If the signatures do verify and the response was 1629 cMCStatusInfoEx indicating cMCStatus.success, the GLO 1630 has successfully created the GL. 1632 3.a.2.b - Else if the signatures are valid and the response is 1633 cMCStatusInfoEx.cMCStatus.failed with any reason, the 1634 GLO can reattempt to create the GL using the information 1635 provided in the response. The GLO can also use the 1636 glaQueryRequest to determine the algorithms and other 1637 characteristics supported by the GLA (see section 4.9). 1639 4.2 Delete GL From GLA 1641 From time to time, there are instances when a GL is no longer 1642 needed. In this case, the GLO deletes the GL. Figure 4 depicts that 1643 protocol interactions to delete a GL. 1645 +-----+ 1 2 +-----+ 1646 | GLA | <-------> | GLO | 1647 +-----+ +-----+ 1649 Figure 4 - Delete Group List 1651 The process is as follows: 1653 1 - The GLO is responsible for requesting the deletion of the GL. 1654 The GLO sends a SignedData.PKIData.controlSequence.glDelete 1656 Turner 32 1657 And Distribution 1659 request to the GLA (1 in Figure 4). The name of the GL to be 1660 deleted is included in GeneralName. 1662 1.a - The GLO can optionally apply confidentiality to the request 1663 by encapsulating the SignedData.PKIData in an EnvelopedData 1664 (see section 3.2.1.2). 1666 1.b - The GLO MAY can also optionally apply another SignedData 1667 over the EnvelopedData (see section 3.2.1.2). 1669 2 - Upon receipt of the request the GLA verifies the signature on 1670 the inner most SignedData.PKIData. If an additional SignedData 1671 and/or EnvelopedData encapsulates the request (see section 1672 3.2.1.2 or 3.2.2), the GLA verifies the outer signature and/or 1673 decrypt the outer layer prior to verifying the signature on 1674 the inner most SignedData. 1676 2.a - If the signatures cannot be verified, the GLA returns a 1677 cMCStatusInfoEx response indicating cMCStatus.failed and 1678 otherInfo.failInfo.badMessageCheck. 1680 2.b - Else if the signatures verify, the GLA makes sure the GL is 1681 supported by checking the name of the GL matches a glName 1682 stored on the GLA. 1684 2.b.1 - If the glName is not supported by the GLA, the GLA returns 1685 a response indicating cMCStatusInfoEx with 1686 cMCStatus.failed and 1687 otherInfo.extendedFailInfo.SKDFailInfo value of 1688 invalidGLName. 1690 2.b.2 - Else if the glName is supported by the GLA, the GLA 1691 ensures a registered GLO signed the glDelete request by 1692 checking if one of the names present in the digital 1693 signature certificate used to sign the glDelete request 1694 matches a registered GLO. 1696 2.b.2.a - If the names do not match, the GLA returns a response 1697 indicating cMCStatusInfoEx with cMCStatus.failed and 1698 otherInfo.extendedFailInfo.SKDFailInfo value of 1699 noGLONameMatch. 1701 2.b.2.b - Else if the names do match, but the GL cannot be deleted 1702 for other reasons, which the GLA does not wish to 1703 disclose, the GLA returns a response indicating 1704 cMCStatusInfoEx with cMCStatus.failed and 1705 otherInfo.extendedFailInfo.SKDFailInfo value of 1706 unspecified. Actions beyond the scope of this document 1707 must then be taken to delete the GL from the GLA. 1709 2.b.2.c - Else if the names do match, the GLA returns a 1710 cMCStatusInfoEx indicating cMCStatus.success (2 in 1712 Turner 33 1713 And Distribution 1715 Figure 4). The GLA ought not accept further requests for 1716 member additions, member deletions, or group rekeys for 1717 this GL. 1719 2.b.2.c.1 - The GLA can apply confidentiality to the response by 1720 encapsulating the SignedData.PKIResponse in an 1721 EnvelopedData if the request was encapsulated in an 1722 EnvelopedData (see section 3.2.1.2). 1724 2.b.2.c.2 - The GLA MAY can also optionally apply another 1725 SignedData over the EnvelopedData (see section 1726 3.2.1.2). 1728 3 - Upon receipt of the cMCStatusInfoEx response, the GLO verifies 1729 the GLA signature(s). If an additional SignedData and/or 1730 EnvelopedData encapsulates the response (see section 3.2.1.2 1731 or 3.2.2), the GLO verifies the outer signature and/or decrypt 1732 the outer layer prior to verifying the signature on the inner 1733 most SignedData. 1735 3.a - If the signatures verify, the GLO checks that one of the 1736 names in the certificate used to sign the response matches 1737 the name of the GL. 1739 3.a.1 � If the name of the GL does not match the name present in 1740 the certificate used to sign the message, the GLO should 1741 not believe the response. 1743 3.a.2 � Else if the name of the GL does match the name present in 1744 the certificate and: 1746 3.a.2.a - If the signatures verify and the response was 1747 cMCStatusInfoEx indicating cMCStatus.success, the GLO 1748 has successfully deleted the GL. 1750 3.a.2.b - Else if the signatures do verify and the response was 1751 cMCStatusInfoEx.cMCStatus.failed with any reason, the 1752 GLO can reattempt to delete the GL using the information 1753 provided in the response. 1755 4.3 Add Members To GL 1757 To add members to GLs, either the GLO or prospective members use the 1758 glAddMember request. The GLA processes GLO and prospective GL member 1759 requests differently though. GLOs can submit the request at any time 1760 to add members to the GL, and the GLA, once it has verified the 1761 request came from a registered GLO, should process it. If a 1762 prospective member sends the request, the GLA needs to determine how 1763 the GL is administered. When the GLO initially configured the GL, 1764 they set the GL to be unmanaged, managed, or closed (see section 1765 3.1.1). In the unmanaged case, the GLA merely processes the member�s 1767 Turner 34 1768 And Distribution 1770 request. For the managed case, the GLA forwards the requests from 1771 the prospective members to the GLO for review. Where there are 1772 multiple GLOs for a GL, which GLO the request is forwarded to is 1773 beyond the scope of this document. The GLO reviews the request and 1774 either rejects it or submits a reformed request to the GLA. In the 1775 closed case, the GLA will not accept requests from prospective 1776 members. The following sections describe the processing for the 1777 GLO(s), GLA, and prospective GL members depending on where the 1778 glAddMeber request originated, either from a GLO or from prospective 1779 members. Figure 5 depicts the protocol interactions for the three 1780 options. Note that the error messages are not depicted. 1782 +-----+ 2,B{A} 3 +----------+ 1783 | GLO | <--------+ +-------> | Member 1 | 1784 +-----+ | | +----------+ 1785 1 | | 1786 +-----+ <--------+ | 3 +----------+ 1787 | GLA | A +-------> | ... | 1788 +-----+ <-------------+ +----------+ 1789 | 1790 | 3 +----------+ 1791 +-------> | Member n | 1792 +----------+ 1794 Figure 5 - Member Addition 1796 An important decision that needs to be made on a group by group 1797 basis is whether to rekey the group every time a new member is 1798 added. Typically, unmanaged GLs should not be rekeyed when a new 1799 member is added, as the overhead associated with rekeying the group 1800 becomes prohibitive, as the group becomes large. However, managed 1801 and closed GLs can be rekeyed to maintain the confidentiality of the 1802 traffic sent by group members. An option to rekeying managed or 1803 closed GLs when a member is added is to generate a new GL with a 1804 different group key. Group rekeying is discussed in sections 4.5 and 1805 5. 1807 4.3.1 GLO Initiated Additions 1809 The process for GLO initiated glAddMember requests is as follows: 1811 1 - The GLO collects the pertinent information for the member(s) 1812 to be added (this may be done through an out of bands means). 1813 The GLO then sends a SignedData.PKIData.controlSequence with a 1814 separate glAddMember request for each member to the GLA (1 in 1815 Figure 5). The GLO includes: the GL name in glName, the 1816 member's name in glMember.glMemberName, the member�s address 1817 in glMember.glMemberAddress, and the member's encryption 1818 certificate in glMember.certificates.pKC. The GLO can also 1819 include any attribute certificates associated with the 1820 member�s encryption certificate in glMember.certificates.aC, 1822 Turner 35 1823 And Distribution 1825 and the certification path associated with the member�s 1826 encryption and attribute certificates in 1827 glMember.certificates.certPath. 1829 1.a - The GLO can optionally apply confidentiality to the request 1830 by encapsulating the SignedData.PKIData in an EnvelopedData 1831 (see section 3.2.1.2). 1833 1.b - The GLO can also optionally apply another SignedData over 1834 the EnvelopedData (see section 3.2.1.2). 1836 2 - Upon receipt of the request, the GLA verifies the signature on 1837 the inner most SignedData.PKIData. If an additional SignedData 1838 and/or EnvelopedData encapsulates the request (see section 1839 3.2.1.2 or 3.2.2), the GLA verifies the outer signature and/or 1840 decrypt the outer layer prior to verifying the signature on 1841 the inner most SignedData. 1843 2.a - If the signatures cannot be verified, the GLA returns a 1844 cMCStatusInfoEx response indicating cMCStatus.failed and 1845 otherInfo.failInfo.badMessageCheck. 1847 2.b - Else if the signatures verify, the glAddMember request is 1848 included in a controlSequence with the glUseKEK request, and 1849 the processing in section 4.1 item 2.e is successfully 1850 completed the GLA returns a cMCStatusInfoEx indicating 1851 cMCStatus.success (2 in Figure 5). 1853 2.b.1 - The GLA can apply confidentiality to the response by 1854 encapsulating the SignedData.PKIData in an EnvelopedData 1855 if the request was encapsulated in an EnvelopedData (see 1856 section 3.2.1.2). 1858 2.b.2 - The GLA can also optionally apply another SignedData over 1859 the EnvelopedData (see section 3.2.1.2). 1861 2.c - Else if the signatures verify and the GLAddMember request is 1862 not included in a controlSequence with the GLCreate request, 1863 the GLA makes sure the GL is supported by checking that the 1864 glName matches a glName stored on the GLA. 1866 2.c.1 - If the glName is not supported by the GLA, the GLA returns 1867 a response indicating cMCStatusInfoEx with 1868 cMCStatus.failed and 1869 otherInfo.extendedFailInfo.SKDFailInfo value of 1870 invalidGLName. 1872 2.c.2 - Else if the glName is supported by the GLA, the GLA checks 1873 to see if the glMemberName is present on the GL. 1875 2.c.2.a - If the glMemberName is present on the GL, the GLA 1876 returns a response indicating cMCStatusInfoEx with 1878 Turner 36 1879 And Distribution 1881 cMCStatus.failed and 1882 otherInfo.extendedFailInfo.SKDFailInfo value of 1883 alreadyAMember. 1885 2.c.2.b - Else if the glMemberName is not present on the GL, the 1886 GLA checks how the GL is administered. 1888 2.c.2.b.1 - If the GL is closed, the GLA checks that a registered 1889 GLO signed the request by checking that one of the 1890 names in the digital signature certificate used to 1891 sign the request matches a registered GLO. 1893 2.c.2.b.1.a - If the names do not match, the GLA returns a 1894 response indicating cMCStatusInfoEx with 1895 cMCStatus.failed and 1896 otherInfo.extendedFailInfo.SKDFailInfo value of 1897 noGLONameMatch. 1899 2.c.2.b.1.b - Else if the names match, the GLA verifies the 1900 member's encryption certificate. 1902 2.c.2.b.1.b.1 - If the member's encryption certificate cannot be 1903 verified, the GLA can return a response indicating 1904 cMCStatusInfoEx with cMCStatus.failed and 1905 otherInfo.extendedFailInfo.SKDFailInfo value of 1906 invalidCert to the GLO. If the GLA does not return 1907 a cMCStatusInfoEx.cMCStatus.failed response, the 1908 GLA issues a glProvideCert request (see section 1909 4.10). 1911 2.c.2.b.1.b.2 - Else if the member's certificate verifies, the GLA 1912 returns a cMCStatusInfoEx indicating 1913 cMCStatus.success (2 in Figure 5). The GLA also 1914 takes administrative actions, which are beyond the 1915 scope of this document, to add the member to the 1916 GL stored on the GLA. The GLA also distributes the 1917 shared KEK to the member via the mechanism 1918 described in section 5. 1920 2.c.2.b.1.b.2.a - The GLA applies confidentiality to the response 1921 by encapsulating the SignedData.PKIData in an 1922 EnvelopedData if the request was encapsulated in 1923 an EnvelopedData (see section 3.2.1.2). 1925 2.c.2.b.1.b.2.b - The GLA can also optionally apply another 1926 SignedData over the EnvelopedData (see section 1927 3.2.1.2). 1929 2.c.2.b.2 - Else if the GL is managed, the GLA checks that either 1930 a registered GLO or the prospective member signed the 1931 request. For GLOs, one of the names in the certificate 1932 used to sign the request needs to match a registered 1934 Turner 37 1935 And Distribution 1937 GLO. For the prospective member, the name in 1938 glMember.glMemberName needs to match one of the names 1939 in the certificate used to sign the request. 1941 2.c.2.b.2.a - If the signer is neither a registered GLO nor the 1942 prospective GL member, the GLA returns a response 1943 indicating cMCStatusInfoEx with cMCStatus.failed and 1944 otherInfo.extendedFailInfo.SKDFailInfo value of 1945 noSpam. 1947 2.c.2.b.2.b � Else if the signer is a registered GLO, the GLA 1948 verifies the member's encryption certificate. 1950 2.c.2.b.2.b.1 - If the member's certificate cannot be verified, 1951 the GLA can return a response indicating 1952 cMCStatusInfoEx with cMCStatus.failed and 1953 otherInfo.extendedFailInfo.SKDFailInfo value of 1954 invalidCert. If the GLA does not return a 1955 cMCStatus.failed response, the GLA MUST issue a 1956 glProvideCert request (see section 4.10). 1958 2.c.2.b.2.b.2 - Else if the member's certificate verifies, the GLA 1959 MUST return a cMCStatusInfoEx indicating 1960 cMCStatus.success to the GLO (2 in Figure 5). The 1961 GLA also takes administrative actions, which are 1962 beyond the scope of this document, to add the 1963 member to the GL stored on the GLA. The GLA also 1964 distributes the shared KEK to the member via the 1965 mechanism described in section 5. The GL policy 1966 may mandate that the GL member�s address be 1967 included in the GL member�s certificate. 1969 2.c.2.b.2.b.2.a - The GLA applies confidentiality to the response 1970 by encapsulating the SignedData.PKIData in an 1971 EnvelopedData if the request was encapsulated in 1972 an EnvelopedData (see section 3.2.1.2). 1974 2.c.2.b.2.b.2.b - The GLA can also optionally apply another 1975 SignedData over the EnvelopedData (see section 1976 3.2.1.2). 1978 2.c.2.b.2.c - Else if the signer is the prospective member, the 1979 GLA forwards the glAddMember request (see section 1980 3.2.3) to a registered GLO (B{A} in Figure 5). If 1981 there is more than one registered GLO, the GLO to 1982 which the request is forwarded to is beyond the 1983 scope of this document. Further processing of the 1984 forwarded request by GLOs is addressed in 3 of 1985 section 4.3.2. 1987 2.c.2.b.2.c.1 - The GLA applies confidentiality to the forwarded 1988 request by encapsulating the SignedData.PKIData in 1990 Turner 38 1991 And Distribution 1993 an EnvelopedData if the original request was 1994 encapsulated in an EnvelopedData (see section 1995 3.2.1.2). 1997 2.c.2.b.2.c.2 - The GLA can also optionally apply another 1998 SignedData over the EnvelopedData (see section 1999 3.2.1.2). 2001 2.c.2.b.3 - Else if the GL is unmanaged, the GLA checks that 2002 either a registered GLO or the prospective member 2003 signed the request. For GLOs, one of the names in the 2004 certificate used to sign the request needs tp match 2005 the name of a registered GLO. For the prospective 2006 member, the name in glMember.glMemberName needs to 2007 match one of the names in the certificate used to sign 2008 the request. 2010 2.c.2.b.3.a - If the signer is neither a registered GLO nor the 2011 prospective member, the GLA returns a response 2012 indicating cMCStatusInfoEx with cMCStatus.failed and 2013 otherInfo.extendedFailInfo.SKDFailInfo value of 2014 noSpam. 2016 2.c.2.b.3.b - Else if the signer is either a registered GLO or the 2017 prospective member, the GLA verifies the member's 2018 encryption certificate. 2020 2.c.2.b.3.b.1 - If the member's certificate cannot be verified, 2021 the GLA can return a response indicating 2022 cMCStatusInfoEx with cMCStatus.failed and 2023 otherInfo.extendedFailInfo.SKDFailInfo value of 2024 invalidCert to either the GLO or the prospective 2025 member depending on where the request originated. 2026 If the GLA does not return a cMCStatus.failed 2027 response, the GLA issues a glProvideCert request 2028 (see section 4.10) to either the GLO or 2029 prospective member depending on where the request 2030 originated. 2032 2.c.2.b.3.b.2 - Else if the member's certificate verifies, the GLA 2033 returns a cMCStatusInfoEx indicating 2034 cMCStatus.success to the GLO (2 in Figure 5) if 2035 the GLO signed the request and to the GL member (3 2036 in Figure 5) if the GL member signed the request. 2037 The GLA also takes administrative actions, which 2038 are beyond the scope of this document, to add the 2039 member to the GL stored on the GLA. The GLA also 2040 distributes the shared KEK to the member via the 2041 mechanism described in section 5. 2043 2.c.2.b.3.b.2.a - The GLA applies confidentiality to the response 2044 by encapsulating the SignedData.PKIData in an 2046 Turner 39 2047 And Distribution 2049 EnvelopedData if the request was encapsulated in 2050 an EnvelopedData (see section 3.2.1.2). 2052 2.c.2.b.3.b.2.b - The GLA can also optionally apply another 2053 SignedData over the EnvelopedData (see section 2054 3.2.1.2). 2056 3 - Upon receipt of the cMCStatusInfoEx response, the GLO verifies 2057 the GLA signature(s). If an additional SignedData and/or 2058 EnvelopedData encapsulates the response (see section 3.2.1.2 2059 or 3.2.2), the GLO verifies the outer signature and/or decrypt 2060 the outer layer prior to verifying the signature on the inner 2061 most SignedData. 2063 3.a - If the signatures verify, the GLO checks that one of the 2064 names in the certificate used to sign the response matches 2065 the name of the GL. 2067 3.a.1 � If the name of the GL does not match the name present in 2068 the certificate used to sign the message, the GLO should 2069 not believe the response. 2071 3.a.2 � Else if the name of the GL matches the name present in the 2072 certificate and: 2074 3.a.2.a - If the signatures verify and the response is 2075 cMCStatusInfoEx indicating cMCStatus.success, the GLA 2076 has added the member to the GL. If member was added to a 2077 managed list and the original request was signed by the 2078 member, the GLO sends a 2079 cMCStatusInfoEx.cMCStatus.success to the GL member. 2081 3.a.2.b - Else if the GLO received a 2082 cMCStatusInfoEx.cMCStatus.failed with any reason, the 2083 GLO can reattempt to add the member to the GL using the 2084 information provided in the response. 2086 4 - Upon receipt of the cMCStatusInfoEx response, the prospective 2087 member verifies the GLA signatures or GLO signatures. If an 2088 additional SignedData and/or EnvelopedData encapsulates the 2089 response (see section 3.2.1.2 or 3.2.2), the GLO verifies the 2090 outer signature and/or decrypt the outer layer prior to 2091 verifying the signature on the inner most SignedData. 2093 4.a - If the signatures verify, the GL member checks that one of 2094 the names in the certificate used to sign the response 2095 matches the name of the GL. 2097 4.a.1 � If the name of the GL does not match the name present in 2098 the certificate used to sign the message, the GL member 2099 should not believe the response. 2101 Turner 40 2102 And Distribution 2104 4.a.2 � Else if the name of the GL matches the name present in the 2105 certificate and: 2107 4.a.2.a - If the signatures verify, the prospective member has 2108 been added to the GL. 2110 4.a.2.b - Else if the prospective member received a 2111 cMCStatusInfoEx.cMCStatus.failed, for any reason, the 2112 prospective member MAY reattempt to add themselves to 2113 the GL using the information provided in the response. 2115 4.3.2 Prospective Member Initiated Additions 2117 The process for prospective member initiated glAddMember requests is 2118 as follows: 2120 1 - The prospective GL member sends a 2121 SignedData.PKIData.controlSequence.glAddMember request to the 2122 GLA (A in Figure 5). The prospective GL member includes: the 2123 GL name in glName, their name in glMember.glMemberName, their 2124 address in glMember.glMemberAddress, and their encryption 2125 certificate in glMember.certificates.pKC. The prospective GL 2126 member can also include any attribute certificates associated 2127 with their encryption certificate in glMember.certificates.aC, 2128 and the certification path associated with their encryption 2129 and attribute certificates in glMember.certificates.certPath. 2131 1.a - The prospective GL member can optionally apply 2132 confidentiality to the request by encapsulating the 2133 SignedData.PKIData in an EnvelopedData (see section 2134 3.2.1.2). 2136 1.b - The prospective GL member MAY can also optionally apply 2137 another SignedData over the EnvelopedData (see section 2138 3.2.1.2). 2140 2 - Upon receipt of the request, the GLA verifies the request as 2141 per 2 in section 4.3.1. 2143 3 - Upon receipt of the forwarded request, the GLO verifies the 2144 prospective GL member signature on the inner most 2145 SignedData.PKIData and the GLA signature on the outer layer. 2146 If an EnvelopedData encapsulates the inner most layer (see 2147 section 3.2.1.2 or 3.2.2), the GLO decrypts the outer layer 2148 prior to verifying the signature on the inner most SignedData. 2150 Note: For cases where the GL is closed and either a) a 2151 prospective member sends directly to the GLO or b) the GLA has 2152 mistakenly forwarded the request to the GLO, the GLO should 2153 first determine whether to honor the request. 2155 Turner 41 2156 And Distribution 2158 3.a - If the signatures verify, the GLO checks to make sure one of 2159 the names in the certificate used to sign the request 2160 matches the name in glMember.glMemberName. 2162 3.a.1 - If the names do not match, the GLO sends a 2163 SignedData.PKIResponse.controlSequence message back to the 2164 prospective member with cMCStatusInfoEx.cMCStatus.failed 2165 indicating why the prospective member was denied in 2166 cMCStausInfo.statusString. This stops people from adding 2167 people to GLs without their permission. 2169 3.a.2 - Else if the names match, the GLO determines whether the 2170 prospective member is allowed to be added. The mechanism 2171 is beyond the scope of this document; however, the GLO 2172 should check to see that the glMember.glMemberName is not 2173 already on the GL. 2175 3.a.2.a - If the GLO determines the prospective member is not 2176 allowed to join the GL, the GLO can return a 2177 SignedData.PKIResponse.controlSequence message back to 2178 the prospective member with 2179 cMCStatusInfoEx.cMCtatus.failed indicating why the 2180 prospective member was denied in cMCStatus.statusString. 2182 3.a.2.b - Else if GLO determines the prospective member is allowed 2183 to join the GL, the GLO verifies the member's encryption 2184 certificate. 2186 3.a.2.b.1 - If the member's certificate cannot be verified, the 2187 GLO returns a SignedData.PKIResponse.controlSequence 2188 back to the prospective member with 2189 cMCStatusInfoEx.cMCtatus.failed indicating that the 2190 member�s encryption certificate did not verify in 2191 cMCStatus.statusString. If the GLO does not return a 2192 cMCStatusInfoEx response, the GLO sends a 2193 SignedData.PKIData.controlSequence.glProvideCert 2194 message to the prospective member requesting a new 2195 encryption certificate (see section 4.10). 2197 3.a.2.b.2 - Else if the member's certificate verifies, the GLO 2198 resubmits the glAddMember request (see section 3.2.5) 2199 to the GLA (1 in Figure 5). 2201 3.a.2.b.2.a - The GLO applies confidentiality to the new 2202 GLAddMember request by encapsulating the 2203 SignedData.PKIData in an EnvelopedData if the 2204 initial request was encapsulated in an EnvelopedData 2205 (see section 3.2.1.2). 2207 3.a.2.b.2.b - The GLO can also optionally apply another SignedData 2208 over the EnvelopedData (see section 3.2.1.2). 2210 Turner 42 2211 And Distribution 2213 4 - Processing continues as in 2 of section 4.3.1. 2215 4.4 Delete Members From GL 2217 To delete members from GLs, either the GLO or members to be removed 2218 use the glDeleteMember request. The GLA processes GLO and members 2219 requesting their own removal make requests differently. The GLO can 2220 submit the request at any time to delete members from the GL, and 2221 the GLA, once it has verified the request came from a registered 2222 GLO, should delete the member. If a member sends the request, the 2223 GLA needs to determine how the GL is administered. When the GLO 2224 initially configured the GL, they set the GL to be unmanaged, 2225 managed, or closed (see section 3.1.1). In the unmanaged case, the 2226 GLA merely processes the member�s request. For the managed case, the 2227 GLA forwards the requests from the member to the GLO for review. 2228 Where there are multiple GLOs for a GL, which GLO the request is 2229 forwarded to is beyond the scope of this document. The GLO reviews 2230 the request and either rejects it or submits a reformed request to 2231 the GLA. In the closed case, the GLA will not accept requests from 2232 members. The following sections describe the processing for the 2233 GLO(s), GLA, and GL members depending on where the request 2234 originated, either from a GLO or from members wanting to be removed. 2235 Figure 6 depicts the protocol interactions for the three options. 2236 Note that the error messages are not depicted. 2238 +-----+ 2,B{A} 3 +----------+ 2239 | GLO | <--------+ +-------> | Member 1 | 2240 +-----+ | | +----------+ 2241 1 | | 2242 +-----+ <--------+ | 3 +----------+ 2243 | GLA | A +-------> | ... | 2244 +-----+ <-------------+ +----------+ 2245 | 2246 | 3 +----------+ 2247 +-------> | Member n | 2248 +----------+ 2250 Figure 6 - Member Deletion 2252 If the member is not removed from the GL, they will continue to 2253 receive and be able to decrypt data protected with the shared KEK 2254 and will continue to receive rekeys. For unmanaged lists, there is 2255 no point to a group rekey because there is no guarantee that the 2256 member requesting to be removed has not already added themselves 2257 back on the GL under a different name. For managed and closed GLs, 2258 the GLO needs to take steps to ensure the member being deleted is 2259 not on the GL twice. After ensuring this, managed and closed GLs can 2260 be rekeyed to maintain the confidentiality of the traffic sent by 2261 group members. If the GLO is sure the member has been deleted the 2262 group rekey mechanism can be used to distribute the new key (see 2263 sections 4.5 and 5). 2265 Turner 43 2266 And Distribution 2268 4.4.1 GLO Initiated Deletions 2270 The process for GLO initiated glDeleteMember requests is as follows: 2272 1 - The GLO collects the pertinent information for the member(s) 2273 to be deleted (this can be done through an out of bands 2274 means). The GLO then sends a 2275 SignedData.PKIData.controlSequence with a separate 2276 glDeleteMember request for each member to the GLA (1 in Figure 2277 6). The GLO MUST include: the GL name in glName and the 2278 member's name in glMemberToDelete. If the GL from which the 2279 member is being deleted in a closed or managed GL, the GLO 2280 MUST also generate a glRekey request and include it with the 2281 glDeletemember request (see section 4.5). 2283 1.a - The GLO can optionally apply confidentiality to the request 2284 by encapsulating the SignedData.PKIData in an EnvelopedData 2285 (see section 3.2.1.2). 2287 1.b - The GLO can also optionally apply another SignedData over 2288 the EnvelopedData (see section 3.2.1.2). 2290 2 - Upon receipt of the request, the GLA verifies the signature on 2291 the inner most SignedData.PKIData. If an additional SignedData 2292 and/or EnvelopedData encapsulates the request (see section 2293 3.2.1.2 or 3.2.2), the GLA verifies the outer signature and/or 2294 decrypt the outer layer prior to verifying the signature on 2295 the inner most SignedData. 2297 2.a - If the signatures cannot be verified, the GLA returns a 2298 cMCStatusInfoEx response indicating cMCStatus.failed and 2299 otherInfo.failInfo.badMessageCheck. 2301 2.b - Else if the signatures verify, the GLA makes sure the GL is 2302 supported by the GLA by checking that the glName matches a 2303 glName stored on the GLA. 2305 2.b.1 - If the glName is not supported by the GLA, the GLA returns 2306 a response indicating cMCStatusInfoEx with 2307 cMCStatus.failed and 2308 otherInfo.extendedFailInfo.SKDFailInfo value of 2309 invalidGLName. 2311 2.b.2 - Else if the glName is supported by the GLA, the GLA checks 2312 to see if the glMemberName is present on the GL. 2314 2.b.2.a - If the glMemberName is not present on the GL, the GLA 2315 returns a response indicating cMCStatusInfoEx with 2316 cMCStatus.failed and 2318 Turner 44 2319 And Distribution 2321 otherInfo.extendedFailInfo.SKDFailInfo value of 2322 notAMember. 2324 2.b.2.b - Else if the glMemberName is already on the GL, the GLA 2325 checks how the GL is administered. 2327 2.b.2.b.1 - If the GL is closed, the GLA checks that the 2328 registered GLO signed the request by checking that one 2329 of the names in the digital signature certificate used 2330 to sign the request matches the registered GLO. 2332 2.b.2.b.1.a - If the names do not match, the GLA returns a 2333 response indicating cMCStatusInfoEx with 2334 cMCStatus.failed and 2335 otherInfo.extendedFailInfo.SKDFailInfo value of 2336 closedGL. 2338 2.b.2.b.1.b - Else if the names do match, the GLA returns a 2339 cMCStatusInfoEx.cMCStatus.success (2 in Figure 5). 2340 The GLA also takes administrative actions, which are 2341 beyond the scope of this document, to delete the 2342 member with the GL stored on the GLA. Note that he 2343 GL also needs to be rekeyed as described in section 2344 5. 2346 2.b.2.b.1.b.1 - The GLA applies confidentiality to the response by 2347 encapsulating the SignedData.PKIData in an 2348 EnvelopedData if the request was encapsulated in 2349 an EnvelopedData (see section 3.2.1.2). 2351 2.b.2.b.1.b.2 - The GLA can also optionally apply another 2352 SignedData over the EnvelopedData (see section 2353 3.2.1.2). 2355 2.b.2.b.2 - Else if the GL is managed, the GLA checks that either 2356 a registered GLO or the prospective member signed the 2357 request. For GLOs, one of the names in the certificate 2358 used to sign the request needs to match a registered 2359 GLO. For the prospective member, the name in 2360 glMember.glMemberName needs to match one of the names 2361 in the certificate used to sign the request. 2363 2.b.2.b.2.a - If the signer is neither a registered GLO nor the 2364 prospective GL member, the GLA returns a response 2365 indicating cMCStatusInfoEx with cMCStatus.failed and 2366 otherInfo.extendedFailInfo.SKDFailInfo value of 2367 noSpam. 2369 2.b.2.b.2.b - Else if the signer is a registered GLO, the GLA 2370 returns a cMCStatusInfoEx.cMCStatus.success (2 in 2371 Figure 6). The GLA also takes administrative 2372 actions, which are beyond the scope of this 2374 Turner 45 2375 And Distribution 2377 document, to delete the member with the GL stored on 2378 the GLA. Note that the GL will also be rekeyed as 2379 described in section 5. 2381 2.b.2.b.2.b.1 - The GLA applies confidentiality to the response by 2382 encapsulating the SignedData.PKIData in an 2383 EnvelopedData if the request was encapsulated in 2384 an EnvelopedData (see section 3.2.1.2). 2386 2.b.2.b.2.b.2 - The GLA can also optionally apply another 2387 SignedData over the EnvelopedData (see section 2388 3.2.1.2). 2390 2.b.2.b.2.c - Else if the signer is the prospective member, the 2391 GLA forwards the glDeleteMember request (see section 2392 3.2.3) to the GLO (B{A} in Figure 6). If there is 2393 more than one registered GLO, the GLO to which the 2394 request is forwarded to is beyond the scope of this 2395 document. Further processing of the forwarded 2396 request by GLOs is addressed in 3 of section 4.4.2. 2398 2.b.2.b.2.c.1 - The GLA applies confidentiality to the forwarded 2399 request by encapsulating the SignedData.PKIData in 2400 an EnvelopedData if the request was encapsulated 2401 in an EnvelopedData (see section 3.2.1.2). 2403 2.b.2.b.2.c.2 - The GLA can also optionally apply another 2404 SignedData over the EnvelopedData (see section 2405 3.2.1.2). 2407 2.b.2.b.3 - Else if the GL is unmanaged, the GLA checks that 2408 either a registered GLO or the prospective member 2409 signed the request. For GLOs, one of the names in the 2410 certificate used to sign the request needs to match 2411 the name of a registered GLO. For the prospective 2412 member, the name in glMember.glMemberName needs to 2413 match one of the names in the certificate used to sign 2414 the request. 2416 2.b.2.b.3.a - If the signer is neither the GLO nor the prospective 2417 member, the GLA returns a response indicating 2418 cMCStatusInfoEx with cMCStatus.failed and 2419 otherInfo.extendedFailInfo.SKDFailInfo value of 2420 noSpam. 2422 2.b.2.b.3.b - Else if the signer is either a registered GLO or the 2423 member, the GLA returns a 2424 cMCStatusInfoEx.cMCStatus.success to the GLO (2 in 2425 Figure 6) if the GLO signed the request and to the 2426 GL member (3 in Figure 6) if the GL member signed 2427 the request. The GLA also takes administrative 2428 actions, which are beyond the scope of this 2430 Turner 46 2431 And Distribution 2433 document, to delete the member with the GL stored on 2434 the GLA. 2436 2.b.2.b.3.b.1 - The GLA applies confidentiality to the response by 2437 encapsulating the SignedData.PKIData in an 2438 EnvelopedData if the request was encapsulated in 2439 an EnvelopedData (see section 3.2.1.2). 2441 2.b.2.b.3.b.2 - The GLA can also optionally apply another 2442 SignedData over the EnvelopedData (see section 2443 3.2.1.2). 2445 3 - Upon receipt of the cMCStatusInfoEx response, the GLO verifies 2446 the GLA signatures. If an additional SignedData and/or 2447 EnvelopedData encapsulates the response (see section 3.2.1.2 2448 or 3.2.2), the GLO verifies the outer signature and/or decrypt 2449 the outer layer prior to verifying the signature on the inner 2450 most SignedData. 2452 3.a - If the signatures do verify, the GLO checks that one of the 2453 names in the certificate used to sign the response matches 2454 the name of the GL. 2456 3.a.1 � If the name of the GL does not match the name present in 2457 the certificate used to sign the message, the GLO should 2458 not believe the response. 2460 3.a.2 � Else if the name of the GL matches the name present in the 2461 certificate and: 2463 3.a.2.a - If the signatures verify and the response is 2464 cMCStatusInfoEx.cMCStatus.success, the GLO has deleted 2465 the member from the GL. If member was deleted from a 2466 managed list and the original request was signed by the 2467 member, the GLO sends a 2468 cMCStatusInfoEx.cMCStatus.success to the GL member. 2470 3.a.2.b - Else if the GLO received a 2471 cMCStatusInfoEx.cMCStatus.failed with any reason, the 2472 GLO may reattempt to delete the member from the GL using 2473 the information provided in the response. 2475 4 - Upon receipt of the cMCStatusInfoEx response, the member 2476 verifies the GLA signature(s) or GLO signature(s). If an 2477 additional SignedData and/or EnvelopedData encapsulates the 2478 response (see section 3.2.1.2 or 3.2.2), the GLO verifies the 2479 outer signature and/or decrypt the outer layer prior to 2480 verifying the signature on the inner most SignedData. 2482 4.a - If the signatures verify, the GL member checks that one of 2483 the names in the certificate used to sign the response 2484 matches the name of the GL. 2486 Turner 47 2487 And Distribution 2489 4.a.1 � If the name of the GL does not match the name present in 2490 the certificate used to sign the message, the GL member 2491 should not believe the response. 2493 4.a.2 � Else if the name of the GL matches the name present in the 2494 certificate and: 2496 4.a.2.a - If the signature(s) verify, the member has been deleted 2497 from the GL. 2499 4.a.2.b - Else if the member received a 2500 cMCStatusInfoEx.cMCStatus.failed with any reason, the 2501 member can reattempt to delete themselves from the GL 2502 using the information provided in the response. 2504 4.4.2 Member Initiated Deletions 2506 The process for member initiated deletion of their own membership 2507 using the glDeleteMember requests is as follows: 2509 1 - The member sends a 2510 SignedData.PKIData.controlSequence.glDeleteMember request to 2511 the GLA (A in Figure 6). The member includes: the name of the 2512 GL in glName and their own name in glMemberToDelete. 2514 1.a - The member can optionally apply confidentiality to the 2515 request by encapsulating the SignedData.PKIData in an 2516 EnvelopedData (see section 3.2.1.2). 2518 1.b - The member can also optionally apply another SignedData over 2519 the EnvelopedData (see section 3.2.1.2). 2521 2 - Upon receipt of the request, the GLA verifies the request as 2522 per 2 in section 4.4.1. 2524 3 - Upon receipt of the forwarded request, the GLO verifies the 2525 member signature on the inner most SignedData.PKIData and the 2526 GLA signature on the outer layer. If an EnvelopedData 2527 encapsulates the inner most layer (see section 3.2.1.2 or 2528 3.2.2), the GLO decrypts the outer layer prior to verifying 2529 the signature on the inner most SignedData. 2531 Note: For cases where the GL is closed and either (a) a 2532 prospective member sends directly to the GLO or (b) the GLA 2533 has mistakenly forwarded the request to the GLO, the GLO 2534 should first determine whether to honor the request. 2536 3.a - If the signatures cannot be verified, the GLO returns a 2537 cMCStatusInfoEx response indicating cMCStatus.failed and 2538 otherInfo.failInfo.badMessageCheck. 2540 Turner 48 2541 And Distribution 2543 3.b - Else if the signatures verify, the GLO checks to make sure 2544 one of the names in the certificates used to sign the 2545 request matches the name in glMemberToDelete. 2547 3.b.1 - If the names match, the GLO sends a 2548 SignedData.PKIResponse.controlSequence message back to the 2549 prospective member with cMCStatusInfoEx.cMCtatus.failed 2550 indicating why the prospective member was denied in 2551 cMCStatusInfoEx.statusString. This stops people from 2552 adding people to GLs without their permission. 2554 3.b.2 - Else if the names match, the GLO resubmits the 2555 glDeleteMember request (see section 3.2.5) to the GLA (1 2556 in Figure 6). The GLO makes sure the glMemberName is 2557 already on the GL. The GLO also generates a glRekey 2558 request and include it with the GLDeleteMember request 2559 (see section 4.5). 2561 3.b.2.a - The GLO applies confidentiality to the new 2562 GLDeleteMember request by encapsulating the 2563 SignedData.PKIData in an EnvelopedData if the initial 2564 request was encapsulated in an EnvelopedData (see 2565 section 3.2.1.2). 2567 3.b.2.b - The GLO can also optionally apply another SignedData 2568 over the EnvelopedData (see section 3.2.1.2). 2570 4 - Further processing is as in 2 of section 4.4.1. 2572 4.5 Request Rekey Of GL 2574 From time to time, the GL will need to be rekeyed. Some situations 2575 follow: 2577 - When a member is removed from a closed or managed GL. In this 2578 case, the PKIData.controlSequence containing the glDeleteMember 2579 ought to contain a glRekey request. 2581 - Depending on policy, when a member is removed from an unmanaged 2582 GL. If the policy is to rekey the GL, the 2583 PKIData.controlSequence containing the glDeleteMember could also 2584 contain a glRekey request or an out of bands means could be used 2585 to tell the GLA to rekey the GL. Rekeying of unmanaged GLs when 2586 members are deleted is not advised. 2588 - When the current shared KEK has been compromised. 2590 - When the current shared KEK is about to expire. Consider two 2591 cases: 2593 Turner 49 2594 And Distribution 2596 - If the GLO controls the GL rekey, the GLA should not assume 2597 that a new shared KEK should be distributed, but instead wait 2598 for the glRekey message. 2600 - If the GLA controls the GL rekey, the GLA should initiate a 2601 glKey message as specified in section 5. 2603 If the generationCounter (see section 3.1.1) is set to a value 2604 greater than one (1) and the GLO controls the GL rekey, the GLO may 2605 generate a glRekey any time before the last shared KEK has expired. 2606 To be on the safe side, the GLO ought to request a rekey one (1) 2607 duration before the last shared KEK expires. 2609 The GLA and GLO are the only entities allowed to initiate a GL 2610 rekey. The GLO indicated whether they are going to control rekeys or 2611 whether the GLA is going to control rekeys when they assigned the 2612 shared KEK to GL (see section 3.1.1). The GLO initiates a GL rekey 2613 at any time. The GLA can be configured to automatically rekey the GL 2614 prior to the expiration of the shared KEK (the length of time before 2615 the expiration is an implementation decision). The GLA can also 2616 automatically rekey GLs that have been compromised, but this is 2617 covered in section 5. Figure 7 depicts the protocol interactions to 2618 request a GL rekey. Note that error messages are not depicted. 2620 +-----+ 1 2,A +-----+ 2621 | GLA | <-------> | GLO | 2622 +-----+ +-----+ 2624 Figure 7 - GL Rekey Request 2626 4.5.1 GLO Initiated Rekey Requests 2628 The process for GLO initiated glRekey requests is as follows: 2630 1 - The GLO sends a SignedData.PKIData.controlSequence.glRekey 2631 request to the GLA (1 in Figure 7). The GLO includes the 2632 glName. If glAdministration and glKeyNewAttributes are omitted 2633 then there is no change from the previously registered GL 2634 values for these fields. If the GLO wants to force a rekey for 2635 all outstanding shared KEKs it includes the glRekeyAllGLKeys 2636 set to TRUE. 2638 1.a - The GLO can optionally apply confidentiality to the request 2639 by encapsulating the SignedData.PKIData in an EnvelopedData 2640 (see section 3.2.1.2). 2642 1.b - The GLO can also optionally apply another SignedData over 2643 the EnvelopedData (see section 3.2.1.2). 2645 2 - Upon receipt of the request, the GLA verifies the signature on 2646 the inner most SignedData.PKIData. If an additional SignedData 2648 Turner 50 2649 And Distribution 2651 and/or EnvelopedData encapsulates the request (see section 2652 3.2.1.2 or 3.2.2), the GLA verifies the outer signature and/or 2653 decrypt the outer layer prior to verifying the signature on 2654 the inner most SignedData. 2656 2.a - If the signatures do not verify, the GLA returns a 2657 cMCStatusInfoEx response indicating cMCStatus.failed and 2658 otherInfo.failInfo.badMessageCheck. 2660 2.b - Else if the signatures do verify, the GLA makes sure the GL 2661 is supported by the GLA by checking that the glName matches 2662 a glName stored on the GLA. 2664 2.b.1 - If the glName present does not match a GL stored on the 2665 GLA, the GLA returns a response indicating cMCStatusInfoEx 2666 with cMCStatus.failed and 2667 otherInfo.extendedFailInfo.SKDFailInfo value of 2668 invalidGLName. 2670 2.b.2 - Else if the glName present matches a GL stored on the GLA, 2671 the GLA checks that a registered GLO signed the request by 2672 checking that one of the names in the certificate used to 2673 sign the request is a registered GLO. 2675 2.b.2.a - If the names do not match, the GLA returns a response 2676 indicating cMCStatusInfoEx with cMCStatus.failed and 2677 otherInfo.extendedFailInfo.SKDFailInfo value of 2678 noGLONameMatch. 2680 2.b.2.b - Else if the names match, the GLA checks the 2681 glNewKeyAttribute values. 2683 2.b.2.b.1 - If the new value for requestedAlgorithm is not 2684 supported, the GLA returns a response indicating 2685 cMCStatusInfoEx with cMCStatus.failed and 2686 otherInfo.extendedFailInfo.SKDFailInfo value of 2687 unsupportedAlgorithm. 2689 2.b.2.b.2 - Else if the new value duration is not supportable, 2690 determining this is beyond the scope this document, 2691 the GLA returns a response indicating cMCStatusInfoEx 2692 with cMCStatus.failed and 2693 otherInfo.extendedFailInfo.SKDFailInfo value of 2694 unsupportedDuration. 2696 2.b.2.b.3 - Else if the GL is not supportable for other reasons, 2697 which the GLA does not wish to disclose, the GLA 2698 returns a response indicating cMCStatusInfoEx with 2699 cMCStatus.failed and 2700 otherInfo.extendedFailInfo.SKDFailInfo value of 2701 unspecified. 2703 Turner 51 2704 And Distribution 2706 2.b.2.b.4 - Else if the new requestedAlgorithm and duration are 2707 supportable or the glNewKeyAttributes was omitted, the 2708 GLA returns a cMCStatusInfoEx.cMCStatus.success (2 in 2709 Figure 7). The GLA also uses the glKey message to 2710 distribute the rekey shared KEK (see section 5). 2712 2.b.2.b.4.a - The GLA applies confidentiality to response by 2713 encapsulating the SignedData.PKIData in an 2714 EnvelopedData if the request was encapsulated in an 2715 EnvelopedData (see section 3.2.1.2). 2717 2.b.2.b.4.b - The GLA can also optionally apply another SignedData 2718 over the EnvelopedData (see section 3.2.1.2). 2720 3 - Upon receipt of the cMCStatusInfoEx response, the GLO verifies 2721 the GLA signature(s). If an additional SignedData and/or 2722 EnvelopedData encapsulates the forwarded response (see section 2723 3.2.1.2 or 3.2.2), the GLO verifies the outer signature and/or 2724 decrypt the forwarded response prior to verifying the 2725 signature on the inner most SignedData. 2727 3.a - If the signatures verify, the GLO checks that one of the 2728 names in the certificate used to sign the response matches 2729 the name of the GL. 2731 3.a.1 � If the name of the GL does not match the name present in 2732 the certificate used to sign the message, the GLO should 2733 not believe the response. 2735 3.a.2 � Else if the name of the GL matches the name present in the 2736 certificate and: 2738 3.a.2.a - If the signatures verify and the response is 2739 cMCStatusInfoEx.cMCStatus.success, the GLO has 2740 successfully rekeyed the GL. 2742 3.a.2.b � Else if the GLO received a 2743 cMCStatusInfoEx.cMCStatus.failed with any reason, the 2744 GLO can reattempt to rekey the GL using the information 2745 provided in the response. 2747 Turner 52 2748 And Distribution 2750 4.5.2 GLA Initiated Rekey Requests 2752 If the GLA is in charge of rekeying the GL the GLA will 2753 automatically issue a glKey message (see section 5). In addition the 2754 GLA will generate a cMCStatusInfoEx to indicate to the GL that a 2755 successful rekey has occurred. The process for GLA initiated rekey 2756 is as follows: 2758 1 - The GLA generates for all GLOs a 2759 SignedData.PKIData.controlSequence.cMCStatusInfoEx.cMCStatus.s 2760 uccess (A in Figure 7). 2762 1.a - The GLA can optionally apply confidentiality to the request 2763 by encapsulating the SignedData.PKIData in an EnvelopedData 2764 (see section 3.2.1.2). 2766 1.b - The GLA can also optionally apply another SignedData over 2767 the EnvelopedData (see section 3.2.1.2). 2769 2 - Upon receipt of the cMCStatusInfoEx.cMCStatus.success 2770 response, the GLO verifies the GLA signature(s). If an 2771 additional SignedData and/or EnvelopedData encapsulates the 2772 forwarded response (see section 3.2.1.2 or 3.2.2), the GLO 2773 MUST verify the outer signature and/or decrypt the outer layer 2774 prior to verifying the signature on the inner most SignedData. 2776 2.a - If the signatures verify, the GLO checks that one of the 2777 names in the certificate used to sign the response matches 2778 the name of the GL. 2780 2.a.1 � If the name of the GL does not match the name present in 2781 the certificate used to sign the message, the GLO ought 2782 not believe the response. 2784 2.a.2 � Else if the name of the GL does match the name present in 2785 the certificate and and the response is 2786 cMCStatusInfoEx.cMCStatus.success, the GLO knows the GLA 2787 has successfully rekeyed the GL. 2789 4.6 Change GLO 2791 Management of managed and closed GLs can become difficult for one 2792 GLO if the GL membership grows large. To support distributing the 2793 workload, GLAs support having GLs be managed by multiple GLOs. The 2794 glAddOwner and glRemoveOwner messages are designed to support adding 2795 and removing registered GLOs. Figure 8 depicts the protocol 2796 interactions to send glAddOwner and glRemoveOwner messages and the 2797 resulting response messages. 2799 Turner 53 2800 And Distribution 2802 +-----+ 1 2 +-----+ 2803 | GLA | <-------> | GLO | 2804 +-----+ +-----+ 2806 Figure 8 - GLO Add & Delete Owners 2808 The process for glAddOwner and glDeleteOwner is as follows: 2810 1 - The GLO sends a SignedData.PKIData.controlSequence.glAddOwner 2811 or glRemoveOwner request to the GLA (1 in Figure 8). The GLO 2812 includes: the GL name in glName, the name and address of the 2813 GLO in glOwnerName and glOwnerAddress, respectively. 2815 1.a - The GLO can optionally apply confidentiality to the request 2816 by encapsulating the SignedData.PKIData in an EnvelopedData 2817 (see section 3.2.1.2). 2819 1.b - The GLO can also optionally apply another SignedData over 2820 the EnvelopedData (see section 3.2.1.2). 2822 2 - Upon receipt of the glAddOwner or glRemoveOwner request, the 2823 GLA verifies the GLO signature(s). If an additional SignedData 2824 and/or EnvelopedData encapsulates the request (see section 2825 3.2.1.2 or 3.2.2), the GLA verifies the outer signature and/or 2826 decrypt the outer layer prior to verifying the signature on 2827 the inner most SignedData. 2829 2.a - If the signatures cannot verified, the GLA returns a 2830 cMCStatusInfoEx response indicating cMCStatus.failed and 2831 otherInfo.failInfo.badMessageCheck. 2833 2.b - Else if the signatures verify, the GLA makes sure the GL is 2834 supported by checking that the glName matches a glName 2835 stored on the GLA. 2837 2.b.1 - If the glName is not supported by the GLA, the GLA returns 2838 a response indicating cMCStatusInfoEx with 2839 cMCStatus.failed and 2840 otherInfo.extendedFailInfo.SKDFailInfo value of 2841 invalidGLName. 2843 2.b.2 - Else if the glName is supported by the GLA, the GLA 2844 ensures a registered GLO signed the glAddOwner or 2845 glRemoveOwner request by checking that one of the names 2846 present in the digital signature certificate used to sign 2847 the glAddOwner or glDeleteOwner request matches the name 2848 of a registered GLO. 2850 2.b.2.a - If the names do not match, the GLA returns a response 2851 indicating cMCStatusInfoEx with cMCStatus.failed and 2852 otherInfo.extendedFailInfo.SKDFailInfo value of 2853 noGLONameMatch. 2855 Turner 54 2856 And Distribution 2858 2.b.2.b - Else if the names match, the GLA returns a 2859 cMCStatusInfoEx.cMCStatus.success (2 in Figure 4). The 2860 GLA also takes administrative actions to associate the 2861 new glOwnerName with the GL in the case of glAddOwner or 2862 to disassociate the old glOwnerName with the GL in the 2863 cased of glRemoveOwner. 2865 2.b.2.b.1 - The GLA applies confidentiality to the response by 2866 encapsulating the SignedData.PKIResponse in an 2867 EnvelopedData if the request was encapsulated in an 2868 EnvelopedData (see section 3.2.1.2). 2870 2.b.2.b.2 - The GLA can also optionally apply another SignedData 2871 over the EnvelopedData (see section 3.2.1.2). 2873 3 - Upon receipt of the cMCStatusInfoEx response, the GLO verifies 2874 the GLA's signature(s). If an additional SignedData and/or 2875 EnvelopedData encapsulates the response (see section 3.2.1.2 2876 or 3.2.2), the GLO verifies the outer signature and/or decrypt 2877 the outer layer prior to verifying the signature on the inner 2878 most SignedData. 2880 3.a - If the signatures verify, the GLO checks that one of the 2881 names in the certificate used to sign the response matches 2882 the name of the GL. 2884 3.a.1 � If the name of GL does not match the name present in the 2885 certificate used to sign the message, the GLO should not 2886 believe the response. 2888 3.a.2 � Else if the name of the GL does match the name present in 2889 the certificate and: 2891 3.a.2.a - If the signatures verify and the response was 2892 cMCStatusInfoEx.cMCStatus.success, the GLO has 2893 successfully added or removed the GLO. 2895 3.a.2.b - Else if the signatures verify and the response was 2896 cMCStatusInfoEx.cMCStatus.failed with any reason, the 2897 GLO can reattempt to add or delete the GLO using the 2898 information provided in the response. 2900 4.7 Indicate KEK Compromise 2902 There will be times when the shared KEK is compromised. GL members 2903 and GLOs use glkCompromise to tell the GLA that the shared KEK has 2904 been compromised. Figure 9 depicts the protocol interactions for GL 2905 Key Compromise. 2907 Turner 55 2908 And Distribution 2910 +-----+ 2{1} 4 +----------+ 2911 | GLO | <----------+ +-------> | Member 1 | 2912 +-----+ 5,3{1} | | +----------+ 2913 +-----+ <----------+ | 4 +----------+ 2914 | GLA | 1 +-------> | ... | 2915 +-----+ <---------------+ +----------+ 2916 | 4 +----------+ 2917 +-------> | Member n | 2918 +----------+ 2920 Figure 9 - GL Key Compromise 2922 4.7.1 GL Member Initiated KEK Compromise Message 2924 The process for GL member initiated glkCompromise messages is as 2925 follows: 2927 1 - The GL member sends a 2928 SignedData.PKIData.controlSequence.glkCompromise request to 2929 the GLA (1 in Figure 9). The GL member includes the name of 2930 the GL in GeneralName. 2932 1.a - The GL member can optionally apply confidentiality to the 2933 request by encapsulating the SignedData.PKIData in an 2934 EnvelopedData (see section 3.2.1.2). The glkCompromise can 2935 be included in an EnvelopedData generated with the 2936 compromised shared KEK. 2938 1.b - The GL member can also optionally apply another SignedData 2939 over the EnvelopedData (see section 3.2.1.2). 2941 2 - Upon receipt of the glkCompromise request, the GLA verifies 2942 the GL member signature(s). If an additional SignedData and/or 2943 EnvelopedData encapsulates the request (see section 3.2.1.2 or 2944 3.2.2), the GLA verifies the outer signature and/or decrypt 2945 the outer layer prior to verifying the signature on the inner 2946 most SignedData. 2948 2.a - If the signatures cannotbe verified, the GLA returns a 2949 cMCStatusInfoEx response indicating cMCStatus.failed and 2950 otherInfo.failInfo.badMessageCheck. 2952 2.b - Else if the signatures verify, the GLA makes sure the GL is 2953 supported by checking that the indicated GL name matches a 2954 glName stored on the GLA. 2956 2.b.1 - If the glName is not supported by the GLA, the GLA returns 2957 a response indicating cMCStatusInfoEx with 2958 cMCStatus.failed and 2959 otherInfo.extendedFailInfo.SKDFailInfo value of 2960 invalidGLName. 2962 Turner 56 2963 And Distribution 2965 2.b.2 - Else if the glName is supported by the GLA, the GLA checks 2966 who signed the request. For GLOs, one of the names in the 2967 certificate used to sign the request needs to match a 2968 registered GLO. For the member, the name in 2969 glMember.glMemberName needs to match one of the names in 2970 the certificate used to sign the request. 2972 2.b.2.a - If the GLO signed the request, the GLA generates a glKey 2973 message as described in section 5 to rekey the GL (4 in 2974 Figure 9). 2976 2.b.2.b - Else if someone other than the GLO signed the request, 2977 the GLA forwards the glkCompromise message (see section 2978 3.2.3) to the GLO (2{1} in Figure 9). If there is more 2979 than one GLO, to which GLO the request is forwarded is 2980 beyond the scope of this document. Further processing by 2981 the GLO is discussed in section 4.7.2. 2983 4.7.2 GLO Initiated KEK Compromise Message 2985 The process for GLO initiated glkCompromise messages is as follows: 2987 1 - The GLO either: 2989 1.a - Generates the glkCompromise message itself by sending a 2990 SignedData.PKIData.controlSequence.glkCompromise request to 2991 the GLA (5 in Figure 9). The GLO includes the name of the GL 2992 in GeneralName. 2994 1.a.1 - The GLO can optionally apply confidentiality to the 2995 request by encapsulating the SignedData.PKIData in an 2996 EnvelopedData (see section 3.2.1.2). The glkCompromise can 2997 be included in an EnvelopedData generated with the 2998 compromised shared KEK. 3000 1.a.2 - The GLO can also optionally apply another SignedData over 3001 the EnvelopedData (see section 3.2.1.2). 3003 1.b � Otherwise, verifies the GLA and GL member signatures on the 3004 forwarded glkCompromise message. If an additional SignedData 3005 and/or EnvelopedData encapsulates the request (see section 3006 3.2.1.2 or 3.2.2), the GLO verifies the outer signature 3007 and/or decrypt the outer layer prior to verifying the 3008 signature on the inner most SignedData. 3010 1.b.1 - If the signatures cannot be verified, the GLO returns a 3011 cMCStatusInfoEx response indicating cMCStatus.failed and 3012 otherInfo.failInfo.badMessageCheck. 3014 1.b.1.a - If the signatures verify, the GLO checks the names in 3015 the certificate match the name of the signer (i.e., the 3017 Turner 57 3018 And Distribution 3020 name in the certificate used to sign the GL member�s 3021 request is the GL member). 3023 1.b.1.a.1 � If either name does not match, the GLO ought not trust 3024 the signer and it ought not forward the message to the 3025 GLA. 3027 1.b.1.a.2 � Else if the names match and the signatures verify, the 3028 GLO determines whether to forward the glkCompromise 3029 message back to the GLA (3{1} in Figure 9). Further 3030 processing by the GLA is in 2 of section 4.7.1. The 3031 GLO can also return a response to the prospective 3032 member with cMCStatusInfoEx.cMCtatus.success 3033 indicating that the glkCompromise message was 3034 successfully received. 3036 4.8 Request KEK Refresh 3038 There will be times when GL members have unrecoverably lost their 3039 shared KEK. The shared KEK is not compromised and a rekey of the 3040 entire GL is not necessary. GL members use the glkRefresh message to 3041 request that the shared KEK(s) be redistributed to them. Figure 10 3042 depicts the protocol interactions for GL Key Refresh. 3044 +-----+ 1 2 +----------+ 3045 | GLA | <-----------> | Member | 3046 +-----+ +----------+ 3048 Figure 10 - GL KEK Refresh 3050 The process for glkRefresh is as follows: 3052 1 - The GL member sends a 3053 SignedData.PKIData.controlSequence.glkRefresh request to the 3054 GLA (1 in Figure 10). The GL member includes name of the GL in 3055 GeneralName. 3057 1.a - The GL member can optionally apply confidentiality to the 3058 request by encapsulating the SignedData.PKIData in an 3059 EnvelopedData (see section 3.2.1.2). 3061 1.b - The GL member can also optionally apply another SignedData 3062 over the EnvelopedData (see section 3.2.1.2). 3064 2 - Upon receipt of the glkRefresh request, the GLA verifies the 3065 GL member signature(s). If an additional SignedData and/or 3066 EnvelopedData encapsulates the request (see section 3.2.1.2 or 3067 3.2.2), the GLA verifies the outer signature and/or decrypt 3068 the outer layer prior to verifying the signature on the inner 3069 most SignedData. 3071 Turner 58 3072 And Distribution 3074 2.a - If the signatures cannot be verified, the GLA returns a 3075 cMCStatusInfoEx response indicating cMCStatus.failed and 3076 otherInfo.failInfo.badMessageCheck. 3078 2.b - Else if the signatures verify, the GLA makes sure the GL is 3079 supported by checking that the GLGeneralName matches a 3080 glName stored on the GLA. 3082 2.b.1 - If the name of the GL is not supported by the GLA, the GLA 3083 returns a response indicating cMCStatusInfoEx with 3084 cMCStatus.failed and 3085 otherInfo.extendedFailInfo.SKDFailInfo value of 3086 invalidGLName. 3088 2.b.2 � Else if the glName is supported by the GLA, the GLA 3089 ensures the GL member is on the GL. 3091 2.b.2.a - If the glMemberName is not present on the GL, the GLA 3092 returns a response indicating cMCStatusInfoEx with 3093 cMCStatus.failed and 3094 otherInfo.extendedFailInfo.SKDFailInfo value of noSpam. 3096 2.b.2.b - Else if the glMemberName is present on the GL, the GLA 3097 returns a cMCStatusInfoEx.cMCStatus.success and a glKey 3098 message (2 in Figure 10) as described in section 5. 3100 4.9 GLA Query Request and Response 3102 There will be certain times when a GLO is having trouble setting up 3103 a GL because they do not know the algorithm(s) or some other 3104 characteristic that the GLA supports. There can also be times when 3105 prospective GL members or GL members need to know something about 3106 the GLA (these requests are not defined in the document). The 3107 glaQueryRequest and glaQueryResponse message have been defined to 3108 support determining this information. Figure 11 depicts the protocol 3109 interactions for glaQueryRequest and glaQueryResponse. 3111 +-----+ 1 2 +------------------+ 3112 | GLA | <-------> | GLO or GL Member | 3113 +-----+ +------------------+ 3115 Figure 11 - GLA Query Request & Response 3117 The process for glaQueryRequest and glaQueryResponse is as follows: 3119 1 - The GLO, GL member, or prospective GL member sends a 3120 SignedData.PKIData.controlSequence.glaQueryRequest request to 3121 the GLA (1 in Figure 11). The GLO, GL member, or prospective 3123 Turner 59 3124 And Distribution 3126 GL member indicates the information they are interested in 3127 receiving from the GLA. 3129 1.a - The GLO, GL member, or prospective GL member can optionally 3130 apply confidentiality to the request by encapsulating the 3131 SignedData.PKIData in an EnvelopedData (see section 3132 3.2.1.2). 3134 1.b - The GLO, GL member, or prospective GL member can also 3135 optionally apply another SignedData over the EnvelopedData 3136 (see section 3.2.1.2). 3138 2 - Upon receipt of the glaQueryRequest, the GLA determines if it 3139 accepts glaQueryRequest messages. 3141 2.a - If the GLA does not accept glaQueryRequest messages, the GLA 3142 returns a cMCStatusInfoEx response indicating 3143 cMCStatus.noSupport and any other information in 3144 statusString. 3146 2.b - Else if the GLA does accept GLAQueryRequests, the GLA 3147 verifies the GLO, GL member, or prospective GL member 3148 signature(s). If an additional SignedData and/or 3149 EnvelopedData encapsulates the request (see section 3.2.1.2 3150 or 3.2.2), the GLA verifies the outer signature and/or 3151 decrypt the outer layer prior to verifying the signature on 3152 the inner most SignedData. 3154 2.b.1 - If the signatures cannot be verified, the GLA returns a 3155 cMCStatusInfoEx response indicating cMCStatus.failed and 3156 otherInfo.failInfo.badMessageCheck. 3158 2.b.2 - Else if the signatures verify, the GLA returns a 3159 glaQueryResponse (2 in Figure 11) with the correct 3160 response if the glaRequestType is supported or return a 3161 cMCStatusInfoEx response indicating cMCStatus.noSupport if 3162 the glaRequestType is not supported. 3164 2.b.2.a - The GLA applies confidentiality to the response by 3165 encapsulating the SignedData.PKIResponse in an 3166 EnvelopedData if the request was encapsulated in an 3167 EnvelopedData (see section 3.2.1.2). 3169 2.b.2.b - The GLA can also optionally apply another SignedData 3170 over the EnvelopedData (see section 3.2.1.2). 3172 3 - Upon receipt of the glaQueryResponse, the GLO, GL member, or 3173 prospective GL member verifies the GLA signature(s). If an 3174 additional SignedData and/or EnvelopedData encapsulates the 3175 response (see section 3.2.1.2 or 3.2.2), the GLO, GL member, 3176 or prospective GL member verifies the outer signature and/or 3178 Turner 60 3179 And Distribution 3181 decrypt the outer layer prior to verifying the signature on 3182 the inner most SignedData. 3184 3.a - If the signatures do not verify, the GLO, GL member, or 3185 prospective GL member returns a cMCStatusInfoEx response 3186 indicating cMCStatus.failed and 3187 otherInfo.failInfo.badMessageCheck. 3189 3.b - Else if the signatures verify, then the GLO, GL member, or 3190 prospective GL member checks that one of the names in the 3191 certificate used to sign the response matches the name of 3192 the GL. 3194 3.b.1 � If the name of the GL does not match the name present in 3195 the certificate used to sign the message, the GLO ought 3196 not believe the response. 3198 3.b.2 - Else if the name of the GL matches the name present in the 3199 certificate and the response was glaQueryResponse, then 3200 the GLO, GL member, or prospective GL member may use the 3201 information contained therein. 3203 4.10 Update Member Certificate 3205 When the GLO generates a glAddMember request, when the GLA generates 3206 a glKey message, or when the GLA processes a glAddMember there can 3207 be instances when GL member�s certificate has expired or is invalid. 3208 In these instances the GLO or GLA may request that the GL member 3209 provide a new certificate to avoid the GLA from being unable to 3210 generate a glKey message for the GL member. There might also be 3211 times when the GL member knows their certificate is about to expire 3212 or has been revoked and they will not be able to receive GL rekeys. 3214 4.10.1 GLO and GLA Initiated Update Member Certificate 3216 The process for GLO initiated glUpdateCert is as follows: 3218 1 - The GLO or GLA sends a 3219 SignedData.PKIData.controlSequence.glProvideCert request to 3220 the GL member. The GLO or GLA indicates the GL name in glName 3221 and the GL member name in glMemberName. 3223 1.a - The GLO or GLA can optionally apply confidentiality to the 3224 request by encapsulating the SignedData.PKIData in an 3225 EnvelopedData (see section 3.2.1.2). If the GL member�s PKC 3226 has been revoked, the GLO or GLA ought not use it to 3227 generate the EnvelopedData that encapsulates the 3228 glProvideCert request. 3230 1.b - The GLO or GLA can also optionally apply another SignedData 3231 over the EnvelopedData (see section 3.2.1.2). 3233 Turner 61 3234 And Distribution 3236 2 - Upon receipt of the glProvideCert message, the GL member 3237 verifies the GLO or GLA signature(s). If an additional 3238 SignedData and/or EnvelopedData encapsulates the response (see 3239 section 3.2.1.2 or 3.2.2), the GL member verifies the outer 3240 signature and/or decrypt the outer layer prior to verifying 3241 the signature on the inner most SignedData. 3243 2.a - If the signatures cannot be verified, the GL member returns 3244 a cMCStatusInfoEx response indicating cMCStatus.failed and 3245 otherInfo.failInfo.badMessageCheck. 3247 2.b - Else if the signatures verify, the GL member generates a 3248 Signed.PKIResponse.controlSequence.glUpdateCert that 3249 includes the GL name in glName, the member name in 3250 glMember.glMemberName, their encryption certificate in 3251 glMember.certificates.pKC. The GL member can also include 3252 any attribute certificates associated with their encryption 3253 certificate in glMember.certificates.aC, and the 3254 certification path associated with their encryption and 3255 attribute certificates in glMember.certificates.certPath. 3257 2.a - The GL member can optionally apply confidentiality to the 3258 request by encapsulating the SignedData.PKIResponse in an 3259 EnvelopedData (see section 3.2.1.2). If the GL member�s PKC 3260 has been revoked, the GL member ought not use it to generate 3261 the EnvelopedData that encapsulates the glProvideCert 3262 request. 3264 2.b - The GL member can also optionally apply another SignedData 3265 over the EnvelopedData (see section 3.2.1.2). 3267 3 - Upon receipt of the glUpdateCert message, the GLO or GLA 3268 verifies the GL member signature(s). If an additional 3269 SignedData and/or EnvelopedData encapsulates the response (see 3270 section 3.2.1.2 or 3.2.2), the GL member verifies the outer 3271 signature and/or decrypt the outer layer prior to verifying 3272 the signature on the inner most SignedData. 3274 3.a - If the signatures cannot be verified, the GLO or GLA returns 3275 a cMCStatusInfoEx response indicating cMCStatus.failed and 3276 otherInfo.failInfo.badMessageCheck. 3278 3.b - Else if the signatures verify, the GLO or GLA verifies the 3279 member�s encryption certificate. 3281 3.b.1 - If the member�s encryption certificate cannot be verified, 3282 the GLO returns either another glProvideCert request or a 3283 cMCStatusInfoEx with cMCStatus.failed and the reason why 3284 in cMCStatus.statusString. glProvideCert should be 3285 returned only a certain number of times because if the GL 3287 Turner 62 3288 And Distribution 3290 member does not have a valid certificate they will never 3291 be able to return one. 3293 3.b.2 - Else if the member�s encryption certificate cannot be 3294 verified, the GLA returns another glProvideCert request to 3295 the GL member or a cMCStatusInfoEx with cMCStatus.failed 3296 and the reason why in cMCStatus.statusString to the GLO. 3297 glProvideCert should be returned only a certain number of 3298 times because if the GL member does not have a valid 3299 certificate they will never be able to return one. 3301 3.b.3 - Else if the member�s encryption certificate verifies, the 3302 GLO or GLA will use it in subsequent glAddMember requests 3303 and glKey messages associated with the GL member. 3305 4.10.2 GL Member Initiated Update Member Certificate 3307 The process for an unsolicited GL member glUpdateCert is as follows: 3309 1 - The GL member sends a 3310 Signed.PKIData.controlSequence.glUpdateCert that includes the 3311 GL name in glName, the member name in glMember.glMemberName, 3312 their encryption certificate in glMember.certificates.pKC. The 3313 GL member can also include any attribute certificates 3314 associated with their encryption certificate in 3315 glMember.certificates.aC, and the certification path 3316 associated with their encryption and attribute certificates in 3317 glMember.certificates.certPath. 3319 1.a - The GL member can optionally apply confidentiality to the 3320 request by encapsulating the SignedData.PKIData in an 3321 EnvelopedData (see section 3.2.1.2). If the GL member�s PKC 3322 has been revoked, the GLO or GLA ought not use it to 3323 generate the EnvelopedData that encapsulates the 3324 glProvideCert request. 3326 1.b - The GL member can also optionally apply another SignedData 3327 over the EnvelopedData (see section 3.2.1.2). 3329 2 - Upon receipt of the glUpdateCert message, the GLA verifies the 3330 GL member signature(s). If an additional SignedData and/or 3331 EnvelopedData encapsulates the response (see section 3.2.1.2 3332 or 3.2.2), the GLA verifies the outer signature and/or decrypt 3333 the outer layer prior to verifying the signature on the inner 3334 most SignedData. 3336 2.a - If the signatures cannot be verified, the GLA returns a 3337 cMCStatusInfoEx response indicating cMCStatus.failed and 3338 otherInfo.failInfo.badMessageCheck. 3340 Turner 63 3341 And Distribution 3343 2.b - Else if the signatures verify, the GLA verifies the member�s 3344 encryption certificate. 3346 2.b.1 - If the member�s encryption certificate cannot be verified, 3347 the GLA returns another glProvideCert request to the GL 3348 member or a cMCStatusInfoEx with cMCStatus.failed and the 3349 reason why in cMCStatus.statusString to the GLO. 3350 glProvideCert ought not be returned indefinitely; if the 3351 GL member does not have a valid certificate they will 3352 never be able to return one. 3354 2.b.2 - Else if the member�s encryption certificate verifies, the 3355 GLA will use it in subsequent glAddMember requests and 3356 glKey messages associated with the GL member. The GLA also 3357 forwards the glUpdateCert message to the GLO. 3359 5 Distribution Message 3361 The GLA uses the glKey message to distribute new, shared KEK(s) 3362 after receiving glAddMember, glDeleteMember (for closed and managed 3363 GLs), glRekey, glkCompromise, or glkRefresh requests and returning a 3364 cMCStatusInfoEx response for the respective request. Figure 12 3365 depicts the protocol interactions to send out glKey messages. Unlike 3366 the procedures defined for the administrative messages, the 3367 procedures defined in this section MUST be implemented by GLAs for 3368 origination and by GL members on reception. 3370 1 +----------+ 3371 +-------> | Member 1 | 3372 | +----------+ 3373 +-----+ | 1 +----------+ 3374 | GLA | ----+-------> | ... | 3375 +-----+ | +----------+ 3376 | 1 +----------+ 3377 +-------> | Member n | 3378 +----------+ 3380 Figure 12 - GL Key Distribution 3382 If the GL was setup with GLKeyAttributes.recipientsNotMutuallyAware 3383 set to FALSE, a separate glKey message MUST be sent to each GL 3384 member so as to not divulge information about the other GL members. 3386 Turner 64 3387 And Distribution 3389 When the glKey message is generated as a result of a: 3391 - glAddMember request, 3392 - glkComrpomise indication, 3393 - glkRefresh request, 3394 - glDeleteMember request with the GL�s glAdministration set to 3395 managed or closed, and 3396 - glRekey request with generationCounter set to zero (0). 3398 The GLA MUST use either the kari (see section 12.3.2 of CMS [2]) or 3399 ktri (see section 12.3.1 of CMS [2]) choice in 3400 glKey.glkWrapped.RecipientInfo to ensure only the intended 3401 recipients receive the shared KEK. The GLA MUST support the ktri 3402 choice. 3404 When the glKey message is generated as a result of a glRekey request 3405 with generationCounter greater than zero (0) or when the GLA 3406 controls rekeys, the GLA MAY use the kari, ktri, or kekri (see 3407 section 12.3.3 of CMS [2]) in glKey.glkWrapped.RecipientInfo to 3408 ensure only the intended recipients receive the shared KEK. The GLA 3409 MUST support the RecipientInfo.ktri choice. 3411 5.1 Distribution Process 3413 When a glKey message is generated the process is as follows: 3415 1 - The GLA MUST send a SignedData.PKIData.controlSequence.glKey 3416 to each member by including: glName, glIdentifier, glkWrapped, 3417 glkAlgorithm, glkNotBefore, and glkNotAfter. If the GLA can 3418 not generate a glKey message for the GL member because the GL 3419 member�s PKC has expired or is otherwise invalid, the GLA MAY 3420 send a glUpdateCert to the GL member requesting a new 3421 certificate be provided (see section 4.10). The number of 3422 glKey messages generated for the GL is described in section 3423 3.1.16. 3425 1.a - The GLA MAY optionally apply another confidentiality layer 3426 to the message by encapsulating the SignedData.PKIData in 3427 another EnvelopedData (see section 3.2.1.2). 3429 1.b - The GLA MAY also optionally apply another SignedData over 3430 the EnvelopedData.SignedData.PKIData (see section 3.2.1.2). 3432 2 - Upon receipt of the glKey message, the GL members MUST verify 3433 the signature over the inner most SignedData.PKIData. If an 3434 additional SignedData and/or EnvelopedData encapsulates the 3435 message (see section 3.2.1.2 or 3.2.2), the GL Member MUST 3436 verify the outer signature and/or decrypt the outer layer 3437 prior to verifying the signature on the 3438 SignedData.PKIData.controlSequence.glKey. 3440 Turner 65 3441 And Distribution 3443 2.a - If the signatures cannot be verified, the GL member MUST 3444 return a cMCStatusInfoEx response indicating 3445 cMCStatus.failed and otherInfo.failInfo.badMessageCheck. 3447 2.b - Else if the signatures verify, the GL member process the 3448 RecipientInfos according to CMS [2]. Once unwrapped the GL 3449 member should store the shared KEK in a safe place. When 3450 stored, the glName, glIdentifier, and shared KEK should be 3451 associated. Additionally, the GL member MUST return a 3452 cMCStatusInfoEx indicating cMCStatus.success to tell the GLA 3453 the KEK was received. 3455 6 Algorithms 3457 This section lists the algorithms that MUST be implemented. 3458 Additional algorithms that SHOULD be implemented are also included. 3459 Further algorithms MAY also be implemented. 3461 6.1 KEK Generation Algorithm 3463 Implementations MUST randomly generate content-encryption keys, 3464 message-authentication keys, initialization vectors (IVs), and 3465 padding. Also, the generation of public/private key pairs relies on 3466 a random numbers. The use of inadequate pseudo-random number 3467 generators (PRNGs) to generate cryptographic keys can result in 3468 little or no security. An attacker may find it much easier to 3469 reproduce the PRNG environment that produced the keys, searching the 3470 resulting small set of possibilities, rather than brute force 3471 searching the whole key space. The generation of quality random 3472 numbers is difficult. RFC 1750 [10] offers important guidance in 3473 this area, and Appendix 3 of FIPS Pub 186 [11] provides one quality 3474 PRNG technique. 3476 6.2 Shared KEK Wrap Algorithm 3478 In the mechanisms described in sections 5, the shared KEK being 3479 distributed in glkWrapped MUST be protected by a key of equal or 3480 greater length (i.e., if a RC2 128-bit key is being distributed a 3481 key of 128-bits or greater must be used to protect the key). 3483 The algorithm object identifiers included in glkWrapped are as 3484 specified in AlgSpec [12]. 3486 6.3 Shared KEK Algorithm 3488 The shared KEK distributed and indicated in glkAlgorithm MUST 3489 support the symmetric key-encryption algorithms as specified in 3490 section AlgSpec [12]. 3492 Turner 66 3493 And Distribution 3495 7 Message Transport 3497 SMTP [13] MUST be supported. Other transport mechanisms MAY also be 3498 supported. 3500 8 Security Considerations 3502 As GLOs control setting up and tearing down the GL, rekeying the GL, 3503 and can control member additions and deletions, GLOs play an 3504 important role in the management of the GL, and only �trusted� GLOs 3505 should be used. 3507 If a member is deleted or removed from a closed or a managed GL, the 3508 GL needs to be rekeyed. If the GL is not rekeyed after a member is 3509 removed or deleted, the member still posses the group key and will 3510 be able to continue to decrypt any messages that can be obtained. 3512 Members who store KEKs MUST associate the name of the GLA that 3513 distributed the key so that the members can make sure subsequent 3514 rekeys are originated from the same entity. 3516 When generating keys, care should be taken to ensure that the key 3517 size is not too small and duration too long because people will have 3518 more time to attack the key. Key size should be selected to 3519 adequately protect sensitive business communications. 3521 GLOs and GLAs need to make sure that the generationCounter and 3522 duration are not too large. For example, if the GLO indicates that 3523 the generationCounter is 14 and the duration is one year, then 14 3524 keys are generated each with a validity period of a year. An 3525 attacker will have at least 13 years to attack the final key. 3527 Assume that two or more parties have a shared KEK, and the shared 3528 KEK is used to encrypt a second KEK for confidential distribution to 3529 those parties. The second KEK might be used to encrypt a third KEK; 3530 the third KEK might be used to encrypt a fourth KEK; and so on. If 3531 any of the KEKs in such a chain is compromised, all of the 3532 subsequent KEKs in the chain MUST also be considered compromised. 3534 9 References 3536 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 3537 9, RFC 2026, October 1996. 3539 2 Housley, R., "Cryptographic Message Syntax," draft-ietf-smime- 3540 rfc2630bis-01.txt, April 2001. 3542 Turner 67 3543 And Distribution 3545 3 Myers, M., Liu, X., Schaad, J., Weinsten, J., "Certificate 3546 Management Message over CMS," draft-ietf-pkix-2797-bis-00.txt, 3547 April 2001. 3549 4 Bradner, S., "Key words for use in RFCs to Indicate Requirement 3550 Levels", BCP 14, RFC 2119, March 1997. 3552 5 Housley, R., Ford, W., Polk, W. and D. Solo, "Internet X.509 3553 Public Key Infrastructure: Certificate and CRL Profile", draft- 3554 ietf-pkix-new-part1-06.txt, 8 March 2001. 3556 6 Farrell, S., Housley, R., �An Internet Attribute Certificate 3557 Profile for Authorization�, draft-ietf-pkix-acx.509prof-06.txt, 3558 10 January 2001. 3560 7 Ramsdale, B., "S/MIME Version 3 Message Specification," TBD. 3562 8 Hoffman, P., and C. Bonatti, �Transporting S/MIME Objects in 3563 X.400�, draft-ietf-smime-x400transport-02.txt, May 2000. 3565 9 Hoffman, P., �Extended Security Services for S/MIME�, RFC 2634, 3566 June 1999. 3568 10 Eastlake, D., Crocker, S. and J. Schiller, "Randomness 3569 Recommendations for Security", RFC 1750, December 1994. 3571 11 National Institute of Standards and Technology. FIPS Pub 186: 3572 Digital Signature Standard. 19 May 1994. 3574 12 Housley, R., �Cryptographic Message Syntax (CMS) Algorithms�, 3575 draft-ietf-smime-cmsalg-01.txt, July 2001. 3577 13 Postel, j., "Simple Mail Transport Protocol," RFC 821, August 3578 1982. 3580 10 Acknowledgements 3582 Thanks to Russ Housley and Jim Schaad for providing much of the 3583 background and review required to write this document. 3585 Turner 68 3586 And Distribution 3588 11 Author's Addresses 3590 Sean Turner 3591 IECA, Inc. 3592 9010 Edgepark Road 3593 Vienna, VA 22182 3594 Phone: +1.703.628.3180 3595 Email: turners@ieca.com 3597 Turner 69 3598 And Distribution 3600 Annex A: ASN.1 Module 3602 SMIMESymmetricKeyDistribution 3603 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 3604 smime(16) modules(0) symkeydist(12) } 3606 DEFINITIONS IMPLICIT TAGS ::= 3607 BEGIN 3609 -- EXPORTS All -- 3610 -- The types and values defined in this module are exported for use 3611 -- in the other ASN.1 modules. Other applications may use them for 3612 -- their own purposes. 3614 IMPORTS 3616 -- PKIX Part 1 - Implicit 3617 GeneralName 3618 FROM PKIX1Implicit88 {iso(1) identified-organization(3) dod(6) 3619 internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) 3620 id-pkix1-implicit(19)} 3622 -- PKIX Part 1 - Explicit 3623 AlgorithmIdentifier, Certificate 3624 FROM PKIX1Explicit88 { iso(1) identified-organization(3) dod(6) 3625 internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) 3626 id-pkix1-explicit(18) } 3628 -- Cryptographic Message Syntax 3629 RecipientInfos, id-alg-CMS3DESwrap, KEKIdentifier, 3630 CertificateSet 3631 FROM CryptographicMessageSyntax {iso(1) member-body(2) us(840) 3632 rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) modules(0) 3633 cms-2001(14)} 3635 -- Attribute Certificate Profile 3636 AttributeCertificate FROM 3637 PKIXAttributeCertificate { iso(1) identified-organization(3) 3638 dod(6) internet(1) security(5) mechanisms(5) pkix(7) 3639 id-mod(0) id-mod-attribute-cert(12)}; 3641 -- This defines the GL symmetric key distribution object identifier 3642 -- arc. 3644 id-skd OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) 3645 rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) skd(8) } 3647 -- This defines the GL Use KEK control attribute 3649 id-skd-glUseKEK OBJECT IDENTIFIER ::= { id-skd 1} 3651 Turner 70 3652 And Distribution 3654 GLUseKEK ::= SEQUENCE { 3655 glInfo GLInfo, 3656 glOwnerInfo SEQUENCE SIZE (1..MAX) OF GLOwnerInfo, 3657 glAdministration GLAdministration DEFAULT 1, 3658 glKeyAttributes GLKeyAttributes OPTIONAL } 3660 GLInfo ::= SEQUENCE { 3661 glName GeneralName, 3662 glAddress GeneralName } 3664 GLOwnerInfo ::= SEQUENCE { 3665 glOwnerName GeneralName, 3666 glOwnerAddress GeneralName, 3667 certificates Certificates OPTIONAL } 3669 GLAdministration ::= INTEGER { 3670 unmanaged (0), 3671 managed (1), 3672 closed (2) } 3674 GLKeyAttributes ::= SEQUENCE { 3675 rekeyControlledByGLO [0] BOOLEAN DEFAULT FALSE, 3676 recipientsNotMutuallyAware [1] BOOLEAN DEFAULT TRUE, 3677 duration [2] INTEGER DEFAULT 0, 3678 generationCounter [3] INTEGER DEFAULT 2, 3679 requestedAlgorithm [4] AlgorithmIdentifier 3680 DEFAULT id-alg-CMS3DESwrap } 3682 -- This defines the Delete GL control attribute. 3683 -- It has the simple type GeneralName. 3685 id-skd-glDelete OBJECT IDENTIFIER ::= { id-skd 2} 3687 DeleteGL ::= GeneralName 3689 -- This defines the Add GL Member control attribute 3691 id-skd-glAddMember OBJECT IDENTIFIER ::= { id-skd 3} 3693 GLAddMember ::= SEQUENCE { 3694 glName GeneralName, 3695 glMember GLMember } 3697 GLMember ::= SEQUENCE { 3698 glMemberName GeneralName, 3699 glMemberAddress GeneralName OPTIONAL, 3700 certificates Certificates OPTIONAL } 3702 Turner 71 3703 And Distribution 3705 Certificates ::= SEQUENCE { 3706 pKC [0] Certificate OPTIONAL, 3707 -- See PKIX [5] 3708 aC [1] SEQUENCE SIZE (1.. MAX) OF 3709 AttributeCertificate OPTIONAL, 3710 -- See ACPROF [6] 3711 certPath [2] CertificateSet OPTIONAL } 3712 -- From CMS [2] 3714 -- This defines the Delete GL Member control attribute 3716 id-skd-glDeleteMember OBJECT IDENTIFIER ::= { id-skd 4} 3718 GLDeleteMember ::= SEQUENCE { 3719 glName GeneralName, 3720 glMemberToDelete GeneralName } 3722 -- This defines the Delete GL Member control attribute 3724 id-skd-glRekey OBJECT IDENTIFIER ::= { id-skd 5} 3726 GLRekey ::= SEQUENCE { 3727 glName GeneralName, 3728 glAdministration GLAdministration OPTIONAL, 3729 glNewKeyAttributes GLNewKeyAttributes OPTIONAL, 3730 glRekeyAllGLKeys BOOLEAN OPTIONAL } 3732 GLNewKeyAttributes ::= SEQUENCE { 3733 rekeyControlledByGLO [0] BOOLEAN OPTIONAL, 3734 recipientsNotMutuallyAware [1] BOOLEAN OPTIONAL, 3735 duration [2] INTEGER OPTIONAL, 3736 generationCounter [3] INTEGER OPTIONAL, 3737 requestedAlgorithm [4] AlgorithmIdentifier OPTIONAL } 3739 -- This defines the Add and Delete GL Owner control attributes 3741 id-skd-glAddOwner OBJECT IDENTIFIER ::= { id-skd 6} 3742 id-skd-glRemoveOwner OBJECT IDENTIFIER ::= { id-skd 7} 3744 GLOwnerAdministration ::= SEQUENCE { 3745 glName GeneralName, 3746 glOwnerInfo GLOwnerInfo } 3748 -- This defines the GL Key Compromise control attribute. 3749 -- It has the simple type GeneralName. 3751 id-skd-glKeyCompromise OBJECT IDENTIFIER ::= { id-skd 8} 3753 GLKCompromise ::= GeneralName 3755 Turner 72 3756 And Distribution 3758 -- This defines the GL Key Refresh control attribute. 3760 id-skd-glkRefresh OBJECT IDENTIFIER ::= { id-skd 9} 3762 GLKRefresh ::= SEQUENCE { 3763 glName GeneralName, 3764 dates SEQUENCE SIZE (1..MAX) OF Date } 3766 Date ::= SEQUENCE { 3767 start GeneralizedTime, 3768 end GeneralizedTime OPTIONAL } 3770 -- This defines the GLA Query Request control attribute. 3772 id-skd-glaQueryRequest OBJECT IDENTIFIER ::= { id-skd 11} 3774 GLAQueryRequest ::= SEQUENCE { 3775 glaRequestType OBJECT IDENTIFIER, 3776 glaRequestValue ANY DEFINED BY glaRequestType } 3778 -- This defines the GLA Query Response control attribute. 3780 id-skd-glaQueryResponse OBJECT IDENTIFIER ::= { id-skd 12} 3782 GLAQueryResponse ::= SEQUENCE { 3783 glaResponseType OBJECT IDENTIFIER, 3784 glaResponseValue ANY DEFINED BY glaResponseType } 3786 -- This defines the GLA Request/Response (glaRR) arc for 3787 -- glaRequestType/glaResponseType. 3789 id-cmc-glaRR OBJECT IDENTIFIER ::= { iso(1) identified- 3790 organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) 3791 cmc(7) glaRR(99) } 3793 -- This defines the Algorithm Request 3795 id-cmc-gla-skdAlgRequest OBJECT IDENTIFIER ::= { id-cmc-glaRR 1 } 3797 SKDAlgRequest ::= NULL 3799 -- This defines the Algorithm Response 3801 id-cmc-gla-skdAlgResponse OBJECT IDENTIFIER ::= { id-cmc-glaRR 2 } 3803 -- Note that the response for algorithmSupported request is the 3804 -- smimeCapabilities attribute as defined in MsgSpec [7]. 3806 Turner 73 3807 And Distribution 3809 -- This defines the control attribute to request an updated 3810 -- certificate to the GLA. 3812 id-skd-glProvideCert OBJECT IDENTIFIER ::= { id-skd 13} 3814 GLManageCert ::= SEQUENCE { 3815 glName GeneralName, 3816 glMember GLMember } 3818 -- This defines the control attribute to return an updated 3819 -- certificate to the GLA. It has the type GLManageCert. 3821 id-skd-glManageCert OBJECT IDENTIFIER ::= { id-skd 14} 3823 -- This defines the control attribute to distribute the GL shared 3824 -- KEK. 3826 id-skd-glKey OBJECT IDENTIFIER ::= { id-skd 15} 3828 GLKey ::= SEQUENCE { 3829 glName GeneralName, 3830 glIdentifier KEKIdentifier, -- See CMS [2] 3831 glkWrapped RecipientInfos, -- See CMS [2] 3832 glkAlgorithm AlgorithmIdentifier, 3833 glkNotBefore GeneralizedTime, 3834 glkNotAfter GeneralizedTime } 3836 Turner 74 3837 And Distribution 3839 -- This defines the CMC error types 3841 id-cet-skdFailInfo OBJECT IDENTIFIER ::= { iso(1) 3842 identified-organization(3) dod(6) internet(1) security(5) 3843 mechanisms(5) pkix(7) cet(15) skdFailInfo(1) } 3845 SKDFailInfo ::= INTEGER { 3846 unspecified (0), 3847 closedGL (1), 3848 unsupportedDuration (2), 3849 noGLACertificate (3), 3850 invalidCert (4), 3851 unsupportedAlgorithm (5), 3852 noGLONameMatch (6), 3853 invalidGLName (7), 3854 nameAlreadyInUse (8), 3855 noSpam (9), 3856 deniedAccess (10), 3857 alreadyAMember (11), 3858 notAMember (12), 3859 alreadyAnOwner (13), 3860 notAnOwner (14) } 3862 END -- SMIMESymmetricKeyDistribution 3864 Expires 20 December 2001 3866 Turner 75