idnits 2.17.1 draft-ietf-smime-symkeydist-05.txt: -(885): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(915): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1479): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1699): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1993): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(2024): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(2142): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(2368): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(2399): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(2633): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(2909): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(2913): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(3087): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(3159): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(3217): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(3220): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(3372): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(3431): 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 358 has weird spacing: '...esponse id-...' == Line 2707 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 (July 2001) is 8321 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 3592 looks like a reference -- Missing reference section? '2' on line 3685 looks like a reference -- Missing reference section? '3' on line 3594 looks like a reference -- Missing reference section? '4' on line 3595 looks like a reference -- Missing reference section? '0' on line 3591 looks like a reference -- Missing reference section? '5' on line 3565 looks like a reference -- Missing reference section? '6' on line 3568 looks like a reference -- Missing reference section? '7' on line 3660 looks like a reference -- Missing reference section? '8' on line 1054 looks like a reference -- Missing reference section? '9' on line 1093 looks like a reference -- Missing reference section? '10' on line 3342 looks like a reference -- Missing reference section? '11' on line 3343 looks like a reference -- Missing reference section? '12' on line 3360 looks like a reference -- Missing reference section? '13' on line 3365 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-05.txt July 2001 4 Expires: December 20, 2001 6 S/MIME Symmetric Key Distribution 8 Status of this Memo 10 This document is an Internet-Draft and is in full conformance with 11 all provisions of Section 10 of RFC2026 [1]. 13 This document is an Internet-Draft. Internet-Drafts are working 14 documents of the Internet Engineering Task Force (IETF), its areas, 15 and its working groups. Note that other groups may also distribute 16 working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six 19 months and may be updated, replaced, or obsoleted by other documents 20 at any time. It is inappropriate to use Internet-Drafts as reference 21 material or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 This draft is being discussed on the 'ietf-smime' mailing list. To 30 subscribe, send a message to ietf-smime-request@imc.org with the 31 single word subscribe in the body of the message. There is a Web 32 site for the mailing list at . 34 Abstract 36 This document describes a mechanism to manage (i.e., setup, 37 distribute, and rekey) keys used with symmetric cryptographic 38 algorithms. Also defined herein is a mechanism to organize users 39 into groups to support distribution of encrypted content using 40 symmetric cryptographic algorithms. The mechanism uses the 41 Cryptographic Message Syntax (CMS) protocol [2] and Certificate 42 Management Message over CMS (CMC) protocol [3] to manage the 43 symmetric keys. Any member of the group can then later use this 44 distributed shared key to decrypt other CMS encrypted objects with 45 the symmetric key. This mechanism has been developed to support 46 S/MIME Mail List Agents (MLAs). 48 Turner 1 49 Conventions used in this document 51 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 52 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 53 document are to be interpreted as described in RFC-2119 [4]. 55 1. INTRODUCTION....................................................3 56 1.1 APPLICABILITY TO E-MAIL........................................4 57 1.2 APPLICABILITY TO REPOSITORIES..................................4 58 1.3 USING THE GROUP KEY............................................4 59 2. ARCHITECTURE....................................................5 60 3. PROTOCOL INTERACTIONS...........................................6 61 3.1 CONTROL ATTRIBUTES.............................................7 62 3.1.1 GL USE KEK...................................................9 63 3.1.2 DELETE GL...................................................12 64 3.1.3 ADD GL MEMBER...............................................12 65 3.1.4 DELETE GL MEMBER............................................14 66 3.1.5 REKEY GL....................................................14 67 3.1.6 ADD GL OWNER................................................15 68 3.1.7 REMOVE GL OWNER.............................................15 69 3.1.8 GL KEY COMPROMISE...........................................16 70 3.1.9 GL KEY REFRESH..............................................16 71 3.1.10 GLA QUERY REQUEST AND RESPONSE.............................17 72 3.1.10.1 GLA QUERY REQUEST........................................17 73 3.1.10.2 GLA QUERY RESPONSE.......................................17 74 3.1.10.3 REQUEST AND RESPONSE TYPES...............................17 75 3.1.12 PROVIDE CERT...............................................18 76 3.1.13 UPDATE CERT................................................18 77 3.1.14 GL KEY.....................................................19 78 3.2 USE OF CMC, CMS, AND PKIX.....................................21 79 3.2.1 PROTECTION LAYERS...........................................21 80 3.2.1.1 MINIMUM PROTECTION........................................22 81 3.2.1.2 ADDITIONAL PROTECTION.....................................22 82 3.2.2 COMBINING REQUESTS AND RESPONSES............................23 83 3.2.3 GLA GENERATED MESSAGES......................................24 84 3.2.4 CMC CONTROL ATTRIBUTES......................................25 85 3.2.4.1 USING CMCSTATUSINFOEX.....................................25 86 3.2.4.2 USING TRANSACTIONID.......................................28 87 3.2.4.3 USING NONCES..............................................28 88 3.2.4.4 CMC ATTRIBUTE SUPPORT REQUIREMENTS........................28 89 3.2.5 RESUBMITTED GL MEMBER MESSAGES..............................29 90 3.2.6 PKIX CERTIFICATE AND CRL PROFILE............................29 91 4 ADMINISTRATIVE MESSAGES.........................................29 92 4.1 ASSIGN KEK TO GL..............................................29 93 4.2 DELETE GL FROM GLA............................................32 94 4.3 ADD MEMBERS TO GL.............................................34 95 4.3.1 GLO INITIATED ADDITIONS.....................................35 96 4.3.2 PROSPECTIVE MEMBER INITIATED ADDITIONS......................41 97 4.4 DELETE MEMBERS FROM GL........................................43 98 4.4.1 GLO INITIATED DELETIONS.....................................44 99 4.4.2 MEMBER INITIATED DELETIONS..................................48 100 4.5 REQUEST REKEY OF GL...........................................49 102 Turner 2 103 4.5.1 GLO INITIATED REKEY REQUESTS................................50 104 4.5.2 GLA INITIATED REKEY REQUESTS................................53 105 4.6 CHANGE GLO....................................................53 106 4.7 INDICATE KEK COMPROMISE.......................................55 107 4.7.1 GL MEMBER INITIATED KEK COMPROMISE MESSAGE..................56 108 4.7.2 GLO INITIATED KEK COMPROMISE MESSAGE........................57 109 4.8 REQUEST KEK REFRESH...........................................58 110 4.9 GLA QUERY REQUEST AND RESPONSE................................59 111 4.10 UPDATE MEMBER CERTIFICATE....................................61 112 4.10.1 GLO AND GLA INITIATED UPDATE MEMBER CERTIFICATE............61 113 4.10.2 GL MEMBER INITIATED UPDATE MEMBER CERTIFICATE..............63 114 5 DISTRIBUTION MESSAGE............................................64 115 5.1 DISTRIBUTION PROCESS..........................................65 116 6 ALGORITHMS......................................................66 117 6.1 KEK GENERATION ALGORITHM......................................66 118 6.2 SHARED KEK WRAP ALGORITHM.....................................66 119 6.3 SHARED KEK ALGORITHM..........................................66 120 7 MESSAGE TRANSPORT...............................................67 121 8 SECURITY CONSIDERATIONS.........................................67 122 9 REFERENCES......................................................67 123 10 ACKNOWLEDGEMENTS...............................................68 124 11 AUTHOR'S ADDRESSES.............................................69 125 ANNEX A: ASN.1 MODULE.............................................70 127 1. Introduction 129 With the ever-expanding use of secure electronic communications 130 (e.g., S/MIME [2]), users require a mechanism to distribute 131 encrypted data to multiple recipients (i.e., a group of users). 132 There are essentially two ways to encrypt the data for recipients: 133 using asymmetric algorithms with public key certificates (PKCs) or 134 symmetric algorithms with symmetric keys. 136 With asymmetric algorithms, the originator forms an originator- 137 determined content-encryption key (CEK) and encrypts the content, 138 using a symmetric algorithm. Then, using an asymmetric algorithm and 139 the recipient's PKCs, the originator generates per-recipient 140 information that either (a) encrypts the CEK for a particular 141 recipient (ktri ReipientInfo CHOICE), or (b) transfers sufficient 142 parameters to enable a particular recipient to independently 143 generate the same KEK (kari RecipientInfo CHOICE). If the group is 144 large, processing of the per-recipient information may take quite 145 some time, not to mention the time required to collect and validate 146 the PKCs for each of the recipients. Each recipient identifies their 147 per-recipient information and uses the private key associated with 148 the public key of their PKC to decrypt the CEK and hence gain access 149 to the encrypted content. 151 With symmetric algorithms, the origination process is slightly 152 different. Instead of using PKCs, the originator uses a previously 153 distributed secret key-encryption key (KEK) to encrypt the CEK 155 Turner 3 156 (kekri RecipientInfo CHOICE). Only one copy of the encrypted CEK is 157 required because all the recipients already have the shared KEK 158 needed to decrypt the CEK and hence gain access to the encrypted 159 content. 161 The security provided by the shared KEK is only as good as the sum 162 of the techniques employed by each member of the group to keep the 163 KEK secret from nonmembers. These techniques are beyond the scope of 164 this document. Only the members of the list and the key manager 165 should have the KEK in order to maintain confidentiality. Access 166 control to the information protected by the KEK is determined by the 167 entity that encrypts the information, as all members of the group 168 have access. If the entity that is performing the encryption wants 169 to ensure some subset of the group does not gain access to the 170 information either a different KEK should be used (shared only with 171 this smaller group) or asymmetric algorithms should be used. 173 1.1 Applicability to E-mail 175 One primary audience for this distribution mechanism is e-mail. 176 Distribution lists, sometimes referred to as mail lists, support the 177 distribution of messages to recipients subscribed to the mail list. 178 There are two models for how the mail list can be used. If the 179 originator is a member of the mail list, the originator sends 180 messages encrypted with the shared KEK to the mail list (e.g., 181 listserv or majordomo) and the message is distributed to the mail 182 list members. If the originator is not a member of the mail list 183 (does not have the shared KEK), the originator sends the message 184 (encrypted for the MLA) to the mail list agent (MLA), and then the 185 MLA uses the shared KEK to encrypt the message for the members. In 186 either case the recipients of the mail list use the previously 187 distributed-shared KEK to decrypt the message. 189 1.2 Applicability to Repositories 191 Objects can also be distributed via a repository (e.g., Light Weight 192 Directory Protocol (LDAP) servers, X.500 Directory System Agents 193 (DSAs), Web-based servers). If an object is stored in a repository 194 encrypted with a symmetric key algorithm, any one with the shared 195 KEK and access to that object can then decrypt that object. The 196 encrypted object and the encrypted, shared KEK can be stored in the 197 repository. 199 1.3 Using the Group Key 201 This document was written with three specific scenarios in mind: two 202 supporting mail list agents and one for general message 203 distribution. Scenario 1 depicts the originator sending a public key 204 (PK) protected message to a MLA who then uses the shared KEK (S) to 206 Turner 4 207 redistribute the message to the members of the list. Scenario 2 208 depicts the originator sending a shared KEK protected message to a 209 MLA who then redistributes the message to the members of the list 210 (the MLA only adds additional recipients). Scenario 3 shows an 211 originator sending a shared KEK protected message to a group of 212 recipients without an intermediate MLA. 214 +----> +----> +----> 215 PK +-----+ S | S +-----+ S | S | 216 ----> | MLA | --+----> ----> | MLA | --+----> ----+----> 217 +-----+ | +-----+ | | 218 +----> +----> +----> 220 Scenario 1 Scenario 2 Scenario 3 222 2. Architecture 224 Figure 1 depicts the architecture to support symmetric key 225 distribution. The Group List Agent (GLA) supports two distinct 226 functions with two different agents: 228 - The Key Management Agent (KMA) which is responsible for 229 generating the shared KEKs. 231 - The Group Management Agent (GMA) which is responsible for 232 managing the Group List (GL) to which the shared KEKs are 233 distributed. 235 +----------------------------------------------+ 236 | Group List Agent | +-------+ 237 | +------------+ + -----------------------+ | | Group | 238 | | Key | | Group Management Agent | |<-->| List | 239 | | Management |<-->| +------------+ | | | Owner | 240 | | Agent | | | Group List | | | +-------+ 241 | +------------+ | +------------+ | | 242 | | / | \ | | 243 | +------------------------+ | 244 +----------------------------------------------+ 245 / | \ 246 +----------+ +---------+ +----------+ 247 | Member 1 | | ... | | Member n | 248 +----------+ +---------+ +----------+ 250 Figure 1 - Key Distribution Architecture 252 A GLA may support multiple KMAs. A GLA in general supports only one 253 GMA, but the GMA may support multiple GLs. Multiple KMAs may support 254 a GMA in the same fashion as GLAs support multiple KMAs. Assigning a 255 particular KMA to a GL is beyond the scope of this document. 257 Turner 5 258 Modeling real world GL implementations shows that there are very 259 restrictive GLs, where a human determines GL membership, and very 260 open GLs, where there are no restrictions on GL membership. To 261 support this spectrum, the mechanism described herein supports both 262 managed (i.e., where access control is applied) and unmanaged (i.e., 263 where no access control is applied) GLs. The access control 264 mechanism for managed lists is beyond the scope of this document. 265 Note: If the distribution for the list is performed by an entity 266 other than the originator (e.g., an MLA distributing a mail 267 message), this entity can also enforce access control rules. 269 In either case, the GL must initially be constructed by an entity 270 hereafter called the Group List Owner (GLO). There may be multiple 271 entities who 'own' the GL and who are allowed to make changes to the 272 GL�s properties or membership. The GLO determines if the GL will be 273 managed or unmanaged and is the only entity that may delete the GL. 274 GLO(s) may or may not be GL members. GLO(s) may also setup lists 275 that are closed, where the GLO solely determines GL membership. 277 Though Figure 1 depicts the GLA as encompassing both the KMA and GMA 278 functions, the two functions could be supported by the same entity 279 or they could be supported by two different entities. If two 280 entities are used, they could be located on one or two platforms. 281 There is however a close relationship between the KMA and GMA 282 functions. If the GMA stores all information pertaining to the GLs 283 and the KMA merely generates keys, a corrupted GMA could cause 284 havoc. To protect against a corrupted GMA, the KMA would be forced 285 to double check the requests it receives to ensure the GMA did not 286 tamper with them. These duplicative checks blur the functionality of 287 the two components together. For this reason, the interactions 288 between the KMA and GMA are beyond the scope of this document. 289 Proprietary mechanisms may be used to separate the functions by 290 strengthening the trust relationship between the two entities. 291 Henceforth, the distinction between the two agents is not discussed 292 further; the term GLA will be used to address both functions. It 293 should be noted that corrupt GLA can always cause havoc. 295 3. Protocol Interactions 297 There are existing mechanisms (e.g., listserv and majordomo) to 298 manage GLs; however, this document does not address securing these 299 mechanisms, as they are not standardized. Instead, it defines 300 protocol interactions, as depicted in Figure 2, used by the GL 301 members, GLA, and GLO(s) to manage GLs and distribute shared KEKs. 302 The interactions have been divided into administration messages and 303 distribution messages. The administrative messages are the request 304 and response messages needed to setup the GL, delete the GL, add 305 members to the GL, delete members of the GL, request a group rekey, 306 add owners to the GL, remove owners of the GL, indicate a group key 307 compromise, refresh a group key, interrogate the GLA, and update 308 member�s and owner�s public key certificates. The distribution 310 Turner 6 311 messages are the messages that distribute the shared KEKs. The 312 following sections describe the ASN.1 for both the administration 313 and distribution messages. Section 4 describes how to use the 314 administration messages, and section 5 describes how to use the 315 distribution messages. 317 +-----+ +----------+ 318 | GLO | <---+ +----> | Member 1 | 319 +-----+ | | +----------+ 320 | | 321 +-----+ <------+ | +----------+ 322 | GLA | <-------------+----> | ... | 323 +-----+ | +----------+ 324 | 325 | +----------+ 326 +----> | Member n | 327 +----------+ 329 Figure 2 - Protocol Interactions 331 3.1 Control Attributes 333 To avoid creating an entirely new protocol, the Certificate 334 Management Messages over CMS (CMC) protocol was chosen as the 335 foundation of this protocol. The main reason for the choice was the 336 layering aspect provided by CMC where one or more control attributes 337 are included in message, protected with CMS, to request or respond 338 to a desired action. The CMC PKIData structure is used for requests, 339 and the CMC ResponseBody structure is used for responses. The 340 content-types PKIData and PKIResponse are then encapsulated in CMS's 341 SignedData or EnvelopedData, or a combination of the two (see 342 section 3.2). The following are the control attributes defined in 343 this document: 345 Control 346 Attribute OID Syntax 347 ------------------- ----------- ----------------- 348 glUseKEK id-skd 1 GLUseKEK 349 glDelete id-skd 2 GeneralName 350 glAddMember id-skd 3 GLAddMember 351 glDeleteMember id-skd 4 GLDeleteMember 352 glRekey id-skd 5 GLRekey 353 glAddOwner id-skd 6 GLOwnerAdministration 354 glRemoveOwner id-skd 7 GLOwnerAdministration 355 glkCompromise id-skd 8 GeneralName 356 glkRefresh id-skd 9 GLKRefresh 357 glaQueryRequest id-skd 11 GLAQueryRequest 358 glaQueryResponse id-skd 12 GLAQueryResponse 359 glProvideCert id-skd 13 GLManageCert 360 glUpdateCert id-skd 14 GLManageCert 361 glKey id-skd 15 GLKey 363 Turner 7 364 In the following conformance tables, the column headings have the 365 following meanings: O for originate, R for receive, and F for 366 forward. There are three types of implementations: GLOs, GLAs, and 367 GL members. The GLO is an optional component hence all GLO O and GLO 368 R messages are optional, and GLA F messages are optional. The first 369 table includes messages that conformant implementions MUST support. 370 The second table includes messages that MAY be implemented. The 371 second table should be interpreted as follows: if the control 372 attribute is implemented by a component then it must be implemented 373 as indicated. For example, if a GLA is implemented that supports the 374 glAddMember control attribute, then it MUST support receiving the 375 glAddMember message. Note that �-� means not applicable. 377 Required 378 Implementation Requirement | Control 379 GLO | GLA | GL Member | Attribute 380 O R | O R F | O R | 381 ------- | ----------------- | --------- | ---------- 382 MAY - | MUST - MAY | - MUST | glProvideCert 383 MAY MAY | - MUST MAY | MUST - | glUpdateCert 384 - - | MUST - - | - MUST | glKey 386 Optional 387 Implementation Requirement | Control 388 GLO | GLA | GL Member | Attribute 389 O R | O R F | O R | 390 ------- | ----------------- | --------- | ---------- 391 MAY - | - MAY - | - - | glUseKEK 392 MAY - | - MAY - | - - | glDelete 393 MAY MAY | - MUST MAY | MUST - | glAddMember 394 MAY MAY | - MUST MAY | MUST - | glDeleteMember 395 MAY - | - MAY - | - - | glRekey 396 MAY - | - MAY - | - - | glAddOwner 397 MAY - | - MAY - | - - | glRemoveOwner 398 MAY MAY | - MUST MAY | MUST - | glkCompromise 399 MAY - | - MUST - | MUST - | glkRefresh 400 MAY - | - SHOULD - | MAY - | glaQueryRequest 401 - MAY | SHOULD - - | - MAY | glaQueryResponse 403 glaQueryResponse and gloResponse are carried in the CMC PKIResponse 404 content-type, all other control attributes are carried in the CMC 405 PKIData content-type. The exception is glUpdateCert which can be 406 carried in either PKIData or PKIResponse. 408 Success and failure messages use CMC (see section 3.2.4). 410 Turner 8 411 3.1.1 GL USE KEK 413 The GLO uses glUseKEK to request that a shared KEK be assigned to a 414 GL. glUseKEK messages MUST be signed by the GLO. The glUseKEK 415 control attribute has the syntax GLUseKEK: 417 GLUseKEK ::= SEQUENCE { 418 glInfo GLInfo, 419 glOwnerInfo SEQUENCE SIZE (1..MAX) OF GLOwnerInfo, 420 glAdministration GLAdministration DEFAULT 1, 421 glKeyAttributes GLKeyAttributes OPTIONAL } 423 GLInfo ::= SEQUENCE { 424 glName GeneralName, 425 glAddress GeneralName } 427 GLOwnerInfo ::= SEQUENCE { 428 glOwnerName GeneralName, 429 glOwnerAddress GeneralName, 430 certificate Certificates OPTIONAL } 432 Certificates ::= SEQUENCE { 433 pKC [0] Certificate OPTIONAL, 434 -- See PKIX [5] 435 aC [1] SEQUENCE SIZE (1.. MAX) OF 436 AttributeCertificate OPTIONAL, 437 -- See ACPROF [6] 438 certPath [2] CertificateSet OPTIONAL } 439 -- From CMS [2] 441 -- CertificateSet and CertificateChoices are included only 442 -- for illustrative purposes as they are imported from CMS [2]. 444 CertificateSet ::= SET SIZE (1..MAX) OF CertificateChoices 446 -- CertificateChoices supports X.509 public key certificates in 447 -- certificates and v2 attribute certificates in v2AttrCert. 449 GLAdministration ::= INTEGER { 450 unmanaged (0), 451 managed (1), 452 closed (2) } 454 GLKeyAttributes ::= SEQUENCE { 455 rekeyControlledByGLO [0] BOOLEAN DEFAULT FALSE, 456 recipientsNotMutuallyAware [1] BOOLEAN DEFAULT TRUE, 457 duration [2] INTEGER DEFAULT 0, 458 generationCounter [3] INTEGER DEFAULT 2, 459 requestedAlgorithm [4] AlgorithmIdentifier 460 DEFAULT id-alg-CMS3DESwrap } 462 Turner 9 463 The fields in GLUseKEK have the following meaning: 465 - glInfo indicates the name of the GL in glName and the address of 466 the GL in glAddress. The glName and glAddress can be the same, 467 but this is not always the case. Both the name and address MUST 468 be unique for a given GLA. 470 - glOwnerInfo indicates: 472 - glOwnerName indicates the name of the owner of the GL. 474 - glOwnerAddress indicates the address of the owner of the GL. 475 One of the names in glOwnerName MUST match one of the names in 476 the certificate (either the subject distinguished name or one 477 of the subject alternative names) used to sign this 478 SignedData.PKIData creating the GL (i.e., the immediate 479 signer). 481 - certificates MAY be included. It contains the following three 482 fields: 484 - certificates.pKC includes the encryption certificate for the 485 GLO. It will be used, at least initially, to encrypt the 486 shared KEK for that member. If the message is generated by a 487 GLO and they are adding another GLO (i.e., the name in one 488 of the certificates used to sign this message does not match 489 the name in glOwnerName), the pKC for the other GLO MUST be 490 included. Otherwise, the pKC MAY be included. 492 - certificates.aC MAY be included to convey any attribute 493 certificate (see AC Profile [6]) associated with the 494 encryption certificate of the GLO included in 495 certificates.pKC. 497 - certificates.certPath MAY also be included to convey 498 certificates that might aid the recipient in constructing 499 valid certification paths for the certificate provided in 500 certificates.pKC and the attribute certificates provided in 501 certificates.aC. Theses certificates are optional because 502 they might already be included elsewhere in the message 503 (e.g., in the outer CMS layer). 505 - glAdministration indicates how the GL ought to be administered. 506 The default is for the list to be managed. Three values are 507 supported for glAdministration: 509 - Unmanaged - When the GLO sets glAdministration to unmanaged, 510 they are allowing prospective members to request addition and 511 deletion from the GL without GLO intervention. 513 - Managed - When the GLO sets glAdministration to managed, they 514 are allowing prospective members to request addition and 516 Turner 10 517 deletion from the GL, but the request is redirected by the GLA 518 to GLO for review. The GLO makes the determination as to 519 whether to honor the request. 521 - Closed - When the GLO sets glAdministration to closed, they 522 are not allowing prospective members to request addition or 523 deletion from the GL. The GLA will only accept glAddMember and 524 glDeleteMember requests from the GLO. 526 - glKeyAttributes indicates the attributes the GLO wants the GLA 527 to assign to the shared KEK. If this field is omitted, GL rekeys 528 will be controlled by the GLA, the recipients are allowed to 529 know about one another, the algorithm will be Triple-DES (see 530 paragrpah 7), the shared KEK will be valid for a calendar month 531 (i.e., first of the month until the last day of the month), and 532 two shared KEKs will be distributed initially. The fields in 533 glKeyAttributes have the following meaning: 535 - rekeyControlledByGLO indicates whether the GL rekey messages 536 will be generated by the GLO or by the GLA. The default is for 537 the GLA to control rekeys. If GL rekey is controlled by the 538 GLA, the GL will continue to be rekeyed until the GLO deletes 539 the GL or changes the GL rekey to be GLO controlled. 541 - recipientsNotMutuallyAware indicates that the GLO wants the 542 GLA to distribute the shared KEK individually for each of the 543 GL members (i.e., a separate glKey message is sent to each 544 recipient). The default is for separate glKey message to not 545 be required. 547 NOTE: This supports lists where one member does not know the 548 identities of the other members. For example, a list is 549 configured granting submit permissions to only one member. All 550 other members are 'listening.' The security policy of the list 551 does not allow the members to know who else is on the list. If 552 a glKey is constructed for all of the GL members, information 553 about each of the members may be derived from the information 554 in RecipientInfos. To make sure the glkey message does not 555 divulge information about the other recipients, a separate 556 glKey message would be sent to each GL member. 558 - duration indicates the length of time (in days) during which 559 the shared KEK is considered valid. The value zero (0) 560 indicates that the shared KEK is valid for a calendar month in 561 the UTC Zulu time zone. For example if the duration is zero 562 (0), if the GL shared KEK is requested on July 24, the first 563 key will be valid until the end of July and the next key will 564 be valid for the entire month of August. If the value is not 565 zero (0), the shared KEK will be valid for the number of days 566 indicated by the value. For example, if the value of duration 567 is seven (7) and the shared KEK is requested on Monday but not 568 generated until Tuesday (2359); the shared KEKs will be valid 570 Turner 11 571 from Tuesday (2359) to Tuesday (2359). The exact time of the 572 day is determined when the key is generated. 574 - generationCounter indicates the number of keys the GLO wants 575 the GLA to distribute. To ensure uninterrupted function of the 576 GL two (2) shared KEKs at a minimum MUST be initially 577 distributed. The second shared KEK is distributed with the 578 first shared KEK, so that when the first shared KEK is no 579 longer valid the second key can be used. If the GLA controls 580 rekey then it also indicates the number of shared KEKs the GLO 581 wants outstanding at any one time. See sections 4.5 and 5 for 582 more on rekey. 584 - requestedAlgorithm indicates the algorithm and any parameters 585 the GLO wants the GLA to use with the shared KEK. The 586 parameters are conveyed via the SMIMECapabilities attribute 587 (see MSG [7]). See section 6 for more on algorithms. 589 3.1.2 Delete GL 591 GLOs use glDelete to request that a GL be deleted from the GLA. The 592 glDelete control attribute has the syntax GeneralName. The glDelete 593 message MUST be signed by the GLO. The name of the GL to be deleted 594 is included in GeneralName: 596 DeleteGL ::= GeneralName 598 3.1.3 Add GL Member 600 GLOs use the glAddMember to request addition of new members, and 601 prospective GL members use the glAddMember to request their own 602 addition to the GL. The glAddMember message MUST be signed by either 603 the GLO or the prospective GL member. The glAddMember control 604 attribute has the syntax GLAddMember: 606 GLAddMember ::= SEQUENCE { 607 glName GeneralName, 608 glMember GLMember } 610 GLMember ::= SEQUENCE { 611 glMemberName GeneralName, 612 glMemberAddress GeneralName OPTIONAL, 613 certificates Certificates OPTIONAL } 615 Turner 12 616 Certificates ::= SEQUENCE { 617 pKC [0] Certificate OPTIONAL, 618 -- See PKIX [5] 619 aC [1] SEQUENCE SIZE (1.. MAX) OF 620 AttributeCertificate OPTIONAL, 621 -- See ACPROF [6] 622 certPath [2] CertificateSet OPTIONAL } 623 -- From CMS [2] 625 -- CertificateSet and CertificateChoices are included only 626 -- for illustrative purposes as they are imported from CMS [2]. 628 CertificateSet ::= SET SIZE (1..MAX) OF CertificateChoices 630 -- CertificateChoices supports X.509 public key certificates in 631 -- certificates and v2 attribute certificates in v2AttrCert. 633 The fields in GLAddMembers have the following meaning: 635 - glName indicates the name of the GL to which the member should 636 be added. 638 - glMember indicates the particulars for the GL member. Both of 639 the following fields must be unique for a given GL: 641 - glMemberName indicates the name of the GL member. 643 - glMemberAddress indicates the GL member�s address. It MUST be 644 included. 646 Note: In some instances the glMemberName and glMemberAddress 647 may be the same, but this is not always the case. 649 - certificates MUST be included. It contains the following three 650 fields: 652 - certificates.pKC includes the member's encryption 653 certificate. It will be used, at least initially, to encrypt 654 the shared KEK for that member. If the message is generated 655 by a prospective GL member, the pKC MUST be included. If the 656 message is generated by a GLO, the pKC SHOULD be included. 658 - certificates.aC MAY be included to convey any attribute 659 certificate (see AC Profile [6]) associated with the 660 member�s encryption certificate. 662 - certificates.certPath MAY also be included to convey 663 certificates that might aid the recipient in constructing 664 valid certification paths for the certificate provided in 665 certificates.pKC and the attribute certificates provided in 666 certificates.aC. These certificates are optional because 668 Turner 13 669 they might already be included elsewhere in the message 670 (e.g., in the outer CMS layer). 672 3.1.4 Delete GL Member 674 GLOs use the glDeleteMember to request deletion of GL members, and 675 GL members use the glDeleteMember to request their own removal from 676 the GL. The glDeleteMember message MUST be signed by either the GLO 677 or the GL member. The glDeleteMember control attribute has the 678 syntax GLDeleteMember: 680 GLDeleteMember ::= SEQUENCE { 681 glName GeneralName, 682 glMemberToDelete GeneralName } 684 The fields in GLDeleteMembers have the following meaning: 686 - glName indicates the name of the GL from which the member should 687 be removed. 689 - glMemberToDelete indicates the name of the member to be deleted. 691 3.1.5 Rekey GL 693 GLOs use the glRekey to request a GL rekey. The glRekey message MUST 694 be signed by the GLO. The glRekey control attribute has the syntax 695 GLRekey: 697 GLRekey ::= SEQUENCE { 698 glName GeneralName, 699 glAdministration GLAdministration OPTIONAL, 700 glNewKeyAttributes GLNewKeyAttributes OPTIONAL, 701 glRekeyAllGLKeys BOOLEAN OPTIONAL } 703 GLNewKeyAttributes ::= SEQUENCE { 704 rekeyControlledByGLO [0] BOOLEAN OPTIONAL, 705 recipientsNotMutuallyAware [1] BOOLEAN OPTIONAL, 706 duration [2] INTEGER OPTIONAL, 707 generationCounter [3] INTEGER OPTIONAL, 708 requestedAlgorithm [4] AlgorithmIdentifier OPTIONAL } 710 The fields in GLRekey have the following meaning: 712 - glName indicates the name of the GL to be rekeyed. 714 - glAdministration indicates if there is any change to how the GL 715 should be administered. See section 3.1.1 for the three options. 717 Turner 14 718 This field is only included if there is a change from the 719 previously registered administered. 721 - glNewKeyAttributes indicates whether the rekey of the GLO is 722 controlled by the GLA or GL, what algorithm and parameters the 723 GLO wishes to use, the duration of the key, and how many 724 outstanding keys will be issued. The field is only included if 725 there is a change from the previously registered 726 glKeyAttributes. 728 - glRekeyAllGLKeys indicates whether the GLO wants all of the 729 outstanding GL�s shared KEKs rekeyed. If it is set to TRUE then 730 all outstanding KEKs MUST be issued. If it is set to FALSE then 731 all outstanding KEKs need not be resissued. 733 3.1.6 Add GL Owner 735 GLOs use the glAddOwner to request that a new GLO be allowed to 736 administer the GL. The glAddOwner message MUST be signed by a 737 registered GLO. The glAddOwner control attribute has the syntax 738 GLOwnerAdministration: 740 GLOwnerAdministration ::= SEQUENCE { 741 glName GeneralName, 742 glOwnerInfo GLOwnerInfo } 744 The fields in GLAddOwners have the following meaning: 746 - glName indicates the name of the GL to which the new GLO should 747 be associated. 749 - glOwnerInfo indicates the name, address, and certificates of the 750 new GLO. As this message includes names of new GLOs, the 751 certificates.pKC MUST be included, and it MUST include the 752 encryption certificate of the new GLO. 754 3.1.7 Remove GL Owner 756 GLOs use the glRemoveOwner to request that a GLO be disassociated 757 with the GL. The glRemoveOwner message MUST be signed by a 758 registered GLO. The glRemoveOwner control attribute has the syntax 759 GLOwnerAdministration: 761 GLOwnerAdministration ::= SEQUENCE { 762 glName GeneralName, 763 glOwnerInfo GLOwnerInfo } 765 Turner 15 766 The fields in GLRemoveOwners have the following meaning: 768 - glName indicates the name of the GL to which the GLO should be 769 disassociated. 771 - glOwnerInfo indicates the name and address of the GLO to be 772 removed. The certificates field SHOULD be omitted, as it will be 773 ignored. 775 3.1.8 GL Key Compromise 777 GL members and GLOs use glkCompromise to indicate that the shared 778 KEK possessed has been compromised. The glKeyCompromise control 779 attribute has the syntax GeneralName. This message is always 780 redirected by the GLA to the GLO for further action. The 781 glkCompromise MAY be included in an EnvelopedData generated with the 782 compromised shared KEK. The name of the GL to which the compromised 783 key is associated with is included in GeneralName: 785 GLKCompromise ::= GeneralName 787 3.1.9 GL Key Refresh 789 GL members use the glkRefresh to request that the shared KEK be 790 redistributed to them. The glkRefresh control attribute has the 791 syntax GLKRefresh. 793 GLKRefresh ::= SEQUENCE { 794 glName GeneralName, 795 dates SEQUENCE SIZE (1..MAX) OF Date } 797 Date ::= SEQUENCE { 798 start GeneralizedTime, 799 end GeneralizedTime OPTIONAL } 801 The fields in GLKRefresh have the following meaning: 803 - glName indicates the name of the GL for which the GL member 804 wants shared KEKs. 806 - dates indicates a date range for keys the GL member wants. The 807 start field indicates the first date the GL member wants and the 808 end field indicates the last date. The end date MAY be omitted 809 to indicate the GL member wants all keys from the specified 810 start date to the current date. Note that a procedural mechanism 811 is needed to restrict users from accessing messages that they 812 are not allowed to access. 814 Turner 16 815 3.1.10 GLA Query Request and Response 817 There are situations where GLOs and GL members may need to determine 818 some information from the GLA about the GL. GLOs and GL members use 819 the glaQueryRequest, defined in section 3.1.10.1, to request 820 information and GLAs use the glaQueryResponse, defined in section 821 3.1.10.2, to return the requested information. Section 3.1.10.3 822 includes one request and response type and value; others may be 823 defined in additional documents. 825 3.1.10.1 GLA Query Request 827 GLOs and GL members use the glaQueryRequest to ascertain information 828 about the GLA. The glaQueryRequest control attribute has the syntax 829 GLAQueryRequest: 831 GLAQueryRequest ::= SEQUENCE { 832 glaRequestType OBJECT IDENTIFIER, 833 glaRequestValue ANY DEFINED BY glaRequestType } 835 3.1.10.2 GLA Query Response 837 GLAs return the glaQueryResponse after receiving a GLAQueryRequest. 838 The glaQueryResponse MUST be signed by a GLA. The glaQueryResponse 839 control attribute has the syntax GLAQueryResponse: 841 GLAQueryResponse ::= SEQUENCE { 842 glaResponseType OBJECT IDENTIFIER, 843 glaResponseValue ANY DEFINED BY glaResponseType } 845 3.1.10.3 Request and Response Types 847 Request and Responses are registered as a pair under the following 848 object identifier arc: 850 id-cmc-glaRR OBJECT IDENTIFIER ::= { id-cmc 99 } 852 This document defines one request/response pair for GL members and 853 GLOs to query the GLA for the list of algorithm it supports. The 854 following object identifier (OID) is included in the glaQueryType 855 field: 857 id-cmc-gla-skdAlgRequest OBJECT IDENTIFIER ::={ id-cmc-glaRR 1 } 859 SKDAlgRequest ::= NULL 861 Turner 17 862 If the GLA supports GLAQueryRequest and GLAQueryResponse messages, 863 the GLA may return the following OID in the glaQueryType field: 865 id-cmc-gla-skdAlgResponse OBJECT IDENTIFIER ::= { id-cmc-glaRR 2 } 867 The glaQueryValue has the form of the smimeCapabilities attributes 868 as defined in MSG [7]. 870 3.1.12 Provide Cert 872 GLAs and GLOs use the glProvideCert to request that a GL member 873 provide an updated or new encryption certificate. The glProvideCert 874 message MUST be signed by either GLA or GLO. If the GL member�s PKC 875 has been revoked, the GLO or GLA MUST NOT use it to generate the 876 EnvelopedData that encapsulates the glProvideCert request. The 877 glProvideCert control attribute has the syntax GLManageCert: 879 GLManageCert ::= SEQUENCE { 880 glName GeneralName, 881 glMember GLMember } 883 The fields in GLManageCert have the following meaning: 885 - glName indicates the name of the GL to which the GL member�s new 886 certificate is to be associated. 888 - glMember indicates particulars for the GL member: 890 - glMemberName indicates the GL member�s name. 892 - glMemberAddress indicates the GL member�s address. It MAY be 893 omitted. 895 - certificates SHOULD be omitted. 897 3.1.13 Update Cert 899 GL members and GLOs use the glUpdateCert to provide a new 900 certificate for the GL. GL members can generate an unsolicited 901 glUpdateCert or generate a response glUpdateCert as a result of 902 receiveing a glProvideCert message. GL members MUST sign the 903 glUpdateCert. If the GL member�s encryption certificate has been 904 revoked, the GL member MUST NOT use it to generate the EnvelopedData 905 that encapsulates the glUpdateCert request or response. The 906 glUpdateCert control attribute has the syntax GLManageCert: 908 GLManageCert ::= SEQUENCE { 909 glName GeneralName, 910 glMember GLMember } 912 Turner 18 913 The fields in GLManageCert have the following meaning: 915 - glName indicates the name of the GL to which the GL member�s new 916 certificate should be associated. 918 - glMember indicates the particulars for the GL member: 920 - glMemberName indicates the GL member�s name 922 - glMemberAddress indicates the GL member�s address. It MAY be 923 omitted. 925 - certificates MAY be omitted if the GLManageCert message is 926 sent to request the GL member�s certificate; otherwise, it 927 MUST be included. It includes the following three fields: 929 - certificates.pKC includes the member's encryption 930 certificate that will be used to encrypt the shared KEK for 931 that member. 933 - certificates.aC MAY be included to convey one or more 934 attribute certificate associated with the member�s 935 encryption certificate. 937 - certificates.certPath MAY also be included to convey 938 certificates that might aid the recipient in constructing 939 valid certification paths for the certificate provided in 940 certificates.pKC and the attribute certificates provided in 941 certificates.aC. These certificates is optional because they 942 might already be included elsewhere in the message (e.g., in 943 the outer CMS layer). 945 3.1.14 GL Key 947 The GLA uses the glKey to distribute the shared KEK. The glKey 948 message MUST be signed by the GLA. The glKey control attribute has 949 the syntax GLKey: 951 GLKey ::= SEQUENCE { 952 glName GeneralName, 953 glIdentifier KEKIdentifier, -- See CMS [2] 954 glkWrapped RecipientInfos, -- See CMS [2] 955 glkAlgorithm AlgorithmIdentifier, 956 glkNotBefore GeneralizedTime, 957 glkNotAfter GeneralizedTime } 959 Turner 19 960 -- KEKIdentifier is included only for illustrative purposes as 961 -- it is imported from CMS [2]. 963 KEKIdentifier ::= SEQUENCE { 964 keyIdentifier OCTET STRING, 965 date GeneralizedTime OPTIONAL, 966 other OtherKeyAttribute OPTIONAL } 968 The fields in GLKey have the following meaning: 970 - glName is the name of the GL. 972 - glIdentifier is the key identifier of the shared KEK. See 973 paragraph 6.2.3 of CMS [2] for a description of the subfields. 975 - glkWrapped is the wrapped shared KEK for the GL for a particular 976 duration. The RecipientInfos MUST be generated as specified in 977 section 6.2 of CMS [2]. The ktri RecipientInfo choice MUST be 978 supported. The key in the EncryptedKey field (i.e., the 979 distributed shared KEK) MUST be generated according to the 980 section concerning random number generation in the security 981 considerations of CMS [2]. 983 - glkAlgorithm identifies the algorithm the shared KEK is used 984 with. Since no encrypted data content is being conveyed at this 985 point, the parameters encoded with the algorithm should be the 986 structure defined for smimeCapabilities rather than encrypted 987 content. 989 - glkNotBefore indicates the date at which the shared KEK is 990 considered valid. GeneralizedTime values MUST be expressed in 991 UTC (Zulu) and MUST include seconds (i.e., times are 992 YYYYMMDDHHMMSSZ), even where the number of seconds is zero. 993 GeneralizedTime values MUST NOT include fractional seconds. 995 - glkNotAfter indicates the date after which the shared KEK is 996 considered invalid. GeneralizedTime values MUST be expressed in 997 UTC (Zulu) and MUST include seconds (i.e., times are 998 YYYYMMDDHHMMSSZ), even where the number of seconds is zero. 999 GeneralizedTime values MUST NOT include fractional seconds. 1001 If the glKey message is in response to a glUseKEK message: 1003 - The GLA MUST generate separate glKey messages for each recipient 1004 if glUseKEK.glKeyAttributes.recipientsNotMutuallyAware is set to 1005 FALSE. For each recipient you want to generate a message that 1006 contains that recipient�s key (i.e., one message with one 1007 attribute). 1009 Turner 20 1010 - The GLA MUST generate the requested number of glKey messages. 1011 The value in glUseKEK.glKeyAttributes.generationCounter 1012 indicates the number of glKey messages requested. 1014 If the glKey message is in response to a glRekey message: 1016 - The GLA MUST generate separate glKey messages for each recipient 1017 if glRekey.glNewKeyAttributes.recipientsNotMutuallyAware is set 1018 to FALSE. 1020 - The GLA MUST generate the requested number of glKey messages. 1021 The value in glUseKEK.glKeyAttributes.generationCounter 1022 indicates the number of glKey messages requested. 1024 - The GLA MUST generate one glKey messagefor each outstanding 1025 shared KEKs for the GL when glRekeyAllGLKeys is set to TRUE. 1027 If the glKey message was not in response to a glRekey or glUseKEK 1028 (e.g., where the GLA controls rekey): 1030 - The GLA MUST generate separate glKey messages for each recipient 1031 when glUseKEK.glNewKeyAttributes.recipientsNotMutuallyAware that 1032 set up the GL was set to FALSE. 1034 - The GLA MAY generate glKey messages prior to the duration on the 1035 last outstanding shared KEK expiring, where the number of glKey 1036 messages generated is generationCounter minus one (1). Other 1037 distribution mechanisms can also be supported to support this 1038 functionality. 1040 3.2 Use of CMC, CMS, and PKIX 1042 The following sections outline the use of CMC, CMS, and the PKIX 1043 certificate and CRL profile. 1045 3.2.1 Protection Layers 1047 The following sections outline the protection required for the 1048 control attributes defined in this document. 1050 Note: There are multiple ways to encapsulate SignedData and 1051 EnvelopedData. The first is to use a MIME wrapper around each 1052 ContentInfo, as specified in MSG [7]. The second is to not use a 1053 MIME wrapper around each ContentInfo, as specified in Transporting 1054 S/MIME Objects in X.400 [8]. 1056 Turner 21 1057 3.2.1.1 Minimum Protection 1059 At a minimum, a SignedData MUST protect each request and response 1060 encapsulated in PKIData and PKIResponse. The following is a 1061 depiction of the minimum wrappings: 1063 Minimum Protection 1064 ------------------ 1065 SignedData 1066 PKIData or PKIResponse 1067 controlSequence 1069 Prior to taking any action on any request or response SignedData(s) 1070 MUST be processed according to CMS [2]. 1072 3.2.1.2 Additional Protection 1074 An additional EnvelopedData MAY also be used to provide 1075 confidentiality of the request and response. An additional 1076 SignedData MAY also be added to provide authentication and integrity 1077 of the encapsulated EnvelopedData. The following is a depiction of 1078 the optional additional wrappings: 1080 Authentication and Integrity 1081 Confidentiality Protection of Confidentiality Protection 1082 -------------------------- ----------------------------- 1083 EnvelopedData SignedData 1084 SignedData EnvelopedData 1085 PKIData or PKIResponse SignedData 1086 controlSequence PKIData or PKIResponse 1087 controlSequence 1089 If an incoming message is encrypted, the confidentiality of the 1090 message MUST be preserved. All EnvelopedData objects MUST be 1091 processed as specified in CMS [2]. If a SignedData is added over an 1092 EnvelopedData, a ContentHints attribute SHOULD be added. See 1093 paragraph 2.9 of Extended Security Services for S/MIME [9]. 1095 If the GLO or GL member applies confidentiality to a request, the 1096 EnvelopedData MUST include the GLA as a recipient. If the GLA 1097 forwards the GL member request to the GLO, then the GLA MUST decrypt 1098 the EnvelopedData content, strip the confidentiality layer, and 1099 apply its own confidentiality layer as an EnvelopedData with the GLO 1100 as a recipient. 1102 Turner 22 1103 3.2.2 Combining Requests and Responses 1105 Multiple requests and response corresponding to a GL MAY be included 1106 in one PKIData.controlSequence or PKIResponse.controlSequence. 1107 Requests and responses for multiple GLs MAY be combined in one 1108 PKIData or PKIResponse by using PKIData.cmsSequence and 1109 PKIResponse.cmsSequence. A separate cmsSequence MUST be used for 1110 different GLs. That is, requests corresponding to two different GLs 1111 are included in different cmsSequences. The following is a diagram 1112 depicting multiple requests and responses combined in one PKIData 1113 and PKIResponse: 1115 Multiple Request and Response 1116 Request Response 1117 ------- -------- 1118 SignedData SignedData 1119 PKIData PKIResponse 1120 cmsSequence cmsSequence 1121 SignedData SignedData 1122 PKIData PKIResponse 1123 controlSequence controlSequence 1124 One or more requests One or more responses 1125 corresponding to one GL corresponding to one GL 1126 SignedData SignedData 1127 PKIData PKIResponse 1128 controlSequence controlSequence 1129 One or more requests One or more responses 1130 corresponding to another GL corresponding to another GL 1132 When applying confidentiality to multiple requests and responses, 1133 all of the requests/response MAY be included in one EnvelopedData. 1134 The following is a depiction: 1136 Confidentiality of Multiple Requests and Responses 1137 Wrapped Together 1138 ---------------- 1139 EnvelopedData 1140 SignedData 1141 PKIData 1142 cmsSequence 1143 SignedData 1144 PKIResponse 1145 controlSequence 1146 One or more requests 1147 corresponding to one GL 1148 SignedData 1149 PKIData 1150 controlSequence 1151 One or more requests 1152 corresponding to one GL 1154 Turner 23 1155 Certain combinations of requests in one PKIData.controlSequence and 1156 one PKIResponse.controlSequence are not allowed. The invalid 1157 combinations listed here MUST NOT be generated: 1159 Invalid Combinations 1160 --------------------------- 1161 glUseKEK & glDeleteMember 1162 glUseKEK & glRekey 1163 glUseKEK & glDelete 1164 glDelete & glAddMember 1165 glDelete & glDeleteMember 1166 glDelete & glRekey 1167 glDelete & glAddOwner 1168 glDelete & glRemoveOwner 1170 To avoid unnecessary errors, certain requests and responses SHOULD 1171 be processed prior to others. The following is the priority of 1172 message processing, if not listed it is an implementation decision 1173 as to which to process first: glUseKEK before glAddMember, glRekey 1174 before glAddMember, and glDeleteMember before glRekey. Note that 1175 there is a processing priority but it does not imply an ordering 1176 within the content. 1178 3.2.3 GLA Generated Messages 1180 When the GLA generates a success or fail message, it generates one 1181 for each request. SKDFailInfo values of unsupportedDuration, 1182 unsupportedDeliveryMethod, unsupportedAlgorithm, noGLONameMatch, 1183 nameAlreadyInUse, alreadyAnOwner, notAnOwner are not returned to GL 1184 members. 1186 If GLKeyAttributes.recipientsNotMutuallyAware is set to FALSE, a 1187 separate PKIResponse.cMCStatusInfoExand PKIData.glKey MUST be 1188 generated for each recipient. However, it is valid to send one 1189 message with multiple attributes to the same recipient. 1191 If the GL has multiple GLOs, the GLA MUST send cMCStatusInfoEx 1192 messages to the requesting GLO. The mechanism to determine which GLO 1193 made the request is beyond the scope of this document. 1195 Turner 24 1196 If a GL is managed and the GLA receives a glAddMember, 1197 glDeleteMember, or glkCompromise message, the GLA redirects the 1198 request to the GLO for review. An additional, SignedData MUST be 1199 applied to the redirected request as follows: 1201 GLA Forwarded Requests 1202 ---------------------- 1203 SignedData 1204 PKIData 1205 cmsSequence 1206 SignedData 1207 PKIData 1208 controlSequence 1210 3.2.4 CMC Control Attributes 1212 Certain control attributes defined in CMC [3] are allowed; they are 1213 as follows: cMCStatusInfoEx transactionId, senderNonce, 1214 recipientNonce, and queryPending. 1216 3.2.4.1 Using cMCStatusInfoEx 1218 cMCStatusInfoEx is used by GLAs to indicate to GLOs and GL members 1219 that a request was unsuccessful. Two classes of failure codes are 1220 used within this document. Errors from the CMCFailInfo list, found 1221 in section 5.1.4 of CMC, are encoded as defined in CMC. Error codes 1222 defined in this document are encoded using the ExtendedFailInfo 1223 field of the cmcStatusInfoEx structure. If the same failure code 1224 applies to multiple commands, a single cmcStatusInfoEx structure can 1225 be used with multiple items in cMCStatusInfoEx.bodyList. The GLA MAY 1226 also return other pertinent information in statusString. The 1227 SKDFailInfo object identifier and value are: 1229 id-cet-skdFailInfo OBJECT IDENTIFIER ::= { iso(1) 1230 identified-organization(3) dod(6) internet(1) security(5) 1231 mechanisms(5) pkix(7) cet(15) skdFailInfo(1) } 1233 Turner 25 1234 SKDFailInfo ::= INTEGER { 1235 unspecified (0), 1236 closedGL (1), 1237 unsupportedDuration (2), 1238 noGLACertificate (3), 1239 invalidCert (4), 1240 unsupportedAlgorithm (5), 1241 noGLONameMatch (6), 1242 invalidGLName (7), 1243 nameAlreadyInUse (8), 1244 noSpam (9), 1245 deniedAccess (10), 1246 alreadyAMember (11), 1247 notAMember (12), 1248 alreadyAnOwner (13), 1249 notAnOwner (14) } 1251 The values have the following meaning: 1253 - unspecified indicates that the GLA is unable or unwilling to 1254 perform the requested action and does not want to indicate the 1255 reason. 1257 - closedGL indicates that members can only be added or deleted by 1258 the GLO. 1260 - unsupportedDuration indicates the GLA does not support 1261 generating keys that are valid for the requested duration. 1263 - noGLACertificate indicates that the GLA does not have a valid 1264 certificate. 1266 - invalidCert indicates the member's encryption certificate was 1267 not verifiable (i.e., signature did not validate, certificate�s 1268 serial number present on a CRL, expired, etc.). 1270 - unsupportedAlgorithm indicates the GLA does not support the 1271 requested algorithm. 1273 - noGLONameMatch indicates that one of the names in the 1274 certificate used to sign a request does not match the name of a 1275 registered GLO. 1277 - invalidGLName indicates the GLA does not support the glName 1278 present in the request. 1280 - nameAlreadyInUse indicates the glName is already assigned on the 1281 GLA. 1283 - noSpam indicates the prospective GL member did not sign the 1284 request (i.e., if the name in glMember.glMemberName does not 1285 match one of the names (either the subject distinguished name or 1287 Turner 26 1288 one of the subject alternative names) in the certificate used to 1289 sign the request). 1291 - alreadyAMember indicates the prospective GL member is already a 1292 GL member. 1294 - notAMember indicates the prospective GL member to be deleted is 1295 not presently a GL member. 1297 - alreadyAnOwner indicates the prospective GLO is already a GLO. 1299 - notAnOwner indicates the prospective GLO to be deleted is not 1300 presently a GLO. 1302 cMCStatusInfoEx is used by GLAs to indicate to GLOs and GL members 1303 that a request was successfully completed. If the request was 1304 successful, the GLA returns a cMCStatusInfoEx response with 1305 cMCStatus.success and optionally other pertinent information in 1306 statusString. 1308 When the GL is managed and the GLO has reviewed GL member initiated 1309 glAddMember, glDeleteMember, and glkComrpomise requests, the GLO 1310 uses cMCStatusInfoEx to indicate the success or failure of the 1311 request. If the request is allowed, cMCStatus.success is returned 1312 and statusString is optionally returned to convey additional 1313 information. If the request is denied, cMCStatus.failed is returned 1314 and statusString is optionally returned to convey additional 1315 information. Additionally, the appropriate SKDFailInfo can be 1316 included in cMCStatusInfoEx.extendedFailInfo. 1318 cMCStatusInfoEx is used by GLOs, GLAs, and GL members to indicate 1319 that signature verification failed. If the signature failed to 1320 verify over any control attibute except a cMCStatusInfoEx, a 1321 cMCStatusInfoEx control attribute MUST be returned indicating 1322 cMCStatus.failed and otherInfo.failInfo.badMessageCheck. If the 1323 signature over the outermost PKIData failed, the bodyList value is 1324 zero (0). If the signature over any other PKIData failed the 1325 bodyList value is the bodyPartId value from the request or response. 1326 GLOs and GL members who receive cMCStatusInfoEx messages whose 1327 signatures are invalid SHOULD generate a new request to avoid 1328 badMessageCheck message loops. 1330 cMCStatusInfoEx is also used by GLOs and GLAs to indicate that a 1331 request could not be performed immediately. If the request could not 1332 be processed immediately by the GLA or GLO, the cMCStatusInfoEx 1333 control attribute MUST be returned indicating cMCStatus.pending and 1334 otherInfo.pendInfo. When requests are redirected to the GLO for 1335 approval (for managed lists), the GLA MUST NOT return a 1336 cMCStatusInfoEx indicating query pending. 1338 cMCStatusInfoEx is also used by GLAs to indicate that a 1339 glaQueryRequest is not supported. If the glaQueryRequest is not 1341 Turner 27 1342 supported, the cMCStatusInfoEx control attribute MUST be returned 1343 indicating cMCStatus.noSupport and statusString is optionally 1344 returned to convey additional information. 1346 3.2.4.2 Using transactionId 1348 transactionId MAY be included by GLOs, GLAs, or GL members to 1349 identify a given transaction. All subsequent requests and responses 1350 related to the original request MUST include the same transactionId 1351 control attribute. If GL members include a transactionId and the 1352 request is redirected to the GLO, the GLA MAY include an additional 1353 transactionId in the outer PKIData. If the GLA included an 1354 additional transactionId in the outer PKIData, when the GLO 1355 generates a cMCStatusInfoEx response it generates one for the GLA 1356 with the GLA�s transactionId and one for the GL member with the GL 1357 member�s transactionId. 1359 3.2.4.3 Using nonces 1361 The use of nonces (see section 5.6 of [3]) can be used to provide 1362 application-level replay prevention. If the originating message 1363 includes a senderNonce, the response to the message MUST include the 1364 received senderNonce value as the recipientNonce and a new value as 1365 the senderNonce value in the response. 1367 If a GLA aggratates multiple messages together or forwards a message 1368 to a GLO, the GLA MAY optionally generate a new nonce value and 1369 include that in the wrapping message. When the response comes back 1370 from the GLO, the GLA builds a response to the originator(s) of the 1371 message(s) and deals with each of the nonce values from the 1372 originating messages. 1374 3.2.4.4 CMC Attribute Support Requirements 1376 The following are the implementation requirements for CMC control 1377 attributes for an implementation be considered conformant to this 1378 specification: 1380 Required 1381 Implementation Requirement | Control 1382 GLO | GLA | GL Member | Attribute 1383 O R | O R F | O R | 1384 --------- | ------------- | --------- | ---------- 1385 MUST MUST | MUST MUST - | MUST MUST | cMCStatusinfoEx 1386 MAY MAY | MAY MAY - | MAY MAY | transactionId 1387 MAY MAY | MAY MAY - | MAY MAY | senderNonce 1388 MAY MAY | MAY MAY - | MAY MAY | recepientNonce 1389 MUST MUST | MUST MUST - | MUST MUST | SKDFailInfo 1391 Turner 28 1392 3.2.5 Resubmitted GL Member Messages 1394 When the GL is managed, the GLA forwards the GL member requests to 1395 the GLO for GLO approval by creating a new request message 1396 containing the GL member request(s) as a cmsSequence item. If the 1397 GLO approves the request it can either add a new layer of wrapping 1398 and send it back to the GLA or create a new message and send it to 1399 the GLA. (Note in this case there are now 3 layers of PKIData 1400 messages with appropriate signing layers.) 1402 3.2.6 PKIX Certificate and CRL Profile 1404 Signatures, certificates, and CRLs are verified according to the 1405 PKIX profile [5]. 1407 Name matching is performed according to the PKIX profile [5]. 1409 All distinguished name forms must follow the UTF8String convention 1410 noted in the PKIX profile [5]. 1412 A certificate per-GL would be issued to the GLA. 1414 GL policy may mandate that the GL member�s address be included in 1415 the GL member�s certificate. 1417 4 Administrative Messages 1419 There are a number of administrative messages that must be performed 1420 to manage a GL. The following sections describe each request and 1421 response message combination in detail. The procedures defined in 1422 this section are not prescriptive. 1424 4.1 Assign KEK To GL 1426 Prior to generating a group key, a GL needs to be setup and a shared 1427 KEK assigned to the GL. Figure 3 depicts the protocol interactions 1428 to setup and assign a shared KEK. Note that error messages are not 1429 depicted in Figure 3. 1431 +-----+ 1 2 +-----+ 1432 | GLA | <-------> | GLO | 1433 +-----+ +-----+ 1435 Figure 3 - Create Group List 1437 Turner 29 1438 The process is as follows: 1440 1 - The GLO is the entity responsible for requesting the creation 1441 of the GL. The GLO sends a 1442 SignedData.PKIData.controlSequence.glUseKEK request to the GLA 1443 (1 in Figure 3). The GLO MUST include: glName, glAddress, 1444 glOwnerName, glOwnerAddress, and glAdministration. The GLO MAY 1445 also include their preferences for the shared KEK in 1446 glKeyAttributes by indicating whether the GLO controls the 1447 rekey in rekeyControlledByGLO, whether separate glKey messages 1448 should be sent to each recipient in 1449 recipientsNotMutuallyAware, the requested algorithm to be used 1450 with the shared KEK in requestedAlgorithm, the duration of the 1451 shared KEK, and how many shared KEKs should be initially 1452 distributed in generationCounter. 1454 1.a - If the GLO knows of members to be added to the GL, the 1455 glAddMember request(s) MAY be included in the same 1456 controlSequence as the glUseKEK request (see section 3.2.2). 1457 The GLO indicates the same glName in the glAddMember request 1458 as in glUseKEK.glInfo.glName. Further glAddMember procedures 1459 are covered in section 4.3. 1461 1.b - The GLO can apply confidentiality to the request by 1462 encapsulating the SignedData.PKIData in an EnvelopedData 1463 (see section 3.2.1.2). 1465 1.c - The GLO can also optionally apply another SignedData over 1466 the EnvelopedData (see section 3.2.1.2). 1468 2 - Upon receipt of the request, the GLA verifies the signature on 1469 the inner most SignedData.PKIData. If an additional SignedData 1470 and/or EnvelopedData encapsulates the request (see sections 1471 3.2.1.2 and 3.2.2), the GLA verifies the outer signature(s) 1472 and/or decrypt the outer layer(S) prior to verifying the 1473 signature on the inner most SignedData. 1475 2.a - If the signatures do not verify, the GLA returns a 1476 cMCStatusInfoEx response indicating cMCStatus.failed and 1477 otherInfo.failInfo.badMessageCheck. 1479 2.b � Else if the signatures do verify but the GLA does not have a 1480 valid certificate, the GLA returns a cMCStatusInfoEx with 1481 cMCStatus.failed and otherInfo.extendedFailInfo.SKDFailInfo 1482 value of noValidGLACertificate. Instead of immediately 1483 returning the error code, the GLA attempts to get a 1484 certificate, possibly using CMC [3]. 1486 2.c - Else the signatures are valid and the GLA does have a valid 1487 certificate, the GLA checks that one of the names in the 1488 certificate used to sign the request matches one of the 1489 names in glUseKEK.glOwnerInfo.glOwnerName. 1491 Turner 30 1492 2.c.1 - If the names do not match, the GLA returns a response 1493 indicating cMCStatusInfoEx with cMCStatus.failed and 1494 otherInfo.extendedFailInfo.SKDFailInfo value of 1495 noGLONameMatch. 1497 2.c.2 - Else if the names all match, the GLA checks that the 1498 glName and glAddress is not already in use. The GLA also 1499 checks any glAddMember included within the controlSequence 1500 with this glUseKEK. Further processing of the glAddMember 1501 is covered in section 4.3. 1503 2.c.2.a - If the glName is already in use the GLA returns a 1504 response indicating cMCStatusInfoEx with 1505 cMCStatus.failed and 1506 otherInfo.extendedFailInfo.SKDFailInfo value of 1507 nameAlreadyInUse. 1509 2.c.2.b - Else if the requestedAlgorithm is not supported, the GLA 1510 returns a response indicating cMCStatusInfoEx with 1511 cMCStatus.failed and 1512 otherInfo.extendedFailInfo.SKDFailInfo value of 1513 unsupportedAlgorithm. 1515 2.c.2.c - Else if the duration cannot be supported, determining 1516 this is beyond the scope of this document, the GLA 1517 returns a response indicating cMCStatusInfoEx with 1518 cMCStatus.failed and 1519 otherInfo.extendedFailInfo.SKDFailInfo value of 1520 unsupportedDuration. 1522 2.c.2.d - Else if the GL cannot be supported for other reasons, 1523 which the GLA does not wish to disclose, the GLA returns 1524 a response indicating cMCStatusInfoEx with 1525 cMCStatus.failed and 1526 otherInfo.extendedFailInfo.SKDFailInfo value of 1527 unspecified. 1529 2.c.2.e - Else if the glName is not already in use, the duration 1530 can be supported, and the requestedAlgorithm is 1531 supported, the GLA MUST return a cMCStatusInfoEx 1532 indicating cMCStatus.success (2 in Figure 3). The GLA 1533 also takes administrative actions, which are beyond the 1534 scope of this document, to store the glName, glAddress, 1535 glKeyAttributes, glOwnerName, and glOwnerAddress. The 1536 GLA also sends a glKey message as described in section 1537 5. 1539 2.c.2.e.1 - The GLA can apply confidentiality to the response by 1540 encapsulating the SignedData.PKIResponse in an 1541 EnvelopedData if the request was encapsulated in an 1542 EnvelopedData (see section 3.2.1.2). 1544 Turner 31 1545 2.c.2.e.2 - The GLA can also optionally apply another SignedData 1546 over the EnvelopedData (see section 3.2.1.2). 1548 3 - Upon receipt of the cMCStatusInfoEx responses, the GLO 1549 verifies the GLA signature(s). If an additional SignedData 1550 and/or EnvelopedData encapsulates the response (see section 1551 3.2.1.2 or 3.2.2), the GLO verifies the outer signature and/or 1552 decrypt the outer layer prior to verifying the signature on 1553 the inner most SignedData. 1555 3.a - If the signatures do verify, the GLO MUST check that one of 1556 the names in the certificate used to sign the response 1557 matches the name of the GL. 1559 3.a.1 � If the name of the GL does not match the name present in 1560 the certificate used to sign the message, the GLO should 1561 not believe the response. 1563 3.a.2 � Else if the name of the GL does match the name present in 1564 the certificate and: 1566 3.a.2.a - If the signatures do verify and the response was 1567 cMCStatusInfoEx indicating cMCStatus.success, the GLO 1568 has successfully created the GL. 1570 3.a.2.b - Else if the signatures are valid and the response is 1571 cMCStatusInfoEx.cMCStatus.failed with any reason, the 1572 GLO can reattempt to create the GL using the information 1573 provided in the response. The GLO can also use the 1574 glaQueryRequest to determine the algorithms and other 1575 characteristics supported by the GLA (see section 4.9). 1577 4.2 Delete GL From GLA 1579 From time to time, there are instances when a GL is no longer 1580 needed. In this case, the GLO deletes the GL. Figure 4 depicts that 1581 protocol interactions to delete a GL. 1583 +-----+ 1 2 +-----+ 1584 | GLA | <-------> | GLO | 1585 +-----+ +-----+ 1587 Figure 4 - Delete Group List 1589 The process is as follows: 1591 1 - The GLO is responsible for requesting the deletion of the GL. 1592 The GLO sends a SignedData.PKIData.controlSequence.glDelete 1594 Turner 32 1595 request to the GLA (1 in Figure 4). The name of the GL to be 1596 deleted is included in GeneralName. 1598 1.a - The GLO can optionally apply confidentiality to the request 1599 by encapsulating the SignedData.PKIData in an EnvelopedData 1600 (see section 3.2.1.2). 1602 1.b - The GLO MAY can also optionally apply another SignedData 1603 over the EnvelopedData (see section 3.2.1.2). 1605 2 - Upon receipt of the request the GLA verifies the signature on 1606 the inner most SignedData.PKIData. If an additional SignedData 1607 and/or EnvelopedData encapsulates the request (see section 1608 3.2.1.2 or 3.2.2), the GLA verifies the outer signature and/or 1609 decrypt the outer layer prior to verifying the signature on 1610 the inner most SignedData. 1612 2.a - If the signatures cannot be verified, the GLA returns a 1613 cMCStatusInfoEx response indicating cMCStatus.failed and 1614 otherInfo.failInfo.badMessageCheck. 1616 2.b - Else if the signatures verify, the GLA makes sure the GL is 1617 supported by checking the name of the GL matches a glName 1618 stored on the GLA. 1620 2.b.1 - If the glName is not supported by the GLA, the GLA returns 1621 a response indicating cMCStatusInfoEx with 1622 cMCStatus.failed and 1623 otherInfo.extendedFailInfo.SKDFailInfo value of 1624 invalidGLName. 1626 2.b.2 - Else if the glName is supported by the GLA, the GLA 1627 ensures a registered GLO signed the glDelete request by 1628 checking if one of the names present in the digital 1629 signature certificate used to sign the glDelete request 1630 matches a registered GLO. 1632 2.b.2.a - If the names do not match, the GLA returns a response 1633 indicating cMCStatusInfoEx with cMCStatus.failed and 1634 otherInfo.extendedFailInfo.SKDFailInfo value of 1635 noGLONameMatch. 1637 2.b.2.b - Else if the names do match, but the GL cannot be deleted 1638 for other reasons, which the GLA does not wish to 1639 disclose, the GLA returns a response indicating 1640 cMCStatusInfoEx with cMCStatus.failed and 1641 otherInfo.extendedFailInfo.SKDFailInfo value of 1642 unspecified. Actions beyond the scope of this document 1643 must then be taken to delete the GL from the GLA. 1645 2.b.2.c - Else if the names do match, the GLA returns a 1646 cMCStatusInfoEx indicating cMCStatus.success (2 in 1648 Turner 33 1649 Figure 4). The GLA ought not accept further requests for 1650 member additions, member deletions, or group rekeys for 1651 this GL. 1653 2.b.2.c.1 - The GLA can apply confidentiality to the response by 1654 encapsulating the SignedData.PKIResponse in an 1655 EnvelopedData if the request was encapsulated in an 1656 EnvelopedData (see section 3.2.1.2). 1658 2.b.2.c.2 - The GLA MAY can also optionally apply another 1659 SignedData over the EnvelopedData (see section 1660 3.2.1.2). 1662 3 - Upon receipt of the cMCStatusInfoEx response, the GLO verifies 1663 the GLA signature(s). If an additional SignedData and/or 1664 EnvelopedData encapsulates the response (see section 3.2.1.2 1665 or 3.2.2), the GLO verifies the outer signature and/or decrypt 1666 the outer layer prior to verifying the signature on the inner 1667 most SignedData. 1669 3.a - If the signatures verify, the GLO checks that one of the 1670 names in the certificate used to sign the response matches 1671 the name of the GL. 1673 3.a.1 � If the name of the GL does not match the name present in 1674 the certificate used to sign the message, the GLO should 1675 not believe the response. 1677 3.a.2 � Else if the name of the GL does match the name present in 1678 the certificate and: 1680 3.a.2.a - If the signatures verify and the response was 1681 cMCStatusInfoEx indicating cMCStatus.success, the GLO 1682 has successfully deleted the GL. 1684 3.a.2.b - Else if the signatures do verify and the response was 1685 cMCStatusInfoEx.cMCStatus.failed with any reason, the 1686 GLO can reattempt to delete the GL using the information 1687 provided in the response. 1689 4.3 Add Members To GL 1691 To add members to GLs, either the GLO or prospective members use the 1692 glAddMember request. The GLA processes GLO and prospective GL member 1693 requests differently though. GLOs can submit the request at any time 1694 to add members to the GL, and the GLA, once it has verified the 1695 request came from a registered GLO, should process it. If a 1696 prospective member sends the request, the GLA needs to determine how 1697 the GL is administered. When the GLO initially configured the GL, 1698 they set the GL to be unmanaged, managed, or closed (see section 1699 3.1.1). In the unmanaged case, the GLA merely processes the member�s 1701 Turner 34 1702 request. For the managed case, the GLA forwards the requests from 1703 the prospective members to the GLO for review. Where there are 1704 multiple GLOs for a GL, which GLO the request is forwarded to is 1705 beyond the scope of this document. The GLO reviews the request and 1706 either rejects it or submits a reformed request to the GLA. In the 1707 closed case, the GLA will not accept requests from prospective 1708 members. The following sections describe the processing for the 1709 GLO(s), GLA, and prospective GL members depending on where the 1710 glAddMeber request originated, either from a GLO or from prospective 1711 members. Figure 5 depicts the protocol interactions for the three 1712 options. Note that the error messages are not depicted. 1714 +-----+ 2,B{A} 3 +----------+ 1715 | GLO | <--------+ +-------> | Member 1 | 1716 +-----+ | | +----------+ 1717 1 | | 1718 +-----+ <--------+ | 3 +----------+ 1719 | GLA | A +-------> | ... | 1720 +-----+ <-------------+ +----------+ 1721 | 1722 | 3 +----------+ 1723 +-------> | Member n | 1724 +----------+ 1726 Figure 5 - Member Addition 1728 An important decision that needs to be made on a group by group 1729 basis is whether to rekey the group every time a new member is 1730 added. Typically, unmanaged GLs should not be rekeyed when a new 1731 member is added, as the overhead associated with rekeying the group 1732 becomes prohibitive, as the group becomes large. However, managed 1733 and closed GLs can be rekeyed to maintain the confidentiality of the 1734 traffic sent by group members. An option to rekeying managed or 1735 closed GLs when a member is added is to generate a new GL with a 1736 different group key. Group rekeying is discussed in sections 4.5 and 1737 5. 1739 4.3.1 GLO Initiated Additions 1741 The process for GLO initiated glAddMember requests is as follows: 1743 1 - The GLO collects the pertinent information for the member(s) 1744 to be added (this may be done through an out of bands means). 1745 The GLO then sends a SignedData.PKIData.controlSequence with a 1746 separate glAddMember request for each member to the GLA (1 in 1747 Figure 5). The GLO includes: the GL name in glName, the 1748 member's name in glMember.glMemberName, the member�s address 1749 in glMember.glMemberAddress, and the member's encryption 1750 certificate in glMember.certificates.pKC. The GLO can also 1751 include any attribute certificates associated with the 1752 member�s encryption certificate in glMember.certificates.aC, 1754 Turner 35 1755 and the certification path associated with the member�s 1756 encryption and attribute certificates in 1757 glMember.certificates.certPath. 1759 1.a - The GLO can optionally apply confidentiality to the request 1760 by encapsulating the SignedData.PKIData in an EnvelopedData 1761 (see section 3.2.1.2). 1763 1.b - The GLO can also optionally apply another SignedData over 1764 the EnvelopedData (see section 3.2.1.2). 1766 2 - Upon receipt of the request, the GLA verifies the signature on 1767 the inner most SignedData.PKIData. If an additional SignedData 1768 and/or EnvelopedData encapsulates the request (see section 1769 3.2.1.2 or 3.2.2), the GLA verifies the outer signature and/or 1770 decrypt the outer layer prior to verifying the signature on 1771 the inner most SignedData. 1773 2.a - If the signatures cannot be verified, the GLA returns a 1774 cMCStatusInfoEx response indicating cMCStatus.failed and 1775 otherInfo.failInfo.badMessageCheck. 1777 2.b - Else if the signatures verify, the glAddMember request is 1778 included in a controlSequence with the glUseKEK request, and 1779 the processing in section 4.1 item 2.e is successfully 1780 completed the GLA returns a cMCStatusInfoEx indicating 1781 cMCStatus.success (2 in Figure 5). 1783 2.b.1 - The GLA can apply confidentiality to the response by 1784 encapsulating the SignedData.PKIData in an EnvelopedData 1785 if the request was encapsulated in an EnvelopedData (see 1786 section 3.2.1.2). 1788 2.b.2 - The GLA can also optionally apply another SignedData over 1789 the EnvelopedData (see section 3.2.1.2). 1791 2.c - Else if the signatures verify and the GLAddMember request is 1792 not included in a controlSequence with the GLCreate request, 1793 the GLA makes sure the GL is supported by checking that the 1794 glName matches a glName stored on the GLA. 1796 2.c.1 - If the glName is not supported by the GLA, the GLA returns 1797 a response indicating cMCStatusInfoEx with 1798 cMCStatus.failed and 1799 otherInfo.extendedFailInfo.SKDFailInfo value of 1800 invalidGLName. 1802 2.c.2 - Else if the glName is supported by the GLA, the GLA checks 1803 to see if the glMemberName is present on the GL. 1805 2.c.2.a - If the glMemberName is present on the GL, the GLA 1806 returns a response indicating cMCStatusInfoEx with 1808 Turner 36 1809 cMCStatus.failed and 1810 otherInfo.extendedFailInfo.SKDFailInfo value of 1811 alreadyAMember. 1813 2.c.2.b - Else if the glMemberName is not present on the GL, the 1814 GLA checks how the GL is administered. 1816 2.c.2.b.1 - If the GL is closed, the GLA checks that a registered 1817 GLO signed the request by checking that one of the 1818 names in the digital signature certificate used to 1819 sign the request matches a registered GLO. 1821 2.c.2.b.1.a - If the names do not match, the GLA returns a 1822 response indicating cMCStatusInfoEx with 1823 cMCStatus.failed and 1824 otherInfo.extendedFailInfo.SKDFailInfo value of 1825 noGLONameMatch. 1827 2.c.2.b.1.b - Else if the names match, the GLA verifies the 1828 member's encryption certificate. 1830 2.c.2.b.1.b.1 - If the member's encryption certificate cannot be 1831 verified, the GLA can return a response indicating 1832 cMCStatusInfoEx with cMCStatus.failed and 1833 otherInfo.extendedFailInfo.SKDFailInfo value of 1834 invalidCert to the GLO. If the GLA does not return 1835 a cMCStatusInfoEx.cMCStatus.failed response, the 1836 GLA issues a glProvideCert request (see section 1837 4.10). 1839 2.c.2.b.1.b.2 - Else if the member's certificate verifies, the GLA 1840 returns a cMCStatusInfoEx indicating 1841 cMCStatus.success (2 in Figure 5). The GLA also 1842 takes administrative actions, which are beyond the 1843 scope of this document, to add the member to the 1844 GL stored on the GLA. The GLA also distributes the 1845 shared KEK to the member via the mechanism 1846 described in section 5. 1848 2.c.2.b.1.b.2.a - The GLA applies confidentiality to the response 1849 by encapsulating the SignedData.PKIData in an 1850 EnvelopedData if the request was encapsulated in 1851 an EnvelopedData (see section 3.2.1.2). 1853 2.c.2.b.1.b.2.b - The GLA can also optionally apply another 1854 SignedData over the EnvelopedData (see section 1855 3.2.1.2). 1857 2.c.2.b.2 - Else if the GL is managed, the GLA checks that either 1858 a registered GLO or the prospective member signed the 1859 request. For GLOs, one of the names in the certificate 1860 used to sign the request needs to match a registered 1862 Turner 37 1863 GLO. For the prospective member, the name in 1864 glMember.glMemberName needs to match one of the names 1865 in the certificate used to sign the request. 1867 2.c.2.b.2.a - If the signer is neither a registered GLO nor the 1868 prospective GL member, the GLA returns a response 1869 indicating cMCStatusInfoEx with cMCStatus.failed and 1870 otherInfo.extendedFailInfo.SKDFailInfo value of 1871 noSpam. 1873 2.c.2.b.2.b � Else if the signer is a registered GLO, the GLA 1874 verifies the member's encryption certificate. 1876 2.c.2.b.2.b.1 - If the member's certificate cannot be verified, 1877 the GLA can return a response indicating 1878 cMCStatusInfoEx with cMCStatus.failed and 1879 otherInfo.extendedFailInfo.SKDFailInfo value of 1880 invalidCert. If the GLA does not return a 1881 cMCStatus.failed response, the GLA MUST issue a 1882 glProvideCert request (see section 4.10). 1884 2.c.2.b.2.b.2 - Else if the member's certificate verifies, the GLA 1885 MUST return a cMCStatusInfoEx indicating 1886 cMCStatus.success to the GLO (2 in Figure 5). The 1887 GLA also takes administrative actions, which are 1888 beyond the scope of this document, to add the 1889 member to the GL stored on the GLA. The GLA also 1890 distributes the shared KEK to the member via the 1891 mechanism described in section 5. The GL policy 1892 may mandate that the GL member�s address be 1893 included in the GL member�s certificate. 1895 2.c.2.b.2.b.2.a - The GLA applies confidentiality to the response 1896 by encapsulating the SignedData.PKIData in an 1897 EnvelopedData if the request was encapsulated in 1898 an EnvelopedData (see section 3.2.1.2). 1900 2.c.2.b.2.b.2.b - The GLA can also optionally apply another 1901 SignedData over the EnvelopedData (see section 1902 3.2.1.2). 1904 2.c.2.b.2.c - Else if the signer is the prospective member, the 1905 GLA forwards the glAddMember request (see section 1906 3.2.3) to a registered GLO (B{A} in Figure 5). If 1907 there is more than one registered GLO, the GLO to 1908 which the request is forwarded to is beyond the 1909 scope of this document. Further processing of the 1910 forwarded request by GLOs is addressed in 3 of 1911 section 4.3.2. 1913 2.c.2.b.2.c.1 - The GLA applies confidentiality to the forwarded 1914 request by encapsulating the SignedData.PKIData in 1916 Turner 38 1917 an EnvelopedData if the original request was 1918 encapsulated in an EnvelopedData (see section 1919 3.2.1.2). 1921 2.c.2.b.2.c.2 - The GLA can also optionally apply another 1922 SignedData over the EnvelopedData (see section 1923 3.2.1.2). 1925 2.c.2.b.3 - Else if the GL is unmanaged, the GLA checks that 1926 either a registered GLO or the prospective member 1927 signed the request. For GLOs, one of the names in the 1928 certificate used to sign the request needs tp match 1929 the name of a registered GLO. For the prospective 1930 member, the name in glMember.glMemberName needs to 1931 match one of the names in the certificate used to sign 1932 the request. 1934 2.c.2.b.3.a - If the signer is neither a registered GLO nor the 1935 prospective member, the GLA returns a response 1936 indicating cMCStatusInfoEx with cMCStatus.failed and 1937 otherInfo.extendedFailInfo.SKDFailInfo value of 1938 noSpam. 1940 2.c.2.b.3.b - Else if the signer is either a registered GLO or the 1941 prospective member, the GLA verifies the member's 1942 encryption certificate. 1944 2.c.2.b.3.b.1 - If the member's certificate cannot be verified, 1945 the GLA can return a response indicating 1946 cMCStatusInfoEx with cMCStatus.failed and 1947 otherInfo.extendedFailInfo.SKDFailInfo value of 1948 invalidCert to either the GLO or the prospective 1949 member depending on where the request originated. 1950 If the GLA does not return a cMCStatus.failed 1951 response, the GLA issues a glProvideCert request 1952 (see section 4.10) to either the GLO or 1953 prospective member depending on where the request 1954 originated. 1956 2.c.2.b.3.b.2 - Else if the member's certificate verifies, the GLA 1957 returns a cMCStatusInfoEx indicating 1958 cMCStatus.success to the GLO (2 in Figure 5) if 1959 the GLO signed the request and to the GL member (3 1960 in Figure 5) if the GL member signed the request. 1961 The GLA also takes administrative actions, which 1962 are 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. 1967 2.c.2.b.3.b.2.a - The GLA applies confidentiality to the response 1968 by encapsulating the SignedData.PKIData in an 1970 Turner 39 1971 EnvelopedData if the request was encapsulated in 1972 an EnvelopedData (see section 3.2.1.2). 1974 2.c.2.b.3.b.2.b - The GLA can also optionally apply another 1975 SignedData over the EnvelopedData (see section 1976 3.2.1.2). 1978 3 - Upon receipt of the cMCStatusInfoEx response, the GLO verifies 1979 the GLA signature(s). If an additional SignedData and/or 1980 EnvelopedData encapsulates the response (see section 3.2.1.2 1981 or 3.2.2), the GLO verifies the outer signature and/or decrypt 1982 the outer layer prior to verifying the signature on the inner 1983 most SignedData. 1985 3.a - If the signatures verify, the GLO checks that one of the 1986 names in the certificate used to sign the response matches 1987 the name of the GL. 1989 3.a.1 � If the name of the GL does not match the name present in 1990 the certificate used to sign the message, the GLO should 1991 not believe the response. 1993 3.a.2 � Else if the name of the GL matches the name present in the 1994 certificate and: 1996 3.a.2.a - If the signatures verify and the response is 1997 cMCStatusInfoEx indicating cMCStatus.success, the GLA 1998 has added the member to the GL. If member was added to a 1999 managed list and the original request was signed by the 2000 member, the GLO sends a 2001 cMCStatusInfoEx.cMCStatus.success to the GL member. 2003 3.a.2.b - Else if the GLO received a 2004 cMCStatusInfoEx.cMCStatus.failed with any reason, the 2005 GLO can reattempt to add the member to the GL using the 2006 information provided in the response. 2008 4 - Upon receipt of the cMCStatusInfoEx response, the prospective 2009 member verifies the GLA signatures or GLO signatures. If an 2010 additional SignedData and/or EnvelopedData encapsulates the 2011 response (see section 3.2.1.2 or 3.2.2), the GLO verifies the 2012 outer signature and/or decrypt the outer layer prior to 2013 verifying the signature on the inner most SignedData. 2015 4.a - If the signatures verify, the GL member checks that one of 2016 the names in the certificate used to sign the response 2017 matches the name of the GL. 2019 4.a.1 � If the name of the GL does not match the name present in 2020 the certificate used to sign the message, the GL member 2021 should not believe the response. 2023 Turner 40 2024 4.a.2 � Else if the name of the GL matches the name present in the 2025 certificate and: 2027 4.a.2.a - If the signatures verify, the prospective member has 2028 been added to the GL. 2030 4.a.2.b - Else if the prospective member received a 2031 cMCStatusInfoEx.cMCStatus.failed, for any reason, the 2032 prospective member MAY reattempt to add themselves to 2033 the GL using the information provided in the response. 2035 4.3.2 Prospective Member Initiated Additions 2037 The process for prospective member initiated glAddMember requests is 2038 as follows: 2040 1 - The prospective GL member sends a 2041 SignedData.PKIData.controlSequence.glAddMember request to the 2042 GLA (A in Figure 5). The prospective GL member includes: the 2043 GL name in glName, their name in glMember.glMemberName, their 2044 address in glMember.glMemberAddress, and their encryption 2045 certificate in glMember.certificates.pKC. The prospective GL 2046 member can also include any attribute certificates associated 2047 with their encryption certificate in glMember.certificates.aC, 2048 and the certification path associated with their encryption 2049 and attribute certificates in glMember.certificates.certPath. 2051 1.a - The prospective GL member can optionally apply 2052 confidentiality to the request by encapsulating the 2053 SignedData.PKIData in an EnvelopedData (see section 2054 3.2.1.2). 2056 1.b - The prospective GL member MAY can also optionally apply 2057 another SignedData over the EnvelopedData (see section 2058 3.2.1.2). 2060 2 - Upon receipt of the request, the GLA verifies the request as 2061 per 2 in section 4.3.1. 2063 3 - Upon receipt of the forwarded request, the GLO verifies the 2064 prospective GL member signature on the inner most 2065 SignedData.PKIData and the GLA signature on the outer layer. 2066 If an EnvelopedData encapsulates the inner most layer (see 2067 section 3.2.1.2 or 3.2.2), the GLO decrypts the outer layer 2068 prior to verifying the signature on the inner most SignedData. 2070 Note: For cases where the GL is closed and either a) a 2071 prospective member sends directly to the GLO or b) the GLA has 2072 mistakenly forwarded the request to the GLO, the GLO should 2073 first determine whether to honor the request. 2075 Turner 41 2076 3.a - If the signatures verify, the GLO checks to make sure one of 2077 the names in the certificate used to sign the request 2078 matches the name in glMember.glMemberName. 2080 3.a.1 - If the names do not match, the GLO sends a 2081 SignedData.PKIResponse.controlSequence message back to the 2082 prospective member with cMCStatusInfoEx.cMCStatus.failed 2083 indicating why the prospective member was denied in 2084 cMCStausInfo.statusString. This stops people from adding 2085 people to GLs without their permission. 2087 3.a.2 - Else if the names match, the GLO determines whether the 2088 prospective member is allowed to be added. The mechanism 2089 is beyond the scope of this document; however, the GLO 2090 should check to see that the glMember.glMemberName is not 2091 already on the GL. 2093 3.a.2.a - If the GLO determines the prospective member is not 2094 allowed to join the GL, the GLO can return a 2095 SignedData.PKIResponse.controlSequence message back to 2096 the prospective member with 2097 cMCStatusInfoEx.cMCtatus.failed indicating why the 2098 prospective member was denied in cMCStatus.statusString. 2100 3.a.2.b - Else if GLO determines the prospective member is allowed 2101 to join the GL, the GLO verifies the member's encryption 2102 certificate. 2104 3.a.2.b.1 - If the member's certificate cannot be verified, the 2105 GLO returns a SignedData.PKIResponse.controlSequence 2106 back to the prospective member with 2107 cMCStatusInfoEx.cMCtatus.failed indicating that the 2108 member�s encryption certificate did not verify in 2109 cMCStatus.statusString. If the GLO does not return a 2110 cMCStatusInfoEx response, the GLO sends a 2111 SignedData.PKIData.controlSequence.glProvideCert 2112 message to the prospective member requesting a new 2113 encryption certificate (see section 4.10). 2115 3.a.2.b.2 - Else if the member's certificate verifies, the GLO 2116 resubmits the glAddMember request (see section 3.2.5) 2117 to the GLA (1 in Figure 5). 2119 3.a.2.b.2.a - The GLO applies confidentiality to the new 2120 GLAddMember request by encapsulating the 2121 SignedData.PKIData in an EnvelopedData if the 2122 initial request was encapsulated in an EnvelopedData 2123 (see section 3.2.1.2). 2125 3.a.2.b.2.b - The GLO can also optionally apply another SignedData 2126 over the EnvelopedData (see section 3.2.1.2). 2128 Turner 42 2129 4 - Processing continues as in 2 of section 4.3.1. 2131 4.4 Delete Members From GL 2133 To delete members from GLs, either the GLO or members to be removed 2134 use the glDeleteMember request. The GLA processes GLO and members 2135 requesting their own removal make requests differently. The GLO can 2136 submit the request at any time to delete members from the GL, and 2137 the GLA, once it has verified the request came from a registered 2138 GLO, should delete the member. If a member sends the request, the 2139 GLA needs to determine how the GL is administered. When the GLO 2140 initially configured the GL, they set the GL to be unmanaged, 2141 managed, or closed (see section 3.1.1). In the unmanaged case, the 2142 GLA merely processes the member�s request. For the managed case, the 2143 GLA forwards the requests from the member to the GLO for review. 2144 Where there are multiple GLOs for a GL, which GLO the request is 2145 forwarded to is beyond the scope of this document. The GLO reviews 2146 the request and either rejects it or submits a reformed request to 2147 the GLA. In the closed case, the GLA will not accept requests from 2148 members. The following sections describe the processing for the 2149 GLO(s), GLA, and GL members depending on where the request 2150 originated, either from a GLO or from members wanting to be removed. 2151 Figure 6 depicts the protocol interactions for the three options. 2152 Note that the error messages are not depicted. 2154 +-----+ 2,B{A} 3 +----------+ 2155 | GLO | <--------+ +-------> | Member 1 | 2156 +-----+ | | +----------+ 2157 1 | | 2158 +-----+ <--------+ | 3 +----------+ 2159 | GLA | A +-------> | ... | 2160 +-----+ <-------------+ +----------+ 2161 | 2162 | 3 +----------+ 2163 +-------> | Member n | 2164 +----------+ 2166 Figure 6 - Member Deletion 2168 If the member is not removed from the GL, they will continue to 2169 receive and be able to decrypt data protected with the shared KEK 2170 and will continue to receive rekeys. For unmanaged lists, there is 2171 no point to a group rekey because there is no guarantee that the 2172 member requesting to be removed has not already added themselves 2173 back on the GL under a different name. For managed and closed GLs, 2174 the GLO needs to take steps to ensure the member being deleted is 2175 not on the GL twice. After ensuring this, managed and closed GLs can 2176 be rekeyed to maintain the confidentiality of the traffic sent by 2177 group members. If the GLO is sure the member has been deleted the 2178 group rekey mechanism can be used to distribute the new key (see 2179 sections 4.5 and 5). 2181 Turner 43 2182 4.4.1 GLO Initiated Deletions 2184 The process for GLO initiated glDeleteMember requests is as follows: 2186 1 - The GLO collects the pertinent information for the member(s) 2187 to be deleted (this can be done through an out of bands 2188 means). The GLO then sends a 2189 SignedData.PKIData.controlSequence with a separate 2190 glDeleteMember request for each member to the GLA (1 in Figure 2191 6). The GLO MUST include: the GL name in glName and the 2192 member's name in glMemberToDelete. If the GL from which the 2193 member is being deleted in a closed or managed GL, the GLO 2194 MUST also generate a glRekey request and include it with the 2195 glDeletemember request (see section 4.5). 2197 1.a - The GLO can optionally apply confidentiality to the request 2198 by encapsulating the SignedData.PKIData in an EnvelopedData 2199 (see section 3.2.1.2). 2201 1.b - The GLO can also optionally apply another SignedData over 2202 the EnvelopedData (see section 3.2.1.2). 2204 2 - Upon receipt of the request, the GLA verifies the signature on 2205 the inner most SignedData.PKIData. If an additional SignedData 2206 and/or EnvelopedData encapsulates the request (see section 2207 3.2.1.2 or 3.2.2), the GLA verifies the outer signature and/or 2208 decrypt the outer layer prior to verifying the signature on 2209 the inner most SignedData. 2211 2.a - If the signatures cannot be verified, the GLA returns a 2212 cMCStatusInfoEx response indicating cMCStatus.failed and 2213 otherInfo.failInfo.badMessageCheck. 2215 2.b - Else if the signatures verify, the GLA makes sure the GL is 2216 supported by the GLA by checking that the glName matches a 2217 glName stored on the GLA. 2219 2.b.1 - If the glName is not supported by the GLA, the GLA returns 2220 a response indicating cMCStatusInfoEx with 2221 cMCStatus.failed and 2222 otherInfo.extendedFailInfo.SKDFailInfo value of 2223 invalidGLName. 2225 2.b.2 - Else if the glName is supported by the GLA, the GLA checks 2226 to see if the glMemberName is present on the GL. 2228 2.b.2.a - If the glMemberName is not present on the GL, the GLA 2229 returns a response indicating cMCStatusInfoEx with 2230 cMCStatus.failed and 2232 Turner 44 2233 otherInfo.extendedFailInfo.SKDFailInfo value of 2234 notAMember. 2236 2.b.2.b - Else if the glMemberName is already on the GL, the GLA 2237 checks how the GL is administered. 2239 2.b.2.b.1 - If the GL is closed, the GLA checks that the 2240 registered GLO signed the request by checking that one 2241 of the names in the digital signature certificate used 2242 to sign the request matches the registered GLO. 2244 2.b.2.b.1.a - If the names do not match, the GLA returns a 2245 response indicating cMCStatusInfoEx with 2246 cMCStatus.failed and 2247 otherInfo.extendedFailInfo.SKDFailInfo value of 2248 closedGL. 2250 2.b.2.b.1.b - Else if the names do match, the GLA returns a 2251 cMCStatusInfoEx.cMCStatus.success (2 in Figure 5). 2252 The GLA also takes administrative actions, which are 2253 beyond the scope of this document, to delete the 2254 member with the GL stored on the GLA. Note that he 2255 GL also needs to be rekeyed as described in section 2256 5. 2258 2.b.2.b.1.b.1 - The GLA applies confidentiality to the response by 2259 encapsulating the SignedData.PKIData in an 2260 EnvelopedData if the request was encapsulated in 2261 an EnvelopedData (see section 3.2.1.2). 2263 2.b.2.b.1.b.2 - The GLA can also optionally apply another 2264 SignedData over the EnvelopedData (see section 2265 3.2.1.2). 2267 2.b.2.b.2 - Else if the GL is managed, the GLA checks that either 2268 a registered GLO or the prospective member signed the 2269 request. For GLOs, one of the names in the certificate 2270 used to sign the request needs to match a registered 2271 GLO. For the prospective member, the name in 2272 glMember.glMemberName needs to match one of the names 2273 in the certificate used to sign the request. 2275 2.b.2.b.2.a - If the signer is neither a registered GLO nor the 2276 prospective GL member, the GLA returns a response 2277 indicating cMCStatusInfoEx with cMCStatus.failed and 2278 otherInfo.extendedFailInfo.SKDFailInfo value of 2279 noSpam. 2281 2.b.2.b.2.b - Else if the signer is a registered GLO, the GLA 2282 returns a cMCStatusInfoEx.cMCStatus.success (2 in 2283 Figure 6). The GLA also takes administrative 2284 actions, which are beyond the scope of this 2286 Turner 45 2287 document, to delete the member with the GL stored on 2288 the GLA. Note that the GL will also be rekeyed as 2289 described in section 5. 2291 2.b.2.b.2.b.1 - The GLA applies confidentiality to the response by 2292 encapsulating the SignedData.PKIData in an 2293 EnvelopedData if the request was encapsulated in 2294 an EnvelopedData (see section 3.2.1.2). 2296 2.b.2.b.2.b.2 - The GLA can also optionally apply another 2297 SignedData over the EnvelopedData (see section 2298 3.2.1.2). 2300 2.b.2.b.2.c - Else if the signer is the prospective member, the 2301 GLA forwards the glDeleteMember request (see section 2302 3.2.3) to the GLO (B{A} in Figure 6). If there is 2303 more than one registered GLO, the GLO to which the 2304 request is forwarded to is beyond the scope of this 2305 document. Further processing of the forwarded 2306 request by GLOs is addressed in 3 of section 4.4.2. 2308 2.b.2.b.2.c.1 - The GLA applies confidentiality to the forwarded 2309 request by encapsulating the SignedData.PKIData in 2310 an EnvelopedData if the request was encapsulated 2311 in an EnvelopedData (see section 3.2.1.2). 2313 2.b.2.b.2.c.2 - The GLA can also optionally apply another 2314 SignedData over the EnvelopedData (see section 2315 3.2.1.2). 2317 2.b.2.b.3 - Else if the GL is unmanaged, the GLA checks that 2318 either a registered GLO or the prospective member 2319 signed the request. For GLOs, one of the names in the 2320 certificate used to sign the request needs to match 2321 the name of a registered GLO. For the prospective 2322 member, the name in glMember.glMemberName needs to 2323 match one of the names in the certificate used to sign 2324 the request. 2326 2.b.2.b.3.a - If the signer is neither the GLO nor the prospective 2327 member, the GLA returns a response indicating 2328 cMCStatusInfoEx with cMCStatus.failed and 2329 otherInfo.extendedFailInfo.SKDFailInfo value of 2330 noSpam. 2332 2.b.2.b.3.b - Else if the signer is either a registered GLO or the 2333 member, the GLA returns a 2334 cMCStatusInfoEx.cMCStatus.success to the GLO (2 in 2335 Figure 6) if the GLO signed the request and to the 2336 GL member (3 in Figure 6) if the GL member signed 2337 the request. The GLA also takes administrative 2338 actions, which are beyond the scope of this 2340 Turner 46 2341 document, to delete the member with the GL stored on 2342 the GLA. 2344 2.b.2.b.3.b.1 - The GLA applies confidentiality to the response by 2345 encapsulating the SignedData.PKIData in an 2346 EnvelopedData if the request was encapsulated in 2347 an EnvelopedData (see section 3.2.1.2). 2349 2.b.2.b.3.b.2 - The GLA can also optionally apply another 2350 SignedData over the EnvelopedData (see section 2351 3.2.1.2). 2353 3 - Upon receipt of the cMCStatusInfoEx response, the GLO verifies 2354 the GLA signatures. If an additional SignedData and/or 2355 EnvelopedData encapsulates the response (see section 3.2.1.2 2356 or 3.2.2), the GLO verifies the outer signature and/or decrypt 2357 the outer layer prior to verifying the signature on the inner 2358 most SignedData. 2360 3.a - If the signatures do verify, the GLO checks that one of the 2361 names in the certificate used to sign the response matches 2362 the name of the GL. 2364 3.a.1 � If the name of the GL does not match the name present in 2365 the certificate used to sign the message, the GLO should 2366 not believe the response. 2368 3.a.2 � Else if the name of the GL matches the name present in the 2369 certificate and: 2371 3.a.2.a - If the signatures verify and the response is 2372 cMCStatusInfoEx.cMCStatus.success, the GLO has deleted 2373 the member from the GL. If member was deleted from a 2374 managed list and the original request was signed by the 2375 member, the GLO sends a 2376 cMCStatusInfoEx.cMCStatus.success to the GL member. 2378 3.a.2.b - Else if the GLO received a 2379 cMCStatusInfoEx.cMCStatus.failed with any reason, the 2380 GLO may reattempt to delete the member from the GL using 2381 the information provided in the response. 2383 4 - Upon receipt of the cMCStatusInfoEx response, the member 2384 verifies the GLA signature(s) or GLO signature(s). If an 2385 additional SignedData and/or EnvelopedData encapsulates the 2386 response (see section 3.2.1.2 or 3.2.2), the GLO verifies the 2387 outer signature and/or decrypt the outer layer prior to 2388 verifying the signature on the inner most SignedData. 2390 4.a - If the signatures verify, the GL member checks that one of 2391 the names in the certificate used to sign the response 2392 matches the name of the GL. 2394 Turner 47 2395 4.a.1 � If the name of the GL does not match the name present in 2396 the certificate used to sign the message, the GL member 2397 should not believe the response. 2399 4.a.2 � Else if the name of the GL matches the name present in the 2400 certificate and: 2402 4.a.2.a - If the signature(s) verify, the member has been deleted 2403 from the GL. 2405 4.a.2.b - Else if the member received a 2406 cMCStatusInfoEx.cMCStatus.failed with any reason, the 2407 member can reattempt to delete themselves from the GL 2408 using the information provided in the response. 2410 4.4.2 Member Initiated Deletions 2412 The process for member initiated deletion of their own membership 2413 using the glDeleteMember requests is as follows: 2415 1 - The member sends a 2416 SignedData.PKIData.controlSequence.glDeleteMember request to 2417 the GLA (A in Figure 6). The member includes: the name of the 2418 GL in glName and their own name in glMemberToDelete. 2420 1.a - The member can optionally apply confidentiality to the 2421 request by encapsulating the SignedData.PKIData in an 2422 EnvelopedData (see section 3.2.1.2). 2424 1.b - The member can also optionally apply another SignedData over 2425 the EnvelopedData (see section 3.2.1.2). 2427 2 - Upon receipt of the request, the GLA verifies the request as 2428 per 2 in section 4.4.1. 2430 3 - Upon receipt of the forwarded request, the GLO verifies the 2431 member signature on the inner most SignedData.PKIData and the 2432 GLA signature on the outer layer. If an EnvelopedData 2433 encapsulates the inner most layer (see section 3.2.1.2 or 2434 3.2.2), the GLO decrypts the outer layer prior to verifying 2435 the signature on the inner most SignedData. 2437 Note: For cases where the GL is closed and either (a) a 2438 prospective member sends directly to the GLO or (b) the GLA 2439 has mistakenly forwarded the request to the GLO, the GLO 2440 should first determine whether to honor the request. 2442 3.a - If the signatures cannot be verified, the GLO returns a 2443 cMCStatusInfoEx response indicating cMCStatus.failed and 2444 otherInfo.failInfo.badMessageCheck. 2446 Turner 48 2447 3.b - Else if the signatures verify, the GLO checks to make sure 2448 one of the names in the certificates used to sign the 2449 request matches the name in glMemberToDelete. 2451 3.b.1 - If the names match, the GLO sends a 2452 SignedData.PKIResponse.controlSequence message back to the 2453 prospective member with cMCStatusInfoEx.cMCtatus.failed 2454 indicating why the prospective member was denied in 2455 cMCStatusInfoEx.statusString. This stops people from 2456 adding people to GLs without their permission. 2458 3.b.2 - Else if the names match, the GLO resubmits the 2459 glDeleteMember request (see section 3.2.5) to the GLA (1 2460 in Figure 6). The GLO makes sure the glMemberName is 2461 already on the GL. The GLO also generates a glRekey 2462 request and include it with the GLDeleteMember request 2463 (see section 4.5). 2465 3.b.2.a - The GLO applies confidentiality to the new 2466 GLDeleteMember request by encapsulating the 2467 SignedData.PKIData in an EnvelopedData if the initial 2468 request was encapsulated in an EnvelopedData (see 2469 section 3.2.1.2). 2471 3.b.2.b - The GLO can also optionally apply another SignedData 2472 over the EnvelopedData (see section 3.2.1.2). 2474 4 - Further processing is as in 2 of section 4.4.1. 2476 4.5 Request Rekey Of GL 2478 From time to time, the GL will need to be rekeyed. Some situations 2479 follow: 2481 - When a member is removed from a closed or managed GL. In this 2482 case, the PKIData.controlSequence containing the glDeleteMember 2483 ought to contain a glRekey request. 2485 - Depending on policy, when a member is removed from an unmanaged 2486 GL. If the policy is to rekey the GL, the 2487 PKIData.controlSequence containing the glDeleteMember could also 2488 contain a glRekey request or an out of bands means could be used 2489 to tell the GLA to rekey the GL. Rekeying of unmanaged GLs when 2490 members are deleted is not advised. 2492 - When the current shared KEK has been compromised. 2494 - When the current shared KEK is about to expire. Consider two 2495 cases: 2497 Turner 49 2498 - If the GLO controls the GL rekey, the GLA should not assume 2499 that a new shared KEK should be distributed, but instead wait 2500 for the glRekey message. 2502 - If the GLA controls the GL rekey, the GLA should initiate a 2503 glKey message as specified in section 5. 2505 If the generationCounter (see section 3.1.1) is set to a value 2506 greater than one (1) and the GLO controls the GL rekey, the GLO may 2507 generate a glRekey any time before the last shared KEK has expired. 2508 To be on the safe side, the GLO ought to request a rekey one (1) 2509 duration before the last shared KEK expires. 2511 The GLA and GLO are the only entities allowed to initiate a GL 2512 rekey. The GLO indicated whether they are going to control rekeys or 2513 whether the GLA is going to control rekeys when they assigned the 2514 shared KEK to GL (see section 3.1.1). The GLO initiates a GL rekey 2515 at any time. The GLA can be configured to automatically rekey the GL 2516 prior to the expiration of the shared KEK (the length of time before 2517 the expiration is an implementation decision). The GLA can also 2518 automatically rekey GLs that have been compromised, but this is 2519 covered in section 5. Figure 7 depicts the protocol interactions to 2520 request a GL rekey. Note that error messages are not depicted. 2522 +-----+ 1 2,A +-----+ 2523 | GLA | <-------> | GLO | 2524 +-----+ +-----+ 2526 Figure 7 - GL Rekey Request 2528 4.5.1 GLO Initiated Rekey Requests 2530 The process for GLO initiated glRekey requests is as follows: 2532 1 - The GLO sends a SignedData.PKIData.controlSequence.glRekey 2533 request to the GLA (1 in Figure 7). The GLO includes the 2534 glName. If glAdministration and glKeyNewAttributes are omitted 2535 then there is no change from the previously registered GL 2536 values for these fields. If the GLO wants to force a rekey for 2537 all outstanding shared KEKs it includes the glRekeyAllGLKeys 2538 set to TRUE. 2540 1.a - The GLO can optionally apply confidentiality to the request 2541 by encapsulating the SignedData.PKIData in an EnvelopedData 2542 (see section 3.2.1.2). 2544 1.b - The GLO can also optionally apply another SignedData over 2545 the EnvelopedData (see section 3.2.1.2). 2547 2 - Upon receipt of the request, the GLA verifies the signature on 2548 the inner most SignedData.PKIData. If an additional SignedData 2550 Turner 50 2551 and/or EnvelopedData encapsulates the request (see section 2552 3.2.1.2 or 3.2.2), the GLA verifies the outer signature and/or 2553 decrypt the outer layer prior to verifying the signature on 2554 the inner most SignedData. 2556 2.a - If the signatures do not verify, the GLA returns a 2557 cMCStatusInfoEx response indicating cMCStatus.failed and 2558 otherInfo.failInfo.badMessageCheck. 2560 2.b - Else if the signatures do verify, the GLA makes sure the GL 2561 is supported by the GLA by checking that the glName matches 2562 a glName stored on the GLA. 2564 2.b.1 - If the glName present does not match a GL stored on the 2565 GLA, the GLA returns a response indicating cMCStatusInfoEx 2566 with cMCStatus.failed and 2567 otherInfo.extendedFailInfo.SKDFailInfo value of 2568 invalidGLName. 2570 2.b.2 - Else if the glName present matches a GL stored on the GLA, 2571 the GLA checks that a registered GLO signed the request by 2572 checking that one of the names in the certificate used to 2573 sign the request is a registered GLO. 2575 2.b.2.a - If the names do not match, the GLA returns a response 2576 indicating cMCStatusInfoEx with cMCStatus.failed and 2577 otherInfo.extendedFailInfo.SKDFailInfo value of 2578 noGLONameMatch. 2580 2.b.2.b - Else if the names match, the GLA checks the 2581 glNewKeyAttribute values. 2583 2.b.2.b.1 - If the new value for requestedAlgorithm is not 2584 supported, the GLA returns a response indicating 2585 cMCStatusInfoEx with cMCStatus.failed and 2586 otherInfo.extendedFailInfo.SKDFailInfo value of 2587 unsupportedAlgorithm. 2589 2.b.2.b.2 - Else if the new value duration is not supportable, 2590 determining this is beyond the scope this document, 2591 the GLA returns a response indicating cMCStatusInfoEx 2592 with cMCStatus.failed and 2593 otherInfo.extendedFailInfo.SKDFailInfo value of 2594 unsupportedDuration. 2596 2.b.2.b.3 - Else if the GL is not supportable for other reasons, 2597 which the GLA does not wish to disclose, the GLA 2598 returns a response indicating cMCStatusInfoEx with 2599 cMCStatus.failed and 2600 otherInfo.extendedFailInfo.SKDFailInfo value of 2601 unspecified. 2603 Turner 51 2604 2.b.2.b.4 - Else if the new requestedAlgorithm and duration are 2605 supportable or the glNewKeyAttributes was omitted, the 2606 GLA returns a cMCStatusInfoEx.cMCStatus.success (2 in 2607 Figure 7). The GLA also uses the glKey message to 2608 distribute the rekey shared KEK (see section 5). 2610 2.b.2.b.4.a - The GLA applies confidentiality to response by 2611 encapsulating the SignedData.PKIData in an 2612 EnvelopedData if the request was encapsulated in an 2613 EnvelopedData (see section 3.2.1.2). 2615 2.b.2.b.4.b - The GLA can also optionally apply another SignedData 2616 over the EnvelopedData (see section 3.2.1.2). 2618 3 - Upon receipt of the cMCStatusInfoEx response, the GLO verifies 2619 the GLA signature(s). If an additional SignedData and/or 2620 EnvelopedData encapsulates the forwarded response (see section 2621 3.2.1.2 or 3.2.2), the GLO verifies the outer signature and/or 2622 decrypt the forwarded response prior to verifying the 2623 signature on the inner most SignedData. 2625 3.a - If the signatures verify, the GLO checks that one of the 2626 names in the certificate used to sign the response matches 2627 the name of the GL. 2629 3.a.1 � If the name of the GL does not match the name present in 2630 the certificate used to sign the message, the GLO should 2631 not believe the response. 2633 3.a.2 � Else if the name of the GL matches the name present in the 2634 certificate and: 2636 3.a.2.a - If the signatures verify and the response is 2637 cMCStatusInfoEx.cMCStatus.success, the GLO has 2638 successfully rekeyed the GL. 2640 3.a.2.b � Else if the GLO received a 2641 cMCStatusInfoEx.cMCStatus.failed with any reason, the 2642 GLO can reattempt to rekey the GL using the information 2643 provided in the response. 2645 Turner 52 2646 4.5.2 GLA Initiated Rekey Requests 2648 If the GLA is in charge of rekeying the GL the GLA will 2649 automatically issue a glKey message (see section 5). In addition the 2650 GLA will generate a cMCStatusInfoEx to indicate to the GL that a 2651 successful rekey has occurred. The process for GLA initiated rekey 2652 is as follows: 2654 1 - The GLA generates for all GLOs a 2655 SignedData.PKIData.controlSequence.cMCStatusInfoEx.cMCStatus.s 2656 uccess (A in Figure 7). 2658 1.a - The GLA can optionally apply confidentiality to the request 2659 by encapsulating the SignedData.PKIData in an EnvelopedData 2660 (see section 3.2.1.2). 2662 1.b - The GLA can also optionally apply another SignedData over 2663 the EnvelopedData (see section 3.2.1.2). 2665 2 - Upon receipt of the cMCStatusInfoEx.cMCStatus.success 2666 response, the GLO verifies the GLA signature(s). If an 2667 additional SignedData and/or EnvelopedData encapsulates the 2668 forwarded response (see section 3.2.1.2 or 3.2.2), the GLO 2669 MUST verify the outer signature and/or decrypt the outer layer 2670 prior to verifying the signature on the inner most SignedData. 2672 2.a - If the signatures verify, the GLO checks that one of the 2673 names in the certificate used to sign the response matches 2674 the name of the GL. 2676 2.a.1 � If the name of the GL does not match the name present in 2677 the certificate used to sign the message, the GLO ought 2678 not believe the response. 2680 2.a.2 � Else if the name of the GL does match the name present in 2681 the certificate and and the response is 2682 cMCStatusInfoEx.cMCStatus.success, the GLO knows the GLA 2683 has successfully rekeyed the GL. 2685 4.6 Change GLO 2687 Management of managed and closed GLs can become difficult for one 2688 GLO if the GL membership grows large. To support distributing the 2689 workload, GLAs support having GLs be managed by multiple GLOs. The 2690 glAddOwner and glRemoveOwner messages are designed to support adding 2691 and removing registered GLOs. Figure 8 depicts the protocol 2692 interactions to send glAddOwner and glRemoveOwner messages and the 2693 resulting response messages. 2695 Turner 53 2696 +-----+ 1 2 +-----+ 2697 | GLA | <-------> | GLO | 2698 +-----+ +-----+ 2700 Figure 8 - GLO Add & Delete Owners 2702 The process for glAddOwner and glDeleteOwner is as follows: 2704 1 - The GLO sends a SignedData.PKIData.controlSequence.glAddOwner 2705 or glRemoveOwner request to the GLA (1 in Figure 8). The GLO 2706 includes: the GL name in glName, the name and address of the 2707 GLO in glOwnerName and glOwnerAddress, respectively. 2709 1.a - The GLO can optionally apply confidentiality to the request 2710 by encapsulating the SignedData.PKIData in an EnvelopedData 2711 (see section 3.2.1.2). 2713 1.b - The GLO can also optionally apply another SignedData over 2714 the EnvelopedData (see section 3.2.1.2). 2716 2 - Upon receipt of the glAddOwner or glRemoveOwner request, the 2717 GLA verifies the GLO signature(s). If an additional SignedData 2718 and/or EnvelopedData encapsulates the request (see section 2719 3.2.1.2 or 3.2.2), the GLA verifies the outer signature and/or 2720 decrypt the outer layer prior to verifying the signature on 2721 the inner most SignedData. 2723 2.a - If the signatures cannot verified, the GLA returns a 2724 cMCStatusInfoEx response indicating cMCStatus.failed and 2725 otherInfo.failInfo.badMessageCheck. 2727 2.b - Else if the signatures verify, the GLA makes sure the GL is 2728 supported by checking that the glName matches a glName 2729 stored on the GLA. 2731 2.b.1 - If the glName is not supported by the GLA, the GLA returns 2732 a response indicating cMCStatusInfoEx with 2733 cMCStatus.failed and 2734 otherInfo.extendedFailInfo.SKDFailInfo value of 2735 invalidGLName. 2737 2.b.2 - Else if the glName is supported by the GLA, the GLA 2738 ensures a registered GLO signed the glAddOwner or 2739 glRemoveOwner request by checking that one of the names 2740 present in the digital signature certificate used to sign 2741 the glAddOwner or glDeleteOwner request matches the name 2742 of a registered GLO. 2744 2.b.2.a - If the names do not match, the GLA returns a response 2745 indicating cMCStatusInfoEx with cMCStatus.failed and 2746 otherInfo.extendedFailInfo.SKDFailInfo value of 2747 noGLONameMatch. 2749 Turner 54 2750 2.b.2.b - Else if the names match, the GLA returns a 2751 cMCStatusInfoEx.cMCStatus.success (2 in Figure 4). The 2752 GLA also takes administrative actions to associate the 2753 new glOwnerName with the GL in the case of glAddOwner or 2754 to disassociate the old glOwnerName with the GL in the 2755 cased of glRemoveOwner. 2757 2.b.2.b.1 - The GLA applies confidentiality to the response by 2758 encapsulating the SignedData.PKIResponse in an 2759 EnvelopedData if the request was encapsulated in an 2760 EnvelopedData (see section 3.2.1.2). 2762 2.b.2.b.2 - The GLA can also optionally apply another SignedData 2763 over the EnvelopedData (see section 3.2.1.2). 2765 3 - Upon receipt of the cMCStatusInfoEx response, the GLO verifies 2766 the GLA's signature(s). If an additional SignedData and/or 2767 EnvelopedData encapsulates the response (see section 3.2.1.2 2768 or 3.2.2), the GLO verifies the outer signature and/or decrypt 2769 the outer layer prior to verifying the signature on the inner 2770 most SignedData. 2772 3.a - If the signatures verify, the GLO checks that one of the 2773 names in the certificate used to sign the response matches 2774 the name of the GL. 2776 3.a.1 � If the name of GL does not match the name present in the 2777 certificate used to sign the message, the GLO should not 2778 believe the response. 2780 3.a.2 � Else if the name of the GL does match the name present in 2781 the certificate and: 2783 3.a.2.a - If the signatures verify and the response was 2784 cMCStatusInfoEx.cMCStatus.success, the GLO has 2785 successfully added or removed the GLO. 2787 3.a.2.b - Else if the signatures verify and the response was 2788 cMCStatusInfoEx.cMCStatus.failed with any reason, the 2789 GLO can reattempt to add or delete the GLO using the 2790 information provided in the response. 2792 4.7 Indicate KEK Compromise 2794 There will be times when the shared KEK is compromised. GL members 2795 and GLOs use glkCompromise to tell the GLA that the shared KEK has 2796 been compromised. Figure 9 depicts the protocol interactions for GL 2797 Key Compromise. 2799 Turner 55 2800 +-----+ 2{1} 4 +----------+ 2801 | GLO | <----------+ +-------> | Member 1 | 2802 +-----+ 5,3{1} | | +----------+ 2803 +-----+ <----------+ | 4 +----------+ 2804 | GLA | 1 +-------> | ... | 2805 +-----+ <---------------+ +----------+ 2806 | 4 +----------+ 2807 +-------> | Member n | 2808 +----------+ 2810 Figure 9 - GL Key Compromise 2812 4.7.1 GL Member Initiated KEK Compromise Message 2814 The process for GL member initiated glkCompromise messages is as 2815 follows: 2817 1 - The GL member sends a 2818 SignedData.PKIData.controlSequence.glkCompromise request to 2819 the GLA (1 in Figure 9). The GL member includes the name of 2820 the GL in GeneralName. 2822 1.a - The GL member can optionally apply confidentiality to the 2823 request by encapsulating the SignedData.PKIData in an 2824 EnvelopedData (see section 3.2.1.2). The glkCompromise can 2825 be included in an EnvelopedData generated with the 2826 compromised shared KEK. 2828 1.b - The GL member can also optionally apply another SignedData 2829 over the EnvelopedData (see section 3.2.1.2). 2831 2 - Upon receipt of the glkCompromise request, the GLA verifies 2832 the GL member signature(s). If an additional SignedData and/or 2833 EnvelopedData encapsulates the request (see section 3.2.1.2 or 2834 3.2.2), the GLA verifies the outer signature and/or decrypt 2835 the outer layer prior to verifying the signature on the inner 2836 most SignedData. 2838 2.a - If the signatures cannotbe verified, the GLA returns a 2839 cMCStatusInfoEx response indicating cMCStatus.failed and 2840 otherInfo.failInfo.badMessageCheck. 2842 2.b - Else if the signatures verify, the GLA makes sure the GL is 2843 supported by checking that the indicated GL name matches a 2844 glName stored on the GLA. 2846 2.b.1 - If the glName is not supported by the GLA, the GLA returns 2847 a response indicating cMCStatusInfoEx with 2848 cMCStatus.failed and 2849 otherInfo.extendedFailInfo.SKDFailInfo value of 2850 invalidGLName. 2852 Turner 56 2853 2.b.2 - Else if the glName is supported by the GLA, the GLA checks 2854 who signed the request. For GLOs, one of the names in the 2855 certificate used to sign the request needs to match a 2856 registered GLO. For the member, the name in 2857 glMember.glMemberName needs to match one of the names in 2858 the certificate used to sign the request. 2860 2.b.2.a - If the GLO signed the request, the GLA generates a glKey 2861 message as described in section 5 to rekey the GL (4 in 2862 Figure 9). 2864 2.b.2.b - Else if someone other than the GLO signed the request, 2865 the GLA forwards the glkCompromise message (see section 2866 3.2.3) to the GLO (2{1} in Figure 9). If there is more 2867 than one GLO, to which GLO the request is forwarded is 2868 beyond the scope of this document. Further processing by 2869 the GLO is discussed in section 4.7.2. 2871 4.7.2 GLO Initiated KEK Compromise Message 2873 The process for GLO initiated glkCompromise messages is as follows: 2875 1 - The GLO either: 2877 1.a - Generates the glkCompromise message itself by sending a 2878 SignedData.PKIData.controlSequence.glkCompromise request to 2879 the GLA (5 in Figure 9). The GLO includes the name of the GL 2880 in GeneralName. 2882 1.a.1 - The GLO can optionally apply confidentiality to the 2883 request by encapsulating the SignedData.PKIData in an 2884 EnvelopedData (see section 3.2.1.2). The glkCompromise can 2885 be included in an EnvelopedData generated with the 2886 compromised shared KEK. 2888 1.a.2 - The GLO can also optionally apply another SignedData over 2889 the EnvelopedData (see section 3.2.1.2). 2891 1.b � Otherwise, verifies the GLA and GL member signatures on the 2892 forwarded glkCompromise message. If an additional SignedData 2893 and/or EnvelopedData encapsulates the request (see section 2894 3.2.1.2 or 3.2.2), the GLO verifies the outer signature 2895 and/or decrypt the outer layer prior to verifying the 2896 signature on the inner most SignedData. 2898 1.b.1 - If the signatures cannot be verified, the GLO returns a 2899 cMCStatusInfoEx response indicating cMCStatus.failed and 2900 otherInfo.failInfo.badMessageCheck. 2902 1.b.1.a - If the signatures verify, the GLO checks the names in 2903 the certificate match the name of the signer (i.e., the 2905 Turner 57 2906 name in the certificate used to sign the GL member�s 2907 request is the GL member). 2909 1.b.1.a.1 � If either name does not match, the GLO ought not trust 2910 the signer and it ought not forward the message to the 2911 GLA. 2913 1.b.1.a.2 � Else if the names match and the signatures verify, the 2914 GLO determines whether to forward the glkCompromise 2915 message back to the GLA (3{1} in Figure 9). Further 2916 processing by the GLA is in 2 of section 4.7.1. The 2917 GLO can also return a response to the prospective 2918 member with cMCStatusInfoEx.cMCtatus.success 2919 indicating that the glkCompromise message was 2920 successfully received. 2922 4.8 Request KEK Refresh 2924 There will be times when GL members have unrecoverably lost their 2925 shared KEK. The shared KEK is not compromised and a rekey of the 2926 entire GL is not necessary. GL members use the glkRefresh message to 2927 request that the shared KEK(s) be redistributed to them. Figure 10 2928 depicts the protocol interactions for GL Key Refresh. 2930 +-----+ 1 2 +----------+ 2931 | GLA | <-----------> | Member | 2932 +-----+ +----------+ 2934 Figure 10 - GL KEK Refresh 2936 The process for glkRefresh is as follows: 2938 1 - The GL member sends a 2939 SignedData.PKIData.controlSequence.glkRefresh request to the 2940 GLA (1 in Figure 10). The GL member includes name of the GL in 2941 GeneralName. 2943 1.a - The GL member can optionally apply confidentiality to the 2944 request by encapsulating the SignedData.PKIData in an 2945 EnvelopedData (see section 3.2.1.2). 2947 1.b - The GL member can also optionally apply another SignedData 2948 over the EnvelopedData (see section 3.2.1.2). 2950 2 - Upon receipt of the glkRefresh request, the GLA verifies the 2951 GL member signature(s). If an additional SignedData and/or 2952 EnvelopedData encapsulates the request (see section 3.2.1.2 or 2953 3.2.2), the GLA verifies the outer signature and/or decrypt 2954 the outer layer prior to verifying the signature on the inner 2955 most SignedData. 2957 Turner 58 2958 2.a - If the signatures cannot be verified, the GLA returns a 2959 cMCStatusInfoEx response indicating cMCStatus.failed and 2960 otherInfo.failInfo.badMessageCheck. 2962 2.b - Else if the signatures verify, the GLA makes sure the GL is 2963 supported by checking that the GLGeneralName matches a 2964 glName stored on the GLA. 2966 2.b.1 - If the name of the GL is not supported by the GLA, the GLA 2967 returns a response indicating cMCStatusInfoEx with 2968 cMCStatus.failed and 2969 otherInfo.extendedFailInfo.SKDFailInfo value of 2970 invalidGLName. 2972 2.b.2 � Else if the glName is supported by the GLA, the GLA 2973 ensures the GL member is on the GL. 2975 2.b.2.a - If the glMemberName is not present on the GL, the GLA 2976 returns a response indicating cMCStatusInfoEx with 2977 cMCStatus.failed and 2978 otherInfo.extendedFailInfo.SKDFailInfo value of noSpam. 2980 2.b.2.b - Else if the glMemberName is present on the GL, the GLA 2981 returns a cMCStatusInfoEx.cMCStatus.success and a glKey 2982 message (2 in Figure 10) as described in section 5. 2984 4.9 GLA Query Request and Response 2986 There will be certain times when a GLO is having trouble setting up 2987 a GL because they do not know the algorithm(s) or some other 2988 characteristic that the GLA supports. There can also be times when 2989 prospective GL members or GL members need to know something about 2990 the GLA (these requests are not defined in the document). The 2991 glaQueryRequest and glaQueryResponse message have been defined to 2992 support determining this information. Figure 11 depicts the protocol 2993 interactions for glaQueryRequest and glaQueryResponse. 2995 +-----+ 1 2 +------------------+ 2996 | GLA | <-------> | GLO or GL Member | 2997 +-----+ +------------------+ 2999 Figure 11 - GLA Query Request & Response 3001 The process for glaQueryRequest and glaQueryResponse is as follows: 3003 1 - The GLO, GL member, or prospective GL member sends a 3004 SignedData.PKIData.controlSequence.glaQueryRequest request to 3005 the GLA (1 in Figure 11). The GLO, GL member, or prospective 3007 Turner 59 3008 GL member indicates the information they are interested in 3009 receiving from the GLA. 3011 1.a - The GLO, GL member, or prospective GL member can optionally 3012 apply confidentiality to the request by encapsulating the 3013 SignedData.PKIData in an EnvelopedData (see section 3014 3.2.1.2). 3016 1.b - The GLO, GL member, or prospective GL member can also 3017 optionally apply another SignedData over the EnvelopedData 3018 (see section 3.2.1.2). 3020 2 - Upon receipt of the glaQueryRequest, the GLA determines if it 3021 accepts glaQueryRequest messages. 3023 2.a - If the GLA does not accept glaQueryRequest messages, the GLA 3024 returns a cMCStatusInfoEx response indicating 3025 cMCStatus.noSupport and any other information in 3026 statusString. 3028 2.b - Else if the GLA does accept GLAQueryRequests, the GLA 3029 verifies the GLO, GL member, or prospective GL member 3030 signature(s). If an additional SignedData and/or 3031 EnvelopedData encapsulates the request (see section 3.2.1.2 3032 or 3.2.2), the GLA verifies the outer signature and/or 3033 decrypt the outer layer prior to verifying the signature on 3034 the inner most SignedData. 3036 2.b.1 - If the signatures cannot be verified, the GLA returns a 3037 cMCStatusInfoEx response indicating cMCStatus.failed and 3038 otherInfo.failInfo.badMessageCheck. 3040 2.b.2 - Else if the signatures verify, the GLA returns a 3041 glaQueryResponse (2 in Figure 11) with the correct 3042 response if the glaRequestType is supported or return a 3043 cMCStatusInfoEx response indicating cMCStatus.noSupport if 3044 the glaRequestType is not supported. 3046 2.b.2.a - The GLA applies confidentiality to the response by 3047 encapsulating the SignedData.PKIResponse in an 3048 EnvelopedData if the request was encapsulated in an 3049 EnvelopedData (see section 3.2.1.2). 3051 2.b.2.b - The GLA can also optionally apply another SignedData 3052 over the EnvelopedData (see section 3.2.1.2). 3054 3 - Upon receipt of the glaQueryResponse, the GLO, GL member, or 3055 prospective GL member verifies the GLA signature(s). If an 3056 additional SignedData and/or EnvelopedData encapsulates the 3057 response (see section 3.2.1.2 or 3.2.2), the GLO, GL member, 3058 or prospective GL member verifies the outer signature and/or 3060 Turner 60 3061 decrypt the outer layer prior to verifying the signature on 3062 the inner most SignedData. 3064 3.a - If the signatures do not verify, the GLO, GL member, or 3065 prospective GL member returns a cMCStatusInfoEx response 3066 indicating cMCStatus.failed and 3067 otherInfo.failInfo.badMessageCheck. 3069 3.b - Else if the signatures verify, then the GLO, GL member, or 3070 prospective GL member checks that one of the names in the 3071 certificate used to sign the response matches the name of 3072 the GL. 3074 3.b.1 � If the name of the GL does not match the name present in 3075 the certificate used to sign the message, the GLO ought 3076 not believe the response. 3078 3.b.2 - Else if the name of the GL matches the name present in the 3079 certificate and the response was glaQueryResponse, then 3080 the GLO, GL member, or prospective GL member may use the 3081 information contained therein. 3083 4.10 Update Member Certificate 3085 When the GLO generates a glAddMember request, when the GLA generates 3086 a glKey message, or when the GLA processes a glAddMember there can 3087 be instances when GL member�s certificate has expired or is invalid. 3088 In these instances the GLO or GLA may request that the GL member 3089 provide a new certificate to avoid the GLA from being unable to 3090 generate a glKey message for the GL member. There might also be 3091 times when the GL member knows their certificate is about to expire 3092 or has been revoked and they will not be able to receive GL rekeys. 3094 4.10.1 GLO and GLA Initiated Update Member Certificate 3096 The process for GLO initiated glUpdateCert is as follows: 3098 1 - The GLO or GLA sends a 3099 SignedData.PKIData.controlSequence.glProvideCert request to 3100 the GL member. The GLO or GLA indicates the GL name in glName 3101 and the GL member name in glMemberName. 3103 1.a - The GLO or GLA can optionally apply confidentiality to the 3104 request by encapsulating the SignedData.PKIData in an 3105 EnvelopedData (see section 3.2.1.2). If the GL member�s PKC 3106 has been revoked, the GLO or GLA ought not use it to 3107 generate the EnvelopedData that encapsulates the 3108 glProvideCert request. 3110 1.b - The GLO or GLA can also optionally apply another SignedData 3111 over the EnvelopedData (see section 3.2.1.2). 3113 Turner 61 3114 2 - Upon receipt of the glProvideCert message, the GL member 3115 verifies the GLO or GLA signature(s). If an additional 3116 SignedData and/or EnvelopedData encapsulates the response (see 3117 section 3.2.1.2 or 3.2.2), the GL member verifies the outer 3118 signature and/or decrypt the outer layer prior to verifying 3119 the signature on the inner most SignedData. 3121 2.a - If the signatures cannot be verified, the GL member returns 3122 a cMCStatusInfoEx response indicating cMCStatus.failed and 3123 otherInfo.failInfo.badMessageCheck. 3125 2.b - Else if the signatures verify, the GL member generates a 3126 Signed.PKIResponse.controlSequence.glUpdateCert that 3127 includes the GL name in glName, the member name in 3128 glMember.glMemberName, their encryption certificate in 3129 glMember.certificates.pKC. The GL member can also include 3130 any attribute certificates associated with their encryption 3131 certificate in glMember.certificates.aC, and the 3132 certification path associated with their encryption and 3133 attribute certificates in glMember.certificates.certPath. 3135 2.a - The GL member can optionally apply confidentiality to the 3136 request by encapsulating the SignedData.PKIResponse in an 3137 EnvelopedData (see section 3.2.1.2). If the GL member�s PKC 3138 has been revoked, the GL member ought not use it to generate 3139 the EnvelopedData that encapsulates the glProvideCert 3140 request. 3142 2.b - The GL member can also optionally apply another SignedData 3143 over the EnvelopedData (see section 3.2.1.2). 3145 3 - Upon receipt of the glUpdateCert message, the GLO or GLA 3146 verifies the GL member signature(s). If an additional 3147 SignedData and/or EnvelopedData encapsulates the response (see 3148 section 3.2.1.2 or 3.2.2), the GL member verifies the outer 3149 signature and/or decrypt the outer layer prior to verifying 3150 the signature on the inner most SignedData. 3152 3.a - If the signatures cannot be verified, the GLO or GLA returns 3153 a cMCStatusInfoEx response indicating cMCStatus.failed and 3154 otherInfo.failInfo.badMessageCheck. 3156 3.b - Else if the signatures verify, the GLO or GLA verifies the 3157 member�s encryption certificate. 3159 3.b.1 - If the member�s encryption certificate cannot be verified, 3160 the GLO returns either another glProvideCert request or a 3161 cMCStatusInfoEx with cMCStatus.failed and the reason why 3162 in cMCStatus.statusString. glProvideCert should be 3163 returned only a certain number of times because if the GL 3165 Turner 62 3166 member does not have a valid certificate they will never 3167 be able to return one. 3169 3.b.2 - Else if the member�s encryption certificate cannot be 3170 verified, the GLA returns another glProvideCert request to 3171 the GL member or a cMCStatusInfoEx with cMCStatus.failed 3172 and the reason why in cMCStatus.statusString to the GLO. 3173 glProvideCert should be returned only a certain number of 3174 times because if the GL member does not have a valid 3175 certificate they will never be able to return one. 3177 3.b.3 - Else if the member�s encryption certificate verifies, the 3178 GLO or GLA will use it in subsequent glAddMember requests 3179 and glKey messages associated with the GL member. 3181 4.10.2 GL Member Initiated Update Member Certificate 3183 The process for an unsolicited GL member glUpdateCert is as follows: 3185 1 - The GL member sends a 3186 Signed.PKIData.controlSequence.glUpdateCert that includes the 3187 GL name in glName, the member name in glMember.glMemberName, 3188 their encryption certificate in glMember.certificates.pKC. The 3189 GL member can also include any attribute certificates 3190 associated with their encryption certificate in 3191 glMember.certificates.aC, and the certification path 3192 associated with their encryption and attribute certificates in 3193 glMember.certificates.certPath. 3195 1.a - The GL member can optionally apply confidentiality to the 3196 request by encapsulating the SignedData.PKIData in an 3197 EnvelopedData (see section 3.2.1.2). If the GL member�s PKC 3198 has been revoked, the GLO or GLA ought not use it to 3199 generate the EnvelopedData that encapsulates the 3200 glProvideCert request. 3202 1.b - The GL member can also optionally apply another SignedData 3203 over the EnvelopedData (see section 3.2.1.2). 3205 2 - Upon receipt of the glUpdateCert message, the GLA verifies the 3206 GL member signature(s). If an additional SignedData and/or 3207 EnvelopedData encapsulates the response (see section 3.2.1.2 3208 or 3.2.2), the GLA verifies the outer signature and/or decrypt 3209 the outer layer prior to verifying the signature on the inner 3210 most SignedData. 3212 2.a - If the signatures cannot be verified, the GLA returns a 3213 cMCStatusInfoEx response indicating cMCStatus.failed and 3214 otherInfo.failInfo.badMessageCheck. 3216 Turner 63 3217 2.b - Else if the signatures verify, the GLA verifies the member�s 3218 encryption certificate. 3220 2.b.1 - If the member�s encryption certificate cannot be verified, 3221 the GLA returns another glProvideCert request to the GL 3222 member or a cMCStatusInfoEx with cMCStatus.failed and the 3223 reason why in cMCStatus.statusString to the GLO. 3224 glProvideCert ought not be returned indefinitely; if the 3225 GL member does not have a valid certificate they will 3226 never be able to return one. 3228 2.b.2 - Else if the member�s encryption certificate verifies, the 3229 GLA will use it in subsequent glAddMember requests and 3230 glKey messages associated with the GL member. The GLA also 3231 forwards the glUpdateCert message to the GLO. 3233 5 Distribution Message 3235 The GLA uses the glKey message to distribute new, shared KEK(s) 3236 after receiving glAddMember, glDeleteMember (for closed and managed 3237 GLs), glRekey, glkCompromise, or glkRefresh requests and returning a 3238 cMCStatusInfoEx response for the respective request. Figure 12 3239 depicts the protocol interactions to send out glKey messages. Unlike 3240 the procedures defined for the administrative messages, the 3241 procedures defined in this section MUST be implemented by GLAs for 3242 origination and by GL members on reception. 3244 1 +----------+ 3245 +-------> | Member 1 | 3246 | +----------+ 3247 +-----+ | 1 +----------+ 3248 | GLA | ----+-------> | ... | 3249 +-----+ | +----------+ 3250 | 1 +----------+ 3251 +-------> | Member n | 3252 +----------+ 3254 Figure 12 - GL Key Distribution 3256 If the GL was setup with GLKeyAttributes.recipientsNotMutuallyAware 3257 set to FALSE, a separate glKey message MUST be sent to each GL 3258 member so as to not divulge information about the other GL members. 3260 Turner 64 3261 When the glKey message is generated as a result of a: 3263 - glAddMember request, 3264 - glkComrpomise indication, 3265 - glkRefresh request, 3266 - glDeleteMember request with the GL�s glAdministration set to 3267 managed or closed, and 3268 - glRekey request with generationCounter set to zero (0). 3270 The GLA MUST use either the kari (see section 12.3.2 of CMS [2]) or 3271 ktri (see section 12.3.1 of CMS [2]) choice in 3272 glKey.glkWrapped.RecipientInfo to ensure only the intended 3273 recipients receive the shared KEK. The GLA MUST support the ktri 3274 choice. 3276 When the glKey message is generated as a result of a glRekey request 3277 with generationCounter greater than zero (0) or when the GLA 3278 controls rekeys, the GLA MAY use the kari, ktri, or kekri (see 3279 section 12.3.3 of CMS [2]) in glKey.glkWrapped.RecipientInfo to 3280 ensure only the intended recipients receive the shared KEK. The GLA 3281 MUST support the RecipientInfo.ktri choice. 3283 5.1 Distribution Process 3285 When a glKey message is generated the process is as follows: 3287 1 - The GLA MUST send a SignedData.PKIData.controlSequence.glKey 3288 to each member by including: glName, glIdentifier, glkWrapped, 3289 glkAlgorithm, glkNotBefore, and glkNotAfter. If the GLA can 3290 not generate a glKey message for the GL member because the GL 3291 member�s PKC has expired or is otherwise invalid, the GLA MAY 3292 send a glUpdateCert to the GL member requesting a new 3293 certificate be provided (see section 4.10). The number of 3294 glKey messages generated for the GL is described in section 3295 3.1.16. 3297 1.a - The GLA MAY optionally apply another confidentiality layer 3298 to the message by encapsulating the SignedData.PKIData in 3299 another EnvelopedData (see section 3.2.1.2). 3301 1.b - The GLA MAY also optionally apply another SignedData over 3302 the EnvelopedData.SignedData.PKIData (see section 3.2.1.2). 3304 2 - Upon receipt of the glKey message, the GL members MUST verify 3305 the signature over the inner most SignedData.PKIData. If an 3306 additional SignedData and/or EnvelopedData encapsulates the 3307 message (see section 3.2.1.2 or 3.2.2), the GL Member MUST 3308 verify the outer signature and/or decrypt the outer layer 3309 prior to verifying the signature on the 3310 SignedData.PKIData.controlSequence.glKey. 3312 Turner 65 3313 2.a - If the signatures cannot be verified, the GL member MUST 3314 return a cMCStatusInfoEx response indicating 3315 cMCStatus.failed and otherInfo.failInfo.badMessageCheck. 3317 2.b - Else if the signatures verify, the GL member process the 3318 RecipientInfos according to CMS [2]. Once unwrapped the GL 3319 member should store the shared KEK in a safe place. When 3320 stored, the glName, glIdentifier, and shared KEK should be 3321 associated. Additionally, the GL member MUST return a 3322 cMCStatusInfoEx indicating cMCStatus.success to tell the GLA 3323 the KEK was received. 3325 6 Algorithms 3327 This section lists the algorithms that MUST be implemented. 3328 Additional algorithms that SHOULD be implemented are also included. 3329 Further algorithms MAY also be implemented. 3331 6.1 KEK Generation Algorithm 3333 Implementations MUST randomly generate content-encryption keys, 3334 message-authentication keys, initialization vectors (IVs), and 3335 padding. Also, the generation of public/private key pairs relies on 3336 a random numbers. The use of inadequate pseudo-random number 3337 generators (PRNGs) to generate cryptographic keys can result in 3338 little or no security. An attacker may find it much easier to 3339 reproduce the PRNG environment that produced the keys, searching the 3340 resulting small set of possibilities, rather than brute force 3341 searching the whole key space. The generation of quality random 3342 numbers is difficult. RFC 1750 [10] offers important guidance in 3343 this area, and Appendix 3 of FIPS Pub 186 [11] provides one quality 3344 PRNG technique. 3346 6.2 Shared KEK Wrap Algorithm 3348 In the mechanisms described in sections 5, the shared KEK being 3349 distributed in glkWrapped MUST be protected by a key of equal or 3350 greater length (i.e., if a RC2 128-bit key is being distributed a 3351 key of 128-bits or greater must be used to protect the key). 3353 The algorithm object identifiers included in glkWrapped are as 3354 specified in AlgSpec [12]. 3356 6.3 Shared KEK Algorithm 3358 The shared KEK distributed and indicated in glkAlgorithm MUST 3359 support the symmetric key-encryption algorithms as specified in 3360 section AlgSpec [12]. 3362 Turner 66 3363 7 Message Transport 3365 SMTP [13] MUST be supported. Other transport mechanisms MAY also be 3366 supported. 3368 8 Security Considerations 3370 As GLOs control setting up and tearing down the GL, rekeying the GL, 3371 and can control member additions and deletions, GLOs play an 3372 important role in the management of the GL, and only �trusted� GLOs 3373 should be used. 3375 If a member is deleted or removed from a closed or a managed GL, the 3376 GL needs to be rekeyed. If the GL is not rekeyed after a member is 3377 removed or deleted, the member still posses the group key and will 3378 be able to continue to decrypt any messages that can be obtained. 3380 Members who store KEKs MUST associate the name of the GLA that 3381 distributed the key so that the members can make sure subsequent 3382 rekeys are originated from the same entity. 3384 When generating keys, care should be taken to ensure that the key 3385 size is not too small and duration too long because people will have 3386 more time to attack the key. Key size should be selected to 3387 adequately protect sensitive business communications. 3389 GLOs and GLAs need to make sure that the generationCounter and 3390 duration are not too large. For example, if the GLO indicates that 3391 the generationCounter is 14 and the duration is one year, then 14 3392 keys are generated each with a validity period of a year. An 3393 attacker will have at least 13 years to attack the final key. 3395 Assume that two or more parties have a shared KEK, and the shared 3396 KEK is used to encrypt a second KEK for confidential distribution to 3397 those parties. The second KEK might be used to encrypt a third KEK; 3398 the third KEK might be used to encrypt a fourth KEK; and so on. If 3399 any of the KEKs in such a chain is compromised, all of the 3400 subsequent KEKs in the chain MUST also be considered compromised. 3402 9 References 3404 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 3405 9, RFC 2026, October 1996. 3407 2 Housley, R., "Cryptographic Message Syntax," draft-ietf-smime- 3408 rfc2630bis-01.txt, April 2001. 3410 Turner 67 3411 3 Myers, M., Liu, X., Schaad, J., Weinsten, J., "Certificate 3412 Management Message over CMS," draft-ietf-pkix-2797-bis-00.txt, 3413 April 2001. 3415 4 Bradner, S., "Key words for use in RFCs to Indicate Requirement 3416 Levels", BCP 14, RFC 2119, March 1997. 3418 5 Housley, R., Ford, W., Polk, W. and D. Solo, "Internet X.509 3419 Public Key Infrastructure: Certificate and CRL Profile", draft- 3420 ietf-pkix-new-part1-06.txt, 8 March 2001. 3422 6 Farrell, S., Housley, R., �An Internet Attribute Certificate 3423 Profile for Authorization�, draft-ietf-pkix-acx.509prof-06.txt, 3424 10 January 2001. 3426 7 Ramsdale, B., "S/MIME Version 3 Message Specification," TBD. 3428 8 Hoffman, P., and C. Bonatti, �Transporting S/MIME Objects in 3429 X.400�, draft-ietf-smime-x400transport-02.txt, May 2000. 3431 9 Hoffman, P., �Extended Security Services for S/MIME�, RFC 2634, 3432 June 1999. 3434 10 Eastlake, D., Crocker, S. and J. Schiller, "Randomness 3435 Recommendations for Security", RFC 1750, December 1994. 3437 11 National Institute of Standards and Technology. FIPS Pub 186: 3438 Digital Signature Standard. 19 May 1994. 3440 12 Housley, R., �Cryptographic Message Syntax (CMS) Algorithms�, 3441 draft-ietf-smime-cmsalg-01.txt, July 2001. 3443 13 Postel, j., "Simple Mail Transport Protocol," RFC 821, August 3444 1982. 3446 10 Acknowledgements 3448 Thanks to Russ Housley and Jim Schaad for providing much of the 3449 background and review required to write this document. 3451 Turner 68 3452 11 Author's Addresses 3454 Sean Turner 3455 IECA, Inc. 3456 9010 Edgepark Road 3457 Vienna, VA 22182 3458 Phone: +1.703.628.3180 3459 Email: turners@ieca.com 3461 Turner 69 3462 Annex A: ASN.1 Module 3464 SMIMESymmetricKeyDistribution 3465 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 3466 smime(16) modules(0) symkeydist(12) } 3468 DEFINITIONS IMPLICIT TAGS ::= 3469 BEGIN 3471 -- EXPORTS All -- 3472 -- The types and values defined in this module are exported for use 3473 -- in the other ASN.1 modules. Other applications may use them for 3474 -- their own purposes. 3476 IMPORTS 3478 -- PKIX Part 1 - Implicit 3479 GeneralName 3480 FROM PKIX1Implicit88 {iso(1) identified-organization(3) dod(6) 3481 internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) 3482 id-pkix1-implicit(19)} 3484 -- PKIX Part 1 - Explicit 3485 AlgorithmIdentifier, Certificate 3486 FROM PKIX1Explicit88 { iso(1) identified-organization(3) dod(6) 3487 internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) 3488 id-pkix1-explicit(18) } 3490 -- Cryptographic Message Syntax 3491 RecipientInfos, id-alg-CMS3DESwrap, KEKIdentifier, 3492 CertificateSet 3493 FROM CryptographicMessageSyntax {iso(1) member-body(2) us(840) 3494 rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) modules(0) 3495 cms-2001(14)} 3497 -- Attribute Certificate Profile 3498 AttributeCertificate FROM 3499 PKIXAttributeCertificate { iso(1) identified-organization(3) 3500 dod(6) internet(1) security(5) mechanisms(5) pkix(7) 3501 id-mod(0) id-mod-attribute-cert(12)}; 3503 -- This defines the GL symmetric key distribution object identifier 3504 -- arc. 3506 id-skd OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) 3507 rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) skd(8) } 3509 -- This defines the GL Use KEK control attribute 3511 id-skd-glUseKEK OBJECT IDENTIFIER ::= { id-skd 1} 3513 Turner 70 3514 GLUseKEK ::= SEQUENCE { 3515 glInfo GLInfo, 3516 glOwnerInfo SEQUENCE SIZE (1..MAX) OF GLOwnerInfo, 3517 glAdministration GLAdministration DEFAULT 1, 3518 glKeyAttributes GLKeyAttributes OPTIONAL } 3520 GLInfo ::= SEQUENCE { 3521 glName GeneralName, 3522 glAddress GeneralName } 3524 GLOwnerInfo ::= SEQUENCE { 3525 glOwnerName GeneralName, 3526 glOwnerAddress GeneralName, 3527 certificates Certificates OPTIONAL } 3529 GLAdministration ::= INTEGER { 3530 unmanaged (0), 3531 managed (1), 3532 closed (2) } 3534 GLKeyAttributes ::= SEQUENCE { 3535 rekeyControlledByGLO [0] BOOLEAN DEFAULT FALSE, 3536 recipientsNotMutuallyAware [1] BOOLEAN DEFAULT TRUE, 3537 duration [2] INTEGER DEFAULT 0, 3538 generationCounter [3] INTEGER DEFAULT 2, 3539 requestedAlgorithm [4] AlgorithmIdentifier 3540 DEFAULT id-alg-CMS3DESwrap } 3542 -- This defines the Delete GL control attribute. 3543 -- It has the simple type GeneralName. 3545 id-skd-glDelete OBJECT IDENTIFIER ::= { id-skd 2} 3547 DeleteGL ::= GeneralName 3549 -- This defines the Add GL Member control attribute 3551 id-skd-glAddMember OBJECT IDENTIFIER ::= { id-skd 3} 3553 GLAddMember ::= SEQUENCE { 3554 glName GeneralName, 3555 glMember GLMember } 3557 GLMember ::= SEQUENCE { 3558 glMemberName GeneralName, 3559 glMemberAddress GeneralName OPTIONAL, 3560 certificates Certificates OPTIONAL } 3562 Turner 71 3563 Certificates ::= SEQUENCE { 3564 pKC [0] Certificate OPTIONAL, 3565 -- See PKIX [5] 3566 aC [1] SEQUENCE SIZE (1.. MAX) OF 3567 AttributeCertificate OPTIONAL, 3568 -- See ACPROF [6] 3569 certPath [2] CertificateSet OPTIONAL } 3570 -- From CMS [2] 3572 -- This defines the Delete GL Member control attribute 3574 id-skd-glDeleteMember OBJECT IDENTIFIER ::= { id-skd 4} 3576 GLDeleteMember ::= SEQUENCE { 3577 glName GeneralName, 3578 glMemberToDelete GeneralName } 3580 -- This defines the Delete GL Member control attribute 3582 id-skd-glRekey OBJECT IDENTIFIER ::= { id-skd 5} 3584 GLRekey ::= SEQUENCE { 3585 glName GeneralName, 3586 glAdministration GLAdministration OPTIONAL, 3587 glNewKeyAttributes GLNewKeyAttributes OPTIONAL, 3588 glRekeyAllGLKeys BOOLEAN OPTIONAL } 3590 GLNewKeyAttributes ::= SEQUENCE { 3591 rekeyControlledByGLO [0] BOOLEAN OPTIONAL, 3592 recipientsNotMutuallyAware [1] BOOLEAN OPTIONAL, 3593 duration [2] INTEGER OPTIONAL, 3594 generationCounter [3] INTEGER OPTIONAL, 3595 requestedAlgorithm [4] AlgorithmIdentifier OPTIONAL } 3597 -- This defines the Add and Delete GL Owner control attributes 3599 id-skd-glAddOwner OBJECT IDENTIFIER ::= { id-skd 6} 3600 id-skd-glRemoveOwner OBJECT IDENTIFIER ::= { id-skd 7} 3602 GLOwnerAdministration ::= SEQUENCE { 3603 glName GeneralName, 3604 glOwnerInfo GLOwnerInfo } 3606 -- This defines the GL Key Compromise control attribute. 3607 -- It has the simple type GeneralName. 3609 id-skd-glKeyCompromise OBJECT IDENTIFIER ::= { id-skd 8} 3611 GLKCompromise ::= GeneralName 3613 Turner 72 3614 -- This defines the GL Key Refresh control attribute. 3616 id-skd-glkRefresh OBJECT IDENTIFIER ::= { id-skd 9} 3618 GLKRefresh ::= SEQUENCE { 3619 glName GeneralName, 3620 dates SEQUENCE SIZE (1..MAX) OF Date } 3622 Date ::= SEQUENCE { 3623 start GeneralizedTime, 3624 end GeneralizedTime OPTIONAL } 3626 -- This defines the GLA Query Request control attribute. 3628 id-skd-glaQueryRequest OBJECT IDENTIFIER ::= { id-skd 11} 3630 GLAQueryRequest ::= SEQUENCE { 3631 glaRequestType OBJECT IDENTIFIER, 3632 glaRequestValue ANY DEFINED BY glaRequestType } 3634 -- This defines the GLA Query Response control attribute. 3636 id-skd-glaQueryResponse OBJECT IDENTIFIER ::= { id-skd 12} 3638 GLAQueryResponse ::= SEQUENCE { 3639 glaResponseType OBJECT IDENTIFIER, 3640 glaResponseValue ANY DEFINED BY glaResponseType } 3642 -- This defines the GLA Request/Response (glaRR) arc for 3643 -- glaRequestType/glaResponseType. 3645 id-cmc-glaRR OBJECT IDENTIFIER ::= { iso(1) identified- 3646 organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) 3647 cmc(7) glaRR(99) } 3649 -- This defines the Algorithm Request 3651 id-cmc-gla-skdAlgRequest OBJECT IDENTIFIER ::= { id-cmc-glaRR 1 } 3653 SKDAlgRequest ::= NULL 3655 -- This defines the Algorithm Response 3657 id-cmc-gla-skdAlgResponse OBJECT IDENTIFIER ::= { id-cmc-glaRR 2 } 3659 -- Note that the response for algorithmSupported request is the 3660 -- smimeCapabilities attribute as defined in MsgSpec [7]. 3662 Turner 73 3663 -- This defines the control attribute to request an updated 3664 -- certificate to the GLA. 3666 id-skd-glProvideCert OBJECT IDENTIFIER ::= { id-skd 13} 3668 GLManageCert ::= SEQUENCE { 3669 glName GeneralName, 3670 glMember GLMember } 3672 -- This defines the control attribute to return an updated 3673 -- certificate to the GLA. It has the type GLManageCert. 3675 id-skd-glManageCert OBJECT IDENTIFIER ::= { id-skd 14} 3677 -- This defines the control attribute to distribute the GL shared 3678 -- KEK. 3680 id-skd-glKey OBJECT IDENTIFIER ::= { id-skd 15} 3682 GLKey ::= SEQUENCE { 3683 glName GeneralName, 3684 glIdentifier KEKIdentifier, -- See CMS [2] 3685 glkWrapped RecipientInfos, -- See CMS [2] 3686 glkAlgorithm AlgorithmIdentifier, 3687 glkNotBefore GeneralizedTime, 3688 glkNotAfter GeneralizedTime } 3690 Turner 74 3691 -- This defines the CMC error types 3693 id-cet-skdFailInfo OBJECT IDENTIFIER ::= { iso(1) 3694 identified-organization(3) dod(6) internet(1) security(5) 3695 mechanisms(5) pkix(7) cet(15) skdFailInfo(1) } 3697 SKDFailInfo ::= INTEGER { 3698 unspecified (0), 3699 closedGL (1), 3700 unsupportedDuration (2), 3701 noGLACertificate (3), 3702 invalidCert (4), 3703 unsupportedAlgorithm (5), 3704 noGLONameMatch (6), 3705 invalidGLName (7), 3706 nameAlreadyInUse (8), 3707 noSpam (9), 3708 deniedAccess (10), 3709 alreadyAMember (11), 3710 notAMember (12), 3711 alreadyAnOwner (13), 3712 notAnOwner (14) } 3714 END -- SMIMESymmetricKeyDistribution 3716 Expires 20 December 2001 3718 Turner 75