idnits 2.17.1 draft-ietf-smime-symkeydist-09.txt: -(1574): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(2174): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(2215): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(2608): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(2650): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(3269): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(3273): 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 16 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 80 longer pages, the longest (page 2) being 59 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The abstract seems to contain references ([CMC], [CMS]), 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 378 has weird spacing: '...esponse id-...' == Line 1457 has weird spacing: '...ributes and C...' -- 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 (January 2003) is 7771 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) -- Looks like a reference, but probably isn't: '0' on line 4086 -- Looks like a reference, but probably isn't: '1' on line 4087 -- Looks like a reference, but probably isn't: '2' on line 4088 -- Looks like a reference, but probably isn't: '3' on line 4089 -- Looks like a reference, but probably isn't: '4' on line 4090 == Outdated reference: A later version (-09) exists of draft-ietf-smime-x400transport-05 -- Obsolete informational reference (is this intentional?): RFC 1750 (ref. 'RANDOM') (Obsoleted by RFC 4086) ** Obsolete normative reference: RFC 3369 (ref. 'CMS') (Obsoleted by RFC 3852) == Outdated reference: A later version (-07) exists of draft-ietf-pkix-2797-bis-00 ** Obsolete normative reference: RFC 3280 (ref. 'PROFILE') (Obsoleted by RFC 5280) ** Obsolete normative reference: RFC 3281 (ref. 'ACPROF') (Obsoleted by RFC 5755) ** Obsolete normative reference: RFC 2633 (ref. 'MSG') (Obsoleted by RFC 3851) ** Obsolete normative reference: RFC 821 (ref. 'SMTP') (Obsoleted by RFC 2821) Summary: 9 errors (**), 0 flaws (~~), 8 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SMIME Working Group S. Turner 3 Internet Draft IECA 4 Document: draft-ietf-smime-symkeydist-09.txt January 2003 5 Expires: July 2003 7 CMS Symmetric Key Management and Distribution 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 This document is an Internet-Draft. Internet-Drafts are working 15 documents of the Internet Engineering Task Force (IETF), its areas, 16 and its working groups. Note that other groups may also distribute 17 working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six 20 months and may be updated, replaced, or obsoleted by other documents 21 at any time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 This draft is being discussed on the 'ietf-smime' mailing list. To 31 subscribe, send a message to ietf-smime-request@imc.org with the 32 single word subscribe in the body of the message. There is a Web 33 site for the mailing list at . 35 Abstract 37 This document describes a mechanism to manage (i.e., setup, 38 distribute, and rekey) keys used with symmetric cryptographic 39 algorithms. Also defined herein is a mechanism to organize users 40 into groups to support distribution of encrypted content using 41 symmetric cryptographic algorithms. The mechanism uses the 42 Cryptographic Message Syntax (CMS) protocol [CMS] and Certificate 43 Management Message over CMS (CMC) protocol [CMC] to manage the 44 symmetric keys. Any member of the group can then later use this 45 distributed shared key to decrypt other CMS encrypted objects with 46 the symmetric key. This mechanism has been developed to support 47 S/MIME Mail List Agents (MLAs). 49 Turner 1 50 And Distribution 52 Conventions used in this document 54 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 55 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 56 document are to be interpreted as described in RFC-2119 [STDWORDS]. 58 1 INTRODUCTION.....................................................3 59 1.1 APPLICABILITY TO E-MAIL........................................4 60 1.2 APPLICABILITY TO REPOSITORIES..................................4 61 1.3 USING THE GROUP KEY............................................4 62 2 ARCHITECTURE.....................................................5 63 3 PROTOCOL INTERACTIONS............................................6 64 3.1 CONTROL ATTRIBUTES.............................................8 65 3.1.1 GL USE KEK...................................................9 66 3.1.2 DELETE GL...................................................13 67 3.1.3 ADD GL MEMBER...............................................13 68 3.1.4 DELETE GL MEMBER............................................14 69 3.1.5 REKEY GL....................................................15 70 3.1.6 ADD GL OWNER................................................15 71 3.1.7 REMOVE GL OWNER.............................................16 72 3.1.8 GL KEY COMPROMISE...........................................16 73 3.1.9 GL KEY REFRESH..............................................16 74 3.1.10 GLA QUERY REQUEST AND RESPONSE.............................17 75 3.1.10.1 GLA QUERY REQUEST........................................17 76 3.1.10.2 GLA QUERY RESPONSE.......................................17 77 3.1.10.3 REQUEST AND RESPONSE TYPES...............................18 78 3.1.12 PROVIDE CERT...............................................18 79 3.1.13 UPDATE CERT................................................19 80 3.1.14 GL KEY.....................................................20 81 3.2 USE OF CMC, CMS, AND PKIX.....................................21 82 3.2.1 PROTECTION LAYERS...........................................22 83 3.2.1.1 MINIMUM PROTECTION........................................22 84 3.2.1.2 ADDITIONAL PROTECTION.....................................22 85 3.2.2 COMBINING REQUESTS AND RESPONSES............................23 86 3.2.3 GLA GENERATED MESSAGES......................................24 87 3.2.4 CMC CONTROL ATTRIBUTES AND CMS SIGNED ATTRIBUTES............25 88 3.2.4.1 USING CMCSTATUSINFOEXT....................................25 89 3.2.4.2 USING TRANSACTIONID.......................................28 90 3.2.4.3 USING NONCES AND SIGNINGTIME..............................28 91 3.2.4.4 CMC AND CMS ATTRIBUTE SUPPORT REQUIREMENTS................29 92 3.2.5 RESUBMITTED GL MEMBER MESSAGES..............................29 93 3.2.6 PKIX CERTIFICATE AND CRL PROFILE............................29 94 4 ADMINISTRATIVE MESSAGES.........................................30 95 4.1 ASSIGN KEK TO GL..............................................30 96 4.2 DELETE GL FROM GLA............................................33 97 4.3 ADD MEMBERS TO GL.............................................36 98 4.3.1 GLO INITIATED ADDITIONS.....................................37 99 4.3.2 PROSPECTIVE MEMBER INITIATED ADDITIONS......................43 100 4.4 DELETE MEMBERS FROM GL........................................45 101 4.4.1 GLO INITIATED DELETIONS.....................................46 102 4.4.2 MEMBER INITIATED DELETIONS..................................51 103 4.5 REQUEST REKEY OF GL...........................................53 105 Turner Expires July 2003 2 106 And Distribution 108 4.5.1 GLO INITIATED REKEY REQUESTS................................54 109 4.5.2 GLA INITIATED REKEY REQUESTS................................56 110 4.6 CHANGE GLO....................................................57 111 4.7 INDICATE KEK COMPROMISE.......................................60 112 4.7.1 GL MEMBER INITIATED KEK COMPROMISE MESSAGE..................60 113 4.7.2 GLO INITIATED KEK COMPROMISE MESSAGE........................61 114 4.8 REQUEST KEK REFRESH...........................................63 115 4.9 GLA QUERY REQUEST AND RESPONSE................................64 116 4.10 UPDATE MEMBER CERTIFICATE....................................66 117 4.10.1 GLO AND GLA INITIATED UPDATE MEMBER CERTIFICATE............67 118 4.10.2 GL MEMBER INITIATED UPDATE MEMBER CERTIFICATE..............69 119 5 DISTRIBUTION MESSAGE............................................70 120 5.1 DISTRIBUTION PROCESS..........................................71 121 6 ALGORITHMS......................................................72 122 6.1 KEK GENERATION ALGORITHM......................................72 123 6.2 SHARED KEK WRAP ALGORITHM.....................................72 124 6.3 SHARED KEK ALGORITHM..........................................72 125 7 MESSAGE TRANSPORT...............................................73 126 8 SECURITY CONSIDERATIONS.........................................73 127 9 REFERENCES......................................................74 128 9.1 INFORMATIVE...................................................74 129 9.1 NORMATIVE.....................................................74 130 10 ACKNOWLEDGEMENTS...............................................75 131 11 AUTHOR'S ADDRESSES.............................................75 132 ANNEX A: ASN.1 MODULE.............................................76 134 1 Introduction 136 With the ever-expanding use of secure electronic communications 137 (e.g., S/MIME [MSG]), users require a mechanism to distribute 138 encrypted data to multiple recipients (i.e., a group of users). 139 There are essentially two ways to encrypt the data for recipients: 140 using asymmetric algorithms with public key certificates (PKCs) or 141 symmetric algorithms with symmetric keys. 143 With asymmetric algorithms, the originator forms an originator- 144 determined content-encryption key (CEK) and encrypts the content, 145 using a symmetric algorithm. Then, using an asymmetric algorithm and 146 the recipient's PKCs, the originator generates per-recipient 147 information that either (a) encrypts the CEK for a particular 148 recipient (ktri RecipientInfo CHOICE), or (b) transfers sufficient 149 parameters to enable a particular recipient to independently 150 generate the same KEK (kari RecipientInfo CHOICE). If the group is 151 large, processing of the per-recipient information may take quite 152 some time, not to mention the time required to collect and validate 153 the PKCs for each of the recipients. Each recipient identifies its 154 per-recipient information and uses the private key associated with 155 the public key of its PKC to decrypt the CEK and hence gain access 156 to the encrypted content. 158 Turner Expires July 2003 3 159 And Distribution 161 With symmetric algorithms, the origination process is slightly 162 different. Instead of using PKCs, the originator uses a previously 163 distributed secret key-encryption key (KEK) to encrypt the CEK 164 (kekri RecipientInfo CHOICE). Only one copy of the encrypted CEK is 165 required because all the recipients already have the shared KEK 166 needed to decrypt the CEK and hence gain access to the encrypted 167 content. 169 The techniques to protect the shared KEK are beyond the scope of 170 this document. Only the members of the list and the key manager 171 should have the KEK in order to maintain confidentiality. Access 172 control to the information protected by the KEK is determined by the 173 entity that encrypts the information, as all members of the group 174 have access. If the entity that is performing the encryption wants 175 to ensure some subset of the group does not gain access to the 176 information either a different KEK should be used (shared only with 177 this smaller group) or asymmetric algorithms should be used. 179 1.1 Applicability to E-mail 181 One primary audience for this distribution mechanism is e-mail. 182 Distribution lists, sometimes referred to as mail lists, support the 183 distribution of messages to recipients subscribed to the mail list. 184 There are two models for how the mail list can be used. If the 185 originator is a member of the mail list, the originator sends 186 messages encrypted with the shared KEK to the mail list (e.g., 187 listserv or majordomo) and the message is distributed to the mail 188 list members. If the originator is not a member of the mail list 189 (does not have the shared KEK), the originator sends the message 190 (encrypted for the MLA) to the mail list agent (MLA), and then the 191 MLA uses the shared KEK to encrypt the message for the members. In 192 either case the recipients of the mail list use the previously 193 distributed-shared KEK to decrypt the message. 195 1.2 Applicability to Repositories 197 Objects can also be distributed via a repository (e.g., Lightweight 198 Directory Protocol (LDAP) servers, X.500 Directory System Agents 199 (DSAs), Web-based servers). If an object is stored in a repository 200 encrypted with a symmetric key algorithm, anyone with the shared KEK 201 and access to that object can then decrypt that object. The 202 encrypted object and the encrypted, shared KEK can be stored in the 203 repository. 205 1.3 Using the Group Key 207 This document was written with three specific scenarios in mind: two 208 supporting mail list agents and one for general message 209 distribution. Scenario 1 depicts the originator sending a public key 211 Turner Expires July 2003 4 212 And Distribution 214 (PK) protected message to a MLA who then uses the shared KEK(s) to 215 redistribute the message to the members of the list. Scenario 2 216 depicts the originator sending a shared KEK protected message to a 217 MLA who then redistributes the message to the members of the list 218 (the MLA only adds additional recipients). The key used by the 219 originator could either be a key shared amongst all recipients or 220 just between the member and the MLA. Note that if the originator use 221 a key shared only with the MLA, then the MLA will need to decrypt 222 the message and rencrypt the message for the list recipients. 223 Scenario 3 shows an originator sending a shared KEK protected 224 message to a group of recipients without an intermediate MLA. 226 +----> +----> +----> 227 PK +-----+ S | S +-----+ S | S | 228 ----> | MLA | --+----> ----> | MLA | --+----> ----+----> 229 +-----+ | +-----+ | | 230 +----> +----> +----> 232 Scenario 1 Scenario 2 Scenario 3 234 2 Architecture 236 Figure 1 depicts the architecture to support symmetric key 237 distribution. The Group List Agent (GLA) supports two distinct 238 functions with two different agents: 240 - The Key Management Agent (KMA) which is responsible for 241 generating the shared KEKs. 243 - The Group Management Agent (GMA) which is responsible for 244 managing the Group List (GL) to which the shared KEKs are 245 distributed. 247 +----------------------------------------------+ 248 | Group List Agent | +-------+ 249 | +------------+ + -----------------------+ | | Group | 250 | | Key | | Group Management Agent | |<-->| List | 251 | | Management |<-->| +------------+ | | | Owner | 252 | | Agent | | | Group List | | | +-------+ 253 | +------------+ | +------------+ | | 254 | | / | \ | | 255 | +------------------------+ | 256 +----------------------------------------------+ 257 / | \ 258 / | \ 259 +----------+ +---------+ +----------+ 260 | Member 1 | | ... | | Member n | 261 +----------+ +---------+ +----------+ 263 Figure 1 - Key Distribution Architecture 265 Turner Expires July 2003 5 266 And Distribution 268 A GLA may support multiple KMAs. A GLA in general supports only one 269 GMA, but the GMA may support multiple GLs. Multiple KMAs may support 270 a GMA in the same fashion as GLAs support multiple KMAs. Assigning a 271 particular KMA to a GL is beyond the scope of this document. 273 Modeling real world GL implementations shows that there are very 274 restrictive GLs, where a human determines GL membership, and very 275 open GLs, where there are no restrictions on GL membership. To 276 support this spectrum, the mechanism described herein supports both 277 managed (i.e., where access control is applied) and unmanaged (i.e., 278 where no access control is applied) GLs. The access control 279 mechanism for managed lists is beyond the scope of this document. 280 Note: If the distribution for the list is performed by an entity 281 other than the originator (e.g., an MLA distributing a mail 282 message), this entity can also enforce access control rules. 284 In either case, the GL must initially be constructed by an entity 285 hereafter called the Group List Owner (GLO). There may be multiple 286 entities who 'own' the GL and who are allowed to make changes to the 287 GL's properties or membership. The GLO determines if the GL will be 288 managed or unmanaged and is the only entity that may delete the GL. 289 GLO(s) may or may not be GL members. GLO(s) may also set up lists 290 that are closed, where the GLO solely determines GL membership. 292 Though Figure 1 depicts the GLA as encompassing both the KMA and GMA 293 functions, the two functions could be supported by the same entity 294 or they could be supported by two different entities. If two 295 entities are used, they could be located on one or two platforms. 296 There is however a close relationship between the KMA and GMA 297 functions. If the GMA stores all information pertaining to the GLs 298 and the KMA merely generates keys, a corrupted GMA could cause 299 havoc. To protect against a corrupted GMA, the KMA would be forced 300 to double check the requests it receives to ensure the GMA did not 301 tamper with them. These duplicative checks blur the functionality of 302 the two components together. For this reason, the interactions 303 between the KMA and GMA are beyond the scope of this document. 304 Proprietary mechanisms may be used to separate the functions by 305 strengthening the trust relationship between the two entities. 306 Henceforth, the distinction between the two agents is not discussed 307 further; the term GLA will be used to address both functions. It 308 should be noted that corrupt GLA can always cause havoc. 310 3 Protocol Interactions 312 There are existing mechanisms (e.g., listserv and majordomo) to 313 manage GLs; however, this document does not address securing these 314 mechanisms, as they are not standardized. Instead, it defines 315 protocol interactions, as depicted in Figure 2, used by the GL 316 members, GLA, and GLO(s) to manage GLs and distribute shared KEKs. 317 The interactions have been divided into administration messages and 319 Turner Expires July 2003 6 320 And Distribution 322 distribution messages. The administrative messages are the request 323 and response messages needed to setup the GL, delete the GL, add 324 members to the GL, delete members of the GL, request a group rekey, 325 add owners to the GL, remove owners of the GL, indicate a group key 326 compromise, refresh a group key, interrogate the GLA, and update 327 member's and owner's public key certificates. The distribution 328 messages are the messages that distribute the shared KEKs. The 329 following sections describe the ASN.1 for both the administration 330 and distribution messages. Section 4 describes how to use the 331 administration messages, and section 5 describes how to use the 332 distribution messages. 334 +-----+ +----------+ 335 | GLO | <---+ +----> | Member 1 | 336 +-----+ | | +----------+ 337 | | 338 +-----+ <------+ | +----------+ 339 | GLA | <-------------+----> | ... | 340 +-----+ | +----------+ 341 | 342 | +----------+ 343 +----> | Member n | 344 +----------+ 346 Figure 2 - Protocol Interactions 348 Turner Expires July 2003 7 349 And Distribution 351 3.1 Control Attributes 353 To avoid creating an entirely new protocol, the Certificate 354 Management Messages over CMS (CMC) protocol was chosen as the 355 foundation of this protocol. The main reason for the choice was the 356 layering aspect provided by CMC where one or more control attributes 357 are included in message, protected with CMS, to request or respond 358 to a desired action. The CMC PKIData structure is used for requests, 359 and the CMC ResponseBody structure is used for responses. The 360 content-types PKIData and PKIResponse are then encapsulated in CMS's 361 SignedData or EnvelopedData, or a combination of the two (see 362 section 3.2). The following are the control attributes defined in 363 this document: 365 Control 366 Attribute OID Syntax 367 ------------------- ----------- ----------------- 368 glUseKEK id-skd 1 GLUseKEK 369 glDelete id-skd 2 GeneralName 370 glAddMember id-skd 3 GLAddMember 371 glDeleteMember id-skd 4 GLDeleteMember 372 glRekey id-skd 5 GLRekey 373 glAddOwner id-skd 6 GLOwnerAdministration 374 glRemoveOwner id-skd 7 GLOwnerAdministration 375 glkCompromise id-skd 8 GeneralName 376 glkRefresh id-skd 9 GLKRefresh 377 glaQueryRequest id-skd 11 GLAQueryRequest 378 glaQueryResponse id-skd 12 GLAQueryResponse 379 glProvideCert id-skd 13 GLManageCert 380 glUpdateCert id-skd 14 GLManageCert 381 glKey id-skd 15 GLKey 383 In the following conformance tables, the column headings have the 384 following meanings: O for originate, R for receive, and F for 385 forward. There are three types of implementations: GLOs, GLAs, and 386 GL members. The GLO is an optional component hence all GLO O and GLO 387 R messages are optional, and GLA F messages are optional. The first 388 table includes messages that conformant implementions MUST support. 389 The second table includes messages that MAY be implemented. The 390 second table should be interpreted as follows: if the control 391 attribute is implemented by a component then it must be implemented 392 as indicated. For example, if a GLA is implemented that supports the 393 glAddMember control attribute, then it MUST support receiving the 394 glAddMember message. Note that "-" means not applicable. 396 Turner Expires July 2003 8 397 And Distribution 399 Required 400 Implementation Requirement | Control 401 GLO | GLA | GL Member | Attribute 402 O R | O R F | O R | 403 ------- | ----------------- | --------- | ---------- 404 MAY - | MUST - MAY | - MUST | glProvideCert 405 MAY MAY | - MUST MAY | MUST - | glUpdateCert 406 - - | MUST - - | - MUST | glKey 408 Optional 409 Implementation Requirement | Control 410 GLO | GLA | GL Member | Attribute 411 O R | O R F | O R | 412 ------- | ----------------- | --------- | ---------- 413 MAY - | - MAY - | - - | glUseKEK 414 MAY - | - MAY - | - - | glDelete 415 MAY MAY | - MUST MAY | MUST - | glAddMember 416 MAY MAY | - MUST MAY | MUST - | glDeleteMember 417 MAY - | - MAY - | - - | glRekey 418 MAY - | - MAY - | - - | glAddOwner 419 MAY - | - MAY - | - - | glRemoveOwner 420 MAY MAY | - MUST MAY | MUST - | glkCompromise 421 MAY - | - MUST - | MUST - | glkRefresh 422 MAY - | - SHOULD - | MAY - | glaQueryRequest 423 - MAY | SHOULD - - | - MAY | glaQueryResponse 425 glaQueryResponse and gloResponse are carried in the CMC PKIResponse 426 content-type, all other control attributes are carried in the CMC 427 PKIData content-type. The exception is glUpdateCert which can be 428 carried in either PKIData or PKIResponse. 430 Success and failure messages use CMC (see section 3.2.4). 432 3.1.1 GL USE KEK 434 The GLO uses glUseKEK to request that a shared KEK be assigned to a 435 GL. glUseKEK messages MUST be signed by the GLO. The glUseKEK 436 control attribute has the syntax GLUseKEK: 438 GLUseKEK ::= SEQUENCE { 439 glInfo GLInfo, 440 glOwnerInfo SEQUENCE SIZE (1..MAX) OF GLOwnerInfo, 441 glAdministration GLAdministration DEFAULT 1, 442 glKeyAttributes GLKeyAttributes OPTIONAL } 444 Turner Expires July 2003 9 445 And Distribution 447 GLInfo ::= SEQUENCE { 448 glName GeneralName, 449 glAddress GeneralName } 451 GLOwnerInfo ::= SEQUENCE { 452 glOwnerName GeneralName, 453 glOwnerAddress GeneralName, 454 certificate Certificates OPTIONAL } 456 Certificates ::= SEQUENCE { 457 pKC [0] Certificate OPTIONAL, 458 -- See [PROFILE] 459 aC [1] SEQUENCE SIZE (1.. MAX) OF 460 AttributeCertificate OPTIONAL, 461 -- See [ACPROF] 462 certPath [2] CertificateSet OPTIONAL } 463 -- From [CMS] 465 -- CertificateSet and CertificateChoices are included only 466 -- for illustrative purposes as they are imported from [CMS]. 468 CertificateSet ::= SET SIZE (1..MAX) OF CertificateChoices 470 -- CertificateChoices supports X.509 public key certificates in 471 -- certificates and v2 attribute certificates in v2AttrCert. 473 GLAdministration ::= INTEGER { 474 unmanaged (0), 475 managed (1), 476 closed (2) } 478 GLKeyAttributes ::= SEQUENCE { 479 rekeyControlledByGLO [0] BOOLEAN DEFAULT FALSE, 480 recipientsNotMutuallyAware [1] BOOLEAN DEFAULT TRUE, 481 duration [2] INTEGER DEFAULT 0, 482 generationCounter [3] INTEGER DEFAULT 2, 483 requestedAlgorithm [4] AlgorithmIdentifier 484 DEFAULT id-alg-CMS3DESwrap } 486 The fields in GLUseKEK have the following meaning: 488 - glInfo indicates the name of the GL in glName and the address of 489 the GL in glAddress. The glName and glAddress can be the same, 490 but this is not always the case. Both the name and address MUST 491 be unique for a given GLA. 493 - glOwnerInfo indicates: 495 - glOwnerName indicates the name of the owner of the GL. One of 496 the names in glOwnerName MUST match one of the names in the 497 certificate (either the subject distinguished name or one of 499 Turner Expires July 2003 10 500 And Distribution 502 the subject alternative names) used to sign this 503 SignedData.PKIData creating the GL (i.e., the immediate 504 signer). 506 - glOwnerAddress indicates the address of the owner of the GL. 508 - certificates MAY be included. It contains the following three 509 fields: 511 - certificates.pKC includes the encryption certificate for the 512 GLO. It will be used to encrypt responses for the GLO. 514 - certificates.aC MAY be included to convey any attribute 515 certificate (see [ACPROF]) associated with the encryption 516 certificate of the GLO included in certificates.pKC. 518 - certificates.certPath MAY also be included to convey 519 certificates that might aid the recipient in constructing 520 valid certification paths for the certificate provided in 521 certificates.pKC and the attribute certificates provided in 522 certificates.aC. Theses certificates are optional because 523 they might already be included elsewhere in the message 524 (e.g., in the outer CMS layer). 526 - glAdministration indicates how the GL ought to be administered. 527 The default is for the list to be managed. Three values are 528 supported for glAdministration: 530 - Unmanaged - When the GLO sets glAdministration to unmanaged, 531 it is allowing prospective members to request addition and 532 deletion from the GL without GLO intervention. 534 - Managed - When the GLO sets glAdministration to managed, it is 535 allowing prospective members to request addition and deletion 536 from the GL, but the request is redirected by the GLA to GLO 537 for review. The GLO makes the determination as to whether to 538 honor the request. 540 - Closed - When the GLO sets glAdministration to closed, it is 541 not allowing prospective members to request addition or 542 deletion from the GL. The GLA will only accept glAddMember and 543 glDeleteMember requests from the GLO. 545 - glKeyAttributes indicates the attributes the GLO wants the GLA 546 to assign to the shared KEK. If this field is omitted, GL rekeys 547 will be controlled by the GLA, the recipients are allowed to 548 know about one another, the algorithm will be Triple-DES (see 549 paragrpah 7), the shared KEK will be valid for a calendar month 550 (i.e., first of the month until the last day of the month), and 551 two shared KEKs will be distributed initially. The fields in 552 glKeyAttributes have the following meaning: 554 Turner Expires July 2003 11 555 And Distribution 557 - rekeyControlledByGLO indicates whether the GL rekey messages 558 will be generated by the GLO or by the GLA. The default is for 559 the GLA to control rekeys. If GL rekey is controlled by the 560 GLA, the GL will continue to be rekeyed until the GLO deletes 561 the GL or changes the GL rekey to be GLO controlled. 563 - recipientsNotMutuallyAware indicates that the GLO wants the 564 GLA to distribute the shared KEK individually for each of the 565 GL members (i.e., a separate glKey message is sent to each 566 recipient). The default is for separate glKey message not to 567 be required. 569 NOTE: This supports lists where one member does not know the 570 identities of the other members. For example, a list is 571 configured granting submit permissions to only one member. All 572 other members are 'listening.' The security policy of the list 573 does not allow the members to know who else is on the list. If 574 a glKey is constructed for all of the GL members, information 575 about each of the members may be derived from the information 576 in RecipientInfos. To make sure the glkey message does not 577 divulge information about the other recipients, a separate 578 glKey message would be sent to each GL member. 580 - duration indicates the length of time (in days) during which 581 the shared KEK is considered valid. The value zero (0) 582 indicates that the shared KEK is valid for a calendar month in 583 the UTC Zulu time zone. For example if the duration is zero 584 (0), if the GL shared KEK is requested on July 24, the first 585 key will be valid until the end of July and the next key will 586 be valid for the entire month of August. If the value is not 587 zero (0), the shared KEK will be valid for the number of days 588 indicated by the value. For example, if the value of duration 589 is seven (7) and the shared KEK is requested on Monday but not 590 generated until Tuesday (2359); the shared KEKs will be valid 591 from Tuesday (2359) to Tuesday (2359). The exact time of the 592 day is determined when the key is generated. 594 - generationCounter indicates the number of keys the GLO wants 595 the GLA to distribute. To ensure uninterrupted function of the 596 GL two (2) shared KEKs at a minimum MUST be initially 597 distributed. The second shared KEK is distributed with the 598 first shared KEK, so that when the first shared KEK is no 599 longer valid the second key can be used. If the GLA controls 600 rekey then it also indicates the number of shared KEKs the GLO 601 wants outstanding at any one time. See sections 4.5 and 5 for 602 more on rekey. 604 - requestedAlgorithm indicates the algorithm and any parameters 605 the GLO wants the GLA to use with the shared KEK. The 606 parameters are conveyed via the SMIMECapabilities attribute 607 (see [MSG]). See section 6 for more on algorithms. 609 Turner Expires July 2003 12 610 And Distribution 612 3.1.2 Delete GL 614 GLOs use glDelete to request that a GL be deleted from the GLA. The 615 glDelete control attribute has the syntax GeneralName. The glDelete 616 message MUST be signed by the GLO. The name of the GL to be deleted 617 is included in GeneralName: 619 DeleteGL ::= GeneralName 621 3.1.3 Add GL Member 623 GLOs use the glAddMember to request addition of new members, and 624 prospective GL members use the glAddMember to request their own 625 addition to the GL. The glAddMember message MUST be signed by either 626 the GLO or the prospective GL member. The glAddMember control 627 attribute has the syntax GLAddMember: 629 GLAddMember ::= SEQUENCE { 630 glName GeneralName, 631 glMember GLMember } 633 GLMember ::= SEQUENCE { 634 glMemberName GeneralName, 635 glMemberAddress GeneralName OPTIONAL, 636 certificates Certificates OPTIONAL } 638 Certificates ::= SEQUENCE { 639 pKC [0] Certificate OPTIONAL, 640 -- See [PROFILE] 641 aC [1] SEQUENCE SIZE (1.. MAX) OF 642 AttributeCertificate OPTIONAL, 643 -- See [ACPROF] 644 certPath [2] CertificateSet OPTIONAL } 645 -- From [CMS] 647 -- CertificateSet and CertificateChoices are included only 648 -- for illustrative purposes as they are imported from [CMS]. 650 CertificateSet ::= SET SIZE (1..MAX) OF CertificateChoices 652 -- CertificateChoices supports X.509 public key certificates in 653 -- certificates and v2 attribute certificates in v2AttrCert. 655 The fields in GLAddMembers have the following meaning: 657 - glName indicates the name of the GL to which the member should 658 be added. 660 - glMember indicates the particulars for the GL member. Both of 661 the following fields must be unique for a given GL: 663 Turner Expires July 2003 13 664 And Distribution 666 - glMemberName indicates the name of the GL member. 668 - glMemberAddress indicates the GL member's address. It MUST be 669 included. 671 Note: In some instances the glMemberName and glMemberAddress 672 may be the same, but this is not always the case. 674 - certificates MUST be included. It contains the following three 675 fields: 677 - certificates.pKC includes the member's encryption 678 certificate. It will be used, at least initially, to encrypt 679 the shared KEK for that member. If the message is generated 680 by a prospective GL member, the pKC MUST be included. If the 681 message is generated by a GLO, the pKC SHOULD be included. 683 - certificates.aC MAY be included to convey any attribute 684 certificate (see [ACPROF]) associated with the member's 685 encryption certificate. 687 - certificates.certPath MAY also be included to convey 688 certificates that might aid the recipient in constructing 689 valid certification paths for the certificate provided in 690 certificates.pKC and the attribute certificates provided in 691 certificates.aC. These certificates are optional because 692 they might already be included elsewhere in the message 693 (e.g., in the outer CMS layer). 695 3.1.4 Delete GL Member 697 GLOs use the glDeleteMember to request deletion of GL members, and 698 GL members use the glDeleteMember to request their own removal from 699 the GL. The glDeleteMember message MUST be signed by either the GLO 700 or the GL member. The glDeleteMember control attribute has the 701 syntax GLDeleteMember: 703 GLDeleteMember ::= SEQUENCE { 704 glName GeneralName, 705 glMemberToDelete GeneralName } 707 The fields in GLDeleteMembers have the following meaning: 709 - glName indicates the name of the GL from which the member should 710 be removed. 712 - glMemberToDelete indicates the name or address of the member to 713 be deleted. 715 Turner Expires July 2003 14 716 And Distribution 718 3.1.5 Rekey GL 720 GLOs use the glRekey to request a GL rekey. The glRekey message MUST 721 be signed by the GLO. The glRekey control attribute has the syntax 722 GLRekey: 724 GLRekey ::= SEQUENCE { 725 glName GeneralName, 726 glAdministration GLAdministration OPTIONAL, 727 glNewKeyAttributes GLNewKeyAttributes OPTIONAL, 728 glRekeyAllGLKeys BOOLEAN OPTIONAL } 730 GLNewKeyAttributes ::= SEQUENCE { 731 rekeyControlledByGLO [0] BOOLEAN OPTIONAL, 732 recipientsNotMutuallyAware [1] BOOLEAN OPTIONAL, 733 duration [2] INTEGER OPTIONAL, 734 generationCounter [3] INTEGER OPTIONAL, 735 requestedAlgorithm [4] AlgorithmIdentifier OPTIONAL } 737 The fields in GLRekey have the following meaning: 739 - glName indicates the name of the GL to be rekeyed. 741 - glAdministration indicates if there is any change to how the GL 742 should be administered. See section 3.1.1 for the three options. 743 This field is only included if there is a change from the 744 previously registered administered. 746 - glNewKeyAttributes indicates whether the rekey of the GLO is 747 controlled by the GLA or GL, what algorithm and parameters the 748 GLO wishes to use, the duration of the key, and how many keys 749 will be issued. The field is only included if there is a change 750 from the previously registered glKeyAttributes. 752 - glRekeyAllGLKeys indicates whether the GLO wants all of the 753 outstanding GL's shared KEKs rekeyed. If it is set to TRUE then 754 all outstanding KEKs MUST be issued. If it is set to FALSE then 755 all outstanding KEKs need not be resissued. 757 3.1.6 Add GL Owner 759 GLOs use the glAddOwner to request that a new GLO be allowed to 760 administer the GL. The glAddOwner message MUST be signed by a 761 registered GLO. The glAddOwner control attribute has the syntax 762 GLOwnerAdministration: 764 GLOwnerAdministration ::= SEQUENCE { 765 glName GeneralName, 766 glOwnerInfo GLOwnerInfo } 768 Turner Expires July 2003 15 769 And Distribution 771 The fields in GLAddOwners have the following meaning: 773 - glName indicates the name of the GL to which the new GLO should 774 be associated. 776 - glOwnerInfo indicates the name, address, and certificates of the 777 new GLO. As this message includes names of new GLOs, the 778 certificates.pKC MUST be included, and it MUST include the 779 encryption certificate of the new GLO. 781 3.1.7 Remove GL Owner 783 GLOs use the glRemoveOwner to request that a GLO be disassociated 784 with the GL. The glRemoveOwner message MUST be signed by a 785 registered GLO. The glRemoveOwner control attribute has the syntax 786 GLOwnerAdministration: 788 GLOwnerAdministration ::= SEQUENCE { 789 glName GeneralName, 790 glOwnerInfo GLOwnerInfo } 792 The fields in GLRemoveOwners have the following meaning: 794 - glName indicates the name of the GL to which the GLO should be 795 disassociated. 797 - glOwnerInfo indicates the name and address of the GLO to be 798 removed. The certificates field SHOULD be omitted, as it will be 799 ignored. 801 3.1.8 GL Key Compromise 803 GL members and GLOs use glkCompromise to indicate that the shared 804 KEK possessed has been compromised. The glKeyCompromise control 805 attribute has the syntax GeneralName. This message is always 806 redirected by the GLA to the GLO for further action. The 807 glkCompromise MAY be included in an EnvelopedData generated with the 808 compromised shared KEK. The name of the GL to which the compromised 809 key is associated with is placed in GeneralName: 811 GLKCompromise ::= GeneralName 813 3.1.9 GL Key Refresh 815 GL members use the glkRefresh to request that the shared KEK be 816 redistributed to them. The glkRefresh control attribute has the 817 syntax GLKRefresh. 819 Turner Expires July 2003 16 820 And Distribution 822 GLKRefresh ::= SEQUENCE { 823 glName GeneralName, 824 dates SEQUENCE SIZE (1..MAX) OF Date } 826 Date ::= SEQUENCE { 827 start GeneralizedTime, 828 end GeneralizedTime OPTIONAL } 830 The fields in GLKRefresh have the following meaning: 832 - glName indicates the name of the GL for which the GL member 833 wants shared KEKs. 835 - dates indicates a date range for keys the GL member wants. The 836 start field indicates the first date the GL member wants and the 837 end field indicates the last date. The end date MAY be omitted 838 to indicate the GL member wants all keys from the specified 839 start date to the current date. Note that a procedural mechanism 840 is needed to restrict users from accessing messages that they 841 are not allowed to access. 843 3.1.10 GLA Query Request and Response 845 There are situations where GLOs and GL members may need to determine 846 some information from the GLA about the GL. GLOs and GL members use 847 the glaQueryRequest, defined in section 3.1.10.1, to request 848 information and GLAs use the glaQueryResponse, defined in section 849 3.1.10.2, to return the requested information. Section 3.1.10.3 850 includes one request and response type and value; others may be 851 defined in additional documents. 853 3.1.10.1 GLA Query Request 855 GLOs and GL members use the glaQueryRequest to ascertain information 856 about the GLA. The glaQueryRequest control attribute has the syntax 857 GLAQueryRequest: 859 GLAQueryRequest ::= SEQUENCE { 860 glaRequestType OBJECT IDENTIFIER, 861 glaRequestValue ANY DEFINED BY glaRequestType } 863 3.1.10.2 GLA Query Response 865 GLAs return the glaQueryResponse after receiving a GLAQueryRequest. 866 The glaQueryResponse MUST be signed by a GLA. The glaQueryResponse 867 control attribute has the syntax GLAQueryResponse: 869 Turner Expires July 2003 17 870 And Distribution 872 GLAQueryResponse ::= SEQUENCE { 873 glaResponseType OBJECT IDENTIFIER, 874 glaResponseValue ANY DEFINED BY glaResponseType } 876 3.1.10.3 Request and Response Types 878 Request and Responses are registered as a pair under the following 879 object identifier arc: 881 id-cmc-glaRR OBJECT IDENTIFIER ::= { id-cmc 99 } 883 This document defines one request/response pair for GL members and 884 GLOs to query the GLA for the list of algorithm it supports. The 885 following object identifier (OID) is included in the glaQueryType 886 field: 888 id-cmc-gla-skdAlgRequest OBJECT IDENTIFIER ::={ id-cmc-glaRR 1 } 890 SKDAlgRequest ::= NULL 892 If the GLA supports GLAQueryRequest and GLAQueryResponse messages, 893 the GLA may return the following OID in the glaQueryType field: 895 id-cmc-gla-skdAlgResponse OBJECT IDENTIFIER ::= { id-cmc-glaRR 2 } 897 The glaQueryValue has the form of the smimeCapabilities attributes 898 as defined in [MSG]. 900 3.1.12 Provide Cert 902 GLAs and GLOs use the glProvideCert to request that a GL member 903 provide an updated or new encryption certificate. The glProvideCert 904 message MUST be signed by either GLA or GLO. If the GL member's PKC 905 has been revoked, the GLO or GLA MUST NOT use it to generate the 906 EnvelopedData that encapsulates the glProvideCert request. The 907 glProvideCert control attribute has the syntax GLManageCert: 909 GLManageCert ::= SEQUENCE { 910 glName GeneralName, 911 glMember GLMember } 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 is to be associated. 918 - glMember indicates particulars for the GL member: 920 - glMemberName indicates the GL member's name. 922 Turner Expires July 2003 18 923 And Distribution 925 - glMemberAddress indicates the GL member's address. It MAY be 926 omitted. 928 - certificates SHOULD be omitted. 930 3.1.13 Update Cert 932 GL members and GLOs use the glUpdateCert to provide a new 933 certificate for the GL. GL members can generate an unsolicited 934 glUpdateCert or generate a response glUpdateCert as a result of 935 receiveing a glProvideCert message. GL members MUST sign the 936 glUpdateCert. If the GL member's encryption certificate has been 937 revoked, the GL member MUST NOT use it to generate the EnvelopedData 938 that encapsulates the glUpdateCert request or response. The 939 glUpdateCert control attribute has the syntax GLManageCert: 941 GLManageCert ::= SEQUENCE { 942 glName GeneralName, 943 glMember GLMember } 945 The fields in GLManageCert have the following meaning: 947 - glName indicates the name of the GL to which the GL member's new 948 certificate should be associated. 950 - glMember indicates the particulars for the GL member: 952 - glMemberName indicates the GL member's name. 954 - glMemberAddress indicates the GL member's address. It MAY be 955 omitted. 957 - certificates MAY be omitted if the GLManageCert message is 958 sent to request the GL member's certificate; otherwise, it 959 MUST be included. It includes the following three fields: 961 - certificates.pKC includes the member's encryption 962 certificate that will be used to encrypt the shared KEK for 963 that member. 965 - certificates.aC MAY be included to convey one or more 966 attribute certificate associated with the member's 967 encryption certificate. 969 - certificates.certPath MAY also be included to convey 970 certificates that might aid the recipient in constructing 971 valid certification paths for the certificate provided in 972 certificates.pKC and the attribute certificates provided in 973 certificates.aC. These certificates is optional because they 975 Turner Expires July 2003 19 976 And Distribution 978 might already be included elsewhere in the message (e.g., in 979 the outer CMS layer). 981 3.1.14 GL Key 983 The GLA uses the glKey to distribute the shared KEK. The glKey 984 message MUST be signed by the GLA. The glKey control attribute has 985 the syntax GLKey: 987 GLKey ::= SEQUENCE { 988 glName GeneralName, 989 glIdentifier KEKIdentifier, -- See [CMS] 990 glkWrapped RecipientInfos, -- See [CMS] 991 glkAlgorithm AlgorithmIdentifier, 992 glkNotBefore GeneralizedTime, 993 glkNotAfter GeneralizedTime } 995 -- KEKIdentifier is included only for illustrative purposes as 996 -- it is imported from [CMS]. 998 KEKIdentifier ::= SEQUENCE { 999 keyIdentifier OCTET STRING, 1000 date GeneralizedTime OPTIONAL, 1001 other OtherKeyAttribute OPTIONAL } 1003 The fields in GLKey have the following meaning: 1005 - glName is the name of the GL. 1007 - glIdentifier is the key identifier of the shared KEK. See 1008 paragraph 6.2.3 of [CMS] for a description of the subfields. 1010 - glkWrapped is the wrapped shared KEK for the GL for a particular 1011 duration. The RecipientInfos MUST be generated as specified in 1012 section 6.2 of [CMS]. The ktri RecipientInfo choice MUST be 1013 supported. The key in the EncryptedKey field (i.e., the 1014 distributed shared KEK) MUST be generated according to the 1015 section concerning random number generation in the security 1016 considerations of [CMS]. 1018 - glkAlgorithm identifies the algorithm the shared KEK is used 1019 with. Since no encrypted data content is being conveyed at this 1020 point, the parameters encoded with the algorithm should be the 1021 structure defined for smimeCapabilities rather than encrypted 1022 content. 1024 - glkNotBefore indicates the date at which the shared KEK is 1025 considered valid. GeneralizedTime values MUST be expressed in 1026 UTC (Zulu) and MUST include seconds (i.e., times are 1028 Turner Expires July 2003 20 1029 And Distribution 1031 YYYYMMDDHHMMSSZ), even where the number of seconds is zero. 1032 GeneralizedTime values MUST NOT include fractional seconds. 1034 - glkNotAfter indicates the date after which the shared KEK is 1035 considered invalid. GeneralizedTime values MUST be expressed in 1036 UTC (Zulu) and MUST include seconds (i.e., times are 1037 YYYYMMDDHHMMSSZ), even where the number of seconds is zero. 1038 GeneralizedTime values MUST NOT include fractional seconds. 1040 If the glKey message is in response to a glUseKEK message: 1042 - The GLA MUST generate separate glKey messages for each recipient 1043 if glUseKEK.glKeyAttributes.recipientsNotMutuallyAware is set to 1044 TRUE. For each recipient, you want to generate a message that 1045 contains that recipient's key (i.e., one message with one 1046 attribute). 1048 - The GLA MUST generate the requested number of glKey messages. 1049 The value in glUseKEK.glKeyAttributes.generationCounter 1050 indicates the number of glKey messages requested. 1052 If the glKey message is in response to a glRekey message: 1054 - The GLA MUST generate separate glKey messages for each recipient 1055 if glRekey.glNewKeyAttributes.recipientsNotMutuallyAware is set 1056 to TRUE. 1058 - The GLA MUST generate the requested number of glKey messages. 1059 The value in glUseKEK.glKeyAttributes.generationCounter 1060 indicates the number of glKey messages requested. 1062 - The GLA MUST generate one glKey messagefor each outstanding 1063 shared KEKs for the GL when glRekeyAllGLKeys is set to TRUE. 1065 If the glKey message was not in response to a glRekey or glUseKEK 1066 (e.g., where the GLA controls rekey): 1068 - The GLA MUST generate separate glKey messages for each recipient 1069 when glUseKEK.glNewKeyAttributes.recipientsNotMutuallyAware that 1070 set up the GL was set to TRUE. 1072 - The GLA MAY generate glKey messages prior to the duration on the 1073 last outstanding shared KEK expiring, where the number of glKey 1074 messages generated is generationCounter minus one (1). Other 1075 distribution mechanisms can also be supported to support this 1076 functionality. 1078 3.2 Use of CMC, CMS, and PKIX 1080 The following sections outline the use of CMC, CMS, and the PKIX 1081 certificate and CRL profile. 1083 Turner Expires July 2003 21 1084 And Distribution 1086 3.2.1 Protection Layers 1088 The following sections outline the protection required for the 1089 control attributes defined in this document. 1091 Note: There are multiple ways to encapsulate SignedData and 1092 EnvelopedData. The first is to use a MIME wrapper around each 1093 ContentInfo, as specified in [MSG]. The second is to not use a MIME 1094 wrapper around each ContentInfo, as specified in Transporting S/MIME 1095 Objects in X.400 [X400TRANS]. 1097 3.2.1.1 Minimum Protection 1099 At a minimum, a SignedData MUST protect each request and response 1100 encapsulated in PKIData and PKIResponse. The following is a 1101 depiction of the minimum wrappings: 1103 Minimum Protection 1104 ------------------ 1105 SignedData 1106 PKIData or PKIResponse 1107 controlSequence 1109 Prior to taking any action on any request or response SignedData(s) 1110 MUST be processed according to [CMS]. 1112 3.2.1.2 Additional Protection 1114 An additional EnvelopedData MAY also be used to provide 1115 confidentiality of the request and response. An additional 1116 SignedData MAY also be added to provide authentication and integrity 1117 of the encapsulated EnvelopedData. The following is a depiction of 1118 the optional additional wrappings: 1120 Authentication and Integrity 1121 Confidentiality Protection of Confidentiality Protection 1122 -------------------------- ----------------------------- 1123 EnvelopedData SignedData 1124 SignedData EnvelopedData 1125 PKIData or PKIResponse SignedData 1126 controlSequence PKIData or PKIResponse 1127 controlSequence 1129 If an incoming message is encrypted, the confidentiality of the 1130 message MUST be preserved. All EnvelopedData objects MUST be 1131 processed as specified in [CMS]. If a SignedData is added over an 1133 Turner Expires July 2003 22 1134 And Distribution 1136 EnvelopedData, a ContentHints attribute SHOULD be added. See 1137 paragraph 2.9 of Extended Security Services for S/MIME [ESS]. 1139 If the GLO or GL member applies confidentiality to a request, the 1140 EnvelopedData MUST include the GLA as a recipient. If the GLA 1141 forwards the GL member request to the GLO, then the GLA MUST decrypt 1142 the EnvelopedData content, strip the confidentiality layer, and 1143 apply its own confidentiality layer as an EnvelopedData with the GLO 1144 as a recipient. 1146 3.2.2 Combining Requests and Responses 1148 Multiple requests and response corresponding to a GL MAY be included 1149 in one PKIData.controlSequence or PKIResponse.controlSequence. 1150 Requests and responses for multiple GLs MAY be combined in one 1151 PKIData or PKIResponse by using PKIData.cmsSequence and 1152 PKIResponse.cmsSequence. A separate cmsSequence MUST be used for 1153 different GLs. That is, requests corresponding to two different GLs 1154 are included in different cmsSequences. The following is a diagram 1155 depicting multiple requests and responses combined in one PKIData 1156 and PKIResponse: 1158 Multiple Request and Response 1159 Request Response 1160 ------- -------- 1161 SignedData SignedData 1162 PKIData PKIResponse 1163 cmsSequence cmsSequence 1164 SignedData SignedData 1165 PKIData PKIResponse 1166 controlSequence controlSequence 1167 One or more requests One or more responses 1168 corresponding to one GL corresponding to one GL 1169 SignedData SignedData 1170 PKIData PKIResponse 1171 controlSequence controlSequence 1172 One or more requests One or more responses 1173 corresponding to another GL corresponding to another GL 1175 Turner Expires July 2003 23 1176 And Distribution 1178 When applying confidentiality to multiple requests and responses, 1179 all of the requests/response MAY be included in one EnvelopedData. 1180 The following is a depiction: 1182 Confidentiality of Multiple Requests and Responses 1183 Wrapped Together 1184 ---------------- 1185 EnvelopedData 1186 SignedData 1187 PKIData 1188 cmsSequence 1189 SignedData 1190 PKIResponse 1191 controlSequence 1192 One or more requests 1193 corresponding to one GL 1194 SignedData 1195 PKIData 1196 controlSequence 1197 One or more requests 1198 corresponding to one GL 1200 Certain combinations of requests in one PKIData.controlSequence and 1201 one PKIResponse.controlSequence are not allowed. The invalid 1202 combinations listed here MUST NOT be generated: 1204 Invalid Combinations 1205 --------------------------- 1206 glUseKEK & glDeleteMember 1207 glUseKEK & glRekey 1208 glUseKEK & glDelete 1209 glDelete & glAddMember 1210 glDelete & glDeleteMember 1211 glDelete & glRekey 1212 glDelete & glAddOwner 1213 glDelete & glRemoveOwner 1215 To avoid unnecessary errors, certain requests and responses SHOULD 1216 be processed prior to others. The following is the priority of 1217 message processing, if not listed it is an implementation decision 1218 as to which to process first: glUseKEK before glAddMember, glRekey 1219 before glAddMember, and glDeleteMember before glRekey. Note that 1220 there is a processing priority but it does not imply an ordering 1221 within the content. 1223 3.2.3 GLA Generated Messages 1225 When the GLA generates a success or fail message, it generates one 1226 for each request. SKDFailInfo values of unsupportedDuration, 1228 Turner Expires July 2003 24 1229 And Distribution 1231 unsupportedDeliveryMethod, unsupportedAlgorithm, noGLONameMatch, 1232 nameAlreadyInUse, alreadyAnOwner, notAnOwner are not returned to GL 1233 members. 1235 If GLKeyAttributes.recipientsNotMutuallyAware is set to TRUE, a 1236 separate PKIResponse.cMCStatusInfoExt and PKIData.glKey MUST be 1237 generated for each recipient. However, it is valid to send one 1238 message with multiple attributes to the same recipient. 1240 If the GL has multiple GLOs, the GLA MUST send cMCStatusInfoExt 1241 messages to the requesting GLO. The mechanism to determine which GLO 1242 made the request is beyond the scope of this document. 1244 If a GL is managed and the GLA receives a glAddMember, 1245 glDeleteMember, or glkCompromise message, the GLA redirects the 1246 request to the GLO for review. An additional, SignedData MUST be 1247 applied to the redirected request as follows: 1249 GLA Forwarded Requests 1250 ---------------------- 1251 SignedData 1252 PKIData 1253 cmsSequence 1254 SignedData 1255 PKIData 1256 controlSequence 1258 3.2.4 CMC Control Attributes and CMS Signed Attributes 1260 CMC carries control attributes as CMS signed attributes. These 1261 attributes are defined in [CMC] and [CMS]. Some of these attributes 1262 are REQUIRED; others are OPTIONAL. The required attributes are as 1263 follows: cMCStatusInfoExt transactionId, senderNonce, 1264 recipientNonce, queryPending, and signingTime. Other attributes can 1265 also be used; however, their use is beyond the scope of this 1266 document. The following sections specify requirements in addition to 1267 those already specified in [CMC] and [CMS]. 1269 3.2.4.1 Using cMCStatusInfoExt 1271 cMCStatusInfoExt is used by GLAs to indicate to GLOs and GL members 1272 that a request was unsuccessful. Two classes of failure codes are 1273 used within this document. Errors from the CMCFailInfo list, found 1274 in section 5.1.4 of CMC, are encoded as defined in CMC. Error codes 1275 defined in this document are encoded using the ExtendedFailInfo 1276 field of the cmcStatusInfoExt structure. If the same failure code 1277 applies to multiple commands, a single cmcStatusInfoExt structure 1278 can be used with multiple items in cMCStatusInfoExt.bodyList. The 1279 GLA MAY also return other pertinent information in statusString. The 1280 SKDFailInfo object identifier and value are: 1282 Turner Expires July 2003 25 1283 And Distribution 1285 id-cet-skdFailInfo OBJECT IDENTIFIER ::= { iso(1) 1286 identified-organization(3) dod(6) internet(1) security(5) 1287 mechanisms(5) pkix(7) cet(15) skdFailInfo(1) } 1289 SKDFailInfo ::= INTEGER { 1290 unspecified (0), 1291 closedGL (1), 1292 unsupportedDuration (2), 1293 noGLACertificate (3), 1294 invalidCert (4), 1295 unsupportedAlgorithm (5), 1296 noGLONameMatch (6), 1297 invalidGLName (7), 1298 nameAlreadyInUse (8), 1299 noSpam (9), 1300 deniedAccess (10), 1301 alreadyAMember (11), 1302 notAMember (12), 1303 alreadyAnOwner (13), 1304 notAnOwner (14) } 1306 The values have the following meaning: 1308 - unspecified indicates that the GLA is unable or unwilling to 1309 perform the requested action and does not want to indicate the 1310 reason. 1312 - closedGL indicates that members can only be added or deleted by 1313 the GLO. 1315 - unsupportedDuration indicates the GLA does not support 1316 generating keys that are valid for the requested duration. 1318 - noGLACertificate indicates that the GLA does not have a valid 1319 certificate. 1321 - invalidCert indicates the member's encryption certificate was 1322 not verifiable (i.e., signature did not validate, certificate's 1323 serial number present on a CRL, expired, etc.). 1325 - unsupportedAlgorithm indicates the GLA does not support the 1326 requested algorithm. 1328 - noGLONameMatch indicates that one of the names in the 1329 certificate used to sign a request does not match the name of a 1330 registered GLO. 1332 - invalidGLName indicates the GLA does not support the glName 1333 present in the request. 1335 Turner Expires July 2003 26 1336 And Distribution 1338 - nameAlreadyInUse indicates the glName is already assigned on the 1339 GLA. 1341 - noSpam indicates the prospective GL member did not sign the 1342 request (i.e., if the name in glMember.glMemberName does not 1343 match one of the names (either the subject distinguished name or 1344 one of the subject alternative names) in the certificate used to 1345 sign the request). 1347 - alreadyAMember indicates the prospective GL member is already a 1348 GL member. 1350 - notAMember indicates the prospective GL member to be deleted is 1351 not presently a GL member. 1353 - alreadyAnOwner indicates the prospective GLO is already a GLO. 1355 - notAnOwner indicates the prospective GLO to be deleted is not 1356 presently a GLO. 1358 cMCStatusInfoExt is used by GLAs to indicate to GLOs and GL members 1359 that a request was successfully completed. If the request was 1360 successful, the GLA returns a cMCStatusInfoExt response with 1361 cMCStatus.success and optionally other pertinent information in 1362 statusString. 1364 When the GL is managed and the GLO has reviewed GL member initiated 1365 glAddMember, glDeleteMember, and glkComrpomise requests, the GLO 1366 uses cMCStatusInfoExt to indicate the success or failure of the 1367 request. If the request is allowed, cMCStatus.success is returned 1368 and statusString is optionally returned to convey additional 1369 information. If the request is denied, cMCStatus.failed is returned 1370 and statusString is optionally returned to convey additional 1371 information. Additionally, the appropriate SKDFailInfo can be 1372 included in cMCStatusInfoExt.extendedFailInfo. 1374 cMCStatusInfoExt is used by GLOs, GLAs, and GL members to indicate 1375 that signature verification failed. If the signature failed to 1376 verify over any control attibute except a cMCStatusInfoExt, a 1377 cMCStatusInfoExt control attribute MUST be returned indicating 1378 cMCStatus.failed and otherInfo.failInfo.badMessageCheck. If the 1379 signature over the outermost PKIData failed, the bodyList value is 1380 zero (0). If the signature over any other PKIData failed the 1381 bodyList value is the bodyPartId value from the request or response. 1382 GLOs and GL members who receive cMCStatusInfoExt messages whose 1383 signatures are invalid SHOULD generate a new request to avoid 1384 badMessageCheck message loops. 1386 cMCStatusInfoExt is also used by GLOs and GLAs to indicate that a 1387 request could not be performed immediately. If the request could not 1388 be processed immediately by the GLA or GLO, the cMCStatusInfoExt 1389 control attribute MUST be returned indicating cMCStatus.pending and 1391 Turner Expires July 2003 27 1392 And Distribution 1394 otherInfo.pendInfo. When requests are redirected to the GLO for 1395 approval (for managed lists), the GLA MUST NOT return a 1396 cMCStatusInfoExt indicating query pending. 1398 cMCStatusInfoExt is also used by GLAs to indicate that a 1399 glaQueryRequest is not supported. If the glaQueryRequest is not 1400 supported, the cMCStatusInfoExt control attribute MUST be returned 1401 indicating cMCStatus.noSupport and statusString is optionally 1402 returned to convey additional information. 1404 cMCStatusInfoExt is also used by GL members, GLOs, and GLAs to 1405 indicate that the signingTime (see section 3.2.4.3) is not close 1406 enough to the locally specified time. If the local time is not close 1407 enough to the time specified in signingTime, a cMCStatus.failed and 1408 otherInfo.failInfo.badTime MAY be returned. 1410 3.2.4.2 Using transactionId 1412 transactionId MAY be included by GLOs, GLAs, or GL members to 1413 identify a given transaction. All subsequent requests and responses 1414 related to the original request MUST include the same transactionId 1415 control attribute. If GL members include a transactionId and the 1416 request is redirected to the GLO, the GLA MAY include an additional 1417 transactionId in the outer PKIData. If the GLA included an 1418 additional transactionId in the outer PKIData, when the GLO 1419 generates a cMCStatusInfoExt response it generates one for the GLA 1420 with the GLA's transactionId and one for the GL member with the GL 1421 member's transactionId. 1423 3.2.4.3 Using nonces and signingTime 1425 The use of nonces (see section 5.6 of [CMC]) and an indication of 1426 when the message was signed (see section 11.3 of [CMS]) can be used 1427 to provide application-level replay prevention. 1429 To protect the GL, all messages MUST include the signingTime 1430 attribute. Message originators and recipients can then use the time 1431 provided in this attribute to determine whether they have previously 1432 received the message. 1434 If the originating message includes a senderNonce, the response to 1435 the message MUST include the received senderNonce value as the 1436 recipientNonce and a new value as the senderNonce value in the 1437 response. 1439 If a GLA aggragates multiple messages together or forwards a message 1440 to a GLO, the GLA MAY optionally generate a new nonce value and 1441 include that in the wrapping message. When the response comes back 1442 from the GLO, the GLA builds a response to the originator(s) of the 1444 Turner Expires July 2003 28 1445 And Distribution 1447 message(s) and deals with each of the nonce values from the 1448 originating messages. 1450 For these attributes it is necessary to maintain state information 1451 on exchanges to compare one result to another. The time period for 1452 which this information is maintained in a local policy. 1454 3.2.4.4 CMC and CMS Attribute Support Requirements 1456 The following are the implementation requirements for CMC control 1457 attributes and CMS signed attributes for an implementation be 1458 considered conformant to this specification: 1460 Implementation Requirement | 1461 GLO | GLA | GL Member | Attribute 1462 O R | O R F | O R | 1463 --------- | ------------- | --------- | ---------- 1464 MUST MUST | MUST MUST - | MUST MUST | cMCStatusInfoExt 1465 MAY MAY | MUST MUST - | MAY MAY | transactionId 1466 MAY MAY | MUST MUST - | MAY MAY | senderNonce 1467 MAY MAY | MUST MUST - | MAY MAY | recepientNonce 1468 MUST MUST | MUST MUST - | MUST MUST | SKDFailInfo 1469 MUST MUST | MUST MUST - | MUST MUST | signingTime 1471 3.2.5 Resubmitted GL Member Messages 1473 When the GL is managed, the GLA forwards the GL member requests to 1474 the GLO for GLO approval by creating a new request message 1475 containing the GL member request(s) as a cmsSequence item. If the 1476 GLO approves the request it can either add a new layer of wrapping 1477 and send it back to the GLA or create a new message and send it to 1478 the GLA. (Note in this case there are now 3 layers of PKIData 1479 messages with appropriate signing layers.) 1481 3.2.6 PKIX Certificate and CRL Profile 1483 Signatures, certificates, and CRLs are verified according to the 1484 PKIX profile [PROFILE]. 1486 Name matching is performed according to the PKIX profile [PROFILE]. 1488 All distinguished name forms must follow the UTF8String convention 1489 noted in the PKIX profile [PROFILE]. 1491 A certificate per-GL would be issued to the GLA. 1493 GL policy may mandate that the GL member's address be included in 1494 the GL member's certificate. 1496 Turner Expires July 2003 29 1497 And Distribution 1499 4 Administrative Messages 1501 There are a number of administrative messages that must be performed 1502 to manage a GL. The following sections describe each request and 1503 response message combination in detail. The procedures defined in 1504 this section are not prescriptive. 1506 4.1 Assign KEK To GL 1508 Prior to generating a group key, a GL needs to be setup and a shared 1509 KEK assigned to the GL. Figure 3 depicts the protocol interactions 1510 to setup and assign a shared KEK. Note that error messages are not 1511 depicted in Figure 3. Additionally, behavior for the optional 1512 transactionId, senderNonce, and recipientNonce CMC control 1513 attributes is not addressed in these procedures. 1515 +-----+ 1 2 +-----+ 1516 | GLA | <-------> | GLO | 1517 +-----+ +-----+ 1519 Figure 3 - Create Group List 1521 The process is as follows: 1523 1 - The GLO is the entity responsible for requesting the creation 1524 of the GL. The GLO sends a 1525 SignedData.PKIData.controlSequence.glUseKEK request to the GLA 1526 (1 in Figure 3). The GLO MUST include: glName, glAddress, 1527 glOwnerName, glOwnerAddress, and glAdministration. The GLO MAY 1528 also include their preferences for the shared KEK in 1529 glKeyAttributes by indicating whether the GLO controls the 1530 rekey in rekeyControlledByGLO, whether separate glKey messages 1531 should be sent to each recipient in 1532 recipientsNotMutuallyAware, the requested algorithm to be used 1533 with the shared KEK in requestedAlgorithm, the duration of the 1534 shared KEK, and how many shared KEKs should be initially 1535 distributed in generationCounter. The GLO MUST also include 1536 the signingTime attribute with this request. 1538 1.a - If the GLO knows of members to be added to the GL, the 1539 glAddMember request(s) MAY be included in the same 1540 controlSequence as the glUseKEK request (see section 3.2.2). 1541 The GLO indicates the same glName in the glAddMember request 1542 as in glUseKEK.glInfo.glName. Further glAddMember procedures 1543 are covered in section 4.3. 1545 1.b - The GLO can apply confidentiality to the request by 1546 encapsulating the SignedData.PKIData in an EnvelopedData 1547 (see section 3.2.1.2). 1549 Turner Expires July 2003 30 1550 And Distribution 1552 1.c - The GLO can also optionally apply another SignedData over 1553 the EnvelopedData (see section 3.2.1.2). 1555 2 - Upon receipt of the request, the GLA checks the signingTime 1556 and verifies the signature on the inner most 1557 SignedData.PKIData. If an additional SignedData and/or 1558 EnvelopedData encapsulates the request (see sections 3.2.1.2 1559 and 3.2.2), the GLA verifies the outer signature(s) and/or 1560 decrypt the outer layer(s) prior to verifying the signature on 1561 the inner most SignedData. 1563 2.a - If the signingTime attribute value is not within the locally 1564 accepted time window, the GLA MAY return a response 1565 indicating cMCStatus.failed and otherInfo.failInfo.badTime 1566 and a signingTime attribute. 1568 2.b - Else if signature processing continues and if the signatures 1569 do not verify, the GLA returns a cMCStatusInfoExt response 1570 indicating cMCStatus.failed and 1571 otherInfo.failInfo.badMessageCheck. Additionally, a 1572 signingTime attribute is included with the response. 1574 2.c � Else if the signatures do verify but the GLA does not have a 1575 valid certificate, the GLA returns a cMCStatusInfoExt with 1576 cMCStatus.failed and otherInfo.extendedFailInfo.SKDFailInfo 1577 value of noValidGLACertificate. Additionally, a signingTime 1578 attribute is included with the response. Instead of 1579 immediately returning the error code, the GLA attempts to 1580 get a certificate, possibly using [CMC]. 1582 2.d - Else the signatures are valid and the GLA does have a valid 1583 certificate, the GLA checks that one of the names in the 1584 certificate used to sign the request matches one of the 1585 names in glUseKEK.glOwnerInfo.glOwnerName. 1587 2.d.1 - If the names do not match, the GLA returns a response 1588 indicating cMCStatusInfoExt with cMCStatus.failed and 1589 otherInfo.extendedFailInfo.SKDFailInfo value of 1590 noGLONameMatch. Additionally, a signingTime attribute is 1591 included with the response. 1593 2.d.2 - Else if the names all match, the GLA checks that the 1594 glName and glAddress is not already in use. The GLA also 1595 checks any glAddMember included within the controlSequence 1596 with this glUseKEK. Further processing of the glAddMember 1597 is covered in section 4.3. 1599 2.d.2.a - If the glName is already in use the GLA returns a 1600 response indicating cMCStatusInfoExt with 1601 cMCStatus.failed and 1602 otherInfo.extendedFailInfo.SKDFailInfo value of 1604 Turner Expires July 2003 31 1605 And Distribution 1607 nameAlreadyInUse. Additionally, a signingTime attribute 1608 is included with the response. 1610 2.d.2.b - Else if the requestedAlgorithm is not supported, the GLA 1611 returns a response indicating cMCStatusInfoExt with 1612 cMCStatus.failed and 1613 otherInfo.extendedFailInfo.SKDFailInfo value of 1614 unsupportedAlgorithm. Additionally, a signingTime 1615 attribute is included with the response. 1617 2.d.2.c - Else if the duration cannot be supported, determining 1618 this is beyond the scope of this document, the GLA 1619 returns a response indicating cMCStatusInfoExt with 1620 cMCStatus.failed and 1621 otherInfo.extendedFailInfo.SKDFailInfo value of 1622 unsupportedDuration. Additionally, a signingTime 1623 attribute is included with the response. 1625 2.d.2.d - Else if the GL cannot be supported for other reasons, 1626 which the GLA does not wish to disclose, the GLA returns 1627 a response indicating cMCStatusInfoExt with 1628 cMCStatus.failed and 1629 otherInfo.extendedFailInfo.SKDFailInfo value of 1630 unspecified. Additionally, a signingTime attribute is 1631 included with the response. 1633 2.d.2.e - Else if the glName is not already in use, the duration 1634 can be supported, and the requestedAlgorithm is 1635 supported, the GLA MUST return a cMCStatusInfoExt 1636 indicating cMCStatus.success and a signingTime 1637 attribute. (2 in Figure 3). The GLA also takes 1638 administrative actions, which are beyond the scope of 1639 this document, to store the glName, glAddress, 1640 glKeyAttributes, glOwnerName, and glOwnerAddress. The 1641 GLA also sends a glKey message as described in section 1642 5. 1644 2.d.2.e.1 - The GLA can apply confidentiality to the response by 1645 encapsulating the SignedData.PKIResponse in an 1646 EnvelopedData if the request was encapsulated in an 1647 EnvelopedData (see section 3.2.1.2). 1649 2.d.2.e.2 - The GLA can also optionally apply another SignedData 1650 over the EnvelopedData (see section 3.2.1.2). 1652 3 - Upon receipt of the cMCStatusInfoExt responses, the GLO checks 1653 the signingTime and verifies the GLA signature(s). If an 1654 additional SignedData and/or EnvelopedData encapsulates the 1655 response (see section 3.2.1.2 or 3.2.2), the GLO verifies the 1656 outer signature and/or decrypt the outer layer prior to 1657 verifying the signature on the inner most SignedData. 1659 Turner Expires July 2003 32 1660 And Distribution 1662 3.a - If the signingTime attribute value is not within the locally 1663 accepted time window, the GLO MAY return a response 1664 indicating cMCStatus.failed and otherInfo.failInfo.badTime 1665 and a signingTime attribute. 1667 3.b - Else if signature processing continues and if the signatures 1668 do verify, the GLO MUST check that one of the names in the 1669 certificate used to sign the response matches the name of 1670 the GL. 1672 3.b.1 - If the name of the GL does not match the name present in 1673 the certificate used to sign the message, the GLO should 1674 not believe the response. 1676 3.b.2 - Else if the name of the GL does match the name present in 1677 the certificate and: 1679 3.b.2.a - If the signatures do verify and the response was 1680 cMCStatusInfoExt indicating cMCStatus.success, the GLO 1681 has successfully created the GL. 1683 3.b.2.b - Else if the signatures are valid and the response is 1684 cMCStatusInfoExt.cMCStatus.failed with any reason, the 1685 GLO can reattempt to create the GL using the information 1686 provided in the response. The GLO can also use the 1687 glaQueryRequest to determine the algorithms and other 1688 characteristics supported by the GLA (see section 4.9). 1690 4.2 Delete GL From GLA 1692 From time to time, there are instances when a GL is no longer 1693 needed. In this case, the GLO deletes the GL. Figure 4 depicts that 1694 protocol interactions to delete a GL. Note that behavior for the 1695 optional transactionId, senderNonce, and recipientNonce CMC control 1696 attributes is not addressed in these procedures. 1698 +-----+ 1 2 +-----+ 1699 | GLA | <-------> | GLO | 1700 +-----+ +-----+ 1702 Figure 4 - Delete Group List 1704 The process is as follows: 1706 1 - The GLO is responsible for requesting the deletion of the GL. 1707 The GLO sends a SignedData.PKIData.controlSequence.glDelete 1708 request to the GLA (1 in Figure 4). The name of the GL to be 1709 deleted is included in GeneralName. The GLO MUST also include 1710 the signingTime attribute and can also include a transactionId 1711 and senderNonce attributes. 1713 Turner Expires July 2003 33 1714 And Distribution 1716 1.a - The GLO can optionally apply confidentiality to the request 1717 by encapsulating the SignedData.PKIData in an EnvelopedData 1718 (see section 3.2.1.2). 1720 1.b - The GLO MAY optionally apply another SignedData over the 1721 EnvelopedData (see section 3.2.1.2). 1723 2 - Upon receipt of the request the GLA checks the signingTime and 1724 verifies the signature on the inner most SignedData.PKIData. 1725 If an additional SignedData and/or EnvelopedData encapsulates 1726 the request (see section 3.2.1.2 or 3.2.2), the GLA verifies 1727 the outer signature and/or decrypt the outer layer prior to 1728 verifying the signature on the inner most SignedData. 1730 2.a - If the signingTime attribute value is not within the locally 1731 accepted time window, the GLA MAY return a response 1732 indicating cMCStatus.failed and otherInfo.failInfo.badTime 1733 and a signingTime attribute. 1735 2.b - Else if signature processing continues and if the signatures 1736 cannot be verified, the GLA returns a cMCStatusInfoExt 1737 response indicating cMCStatus.failed and 1738 otherInfo.failInfo.badMessageCheck. Additionally, a 1739 signingTime attribute is included with the response. 1741 2.c - Else if the signatures verify, the GLA makes sure the GL is 1742 supported by checking the name of the GL matches a glName 1743 stored on the GLA. 1745 2.c.1 - If the glName is not supported by the GLA, the GLA returns 1746 a response indicating cMCStatusInfoExt with 1747 cMCStatus.failed and 1748 otherInfo.extendedFailInfo.SKDFailInfo value of 1749 invalidGLName. Additionally, a signingTime attribute is 1750 included with the response. 1752 2.c.2 - Else if the glName is supported by the GLA, the GLA 1753 ensures a registered GLO signed the glDelete request by 1754 checking if one of the names present in the digital 1755 signature certificate used to sign the glDelete request 1756 matches a registered GLO. 1758 2.c.2.a - If the names do not match, the GLA returns a response 1759 indicating cMCStatusInfoExt with cMCStatus.failed and 1760 otherInfo.extendedFailInfo.SKDFailInfo value of 1761 noGLONameMatch. Additionally, a signingTime attribute is 1762 included with the response. 1764 2.c.2.b - Else if the names do match, but the GL cannot be deleted 1765 for other reasons, which the GLA does not wish to 1766 disclose, the GLA returns a response indicating 1768 Turner Expires July 2003 34 1769 And Distribution 1771 cMCStatusInfoExt with cMCStatus.failed and 1772 otherInfo.extendedFailInfo.SKDFailInfo value of 1773 unspecified. Additionally, a signingTime attribute is 1774 included with the response. Actions beyond the scope of 1775 this document must then be taken to delete the GL from 1776 the GLA. 1778 2.c.2.c - Else if the names do match, the GLA returns a 1779 cMCStatusInfoExt indicating cMCStatus.success and a 1780 signingTime attribute (2 in Figure 4). The GLA ought not 1781 accept further requests for member additions, member 1782 deletions, or group rekeys for this GL. 1784 2.c.2.c.1 - The GLA can apply confidentiality to the response by 1785 encapsulating the SignedData.PKIResponse in an 1786 EnvelopedData if the request was encapsulated in an 1787 EnvelopedData (see section 3.2.1.2). 1789 2.c.2.c.2 - The GLA MAY optionally apply another SignedData over 1790 the EnvelopedData (see section 3.2.1.2). 1792 3 - Upon receipt of the cMCStatusInfoExt response, the GLO checks 1793 the signingTime and verifies the GLA signature(s). If an 1794 additional SignedData and/or EnvelopedData encapsulates the 1795 response (see section 3.2.1.2 or 3.2.2), the GLO verifies the 1796 outer signature and/or decrypt the outer layer prior to 1797 verifying the signature on the inner most SignedData. 1799 3.a - If the signingTime attribute value is not within the locally 1800 accepted time window, the GLO MAY return a response 1801 indicating cMCStatus.failed and otherInfo.failInfo.badTime 1802 and a signingTime attribute. 1804 3.b - Else if signature processing continues and if the signatures 1805 verify, the GLO checks that one of the names in the 1806 certificate used to sign the response matches the name of 1807 the GL. 1809 3.b.1 � If the name of the GL does not match the name present in 1810 the certificate used to sign the message, the GLO should 1811 not believe the response. 1813 3.b.2 � Else if the name of the GL does match the name present in 1814 the certificate and: 1816 3.b.2.a - If the signatures verify and the response was 1817 cMCStatusInfoExt indicating cMCStatus.success, the GLO 1818 has successfully deleted the GL. 1820 3.b.2.b - Else if the signatures do verify and the response was 1821 cMCStatusInfoExt.cMCStatus.failed with any reason, the 1823 Turner Expires July 2003 35 1824 And Distribution 1826 GLO can reattempt to delete the GL using the information 1827 provided in the response. 1829 4.3 Add Members To GL 1831 To add members to GLs, either the GLO or prospective members use the 1832 glAddMember request. The GLA processes GLO and prospective GL member 1833 requests differently though. GLOs can submit the request at any time 1834 to add members to the GL, and the GLA, once it has verified the 1835 request came from a registered GLO, should process it. If a 1836 prospective member sends the request, the GLA needs to determine how 1837 the GL is administered. When the GLO initially configured the GL, 1838 they set the GL to be unmanaged, managed, or closed (see section 1839 3.1.1). In the unmanaged case, the GLA merely processes the member's 1840 request. For the managed case, the GLA forwards the requests from 1841 the prospective members to the GLO for review. Where there are 1842 multiple GLOs for a GL, which GLO the request is forwarded to is 1843 beyond the scope of this document. The GLO reviews the request and 1844 either rejects it or submits a reformed request to the GLA. In the 1845 closed case, the GLA will not accept requests from prospective 1846 members. The following sections describe the processing for the 1847 GLO(s), GLA, and prospective GL members depending on where the 1848 glAddMeber request originated, either from a GLO or from prospective 1849 members. Figure 5 depicts the protocol interactions for the three 1850 options. Note that the error messages are not depicted. 1851 Additionally, note that behavior for the optional transactionId, 1852 senderNonce, and recipientNonce CMC control attributes is not 1853 addressed in these procedures. 1855 +-----+ 2,B{A} 3 +----------+ 1856 | GLO | <--------+ +-------> | Member 1 | 1857 +-----+ | | +----------+ 1858 1 | | 1859 +-----+ <--------+ | 3 +----------+ 1860 | GLA | A +-------> | ... | 1861 +-----+ <-------------+ +----------+ 1862 | 1863 | 3 +----------+ 1864 +-------> | Member n | 1865 +----------+ 1867 Figure 5 - Member Addition 1869 An important decision that needs to be made on a group by group 1870 basis is whether to rekey the group every time a new member is 1871 added. Typically, unmanaged GLs should not be rekeyed when a new 1872 member is added, as the overhead associated with rekeying the group 1873 becomes prohibitive, as the group becomes large. However, managed 1874 and closed GLs can be rekeyed to maintain the confidentiality of the 1875 traffic sent by group members. An option to rekeying managed or 1876 closed GLs when a member is added is to generate a new GL with a 1878 Turner Expires July 2003 36 1879 And Distribution 1881 different group key. Group rekeying is discussed in sections 4.5 and 1882 5. 1884 4.3.1 GLO Initiated Additions 1886 The process for GLO initiated glAddMember requests is as follows: 1888 1 - The GLO collects the pertinent information for the member(s) 1889 to be added (this may be done through an out of bands means). 1890 The GLO then sends a SignedData.PKIData.controlSequence with a 1891 separate glAddMember request for each member to the GLA (1 in 1892 Figure 5). The GLO includes: the GL name in glName, the 1893 member's name in glMember.glMemberName, the member's address 1894 in glMember.glMemberAddress, and the member's encryption 1895 certificate in glMember.certificates.pKC. The GLO can also 1896 include any attribute certificates associated with the 1897 member's encryption certificate in glMember.certificates.aC, 1898 and the certification path associated with the member's 1899 encryption and attribute certificates in 1900 glMember.certificates.certPath. The GLO MUST also include the 1901 signingTime attribute with this request. 1903 1.a - The GLO can optionally apply confidentiality to the request 1904 by encapsulating the SignedData.PKIData in an EnvelopedData 1905 (see section 3.2.1.2). 1907 1.b - The GLO can also optionally apply another SignedData over 1908 the EnvelopedData (see section 3.2.1.2). 1910 2 - Upon receipt of the request, the GLA checks the signingTime 1911 and verifies the signature on the inner most 1912 SignedData.PKIData. If an additional SignedData and/or 1913 EnvelopedData encapsulates the request (see section 3.2.1.2 or 1914 3.2.2), the GLA verifies the outer signature and/or decrypt 1915 the outer layer prior to verifying the signature on the inner 1916 most SignedData. 1918 2.a - If the signingTime attribute value is not within the locally 1919 accepted time window, the GLA MAY return a response 1920 indicating cMCStatus.failed and otherInfo.failInfo.badTime 1921 and a signingTime attribute. 1923 2.b - Else if signature processing continues and if the signatures 1924 cannot be verified, the GLA returns a cMCStatusInfoExt 1925 response indicating cMCStatus.failed and 1926 otherInfo.failInfo.badMessageCheck. Additionally, a 1927 signingTime attribute is included with the response. 1929 2.c - Else if the signatures verify, the glAddMember request is 1930 included in a controlSequence with the glUseKEK request, and 1931 the processing in section 4.1 item 2.e is successfully 1933 Turner Expires July 2003 37 1934 And Distribution 1936 completed the GLA returns a cMCStatusInfoExt indicating 1937 cMCStatus.success and a signingTime attribute (2 in Figure 1938 5). 1940 2.c.1 - The GLA can apply confidentiality to the response by 1941 encapsulating the SignedData.PKIData in an EnvelopedData 1942 if the request was encapsulated in an EnvelopedData (see 1943 section 3.2.1.2). 1945 2.c.2 - The GLA can also optionally apply another SignedData over 1946 the EnvelopedData (see section 3.2.1.2). 1948 2.d - Else if the signatures verify and the GLAddMember request is 1949 not included in a controlSequence with the GLCreate request, 1950 the GLA makes sure the GL is supported by checking that the 1951 glName matches a glName stored on the GLA. 1953 2.d.1 - If the glName is not supported by the GLA, the GLA returns 1954 a response indicating cMCStatusInfoExt with 1955 cMCStatus.failed and 1956 otherInfo.extendedFailInfo.SKDFailInfo value of 1957 invalidGLName. Additionally, a signingTime attribute is 1958 included with the response. 1960 2.d.2 - Else if the glName is supported by the GLA, the GLA checks 1961 to see if the glMemberName is present on the GL. 1963 2.d.2.a - If the glMemberName is present on the GL, the GLA 1964 returns a response indicating cMCStatusInfoExt with 1965 cMCStatus.failed and 1966 otherInfo.extendedFailInfo.SKDFailInfo value of 1967 alreadyAMember. Additionally, a signingTime attribute is 1968 included with the response. 1970 2.d.2.b - Else if the glMemberName is not present on the GL, the 1971 GLA checks how the GL is administered. 1973 2.d.2.b.1 - If the GL is closed, the GLA checks that a registered 1974 GLO signed the request by checking that one of the 1975 names in the digital signature certificate used to 1976 sign the request matches a registered GLO. 1978 2.d.2.b.1.a - If the names do not match, the GLA returns a 1979 response indicating cMCStatusInfoExt with 1980 cMCStatus.failed and 1981 otherInfo.extendedFailInfo.SKDFailInfo value of 1982 noGLONameMatch. Additionally, a signingTime 1983 attribute is included with the response. 1985 2.d.2.b.1.b - Else if the names match, the GLA verifies the 1986 member's encryption certificate. 1988 Turner Expires July 2003 38 1989 And Distribution 1991 2.d.2.b.1.b.1 - If the member's encryption certificate cannot be 1992 verified, the GLA can return a response indicating 1993 cMCStatusInfoExt with cMCStatus.failed and 1994 otherInfo.extendedFailInfo.SKDFailInfo value of 1995 invalidCert to the GLO. Additionally, a 1996 signingTime attribute is included with the 1997 response. If the GLA does not return a 1998 cMCStatusInfoExt.cMCStatus.failed response, the 1999 GLA issues a glProvideCert request (see section 2000 4.10). 2002 2.d.2.b.1.b.2 - Else if the member's certificate verifies, the GLA 2003 returns a cMCStatusInfoExt indicating 2004 cMCStatus.success and a signingTime attribute (2 2005 in Figure 5). The GLA also takes administrative 2006 actions, which are beyond the scope of this 2007 document, to add the member to the GL stored on 2008 the GLA. The GLA also distributes the shared KEK 2009 to the member via the mechanism described in 2010 section 5. 2012 2.d.2.b.1.b.2.a - The GLA applies confidentiality to the response 2013 by encapsulating the SignedData.PKIData in an 2014 EnvelopedData if the request was encapsulated in 2015 an EnvelopedData (see section 3.2.1.2). 2017 2.d.2.b.1.b.2.b - The GLA can also optionally apply another 2018 SignedData over the EnvelopedData (see section 2019 3.2.1.2). 2021 2.d.2.b.2 - Else if the GL is managed, the GLA checks that either 2022 a registered GLO or the prospective member signed the 2023 request. For GLOs, one of the names in the certificate 2024 used to sign the request needs to match a registered 2025 GLO. For the prospective member, the name in 2026 glMember.glMemberName needs to match one of the names 2027 in the certificate used to sign the request. 2029 2.d.2.b.2.a - If the signer is neither a registered GLO nor the 2030 prospective GL member, the GLA returns a response 2031 indicating cMCStatusInfoExt with cMCStatus.failed 2032 and otherInfo.extendedFailInfo.SKDFailInfo value of 2033 noSpam. Additionally, a signingTime attribute is 2034 included with the response. 2036 2.d.2.b.2.b - Else if the signer is a registered GLO, the GLA 2037 verifies the member's encryption certificate. 2039 2.d.2.b.2.b.1 - If the member's certificate cannot be verified, 2040 the GLA can return a response indicating 2041 cMCStatusInfoExt with cMCStatus.failed and 2042 otherInfo.extendedFailInfo.SKDFailInfo value of 2044 Turner Expires July 2003 39 2045 And Distribution 2047 invalidCert. Additionally, a signingTime attribute 2048 is included with the response. If the GLA does not 2049 return a cMCStatus.failed response, the GLA MUST 2050 issue a glProvideCert request (see section 4.10). 2052 2.d.2.b.2.b.2 - Else if the member's certificate verifies, the GLA 2053 MUST return a cMCStatusInfoExt indicating 2054 cMCStatus.success and a signingTime attribute to 2055 the GLO (2 in Figure 5). The GLA also takes 2056 administrative actions, which are beyond the scope 2057 of this document, to add the member to the GL 2058 stored on the GLA. The GLA also distributes the 2059 shared KEK to the member via the mechanism 2060 described in section 5. The GL policy may mandate 2061 that the GL member's address be included in the GL 2062 member's certificate. 2064 2.d.2.b.2.b.2.a - The GLA applies confidentiality to the response 2065 by encapsulating the SignedData.PKIData in an 2066 EnvelopedData if the request was encapsulated in 2067 an EnvelopedData (see section 3.2.1.2). 2069 2.d.2.b.2.b.2.b - The GLA can also optionally apply another 2070 SignedData over the EnvelopedData (see section 2071 3.2.1.2). 2073 2.d.2.b.2.c - Else if the signer is the prospective member, the 2074 GLA forwards the glAddMember request (see section 2075 3.2.3) to a registered GLO (B{A} in Figure 5). If 2076 there is more than one registered GLO, the GLO to 2077 which the request is forwarded to is beyond the 2078 scope of this document. Further processing of the 2079 forwarded request by GLOs is addressed in 3 of 2080 section 4.3.2. 2082 2.d.2.b.2.c.1 - The GLA applies confidentiality to the forwarded 2083 request by encapsulating the SignedData.PKIData in 2084 an EnvelopedData if the original request was 2085 encapsulated in an EnvelopedData (see section 2086 3.2.1.2). 2088 2.d.2.b.2.c.2 - The GLA can also optionally apply another 2089 SignedData over the EnvelopedData (see section 2090 3.2.1.2). 2092 2.d.2.b.3 - Else if the GL is unmanaged, the GLA checks that 2093 either a registered GLO or the prospective member 2094 signed the request. For GLOs, one of the names in the 2095 certificate used to sign the request needs tp match 2096 the name of a registered GLO. For the prospective 2097 member, the name in glMember.glMemberName needs to 2099 Turner Expires July 2003 40 2100 And Distribution 2102 match one of the names in the certificate used to sign 2103 the request. 2105 2.d.2.b.3.a - If the signer is neither a registered GLO nor the 2106 prospective member, the GLA returns a response 2107 indicating cMCStatusInfoExt with cMCStatus.failed 2108 and otherInfo.extendedFailInfo.SKDFailInfo value of 2109 noSpam. Additionally, a signingTime attribute is 2110 included with the response. 2112 2.d.2.b.3.b - Else if the signer is either a registered GLO or the 2113 prospective member, the GLA verifies the member's 2114 encryption certificate. 2116 2.d.2.b.3.b.1 - If the member's certificate cannot be verified, 2117 the GLA can return a response indicating 2118 cMCStatusInfoExt with cMCStatus.failed and 2119 otherInfo.extendedFailInfo.SKDFailInfo value of 2120 invalidCert and a signingTime attribute to either 2121 the GLO or the prospective member depending on 2122 where the request originated. If the GLA does not 2123 return a cMCStatus.failed response, the GLA issues 2124 a glProvideCert request (see section 4.10) to 2125 either the GLO or prospective member depending on 2126 where the request originated. 2128 2.d.2.b.3.b.2 - Else if the member's certificate verifies, the GLA 2129 returns a cMCStatusInfoExt indicating 2130 cMCStatus.success and a signingTime attribute to 2131 the GLO (2 in Figure 5) if the GLO signed the 2132 request and to the GL member (3 in Figure 5) if 2133 the GL member signed the request. The GLA also 2134 takes administrative actions, which are beyond the 2135 scope of this document, to add the member to the 2136 GL stored on the GLA. The GLA also distributes the 2137 shared KEK to the member via the mechanism 2138 described in section 5. 2140 2.d.2.b.3.b.2.a - The GLA applies confidentiality to the response 2141 by encapsulating the SignedData.PKIData in an 2142 EnvelopedData if the request was encapsulated in 2143 an EnvelopedData (see section 3.2.1.2). 2145 2.d.2.b.3.b.2.b - The GLA can also optionally apply another 2146 SignedData over the EnvelopedData (see section 2147 3.2.1.2). 2149 3 - Upon receipt of the cMCStatusInfoExt response, the GLO checks 2150 the signingTime and verifies the GLA signature(s). If an 2151 additional SignedData and/or EnvelopedData encapsulates the 2152 response (see section 3.2.1.2 or 3.2.2), the GLO verifies the 2154 Turner Expires July 2003 41 2155 And Distribution 2157 outer signature and/or decrypt the outer layer prior to 2158 verifying the signature on the inner most SignedData. 2160 3.a - If the signingTime attribute value is not within the locally 2161 accepted time window, the GLO MAY return a response 2162 indicating cMCStatus.failed and otherInfo.failInfo.badTime 2163 and a signingTime attribute. 2165 3.b - Else if signature processing continues and if the signatures 2166 verify, the GLO checks that one of the names in the 2167 certificate used to sign the response matches the name of 2168 the GL. 2170 3.b.1 � If the name of the GL does not match the name present in 2171 the certificate used to sign the message, the GLO should 2172 not believe the response. 2174 3.b.2 � Else if the name of the GL matches the name present in the 2175 certificate and: 2177 3.b.2.a - If the signatures verify and the response is 2178 cMCStatusInfoExt indicating cMCStatus.success, the GLA 2179 has added the member to the GL. If member was added to a 2180 managed list and the original request was signed by the 2181 member, the GLO sends a 2182 cMCStatusInfoExt.cMCStatus.success and a signingTime 2183 attribute to the GL member. 2185 3.b.2.b - Else if the GLO received a 2186 cMCStatusInfoExt.cMCStatus.failed with any reason, the 2187 GLO can reattempt to add the member to the GL using the 2188 information provided in the response. 2190 4 - Upon receipt of the cMCStatusInfoExt response, the prospective 2191 member checks the signingTime and verifies the GLA signatures 2192 or GLO signatures. If an additional SignedData and/or 2193 EnvelopedData encapsulates the response (see section 3.2.1.2 2194 or 3.2.2), the GLO verifies the outer signature and/or decrypt 2195 the outer layer prior to verifying the signature on the inner 2196 most SignedData. 2198 4.a - If the signingTime attribute value is not within the locally 2199 accepted time window, the prospective member MAY return a 2200 response indicating cMCStatus.failed and 2201 otherInfo.failInfo.badTime and a signingTime attribute. 2203 4.b - Else if signature processing continues and if the signatures 2204 verify, the GL member checks that one of the names in the 2205 certificate used to sign the response matches the name of 2206 the GL. 2208 Turner Expires July 2003 42 2209 And Distribution 2211 4.b.1 - If the name of the GL does not match the name present in 2212 the certificate used to sign the message, the GL member 2213 should not believe the response. 2215 4.b.2 � Else if the name of the GL matches the name present in the 2216 certificate and: 2218 4.b.2.a - If the signatures verify, the prospective member has 2219 been added to the GL. 2221 4.b.2.b - Else if the prospective member received a 2222 cMCStatusInfoExt.cMCStatus.failed, for any reason, the 2223 prospective member MAY reattempt to add themselves to 2224 the GL using the information provided in the response. 2226 4.3.2 Prospective Member Initiated Additions 2228 The process for prospective member initiated glAddMember requests is 2229 as follows: 2231 1 - The prospective GL member sends a 2232 SignedData.PKIData.controlSequence.glAddMember request to the 2233 GLA (A in Figure 5). The prospective GL member includes: the 2234 GL name in glName, their name in glMember.glMemberName, their 2235 address in glMember.glMemberAddress, and their encryption 2236 certificate in glMember.certificates.pKC. The prospective GL 2237 member can also include any attribute certificates associated 2238 with their encryption certificate in glMember.certificates.aC, 2239 and the certification path associated with their encryption 2240 and attribute certificates in glMember.certificates.certPath. 2241 The prosepective member MUST also include the signingTime 2242 attribute with this request. 2244 1.a - The prospective GL member can optionally apply 2245 confidentiality to the request by encapsulating the 2246 SignedData.PKIData in an EnvelopedData (see section 2247 3.2.1.2). 2249 1.b - The prospective GL member MAY optionally apply another 2250 SignedData over the EnvelopedData (see section 3.2.1.2). 2252 2 - Upon receipt of the request, the GLA verifies the request as 2253 per 2 in section 4.3.1. 2255 3 - Upon receipt of the forwarded request, the GLO checks the 2256 signingTime and verifies the prospective GL member signature 2257 on the inner most SignedData.PKIData and the GLA signature on 2258 the outer layer. If an EnvelopedData encapsulates the inner 2259 most layer (see section 3.2.1.2 or 3.2.2), the GLO decrypts 2260 the outer layer prior to verifying the signature on the inner 2261 most SignedData. 2263 Turner Expires July 2003 43 2264 And Distribution 2266 Note: For cases where the GL is closed and either a) a 2267 prospective member sends directly to the GLO or b) the GLA has 2268 mistakenly forwarded the request to the GLO, the GLO should 2269 first determine whether to honor the request. 2271 3.a - If the signingTime attribute value is not within the locally 2272 accepted time window, the GLO MAY return a response 2273 indicating cMCStatus.failed and otherInfo.failInfo.badTime. 2275 3.b - Else if signature processing continues and if the signatures 2276 verify, the GLO checks to make sure one of the names in the 2277 certificate used to sign the request matches the name in 2278 glMember.glMemberName. 2280 3.b.1 - If the names do not match, the GLO sends a 2281 SignedData.PKIResponse.controlSequence message back to the 2282 prospective member with cMCStatusInfoExt.cMCStatus.failed 2283 indicating why the prospective member was denied in 2284 cMCStausInfo.statusString. This stops people from adding 2285 people to GLs without their permission. Additionally, a 2286 signingTime attribute is included with the response. 2288 3.b.2 - Else if the names match, the GLO determines whether the 2289 prospective member is allowed to be added. The mechanism 2290 is beyond the scope of this document; however, the GLO 2291 should check to see that the glMember.glMemberName is not 2292 already on the GL. 2294 3.b.2.a - If the GLO determines the prospective member is not 2295 allowed to join the GL, the GLO can return a 2296 SignedData.PKIResponse.controlSequence message back to 2297 the prospective member with 2298 cMCStatusInfoExt.cMCtatus.failed indicating why the 2299 prospective member was denied in cMCStatus.statusString. 2300 Additionally, a signingTime attribute is included with 2301 the response. 2303 3.b.2.b - Else if GLO determines the prospective member is allowed 2304 to join the GL, the GLO verifies the member's encryption 2305 certificate. 2307 3.b.2.b.1 - If the member's certificate cannot be verified, the 2308 GLO returns a SignedData.PKIResponse.controlSequence 2309 back to the prospective member with 2310 cMCStatusInfoExt.cMCtatus.failed indicating that the 2311 member's encryption certificate did not verify in 2312 cMCStatus.statusString. Additionally, a signingTime 2313 attribute is included with the response. If the GLO 2314 does not return a cMCStatusInfoExt response, the GLO 2315 sends a 2316 SignedData.PKIData.controlSequence.glProvideCert 2318 Turner Expires July 2003 44 2319 And Distribution 2321 message to the prospective member requesting a new 2322 encryption certificate (see section 4.10). 2324 3.b.2.b.2 - Else if the member's certificate verifies, the GLO 2325 resubmits the glAddMember request (see section 3.2.5) 2326 to the GLA (1 in Figure 5). 2328 3.b.2.b.2.a - The GLO applies confidentiality to the new 2329 GLAddMember request by encapsulating the 2330 SignedData.PKIData in an EnvelopedData if the 2331 initial request was encapsulated in an EnvelopedData 2332 (see section 3.2.1.2). 2334 3.b.2.b.2.b - The GLO can also optionally apply another SignedData 2335 over the EnvelopedData (see section 3.2.1.2). 2337 4 - Processing continues as in 2 of section 4.3.1. 2339 4.4 Delete Members From GL 2341 To delete members from GLs, either the GLO or members to be removed 2342 use the glDeleteMember request. The GLA processes GLO and members 2343 requesting their own removal make requests differently. The GLO can 2344 submit the request at any time to delete members from the GL, and 2345 the GLA, once it has verified the request came from a registered 2346 GLO, should delete the member. If a member sends the request, the 2347 GLA needs to determine how the GL is administered. When the GLO 2348 initially configured the GL, they set the GL to be unmanaged, 2349 managed, or closed (see section 3.1.1). In the unmanaged case, the 2350 GLA merely processes the member's request. For the managed case, the 2351 GLA forwards the requests from the member to the GLO for review. 2352 Where there are multiple GLOs for a GL, which GLO the request is 2353 forwarded to is beyond the scope of this document. The GLO reviews 2354 the request and either rejects it or submits a reformed request to 2355 the GLA. In the closed case, the GLA will not accept requests from 2356 members. The following sections describe the processing for the 2357 GLO(s), GLA, and GL members depending on where the request 2358 originated, either from a GLO or from members wanting to be removed. 2359 Figure 6 depicts the protocol interactions for the three options. 2360 Note that the error messages are not depicted. Additionally, 2361 behavior for the optional transactionId, senderNonce, and 2362 recipientNonce CMC control attributes is not addressed in these 2363 procedures. 2365 Turner Expires July 2003 45 2366 And Distribution 2368 +-----+ 2,B{A} 3 +----------+ 2369 | GLO | <--------+ +-------> | Member 1 | 2370 +-----+ | | +----------+ 2371 1 | | 2372 +-----+ <--------+ | 3 +----------+ 2373 | GLA | A +-------> | ... | 2374 +-----+ <-------------+ +----------+ 2375 | 2376 | 3 +----------+ 2377 +-------> | Member n | 2378 +----------+ 2380 Figure 6 - Member Deletion 2382 If the member is not removed from the GL, they will continue to 2383 receive and be able to decrypt data protected with the shared KEK 2384 and will continue to receive rekeys. For unmanaged lists, there is 2385 no point to a group rekey because there is no guarantee that the 2386 member requesting to be removed has not already added themselves 2387 back on the GL under a different name. For managed and closed GLs, 2388 the GLO needs to take steps to ensure the member being deleted is 2389 not on the GL twice. After ensuring this, managed and closed GLs can 2390 be rekeyed to maintain the confidentiality of the traffic sent by 2391 group members. If the GLO is sure the member has been deleted the 2392 group rekey mechanism can be used to distribute the new key (see 2393 sections 4.5 and 5). 2395 4.4.1 GLO Initiated Deletions 2397 The process for GLO initiated glDeleteMember requests is as follows: 2399 1 - The GLO collects the pertinent information for the member(s) 2400 to be deleted (this can be done through an out of bands 2401 means). The GLO then sends a 2402 SignedData.PKIData.controlSequence with a separate 2403 glDeleteMember request for each member to the GLA (1 in Figure 2404 6). The GLO MUST include: the GL name in glName and the 2405 member's name in glMemberToDelete. If the GL from which the 2406 member is being deleted in a closed or managed GL, the GLO 2407 MUST also generate a glRekey request and include it with the 2408 glDeletemember request (see section 4.5). The GLO MUST also 2409 include the signingTime attribute with this request. 2411 1.a - The GLO can optionally apply confidentiality to the request 2412 by encapsulating the SignedData.PKIData in an EnvelopedData 2413 (see section 3.2.1.2). 2415 1.b - The GLO can also optionally apply another SignedData over 2416 the EnvelopedData (see section 3.2.1.2). 2418 Turner Expires July 2003 46 2419 And Distribution 2421 2 - Upon receipt of the request, the GLA checks the signingTime 2422 attribute and verifies the signature on the inner most 2423 SignedData.PKIData. If an additional SignedData and/or 2424 EnvelopedData encapsulates the request (see section 3.2.1.2 or 2425 3.2.2), the GLA verifies the outer signature and/or decrypt 2426 the outer layer prior to verifying the signature on the inner 2427 most SignedData. 2429 2.a - If the signingTime attribute value is not within the locally 2430 accepted time window, the GLA MAY return a response 2431 indicating cMCStatus.failed and otherInfo.failInfo.badTime 2432 and a signingTime attribute. 2434 2.b - Else if signature processing continues and if the signatures 2435 cannot be verified, the GLA returns a cMCStatusInfoExt 2436 response indicating cMCStatus.failed and 2437 otherInfo.failInfo.badMessageCheck. Additionally, a 2438 signingTime attribute is included with the response. 2440 2.c - Else if the signatures verify, the GLA makes sure the GL is 2441 supported by the GLA by checking that the glName matches a 2442 glName stored on the GLA. 2444 2.c.1 - If the glName is not supported by the GLA, the GLA returns 2445 a response indicating cMCStatusInfoExt with 2446 cMCStatus.failed and 2447 otherInfo.extendedFailInfo.SKDFailInfo value of 2448 invalidGLName. Additionally, a signingTime attribute is 2449 included with the response. 2451 2.c.2 - Else if the glName is supported by the GLA, the GLA checks 2452 to see if the glMemberName is present on the GL. 2454 2.c.2.a - If the glMemberName is not present on the GL, the GLA 2455 returns a response indicating cMCStatusInfoExt with 2456 cMCStatus.failed and 2457 otherInfo.extendedFailInfo.SKDFailInfo value of 2458 notAMember. Additionally, a signingTime attribute is 2459 included with the response. 2461 2.c.2.b - Else if the glMemberName is already on the GL, the GLA 2462 checks how the GL is administered. 2464 2.c.2.b.1 - If the GL is closed, the GLA checks that the 2465 registered GLO signed the request by checking that one 2466 of the names in the digital signature certificate used 2467 to sign the request matches the registered GLO. 2469 2.c.2.b.1.a - If the names do not match, the GLA returns a 2470 response indicating cMCStatusInfoExt with 2471 cMCStatus.failed and 2472 otherInfo.extendedFailInfo.SKDFailInfo value of 2474 Turner Expires July 2003 47 2475 And Distribution 2477 closedGL. Additionally, a signingTime attribute is 2478 included with the response. 2480 2.c.2.b.1.b - Else if the names do match, the GLA returns a 2481 cMCStatusInfoExt.cMCStatus.success and a signingTime 2482 attribute (2 in Figure 5). The GLA also takes 2483 administrative actions, which are beyond the scope 2484 of this document, to delete the member with the GL 2485 stored on the GLA. Note that he GL also needs to be 2486 rekeyed as described in section 5. 2488 2.c.2.b.1.b.1 - The GLA applies confidentiality to the response by 2489 encapsulating the SignedData.PKIData in an 2490 EnvelopedData if the request was encapsulated in 2491 an EnvelopedData (see section 3.2.1.2). 2493 2.c.2.b.1.b.2 - The GLA can also optionally apply another 2494 SignedData over the EnvelopedData (see section 2495 3.2.1.2). 2497 2.c.2.b.2 - Else if the GL is managed, the GLA checks that either 2498 a registered GLO or the prospective member signed the 2499 request. For GLOs, one of the names in the certificate 2500 used to sign the request needs to match a registered 2501 GLO. For the prospective member, the name in 2502 glMember.glMemberName needs to match one of the names 2503 in the certificate used to sign the request. 2505 2.c.2.b.2.a - If the signer is neither a registered GLO nor the 2506 prospective GL member, the GLA returns a response 2507 indicating cMCStatusInfoExt with cMCStatus.failed 2508 and otherInfo.extendedFailInfo.SKDFailInfo value of 2509 noSpam. Additionally, a signingTime attribute is 2510 included with the response. 2512 2.c.2.b.2.b - Else if the signer is a registered GLO, the GLA 2513 returns a cMCStatusInfoExt.cMCStatus.success and a 2514 signingTime attribute(2 in Figure 6). The GLA also 2515 takes administrative actions, which are beyond the 2516 scope of this document, to delete the member with 2517 the GL stored on the GLA. Note that the GL will also 2518 be rekeyed as described in section 5. 2520 2.c.2.b.2.b.1 - The GLA applies confidentiality to the response by 2521 encapsulating the SignedData.PKIData in an 2522 EnvelopedData if the request was encapsulated in 2523 an EnvelopedData (see section 3.2.1.2). 2525 2.c.2.b.2.b.2 - The GLA can also optionally apply another 2526 SignedData over the EnvelopedData (see section 2527 3.2.1.2). 2529 Turner Expires July 2003 48 2530 And Distribution 2532 2.c.2.b.2.c - Else if the signer is the prospective member, the 2533 GLA forwards the glDeleteMember request (see section 2534 3.2.3) to the GLO (B{A} in Figure 6). If there is 2535 more than one registered GLO, the GLO to which the 2536 request is forwarded to is beyond the scope of this 2537 document. Further processing of the forwarded 2538 request by GLOs is addressed in 3 of section 4.4.2. 2540 2.c.2.b.2.c.1 - The GLA applies confidentiality to the forwarded 2541 request by encapsulating the SignedData.PKIData in 2542 an EnvelopedData if the request was encapsulated 2543 in an EnvelopedData (see section 3.2.1.2). 2545 2.c.2.b.2.c.2 - The GLA can also optionally apply another 2546 SignedData over the EnvelopedData (see section 2547 3.2.1.2). 2549 2.c.2.b.3 - Else if the GL is unmanaged, the GLA checks that 2550 either a registered GLO or the prospective member 2551 signed the request. For GLOs, one of the names in the 2552 certificate used to sign the request needs to match 2553 the name of a registered GLO. For the prospective 2554 member, the name in glMember.glMemberName needs to 2555 match one of the names in the certificate used to sign 2556 the request. 2558 2.c.2.b.3.a - If the signer is neither the GLO nor the prospective 2559 member, the GLA returns a response indicating 2560 cMCStatusInfoExt with cMCStatus.failed and 2561 otherInfo.extendedFailInfo.SKDFailInfo value of 2562 noSpam. Additionally, a signingTime attribute is 2563 included with the response. 2565 2.c.2.b.3.b - Else if the signer is either a registered GLO or the 2566 member, the GLA returns a 2567 cMCStatusInfoExt.cMCStatus.success and a signingTime 2568 attribute to the GLO (2 in Figure 6) if the GLO 2569 signed the request and to the GL member (3 in Figure 2570 6) if the GL member signed the request. The GLA also 2571 takes administrative actions, which are beyond the 2572 scope of this document, to delete the member with 2573 the GL stored on the GLA. 2575 2.c.2.b.3.b.1 - The GLA applies confidentiality to the response by 2576 encapsulating the SignedData.PKIData in an 2577 EnvelopedData if the request was encapsulated in 2578 an EnvelopedData (see section 3.2.1.2). 2580 2.c.2.b.3.b.2 - The GLA can also optionally apply another 2581 SignedData over the EnvelopedData (see section 2582 3.2.1.2). 2584 Turner Expires July 2003 49 2585 And Distribution 2587 3 - Upon receipt of the cMCStatusInfoExt response, the GLO checks 2588 the signingTime and verifies the GLA signatures. If an 2589 additional SignedData and/or EnvelopedData encapsulates the 2590 response (see section 3.2.1.2 or 3.2.2), the GLO verifies the 2591 outer signature and/or decrypt the outer layer prior to 2592 verifying the signature on the inner most SignedData. 2594 3.a - If the signingTime attribute value is not within the locally 2595 accepted time window, the GLO MAY return a response 2596 indicating cMCStatus.failed and otherInfo.failInfo.badTime 2597 and a signingTime attribute. 2599 3.b - Else if signature processing continues and if the signatures 2600 do verify, the GLO checks that one of the names in the 2601 certificate used to sign the response matches the name of 2602 the GL. 2604 3.b.1 � If the name of the GL does not match the name present in 2605 the certificate used to sign the message, the GLO should 2606 not believe the response. 2608 3.b.2 � Else if the name of the GL matches the name present in the 2609 certificate and: 2611 3.b.2.a - If the signatures verify and the response is 2612 cMCStatusInfoExt.cMCStatus.success, the GLO has deleted 2613 the member from the GL. If member was deleted from a 2614 managed list and the original request was signed by the 2615 member, the GLO sends a 2616 cMCStatusInfoExt.cMCStatus.success and a signingTime 2617 attribute to the GL member. 2619 3.b.2.b - Else if the GLO received a 2620 cMCStatusInfoExt.cMCStatus.failed with any reason, the 2621 GLO may reattempt to delete the member from the GL using 2622 the information provided in the response. 2624 4 - Upon receipt of the cMCStatusInfoExt response, the member 2625 checks the signingTime and verifies the GLA signature(s) or 2626 GLO signature(s). If an additional SignedData and/or 2627 EnvelopedData encapsulates the response (see section 3.2.1.2 2628 or 3.2.2), the GLO verifies the outer signature and/or decrypt 2629 the outer layer prior to verifying the signature on the inner 2630 most SignedData. 2632 4.b - If the signingTime attribute value is not within the locally 2633 accepted time window, the prospective member MAY return a 2634 response indicating cMCStatus.failed and 2635 otherInfo.failInfo.badTime and a signingTime attribute. 2637 4.b - Else if signature processing continues and if the signatures 2638 verify, the GL member checks that one of the names in the 2640 Turner Expires July 2003 50 2641 And Distribution 2643 certificate used to sign the response matches the name of 2644 the GL. 2646 4.b.1 � If the name of the GL does not match the name present in 2647 the certificate used to sign the message, the GL member 2648 should not believe the response. 2650 4.b.2 � Else if the name of the GL matches the name present in the 2651 certificate and: 2653 4.b.2.a - If the signature(s) verify, the member has been deleted 2654 from the GL. 2656 4.b.2.b - Else if the member received a 2657 cMCStatusInfoExt.cMCStatus.failed with any reason, the 2658 member can reattempt to delete themselves from the GL 2659 using the information provided in the response. 2661 4.4.2 Member Initiated Deletions 2663 The process for member initiated deletion of their own membership 2664 using the glDeleteMember requests is as follows: 2666 1 - The member sends a 2667 SignedData.PKIData.controlSequence.glDeleteMember request to 2668 the GLA (A in Figure 6). The member includes: the name of the 2669 GL in glName and their own name in glMemberToDelete. The GL 2670 member MUST also include the signingTime attribute with this 2671 request. 2673 1.a - The member can optionally apply confidentiality to the 2674 request by encapsulating the SignedData.PKIData in an 2675 EnvelopedData (see section 3.2.1.2). 2677 1.b - The member can also optionally apply another SignedData over 2678 the EnvelopedData (see section 3.2.1.2). 2680 2 - Upon receipt of the request, the GLA verifies the request as 2681 per 2 in section 4.4.1. 2683 3 - Upon receipt of the forwarded request, the GLO checks the 2684 signingTime and verifies the member signature on the inner 2685 most SignedData.PKIData and the GLA signature on the outer 2686 layer. If an EnvelopedData encapsulates the inner most layer 2687 (see section 3.2.1.2 or 3.2.2), the GLO decrypts the outer 2688 layer prior to verifying the signature on the inner most 2689 SignedData. 2691 Note: For cases where the GL is closed and either (a) a 2692 prospective member sends directly to the GLO or (b) the GLA 2694 Turner Expires July 2003 51 2695 And Distribution 2697 has mistakenly forwarded the request to the GLO, the GLO 2698 should first determine whether to honor the request. 2700 3.a - If the signingTime attribute value is not within the locally 2701 accepted time window, the GLO MAY return a response 2702 indicating cMCStatus.failed and otherInfo.failInfo.badTime 2703 and a signingTime attribute. 2705 3.b - Else if signature processing continues if the signatures 2706 cannot be verified, the GLO returns a cMCStatusInfoExt 2707 response indicating cMCStatus.failed and 2708 otherInfo.failInfo.badMessageCheck and a signingTime 2709 attribute. 2711 3.c - Else if the signatures verify, the GLO checks to make sure 2712 one of the names in the certificates used to sign the 2713 request matches the name in glMemberToDelete. 2715 3.c.1 - If the names match, the GLO sends a 2716 SignedData.PKIResponse.controlSequence message back to the 2717 prospective member with cMCStatusInfoExt.cMCtatus.failed 2718 indicating why the prospective member was denied in 2719 cMCStatusInfoExt.statusString. This stops people from 2720 adding people to GLs without their permission. 2721 Additionally, a signingTime attribute is included with the 2722 response. 2724 3.c.2 - Else if the names match, the GLO resubmits the 2725 glDeleteMember request (see section 3.2.5) to the GLA (1 2726 in Figure 6). The GLO makes sure the glMemberName is 2727 already on the GL. The GLO also generates a glRekey 2728 request and include it with the GLDeleteMember request 2729 (see section 4.5). 2731 3.c.2.a - The GLO applies confidentiality to the new 2732 GLDeleteMember request by encapsulating the 2733 SignedData.PKIData in an EnvelopedData if the initial 2734 request was encapsulated in an EnvelopedData (see 2735 section 3.2.1.2). 2737 3.c.2.b - The GLO can also optionally apply another SignedData 2738 over the EnvelopedData (see section 3.2.1.2). 2740 4 - Further processing is as in 2 of section 4.4.1. 2742 Turner Expires July 2003 52 2743 And Distribution 2745 4.5 Request Rekey Of GL 2747 From time to time, the GL will need to be rekeyed. Some situations 2748 follow: 2750 - When a member is removed from a closed or managed GL. In this 2751 case, the PKIData.controlSequence containing the glDeleteMember 2752 ought to contain a glRekey request. 2754 - Depending on policy, when a member is removed from an unmanaged 2755 GL. If the policy is to rekey the GL, the 2756 PKIData.controlSequence containing the glDeleteMember could also 2757 contain a glRekey request or an out of bands means could be used 2758 to tell the GLA to rekey the GL. Rekeying of unmanaged GLs when 2759 members are deleted is not advised. 2761 - When the current shared KEK has been compromised. 2763 - When the current shared KEK is about to expire. Consider two 2764 cases: 2766 - If the GLO controls the GL rekey, the GLA should not assume 2767 that a new shared KEK should be distributed, but instead wait 2768 for the glRekey message. 2770 - If the GLA controls the GL rekey, the GLA should initiate a 2771 glKey message as specified in section 5. 2773 If the generationCounter (see section 3.1.1) is set to a value 2774 greater than one (1) and the GLO controls the GL rekey, the GLO may 2775 generate a glRekey any time before the last shared KEK has expired. 2776 To be on the safe side, the GLO ought to request a rekey one (1) 2777 duration before the last shared KEK expires. 2779 The GLA and GLO are the only entities allowed to initiate a GL 2780 rekey. The GLO indicated whether they are going to control rekeys or 2781 whether the GLA is going to control rekeys when they assigned the 2782 shared KEK to GL (see section 3.1.1). The GLO initiates a GL rekey 2783 at any time. The GLA can be configured to automatically rekey the GL 2784 prior to the expiration of the shared KEK (the length of time before 2785 the expiration is an implementation decision). The GLA can also 2786 automatically rekey GLs that have been compromised, but this is 2787 covered in section 5. Figure 7 depicts the protocol interactions to 2788 request a GL rekey. Note that error messages are not depicted. 2789 Additionally, behavior for the optional transactionId, senderNonce, 2790 and recipientNonce CMC control attributes is not addressed in these 2791 procedures. 2793 +-----+ 1 2,A +-----+ 2794 | GLA | <-------> | GLO | 2795 +-----+ +-----+ 2797 Turner Expires July 2003 53 2798 And Distribution 2800 Figure 7 - GL Rekey Request 2802 4.5.1 GLO Initiated Rekey Requests 2804 The process for GLO initiated glRekey requests is as follows: 2806 1 - The GLO sends a SignedData.PKIData.controlSequence.glRekey 2807 request to the GLA (1 in Figure 7). The GLO includes the 2808 glName. If glAdministration and glKeyNewAttributes are omitted 2809 then there is no change from the previously registered GL 2810 values for these fields. If the GLO wants to force a rekey for 2811 all outstanding shared KEKs it includes the glRekeyAllGLKeys 2812 set to TRUE. The GLO MUST also include a signingTime attribute 2813 is included with this request. 2815 1.a - The GLO can optionally apply confidentiality to the request 2816 by encapsulating the SignedData.PKIData in an EnvelopedData 2817 (see section 3.2.1.2). 2819 1.b - The GLO can also optionally apply another SignedData over 2820 the EnvelopedData (see section 3.2.1.2). 2822 2 - Upon receipt of the request, the GLA checks the signingTime 2823 and verifies the signature on the inner most 2824 SignedData.PKIData. If an additional SignedData and/or 2825 EnvelopedData encapsulates the request (see section 3.2.1.2 or 2826 3.2.2), the GLA verifies the outer signature and/or decrypt 2827 the outer layer prior to verifying the signature on the inner 2828 most SignedData. 2830 2.a - If the signingTime attribute value is not within the locally 2831 accepted time window, the GLA MAY return a response 2832 indicating cMCStatus.failed and otherInfo.failInfo.badTime 2833 and a signingTime attribute. 2835 2.c - Else if signature processing continues and if the signatures 2836 do not verify, the GLA returns a cMCStatusInfoExt response 2837 indicating cMCStatus.failed and 2838 otherInfo.failInfo.badMessageCheck. Additionally, a 2839 signingTime attribute is included with the response. 2841 2.c - Else if the signatures do verify, the GLA makes sure the GL 2842 is supported by the GLA by checking that the glName matches 2843 a glName stored on the GLA. 2845 2.c.1 - If the glName present does not match a GL stored on the 2846 GLA, the GLA returns a response indicating 2847 cMCStatusInfoExt with cMCStatus.failed and 2848 otherInfo.extendedFailInfo.SKDFailInfo value of 2849 invalidGLName. Additionally, a signingTime attribute is 2850 included with the response. 2852 Turner Expires July 2003 54 2853 And Distribution 2855 2.c.2 - Else if the glName present matches a GL stored on the GLA, 2856 the GLA checks that a registered GLO signed the request by 2857 checking that one of the names in the certificate used to 2858 sign the request is a registered GLO. 2860 2.c.2.a - If the names do not match, the GLA returns a response 2861 indicating cMCStatusInfoExt with cMCStatus.failed and 2862 otherInfo.extendedFailInfo.SKDFailInfo value of 2863 noGLONameMatch. Additionally, a signingTime attribute is 2864 included with the response. 2866 2.c.2.b - Else if the names match, the GLA checks the 2867 glNewKeyAttribute values. 2869 2.c.2.b.1 - If the new value for requestedAlgorithm is not 2870 supported, the GLA returns a response indicating 2871 cMCStatusInfoExt with cMCStatus.failed and 2872 otherInfo.extendedFailInfo.SKDFailInfo value of 2873 unsupportedAlgorithm. Additionally, a signingTime 2874 attribute is included with the response. 2876 2.c.2.b.2 - Else if the new value duration is not supportable, 2877 determining this is beyond the scope this document, 2878 the GLA returns a response indicating cMCStatusInfoExt 2879 with cMCStatus.failed and 2880 otherInfo.extendedFailInfo.SKDFailInfo value of 2881 unsupportedDuration. Additionally, a signingTime 2882 attribute is included with the response. 2884 2.c.2.b.3 - Else if the GL is not supportable for other reasons, 2885 which the GLA does not wish to disclose, the GLA 2886 returns a response indicating cMCStatusInfoExt with 2887 cMCStatus.failed and 2888 otherInfo.extendedFailInfo.SKDFailInfo value of 2889 unspecified. Additionally, a signingTime attribute is 2890 included with the response. 2892 2.c.2.b.4 - Else if the new requestedAlgorithm and duration are 2893 supportable or the glNewKeyAttributes was omitted, the 2894 GLA returns a cMCStatusInfoExt.cMCStatus.success and a 2895 sigingTime attribute (2 in Figure 7). The GLA also 2896 uses the glKey message to distribute the rekey shared 2897 KEK (see section 5). 2899 2.c.2.b.4.a - The GLA applies confidentiality to response by 2900 encapsulating the SignedData.PKIData in an 2901 EnvelopedData if the request was encapsulated in an 2902 EnvelopedData (see section 3.2.1.2). 2904 2.c.2.b.4.b - The GLA can also optionally apply another SignedData 2905 over the EnvelopedData (see section 3.2.1.2). 2907 Turner Expires July 2003 55 2908 And Distribution 2910 3 - Upon receipt of the cMCStatusInfoExt response, the GLO checks 2911 the signingTime and verifies the GLA signature(s). If an 2912 additional SignedData and/or EnvelopedData encapsulates the 2913 forwarded response (see section 3.2.1.2 or 3.2.2), the GLO 2914 verifies the outer signature and/or decrypt the forwarded 2915 response prior to verifying the signature on the inner most 2916 SignedData. 2918 3.a - If the signingTime attribute value is not within the locally 2919 accepted time window, the GLA MAY return a response 2920 indicating cMCStatus.failed and otherInfo.failInfo.badTime 2921 and a signingTime attribute. 2923 3.b - Else if signature processing continues and if the signatures 2924 verify, the GLO checks that one of the names in the 2925 certificate used to sign the response matches the name of 2926 the GL. 2928 3.b.1 - If the name of the GL does not match the name present in 2929 the certificate used to sign the message, the GLO should 2930 not believe the response. 2932 3.b.2 - Else if the name of the GL matches the name present in the 2933 certificate and: 2935 3.b.2.a - If the signatures verify and the response is 2936 cMCStatusInfoExt.cMCStatus.success, the GLO has 2937 successfully rekeyed the GL. 2939 3.b.2.b - Else if the GLO received a 2940 cMCStatusInfoExt.cMCStatus.failed with any reason, the 2941 GLO can reattempt to rekey the GL using the information 2942 provided in the response. 2944 4.5.2 GLA Initiated Rekey Requests 2946 If the GLA is in charge of rekeying the GL the GLA will 2947 automatically issue a glKey message (see section 5). In addition the 2948 GLA will generate a cMCStatusInfoExt to indicate to the GL that a 2949 successful rekey has occurred. The process for GLA initiated rekey 2950 is as follows: 2952 1 - The GLA generates for all GLOs a 2953 SignedData.PKIData.controlSequence.cMCStatusInfoExt.cMCStatus. 2954 success and includes a signingTime attribute (A in Figure 7). 2956 1.a - The GLA can optionally apply confidentiality to the request 2957 by encapsulating the SignedData.PKIData in an EnvelopedData 2958 (see section 3.2.1.2). 2960 Turner Expires July 2003 56 2961 And Distribution 2963 1.b - The GLA can also optionally apply another SignedData over 2964 the EnvelopedData (see section 3.2.1.2). 2966 2 - Upon receipt of the cMCStatusInfoExt.cMCStatus.success 2967 response, the GLO checks the signingTime and verifies the GLA 2968 signature(s). If an additional SignedData and/or EnvelopedData 2969 encapsulates the forwarded response (see section 3.2.1.2 or 2970 3.2.2), the GLO MUST verify the outer signature and/or decrypt 2971 the outer layer prior to verifying the signature on the inner 2972 most SignedData. 2974 2.a - If the signingTime attribute value is not within the locally 2975 accepted time window, the GLO MAY return a response 2976 indicating cMCStatus.failed and otherInfo.failInfo.badTime 2977 and a signingTime attribute. 2979 2.b - Else if signature processing continues and if the signatures 2980 verify, the GLO checks that one of the names in the 2981 certificate used to sign the response matches the name of 2982 the GL. 2984 2.b.1 - If the name of the GL does not match the name present in 2985 the certificate used to sign the message, the GLO ought 2986 not believe the response. 2988 2.b.2 - Else if the name of the GL does match the name present in 2989 the certificate and and the response is 2990 cMCStatusInfoExt.cMCStatus.success, the GLO knows the GLA 2991 has successfully rekeyed the GL. 2993 4.6 Change GLO 2995 Management of managed and closed GLs can become difficult for one 2996 GLO if the GL membership grows large. To support distributing the 2997 workload, GLAs support having GLs be managed by multiple GLOs. The 2998 glAddOwner and glRemoveOwner messages are designed to support adding 2999 and removing registered GLOs. Figure 8 depicts the protocol 3000 interactions to send glAddOwner and glRemoveOwner messages and the 3001 resulting response messages. Note that error messages are not shown. 3002 Additionally, behavior for the optional transactionId, senderNonce, 3003 and recipientNonce CMC control attributes is not addressed in these 3004 procedures. 3006 +-----+ 1 2 +-----+ 3007 | GLA | <-------> | GLO | 3008 +-----+ +-----+ 3010 Figure 8 - GLO Add & Delete Owners 3012 Turner Expires July 2003 57 3013 And Distribution 3015 The process for glAddOwner and glDeleteOwner is as follows: 3017 1 - The GLO sends a SignedData.PKIData.controlSequence.glAddOwner 3018 or glRemoveOwner request to the GLA (1 in Figure 8). The GLO 3019 includes: the GL name in glName, the name and address of the 3020 GLO in glOwnerName and glOwnerAddress, respectively. The GLO 3021 MUST also include the signingTime attribute with this request. 3023 1.a - The GLO can optionally apply confidentiality to the request 3024 by encapsulating the SignedData.PKIData in an EnvelopedData 3025 (see section 3.2.1.2). 3027 1.b - The GLO can also optionally apply another SignedData over 3028 the EnvelopedData (see section 3.2.1.2). 3030 2 - Upon receipt of the glAddOwner or glRemoveOwner request, the 3031 GLA checks the signingTime and verifies the GLO signature(s). 3032 If an additional SignedData and/or EnvelopedData encapsulates 3033 the request (see section 3.2.1.2 or 3.2.2), the GLA verifies 3034 the outer signature and/or decrypt the outer layer prior to 3035 verifying the signature on the inner most SignedData. 3037 2.a - If the signingTime attribute value is not within the locally 3038 accepted time window, the GLA MAY return a response 3039 indicating cMCStatus.failed and otherInfo.failInfo.badTime 3040 and a signingTime attribute. 3042 2.b - Else if signature processing continues and if the signatures 3043 cannot verified, the GLA returns a cMCStatusInfoExt response 3044 indicating cMCStatus.failed and 3045 otherInfo.failInfo.badMessageCheck. Additionally, a 3046 signingTime attribute is included with the response. 3048 2.c - Else if the signatures verify, the GLA makes sure the GL is 3049 supported by checking that the glName matches a glName 3050 stored on the GLA. 3052 2.c.1 - If the glName is not supported by the GLA, the GLA returns 3053 a response indicating cMCStatusInfoExt with 3054 cMCStatus.failed and 3055 otherInfo.extendedFailInfo.SKDFailInfo value of 3056 invalidGLName. Additionally, a signingTime attribute is 3057 included with the response. 3059 2.c.2 - Else if the glName is supported by the GLA, the GLA 3060 ensures a registered GLO signed the glAddOwner or 3061 glRemoveOwner request by checking that one of the names 3062 present in the digital signature certificate used to sign 3063 the glAddOwner or glDeleteOwner request matches the name 3064 of a registered GLO. 3066 Turner Expires July 2003 58 3067 And Distribution 3069 2.c.2.a - If the names do not match, the GLA returns a response 3070 indicating cMCStatusInfoExt with cMCStatus.failed and 3071 otherInfo.extendedFailInfo.SKDFailInfo value of 3072 noGLONameMatch. Additionally, a signingTime attribute is 3073 included with the response. 3075 2.c.2.b - Else if the names match, the GLA returns a 3076 cMCStatusInfoExt.cMCStatus.success and a signingTime 3077 attribute (2 in Figure 4). The GLA also takes 3078 administrative actions to associate the new glOwnerName 3079 with the GL in the case of glAddOwner or to disassociate 3080 the old glOwnerName with the GL in the cased of 3081 glRemoveOwner. 3083 2.c.2.b.1 - The GLA applies confidentiality to the response by 3084 encapsulating the SignedData.PKIResponse in an 3085 EnvelopedData if the request was encapsulated in an 3086 EnvelopedData (see section 3.2.1.2). 3088 2.c.2.b.2 - The GLA can also optionally apply another SignedData 3089 over the EnvelopedData (see section 3.2.1.2). 3091 3 - Upon receipt of the cMCStatusInfoExt response, the GLO checks 3092 the signingTime and verifies the GLA's signature(s). If an 3093 additional SignedData and/or EnvelopedData encapsulates the 3094 response (see section 3.2.1.2 or 3.2.2), the GLO verifies the 3095 outer signature and/or decrypt the outer layer prior to 3096 verifying the signature on the inner most SignedData. 3098 3.a - If the signingTime attribute value is not within the locally 3099 accepted time window, the GLO MAY return a response 3100 indicating cMCStatus.failed and otherInfo.failInfo.badTime 3101 and a signingTime attribute. 3103 3.b - Else if signature processing continues and if the signatures 3104 verify, the GLO checks that one of the names in the 3105 certificate used to sign the response matches the name of 3106 the GL. 3108 3.b.1 � If the name of GL does not match the name present in the 3109 certificate used to sign the message, the GLO should not 3110 believe the response. 3112 3.b.2 � Else if the name of the GL does match the name present in 3113 the certificate and: 3115 3.b.2.a - If the signatures verify and the response was 3116 cMCStatusInfoExt.cMCStatus.success, the GLO has 3117 successfully added or removed the GLO. 3119 3.b.2.b - Else if the signatures verify and the response was 3120 cMCStatusInfoExt.cMCStatus.failed with any reason, the 3122 Turner Expires July 2003 59 3123 And Distribution 3125 GLO can reattempt to add or delete the GLO using the 3126 information provided in the response. 3128 4.7 Indicate KEK Compromise 3130 There will be times when the shared KEK is compromised. GL members 3131 and GLOs use glkCompromise to tell the GLA that the shared KEK has 3132 been compromised. Figure 9 depicts the protocol interactions for GL 3133 Key Compromise. Note that error messages are not shown. 3134 Additionally, behavior for the optional transactionId, senderNonce, 3135 and recipientNonce CMC control attributes is not addressed in these 3136 procedures. 3138 +-----+ 2{1} 4 +----------+ 3139 | GLO | <----------+ +-------> | Member 1 | 3140 +-----+ 5,3{1} | | +----------+ 3141 +-----+ <----------+ | 4 +----------+ 3142 | GLA | 1 +-------> | ... | 3143 +-----+ <---------------+ +----------+ 3144 | 4 +----------+ 3145 +-------> | Member n | 3146 +----------+ 3148 Figure 9 - GL Key Compromise 3150 4.7.1 GL Member Initiated KEK Compromise Message 3152 The process for GL member initiated glkCompromise messages is as 3153 follows: 3155 1 - The GL member sends a 3156 SignedData.PKIData.controlSequence.glkCompromise request to 3157 the GLA (1 in Figure 9). The GL member includes the name of 3158 the GL in GeneralName. The GL member MUST also include the 3159 signingTime attribute with this request. 3161 1.a - The GL member can optionally apply confidentiality to the 3162 request by encapsulating the SignedData.PKIData in an 3163 EnvelopedData (see section 3.2.1.2). The glkCompromise can 3164 be included in an EnvelopedData generated with the 3165 compromised shared KEK. 3167 1.b - The GL member can also optionally apply another SignedData 3168 over the EnvelopedData (see section 3.2.1.2). 3170 2 - Upon receipt of the glkCompromise request, the GLA checks the 3171 signingTime and verifies the GL member signature(s). If an 3172 additional SignedData and/or EnvelopedData encapsulates the 3173 request (see section 3.2.1.2 or 3.2.2), the GLA verifies the 3174 outer signature and/or decrypt the outer layer prior to 3175 verifying the signature on the inner most SignedData. 3177 Turner Expires July 2003 60 3178 And Distribution 3180 2.a - If the signingTime attribute value is not within the locally 3181 accepted time window, the GLA MAY return a response 3182 indicating cMCStatus.failed and otherInfo.failInfo.badTime 3183 and a signingTime attribute. 3185 2.b - Else if signature processing continues and if the signatures 3186 cannotbe verified, the GLA returns a cMCStatusInfoExt 3187 response indicating cMCStatus.failed and 3188 otherInfo.failInfo.badMessageCheck. Additionally, a 3189 signingTime attribute is included with the response. 3191 2.c - Else if the signatures verify, the GLA makes sure the GL is 3192 supported by checking that the indicated GL name matches a 3193 glName stored on the GLA. 3195 2.c.1 - If the glName is not supported by the GLA, the GLA returns 3196 a response indicating cMCStatusInfoExt with 3197 cMCStatus.failed and 3198 otherInfo.extendedFailInfo.SKDFailInfo value of 3199 invalidGLName. Additionally, a signingTime attribute is 3200 included with the response. 3202 2.c.2 - Else if the glName is supported by the GLA, the GLA checks 3203 who signed the request. For GLOs, one of the names in the 3204 certificate used to sign the request needs to match a 3205 registered GLO. For the member, the name in 3206 glMember.glMemberName needs to match one of the names in 3207 the certificate used to sign the request. 3209 2.c.2.a - If the GLO signed the request, the GLA generates a glKey 3210 message as described in section 5 to rekey the GL (4 in 3211 Figure 9). 3213 2.c.2.b - Else if someone other than the GLO signed the request, 3214 the GLA forwards the glkCompromise message (see section 3215 3.2.3) to the GLO (2{1} in Figure 9). If there is more 3216 than one GLO, to which GLO the request is forwarded is 3217 beyond the scope of this document. Further processing by 3218 the GLO is discussed in section 4.7.2. 3220 4.7.2 GLO Initiated KEK Compromise Message 3222 The process for GLO initiated glkCompromise messages is as follows: 3224 1 - The GLO either: 3226 1.a - Generates the glkCompromise message itself by sending a 3227 SignedData.PKIData.controlSequence.glkCompromise request to 3228 the GLA (5 in Figure 9). The GLO includes the name of the GL 3230 Turner Expires July 2003 61 3231 And Distribution 3233 in GeneralName. The GLO MUST also include a signingTime 3234 attribute with this request. 3236 1.a.1 - The GLO can optionally apply confidentiality to the 3237 request by encapsulating the SignedData.PKIData in an 3238 EnvelopedData (see section 3.2.1.2). The glkCompromise can 3239 be included in an EnvelopedData generated with the 3240 compromised shared KEK. 3242 1.a.2 - The GLO can also optionally apply another SignedData over 3243 the EnvelopedData (see section 3.2.1.2). 3245 1.b � Otherwise, checks the signingTime and verifies the GLA and 3246 GL member signatures on the forwarded glkCompromise message. 3247 If an additional SignedData and/or EnvelopedData 3248 encapsulates the request (see section 3.2.1.2 or 3.2.2), the 3249 GLO verifies the outer signature and/or decrypt the outer 3250 layer prior to verifying the signature on the inner most 3251 SignedData. 3253 1.b.1 - If the signingTime attribute value is not within the 3254 locally accepted time window, the GLO MAY return a 3255 response indicating cMCStatus.failed and 3256 otherInfo.failInfo.badTime and a signingTime attribute. 3258 1.b.2 - Else if signature processing continues and if the 3259 signatures cannot be verified, the GLO returns a 3260 cMCStatusInfoExt response indicating cMCStatus.failed and 3261 otherInfo.failInfo.badMessageCheck. Additionally, a 3262 signingTime attribute is included with the response. 3264 1.b.2.a - If the signatures verify, the GLO checks the names in 3265 the certificate match the name of the signer (i.e., the 3266 name in the certificate used to sign the GL member's 3267 request is the GL member). 3269 1.b.2.a.1 � If either name does not match, the GLO ought not trust 3270 the signer and it ought not forward the message to the 3271 GLA. 3273 1.b.2.a.2 � Else if the names match and the signatures verify, the 3274 GLO determines whether to forward the glkCompromise 3275 message back to the GLA (3{1} in Figure 9). Further 3276 processing by the GLA is in 2 of section 4.7.1. The 3277 GLO can also return a response to the prospective 3278 member with cMCStatusInfoExt.cMCtatus.success 3279 indicating that the glkCompromise message was 3280 successfully received. 3282 Turner Expires July 2003 62 3283 And Distribution 3285 4.8 Request KEK Refresh 3287 There will be times when GL members have unrecoverably lost their 3288 shared KEK. The shared KEK is not compromised and a rekey of the 3289 entire GL is not necessary. GL members use the glkRefresh message to 3290 request that the shared KEK(s) be redistributed to them. Figure 10 3291 depicts the protocol interactions for GL Key Refresh. Note that 3292 error messages are not shown. Additionally, behavior for the 3293 optional transactionId, senderNonce, and recipientNonce CMC control 3294 attributes is not addressed in these procedures. 3296 +-----+ 1 2 +----------+ 3297 | GLA | <-----------> | Member | 3298 +-----+ +----------+ 3300 Figure 10 - GL KEK Refresh 3302 The process for glkRefresh is as follows: 3304 1 - The GL member sends a 3305 SignedData.PKIData.controlSequence.glkRefresh request to the 3306 GLA (1 in Figure 10). The GL member includes name of the GL in 3307 GeneralName. The GL member MUST also include a signingTime 3308 attribute with this request. 3310 1.a - The GL member can optionally apply confidentiality to the 3311 request by encapsulating the SignedData.PKIData in an 3312 EnvelopedData (see section 3.2.1.2). 3314 1.b - The GL member can also optionally apply another SignedData 3315 over the EnvelopedData (see section 3.2.1.2). 3317 2 - Upon receipt of the glkRefresh request, the GLA checks the 3318 signingTime and verifies the GL member signature(s). If an 3319 additional SignedData and/or EnvelopedData encapsulates the 3320 request (see section 3.2.1.2 or 3.2.2), the GLA verifies the 3321 outer signature and/or decrypt the outer layer prior to 3322 verifying the signature on the inner most SignedData. 3324 2.a - If the signingTime attribute value is not within the locally 3325 accepted time window, the GLA MAY return a response 3326 indicating cMCStatus.failed and otherInfo.failInfo.badTime 3327 and a signingTime attribute. 3329 2.b - Else if signature processing continues and if the signatures 3330 cannot be verified, the GLA returns a cMCStatusInfoExt 3331 response indicating cMCStatus.failed and 3332 otherInfo.failInfo.badMessageCheck. Additionally, a 3333 signingTime attribute is included with the response. 3335 Turner Expires July 2003 63 3336 And Distribution 3338 2.c - Else if the signatures verify, the GLA makes sure the GL is 3339 supported by checking that the GLGeneralName matches a 3340 glName stored on the GLA. 3342 2.c.1 - If the name of the GL is not supported by the GLA, the GLA 3343 returns a response indicating cMCStatusInfoExt with 3344 cMCStatus.failed and 3345 otherInfo.extendedFailInfo.SKDFailInfo value of 3346 invalidGLName. Additionally, a signingTime attribute is 3347 included with the response. 3349 2.c.2 - Else if the glName is supported by the GLA, the GLA 3350 ensures the GL member is on the GL. 3352 2.c.2.a - If the glMemberName is not present on the GL, the GLA 3353 returns a response indicating cMCStatusInfoExt with 3354 cMCStatus.failed and 3355 otherInfo.extendedFailInfo.SKDFailInfo value of noSpam. 3356 Additionally, a signingTime attribute is included with 3357 the response. 3359 2.c.2.b - Else if the glMemberName is present on the GL, the GLA 3360 returns a cMCStatusInfoExt.cMCStatus.success, a 3361 signingTime attribute, and a glKey message (2 in Figure 3362 10) as described in section 5. 3364 4.9 GLA Query Request and Response 3366 There will be certain times when a GLO is having trouble setting up 3367 a GL because they do not know the algorithm(s) or some other 3368 characteristic that the GLA supports. There can also be times when 3369 prospective GL members or GL members need to know something about 3370 the GLA (these requests are not defined in the document). The 3371 glaQueryRequest and glaQueryResponse message have been defined to 3372 support determining this information. Figure 11 depicts the protocol 3373 interactions for glaQueryRequest and glaQueryResponse. Note error 3374 messages are not shown. Additionally, behavior for the optional 3375 transactionId, senderNonce, and recipientNonce CMC control 3376 attributes is not addressed in these procedures. 3378 +-----+ 1 2 +------------------+ 3379 | GLA | <-------> | GLO or GL Member | 3380 +-----+ +------------------+ 3382 Figure 11 - GLA Query Request & Response 3384 The process for glaQueryRequest and glaQueryResponse is as follows: 3386 1 - The GLO, GL member, or prospective GL member sends a 3387 SignedData.PKIData.controlSequence.glaQueryRequest request to 3389 Turner Expires July 2003 64 3390 And Distribution 3392 the GLA (1 in Figure 11). The GLO, GL member, or prospective 3393 GL member indicates the information they are interested in 3394 receiving from the GLA. Additionally, a signingTime attribute 3395 is included with this request. 3397 1.a - The GLO, GL member, or prospective GL member can optionally 3398 apply confidentiality to the request by encapsulating the 3399 SignedData.PKIData in an EnvelopedData (see section 3400 3.2.1.2). 3402 1.b - The GLO, GL member, or prospective GL member can also 3403 optionally apply another SignedData over the EnvelopedData 3404 (see section 3.2.1.2). 3406 2 - Upon receipt of the glaQueryRequest, the GLA determines if it 3407 accepts glaQueryRequest messages. 3409 2.a - If the GLA does not accept glaQueryRequest messages, the GLA 3410 returns a cMCStatusInfoExt response indicating 3411 cMCStatus.noSupport and any other information in 3412 statusString. 3414 2.b - Else if the GLA does accept GLAQueryRequests, the GLA checks 3415 the signingTime and verifies the GLO, GL member, or 3416 prospective GL member signature(s). If an additional 3417 SignedData and/or EnvelopedData encapsulates the request 3418 (see section 3.2.1.2 or 3.2.2), the GLA verifies the outer 3419 signature and/or decrypt the outer layer prior to verifying 3420 the signature on the inner most SignedData. 3422 2.b.1 - If the signingTime attribute value is not within the 3423 locally accepted time window, the GLA MAY return a 3424 response indicating cMCStatus.failed and 3425 otherInfo.failInfo.badTime and a signingTime attribute. 3427 2.b.2 - Else if the signature processing continues and if the 3428 signatures cannot be verified, the GLA returns a 3429 cMCStatusInfoExt response indicating cMCStatus.failed and 3430 otherInfo.failInfo.badMessageCheck. Additionally, a 3431 signingTime attribute is included with the response. 3433 2.b.3 - Else if the signatures verify, the GLA returns a 3434 glaQueryResponse (2 in Figure 11) with the correct 3435 response if the glaRequestType is supported or return a 3436 cMCStatusInfoExt response indicating cMCStatus.noSupport 3437 if the glaRequestType is not supported. Additionally, a 3438 signingTime attribute is included with the response. 3440 2.b.3.a - The GLA applies confidentiality to the response by 3441 encapsulating the SignedData.PKIResponse in an 3442 EnvelopedData if the request was encapsulated in an 3443 EnvelopedData (see section 3.2.1.2). 3445 Turner Expires July 2003 65 3446 And Distribution 3448 2.b.3.b - The GLA can also optionally apply another SignedData 3449 over the EnvelopedData (see section 3.2.1.2). 3451 3 - Upon receipt of the glaQueryResponse, the GLO, GL member, or 3452 prospective GL member checks the signingTime and verifies the 3453 GLA signature(s). If an additional SignedData and/or 3454 EnvelopedData encapsulates the response (see section 3.2.1.2 3455 or 3.2.2), the GLO, GL member, or prospective GL member 3456 verifies the outer signature and/or decrypt the outer layer 3457 prior to verifying the signature on the inner most SignedData. 3459 3.a - If the signingTime attribute value is not within the locally 3460 accepted time window, the GLO, GL member, or prospective GL 3461 member MAY return a response indicating cMCStatus.failed and 3462 otherInfo.failInfo.badTime and a signingTime attribute. 3464 3.b - Else if signature processing continues and if the signatures 3465 do not verify, the GLO, GL member, or prospective GL member 3466 returns a cMCStatusInfoExt response indicating 3467 cMCStatus.failed and otherInfo.failInfo.badMessageCheck. 3468 Additionally, a signingTime attribute is included with the 3469 response. 3471 3.c - Else if the signatures verify, then the GLO, GL member, or 3472 prospective GL member checks that one of the names in the 3473 certificate used to sign the response matches the name of 3474 the GL. 3476 3.c.1 � If the name of the GL does not match the name present in 3477 the certificate used to sign the message, the GLO ought 3478 not believe the response. 3480 3.c.2 - Else if the name of the GL matches the name present in the 3481 certificate and the response was glaQueryResponse, then 3482 the GLO, GL member, or prospective GL member may use the 3483 information contained therein. 3485 4.10 Update Member Certificate 3487 When the GLO generates a glAddMember request, when the GLA generates 3488 a glKey message, or when the GLA processes a glAddMember there can 3489 be instances when GL member's certificate has expired or is invalid. 3490 In these instances the GLO or GLA may request that the GL member 3491 provide a new certificate to avoid the GLA from being unable to 3492 generate a glKey message for the GL member. There might also be 3493 times when the GL member knows their certificate is about to expire 3494 or has been revoked and they will not be able to receive GL rekeys. 3495 Behavior for the optional transactionId, senderNonce, and 3496 recipientNonce CMC control attributes is not addressed in these 3497 procedures. 3499 Turner Expires July 2003 66 3500 And Distribution 3502 4.10.1 GLO and GLA Initiated Update Member Certificate 3504 The process for GLO initiated glUpdateCert is as follows: 3506 1 - The GLO or GLA sends a 3507 SignedData.PKIData.controlSequence.glProvideCert request to 3508 the GL member. The GLO or GLA indicates the GL name in glName 3509 and the GL member name in glMemberName. Additionally, a 3510 signingTime attribute is included with this request. 3512 1.a - The GLO or GLA can optionally apply confidentiality to the 3513 request by encapsulating the SignedData.PKIData in an 3514 EnvelopedData (see section 3.2.1.2). If the GL member's PKC 3515 has been revoked, the GLO or GLA ought not use it to 3516 generate the EnvelopedData that encapsulates the 3517 glProvideCert request. 3519 1.b - The GLO or GLA can also optionally apply another SignedData 3520 over the EnvelopedData (see section 3.2.1.2). 3522 2 - Upon receipt of the glProvideCert message, the GL member 3523 checks the signingTime and verifies the GLO or GLA 3524 signature(s). If an additional SignedData and/or EnvelopedData 3525 encapsulates the response (see section 3.2.1.2 or 3.2.2), the 3526 GL member verifies the outer signature and/or decrypt the 3527 outer layer prior to verifying the signature on the inner most 3528 SignedData. 3530 2.a - If the signingTime attribute value is not within the locally 3531 accepted time window, the GL member MAY return a response 3532 indicating cMCStatus.failed and otherInfo.failInfo.badTime 3533 and a signingTime attribute. 3535 2.b - Else if signature processing continues and if the signatures 3536 cannot be verified, the GL member returns a cMCStatusInfoExt 3537 response indicating cMCStatus.failed and 3538 otherInfo.failInfo.badMessageCheck. Additionally, a 3539 signingTime attribute is included with the response. 3541 2.c - Else if the signatures verify, the GL member generates a 3542 Signed.PKIResponse.controlSequence.glUpdateCert that 3543 includes the GL name in glName, the member name in 3544 glMember.glMemberName, their encryption certificate in 3545 glMember.certificates.pKC. The GL member can also include 3546 any attribute certificates associated with their encryption 3547 certificate in glMember.certificates.aC, and the 3548 certification path associated with their encryption and 3549 attribute certificates in glMember.certificates.certPath. 3550 Additionally, a signingTime attribute is included with the 3551 response. 3553 Turner Expires July 2003 67 3554 And Distribution 3556 2.c.1 - The GL member can optionally apply confidentiality to the 3557 request by encapsulating the SignedData.PKIResponse in an 3558 EnvelopedData (see section 3.2.1.2). If the GL member's 3559 PKC has been revoked, the GL member ought not use it to 3560 generate the EnvelopedData that encapsulates the 3561 glProvideCert request. 3563 2.c.2 - The GL member can also optionally apply another SignedData 3564 over the EnvelopedData (see section 3.2.1.2). 3566 3 - Upon receipt of the glUpdateCert message, the GLO or GLA 3567 checks the signingTime and verifies the GL member 3568 signature(s). If an additional SignedData and/or EnvelopedData 3569 encapsulates the response (see section 3.2.1.2 or 3.2.2), the 3570 GL member verifies the outer signature and/or decrypt the 3571 outer layer prior to verifying the signature on the inner most 3572 SignedData. 3574 3.a - If the signingTime attribute value is not within the locally 3575 accepted time window, the GLO or GLA MAY return a response 3576 indicating cMCStatus.failed and otherInfo.failInfo.badTime 3577 and a signingTime attribute. 3579 3.b - Else if signature processing continues and if the signatures 3580 cannot be verified, the GLO or GLA returns a 3581 cMCStatusInfoExt response indicating cMCStatus.failed and 3582 otherInfo.failInfo.badMessageCheck. Additionally, a 3583 signingTime attribute is included with the response. 3585 3.c - Else if the signatures verify, the GLO or GLA verifies the 3586 member's encryption certificate. 3588 3.c.1 - If the member's encryption certificate cannot be verified, 3589 the GLO returns either another glProvideCert request or a 3590 cMCStatusInfoExt with cMCStatus.failed and the reason why 3591 in cMCStatus.statusString. glProvideCert should be 3592 returned only a certain number of times because if the GL 3593 member does not have a valid certificate they will never 3594 be able to return one. Additionally, a signingTime 3595 attribute is included with either response. 3597 3.c.2 - Else if the member's encryption certificate cannot be 3598 verified, the GLA returns another glProvideCert request to 3599 the GL member or a cMCStatusInfoExt with cMCStatus.failed 3600 and the reason why in cMCStatus.statusString to the GLO. 3601 glProvideCert should be returned only a certain number of 3602 times because if the GL member does not have a valid 3603 certificate they will never be able to return one. 3604 Additionally, a signingTime attribute is included with the 3605 response. 3607 Turner Expires July 2003 68 3608 And Distribution 3610 3.c.3 - Else if the member's encryption certificate verifies, the 3611 GLO or GLA will use it in subsequent glAddMember requests 3612 and glKey messages associated with the GL member. 3614 4.10.2 GL Member Initiated Update Member Certificate 3616 The process for an unsolicited GL member glUpdateCert is as follows: 3618 1 - The GL member sends a 3619 Signed.PKIData.controlSequence.glUpdateCert that includes the 3620 GL name in glName, the member name in glMember.glMemberName, 3621 their encryption certificate in glMember.certificates.pKC. The 3622 GL member can also include any attribute certificates 3623 associated with their encryption certificate in 3624 glMember.certificates.aC, and the certification path 3625 associated with their encryption and attribute certificates in 3626 glMember.certificates.certPath. The GL member MUST also 3627 include a signingTime attribute with this request. 3629 1.a - The GL member can optionally apply confidentiality to the 3630 request by encapsulating the SignedData.PKIData in an 3631 EnvelopedData (see section 3.2.1.2). If the GL member's PKC 3632 has been revoked, the GLO or GLA ought not use it to 3633 generate the EnvelopedData that encapsulates the 3634 glProvideCert request. 3636 1.b - The GL member can also optionally apply another SignedData 3637 over the EnvelopedData (see section 3.2.1.2). 3639 2 - Upon receipt of the glUpdateCert message, the GLA checks the 3640 signingTime and verifies the GL member signature(s). If an 3641 additional SignedData and/or EnvelopedData encapsulates the 3642 response (see section 3.2.1.2 or 3.2.2), the GLA verifies the 3643 outer signature and/or decrypt the outer layer prior to 3644 verifying the signature on the inner most SignedData. 3646 2.a - If the signingTime attribute value is not within the locally 3647 accepted time window, the GLA MAY return a response 3648 indicating cMCStatus.failed and otherInfo.failInfo.badTime 3649 and a signingTime attribute. 3651 2.b - Else if signature processing continues and if the signatures 3652 cannot be verified, the GLA returns a cMCStatusInfoExt 3653 response indicating cMCStatus.failed and 3654 otherInfo.failInfo.badMessageCheck. 3656 2.c - Else if the signatures verify, the GLA verifies the member's 3657 encryption certificate. 3659 2.c.1 - If the member's encryption certificate cannot be verified, 3660 the GLA returns another glProvideCert request to the GL 3662 Turner Expires July 2003 69 3663 And Distribution 3665 member or a cMCStatusInfoExt with cMCStatus.failed and the 3666 reason why in cMCStatus.statusString to the GLO. 3667 glProvideCert ought not be returned indefinitely; if the 3668 GL member does not have a valid certificate they will 3669 never be able to return one. Additionally, a signingTime 3670 attribute is included with the response. 3672 2.c.2 - Else if the member's encryption certificate verifies, the 3673 GLA will use it in subsequent glAddMember requests and 3674 glKey messages associated with the GL member. The GLA also 3675 forwards the glUpdateCert message to the GLO. 3677 5 Distribution Message 3679 The GLA uses the glKey message to distribute new, shared KEK(s) 3680 after receiving glAddMember, glDeleteMember (for closed and managed 3681 GLs), glRekey, glkCompromise, or glkRefresh requests and returning a 3682 cMCStatusInfoExt response for the respective request. Figure 12 3683 depicts the protocol interactions to send out glKey messages. Unlike 3684 the procedures defined for the administrative messages, the 3685 procedures defined in this section MUST be implemented by GLAs for 3686 origination and by GL members on reception. Note that error messages 3687 are not shown. Additionally, behavior for the optional 3688 transactionId, senderNonce, and recipientNonce CMC control 3689 attributes is not addressed in these procedures. 3691 1 +----------+ 3692 +-------> | Member 1 | 3693 | +----------+ 3694 +-----+ | 1 +----------+ 3695 | GLA | ----+-------> | ... | 3696 +-----+ | +----------+ 3697 | 1 +----------+ 3698 +-------> | Member n | 3699 +----------+ 3701 Figure 12 - GL Key Distribution 3703 If the GL was setup with GLKeyAttributes.recipientsNotMutuallyAware 3704 set to TRUE, a separate glKey message MUST be sent to each GL member 3705 so as to not divulge information about the other GL members. 3707 When the glKey message is generated as a result of a: 3709 - glAddMember request, 3710 - glkComrpomise indication, 3711 - glkRefresh request, 3712 - glDeleteMember request with the GL's glAdministration set to 3713 managed or closed, and 3714 - glRekey request with generationCounter set to zero (0). 3716 Turner Expires July 2003 70 3717 And Distribution 3719 The GLA MUST use either the kari (see section 12.3.2 of [CMS]) or 3720 ktri (see section 12.3.1 of [CMS]) choice in 3721 glKey.glkWrapped.RecipientInfo to ensure only the intended 3722 recipients receive the shared KEK. The GLA MUST support the ktri 3723 choice. 3725 When the glKey message is generated as a result of a glRekey request 3726 with generationCounter greater than zero (0) or when the GLA 3727 controls rekeys, the GLA MAY use the kari, ktri, or kekri (see 3728 section 12.3.3 of [CMS]) in glKey.glkWrapped.RecipientInfo to ensure 3729 only the intended recipients receive the shared KEK. The GLA MUST 3730 support the RecipientInfo.ktri choice. 3732 5.1 Distribution Process 3734 When a glKey message is generated the process is as follows: 3736 1 - The GLA MUST send a SignedData.PKIData.controlSequence.glKey 3737 to each member by including: glName, glIdentifier, glkWrapped, 3738 glkAlgorithm, glkNotBefore, and glkNotAfter. If the GLA can 3739 not generate a glKey message for the GL member because the GL 3740 member's PKC has expired or is otherwise invalid, the GLA MAY 3741 send a glUpdateCert to the GL member requesting a new 3742 certificate be provided (see section 4.10). The number of 3743 glKey messages generated for the GL is described in section 3744 3.1.16. Additionally, a signingTime attribute is included with 3745 the distribution message(s). 3747 1.a - The GLA MAY optionally apply another confidentiality layer 3748 to the message by encapsulating the SignedData.PKIData in 3749 another EnvelopedData (see section 3.2.1.2). 3751 1.b - The GLA MAY also optionally apply another SignedData over 3752 the EnvelopedData.SignedData.PKIData (see section 3.2.1.2). 3754 2 - Upon receipt of the glKey message, the GL members MUST check 3755 the signingTime and verify the signature over the inner most 3756 SignedData.PKIData. If an additional SignedData and/or 3757 EnvelopedData encapsulates the message (see section 3.2.1.2 or 3758 3.2.2), the GL Member MUST verify the outer signature and/or 3759 decrypt the outer layer prior to verifying the signature on 3760 the SignedData.PKIData.controlSequence.glKey. 3762 2.a - If the signingTime attribute value is not within the locally 3763 accepted time window, the GLA MAY return a response 3764 indicating cMCStatus.failed and otherInfo.failInfo.badTime 3765 and a signingTime attribute. 3767 2.b - Else if signature processing continues and if the signatures 3768 cannot be verified, the GL member MUST return a 3770 Turner Expires July 2003 71 3771 And Distribution 3773 cMCStatusInfoExt response indicating cMCStatus.failed and 3774 otherInfo.failInfo.badMessageCheck. Additionally, a 3775 signingTime attribute is included with the response. 3777 2.c - Else if the signatures verify, the GL member process the 3778 RecipientInfos according to [CMS]. Once unwrapped the GL 3779 member should store the shared KEK in a safe place. When 3780 stored, the glName, glIdentifier, and shared KEK should be 3781 associated. Additionally, the GL member MUST return a 3782 cMCStatusInfoExt indicating cMCStatus.success to tell the 3783 GLA the KEK was received. 3785 6 Algorithms 3787 This section lists the algorithms that MUST be implemented. 3788 Additional algorithms that SHOULD be implemented are also included. 3789 Further algorithms MAY also be implemented. 3791 6.1 KEK Generation Algorithm 3793 Implementations MUST randomly generate content-encryption keys, 3794 message-authentication keys, initialization vectors (IVs), and 3795 padding. Also, the generation of public/private key pairs relies on 3796 a random numbers. The use of inadequate pseudo-random number 3797 generators (PRNGs) to generate cryptographic keys can result in 3798 little or no security. An attacker may find it much easier to 3799 reproduce the PRNG environment that produced the keys, searching the 3800 resulting small set of possibilities, rather than brute force 3801 searching the whole key space. The generation of quality random 3802 numbers is difficult. RFC 1750 [RANDOM] offers important guidance 3803 in this area, and Appendix 3 of FIPS Pub 186 [FIPS] provides one 3804 quality PRNG technique. 3806 6.2 Shared KEK Wrap Algorithm 3808 In the mechanisms described in sections 5, the shared KEK being 3809 distributed in glkWrapped MUST be protected by a key of equal or 3810 greater length (i.e., if a RC2 128-bit key is being distributed a 3811 key of 128-bits or greater must be used to protect the key). 3813 The algorithm object identifiers included in glkWrapped are as 3814 specified in AlgSpec [CMSALG]. 3816 6.3 Shared KEK Algorithm 3818 The shared KEK distributed and indicated in glkAlgorithm MUST 3819 support the symmetric key-encryption algorithms as specified in 3820 section AlgSpec [CMSALG]. 3822 Turner Expires July 2003 72 3823 And Distribution 3825 7 Message Transport 3827 SMTP [SMTP] MUST be supported. Other transport mechanisms MAY also 3828 be supported. 3830 8 Security Considerations 3832 As GLOs control setting up and tearing down the GL, rekeying the GL, 3833 and can control member additions and deletions, GLOs play an 3834 important role in the management of the GL, and only "trusted" GLOs 3835 should be used. 3837 If a member is deleted or removed from a closed or a managed GL, the 3838 GL needs to be rekeyed. If the GL is not rekeyed after a member is 3839 removed or deleted, the member still posses the group key and will 3840 be able to continue to decrypt any messages that can be obtained. 3842 Members who store KEKs MUST associate the name of the GLA that 3843 distributed the key so that the members can make sure subsequent 3844 rekeys are originated from the same entity. 3846 When generating keys, care should be taken to ensure that the key 3847 size is not too small and duration too long because attackers will 3848 have more time to attack the key. Key size should be selected to 3849 adequately protect sensitive business communications. 3851 GLOs and GLAs need to make sure that the generationCounter and 3852 duration are not too large. For example, if the GLO indicates that 3853 the generationCounter is 14 and the duration is one year, then 14 3854 keys are generated each with a validity period of a year. An 3855 attacker will have at least 13 years to attack the final key. 3857 Assume that two or more parties have a shared KEK, and the shared 3858 KEK is used to encrypt a second KEK for confidential distribution to 3859 those parties. The second KEK might be used to encrypt a third KEK; 3860 the third KEK might be used to encrypt a fourth KEK; and so on. If 3861 any of the KEKs in such a chain is compromised, all of the 3862 subsequent KEKs in the chain MUST also be considered compromised. 3864 An attacker can attack the group's shared KEK by attacking one 3865 member's copy of the shared KEK or attacking multiple member's 3866 copies of the shared KEK. For the attacker it may be easier to 3867 either attack the group member with the weakest security protecting 3868 their copy of the shared KEK or by attacking multiple group members. 3869 An aggregation of the information gathered during the attack(s) may 3870 lead to the compromise of the group's shared KEK. Mechanisms to 3871 protect the shared KEK should be commensurate with value of the data 3872 being protected. 3874 Turner Expires July 2003 73 3875 And Distribution 3877 The nonce and signingTime attributes are used to protect against 3878 replay attacks. However, these provisions are only helpful if 3879 entities maintain state information about the messages they have 3880 sent or received for comparison. If sufficient information is not 3881 maintained on each exchange, nonces and signingTime are not helpful. 3882 Local policy determines the amount and duration of state information 3883 that is maintained. Additionally, without a unified time source, 3884 there is the possibility of clocks drifting. Local policy determines 3885 the acceptable difference between the local time and signingTime, 3886 which must compensate for unsynchronized clock. Implementations MUST 3887 handle messages with siginingTime attributes that indicate they were 3888 created in the future. 3890 9 References 3892 9.1 Informative 3894 [STDWORDS] Bradner, S., "Key words for use in RFCs to Indicate 3895 Requirement Levels", BCP 14, RFC 2119, March 1997. 3897 [X400TRANS] Hoffman, P., and C. Bonatti, "Transporting S/MIME 3898 Objects in X.400", draft-ietf-smime-x400transport-05.txt, November 3899 2002. 3901 [RANDOM] Eastlake, D., Crocker, S. and J. Schiller, "Randomness 3902 Recommendations for Security", RFC 1750, December 1994. 3904 [FIPS] National Institute of Standards and Technology. FIPS Pub 186: 3905 Digital Signature Standard. 19 May 1994. 3907 9.1 Normative 3909 [CMS] Housley, R., "Cryptographic Message Syntax," RFC 3369, August 3910 2002. 3912 [CMC] Myers, M., Liu, X., Schaad, J., Weinsten, J., "Certificate 3913 Management Message over CMS," draft-ietf-pkix-2797-bis-00.txt, April 3914 2001. 3916 [PROFILE] Housley, R., Ford, W., Polk, W. and D. Solo, "Internet 3917 X.509 Public Key Infrastructure: Certificate and CRL Profile", RFC 3918 3280, April 2002. 3920 [ACPROF] Farrell, S., Housley, R., "An Internet Attribute 3921 Certificate Profile for Authorization", RFC 3281, April 2002. 3923 [MSG] Ramsdale, B., "S/MIME Version 3 Message Specification," RFC 3924 2633, June 1999. 3926 Turner Expires July 2003 74 3927 And Distribution 3929 [ESS] Hoffman, P., "Extended Security Services for S/MIME", RFC 3930 2634, June 1999. 3932 [CMSALG] 11 Housley, R., "Cryptographic Message Syntax (CMS) 3933 Algorithms", RFC 3370, August 2002. 3935 [SMTP] Postel, j., "Simple Mail Transport Protocol," RFC 821, August 3936 1982. 3938 10 Acknowledgements 3940 Thanks to Russ Housley and Jim Schaad for providing much of the 3941 background and review required to write this document. 3943 11 Author's Addresses 3945 Sean Turner 3946 IECA, Inc. 3947 Phone: +1.703.628.3180 3948 Email: turners@ieca.com 3950 Turner Expires July 2003 75 3951 And Distribution 3953 Annex A: ASN.1 Module 3955 SMIMESymmetricKeyDistribution 3956 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 3957 smime(16) modules(0) symkeydist(12) } 3959 DEFINITIONS IMPLICIT TAGS ::= 3960 BEGIN 3962 -- EXPORTS All -- 3963 -- The types and values defined in this module are exported for use 3964 -- in the other ASN.1 modules. Other applications may use them for 3965 -- their own purposes. 3967 IMPORTS 3969 -- PKIX Part 1 - Implicit 3970 GeneralName 3971 FROM PKIX1Implicit88 {iso(1) identified-organization(3) dod(6) 3972 internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) 3973 id-pkix1-implicit(19)} 3975 -- PKIX Part 1 - Explicit 3976 AlgorithmIdentifier, Certificate 3977 FROM PKIX1Explicit88 { iso(1) identified-organization(3) dod(6) 3978 internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) 3979 id-pkix1-explicit(18) } 3981 -- Cryptographic Message Syntax 3982 RecipientInfos, id-alg-CMS3DESwrap, KEKIdentifier, 3983 CertificateSet 3984 FROM CryptographicMessageSyntax {iso(1) member-body(2) us(840) 3985 rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) modules(0) 3986 cms-2001(14)} 3988 -- Attribute Certificate Profile 3989 AttributeCertificate FROM 3990 PKIXAttributeCertificate { iso(1) identified-organization(3) 3991 dod(6) internet(1) security(5) mechanisms(5) pkix(7) 3992 id-mod(0) id-mod-attribute-cert(12)}; 3994 -- This defines the GL symmetric key distribution object identifier 3995 -- arc. 3997 id-skd OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) 3998 rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) skd(8) } 4000 -- This defines the GL Use KEK control attribute 4002 id-skd-glUseKEK OBJECT IDENTIFIER ::= { id-skd 1} 4004 Turner Expires July 2003 76 4005 And Distribution 4007 GLUseKEK ::= SEQUENCE { 4008 glInfo GLInfo, 4009 glOwnerInfo SEQUENCE SIZE (1..MAX) OF GLOwnerInfo, 4010 glAdministration GLAdministration DEFAULT 1, 4011 glKeyAttributes GLKeyAttributes OPTIONAL } 4013 GLInfo ::= SEQUENCE { 4014 glName GeneralName, 4015 glAddress GeneralName } 4017 GLOwnerInfo ::= SEQUENCE { 4018 glOwnerName GeneralName, 4019 glOwnerAddress GeneralName, 4020 certificates Certificates OPTIONAL } 4022 GLAdministration ::= INTEGER { 4023 unmanaged (0), 4024 managed (1), 4025 closed (2) } 4027 GLKeyAttributes ::= SEQUENCE { 4028 rekeyControlledByGLO [0] BOOLEAN DEFAULT FALSE, 4029 recipientsNotMutuallyAware [1] BOOLEAN DEFAULT TRUE, 4030 duration [2] INTEGER DEFAULT 0, 4031 generationCounter [3] INTEGER DEFAULT 2, 4032 requestedAlgorithm [4] AlgorithmIdentifier 4033 DEFAULT id-alg-CMS3DESwrap } 4035 -- This defines the Delete GL control attribute. 4036 -- It has the simple type GeneralName. 4038 id-skd-glDelete OBJECT IDENTIFIER ::= { id-skd 2} 4040 DeleteGL ::= GeneralName 4042 -- This defines the Add GL Member control attribute 4044 id-skd-glAddMember OBJECT IDENTIFIER ::= { id-skd 3} 4046 GLAddMember ::= SEQUENCE { 4047 glName GeneralName, 4048 glMember GLMember } 4050 GLMember ::= SEQUENCE { 4051 glMemberName GeneralName, 4052 glMemberAddress GeneralName OPTIONAL, 4053 certificates Certificates OPTIONAL } 4055 Turner Expires July 2003 77 4056 And Distribution 4058 Certificates ::= SEQUENCE { 4059 pKC [0] Certificate OPTIONAL, 4060 -- See [PROFILE] 4061 aC [1] SEQUENCE SIZE (1.. MAX) OF 4062 AttributeCertificate OPTIONAL, 4063 -- See [ACPROF] 4064 certPath [2] CertificateSet OPTIONAL } 4065 -- From [CMS] 4067 -- This defines the Delete GL Member control attribute 4069 id-skd-glDeleteMember OBJECT IDENTIFIER ::= { id-skd 4} 4071 GLDeleteMember ::= SEQUENCE { 4072 glName GeneralName, 4073 glMemberToDelete GeneralName } 4075 -- This defines the Delete GL Member control attribute 4077 id-skd-glRekey OBJECT IDENTIFIER ::= { id-skd 5} 4079 GLRekey ::= SEQUENCE { 4080 glName GeneralName, 4081 glAdministration GLAdministration OPTIONAL, 4082 glNewKeyAttributes GLNewKeyAttributes OPTIONAL, 4083 glRekeyAllGLKeys BOOLEAN OPTIONAL } 4085 GLNewKeyAttributes ::= SEQUENCE { 4086 rekeyControlledByGLO [0] BOOLEAN OPTIONAL, 4087 recipientsNotMutuallyAware [1] BOOLEAN OPTIONAL, 4088 duration [2] INTEGER OPTIONAL, 4089 generationCounter [3] INTEGER OPTIONAL, 4090 requestedAlgorithm [4] AlgorithmIdentifier OPTIONAL } 4092 -- This defines the Add and Delete GL Owner control attributes 4094 id-skd-glAddOwner OBJECT IDENTIFIER ::= { id-skd 6} 4095 id-skd-glRemoveOwner OBJECT IDENTIFIER ::= { id-skd 7} 4097 GLOwnerAdministration ::= SEQUENCE { 4098 glName GeneralName, 4099 glOwnerInfo GLOwnerInfo } 4101 -- This defines the GL Key Compromise control attribute. 4102 -- It has the simple type GeneralName. 4104 id-skd-glKeyCompromise OBJECT IDENTIFIER ::= { id-skd 8} 4106 GLKCompromise ::= GeneralName 4108 Turner Expires July 2003 78 4109 And Distribution 4111 -- This defines the GL Key Refresh control attribute. 4113 id-skd-glkRefresh OBJECT IDENTIFIER ::= { id-skd 9} 4115 GLKRefresh ::= SEQUENCE { 4116 glName GeneralName, 4117 dates SEQUENCE SIZE (1..MAX) OF Date } 4119 Date ::= SEQUENCE { 4120 start GeneralizedTime, 4121 end GeneralizedTime OPTIONAL } 4123 -- This defines the GLA Query Request control attribute. 4125 id-skd-glaQueryRequest OBJECT IDENTIFIER ::= { id-skd 11} 4127 GLAQueryRequest ::= SEQUENCE { 4128 glaRequestType OBJECT IDENTIFIER, 4129 glaRequestValue ANY DEFINED BY glaRequestType } 4131 -- This defines the GLA Query Response control attribute. 4133 id-skd-glaQueryResponse OBJECT IDENTIFIER ::= { id-skd 12} 4135 GLAQueryResponse ::= SEQUENCE { 4136 glaResponseType OBJECT IDENTIFIER, 4137 glaResponseValue ANY DEFINED BY glaResponseType } 4139 -- This defines the GLA Request/Response (glaRR) arc for 4140 -- glaRequestType/glaResponseType. 4142 id-cmc-glaRR OBJECT IDENTIFIER ::= { iso(1) identified- 4143 organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) 4144 cmc(7) glaRR(99) } 4146 -- This defines the Algorithm Request 4148 id-cmc-gla-skdAlgRequest OBJECT IDENTIFIER ::= { id-cmc-glaRR 1 } 4150 SKDAlgRequest ::= NULL 4152 -- This defines the Algorithm Response 4154 id-cmc-gla-skdAlgResponse OBJECT IDENTIFIER ::= { id-cmc-glaRR 2 } 4156 -- Note that the response for algorithmSupported request is the 4157 -- smimeCapabilities attribute as defined in MsgSpec [MSG]. 4159 Turner Expires July 2003 79 4160 And Distribution 4162 -- This defines the control attribute to request an updated 4163 -- certificate to the GLA. 4165 id-skd-glProvideCert OBJECT IDENTIFIER ::= { id-skd 13} 4167 GLManageCert ::= SEQUENCE { 4168 glName GeneralName, 4169 glMember GLMember } 4171 -- This defines the control attribute to return an updated 4172 -- certificate to the GLA. It has the type GLManageCert. 4174 id-skd-glManageCert OBJECT IDENTIFIER ::= { id-skd 14} 4176 -- This defines the control attribute to distribute the GL shared 4177 -- KEK. 4179 id-skd-glKey OBJECT IDENTIFIER ::= { id-skd 15} 4181 GLKey ::= SEQUENCE { 4182 glName GeneralName, 4183 glIdentifier KEKIdentifier, -- See [CMS] 4184 glkWrapped RecipientInfos, -- See [CMS] 4185 glkAlgorithm AlgorithmIdentifier, 4186 glkNotBefore GeneralizedTime, 4187 glkNotAfter GeneralizedTime } 4189 Turner Expires July 2003 80 4190 And Distribution 4192 -- This defines the CMC error types 4194 id-cet-skdFailInfo OBJECT IDENTIFIER ::= { iso(1) 4195 identified-organization(3) dod(6) internet(1) security(5) 4196 mechanisms(5) pkix(7) cet(15) skdFailInfo(1) } 4198 SKDFailInfo ::= INTEGER { 4199 unspecified (0), 4200 closedGL (1), 4201 unsupportedDuration (2), 4202 noGLACertificate (3), 4203 invalidCert (4), 4204 unsupportedAlgorithm (5), 4205 noGLONameMatch (6), 4206 invalidGLName (7), 4207 nameAlreadyInUse (8), 4208 noSpam (9), 4209 deniedAccess (10), 4210 alreadyAMember (11), 4211 notAMember (12), 4212 alreadyAnOwner (13), 4213 notAnOwner (14) } 4215 END -- SMIMESymmetricKeyDistribution 4217 Expires July 2003 4219 Turner Expires July 2003 81