idnits 2.17.00 (12 Aug 2021) /tmp/idnits53644/draft-ietf-smime-symkeydist-10.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 14. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 3974. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 3985. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 3992. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 3998. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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 13 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == Line 359 has weird spacing: '...esponse id-...' == Line 1285 has weird spacing: '...eturned and...' == Line 1367 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 28, 2008) is 5220 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 3828 -- Looks like a reference, but probably isn't: '1' on line 3829 -- Looks like a reference, but probably isn't: '2' on line 3830 -- Looks like a reference, but probably isn't: '3' on line 3831 -- Looks like a reference, but probably isn't: '4' on line 3832 ** Obsolete normative reference: RFC 3852 (ref. 'CMS') (Obsoleted by RFC 5652) -- Possible downref: Non-RFC (?) normative reference: ref. 'CMC' ** 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 3851 (ref. 'MSG') (Obsoleted by RFC 5751) ** Obsolete normative reference: RFC 2821 (ref. 'SMTP') (Obsoleted by RFC 5321) Summary: 7 errors (**), 0 flaws (~~), 5 warnings (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 SMIME Working Group S. Turner, IECA 2 Internet Draft January 28, 2008 3 Intended Status: Standard Track 4 Expires: July 28, 2008 6 CMS Symmetric Key Management and Distribution 7 draft-ietf-smime-symkeydist-10.txt 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html 32 This Internet-Draft will expire on July 28, 2008. 34 Copyright Notice 36 Copyright (C) The IETF Trust (2008). 38 Abstract 40 This document describes a mechanism to manage (i.e., setup, 41 distribute, and rekey) keys used with symmetric cryptographic 42 algorithms. Also defined herein is a mechanism to organize users into 43 groups to support distribution of encrypted content using symmetric 44 cryptographic algorithms. The mechanism uses the Cryptographic 45 Message Syntax (CMS) protocol [CMS] and Certificate Management 46 Message over CMS (CMC) protocol [CMC] to manage the symmetric keys. 47 Any member of the group can then later use this distributed shared 48 key to decrypt other CMS encrypted objects with the symmetric key. 50 This mechanism has been developed to support S/MIME Mail List Agents 51 (MLAs). 53 Conventions used in this document 55 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 56 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 57 document are to be interpreted as described in [RFC2119]. 59 Table of Contents 61 1. Introduction...................................................3 62 1.1. Applicability to E-mail...................................4 63 1.2. Applicability to Repositories.............................5 64 1.3. Using the Group Key.......................................5 65 2. Architecture...................................................5 66 3. Protocol Interactions..........................................7 67 3.1. Control Attributes........................................8 68 3.1.1. GL USE KEK..........................................10 69 3.1.2. Delete GL...........................................13 70 3.1.3. Add GL Member.......................................14 71 3.1.4. Delete GL Member....................................15 72 3.1.5. Rekey GL............................................15 73 3.1.6. Add GL Owner........................................16 74 3.1.7. Remove GL Owner.....................................17 75 3.1.8. GL Key Compromise...................................17 76 3.1.9. GL Key Refresh......................................17 77 3.1.10. GLA Query Request and Response.....................18 78 3.1.10.1. GLA Query Request.............................18 79 3.1.10.2. GLA Query Response............................18 80 3.1.10.3. Request and Response Types....................19 81 3.1.11. Provide Cert.......................................19 82 3.1.12. Update Cert........................................20 83 3.1.13. GL Key.............................................21 84 3.2. Use of CMC, CMS, and PKIX................................23 85 3.2.1. Protection Layers...................................23 86 3.2.1.1. Minimum Protection.............................23 87 3.2.1.2. Additional Protection..........................24 88 3.2.2. Combining Requests and Responses....................25 89 3.2.3. GLA Generated Messages..............................26 90 3.2.4. CMC Control Attributes and CMS Signed Attributes....27 91 3.2.4.1. Using cMCStatusInfoExt.........................27 92 3.2.4.2. Using transactionId............................30 93 3.2.4.3. Using nonces and signingTime...................30 94 3.2.4.4. CMC and CMS Attribute Support Requirements.....31 95 3.2.5. Resubmitted GL Member Messages......................31 96 3.2.6. PKIX Certificate and CRL Profile....................32 98 4. Administrative Messages.......................................32 99 4.1. Assign KEK To GL.........................................32 100 4.2. Delete GL From GLA.......................................36 101 4.3. Add Members To GL........................................38 102 4.3.1. GLO Initiated Additions.............................40 103 4.3.2. Prospective Member Initiated Additions..............46 104 4.4. Delete Members From GL...................................49 105 4.4.1. GLO Initiated Deletions.............................50 106 4.4.2. Member Initiated Deletions..........................55 107 4.5. Request Rekey Of GL......................................57 108 4.5.1. GLO Initiated Rekey Requests........................58 109 4.5.2. GLA Initiated Rekey Requests........................61 110 4.6. Change GLO...............................................62 111 4.7. Indicate KEK Compromise..................................64 112 4.7.1. GL Member Initiated KEK Compromise Message..........65 113 4.7.2. GLO Initiated KEK Compromise Message................66 114 4.8. Request KEK Refresh......................................67 115 4.9. GLA Query Request and Response...........................69 116 4.10. Update Member Certificate...............................71 117 4.10.1. GLO and GLA Initiated Update Member Certificate....72 118 4.10.2. GL Member Initiated Update Member Certificate......74 119 5. Distribution Message..........................................75 120 5.1. Distribution Process.....................................76 121 6. Algorithms....................................................78 122 6.1. KEK Generation Algorithm.................................78 123 6.2. Shared KEK Wrap Algorithm................................78 124 6.3. Shared KEK Algorithm.....................................78 125 7. Message Transport.............................................78 126 8. Security Considerations.......................................78 127 9. IANA Considerations...........................................80 128 10. Acknowledgements.............................................80 129 11. References...................................................80 130 11.1. Normative References....................................80 131 11.2. Informative References..................................81 132 12. ASN.1 Module.................................................81 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). There 139 are essentially two ways to encrypt the data for recipients: using 140 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 generate 150 the same KEK (kari RecipientInfo CHOICE). If the group is large, 151 processing of the per-recipient information may take quite some time, 152 not to mention the time required to collect and validate the PKCs for 153 each of the recipients. Each recipient identifies its per-recipient 154 information and uses the private key associated with the public key 155 of its PKC to decrypt the CEK and hence gain access to the encrypted 156 content. 158 With symmetric algorithms, the origination process is slightly 159 different. Instead of using PKCs, the originator uses a previously 160 distributed secret key-encryption key (KEK) to encrypt the CEK (kekri 161 RecipientInfo CHOICE). Only one copy of the encrypted CEK is required 162 because all the recipients already have the shared KEK needed to 163 decrypt the CEK and hence gain access to the encrypted content. 165 The techniques to protect the shared KEK are beyond the scope of this 166 document. Only the members of the list and the key manager should 167 have the KEK in order to maintain confidentiality. Access control to 168 the information protected by the KEK is determined by the entity that 169 encrypts the information, as all members of the group have access. If 170 the entity that is performing the encryption wants to ensure some 171 subset of the group does not gain access to the information either a 172 different KEK should be used (shared only with this smaller group) or 173 asymmetric algorithms should be used. 175 1.1. Applicability to E-mail 177 One primary audience for this distribution mechanism is e-mail. 178 Distribution lists, sometimes referred to as mail lists, support the 179 distribution of messages to recipients subscribed to the mail list. 180 There are two models for how the mail list can be used. If the 181 originator is a member of the mail list, the originator sends 182 messages encrypted with the shared KEK to the mail list (e.g., 183 listserv or majordomo) and the message is distributed to the mail 184 list members. If the originator is not a member of the mail list 185 (does not have the shared KEK), the originator sends the message 186 (encrypted for the MLA) to the mail list agent (MLA), and then the 187 MLA uses the shared KEK to encrypt the message for the members. In 188 either case the recipients of the mail list use the previously 189 distributed-shared KEK to decrypt the message. 191 1.2. Applicability to Repositories 193 Objects can also be distributed via a repository (e.g., Lightweight 194 Directory Protocol (LDAP) servers, X.500 Directory System Agents 195 (DSAs), Web-based servers). If an object is stored in a repository 196 encrypted with a symmetric key algorithm, anyone with the shared KEK 197 and access to that object can then decrypt that object. The encrypted 198 object and the encrypted, shared KEK can be stored in the repository. 200 1.3. Using the Group Key 202 This document was written with three specific scenarios in mind: two 203 supporting mail list agents and one for general message distribution. 204 Scenario 1 depicts the originator sending a public key (PK) protected 205 message to a MLA who then uses the shared KEK(s) to redistribute the 206 message to the members of the list. Scenario 2 depicts the originator 207 sending a shared KEK protected message to a MLA who then 208 redistributes the message to the members of the list (the MLA only 209 adds additional recipients). The key used by the originator could 210 either be a key shared amongst all recipients or just between the 211 member and the MLA. Note that if the originator use a key shared only 212 with the MLA, then the MLA will need to decrypt the message and 213 rencrypt the message for the list recipients. Scenario 3 shows an 214 originator sending a shared KEK protected message to a group of 215 recipients without an intermediate MLA. 217 +----> +----> +----> 218 PK +-----+ S | S +-----+ S | S | 219 ----> | MLA | --+----> ----> | MLA | --+----> ----+----> 220 +-----+ | +-----+ | | 221 +----> +----> +----> 222 Scenario 1 Scenario 2 Scenario 3 224 2. Architecture 226 Figure 1 depicts the architecture to support symmetric key 227 distribution. The Group List Agent (GLA) supports two distinct 228 functions with two different agents: 230 - The Key Management Agent (KMA) which is responsible for generating 231 the shared KEKs. 233 - The Group Management Agent (GMA) which is responsible for managing 234 the Group List (GL) to which the shared KEKs are distributed. 236 +----------------------------------------------+ 237 | Group List Agent | +-------+ 238 | +------------+ + -----------------------+ | | Group | 239 | | Key | | Group Management Agent | |<-->| List | 240 | | Management |<-->| +------------+ | | | Owner | 241 | | Agent | | | Group List | | | +-------+ 242 | +------------+ | +------------+ | | 243 | | / | \ | | 244 | +------------------------+ | 245 +----------------------------------------------+ 246 / | \ 247 / | \ 248 +----------+ +---------+ +----------+ 249 | Member 1 | | ... | | Member n | 250 +----------+ +---------+ +----------+ 252 Figure 1 - Key Distribution Architecture 254 A GLA may support multiple KMAs. A GLA in general supports only one 255 GMA, but the GMA may support multiple GLs. Multiple KMAs may support 256 a GMA in the same fashion as GLAs support multiple KMAs. Assigning a 257 particular KMA to a GL is beyond the scope of this document. 259 Modeling real world GL implementations shows that there are very 260 restrictive GLs, where a human determines GL membership, and very 261 open GLs, where there are no restrictions on GL membership. To 262 support this spectrum, the mechanism described herein supports both 263 managed (i.e., where access control is applied) and unmanaged (i.e., 264 where no access control is applied) GLs. The access control mechanism 265 for managed lists is beyond the scope of this document. 267 Note: If the distribution for the list is performed by an entity 268 other than the originator (e.g., an MLA distributing a mail message), 269 this entity can also enforce access control rules. 271 In either case, the GL must initially be constructed by an entity 272 hereafter called the Group List Owner (GLO). There may be multiple 273 entities who 'own' the GL and who are allowed to make changes to the 274 GL's properties or membership. The GLO determines if the GL will be 275 managed or unmanaged and is the only entity that may delete the GL. 276 GLO(s) may or may not be GL members. GLO(s) may also set up lists 277 that are closed, where the GLO solely determines GL membership. 279 Though Figure 1 depicts the GLA as encompassing both the KMA and GMA 280 functions, the two functions could be supported by the same entity or 281 they could be supported by two different entities. If two entities 282 are used, they could be located on one or two platforms. There is 283 however a close relationship between the KMA and GMA functions. If 284 the GMA stores all information pertaining to the GLs and the KMA 285 merely generates keys, a corrupted GMA could cause havoc. To protect 286 against a corrupted GMA, the KMA would be forced to double check the 287 requests it receives to ensure the GMA did not tamper with them. 288 These duplicative checks blur the functionality of the two components 289 together. For this reason, the interactions between the KMA and GMA 290 are beyond the scope of this document. 292 Proprietary mechanisms may be used to separate the functions by 293 strengthening the trust relationship between the two entities. 294 Henceforth, the distinction between the two agents is not discussed 295 further; the term GLA will be used to address both functions. It 296 should be noted that corrupt GLA can always cause havoc. 298 3. Protocol Interactions 300 There are existing mechanisms (e.g., listserv and majordomo) to 301 manage GLs; however, this document does not address securing these 302 mechanisms, as they are not standardized. Instead, it defines 303 protocol interactions, as depicted in Figure 2, used by the GL 304 members, GLA, and GLO(s) to manage GLs and distribute shared KEKs. 305 The interactions have been divided into administration messages and 306 distribution messages. The administrative messages are the request 307 and response messages needed to setup the GL, delete the GL, add 308 members to the GL, delete members of the GL, request a group rekey, 309 add owners to the GL, remove owners of the GL, indicate a group key 310 compromise, refresh a group key, interrogate the GLA, and update 311 member's and owner's public key certificates. The distribution 312 messages are the messages that distribute the shared KEKs. The 313 following sections describe the ASN.1 for both the administration and 314 distribution messages. Section 4 describes how to use the 315 administration messages, and section 5 describes how to use the 316 distribution messages. 318 +-----+ +----------+ 319 | GLO | <---+ +----> | Member 1 | 320 +-----+ | | +----------+ 321 | | 322 +-----+ <------+ | +----------+ 323 | GLA | <-------------+----> | ... | 324 +-----+ | +----------+ 325 | 326 | +----------+ 327 +----> | Member n | 328 +----------+ 330 Figure 2 - Protocol Interactions 332 3.1. Control Attributes 334 To avoid creating an entirely new protocol, the Certificate 335 Management Messages over CMS (CMC) protocol was chosen as the 336 foundation of this protocol. The main reason for the choice was the 337 layering aspect provided by CMC where one or more control attributes 338 are included in message, protected with CMS, to request or respond to 339 a desired action. The CMC PKIData structure is used for requests, and 340 the CMC PKIResponse structure is used for responses. The content- 341 types PKIData and PKIResponse are then encapsulated in CMS's 342 SignedData or EnvelopedData, or a combination of the two (see section 343 3.2). The following are the control attributes defined in this 344 document: 346 Control 347 Attribute OID Syntax 348 ------------------- ----------- ----------------- 349 glUseKEK id-skd 1 GLUseKEK 350 glDelete id-skd 2 GeneralName 351 glAddMember id-skd 3 GLAddMember 352 glDeleteMember id-skd 4 GLDeleteMember 353 glRekey id-skd 5 GLRekey 354 glAddOwner id-skd 6 GLOwnerAdministration 355 glRemoveOwner id-skd 7 GLOwnerAdministration 356 glkCompromise id-skd 8 GeneralName 357 glkRefresh id-skd 9 GLKRefresh 358 glaQueryRequest id-skd 11 GLAQueryRequest 359 glaQueryResponse id-skd 12 GLAQueryResponse 360 glProvideCert id-skd 13 GLManageCert 361 glUpdateCert id-skd 14 GLManageCert 362 glKey id-skd 15 GLKey 364 In the following conformance tables, the column headings have the 365 following meanings: O for originate, R for receive, and F for 366 forward. There are three types of implementations: GLOs, GLAs, and GL 367 members. The GLO is an optional component hence all GLO O and GLO R 368 messages are optional, and GLA F messages are optional. The first 369 table includes messages that conformant implementions MUST support. 370 The second table includes messages that MAY be implemented. The 371 second table should be interpreted as follows: if the control 372 attribute is implemented by a component then it must be implemented 373 as indicated. For example, if a GLA is implemented that supports the 374 glAddMember control attribute, then it MUST support receiving the 375 glAddMember message. Note that "-" means not applicable. 377 Required 378 Implementation Requirement | Control 379 GLO | GLA | GL Member | Attribute 380 O R | O R F | O R | 381 ------- | ----------------- | --------- | ---------- 382 MAY - | MUST - MAY | - MUST | glProvideCert 383 MAY MAY | - MUST MAY | MUST - | glUpdateCert 384 - - | MUST - - | - MUST | glKey 386 Optional 387 Implementation Requirement | Control 388 GLO | GLA | GL Member | Attribute 389 O R | O R F | O R | 390 ------- | ----------------- | --------- | ---------- 391 MAY - | - MAY - | - - | glUseKEK 392 MAY - | - MAY - | - - | glDelete 393 MAY MAY | - MUST MAY | MUST - | glAddMember 394 MAY MAY | - MUST MAY | MUST - | glDeleteMember 395 MAY - | - MAY - | - - | glRekey 396 MAY - | - MAY - | - - | glAddOwner 397 MAY - | - MAY - | - - | glRemoveOwner 398 MAY MAY | - MUST MAY | MUST - | glkCompromise 399 MAY - | - MUST - | MUST - | glkRefresh 400 MAY - | - SHOULD - | MAY - | glaQueryRequest 401 - MAY | SHOULD - - | - MAY | glaQueryResponse 403 glaQueryResponse and gloResponse are carried in the CMC PKIResponse 404 content-type, all other control attributes are carried in the CMC 405 PKIData content-type. The exception is glUpdateCert which can be 406 carried in either PKIData or PKIResponse. 408 Success and failure messages use CMC (see section 3.2.4). 410 3.1.1. GL USE KEK 412 The GLO uses glUseKEK to request that a shared KEK be assigned to a 413 GL. glUseKEK messages MUST be signed by the GLO. The glUseKEK control 414 attribute has the syntax GLUseKEK: 416 GLUseKEK ::= SEQUENCE { 417 glInfo GLInfo, 418 glOwnerInfo SEQUENCE SIZE (1..MAX) OF GLOwnerInfo, 419 glAdministration GLAdministration DEFAULT 1, 420 glKeyAttributes GLKeyAttributes OPTIONAL } 422 GLInfo ::= SEQUENCE { 423 glName GeneralName, 424 glAddress GeneralName } 426 GLOwnerInfo ::= SEQUENCE { 427 glOwnerName GeneralName, 428 glOwnerAddress GeneralName, 429 certificate Certificates OPTIONAL } 431 Certificates ::= SEQUENCE { 432 pKC [0] Certificate OPTIONAL, 433 -- See [PROFILE] 434 aC [1] SEQUENCE SIZE (1.. MAX) OF 435 AttributeCertificate OPTIONAL, 436 -- See [ACPROF] 437 certPath [2] CertificateSet OPTIONAL } 438 -- From [CMS] 440 -- CertificateSet and CertificateChoices are included only 441 -- for illustrative purposes as they are imported from [CMS]. 443 CertificateSet ::= SET SIZE (1..MAX) OF CertificateChoices 445 -- CertificateChoices supports X.509 public key certificates in 446 -- certificates and v2 attribute certificates in v2AttrCert. 448 GLAdministration ::= INTEGER { 449 unmanaged (0), 450 managed (1), 451 closed (2) } 453 GLKeyAttributes ::= SEQUENCE { 454 rekeyControlledByGLO [0] BOOLEAN DEFAULT FALSE, 455 recipientsNotMutuallyAware [1] BOOLEAN DEFAULT TRUE, 456 duration [2] INTEGER DEFAULT 0, 457 generationCounter [3] INTEGER DEFAULT 2, 458 requestedAlgorithm [4] AlgorithmIdentifier 459 DEFAULT { id-aes128-wrap } } 461 The fields in GLUseKEK have the following meaning: 463 - glInfo indicates the name of the GL in glName and the address of 464 the GL in glAddress. The glName and glAddress can be the same, 465 but this is not always the case. Both the name and address MUST 466 be unique for a given GLA. 468 - glOwnerInfo indicates: 470 -- glOwnerName indicates the name of the owner of the GL. One of 471 the names in glOwnerName MUST match one of the names in the 472 certificate (either the subject distinguished name or one of 473 the subject alternative names) used to sign this 474 SignedData.PKIData creating the GL (i.e., the immediate 475 signer). 477 -- glOwnerAddress indicates the address of the owner of the GL. 479 -- certificates MAY be included. It contains the following three 480 fields: 482 --- certificates.pKC includes the encryption certificate for 483 the GLO. It will be used to encrypt responses for the 484 GLO. 486 --- certificates.aC MAY be included to convey any attribute 487 certificate (see [ACPROF]) associated with the 488 encryption certificate of the GLO included in 489 certificates.pKC. 491 --- certificates.certPath MAY also be included to convey 492 certificates that might aid the recipient in 493 constructing valid certification paths for the 494 certificate provided in certificates.pKC and the 495 attribute certificates provided in certificates.aC. 496 Theses certificates are optional because they might 497 already be included elsewhere in the message (e.g., in 498 the outer CMS layer). 500 -- glAdministration indicates how the GL ought to be 501 administered. The default is for the list to be managed. 502 Three values are supported for glAdministration: 504 --- Unmanaged - When the GLO sets glAdministration to 505 unmanaged, it is allowing prospective members to 506 request addition and deletion from the GL without GLO 507 intervention. 509 --- Managed - When the GLO sets glAdministration to managed, 510 it is allowing prospective members to request addition 511 and deletion from the GL, but the request is redirected 512 by the GLA to GLO for review. The GLO makes the 513 determination as to whether to honor the request. 515 --- Closed - When the GLO sets glAdministration to closed, 516 it is not allowing prospective members to request 517 addition or deletion from the GL. The GLA will only 518 accept glAddMember and glDeleteMember requests from the 519 GLO. 521 -- glKeyAttributes indicates the attributes the GLO wants the 522 GLA to assign to the shared KEK. If this field is omitted, 523 GL rekeys will be controlled by the GLA, the recipients are 524 allowed to know about one another, the algorithm will be 525 Triple-DES (see paragrpah 7), the shared KEK will be valid 526 for a calendar month (i.e., first of the month until the 527 last day of the month), and two shared KEKs will be 528 distributed initially. The fields in glKeyAttributes have 529 the following meaning: 531 --- rekeyControlledByGLO indicates whether the GL rekey 532 messages will be generated by the GLO or by the GLA. 533 The default is for the GLA to control rekeys. If GL 534 rekey is controlled by the GLA, the GL will continue to 535 be rekeyed until the GLO deletes the GL or changes the 536 GL rekey to be GLO controlled. 538 --- recipientsNotMutuallyAware indicates that the GLO wants 539 the GLA to distribute the shared KEK individually for 540 each of the GL members (i.e., a separate glKey message 541 is sent to each recipient). The default is for separate 542 glKey message not to be required. 544 NOTE: This supports lists where one member does not 545 know the identities of the other members. For example, 546 a list is configured granting submit permissions to 547 only one member. All other members are 'listening.' The 548 security policy of the list does not allow the members 549 to know who else is on the list. If a glKey is 550 constructed for all of the GL members, information 551 about each of the members may be derived from the 552 information in RecipientInfos. To make sure the glkey 553 message does not divulge information about the other 554 recipients, a separate glKey message would be sent to 555 each GL member. 557 --- duration indicates the length of time (in days) during 558 which the shared KEK is considered valid. The value 559 zero (0) indicates that the shared KEK is valid for a 560 calendar month in the UTC Zulu time zone. For example 561 if the duration is zero (0), if the GL shared KEK is 562 requested on July 24, the first key will be valid until 563 the end of July and the next key will be valid for the 564 entire month of August. If the value is not zero (0), 565 the shared KEK will be valid for the number of days 566 indicated by the value. For example, if the value of 567 duration is seven (7) and the shared KEK is requested 568 on Monday but not generated until Tuesday (2359); the 569 shared KEKs will be valid from Tuesday (2359) to 570 Tuesday (2359). The exact time of the day is determined 571 when the key is generated. 573 --- generationCounter indicates the number of keys the GLO 574 wants the GLA to distribute. To ensure uninterrupted 575 function of the GL two (2) shared KEKs at a minimum 576 MUST be initially distributed. The second shared KEK is 577 distributed with the first shared KEK, so that when the 578 first shared KEK is no longer valid the second key can 579 be used. If the GLA controls rekey then it also 580 indicates the number of shared KEKs the GLO wants 581 outstanding at any one time. See sections 4.5 and 5 for 582 more on rekey. 584 --- requestedAlgorithm indicates the algorithm and any 585 parameters the GLO wants the GLA to use with the shared 586 KEK. The parameters are conveyed via the 587 SMIMECapabilities attribute (see [MSG]). See section 6 588 for more on algorithms. 590 3.1.2. Delete GL 592 GLOs use glDelete to request that a GL be deleted from the GLA. The 593 glDelete control attribute has the syntax GeneralName. The glDelete 594 message MUST be signed by the GLO. The name of the GL to be deleted 595 is included in GeneralName: 597 DeleteGL ::= GeneralName 599 3.1.3. Add GL Member 601 GLOs use the glAddMember to request addition of new members, and 602 prospective GL members use the glAddMember to request their own 603 addition to the GL. The glAddMember message MUST be signed by either 604 the GLO or the prospective GL member. The glAddMember control 605 attribute has the syntax GLAddMember: 607 GLAddMember ::= SEQUENCE { 608 glName GeneralName, 609 glMember GLMember } 611 GLMember ::= SEQUENCE { 612 glMemberName GeneralName, 613 glMemberAddress GeneralName OPTIONAL, 614 certificates Certificates OPTIONAL } 616 The fields in GLAddMembers have the following meaning: 618 - glName indicates the name of the GL to which the member should be 619 added. 621 - glMember indicates the particulars for the GL member. Both of the 622 following fields must be unique for a given GL: 624 -- glMemberName indicates the name of the GL member. 626 -- glMemberAddress indicates the GL member's address. It MUST be 627 included. 629 Note: In some instances the glMemberName and glMemberAddress 630 may be the same, but this is not always the case. 632 -- certificates MUST be included. It contains the following three 633 fields: 635 --- certificates.pKC includes the member's encryption 636 certificate. It will be used, at least initially, to 637 encrypt the shared KEK for that member. If the message is 638 generated by a prospective GL member, the pKC MUST be 639 included. If the message is generated by a GLO, the pKC 640 SHOULD be included. 642 --- certificates.aC MAY be included to convey any attribute 643 certificate (see [ACPROF]) associated with the member's 644 encryption certificate. 646 --- certificates.certPath MAY also be included to convey 647 certificates that might aid the recipient in constructing 648 valid certification paths for the certificate provided in 649 certificates.pKC and the attribute certificates provided 650 in certificates.aC. These certificates are optional 651 because they might already be included elsewhere in the 652 message (e.g., in the outer CMS layer). 654 3.1.4. Delete GL Member 656 GLOs use the glDeleteMember to request deletion of GL members, and GL 657 members use the glDeleteMember to request their own removal from the 658 GL. The glDeleteMember message MUST be signed by either the GLO or 659 the GL member. The glDeleteMember control attribute has the syntax 660 GLDeleteMember: 662 GLDeleteMember ::= SEQUENCE { 663 glName GeneralName, 664 glMemberToDelete GeneralName } 666 The fields in GLDeleteMembers have the following meaning: 668 - glName indicates the name of the GL from which the member should 669 be removed. 671 - glMemberToDelete indicates the name or address of the member to 672 be deleted. 674 3.1.5. Rekey GL 676 GLOs use the glRekey to request a GL rekey. The glRekey message MUST 677 be signed by the GLO. The glRekey control attribute has the syntax 678 GLRekey: 680 GLRekey ::= SEQUENCE { 681 glName GeneralName, 682 glAdministration GLAdministration OPTIONAL, 683 glNewKeyAttributes GLNewKeyAttributes OPTIONAL, 684 glRekeyAllGLKeys BOOLEAN OPTIONAL } 686 GLNewKeyAttributes ::= SEQUENCE { 687 rekeyControlledByGLO [0] BOOLEAN OPTIONAL, 688 recipientsNotMutuallyAware [1] BOOLEAN OPTIONAL, 689 duration [2] INTEGER OPTIONAL, 690 generationCounter [3] INTEGER OPTIONAL, 691 requestedAlgorithm [4] AlgorithmIdentifier OPTIONAL } 693 The fields in GLRekey have the following meaning: 695 - glName indicates the name of the GL to be rekeyed. 697 - glAdministration indicates if there is any change to how the GL 698 should be administered. See section 3.1.1 for the three options. 699 This field is only included if there is a change from the 700 previously registered administered. 702 - glNewKeyAttributes indicates whether the rekey of the GLO is 703 controlled by the GLA or GL, what algorithm and parameters the 704 GLO wishes to use, the duration of the key, and how many keys 705 will be issued. The field is only included if there is a change 706 from the previously registered glKeyAttributes. 708 - glRekeyAllGLKeys indicates whether the GLO wants all of the 709 outstanding GL's shared KEKs rekeyed. If it is set to TRUE then 710 all outstanding KEKs MUST be issued. If it is set to FALSE then 711 all outstanding KEKs need not be resissued. 713 3.1.6. Add GL Owner 715 GLOs use the glAddOwner to request that a new GLO be allowed to 716 administer the GL. The glAddOwner message MUST be signed by a 717 registered GLO. The glAddOwner control attribute has the syntax 718 GLOwnerAdministration: 720 GLOwnerAdministration ::= SEQUENCE { 721 glName GeneralName, 722 glOwnerInfo GLOwnerInfo } 724 The fields in GLAddOwners have the following meaning: 726 - glName indicates the name of the GL to which the new GLO should 727 be associated. 729 - glOwnerInfo indicates the name, address, and certificates of the 730 new GLO. As this message includes names of new GLOs, the 731 certificates.pKC MUST be included, and it MUST include the 732 encryption certificate of the new GLO. 734 3.1.7. Remove GL Owner 736 GLOs use the glRemoveOwner to request that a GLO be disassociated 737 with the GL. The glRemoveOwner message MUST be signed by a registered 738 GLO. The glRemoveOwner control attribute has the syntax 739 GLOwnerAdministration: 741 GLOwnerAdministration ::= SEQUENCE { 742 glName GeneralName, 743 glOwnerInfo GLOwnerInfo } 745 The fields in GLRemoveOwners have the following meaning: 747 - glName indicates the name of the GL to which the GLO should be 748 disassociated. 750 - glOwnerInfo indicates the name and address of the GLO to be 751 removed. The certificates field SHOULD be omitted, as it will be 752 ignored. 754 3.1.8. GL Key Compromise 756 GL members and GLOs use glkCompromise to indicate that the shared KEK 757 possessed has been compromised. The glKeyCompromise control attribute 758 has the syntax GeneralName. This message is always redirected by the 759 GLA to the GLO for further action. The glkCompromise MAY be included 760 in an EnvelopedData generated with the compromised shared KEK. The 761 name of the GL to which the compromised key is associated with is 762 placed in GeneralName: 764 GLKCompromise ::= GeneralName 766 3.1.9. GL Key Refresh 768 GL members use the glkRefresh to request that the shared KEK be 769 redistributed to them. The glkRefresh control attribute has the 770 syntax GLKRefresh. 772 GLKRefresh ::= SEQUENCE { 773 glName GeneralName, 774 dates SEQUENCE SIZE (1..MAX) OF Date } 776 Date ::= SEQUENCE { 777 start GeneralizedTime, 778 end GeneralizedTime OPTIONAL } 780 The fields in GLKRefresh have the following meaning: 782 - glName indicates the name of the GL for which the GL member wants 783 shared KEKs. 785 - dates indicates a date range for keys the GL member wants. The 786 start field indicates the first date the GL member wants and the 787 end field indicates the last date. The end date MAY be omitted 788 to indicate the GL member wants all keys from the specified 789 start date to the current date. Note that a procedural mechanism 790 is needed to restrict users from accessing messages that they 791 are not allowed to access. 793 3.1.10. GLA Query Request and Response 795 There are situations where GLOs and GL members may need to determine 796 some information from the GLA about the GL. GLOs and GL members use 797 the glaQueryRequest, defined in section 3.1.10.1, to request 798 information and GLAs use the glaQueryResponse, defined in section 799 3.1.10.2, to return the requested information. Section 3.1.10.3 800 includes one request and response type and value; others may be 801 defined in additional documents. 803 3.1.10.1. GLA Query Request 805 GLOs and GL members use the glaQueryRequest to ascertain information 806 about the GLA. The glaQueryRequest control attribute has the syntax 807 GLAQueryRequest: 809 GLAQueryRequest ::= SEQUENCE { 810 glaRequestType OBJECT IDENTIFIER, 811 glaRequestValue ANY DEFINED BY glaRequestType } 813 3.1.10.2. GLA Query Response 815 GLAs return the glaQueryResponse after receiving a GLAQueryRequest. 816 The glaQueryResponse MUST be signed by a GLA. The glaQueryResponse 817 control attribute has the syntax GLAQueryResponse: 819 GLAQueryResponse ::= SEQUENCE { 820 glaResponseType OBJECT IDENTIFIER, 821 glaResponseValue ANY DEFINED BY glaResponseType } 823 3.1.10.3. Request and Response Types 825 Request and Responses are registered as a pair under the following 826 object identifier arc: 828 id-cmc-glaRR OBJECT IDENTIFIER ::= { id-cmc 99 } 830 This document defines one request/response pair for GL members and 831 GLOs to query the GLA for the list of algorithm it supports. The 832 following object identifier (OID) is included in the glaQueryType 833 field: 835 id-cmc-gla-skdAlgRequest OBJECT IDENTIFIER ::={ id-cmc-glaRR 1 } 837 SKDAlgRequest ::= NULL 839 If the GLA supports GLAQueryRequest and GLAQueryResponse messages, 840 the GLA may return the following OID in the glaQueryType field: 842 id-cmc-gla-skdAlgResponse OBJECT IDENTIFIER ::= { id-cmc-glaRR 2 } 844 The glaQueryValue has the form of the smimeCapabilities attributes as 845 defined in [MSG]. 847 3.1.11. Provide Cert 849 GLAs and GLOs use the glProvideCert to request that a GL member 850 provide an updated or new encryption certificate. The glProvideCert 851 message MUST be signed by either GLA or GLO. If the GL member's PKC 852 has been revoked, the GLO or GLA MUST NOT use it to generate the 853 EnvelopedData that encapsulates the glProvideCert request. The 854 glProvideCert control attribute has the syntax GLManageCert: 856 GLManageCert ::= SEQUENCE { 857 glName GeneralName, 858 glMember GLMember } 860 The fields in GLManageCert have the following meaning: 862 - glName indicates the name of the GL to which the GL member's new 863 certificate is to be associated. 865 - glMember indicates particulars for the GL member: 867 -- glMemberName indicates the GL member's name. 869 -- glMemberAddress indicates the GL member's address. It MAY be 870 omitted. 872 -- certificates SHOULD be omitted. 874 3.1.12. Update Cert 876 GL members and GLOs use the glUpdateCert to provide a new certificate 877 for the GL. GL members can generate an unsolicited glUpdateCert or 878 generate a response glUpdateCert as a result of receiveing a 879 glProvideCert message. GL members MUST sign the glUpdateCert. If the 880 GL member's encryption certificate has been revoked, the GL member 881 MUST NOT use it to generate the EnvelopedData that encapsulates the 882 glUpdateCert request or response. The glUpdateCert control attribute 883 has the syntax GLManageCert: 885 GLManageCert ::= SEQUENCE { 886 glName GeneralName, 887 glMember GLMember } 889 The fields in GLManageCert have the following meaning: 891 - glName indicates the name of the GL to which the GL member's new 892 certificate should be associated. 894 - glMember indicates the particulars for the GL member: 896 -- glMemberName indicates the GL member's name. 898 -- glMemberAddress indicates the GL member's address. It MAY be 899 omitted. 901 -- certificates MAY be omitted if the GLManageCert message is 902 sent to request the GL member's certificate; otherwise, it 903 MUST be included. It includes the following three fields: 905 ---- certificates.pKC includes the member's encryption 906 certificate that will be used to encrypt the shared KEK 907 for that member. 909 --- certificates.aC MAY be included to convey one or more 910 attribute certificate associated with the member's 911 encryption certificate. 913 --- certificates.certPath MAY also be included to convey 914 certificates that might aid the recipient in 915 constructing valid certification paths for the 916 certificate provided in certificates.pKC and the 917 attribute certificates provided in certificates.aC. 918 These certificates is optional because they might 919 already be included elsewhere in the message (e.g., in 920 the outer CMS layer). 922 3.1.13. GL Key 924 The GLA uses the glKey to distribute the shared KEK. The glKey 925 message MUST be signed by the GLA. The glKey control attribute has 926 the syntax GLKey: 928 GLKey ::= SEQUENCE { 929 glName GeneralName, 930 glIdentifier KEKIdentifier, -- See [CMS] 931 glkWrapped RecipientInfos, -- See [CMS] 932 glkAlgorithm AlgorithmIdentifier, 933 glkNotBefore GeneralizedTime, 934 glkNotAfter GeneralizedTime } 936 -- KEKIdentifier is included only for illustrative purposes as 937 -- it is imported from [CMS]. 939 KEKIdentifier ::= SEQUENCE { 940 keyIdentifier OCTET STRING, 941 date GeneralizedTime OPTIONAL, 942 other OtherKeyAttribute OPTIONAL } 944 The fields in GLKey have the following meaning: 946 - glName is the name of the GL. 948 - glIdentifier is the key identifier of the shared KEK. See 949 paragraph 6.2.3 of [CMS] for a description of the subfields. 951 - glkWrapped is the wrapped shared KEK for the GL for a particular 952 duration. The RecipientInfos MUST be generated as specified in 953 section 6.2 of [CMS]. The ktri RecipientInfo choice MUST be 954 supported. The key in the EncryptedKey field (i.e., the 955 distributed shared KEK) MUST be generated according to the 956 section concerning random number generation in the security 957 considerations of [CMS]. 959 - glkAlgorithm identifies the algorithm the shared KEK is used 960 with. Since no encrypted data content is being conveyed at this 961 point, the parameters encoded with the algorithm should be the 962 structure defined for smimeCapabilities rather than encrypted 963 content. 965 - glkNotBefore indicates the date at which the shared KEK is 966 considered valid. GeneralizedTime values MUST be expressed in 967 UTC (Zulu) and MUST include seconds (i.e., times are 968 YYYYMMDDHHMMSSZ), even where the number of seconds is zero. 969 GeneralizedTime values MUST NOT include fractional seconds. 971 - glkNotAfter indicates the date after which the shared KEK is 972 considered invalid. GeneralizedTime values MUST be expressed in 973 UTC (Zulu) and MUST include seconds (i.e., times are 974 YYYYMMDDHHMMSSZ), even where the number of seconds is zero. 975 GeneralizedTime values MUST NOT include fractional seconds. 977 If the glKey message is in response to a glUseKEK message: 979 - The GLA MUST generate separate glKey messages for each recipient 980 if glUseKEK.glKeyAttributes.recipientsNotMutuallyAware is set to 981 TRUE. For each recipient, you want to generate a message that 982 contains that recipient's key (i.e., one message with one 983 attribute). 985 - The GLA MUST generate the requested number of glKey messages. The 986 value in glUseKEK.glKeyAttributes.generationCounter indicates 987 the number of glKey messages requested. 989 If the glKey message is in response to a glRekey message: 991 - The GLA MUST generate separate glKey messages for each recipient 992 if glRekey.glNewKeyAttributes.recipientsNotMutuallyAware is set 993 to TRUE. 995 - The GLA MUST generate the requested number of glKey messages. The 996 value in glUseKEK.glKeyAttributes.generationCounter indicates 997 the number of glKey messages requested. 999 - The GLA MUST generate one glKey messagefor each outstanding 1000 shared KEKs for the GL when glRekeyAllGLKeys is set to TRUE. 1002 If the glKey message was not in response to a glRekey or glUseKEK 1003 (e.g., where the GLA controls rekey): 1005 - The GLA MUST generate separate glKey messages for each recipient 1006 when glUseKEK.glNewKeyAttributes.recipientsNotMutuallyAware that 1007 set up the GL was set to TRUE. 1009 - The GLA MAY generate glKey messages prior to the duration on the 1010 last outstanding shared KEK expiring, where the number of glKey 1011 messages generated is generationCounter minus one (1). Other 1012 distribution mechanisms can also be supported to support this 1013 functionality. 1015 3.2. Use of CMC, CMS, and PKIX 1017 The following sections outline the use of CMC, CMS, and the PKIX 1018 certificate and CRL profile. 1020 3.2.1. Protection Layers 1022 The following sections outline the protection required for the 1023 control attributes defined in this document. 1025 Note: There are multiple ways to encapsulate SignedData and 1026 EnvelopedData. The first is to use a MIME wrapper around each 1027 ContentInfo, as specified in [MSG]. The second is to not use a MIME 1028 wrapper around each ContentInfo, as specified in Transporting S/MIME 1029 Objects in X.400 [X400TRANS]. 1031 3.2.1.1. Minimum Protection 1033 At a minimum, a SignedData MUST protect each request and response 1034 encapsulated in PKIData and PKIResponse. The following is a depiction 1035 of the minimum wrappings: 1037 Minimum Protection 1038 ------------------ 1039 SignedData 1040 PKIData or PKIResponse 1041 controlSequence 1043 Prior to taking any action on any request or response SignedData(s) 1044 MUST be processed according to [CMS]. 1046 3.2.1.2. Additional Protection 1048 An additional EnvelopedData MAY also be used to provide 1049 confidentiality of the request and response. An additional SignedData 1050 MAY also be added to provide authentication and integrity of the 1051 encapsulated EnvelopedData. The following is a depiction of the 1052 optional additional wrappings: 1054 Authentication and Integrity 1055 Confidentiality Protection of Confidentiality Protection 1056 -------------------------- ----------------------------- 1057 EnvelopedData SignedData 1058 SignedData EnvelopedData 1059 PKIData or PKIResponse SignedData 1060 controlSequence PKIData or PKIResponse 1061 controlSequence 1063 If an incoming message is encrypted, the confidentiality of the 1064 message MUST be preserved. All EnvelopedData objects MUST be 1065 processed as specified in [CMS]. If a SignedData is added over an 1066 EnvelopedData, a ContentHints attribute SHOULD be added. See 1067 paragraph 2.9 of Extended Security Services for S/MIME [ESS]. 1069 If the GLO or GL member applies confidentiality to a request, the 1070 EnvelopedData MUST include the GLA as a recipient. If the GLA 1071 forwards the GL member request to the GLO, then the GLA MUST decrypt 1072 the EnvelopedData content, strip the confidentiality layer, and apply 1073 its own confidentiality layer as an EnvelopedData with the GLO as a 1074 recipient. 1076 3.2.2. Combining Requests and Responses 1078 Multiple requests and response corresponding to a GL MAY be included 1079 in one PKIData.controlSequence or PKIResponse.controlSequence. 1080 Requests and responses for multiple GLs MAY be combined in one 1081 PKIData or PKIResponse by using PKIData.cmsSequence and 1082 PKIResponse.cmsSequence. A separate cmsSequence MUST be used for 1083 different GLs. That is, requests corresponding to two different GLs 1084 are included in different cmsSequences. The following is a diagram 1085 depicting multiple requests and responses combined in one PKIData and 1086 PKIResponse: 1088 Multiple Request and Response 1089 Request Response 1090 ------- -------- 1091 SignedData SignedData 1092 PKIData PKIResponse 1093 cmsSequence cmsSequence 1094 SignedData SignedData 1095 PKIData PKIResponse 1096 controlSequence controlSequence 1097 One or more requests One or more responses 1098 corresponding to one GL corresponding to one GL 1099 SignedData SignedData 1100 PKIData PKIResponse 1101 controlSequence controlSequence 1102 One or more requests One or more responses 1103 corresponding to another GL corresponding to another GL 1105 When applying confidentiality to multiple requests and responses, all 1106 of the requests/response MAY be included in one EnvelopedData. 1108 The following is a depiction: 1110 Confidentiality of Multiple Requests and Responses 1111 Wrapped Together 1112 ---------------- 1113 EnvelopedData 1114 SignedData 1115 PKIData 1116 cmsSequence 1117 SignedData 1118 PKIResponse 1119 controlSequence 1120 One or more requests 1121 corresponding to one GL 1122 SignedData 1123 PKIData 1124 controlSequence 1125 One or more requests 1126 corresponding to one GL 1128 Certain combinations of requests in one PKIData.controlSequence and 1129 one PKIResponse.controlSequence are not allowed. The invalid 1130 combinations listed here MUST NOT be generated: 1132 Invalid Combinations 1133 --------------------------- 1134 glUseKEK & glDeleteMember 1135 glUseKEK & glRekey 1136 glUseKEK & glDelete 1137 glDelete & glAddMember 1138 glDelete & glDeleteMember 1139 glDelete & glRekey 1140 glDelete & glAddOwner 1141 glDelete & glRemoveOwner 1143 To avoid unnecessary errors, certain requests and responses SHOULD be 1144 processed prior to others. The following is the priority of message 1145 processing, if not listed it is an implementation decision as to 1146 which to process first: glUseKEK before glAddMember, glRekey before 1147 glAddMember, and glDeleteMember before glRekey. Note that there is a 1148 processing priority but it does not imply an ordering within the 1149 content. 1151 3.2.3. GLA Generated Messages 1153 When the GLA generates a success or fail message, it generates one 1154 for each request. SKDFailInfo values of unsupportedDuration, 1155 unsupportedDeliveryMethod, unsupportedAlgorithm, noGLONameMatch, 1156 nameAlreadyInUse, alreadyAnOwner, notAnOwner are not returned to GL 1157 members. 1159 If GLKeyAttributes.recipientsNotMutuallyAware is set to TRUE, a 1160 separate PKIResponse.cMCStatusInfoExt and PKIData.glKey MUST be 1161 generated for each recipient. However, it is valid to send one 1162 message with multiple attributes to the same recipient. 1164 If the GL has multiple GLOs, the GLA MUST send cMCStatusInfoExt 1165 messages to the requesting GLO. The mechanism to determine which GLO 1166 made the request is beyond the scope of this document. 1168 If a GL is managed and the GLA receives a glAddMember, 1169 glDeleteMember, or glkCompromise message, the GLA redirects the 1170 request to the GLO for review. An additional, SignedData MUST be 1171 applied to the redirected request as follows: 1173 GLA Forwarded Requests 1174 ---------------------- 1175 SignedData 1176 PKIData 1177 cmsSequence 1178 SignedData 1179 PKIData 1180 controlSequence 1182 3.2.4. CMC Control Attributes and CMS Signed Attributes 1184 CMC carries control attributes as CMS signed attributes. These 1185 attributes are defined in [CMC] and [CMS]. Some of these attributes 1186 are REQUIRED; others are OPTIONAL. The required attributes are as 1187 follows: cMCStatusInfoExt transactionId, senderNonce, recipientNonce, 1188 queryPending, and signingTime. Other attributes can also be used; 1189 however, their use is beyond the scope of this document. The 1190 following sections specify requirements in addition to those already 1191 specified in [CMC] and [CMS]. 1193 3.2.4.1. Using cMCStatusInfoExt 1195 cMCStatusInfoExt is used by GLAs to indicate to GLOs and GL members 1196 that a request was unsuccessful. Two classes of failure codes are 1197 used within this document. Errors from the CMCFailInfo list, found in 1198 section 5.1.4 of CMC, are encoded as defined in CMC. Error codes 1199 defined in this document are encoded using the ExtendedFailInfo field 1200 of the cmcStatusInfoExt structure. If the same failure code applies 1201 to multiple commands, a single cmcStatusInfoExt structure can be used 1202 with multiple items in cMCStatusInfoExt.bodyList. The GLA MAY also 1203 return other pertinent information in statusString. The SKDFailInfo 1204 object identifier and value are: 1206 id-cet-skdFailInfo OBJECT IDENTIFIER ::= { iso(1) 1207 identified-organization(3) dod(6) internet(1) security(5) 1208 mechanisms(5) pkix(7) cet(15) skdFailInfo(1) } 1210 SKDFailInfo ::= INTEGER { 1211 unspecified (0), 1212 closedGL (1), 1213 unsupportedDuration (2), 1214 noGLACertificate (3), 1215 invalidCert (4), 1216 unsupportedAlgorithm (5), 1217 noGLONameMatch (6), 1218 invalidGLName (7), 1219 nameAlreadyInUse (8), 1220 noSpam (9), 1221 deniedAccess (10), 1222 alreadyAMember (11), 1223 notAMember (12), 1224 alreadyAnOwner (13), 1225 notAnOwner (14) } 1227 The values have the following meaning: 1229 - unspecified indicates that the GLA is unable or unwilling to 1230 perform the requested action and does not want to indicate the 1231 reason. 1233 - closedGL indicates that members can only be added or deleted by 1234 the GLO. 1236 - unsupportedDuration indicates the GLA does not support generating 1237 keys that are valid for the requested duration. 1239 - noGLACertificate indicates that the GLA does not have a valid 1240 certificate. 1242 - invalidCert indicates the member's encryption certificate was not 1243 verifiable (i.e., signature did not validate, certificate's 1244 serial number present on a CRL, expired, etc.). 1246 - unsupportedAlgorithm indicates the GLA does not support the 1247 requested algorithm. 1249 - noGLONameMatch indicates that one of the names in the certificate 1250 used to sign a request does not match the name of a registered 1251 GLO. 1253 - invalidGLName indicates the GLA does not support the glName 1254 present in the request. 1256 - nameAlreadyInUse indicates the glName is already assigned on the 1257 GLA. 1259 - noSpam indicates the prospective GL member did not sign the 1260 request (i.e., if the name in glMember.glMemberName does not 1261 match one of the names (either the subject distinguished name or 1262 one of the subject alternative names) in the certificate used to 1263 sign the request). 1265 - alreadyAMember indicates the prospective GL member is already a 1266 GL member. 1268 - notAMember indicates the prospective GL member to be deleted is 1269 not presently a GL member. 1271 - alreadyAnOwner indicates the prospective GLO is already a GLO. 1273 - notAnOwner indicates the prospective GLO to be deleted is not 1274 presently a GLO. 1276 cMCStatusInfoExt is used by GLAs to indicate to GLOs and GL members 1277 that a request was successfully completed. If the request was 1278 successful, the GLA returns a cMCStatusInfoExt response with 1279 cMCStatus.success and optionally other pertinent information in 1280 statusString. 1282 When the GL is managed and the GLO has reviewed GL member initiated 1283 glAddMember, glDeleteMember, and glkComrpomise requests, the GLO uses 1284 cMCStatusInfoExt to indicate the success or failure of the request. 1285 If the request is allowed, cMCStatus.success is returned and 1286 statusString is optionally returned to convey additional information. 1287 If the request is denied, cMCStatus.failed is returned and 1288 statusString is optionally returned to convey additional information. 1289 Additionally, the appropriate SKDFailInfo can be included in 1290 cMCStatusInfoExt.extendedFailInfo. 1292 cMCStatusInfoExt is used by GLOs, GLAs, and GL members to indicate 1293 that signature verification failed. If the signature failed to verify 1294 over any control attibute except a cMCStatusInfoExt, a 1295 cMCStatusInfoExt control attribute MUST be returned indicating 1296 cMCStatus.failed and otherInfo.failInfo.badMessageCheck. If the 1297 signature over the outermost PKIData failed, the bodyList value is 1298 zero (0). If the signature over any other PKIData failed the bodyList 1299 value is the bodyPartId value from the request or response. GLOs and 1300 GL members who receive cMCStatusInfoExt messages whose signatures are 1301 invalid SHOULD generate a new request to avoid badMessageCheck 1302 message loops. 1304 cMCStatusInfoExt is also used by GLOs and GLAs to indicate that a 1305 request could not be performed immediately. If the request could not 1306 be processed immediately by the GLA or GLO, the cMCStatusInfoExt 1307 control attribute MUST be returned indicating cMCStatus.pending and 1308 otherInfo.pendInfo. When requests are redirected to the GLO for 1309 approval (for managed lists), the GLA MUST NOT return a 1310 cMCStatusInfoExt indicating query pending. 1312 cMCStatusInfoExt is also used by GLAs to indicate that a 1313 glaQueryRequest is not supported. If the glaQueryRequest is not 1314 supported, the cMCStatusInfoExt control attribute MUST be returned 1315 indicating cMCStatus.noSupport and statusString is optionally 1316 returned to convey additional information. 1318 cMCStatusInfoExt is also used by GL members, GLOs, and GLAs to 1319 indicate that the signingTime (see section 3.2.4.3) is not close 1320 enough to the locally specified time. If the local time is not close 1321 enough to the time specified in signingTime, a cMCStatus.failed and 1322 otherInfo.failInfo.badTime MAY be returned. 1324 3.2.4.2. Using transactionId 1326 transactionId MAY be included by GLOs, GLAs, or GL members to 1327 identify a given transaction. All subsequent requests and responses 1328 related to the original request MUST include the same transactionId 1329 control attribute. If GL members include a transactionId and the 1330 request is redirected to the GLO, the GLA MAY include an additional 1331 transactionId in the outer PKIData. If the GLA included an additional 1332 transactionId in the outer PKIData, when the GLO generates a 1333 cMCStatusInfoExt response it generates one for the GLA with the GLA's 1334 transactionId and one for the GL member with the GL member's 1335 transactionId. 1337 3.2.4.3. Using nonces and signingTime 1339 The use of nonces (see section 5.6 of [CMC]) and an indication of 1340 when the message was signed (see section 11.3 of [CMS]) can be used 1341 to provide application-level replay prevention. 1343 To protect the GL, all messages MUST include the signingTime 1344 attribute. Message originators and recipients can then use the time 1345 provided in this attribute to determine whether they have previously 1346 received the message. 1348 If the originating message includes a senderNonce, the response to 1349 the message MUST include the received senderNonce value as the 1350 recipientNonce and a new value as the senderNonce value in the 1351 response. 1353 If a GLA aggragates multiple messages together or forwards a message 1354 to a GLO, the GLA MAY optionally generate a new nonce value and 1355 include that in the wrapping message. When the response comes back 1356 from the GLO, the GLA builds a response to the originator(s) of the 1357 message(s) and deals with each of the nonce values from the 1358 originating messages. 1360 For these attributes it is necessary to maintain state information on 1361 exchanges to compare one result to another. The time period for which 1362 this information is maintained in a local policy. 1364 3.2.4.4. CMC and CMS Attribute Support Requirements 1366 The following are the implementation requirements for CMC control 1367 attributes and CMS signed attributes for an implementation be 1368 considered conformant to this specification: 1370 Implementation Requirement | 1371 GLO | GLA | GL Member | Attribute 1372 O R | O R F | O R | 1373 --------- | ------------- | --------- | ---------- 1374 MUST MUST | MUST MUST - | MUST MUST | cMCStatusInfoExt 1375 MAY MAY | MUST MUST - | MAY MAY | transactionId 1376 MAY MAY | MUST MUST - | MAY MAY | senderNonce 1377 MAY MAY | MUST MUST - | MAY MAY | recepientNonce 1378 MUST MUST | MUST MUST - | MUST MUST | SKDFailInfo 1379 MUST MUST | MUST MUST - | MUST MUST | signingTime 1381 3.2.5. Resubmitted GL Member Messages 1383 When the GL is managed, the GLA forwards the GL member requests to 1384 the GLO for GLO approval by creating a new request message containing 1385 the GL member request(s) as a cmsSequence item. If the GLO approves 1386 the request it can either add a new layer of wrapping and send it 1387 back to the GLA or create a new message and send it to the GLA. (Note 1388 in this case there are now 3 layers of PKIData messages with 1389 appropriate signing layers.) 1391 3.2.6. PKIX Certificate and CRL Profile 1393 Signatures, certificates, and CRLs are verified according to the PKIX 1394 profile [PROFILE]. 1396 Name matching is performed according to the PKIX profile [PROFILE]. 1398 All distinguished name forms must follow the UTF8String convention 1399 noted in the PKIX profile [PROFILE]. 1401 A certificate per-GL would be issued to the GLA. 1403 GL policy may mandate that the GL member's address be included in the 1404 GL member's certificate. 1406 4. Administrative Messages 1408 There are a number of administrative messages that must be performed 1409 to manage a GL. The following sections describe each request and 1410 response message combination in detail. The procedures defined in 1411 this section are not prescriptive. 1413 4.1. Assign KEK To GL 1415 Prior to generating a group key, a GL needs to be setup and a shared 1416 KEK assigned to the GL. Figure 3 depicts the protocol interactions to 1417 setup and assign a shared KEK. Note that error messages are not 1418 depicted in Figure 3. Additionally, behavior for the optional 1419 transactionId, senderNonce, and recipientNonce CMC control attributes 1420 is not addressed in these procedures. 1422 +-----+ 1 2 +-----+ 1423 | GLA | <-------> | GLO | 1424 +-----+ +-----+ 1426 Figure 3 - Create Group List 1428 The process is as follows: 1430 1 - The GLO is the entity responsible for requesting the creation 1431 of the GL. The GLO sends a 1432 SignedData.PKIData.controlSequence.glUseKEK request to the GLA 1433 (1 in Figure 3). The GLO MUST include: glName, glAddress, 1434 glOwnerName, glOwnerAddress, and glAdministration. The GLO MAY 1435 also include their preferences for the shared KEK in 1436 glKeyAttributes by indicating whether the GLO controls the 1437 rekey in rekeyControlledByGLO, whether separate glKey messages 1438 should be sent to each recipient in recipientsNotMutuallyAware, 1439 the requested algorithm to be used with the shared KEK in 1440 requestedAlgorithm, the duration of the shared KEK, and how 1441 many shared KEKs should be initially distributed in 1442 generationCounter. The GLO MUST also include the signingTime 1443 attribute with this request. 1445 1.a - If the GLO knows of members to be added to the GL, the 1446 glAddMember request(s) MAY be included in the same 1447 controlSequence as the glUseKEK request (see section 3.2.2). 1448 The GLO indicates the same glName in the glAddMember request 1449 as in glUseKEK.glInfo.glName. Further glAddMember procedures 1450 are covered in section 4.3. 1452 1.b - The GLO can apply confidentiality to the request by 1453 encapsulating the SignedData.PKIData in an EnvelopedData 1454 (see section 3.2.1.2). 1456 1.c - The GLO can also optionally apply another SignedData over the 1457 EnvelopedData (see section 3.2.1.2). 1459 2 - Upon receipt of the request, the GLA checks the signingTime and 1460 verifies the signature on the inner most SignedData.PKIData. If 1461 an additional SignedData and/or EnvelopedData encapsulates the 1462 request (see sections 3.2.1.2 and 3.2.2), the GLA verifies the 1463 outer signature(s) and/or decrypt the outer layer(s) prior to 1464 verifying the signature on the inner most SignedData. 1466 2.a - If the signingTime attribute value is not within the locally 1467 accepted time window, the GLA MAY return a response 1468 indicating cMCStatus.failed and otherInfo.failInfo.badTime 1469 and a signingTime attribute. 1471 2.b - Else if signature processing continues and if the signatures 1472 do not verify, the GLA returns a cMCStatusInfoExt response 1473 indicating cMCStatus.failed and 1474 otherInfo.failInfo.badMessageCheck. Additionally, a 1475 signingTime attribute is included with the response. 1477 2.c - Else if the signatures do verify but the GLA does not have a 1478 valid certificate, the GLA returns a cMCStatusInfoExt with 1479 cMCStatus.failed and otherInfo.extendedFailInfo.SKDFailInfo 1480 value of noValidGLACertificate. Additionally, a signingTime 1481 attribute is included with the response. Instead of 1482 immediately returning the error code, the GLA attempts to 1483 get a certificate, possibly using [CMC]. 1485 2.d - Else the signatures are valid and the GLA does have a valid 1486 certificate, the GLA checks that one of the names in the 1487 certificate used to sign the request matches one of the 1488 names in glUseKEK.glOwnerInfo.glOwnerName. 1490 2.d.1 - If the names do not match, the GLA returns a response 1491 indicating cMCStatusInfoExt with cMCStatus.failed and 1492 otherInfo.extendedFailInfo.SKDFailInfo value of 1493 noGLONameMatch. Additionally, a signingTime attribute is 1494 included with the response. 1496 2.d.2 - Else if the names all match, the GLA checks that the glName 1497 and glAddress is not already in use. The GLA also checks 1498 any glAddMember included within the controlSequence with 1499 this glUseKEK. Further processing of the glAddMember is 1500 covered in section 4.3. 1502 2.d.2.a - If the glName is already in use the GLA returns a 1503 response indicating cMCStatusInfoExt with 1504 cMCStatus.failed and 1505 otherInfo.extendedFailInfo.SKDFailInfo value of 1506 nameAlreadyInUse. Additionally, a signingTime attribute 1507 is included with the response. 1509 2.d.2.b - Else if the requestedAlgorithm is not supported, the GLA 1510 returns a response indicating cMCStatusInfoExt with 1511 cMCStatus.failed and 1512 otherInfo.extendedFailInfo.SKDFailInfo value of 1513 unsupportedAlgorithm. Additionally, a signingTime 1514 attribute is included with the response. 1516 2.d.2.c - Else if the duration cannot be supported, determining 1517 this is beyond the scope of this document, the GLA 1518 returns a response indicating cMCStatusInfoExt with 1519 cMCStatus.failed and 1520 otherInfo.extendedFailInfo.SKDFailInfo value of 1521 unsupportedDuration. Additionally, a signingTime 1522 attribute is included with the response. 1524 2.d.2.d - Else if the GL cannot be supported for other reasons, 1525 which the GLA does not wish to disclose, the GLA returns 1526 a response indicating cMCStatusInfoExt with 1527 cMCStatus.failed and 1528 otherInfo.extendedFailInfo.SKDFailInfo value of 1529 unspecified. Additionally, a signingTime attribute is 1530 included with the response. 1532 2.d.2.e - Else if the glName is not already in use, the duration 1533 can be supported, and the requestedAlgorithm is 1534 supported, the GLA MUST return a cMCStatusInfoExt 1535 indicating cMCStatus.success and a signingTime attribute. 1536 (2 in Figure 3). The GLA also takes administrative 1537 actions, which are beyond the scope of this document, to 1538 store the glName, glAddress, glKeyAttributes, 1539 glOwnerName, and glOwnerAddress. The GLA also sends a 1540 glKey message as described in section 5. 1542 2.d.2.e.1 - The GLA can apply confidentiality to the response by 1543 encapsulating the SignedData.PKIResponse in an 1544 EnvelopedData if the request was encapsulated in an 1545 EnvelopedData (see section 3.2.1.2). 1547 2.d.2.e.2 - The GLA can also optionally apply another SignedData 1548 over the EnvelopedData (see section 3.2.1.2). 1550 3 - Upon receipt of the cMCStatusInfoExt responses, the GLO checks 1551 the signingTime and verifies the GLA signature(s). If an 1552 additional SignedData and/or EnvelopedData encapsulates the 1553 response (see section 3.2.1.2 or 3.2.2), the GLO verifies the 1554 outer signature and/or decrypt the outer layer prior to 1555 verifying the signature on the inner most SignedData. 1557 3.a - If the signingTime attribute value is not within the locally 1558 accepted time window, the GLO MAY return a response 1559 indicating cMCStatus.failed and otherInfo.failInfo.badTime 1560 and a signingTime attribute. 1562 3.b - Else if signature processing continues and if the signatures 1563 do verify, the GLO MUST check that one of the names in the 1564 certificate used to sign the response matches the name of 1565 the GL. 1567 3.b.1 - If the name of the GL does not match the name present in 1568 the certificate used to sign the message, the GLO should 1569 not believe the response. 1571 3.b.2 - Else if the name of the GL does match the name present in 1572 the certificate and: 1574 3.b.2.a - If the signatures do verify and the response was 1575 cMCStatusInfoExt indicating cMCStatus.success, the GLO 1576 has successfully created the GL. 1578 3.b.2.b - Else if the signatures are valid and the response is 1579 cMCStatusInfoExt.cMCStatus.failed with any reason, the 1580 GLO can reattempt to create the GL using the information 1581 provided in the response. The GLO can also use the 1582 glaQueryRequest to determine the algorithms and other 1583 characteristics supported by the GLA (see section 4.9). 1585 4.2. Delete GL From GLA 1587 From time to time, there are instances when a GL is no longer needed. 1588 In this case, the GLO deletes the GL. Figure 4 depicts that protocol 1589 interactions to delete a GL. Note that behavior for the optional 1590 transactionId, senderNonce, and recipientNonce CMC control attributes 1591 is not addressed in these procedures. 1593 +-----+ 1 2 +-----+ 1594 | GLA | <-------> | GLO | 1595 +-----+ +-----+ 1597 Figure 4 - Delete Group List 1599 The process is as follows: 1601 1 - The GLO is responsible for requesting the deletion of the GL. 1602 The GLO sends a SignedData.PKIData.controlSequence.glDelete 1603 request to the GLA (1 in Figure 4). The name of the GL to be 1604 deleted is included in GeneralName. The GLO MUST also include 1605 the signingTime attribute and can also include a transactionId 1606 and senderNonce attributes. 1608 1.a - The GLO can optionally apply confidentiality to the request 1609 by encapsulating the SignedData.PKIData in an EnvelopedData 1610 (see section 3.2.1.2). 1612 1.b - The GLO MAY optionally apply another SignedData over the 1613 EnvelopedData (see section 3.2.1.2). 1615 2 - Upon receipt of the request the GLA checks the signingTime and 1616 verifies the signature on the inner most SignedData.PKIData. If 1617 an additional SignedData and/or EnvelopedData encapsulates the 1618 request (see section 3.2.1.2 or 3.2.2), the GLA verifies the 1619 outer signature and/or decrypt the outer layer prior to 1620 verifying the signature on the inner most SignedData. 1622 2.a - If the signingTime attribute value is not within the locally 1623 accepted time window, the GLA MAY return a response 1624 indicating cMCStatus.failed and otherInfo.failInfo.badTime 1625 and a signingTime attribute. 1627 2.b - Else if signature processing continues and if the signatures 1628 cannot be verified, the GLA returns a cMCStatusInfoExt 1629 response indicating cMCStatus.failed and 1630 otherInfo.failInfo.badMessageCheck. Additionally, a 1631 signingTime attribute is included with the response. 1633 2.c - Else if the signatures verify, the GLA makes sure the GL is 1634 supported by checking the name of the GL matches a glName 1635 stored on the GLA. 1637 2.c.1 - If the glName is not supported by the GLA, the GLA returns 1638 a response indicating cMCStatusInfoExt with 1639 cMCStatus.failed and otherInfo.extendedFailInfo.SKDFailInfo 1640 value of invalidGLName. Additionally, a signingTime 1641 attribute is included with the response. 1643 2.c.2 - Else if the glName is supported by the GLA, the GLA ensures 1644 a registered GLO signed the glDelete request by checking if 1645 one of the names present in the digital signature 1646 certificate used to sign the glDelete request matches a 1647 registered GLO. 1649 2.c.2.a - If the names do not match, the GLA returns a response 1650 indicating cMCStatusInfoExt with cMCStatus.failed and 1651 otherInfo.extendedFailInfo.SKDFailInfo value of 1652 noGLONameMatch. Additionally, a signingTime attribute is 1653 included with the response. 1655 2.c.2.b - Else if the names do match, but the GL cannot be deleted 1656 for other reasons, which the GLA does not wish to 1657 disclose, the GLA returns a response indicating 1658 cMCStatusInfoExt with cMCStatus.failed and 1659 otherInfo.extendedFailInfo.SKDFailInfo value of 1660 unspecified. Additionally, a signingTime attribute is 1661 included with the response. Actions beyond the scope of 1662 this document must then be taken to delete the GL from 1663 the GLA. 1665 2.c.2.c - Else if the names do match, the GLA returns a 1666 cMCStatusInfoExt indicating cMCStatus.success and a 1667 signingTime attribute (2 in Figure 4). The GLA ought not 1668 accept further requests for member additions, member 1669 deletions, or group rekeys for this GL. 1671 2.c.2.c.1 - The GLA can apply confidentiality to the response by 1672 encapsulating the SignedData.PKIResponse in an 1673 EnvelopedData if the request was encapsulated in an 1674 EnvelopedData (see section 3.2.1.2). 1676 2.c.2.c.2 - The GLA MAY optionally apply another SignedData over 1677 the EnvelopedData (see section 3.2.1.2). 1679 3 - Upon receipt of the cMCStatusInfoExt response, the GLO checks 1680 the signingTime and verifies the GLA signature(s). If an 1681 additional SignedData and/or EnvelopedData encapsulates the 1682 response (see section 3.2.1.2 or 3.2.2), the GLO verifies the 1683 outer signature and/or decrypt the outer layer prior to 1684 verifying the signature on the inner most SignedData. 1686 3.a - If the signingTime attribute value is not within the locally 1687 accepted time window, the GLO MAY return a response 1688 indicating cMCStatus.failed and otherInfo.failInfo.badTime 1689 and a signingTime attribute. 1691 3.b - Else if signature processing continues and if the signatures 1692 verify, the GLO checks that one of the names in the 1693 certificate used to sign the response matches the name of 1694 the GL. 1696 3.b.1 - If the name of the GL does not match the name present in 1697 the certificate used to sign the message, the GLO should 1698 not believe the response. 1700 3.b.2 - Else if the name of the GL does match the name present in 1701 the certificate and: 1703 3.b.2.a - If the signatures verify and the response was 1704 cMCStatusInfoExt indicating cMCStatus.success, the GLO 1705 has successfully deleted the GL. 1707 3.b.2.b - Else if the signatures do verify and the response was 1708 cMCStatusInfoExt.cMCStatus.failed with any reason, the 1709 GLO can reattempt to delete the GL using the information 1710 provided in the response. 1712 4.3. Add Members To GL 1714 To add members to GLs, either the GLO or prospective members use the 1715 glAddMember request. The GLA processes GLO and prospective GL member 1716 requests differently though. GLOs can submit the request at any time 1717 to add members to the GL, and the GLA, once it has verified the 1718 request came from a registered GLO, should process it. If a 1719 prospective member sends the request, the GLA needs to determine how 1720 the GL is administered. When the GLO initially configured the GL, 1721 they set the GL to be unmanaged, managed, or closed (see section 1722 3.1.1). In the unmanaged case, the GLA merely processes the member's 1723 request. For the managed case, the GLA forwards the requests from the 1724 prospective members to the GLO for review. Where there are multiple 1725 GLOs for a GL, which GLO the request is forwarded to is beyond the 1726 scope of this document. The GLO reviews the request and either 1727 rejects it or submits a reformed request to the GLA. In the closed 1728 case, the GLA will not accept requests from prospective members. The 1729 following sections describe the processing for the GLO(s), GLA, and 1730 prospective GL members depending on where the glAddMeber request 1731 originated, either from a GLO or from prospective members. Figure 5 1732 depicts the protocol interactions for the three options. Note that 1733 the error messages are not depicted. Additionally, note that behavior 1734 for the optional transactionId, senderNonce, and recipientNonce CMC 1735 control attributes is not addressed in these procedures. 1737 +-----+ 2,B{A} 3 +----------+ 1738 | GLO | <--------+ +-------> | Member 1 | 1739 +-----+ | | +----------+ 1740 1 | | 1741 +-----+ <--------+ | 3 +----------+ 1742 | GLA | A +-------> | ... | 1743 +-----+ <-------------+ +----------+ 1744 | 1745 | 3 +----------+ 1746 +-------> | Member n | 1747 +----------+ 1749 Figure 5 - Member Addition 1751 An important decision that needs to be made on a group by group basis 1752 is whether to rekey the group every time a new member is added. 1753 Typically, unmanaged GLs should not be rekeyed when a new member is 1754 added, as the overhead associated with rekeying the group becomes 1755 prohibitive, as the group becomes large. However, managed and closed 1756 GLs can be rekeyed to maintain the confidentiality of the traffic 1757 sent by group members. An option to rekeying managed or closed GLs 1758 when a member is added is to generate a new GL with a different group 1759 key. Group rekeying is discussed in sections 4.5 and 5. 1761 4.3.1. GLO Initiated Additions 1763 The process for GLO initiated glAddMember requests is as follows: 1765 1 - The GLO collects the pertinent information for the member(s) to 1766 be added (this may be done through an out of bands means). The 1767 GLO then sends a SignedData.PKIData.controlSequence with a 1768 separate glAddMember request for each member to the GLA (1 in 1769 Figure 5). The GLO includes: the GL name in glName, the 1770 member's name in glMember.glMemberName, the member's address in 1771 glMember.glMemberAddress, and the member's encryption 1772 certificate in glMember.certificates.pKC. The GLO can also 1773 include any attribute certificates associated with the member's 1774 encryption certificate in glMember.certificates.aC, and the 1775 certification path associated with the member's encryption and 1776 attribute certificates in glMember.certificates.certPath. The 1777 GLO MUST also include the signingTime attribute with this 1778 request. 1780 1.a - The GLO can optionally apply confidentiality to the request 1781 by encapsulating the SignedData.PKIData in an EnvelopedData 1782 (see section 3.2.1.2). 1784 1.b - The GLO can also optionally apply another SignedData over the 1785 EnvelopedData (see section 3.2.1.2). 1787 2 - Upon receipt of the request, the GLA checks the signingTime and 1788 verifies the signature on the inner most SignedData.PKIData. If 1789 an additional SignedData and/or EnvelopedData encapsulates the 1790 request (see section 3.2.1.2 or 3.2.2), the GLA verifies the 1791 outer signature and/or decrypt the outer layer prior to 1792 verifying the signature on the inner most SignedData. 1794 2.a - If the signingTime attribute value is not within the locally 1795 accepted time window, the GLA MAY return a response 1796 indicating cMCStatus.failed and otherInfo.failInfo.badTime 1797 and a signingTime attribute. 1799 2.b - Else if signature processing continues and if the signatures 1800 cannot be verified, the GLA returns a cMCStatusInfoExt 1801 response indicating cMCStatus.failed and 1802 otherInfo.failInfo.badMessageCheck. Additionally, a 1803 signingTime attribute is included with the response. 1805 2.c - Else if the signatures verify, the glAddMember request is 1806 included in a controlSequence with the glUseKEK request, and 1807 the processing in section 4.1 item 2.e is successfully 1808 completed the GLA returns a cMCStatusInfoExt indicating 1809 cMCStatus.success and a signingTime attribute (2 in Figure 1810 5). 1812 2.c.1 - The GLA can apply confidentiality to the response by 1813 encapsulating the SignedData.PKIData in an EnvelopedData if 1814 the request was encapsulated in an EnvelopedData (see 1815 section 3.2.1.2). 1817 2.c.2 - The GLA can also optionally apply another SignedData over 1818 the EnvelopedData (see section 3.2.1.2). 1820 2.d - Else if the signatures verify and the GLAddMember request is 1821 not included in a controlSequence with the GLCreate request, 1822 the GLA makes sure the GL is supported by checking that the 1823 glName matches a glName stored on the GLA. 1825 2.d.1 - If the glName is not supported by the GLA, the GLA returns 1826 a response indicating cMCStatusInfoExt with 1827 cMCStatus.failed and otherInfo.extendedFailInfo.SKDFailInfo 1828 value of invalidGLName. Additionally, a signingTime 1829 attribute is included with the response. 1831 2.d.2 - Else if the glName is supported by the GLA, the GLA checks 1832 to see if the glMemberName is present on the GL. 1834 2.d.2.a - If the glMemberName is present on the GL, the GLA returns 1835 a response indicating cMCStatusInfoExt with 1836 cMCStatus.failed and 1837 otherInfo.extendedFailInfo.SKDFailInfo value of 1838 alreadyAMember. Additionally, a signingTime attribute is 1839 included with the response. 1841 2.d.2.b - Else if the glMemberName is not present on the GL, the 1842 GLA checks how the GL is administered. 1844 2.d.2.b.1 - If the GL is closed, the GLA checks that a registered 1845 GLO signed the request by checking that one of the 1846 names in the digital signature certificate used to 1847 sign the request matches a registered GLO. 1849 2.d.2.b.1.a - If the names do not match, the GLA returns a response 1850 indicating cMCStatusInfoExt with cMCStatus.failed and 1851 otherInfo.extendedFailInfo.SKDFailInfo value of 1852 noGLONameMatch. Additionally, a signingTime attribute 1853 is included with the response. 1855 2.d.2.b.1.b - Else if the names match, the GLA verifies the 1856 member's encryption certificate. 1858 2.d.2.b.1.b.1 - If the member's encryption certificate cannot be 1859 verified, the GLA can return a response indicating 1860 cMCStatusInfoExt with cMCStatus.failed and 1861 otherInfo.extendedFailInfo.SKDFailInfo value of 1862 invalidCert to the GLO. Additionally, a 1863 signingTime attribute is included with the 1864 response. If the GLA does not return a 1865 cMCStatusInfoExt.cMCStatus.failed response, the 1866 GLA issues a glProvideCert request (see section 1867 4.10). 1869 2.d.2.b.1.b.2 - Else if the member's certificate verifies, the GLA 1870 returns a cMCStatusInfoExt indicating 1871 cMCStatus.success and a signingTime attribute (2 1872 in Figure 5). The GLA also takes administrative 1873 actions, which are beyond the scope of this 1874 document, to add the member to the GL stored on 1875 the GLA. The GLA also distributes the shared KEK 1876 to the member via the mechanism described in 1877 section 5. 1879 2.d.2.b.1.b.2.a - The GLA applies confidentiality to the response 1880 by encapsulating the SignedData.PKIData in an 1881 EnvelopedData if the request was encapsulated in 1882 an EnvelopedData (see section 3.2.1.2). 1884 2.d.2.b.1.b.2.b - The GLA can also optionally apply another 1885 SignedData over the EnvelopedData (see section 1886 3.2.1.2). 1888 2.d.2.b.2 - Else if the GL is managed, the GLA checks that either a 1889 registered GLO or the prospective member signed the 1890 request. For GLOs, one of the names in the certificate 1891 used to sign the request needs to match a registered 1892 GLO. For the prospective member, the name in 1893 glMember.glMemberName needs to match one of the names 1894 in the certificate used to sign the request. 1896 2.d.2.b.2.a - If the signer is neither a registered GLO nor the 1897 prospective GL member, the GLA returns a response 1898 indicating cMCStatusInfoExt with cMCStatus.failed and 1899 otherInfo.extendedFailInfo.SKDFailInfo value of 1900 noSpam. Additionally, a signingTime attribute is 1901 included with the response. 1903 2.d.2.b.2.b - Else if the signer is a registered GLO, the GLA 1904 verifies the member's encryption certificate. 1906 2.d.2.b.2.b.1 - If the member's certificate cannot be verified, the 1907 GLA can return a response indicating 1908 cMCStatusInfoExt with cMCStatus.failed and 1909 otherInfo.extendedFailInfo.SKDFailInfo value of 1910 invalidCert. Additionally, a signingTime attribute 1911 is included with the response. If the GLA does not 1912 return a cMCStatus.failed response, the GLA MUST 1913 issue a glProvideCert request (see section 4.10). 1915 2.d.2.b.2.b.2 - Else if the member's certificate verifies, the GLA 1916 MUST return a cMCStatusInfoExt indicating 1917 cMCStatus.success and a signingTime attribute to 1918 the GLO (2 in Figure 5). The GLA also takes 1919 administrative actions, which are beyond the scope 1920 of this document, to add the member to the GL 1921 stored on the GLA. The GLA also distributes the 1922 shared KEK to the member via the mechanism 1923 described in section 5. The GL policy may mandate 1924 that the GL member's address be included in the GL 1925 member's certificate. 1927 2.d.2.b.2.b.2.a - The GLA applies confidentiality to the response 1928 by encapsulating the SignedData.PKIData in an 1929 EnvelopedData if the request was encapsulated in 1930 an EnvelopedData (see section 3.2.1.2). 1932 2.d.2.b.2.b.2.b - The GLA can also optionally apply another 1933 SignedData over the EnvelopedData (see section 1934 3.2.1.2). 1936 2.d.2.b.2.c - Else if the signer is the prospective member, the GLA 1937 forwards the glAddMember request (see section 1938 3.2.3) to a registered GLO (B{A} in Figure 5). If 1939 there is more than one registered GLO, the GLO to 1940 which the request is forwarded to is beyond the 1941 scope of this document. Further processing of the 1942 forwarded request by GLOs is addressed in 3 of 1943 section 4.3.2. 1945 2.d.2.b.2.c.1 - The GLA applies confidentiality to the forwarded 1946 request by encapsulating the SignedData.PKIData in 1947 an EnvelopedData if the original request was 1948 encapsulated in an EnvelopedData (see section 1949 3.2.1.2). 1951 2.d.2.b.2.c.2 - The GLA can also optionally apply another 1952 SignedData over the EnvelopedData (see section 1953 3.2.1.2). 1955 2.d.2.b.3 - Else if the GL is unmanaged, the GLA checks that either 1956 a registered GLO or the prospective member signed the 1957 request. For GLOs, one of the names in the certificate 1958 used to sign the request needs tp match the name of a 1959 registered GLO. For the prospective member, the name 1960 in glMember.glMemberName needs to match one of the 1961 names in the certificate used to sign the request. 1963 2.d.2.b.3.a - If the signer is neither a registered GLO nor the 1964 prospective member, the GLA returns a response 1965 indicating cMCStatusInfoExt with cMCStatus.failed and 1966 otherInfo.extendedFailInfo.SKDFailInfo value of 1967 noSpam. Additionally, a signingTime attribute is 1968 included with the response. 1970 2.d.2.b.3.b - Else if the signer is either a registered GLO or the 1971 prospective member, the GLA verifies the member's 1972 encryption certificate. 1974 2.d.2.b.3.b.1 - If the member's certificate cannot be verified, the 1975 GLA can return a response indicating 1976 cMCStatusInfoExt with cMCStatus.failed and 1977 otherInfo.extendedFailInfo.SKDFailInfo value of 1978 invalidCert and a signingTime attribute to either 1979 the GLO or the prospective member depending on 1980 where the request originated. If the GLA does not 1981 return a cMCStatus.failed response, the GLA issues 1982 a glProvideCert request (see section 4.10) to 1983 either the GLO or prospective member depending on 1984 where the request originated. 1986 2.d.2.b.3.b.2 - Else if the member's certificate verifies, the GLA 1987 returns a cMCStatusInfoExt indicating 1988 cMCStatus.success and a signingTime attribute to 1989 the GLO (2 in Figure 5) if the GLO signed the 1990 request and to the GL member (3 in Figure 5) if 1991 the GL member signed the request. The GLA also 1992 takes administrative actions, which are beyond the 1993 scope of this document, to add the member to the 1994 GL stored on the GLA. The GLA also distributes the 1995 shared KEK to the member via the mechanism 1996 described in section 5. 1998 2.d.2.b.3.b.2.a - The GLA applies confidentiality to the response 1999 by encapsulating the SignedData.PKIData in an 2000 EnvelopedData if the request was encapsulated in 2001 an EnvelopedData (see section 3.2.1.2). 2003 2.d.2.b.3.b.2.b - The GLA can also optionally apply another 2004 SignedData over the EnvelopedData (see section 2005 3.2.1.2). 2007 3 - Upon receipt of the cMCStatusInfoExt response, the GLO checks 2008 the signingTime and verifies the GLA signature(s). If an 2009 additional SignedData and/or EnvelopedData encapsulates the 2010 response (see section 3.2.1.2 or 3.2.2), the GLO verifies the 2011 outer signature and/or decrypt the outer layer prior to 2012 verifying the signature on the inner most SignedData. 2014 3.a - If the signingTime attribute value is not within the locally 2015 accepted time window, the GLO MAY return a response 2016 indicating cMCStatus.failed and otherInfo.failInfo.badTime 2017 and a signingTime attribute. 2019 3.b - Else if signature processing continues and if the signatures 2020 verify, the GLO checks that one of the names in the 2021 certificate used to sign the response matches the name of 2022 the GL. 2024 3.b.1 - If the name of the GL does not match the name present in 2025 the certificate used to sign the message, the GLO should 2026 not believe the response. 2028 3.b.2 - Else if the name of the GL matches the name present in the 2029 certificate and: 2031 3.b.2.a - If the signatures verify and the response is 2032 cMCStatusInfoExt indicating cMCStatus.success, the GLA 2033 has added the member to the GL. If member was added to a 2034 managed list and the original request was signed by the 2035 member, the GLO sends a 2036 cMCStatusInfoExt.cMCStatus.success and a signingTime 2037 attribute to the GL member. 2039 3.b.2.b - Else if the GLO received a 2040 cMCStatusInfoExt.cMCStatus.failed with any reason, the 2041 GLO can reattempt to add the member to the GL using the 2042 information provided in the response. 2044 4 - Upon receipt of the cMCStatusInfoExt response, the prospective 2045 member checks the signingTime and verifies the GLA signatures 2046 or GLO signatures. If an additional SignedData and/or 2047 EnvelopedData encapsulates the response (see section 3.2.1.2 or 2048 3.2.2), the GLO verifies the outer signature and/or decrypt the 2049 outer layer prior to verifying the signature on the inner most 2050 SignedData. 2052 4.a - If the signingTime attribute value is not within the locally 2053 accepted time window, the prospective member MAY return a 2054 response indicating cMCStatus.failed and 2055 otherInfo.failInfo.badTime and a signingTime attribute. 2057 4.b - Else if signature processing continues and if the signatures 2058 verify, the GL member checks that one of the names in the 2059 certificate used to sign the response matches the name of 2060 the GL. 2062 4.b.1 - If the name of the GL does not match the name present in 2063 the certificate used to sign the message, the GL member 2064 should not believe the response. 2066 4.b.2 - Else if the name of the GL matches the name present in the 2067 certificate and: 2069 4.b.2.a - If the signatures verify, the prospective member has been 2070 added to the GL. 2072 4.b.2.b - Else if the prospective member received a 2073 cMCStatusInfoExt.cMCStatus.failed, for any reason, the 2074 prospective member MAY reattempt to add themselves to the 2075 GL using the information provided in the response. 2077 4.3.2. Prospective Member Initiated Additions 2079 The process for prospective member initiated glAddMember requests is 2080 as follows: 2082 1 - The prospective GL member sends a 2083 SignedData.PKIData.controlSequence.glAddMember request to the 2084 GLA (A in Figure 5). The prospective GL member includes: the GL 2085 name in glName, their name in glMember.glMemberName, their 2086 address in glMember.glMemberAddress, and their encryption 2087 certificate in glMember.certificates.pKC. The prospective GL 2088 member can also include any attribute certificates associated 2089 with their encryption certificate in glMember.certificates.aC, 2090 and the certification path associated with their encryption and 2091 attribute certificates in glMember.certificates.certPath. The 2092 prosepective member MUST also include the signingTime attribute 2093 with this request. 2095 1.a - The prospective GL member can optionally apply 2096 confidentiality to the request by encapsulating the 2097 SignedData.PKIData in an EnvelopedData (see section 2098 3.2.1.2). 2100 1.b - The prospective GL member MAY optionally apply another 2101 SignedData over the EnvelopedData (see section 3.2.1.2). 2103 2 - Upon receipt of the request, the GLA verifies the request as 2104 per 2 in section 4.3.1. 2106 3 - Upon receipt of the forwarded request, the GLO checks the 2107 signingTime and verifies the prospective GL member signature on 2108 the inner most SignedData.PKIData and the GLA signature on the 2109 outer layer. If an EnvelopedData encapsulates the inner most 2110 layer (see section 3.2.1.2 or 3.2.2), the GLO decrypts the 2111 outer layer prior to verifying the signature on the inner most 2112 SignedData. 2114 Note: For cases where the GL is closed and either a) a 2115 prospective member sends directly to the GLO or b) the GLA has 2116 mistakenly forwarded the request to the GLO, the GLO should 2117 first determine whether to honor the request. 2119 3.a - If the signingTime attribute value is not within the locally 2120 accepted time window, the GLO MAY return a response 2121 indicating cMCStatus.failed and otherInfo.failInfo.badTime. 2123 3.b - Else if signature processing continues and if the signatures 2124 verify, the GLO checks to make sure one of the names in the 2125 certificate used to sign the request matches the name in 2126 glMember.glMemberName. 2128 3.b.1 - If the names do not match, the GLO sends a 2129 SignedData.PKIResponse.controlSequence message back to the 2130 prospective member with cMCStatusInfoExt.cMCStatus.failed 2131 indicating why the prospective member was denied in 2132 cMCStausInfo.statusString. This stops people from adding 2133 people to GLs without their permission. Additionally, a 2134 signingTime attribute is included with the response. 2136 3.b.2 - Else if the names match, the GLO determines whether the 2137 prospective member is allowed to be added. The mechanism is 2138 beyond the scope of this document; however, the GLO should 2139 check to see that the glMember.glMemberName is not already 2140 on the GL. 2142 3.b.2.a - If the GLO determines the prospective member is not 2143 allowed to join the GL, the GLO can return a 2144 SignedData.PKIResponse.controlSequence message back to 2145 the prospective member with 2146 cMCStatusInfoExt.cMCtatus.failed indicating why the 2147 prospective member was denied in cMCStatus.statusString. 2148 Additionally, a signingTime attribute is included with 2149 the response. 2151 3.b.2.b - Else if GLO determines the prospective member is allowed 2152 to join the GL, the GLO verifies the member's encryption 2153 certificate. 2155 3.b.2.b.1 - If the member's certificate cannot be verified, the GLO 2156 returns a SignedData.PKIResponse.controlSequence back 2157 to the prospective member with 2158 cMCStatusInfoExt.cMCtatus.failed indicating that the 2159 member's encryption certificate did not verify in 2160 cMCStatus.statusString. Additionally, a signingTime 2161 attribute is included with the response. If the GLO 2162 does not return a cMCStatusInfoExt response, the GLO 2163 sends a 2164 SignedData.PKIData.controlSequence.glProvideCert 2165 message to the prospective member requesting a new 2166 encryption certificate (see section 4.10). 2168 3.b.2.b.2 - Else if the member's certificate verifies, the GLO 2169 resubmits the glAddMember request (see section 3.2.5) 2170 to the GLA (1 in Figure 5). 2172 3.b.2.b.2.a - The GLO applies confidentiality to the new 2173 GLAddMember request by encapsulating the 2174 SignedData.PKIData in an EnvelopedData if the initial 2175 request was encapsulated in an EnvelopedData (see 2176 section 3.2.1.2). 2178 3.b.2.b.2.b - The GLO can also optionally apply another SignedData 2179 over the EnvelopedData (see section 3.2.1.2). 2181 4 - Processing continues as in 2 of section 4.3.1. 2183 4.4. Delete Members From GL 2185 To delete members from GLs, either the GLO or members to be removed 2186 use the glDeleteMember request. The GLA processes GLO and members 2187 requesting their own removal make requests differently. The GLO can 2188 submit the request at any time to delete members from the GL, and the 2189 GLA, once it has verified the request came from a registered GLO, 2190 should delete the member. If a member sends the request, the GLA 2191 needs to determine how the GL is administered. When the GLO initially 2192 configured the GL, they set the GL to be unmanaged, managed, or 2193 closed (see section 3.1.1). In the unmanaged case, the GLA merely 2194 processes the member's request. For the managed case, the GLA 2195 forwards the requests from the member to the GLO for review. Where 2196 there are multiple GLOs for a GL, which GLO the request is forwarded 2197 to is beyond the scope of this document. The GLO reviews the request 2198 and either rejects it or submits a reformed request to the GLA. In 2199 the closed case, the GLA will not accept requests from members. The 2200 following sections describe the processing for the GLO(s), GLA, and 2201 GL members depending on where the request originated, either from a 2202 GLO or from members wanting to be removed. Figure 6 depicts the 2203 protocol interactions for the three options. Note that the error 2204 messages are not depicted. Additionally, behavior for the optional 2205 transactionId, senderNonce, and recipientNonce CMC control attributes 2206 is not addressed in these procedures. 2208 +-----+ 2,B{A} 3 +----------+ 2209 | GLO | <--------+ +-------> | Member 1 | 2210 +-----+ | | +----------+ 2211 1 | | 2212 +-----+ <--------+ | 3 +----------+ 2213 | GLA | A +-------> | ... | 2214 +-----+ <-------------+ +----------+ 2215 | 2216 | 3 +----------+ 2217 +-------> | Member n | 2218 +----------+ 2220 Figure 6 - Member Deletion 2222 If the member is not removed from the GL, they will continue to 2223 receive and be able to decrypt data protected with the shared KEK and 2224 will continue to receive rekeys. For unmanaged lists, there is no 2225 point to a group rekey because there is no guarantee that the member 2226 requesting to be removed has not already added themselves back on the 2227 GL under a different name. For managed and closed GLs, the GLO needs 2228 to take steps to ensure the member being deleted is not on the GL 2229 twice. After ensuring this, managed and closed GLs can be rekeyed to 2230 maintain the confidentiality of the traffic sent by group members. If 2231 the GLO is sure the member has been deleted the group rekey mechanism 2232 can be used to distribute the new key (see sections 4.5 and 5). 2234 4.4.1. GLO Initiated Deletions 2236 The process for GLO initiated glDeleteMember requests is as follows: 2238 1 - The GLO collects the pertinent information for the member(s) to 2239 be deleted (this can be done through an out of bands means). 2240 The GLO then sends a SignedData.PKIData.controlSequence with a 2241 separate glDeleteMember request for each member to the GLA (1 2242 in Figure 6). The GLO MUST include: the GL name in glName and 2243 the member's name in glMemberToDelete. If the GL from which the 2244 member is being deleted in a closed or managed GL, the GLO MUST 2245 also generate a glRekey request and include it with the 2246 glDeletemember request (see section 4.5). The GLO MUST also 2247 include the signingTime attribute with this request. 2249 1.a - The GLO can optionally apply confidentiality to the request 2250 by encapsulating the SignedData.PKIData in an EnvelopedData 2251 (see section 3.2.1.2). 2253 1.b - The GLO can also optionally apply another SignedData over the 2254 EnvelopedData (see section 3.2.1.2). 2256 2 - Upon receipt of the request, the GLA checks the signingTime 2257 attribute and verifies the signature on the inner most 2258 SignedData.PKIData. If an additional SignedData and/or 2259 EnvelopedData encapsulates the request (see section 3.2.1.2 or 2260 3.2.2), the GLA verifies the outer signature and/or decrypt the 2261 outer layer prior to verifying the signature on the inner most 2262 SignedData. 2264 2.a - If the signingTime attribute value is not within the locally 2265 accepted time window, the GLA MAY return a response 2266 indicating cMCStatus.failed and otherInfo.failInfo.badTime 2267 and a signingTime attribute. 2269 2.b - Else if signature processing continues and if the signatures 2270 cannot be verified, the GLA returns a cMCStatusInfoExt 2271 response indicating cMCStatus.failed and 2272 otherInfo.failInfo.badMessageCheck. Additionally, a 2273 signingTime attribute is included with the response. 2275 2.c - Else if the signatures verify, the GLA makes sure the GL is 2276 supported by the GLA by checking that the glName matches a 2277 glName stored on the GLA. 2279 2.c.1 - If the glName is not supported by the GLA, the GLA returns 2280 a response indicating cMCStatusInfoExt with 2281 cMCStatus.failed and otherInfo.extendedFailInfo.SKDFailInfo 2282 value of invalidGLName. Additionally, a signingTime 2283 attribute is included with the response. 2285 2.c.2 - Else if the glName is supported by the GLA, the GLA checks 2286 to see if the glMemberName is present on the GL. 2288 2.c.2.a - If the glMemberName is not present on the GL, the GLA 2289 returns a response indicating cMCStatusInfoExt with 2290 cMCStatus.failed and 2291 otherInfo.extendedFailInfo.SKDFailInfo value of 2292 notAMember. Additionally, a signingTime attribute is 2293 included with the response. 2295 2.c.2.b - Else if the glMemberName is already on the GL, the GLA 2296 checks how the GL is administered. 2298 2.c.2.b.1 - If the GL is closed, the GLA checks that the registered 2299 GLO signed the request by checking that one of the 2300 names in the digital signature certificate used to sign 2301 the request matches the registered GLO. 2303 2.c.2.b.1.a - If the names do not match, the GLA returns a response 2304 indicating cMCStatusInfoExt with cMCStatus.failed and 2305 otherInfo.extendedFailInfo.SKDFailInfo value of 2306 closedGL. Additionally, a signingTime attribute is 2307 included with the response. 2309 2.c.2.b.1.b - Else if the names do match, the GLA returns a 2310 cMCStatusInfoExt.cMCStatus.success and a signingTime 2311 attribute (2 in Figure 5). The GLA also takes 2312 administrative actions, which are beyond the scope of 2313 this document, to delete the member with the GL 2314 stored on the GLA. Note that he GL also needs to be 2315 rekeyed as described in section 5. 2317 2.c.2.b.1.b.1 - The GLA applies confidentiality to the response by 2318 encapsulating the SignedData.PKIData in an 2319 EnvelopedData if the request was encapsulated in 2320 an EnvelopedData (see section 3.2.1.2). 2322 2.c.2.b.1.b.2 - The GLA can also optionally apply another 2323 SignedData over the EnvelopedData (see section 2324 3.2.1.2). 2326 2.c.2.b.2 - Else if the GL is managed, the GLA checks that either a 2327 registered GLO or the prospective member signed the 2328 request. For GLOs, one of the names in the certificate 2329 used to sign the request needs to match a registered 2330 GLO. For the prospective member, the name in 2331 glMember.glMemberName needs to match one of the names 2332 in the certificate used to sign the request. 2334 2.c.2.b.2.a - If the signer is neither a registered GLO nor the 2335 prospective GL member, the GLA returns a response 2336 indicating cMCStatusInfoExt with cMCStatus.failed and 2337 otherInfo.extendedFailInfo.SKDFailInfo value of 2338 noSpam. Additionally, a signingTime attribute is 2339 included with the response. 2341 2.c.2.b.2.b - Else if the signer is a registered GLO, the GLA 2342 returns a cMCStatusInfoExt.cMCStatus.success and a 2343 signingTime attribute(2 in Figure 6). The GLA also 2344 takes administrative actions, which are beyond the 2345 scope of this document, to delete the member with the 2346 GL stored on the GLA. Note that the GL will also be 2347 rekeyed as described in section 5. 2349 2.c.2.b.2.b.1 - The GLA applies confidentiality to the response by 2350 encapsulating the SignedData.PKIData in an 2351 EnvelopedData if the request was encapsulated in 2352 an EnvelopedData (see section 3.2.1.2). 2354 2.c.2.b.2.b.2 - The GLA can also optionally apply another 2355 SignedData over the EnvelopedData (see section 2356 3.2.1.2). 2358 2.c.2.b.2.c - Else if the signer is the prospective member, the GLA 2359 forwards the glDeleteMember request (see section 2360 3.2.3) to the GLO (B{A} in Figure 6). If there is 2361 more than one registered GLO, the GLO to which the 2362 request is forwarded to is beyond the scope of this 2363 document. Further processing of the forwarded request 2364 by GLOs is addressed in 3 of section 4.4.2. 2366 2.c.2.b.2.c.1 - The GLA applies confidentiality to the forwarded 2367 request by encapsulating the SignedData.PKIData in an 2368 EnvelopedData if the request was encapsulated in an 2369 EnvelopedData (see section 3.2.1.2). 2371 2.c.2.b.2.c.2 - The GLA can also optionally apply another 2372 SignedData over the EnvelopedData (see section 2373 3.2.1.2). 2375 2.c.2.b.3 - Else if the GL is unmanaged, the GLA checks that either 2376 a registered GLO or the prospective member signed the 2377 request. For GLOs, one of the names in the certificate 2378 used to sign the request needs to match the name of a 2379 registered GLO. For the prospective member, the name 2380 in glMember.glMemberName needs to match one of the 2381 names in the certificate used to sign the request. 2383 2.c.2.b.3.a - If the signer is neither the GLO nor the prospective 2384 member, the GLA returns a response indicating 2385 cMCStatusInfoExt with cMCStatus.failed and 2386 otherInfo.extendedFailInfo.SKDFailInfo value of 2387 noSpam. Additionally, a signingTime attribute is 2388 included with the response. 2390 2.c.2.b.3.b - Else if the signer is either a registered GLO or the 2391 member, the GLA returns a 2392 cMCStatusInfoExt.cMCStatus.success and a signingTime 2393 attribute to the GLO (2 in Figure 6) if the GLO 2394 signed the request and to the GL member (3 in Figure 2395 6) if the GL member signed the request. The GLA also 2396 takes administrative actions, which are beyond the 2397 scope of this document, to delete the member with the 2398 GL stored on the GLA. 2400 2.c.2.b.3.b.1 - The GLA applies confidentiality to the response by 2401 encapsulating the SignedData.PKIData in an 2402 EnvelopedData if the request was encapsulated in 2403 an EnvelopedData (see section 3.2.1.2). 2405 2.c.2.b.3.b.2 - The GLA can also optionally apply another 2406 SignedData over the EnvelopedData (see section 2407 3.2.1.2). 2409 3 - Upon receipt of the cMCStatusInfoExt response, the GLO checks 2410 the signingTime and verifies the GLA signatures. If an 2411 additional SignedData and/or EnvelopedData encapsulates the 2412 response (see section 3.2.1.2 or 3.2.2), the GLO verifies the 2413 outer signature and/or decrypt the outer layer prior to 2414 verifying the signature on the inner most SignedData. 2416 3.a - If the signingTime attribute value is not within the locally 2417 accepted time window, the GLO MAY return a response 2418 indicating cMCStatus.failed and otherInfo.failInfo.badTime 2419 and a signingTime attribute. 2421 3.b - Else if signature processing continues and if the signatures 2422 do verify, the GLO checks that one of the names in the 2423 certificate used to sign the response matches the name of 2424 the GL. 2426 3.b.1 - If the name of the GL does not match the name present in 2427 the certificate used to sign the message, the GLO should 2428 not believe the response. 2430 3.b.2 - Else if the name of the GL matches the name present in the 2431 certificate and: 2433 3.b.2.a - If the signatures verify and the response is 2434 cMCStatusInfoExt.cMCStatus.success, the GLO has deleted 2435 the member from the GL. If member was deleted from a 2436 managed list and the original request was signed by the 2437 member, the GLO sends a 2438 cMCStatusInfoExt.cMCStatus.success and a signingTime 2439 attribute to the GL member. 2441 3.b.2.b - Else if the GLO received a 2442 cMCStatusInfoExt.cMCStatus.failed with any reason, the 2443 GLO may reattempt to delete the member from the GL using 2444 the information provided in the response. 2446 4 - Upon receipt of the cMCStatusInfoExt response, the member 2447 checks the signingTime and verifies the GLA signature(s) or GLO 2448 signature(s). If an additional SignedData and/or EnvelopedData 2449 encapsulates the response (see section 3.2.1.2 or 3.2.2), the 2450 GLO verifies the outer signature and/or decrypt the outer layer 2451 prior to verifying the signature on the inner most SignedData. 2453 4.a - If the signingTime attribute value is not within the locally 2454 accepted time window, the prospective member MAY return a 2455 response indicating cMCStatus.failed and 2456 otherInfo.failInfo.badTime and a signingTime attribute. 2458 4.b - Else if signature processing continues and if the signatures 2459 verify, the GL member checks that one of the names in the 2460 certificate used to sign the response matches the name of 2461 the GL. 2463 4.b.1 - If the name of the GL does not match the name present in 2464 the certificate used to sign the message, the GL member 2465 should not believe the response. 2467 4.b.2 - Else if the name of the GL matches the name present in the 2468 certificate and: 2470 4.b.2.a - If the signature(s) verify, the member has been deleted 2471 from the GL. 2473 4.b.2.b - Else if the member received a 2474 cMCStatusInfoExt.cMCStatus.failed with any reason, the 2475 member can reattempt to delete themselves from the GL 2476 using the information provided in the response. 2478 4.4.2. Member Initiated Deletions 2480 The process for member initiated deletion of their own membership 2481 using the glDeleteMember requests is as follows: 2483 1 - The member sends a 2484 SignedData.PKIData.controlSequence.glDeleteMember request to 2485 the GLA (A in Figure 6). The member includes: the name of the 2486 GL in glName and their own name in glMemberToDelete. The GL 2487 member MUST also include the signingTime attribute with this 2488 request. 2490 1.a - The member can optionally apply confidentiality to the 2491 request by encapsulating the SignedData.PKIData in an 2492 EnvelopedData (see section 3.2.1.2). 2494 1.b - The member can also optionally apply another SignedData over 2495 the EnvelopedData (see section 3.2.1.2). 2497 2 - Upon receipt of the request, the GLA verifies the request as 2498 per 2 in section 4.4.1. 2500 3 - Upon receipt of the forwarded request, the GLO checks the 2501 signingTime and verifies the member signature on the inner most 2502 SignedData.PKIData and the GLA signature on the outer layer. If 2503 an EnvelopedData encapsulates the inner most layer (see section 2504 3.2.1.2 or 3.2.2), the GLO decrypts the outer layer prior to 2505 verifying the signature on the inner most SignedData. Note: For 2506 cases where the GL is closed and either (a) a prospective 2507 member sends directly to the GLO or (b) the GLA has mistakenly 2508 forwarded the request to the GLO, the GLO should first 2509 determine whether to honor the request. 2511 3.a - If the signingTime attribute value is not within the locally 2512 accepted time window, the GLO MAY return a response 2513 indicating cMCStatus.failed and otherInfo.failInfo.badTime 2514 and a signingTime attribute. 2516 3.b - Else if signature processing continues if the signatures 2517 cannot be verified, the GLO returns a cMCStatusInfoExt 2518 response indicating cMCStatus.failed and 2519 otherInfo.failInfo.badMessageCheck and a signingTime 2520 attribute. 2522 3.c - Else if the signatures verify, the GLO checks to make sure 2523 one of the names in the certificates used to sign the 2524 request matches the name in glMemberToDelete. 2526 3.c.1 - If the names match, the GLO sends a 2527 SignedData.PKIResponse.controlSequence message back to the 2528 prospective member with cMCStatusInfoExt.cMCtatus.failed 2529 indicating why the prospective member was denied in 2530 cMCStatusInfoExt.statusString. This stops people from 2531 adding people to GLs without their permission. 2532 Additionally, a signingTime attribute is included with the 2533 response. 2535 3.c.2 - Else if the names match, the GLO resubmits the 2536 glDeleteMember request (see section 3.2.5) to the GLA (1 in 2537 Figure 6). The GLO makes sure the glMemberName is already 2538 on the GL. The GLO also generates a glRekey request and 2539 include it with the GLDeleteMember request (see section 2540 4.5). 2542 3.c.2.a - The GLO applies confidentiality to the new GLDeleteMember 2543 request by encapsulating the SignedData.PKIData in an 2544 EnvelopedData if the initial request was encapsulated in 2545 an EnvelopedData (see section 3.2.1.2). 2547 3.c.2.b - The GLO can also optionally apply another SignedData over 2548 the EnvelopedData (see section 3.2.1.2). 2550 4 - Further processing is as in 2 of section 4.4.1. 2552 4.5. Request Rekey Of GL 2554 From time to time, the GL will need to be rekeyed. Some situations 2555 follow: 2557 - When a member is removed from a closed or managed GL. In this 2558 case, the PKIData.controlSequence containing the glDeleteMember 2559 ought to contain a glRekey request. 2561 - Depending on policy, when a member is removed from an unmanaged 2562 GL. If the policy is to rekey the GL, the 2563 PKIData.controlSequence containing the glDeleteMember could also 2564 contain a glRekey request or an out of bands means could be used 2565 to tell the GLA to rekey the GL. Rekeying of unmanaged GLs when 2566 members are deleted is not advised. 2568 - When the current shared KEK has been compromised. 2570 - When the current shared KEK is about to expire. Consider two 2571 cases: 2573 - If the GLO controls the GL rekey, the GLA should not assume 2574 that a new shared KEK should be distributed, but instead wait 2575 for the glRekey message. 2577 - If the GLA controls the GL rekey, the GLA should initiate a 2578 glKey message as specified in section 5. 2580 If the generationCounter (see section 3.1.1) is set to a value 2581 greater than one (1) and the GLO controls the GL rekey, the GLO may 2582 generate a glRekey any time before the last shared KEK has expired. 2583 To be on the safe side, the GLO ought to request a rekey one (1) 2584 duration before the last shared KEK expires. 2586 The GLA and GLO are the only entities allowed to initiate a GL rekey. 2587 The GLO indicated whether they are going to control rekeys or whether 2588 the GLA is going to control rekeys when they assigned the shared KEK 2589 to GL (see section 3.1.1). The GLO initiates a GL rekey at any time. 2590 The GLA can be configured to automatically rekey the GL prior to the 2591 expiration of the shared KEK (the length of time before the 2592 expiration is an implementation decision). The GLA can also 2593 automatically rekey GLs that have been compromised, but this is 2594 covered in section 5. Figure 7 depicts the protocol interactions to 2595 request a GL rekey. Note that error messages are not depicted. 2596 Additionally, behavior for the optional transactionId, senderNonce, 2597 and recipientNonce CMC control attributes is not addressed in these 2598 procedures. 2600 +-----+ 1 2,A +-----+ 2601 | GLA | <-------> | GLO | 2602 +-----+ +-----+ 2604 Figure 7 - GL Rekey Request 2606 4.5.1. GLO Initiated Rekey Requests 2608 The process for GLO initiated glRekey requests is as follows: 2610 1 - The GLO sends a SignedData.PKIData.controlSequence.glRekey 2611 request to the GLA (1 in Figure 7). The GLO includes the 2612 glName. If glAdministration and glKeyNewAttributes are omitted 2613 then there is no change from the previously registered GL 2614 values for these fields. If the GLO wants to force a rekey for 2615 all outstanding shared KEKs it includes the glRekeyAllGLKeys 2616 set to TRUE. The GLO MUST also include a signingTime attribute 2617 is included with this request. 2619 1.a - The GLO can optionally apply confidentiality to the request 2620 by encapsulating the SignedData.PKIData in an EnvelopedData 2621 (see section 3.2.1.2). 2623 1.b - The GLO can also optionally apply another SignedData over the 2624 EnvelopedData (see section 3.2.1.2). 2626 2 - Upon receipt of the request, the GLA checks the signingTime and 2627 verifies the signature on the inner most SignedData.PKIData. If 2628 an additional SignedData and/or EnvelopedData encapsulates the 2629 request (see section 3.2.1.2 or 3.2.2), the GLA verifies the 2630 outer signature and/or decrypt the outer layer prior to 2631 verifying the signature on the inner most SignedData. 2633 2.a - If the signingTime attribute value is not within the locally 2634 accepted time window, the GLA MAY return a response 2635 indicating cMCStatus.failed and otherInfo.failInfo.badTime 2636 and a signingTime attribute. 2638 2.b - Else if signature processing continues and if the signatures 2639 do not verify, the GLA returns a cMCStatusInfoExt response 2640 indicating cMCStatus.failed and 2641 otherInfo.failInfo.badMessageCheck. Additionally, a 2642 signingTime attribute is included with the response. 2644 2.c - Else if the signatures do verify, the GLA makes sure the GL 2645 is supported by the GLA by checking that the glName matches 2646 a glName stored on the GLA. 2648 2.c.1 - If the glName present does not match a GL stored on the 2649 GLA, the GLA returns a response indicating cMCStatusInfoExt 2650 with cMCStatus.failed and 2651 otherInfo.extendedFailInfo.SKDFailInfo value of 2652 invalidGLName. Additionally, a signingTime attribute is 2653 included with the response. 2655 2.c.2 - Else if the glName present matches a GL stored on the GLA, 2656 the GLA checks that a registered GLO signed the request by 2657 checking that one of the names in the certificate used to 2658 sign the request is a registered GLO. 2660 2.c.2.a - If the names do not match, the GLA returns a response 2661 indicating cMCStatusInfoExt with cMCStatus.failed and 2662 otherInfo.extendedFailInfo.SKDFailInfo value of 2663 noGLONameMatch. Additionally, a signingTime attribute is 2664 included with the response. 2666 2.c.2.b - Else if the names match, the GLA checks the 2667 glNewKeyAttribute values. 2669 2.c.2.b.1 - If the new value for requestedAlgorithm is not 2670 supported, the GLA returns a response indicating 2671 cMCStatusInfoExt with cMCStatus.failed and 2672 otherInfo.extendedFailInfo.SKDFailInfo value of 2673 unsupportedAlgorithm. Additionally, a signingTime 2674 attribute is included with the response. 2676 2.c.2.b.2 - Else if the new value duration is not supportable, 2677 determining this is beyond the scope this document, 2678 the GLA returns a response indicating cMCStatusInfoExt 2679 with cMCStatus.failed and 2680 otherInfo.extendedFailInfo.SKDFailInfo value of 2681 unsupportedDuration. Additionally, a signingTime 2682 attribute is included with the response. 2684 2.c.2.b.3 - Else if the GL is not supportable for other reasons, 2685 which the GLA does not wish to disclose, the GLA 2686 returns a response indicating cMCStatusInfoExt with 2687 cMCStatus.failed and 2688 otherInfo.extendedFailInfo.SKDFailInfo value of 2689 unspecified. Additionally, a signingTime attribute is 2690 included with the response. 2692 2.c.2.b.4 - Else if the new requestedAlgorithm and duration are 2693 supportable or the glNewKeyAttributes was omitted, the 2694 GLA returns a cMCStatusInfoExt.cMCStatus.success and a 2695 sigingTime attribute (2 in Figure 7). The GLA also 2696 uses the glKey message to distribute the rekey shared 2697 KEK (see section 5). 2699 2.c.2.b.4.a - The GLA applies confidentiality to response by 2700 encapsulating the SignedData.PKIData in an 2701 EnvelopedData if the request was encapsulated in an 2702 EnvelopedData (see section 3.2.1.2). 2704 2.c.2.b.4.b - The GLA can also optionally apply another SignedData 2705 over the EnvelopedData (see section 3.2.1.2). 2707 3 - Upon receipt of the cMCStatusInfoExt response, the GLO checks 2708 the signingTime and verifies the GLA signature(s). If an 2709 additional SignedData and/or EnvelopedData encapsulates the 2710 forwarded response (see section 3.2.1.2 or 3.2.2), the GLO 2711 verifies the outer signature and/or decrypt the forwarded 2712 response prior to verifying the signature on the inner most 2713 SignedData. 2715 3.a - If the signingTime attribute value is not within the locally 2716 accepted time window, the GLA MAY return a response 2717 indicating cMCStatus.failed and otherInfo.failInfo.badTime 2718 and a signingTime attribute. 2720 3.b - Else if signature processing continues and if the signatures 2721 verify, the GLO checks that one of the names in the 2722 certificate used to sign the response matches the name of 2723 the GL. 2725 3.b.1 - If the name of the GL does not match the name present in 2726 the certificate used to sign the message, the GLO should 2727 not believe the response. 2729 3.b.2 - Else if the name of the GL matches the name present in the 2730 certificate and: 2732 3.b.2.a - If the signatures verify and the response is 2733 cMCStatusInfoExt.cMCStatus.success, the GLO has 2734 successfully rekeyed the GL. 2736 3.b.2.b - Else if the GLO received a 2737 cMCStatusInfoExt.cMCStatus.failed with any reason, the 2738 GLO can reattempt to rekey the GL using the information 2739 provided in the response. 2741 4.5.2. GLA Initiated Rekey Requests 2743 If the GLA is in charge of rekeying the GL the GLA will automatically 2744 issue a glKey message (see section 5). In addition the GLA will 2745 generate a cMCStatusInfoExt to indicate to the GL that a successful 2746 rekey has occurred. The process for GLA initiated rekey is as 2747 follows: 2749 1 - The GLA generates for all GLOs a 2750 SignedData.PKIData.controlSequence.cMCStatusInfoExt.cMCStatus. 2751 success and includes a signingTime attribute (A in Figure 7). 2753 1.a - The GLA can optionally apply confidentiality to the request 2754 by encapsulating the SignedData.PKIData in an EnvelopedData 2755 (see section 3.2.1.2). 2757 1.b - The GLA can also optionally apply another SignedData over the 2758 EnvelopedData (see section 3.2.1.2). 2760 2 - Upon receipt of the cMCStatusInfoExt.cMCStatus.success 2761 response, the GLO checks the signingTime and verifies the GLA 2762 signature(s). If an additional SignedData and/or EnvelopedData 2763 encapsulates the forwarded response (see section 3.2.1.2 or 2764 3.2.2), the GLO MUST verify the outer signature and/or decrypt 2765 the outer layer prior to verifying the signature on the inner 2766 most SignedData. 2768 2.a - If the signingTime attribute value is not within the locally 2769 accepted time window, the GLO MAY return a response 2770 indicating cMCStatus.failed and otherInfo.failInfo.badTime 2771 and a signingTime attribute. 2773 2.b - Else if signature processing continues and if the signatures 2774 verify, the GLO checks that one of the names in the 2775 certificate used to sign the response matches the name of 2776 the GL. 2778 2.b.1 - If the name of the GL does not match the name present in 2779 the certificate used to sign the message, the GLO ought not 2780 believe the response. 2782 2.b.2 - Else if the name of the GL does match the name present in 2783 the certificate and and the response is 2784 cMCStatusInfoExt.cMCStatus.success, the GLO knows the GLA 2785 has successfully rekeyed the GL. 2787 4.6. Change GLO 2789 Management of managed and closed GLs can become difficult for one GLO 2790 if the GL membership grows large. To support distributing the 2791 workload, GLAs support having GLs be managed by multiple GLOs. The 2792 glAddOwner and glRemoveOwner messages are designed to support adding 2793 and removing registered GLOs. Figure 8 depicts the protocol 2794 interactions to send glAddOwner and glRemoveOwner messages and the 2795 resulting response messages. Note that error messages are not shown. 2796 Additionally, behavior for the optional transactionId, senderNonce, 2797 and recipientNonce CMC control attributes is not addressed in these 2798 procedures. 2800 +-----+ 1 2 +-----+ 2801 | GLA | <-------> | GLO | 2802 +-----+ +-----+ 2804 Figure 8 - GLO Add & Delete Owners 2806 The process for glAddOwner and glDeleteOwner is as follows: 2808 1 - The GLO sends a SignedData.PKIData.controlSequence.glAddOwner 2809 or glRemoveOwner request to the GLA (1 in Figure 8). The GLO 2810 includes: the GL name in glName, the name and address of the 2811 GLO in glOwnerName and glOwnerAddress, respectively. The GLO 2812 MUST also include the signingTime attribute with this request. 2814 1.a - The GLO can optionally apply confidentiality to the request 2815 by encapsulating the SignedData.PKIData in an EnvelopedData 2816 (see section 3.2.1.2). 2818 1.b - The GLO can also optionally apply another SignedData over the 2819 EnvelopedData (see section 3.2.1.2). 2821 2 - Upon receipt of the glAddOwner or glRemoveOwner request, the 2822 GLA checks the signingTime and verifies the GLO signature(s). 2823 If an additional SignedData and/or EnvelopedData encapsulates 2824 the request (see section 3.2.1.2 or 3.2.2), the GLA verifies 2825 the outer signature and/or decrypt the outer layer prior to 2826 verifying the signature on the inner most SignedData. 2828 2.a - If the signingTime attribute value is not within the locally 2829 accepted time window, the GLA MAY return a response 2830 indicating cMCStatus.failed and otherInfo.failInfo.badTime 2831 and a signingTime attribute. 2833 2.b - Else if signature processing continues and if the signatures 2834 cannot verified, the GLA returns a cMCStatusInfoExt response 2835 indicating cMCStatus.failed and 2836 otherInfo.failInfo.badMessageCheck. Additionally, a 2837 signingTime attribute is included with the response. 2839 2.c - Else if the signatures verify, the GLA makes sure the GL is 2840 supported by checking that the glName matches a glName 2841 stored on the GLA. 2843 2.c.1 - If the glName is not supported by the GLA, the GLA returns 2844 a response indicating cMCStatusInfoExt with 2845 cMCStatus.failed and otherInfo.extendedFailInfo.SKDFailInfo 2846 value of invalidGLName. Additionally, a signingTime 2847 attribute is included with the response. 2849 2.c.2 - Else if the glName is supported by the GLA, the GLA ensures 2850 a registered GLO signed the glAddOwner or glRemoveOwner 2851 request by checking that one of the names present in the 2852 digital signature certificate used to sign the glAddOwner 2853 or glDeleteOwner request matches the name of a registered 2854 GLO. 2856 2.c.2.a - If the names do not match, the GLA returns a response 2857 indicating cMCStatusInfoExt with cMCStatus.failed and 2858 otherInfo.extendedFailInfo.SKDFailInfo value of 2859 noGLONameMatch. Additionally, a signingTime attribute is 2860 included with the response. 2862 2.c.2.b - Else if the names match, the GLA returns a 2863 cMCStatusInfoExt.cMCStatus.success and a signingTime 2864 attribute (2 in Figure 4). The GLA also takes 2865 administrative actions to associate the new glOwnerName 2866 with the GL in the case of glAddOwner or to disassociate 2867 the old glOwnerName with the GL in the cased of 2868 glRemoveOwner. 2870 2.c.2.b.1 - The GLA applies confidentiality to the response by 2871 encapsulating the SignedData.PKIResponse in an 2872 EnvelopedData if the request was encapsulated in an 2873 EnvelopedData (see section 3.2.1.2). 2875 2.c.2.b.2 - The GLA can also optionally apply another SignedData 2876 over the EnvelopedData (see section 3.2.1.2). 2878 3 - Upon receipt of the cMCStatusInfoExt response, the GLO checks 2879 the signingTime and verifies the GLA's signature(s). If an 2880 additional SignedData and/or EnvelopedData encapsulates the 2881 response (see section 3.2.1.2 or 3.2.2), the GLO verifies the 2882 outer signature and/or decrypt the outer layer prior to 2883 verifying the signature on the inner most SignedData. 2885 3.a - If the signingTime attribute value is not within the locally 2886 accepted time window, the GLO MAY return a response 2887 indicating cMCStatus.failed and otherInfo.failInfo.badTime 2888 and a signingTime attribute. 2890 3.b - Else if signature processing continues and if the signatures 2891 verify, the GLO checks that one of the names in the 2892 certificate used to sign the response matches the name of 2893 the GL. 2895 3.b.1 - If the name of GL does not match the name present in the 2896 certificate used to sign the message, the GLO should not 2897 believe the response. 2899 3.b.2 - Else if the name of the GL does match the name present in 2900 the certificate and: 2902 3.b.2.a - If the signatures verify and the response was 2903 cMCStatusInfoExt.cMCStatus.success, the GLO has 2904 successfully added or removed the GLO. 2906 3.b.2.b - Else if the signatures verify and the response was 2907 cMCStatusInfoExt.cMCStatus.failed with any reason, the 2908 GLO can reattempt to add or delete the GLO using the 2909 information provided in the response. 2911 4.7. Indicate KEK Compromise 2913 There will be times when the shared KEK is compromised. GL members 2914 and GLOs use glkCompromise to tell the GLA that the shared KEK has 2915 been compromised. Figure 9 depicts the protocol interactions for GL 2916 Key Compromise. Note that error messages are not shown. Additionally, 2917 behavior for the optional transactionId, senderNonce, and 2918 recipientNonce CMC control attributes is not addressed in these 2919 procedures. 2921 +-----+ 2{1} 4 +----------+ 2922 | GLO | <----------+ +-------> | Member 1 | 2923 +-----+ 5,3{1} | | +----------+ 2924 +-----+ <----------+ | 4 +----------+ 2925 | GLA | 1 +-------> | ... | 2926 +-----+ <---------------+ +----------+ 2927 | 4 +----------+ 2928 +-------> | Member n | 2929 +----------+ 2931 Figure 9 - GL Key Compromise 2933 4.7.1. GL Member Initiated KEK Compromise Message 2935 The process for GL member initiated glkCompromise messages is as 2936 follows: 2938 1 - The GL member sends a 2939 SignedData.PKIData.controlSequence.glkCompromise request to the 2940 GLA (1 in Figure 9). The GL member includes the name of the GL 2941 in GeneralName. The GL member MUST also include the signingTime 2942 attribute with this request. 2944 1.a - The GL member can optionally apply confidentiality to the 2945 request by encapsulating the SignedData.PKIData in an 2946 EnvelopedData (see section 3.2.1.2). The glkCompromise can 2947 be included in an EnvelopedData generated with the 2948 compromised shared KEK. 2950 1.b - The GL member can also optionally apply another SignedData 2951 over the EnvelopedData (see section 3.2.1.2). 2953 2 - Upon receipt of the glkCompromise request, the GLA checks the 2954 signingTime and verifies the GL member signature(s). If an 2955 additional SignedData and/or EnvelopedData encapsulates the 2956 request (see section 3.2.1.2 or 3.2.2), the GLA verifies the 2957 outer signature and/or decrypt the outer layer prior to 2958 verifying the signature on the inner most SignedData. 2960 2.a - If the signingTime attribute value is not within the locally 2961 accepted time window, the GLA MAY return a response 2962 indicating cMCStatus.failed and otherInfo.failInfo.badTime 2963 and a signingTime attribute. 2965 2.b - Else if signature processing continues and if the signatures 2966 cannotbe verified, the GLA returns a cMCStatusInfoExt 2967 response indicating cMCStatus.failed and 2968 otherInfo.failInfo.badMessageCheck. Additionally, a 2969 signingTime attribute is included with the response. 2971 2.c - Else if the signatures verify, the GLA makes sure the GL is 2972 supported by checking that the indicated GL name matches a 2973 glName stored on the GLA. 2975 2.c.1 - If the glName is not supported by the GLA, the GLA returns 2976 a response indicating cMCStatusInfoExt with 2977 cMCStatus.failed and otherInfo.extendedFailInfo.SKDFailInfo 2978 value of invalidGLName. Additionally, a signingTime 2979 attribute is included with the response. 2981 2.c.2 - Else if the glName is supported by the GLA, the GLA checks 2982 who signed the request. For GLOs, one of the names in the 2983 certificate used to sign the request needs to match a 2984 registered GLO. For the member, the name in 2985 glMember.glMemberName needs to match one of the names in 2986 the certificate used to sign the request. 2988 2.c.2.a - If the GLO signed the request, the GLA generates a glKey 2989 message as described in section 5 to rekey the GL (4 in 2990 Figure 9). 2992 2.c.2.b - Else if someone other than the GLO signed the request, 2993 the GLA forwards the glkCompromise message (see section 2994 3.2.3) to the GLO (2{1} in Figure 9). If there is more 2995 than one GLO, to which GLO the request is forwarded is 2996 beyond the scope of this document. Further processing by 2997 the GLO is discussed in section 4.7.2. 2999 4.7.2. GLO Initiated KEK Compromise Message 3001 The process for GLO initiated glkCompromise messages is as follows: 3003 1 - The GLO either: 3005 1.a - Generates the glkCompromise message itself by sending a 3006 SignedData.PKIData.controlSequence.glkCompromise request to 3007 the GLA (5 in Figure 9). The GLO includes the name of the GL 3008 in GeneralName. The GLO MUST also include a signingTime 3009 attribute with this request. 3011 1.a.1 - The GLO can optionally apply confidentiality to the request 3012 by encapsulating the SignedData.PKIData in an EnvelopedData 3013 (see section 3.2.1.2). The glkCompromise can be included in 3014 an EnvelopedData generated with the compromised shared KEK. 3016 1.a.2 - The GLO can also optionally apply another SignedData over 3017 the EnvelopedData (see section 3.2.1.2). 3019 1.b - Otherwise, checks the signingTime and verifies the GLA and GL 3020 member signatures on the forwarded glkCompromise message. If 3021 an additional SignedData and/or EnvelopedData encapsulates 3022 the request (see section 3.2.1.2 or 3.2.2), the GLO verifies 3023 the outer signature and/or decrypt the outer layer prior to 3024 verifying the signature on the inner most SignedData. 3026 1.b.1 - If the signingTime attribute value is not within the 3027 locally accepted time window, the GLO MAY return a response 3028 indicating cMCStatus.failed and otherInfo.failInfo.badTime 3029 and a signingTime attribute. 3031 1.b.2 - Else if signature processing continues and if the 3032 signatures cannot be verified, the GLO returns a 3033 cMCStatusInfoExt response indicating cMCStatus.failed and 3034 otherInfo.failInfo.badMessageCheck. Additionally, a 3035 signingTime attribute is included with the response. 3037 1.b.2.a - If the signatures verify, the GLO checks the names in the 3038 certificate match the name of the signer (i.e., the name 3039 in the certificate used to sign the GL member's request 3040 is the GL member). 3042 1.b.2.a.1 - If either name does not match, the GLO ought not trust 3043 the signer and it ought not forward the message to the 3044 GLA. 3046 1.b.2.a.2 - Else if the names match and the signatures verify, the 3047 GLO determines whether to forward the glkCompromise 3048 message back to the GLA (3{1} in Figure 9). Further 3049 processing by the GLA is in 2 of section 4.7.1. The 3050 GLO can also return a response to the prospective 3051 member with cMCStatusInfoExt.cMCtatus.success 3052 indicating that the glkCompromise message was 3053 successfully received. 3055 4.8. Request KEK Refresh 3057 There will be times when GL members have unrecoverably lost their 3058 shared KEK. The shared KEK is not compromised and a rekey of the 3059 entire GL is not necessary. GL members use the glkRefresh message to 3060 request that the shared KEK(s) be redistributed to them. Figure 10 3061 depicts the protocol interactions for GL Key Refresh. Note that error 3062 messages are not shown. Additionally, behavior for the optional 3063 transactionId, senderNonce, and recipientNonce CMC control attributes 3064 is not addressed in these procedures. 3066 +-----+ 1 2 +----------+ 3067 | GLA | <-----------> | Member | 3068 +-----+ +----------+ 3070 Figure 10 - GL KEK Refresh 3072 The process for glkRefresh is as follows: 3074 1 - The GL member sends a 3075 SignedData.PKIData.controlSequence.glkRefresh request to the 3076 GLA (1 in Figure 10). The GL member includes name of the GL in 3077 GeneralName. The GL member MUST also include a signingTime 3078 attribute with this request. 3080 1.a - The GL member can optionally apply confidentiality to the 3081 request by encapsulating the SignedData.PKIData in an 3082 EnvelopedData (see section 3.2.1.2). 3084 1.b - The GL member can also optionally apply another SignedData 3085 over the EnvelopedData (see section 3.2.1.2). 3087 2 - Upon receipt of the glkRefresh request, the GLA checks the 3088 signingTime and verifies the GL member signature(s). If an 3089 additional SignedData and/or EnvelopedData encapsulates the 3090 request (see section 3.2.1.2 or 3.2.2), the GLA verifies the 3091 outer signature and/or decrypt the outer layer prior to 3092 verifying the signature on the inner most SignedData. 3094 2.a - If the signingTime attribute value is not within the locally 3095 accepted time window, the GLA MAY return a response 3096 indicating cMCStatus.failed and otherInfo.failInfo.badTime 3097 and a signingTime attribute. 3099 2.b - Else if signature processing continues and if the signatures 3100 cannot be verified, the GLA returns a cMCStatusInfoExt 3101 response indicating cMCStatus.failed and 3102 otherInfo.failInfo.badMessageCheck. Additionally, a 3103 signingTime attribute is included with the response. 3105 2.c - Else if the signatures verify, the GLA makes sure the GL is 3106 supported by checking that the GLGeneralName matches a 3107 glName stored on the GLA. 3109 2.c.1 - If the name of the GL is not supported by the GLA, the GLA 3110 returns a response indicating cMCStatusInfoExt with 3111 cMCStatus.failed and otherInfo.extendedFailInfo.SKDFailInfo 3112 value of invalidGLName. Additionally, a signingTime 3113 attribute is included with the response. 3115 2.c.2 - Else if the glName is supported by the GLA, the GLA ensures 3116 the GL member is on the GL. 3118 2.c.2.a - If the glMemberName is not present on the GL, the GLA 3119 returns a response indicating cMCStatusInfoExt with 3120 cMCStatus.failed and 3121 otherInfo.extendedFailInfo.SKDFailInfo value of noSpam. 3122 Additionally, a signingTime attribute is included with 3123 the response. 3125 2.c.2.b - Else if the glMemberName is present on the GL, the GLA 3126 returns a cMCStatusInfoExt.cMCStatus.success, a 3127 signingTime attribute, and a glKey message (2 in Figure 3128 10) as described in section 5. 3130 4.9. GLA Query Request and Response 3132 There will be certain times when a GLO is having trouble setting up a 3133 GL because they do not know the algorithm(s) or some other 3134 characteristic that the GLA supports. There can also be times when 3135 prospective GL members or GL members need to know something about the 3136 GLA (these requests are not defined in the document). The 3137 glaQueryRequest and glaQueryResponse message have been defined to 3138 support determining this information. Figure 11 depicts the protocol 3139 interactions for glaQueryRequest and glaQueryResponse. Note error 3140 messages are not shown. Additionally, behavior for the optional 3141 transactionId, senderNonce, and recipientNonce CMC control attributes 3142 is not addressed in these procedures. 3144 +-----+ 1 2 +------------------+ 3145 | GLA | <-------> | GLO or GL Member | 3146 +-----+ +------------------+ 3148 Figure 11 - GLA Query Request & Response 3150 The process for glaQueryRequest and glaQueryResponse is as follows: 3152 1 - The GLO, GL member, or prospective GL member sends a 3153 SignedData.PKIData.controlSequence.glaQueryRequest request to 3154 the GLA (1 in Figure 11). The GLO, GL member, or prospective GL 3155 member indicates the information they are interested in 3156 receiving from the GLA. Additionally, a signingTime attribute 3157 is included with this request. 3159 1.a - The GLO, GL member, or prospective GL member can optionally 3160 apply confidentiality to the request by encapsulating the 3161 SignedData.PKIData in an EnvelopedData (see section 3162 3.2.1.2). 3164 1.b - The GLO, GL member, or prospective GL member can also 3165 optionally apply another SignedData over the EnvelopedData 3166 (see section 3.2.1.2). 3168 2 - Upon receipt of the glaQueryRequest, the GLA determines if it 3169 accepts glaQueryRequest messages. 3171 2.a - If the GLA does not accept glaQueryRequest messages, the GLA 3172 returns a cMCStatusInfoExt response indicating 3173 cMCStatus.noSupport and any other information in 3174 statusString. 3176 2.b - Else if the GLA does accept GLAQueryRequests, the GLA checks 3177 the signingTime and verifies the GLO, GL member, or 3178 prospective GL member signature(s). If an additional 3179 SignedData and/or EnvelopedData encapsulates the request 3180 (see section 3.2.1.2 or 3.2.2), the GLA verifies the outer 3181 signature and/or decrypt the outer layer prior to verifying 3182 the signature on the inner most SignedData. 3184 2.b.1 - If the signingTime attribute value is not within the 3185 locally accepted time window, the GLA MAY return a response 3186 indicating cMCStatus.failed and otherInfo.failInfo.badTime 3187 and a signingTime attribute. 3189 2.b.2 - Else if the signature processing continues and if the 3190 signatures cannot be verified, the GLA returns a 3191 cMCStatusInfoExt response indicating cMCStatus.failed and 3192 otherInfo.failInfo.badMessageCheck. Additionally, a 3193 signingTime attribute is included with the response. 3195 2.b.3 - Else if the signatures verify, the GLA returns a 3196 glaQueryResponse (2 in Figure 11) with the correct response 3197 if the glaRequestType is supported or return a 3198 cMCStatusInfoExt response indicating cMCStatus.noSupport if 3199 the glaRequestType is not supported. Additionally, a 3200 signingTime attribute is included with the response. 3202 2.b.3.a - The GLA applies confidentiality to the response by 3203 encapsulating the SignedData.PKIResponse in an 3204 EnvelopedData if the request was encapsulated in an 3205 EnvelopedData (see section 3.2.1.2). 3207 2.b.3.b - The GLA can also optionally apply another SignedData over 3208 the EnvelopedData (see section 3.2.1.2). 3210 3 - Upon receipt of the glaQueryResponse, the GLO, GL member, or 3211 prospective GL member checks the signingTime and verifies the 3212 GLA signature(s). If an additional SignedData and/or 3213 EnvelopedData encapsulates the response (see section 3.2.1.2 or 3214 3.2.2), the GLO, GL member, or prospective GL member verifies 3215 the outer signature and/or decrypt the outer layer prior to 3216 verifying the signature on the inner most SignedData. 3218 3.a - If the signingTime attribute value is not within the locally 3219 accepted time window, the GLO, GL member, or prospective GL 3220 member MAY return a response indicating cMCStatus.failed and 3221 otherInfo.failInfo.badTime and a signingTime attribute. 3223 3.b - Else if signature processing continues and if the signatures 3224 do not verify, the GLO, GL member, or prospective GL member 3225 returns a cMCStatusInfoExt response indicating 3226 cMCStatus.failed and otherInfo.failInfo.badMessageCheck. 3227 Additionally, a signingTime attribute is included with the 3228 response. 3230 3.c - Else if the signatures verify, then the GLO, GL member, or 3231 prospective GL member checks that one of the names in the 3232 certificate used to sign the response matches the name of 3233 the GL. 3235 3.c.1 - If the name of the GL does not match the name present in 3236 the certificate used to sign the message, the GLO ought not 3237 believe the response. 3239 3.c.2 - Else if the name of the GL matches the name present in the 3240 certificate and the response was glaQueryResponse, then the 3241 GLO, GL member, or prospective GL member may use the 3242 information contained therein. 3244 4.10. Update Member Certificate 3246 When the GLO generates a glAddMember request, when the GLA generates 3247 a glKey message, or when the GLA processes a glAddMember there can be 3248 instances when GL member's certificate has expired or is invalid. In 3249 these instances the GLO or GLA may request that the GL member provide 3250 a new certificate to avoid the GLA from being unable to generate a 3251 glKey message for the GL member. There might also be times when the 3252 GL member knows their certificate is about to expire or has been 3253 revoked and they will not be able to receive GL rekeys. Behavior for 3254 the optional transactionId, senderNonce, and recipientNonce CMC 3255 control attributes is not addressed in these procedures. 3257 4.10.1. GLO and GLA Initiated Update Member Certificate 3259 The process for GLO initiated glUpdateCert is as follows: 3261 1 - The GLO or GLA sends a 3262 SignedData.PKIData.controlSequence.glProvideCert request to the 3263 GL member. The GLO or GLA indicates the GL name in glName and 3264 the GL member name in glMemberName. Additionally, a signingTime 3265 attribute is included with this request. 3267 1.a - The GLO or GLA can optionally apply confidentiality to the 3268 request by encapsulating the SignedData.PKIData in an 3269 EnvelopedData (see section 3.2.1.2). If the GL member's PKC 3270 has been revoked, the GLO or GLA ought not use it to 3271 generate the EnvelopedData that encapsulates the 3272 glProvideCert request. 3274 1.b - The GLO or GLA can also optionally apply another SignedData 3275 over the EnvelopedData (see section 3.2.1.2). 3277 2 - Upon receipt of the glProvideCert message, the GL member checks 3278 the signingTime and verifies the GLO or GLA signature(s). If an 3279 additional SignedData and/or EnvelopedData encapsulates the 3280 response (see section 3.2.1.2 or 3.2.2), the GL member verifies 3281 the outer signature and/or decrypt the outer layer prior to 3282 verifying the signature on the inner most SignedData. 3284 2.a - If the signingTime attribute value is not within the locally 3285 accepted time window, the GL member MAY return a response 3286 indicating cMCStatus.failed and otherInfo.failInfo.badTime 3287 and a signingTime attribute. 3289 2.b - Else if signature processing continues and if the signatures 3290 cannot be verified, the GL member returns a cMCStatusInfoExt 3291 response indicating cMCStatus.failed and 3292 otherInfo.failInfo.badMessageCheck. Additionally, a 3293 signingTime attribute is included with the response. 3295 2.c - Else if the signatures verify, the GL member generates a 3296 Signed.PKIResponse.controlSequence.glUpdateCert that 3297 includes the GL name in glName, the member name in 3298 glMember.glMemberName, their encryption certificate in 3299 glMember.certificates.pKC. The GL member can also include 3300 any attribute certificates associated with their encryption 3301 certificate in glMember.certificates.aC, and the 3302 certification path associated with their encryption and 3303 attribute certificates in glMember.certificates.certPath. 3304 Additionally, a signingTime attribute is included with the 3305 response. 3307 2.c.1 - The GL member can optionally apply confidentiality to the 3308 request by encapsulating the SignedData.PKIResponse in an 3309 EnvelopedData (see section 3.2.1.2). If the GL member's PKC 3310 has been revoked, the GL member ought not use it to 3311 generate the EnvelopedData that encapsulates the 3312 glProvideCert request. 3314 2.c.2 - The GL member can also optionally apply another SignedData 3315 over the EnvelopedData (see section 3.2.1.2). 3317 3 - Upon receipt of the glUpdateCert message, the GLO or GLA checks 3318 the signingTime and verifies the GL member signature(s). If an 3319 additional SignedData and/or EnvelopedData encapsulates the 3320 response (see section 3.2.1.2 or 3.2.2), the GL member verifies 3321 the outer signature and/or decrypt the outer layer prior to 3322 verifying the signature on the inner most SignedData. 3324 3.a - If the signingTime attribute value is not within the locally 3325 accepted time window, the GLO or GLA MAY return a response 3326 indicating cMCStatus.failed and otherInfo.failInfo.badTime 3327 and a signingTime attribute. 3329 3.b - Else if signature processing continues and if the signatures 3330 cannot be verified, the GLO or GLA returns a 3331 cMCStatusInfoExt response indicating cMCStatus.failed and 3332 otherInfo.failInfo.badMessageCheck. Additionally, a 3333 signingTime attribute is included with the response. 3335 3.c - Else if the signatures verify, the GLO or GLA verifies the 3336 member's encryption certificate. 3338 3.c.1 - If the member's encryption certificate cannot be verified, 3339 the GLO returns either another glProvideCert request or a 3340 cMCStatusInfoExt with cMCStatus.failed and the reason why 3341 in cMCStatus.statusString. glProvideCert should be returned 3342 only a certain number of times because if the GL member 3343 does not have a valid certificate they will never be able 3344 to return one. Additionally, a signingTime attribute is 3345 included with either response. 3347 3.c.2 - Else if the member's encryption certificate cannot be 3348 verified, the GLA returns another glProvideCert request to 3349 the GL member or a cMCStatusInfoExt with cMCStatus.failed 3350 and the reason why in cMCStatus.statusString to the GLO. 3351 glProvideCert should be returned only a certain number of 3352 times because if the GL member does not have a valid 3353 certificate they will never be able to return one. 3354 Additionally, a signingTime attribute is included with the 3355 response. 3357 3.c.3 - Else if the member's encryption certificate verifies, the 3358 GLO or GLA will use it in subsequent glAddMember requests 3359 and glKey messages associated with the GL member. 3361 4.10.2. GL Member Initiated Update Member Certificate 3363 The process for an unsolicited GL member glUpdateCert is as follows: 3365 1 - The GL member sends a 3366 Signed.PKIData.controlSequence.glUpdateCert that includes the 3367 GL name in glName, the member name in glMember.glMemberName, 3368 their encryption certificate in glMember.certificates.pKC. The 3369 GL member can also include any attribute certificates 3370 associated with their encryption certificate in 3371 glMember.certificates.aC, and the certification path associated 3372 with their encryption and attribute certificates in 3373 glMember.certificates.certPath. The GL member MUST also include 3374 a signingTime attribute with this request. 3376 1.a - The GL member can optionally apply confidentiality to the 3377 request by encapsulating the SignedData.PKIData in an 3378 EnvelopedData (see section 3.2.1.2). If the GL member's PKC 3379 has been revoked, the GLO or GLA ought not use it to 3380 generate the EnvelopedData that encapsulates the 3381 glProvideCert request. 3383 1.b - The GL member can also optionally apply another SignedData 3384 over the EnvelopedData (see section 3.2.1.2). 3386 2 - Upon receipt of the glUpdateCert message, the GLA checks the 3387 signingTime and verifies the GL member signature(s). If an 3388 additional SignedData and/or EnvelopedData encapsulates the 3389 response (see section 3.2.1.2 or 3.2.2), the GLA verifies the 3390 outer signature and/or decrypt the outer layer prior to 3391 verifying the signature on the inner most SignedData. 3393 2.a - If the signingTime attribute value is not within the locally 3394 accepted time window, the GLA MAY return a response 3395 indicating cMCStatus.failed and otherInfo.failInfo.badTime 3396 and a signingTime attribute. 3398 2.b - Else if signature processing continues and if the signatures 3399 cannot be verified, the GLA returns a cMCStatusInfoExt 3400 response indicating cMCStatus.failed and 3401 otherInfo.failInfo.badMessageCheck. 3403 2.c - Else if the signatures verify, the GLA verifies the member's 3404 encryption certificate. 3406 2.c.1 - If the member's encryption certificate cannot be verified, 3407 the GLA returns another glProvideCert request to the GL 3408 member or a cMCStatusInfoExt with cMCStatus.failed and the 3409 reason why in cMCStatus.statusString to the GLO. 3410 glProvideCert ought not be returned indefinitely; if the 3411 GL member does not have a valid certificate they will never 3412 be able to return one. Additionally, a signingTime 3413 attribute is included with the response. 3415 2.c.2 - Else if the member's encryption certificate verifies, the 3416 GLA will use it in subsequent glAddMember requests and 3417 glKey messages associated with the GL member. The GLA also 3418 forwards the glUpdateCert message to the GLO. 3420 5. Distribution Message 3422 The GLA uses the glKey message to distribute new, shared KEK(s) after 3423 receiving glAddMember, glDeleteMember (for closed and managed GLs), 3424 glRekey, glkCompromise, or glkRefresh requests and returning a 3425 cMCStatusInfoExt response for the respective request. Figure 12 3426 depicts the protocol interactions to send out glKey messages. Unlike 3427 the procedures defined for the administrative messages, the 3428 procedures defined in this section MUST be implemented by GLAs for 3429 origination and by GL members on reception. Note that error messages 3430 are not shown. Additionally, behavior for the optional transactionId, 3431 senderNonce, and recipientNonce CMC control attributes is not 3432 addressed in these procedures. 3434 1 +----------+ 3435 +-------> | Member 1 | 3436 | +----------+ 3437 +-----+ | 1 +----------+ 3438 | GLA | ----+-------> | ... | 3439 +-----+ | +----------+ 3440 | 1 +----------+ 3441 +-------> | Member n | 3442 +----------+ 3444 Figure 12 - GL Key Distribution 3446 If the GL was setup with GLKeyAttributes.recipientsNotMutuallyAware 3447 set to TRUE, a separate glKey message MUST be sent to each GL member 3448 so as to not divulge information about the other GL members. 3450 When the glKey message is generated as a result of a: 3452 - glAddMember request, 3454 - glkComrpomise indication, 3456 - glkRefresh request, 3458 - glDeleteMember request with the GL's glAdministration set to 3459 managed or closed, and 3461 - glRekey request with generationCounter set to zero (0). 3463 The GLA MUST use either the kari (see section 12.3.2 of [CMS]) or 3464 ktri (see section 12.3.1 of [CMS]) choice in 3465 glKey.glkWrapped.RecipientInfo to ensure only the intended recipients 3466 receive the shared KEK. The GLA MUST support the ktri choice. 3468 When the glKey message is generated as a result of a glRekey request 3469 with generationCounter greater than zero (0) or when the GLA controls 3470 rekeys, the GLA MAY use the kari, ktri, or kekri (see section 12.3.3 3471 of [CMS]) in glKey.glkWrapped.RecipientInfo to ensure only the 3472 intended recipients receive the shared KEK. The GLA MUST support the 3473 RecipientInfo.ktri choice. 3475 5.1. Distribution Process 3477 When a glKey message is generated the process is as follows: 3479 1 - The GLA MUST send a SignedData.PKIData.controlSequence.glKey to 3480 each member by including: glName, glIdentifier, glkWrapped, 3481 glkAlgorithm, glkNotBefore, and glkNotAfter. If the GLA can not 3482 generate a glKey message for the GL member because the GL 3483 member's PKC has expired or is otherwise invalid, the GLA MAY 3484 send a glUpdateCert to the GL member requesting a new 3485 certificate be provided (see section 4.10). The number of glKey 3486 messages generated for the GL is described in section 3.1.16. 3487 Additionally, a signingTime attribute is included with the 3488 distribution message(s). 3490 1.a - The GLA MAY optionally apply another confidentiality layer to 3491 the message by encapsulating the SignedData.PKIData in 3492 another EnvelopedData (see section 3.2.1.2). 3494 1.b - The GLA MAY also optionally apply another SignedData over the 3495 EnvelopedData.SignedData.PKIData (see section 3.2.1.2). 3497 2 - Upon receipt of the glKey message, the GL members MUST check 3498 the signingTime and verify the signature over the inner most 3499 SignedData.PKIData. If an additional SignedData and/or 3500 EnvelopedData encapsulates the message (see section 3.2.1.2 or 3501 3.2.2), the GL Member MUST verify the outer signature and/or 3502 decrypt the outer layer prior to verifying the signature on the 3503 SignedData.PKIData.controlSequence.glKey. 3505 2.a - If the signingTime attribute value is not within the locally 3506 accepted time window, the GLA MAY return a response 3507 indicating cMCStatus.failed and otherInfo.failInfo.badTime 3508 and a signingTime attribute. 3510 2.b - Else if signature processing continues and if the signatures 3511 cannot be verified, the GL member MUST return a 3512 cMCStatusInfoExt response indicating cMCStatus.failed and 3513 otherInfo.failInfo.badMessageCheck. Additionally, a 3514 signingTime attribute is included with the response. 3516 2.c - Else if the signatures verify, the GL member process the 3517 RecipientInfos according to [CMS]. Once unwrapped the GL 3518 member should store the shared KEK in a safe place. When 3519 stored, the glName, glIdentifier, and shared KEK should be 3520 associated. Additionally, the GL member MUST return a 3521 cMCStatusInfoExt indicating cMCStatus.success to tell the 3522 GLA the KEK was received. 3524 6. Algorithms 3526 This section lists the algorithms that MUST be implemented. 3527 Additional algorithms that SHOULD be implemented are also included. 3528 Further algorithms MAY also be implemented. 3530 6.1. KEK Generation Algorithm 3532 Implementations MUST randomly generate content-encryption keys, 3533 message-authentication keys, initialization vectors (IVs), and 3534 padding. Also, the generation of public/private key pairs relies on a 3535 random numbers. The use of inadequate pseudo-random number generators 3536 (PRNGs) to generate cryptographic keys can result in little or no 3537 security. An attacker may find it much easier to reproduce the PRNG 3538 environment that produced the keys, searching the resulting small set 3539 of possibilities, rather than brute force searching the whole key 3540 space. The generation of quality random numbers is difficult. RFC 3541 1750 [RANDOM] offers important guidance in this area, and Appendix 3 3542 of FIPS Pub 186 [FIPS] provides one quality PRNG technique. 3544 6.2. Shared KEK Wrap Algorithm 3546 In the mechanisms described in sections 5, the shared KEK being 3547 distributed in glkWrapped MUST be protected by a key of equal or 3548 greater length (i.e., if an AES 128-bit key is being distributed a 3549 key of 128-bits or greater must be used to protect the key). The 3550 algorithm object identifiers included in glkWrapped are as specified 3551 in [CMSALG] and [CMSAES]. 3553 6.3. Shared KEK Algorithm 3555 The shared KEK distributed and indicated in glkAlgorithm MUST support 3556 the symmetric key-encryption algorithms as specified in section 3557 [CMSALG] and [CMSAES]. 3559 7. Message Transport 3561 SMTP [SMTP] MUST be supported. Other transport mechanisms MAY also be 3562 supported. 3564 8. Security Considerations 3566 As GLOs control setting up and tearing down the GL, rekeying the GL, 3567 and can control member additions and deletions, GLOs play an 3568 important role in the management of the GL, and only "trusted" GLOs 3569 should be used. 3571 If a member is deleted or removed from a closed or a managed GL, the 3572 GL needs to be rekeyed. If the GL is not rekeyed after a member is 3573 removed or deleted, the member still posses the group key and will be 3574 able to continue to decrypt any messages that can be obtained. 3576 Members who store KEKs MUST associate the name of the GLA that 3577 distributed the key so that the members can make sure subsequent 3578 rekeys are originated from the same entity. 3580 When generating keys, care should be taken to ensure that the key 3581 size is not too small and duration too long because attackers will 3582 have more time to attack the key. Key size should be selected to 3583 adequately protect sensitive business communications. 3585 GLOs and GLAs need to make sure that the generationCounter and 3586 duration are not too large. For example, if the GLO indicates that 3587 the generationCounter is 14 and the duration is one year, then 14 3588 keys are generated each with a validity period of a year. An attacker 3589 will have at least 13 years to attack the final key. 3591 Assume that two or more parties have a shared KEK, and the shared KEK 3592 is used to encrypt a second KEK for confidential distribution to 3593 those parties. The second KEK might be used to encrypt a third KEK; 3594 the third KEK might be used to encrypt a fourth KEK; and so on. If 3595 any of the KEKs in such a chain is compromised, all of the subsequent 3596 KEKs in the chain MUST also be considered compromised. 3598 An attacker can attack the group's shared KEK by attacking one 3599 member's copy of the shared KEK or attacking multiple member's copies 3600 of the shared KEK. For the attacker it may be easier to either attack 3601 the group member with the weakest security protecting their copy of 3602 the shared KEK or by attacking multiple group members. 3604 An aggregation of the information gathered during the attack(s) may 3605 lead to the compromise of the group's shared KEK. Mechanisms to 3606 protect the shared KEK should be commensurate with value of the data 3607 being protected. 3609 The nonce and signingTime attributes are used to protect against 3610 replay attacks. However, these provisions are only helpful if 3611 entities maintain state information about the messages they have sent 3612 or received for comparison. If sufficient information is not 3613 maintained on each exchange, nonces and signingTime are not helpful. 3615 Local policy determines the amount and duration of state information 3616 that is maintained. Additionally, without a unified time source, 3617 there is the possibility of clocks drifting. Local policy determines 3618 the acceptable difference between the local time and signingTime, 3619 which must compensate for unsynchronized clock. Implementations MUST 3620 handle messages with siginingTime attributes that indicate they were 3621 created in the future. 3623 9. IANA Considerations 3625 None: All identifiers are already registered. Please remove this 3626 section prior to publication as an RFC. 3628 10. Acknowledgements 3630 Thanks to Russ Housley and Jim Schaad for providing much of the 3631 background and review required to write this document. 3633 11. References 3635 11.1. Normative References 3637 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 3638 Requirement Levels", BCP 14, RFC 2119, March 1997. 3640 [CMS] Housley, R., "Cryptographic Message Syntax," RFC 3852, 3641 July 2004. 3643 [CMC] Myers, M., Liu, X., Schaad, J., Weinsten, J., 3644 "Certificate Management Message over CMS," work-in- 3645 progress, December 2007. 3647 [PROFILE] Housley, R., Ford, W., Polk, W. and D. Solo, "Internet 3648 X.509 Public Key Infrastructure: Certificate and CRL 3649 Profile", RFC 3280, April 2002. 3651 [ACPROF] Farrell, S., Housley, R., "An Internet Attribute 3652 Certificate Profile for Authorization", RFC 3281, April 3653 2002. 3655 [MSG] Ramsdale, B., "S/MIME Version 3.1 Message Specification," 3656 RFC 3851, July 2004. 3658 [ESS] Hoffman, P., "Extended Security Services for S/MIME", RFC 3659 2634, June 1999. 3661 Schaad, J., "Extended Security Services (ESS) Update: 3662 Adding CertID Algorithm Agility", RFC 5035, August 2007. 3664 [CMSALG] Housley, R., "Cryptographic Message Syntax (CMS) 3665 Algorithms", RFC 3370, August 2002. 3667 [CMSAES] Schaad, J., "Advanced Encryption Standard (AES) Encryption 3668 Algorithm in Cryptographic Message Syntax (CMS) ", RFC 3669 3565, July 2003. 3671 [SMTP] Klensin, J., "Simple Mail Transport Protocol," RFC 2821, 3672 April 2001. 3674 11.2. Informative References 3676 [X400TRANS] Hoffman, P., and C. Bonatti, "Transporting S/MIME Objects 3677 in X.400", RFC 3855, July 2004. 3679 [RANDOM] Eastlake, D., Crocker, S. and J. Schiller, "Randomness 3680 Recommendations for Security", RFC 4086, June 2005. 3682 [FIPS] National Institute of Standards and Technology. FIPS Pub 3683 186-2: Digital Signature Standard. 27 January 2000. 3685 12. ASN.1 Module 3687 SMIMESymmetricKeyDistribution 3689 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 3690 smime(16) modules(0) symkeydist(12) } 3692 DEFINITIONS IMPLICIT TAGS ::= 3694 BEGIN 3696 -- EXPORTS All -- 3697 -- The types and values defined in this module are exported for use 3698 -- in the other ASN.1 modules. Other applications may use them for 3699 -- their own purposes. 3701 IMPORTS 3703 -- PKIX Part 1 - Implicit 3705 GeneralName 3707 FROM PKIX1Implicit88 { iso(1) identified-organization(3) dod(6) 3708 internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) 3709 id-pkix1-implicit(19) } 3711 -- PKIX Part 1 - Explicit 3713 AlgorithmIdentifier, Certificate 3715 FROM PKIX1Explicit88 { iso(1) identified-organization(3) dod(6) 3716 internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) 3717 id-pkix1-explicit(18) } 3719 -- Cryptographic Message Syntax 3721 RecipientInfos, KEKIdentifier, CertificateSet 3723 FROM CryptographicMessageSyntax2004 {iso(1) member-body(2) us(840) 3724 rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) modules(0) 3725 cms-2004(24) } 3727 -- Advanced Encryption Standard (AES) with CMS 3729 id-aes128-wrap 3731 FROM CMSAesRsaesOaep { iso(1) member-body(2) us(840) rsadsi(113549) 3732 pkcs(1) pkcs-9(9) smime(16) modules(0) id-mod-cms-aes(19) } 3734 -- Attribute Certificate Profile 3736 AttributeCertificate 3738 FROM PKIXAttributeCertificate { iso(1) identified-organization(3) 3739 dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) 3740 id-mod-attribute-cert(12) }; 3742 -- This defines the GL symmetric key distribution object identifier 3743 -- arc. 3745 id-skd OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) 3746 rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) skd(8) } 3748 -- This defines the GL Use KEK control attribute 3750 id-skd-glUseKEK OBJECT IDENTIFIER ::= { id-skd 1} 3752 GLUseKEK ::= SEQUENCE { 3753 glInfo GLInfo, 3754 glOwnerInfo SEQUENCE SIZE (1..MAX) OF GLOwnerInfo, 3755 glAdministration GLAdministration DEFAULT 1, 3756 glKeyAttributes GLKeyAttributes OPTIONAL } 3758 GLInfo ::= SEQUENCE { 3759 glName GeneralName, 3760 glAddress GeneralName } 3762 GLOwnerInfo ::= SEQUENCE { 3763 glOwnerName GeneralName, 3764 glOwnerAddress GeneralName, 3765 certificates Certificates OPTIONAL } 3767 GLAdministration ::= INTEGER { 3768 unmanaged (0), 3769 managed (1), 3770 closed (2) } 3772 GLKeyAttributes ::= SEQUENCE { 3773 rekeyControlledByGLO [0] BOOLEAN DEFAULT FALSE, 3774 recipientsNotMutuallyAware [1] BOOLEAN DEFAULT TRUE, 3775 duration [2] INTEGER DEFAULT 0, 3776 generationCounter [3] INTEGER DEFAULT 2, 3777 requestedAlgorithm [4] AlgorithmIdentifier 3778 DEFAULT { id-aes128-wrap } } 3780 -- This defines the Delete GL control attribute. 3781 -- It has the simple type GeneralName. 3783 id-skd-glDelete OBJECT IDENTIFIER ::= { id-skd 2} 3785 DeleteGL ::= GeneralName 3787 -- This defines the Add GL Member control attribute 3789 id-skd-glAddMember OBJECT IDENTIFIER ::= { id-skd 3} 3791 GLAddMember ::= SEQUENCE { 3792 glName GeneralName, 3793 glMember GLMember } 3795 GLMember ::= SEQUENCE { 3796 glMemberName GeneralName, 3797 glMemberAddress GeneralName OPTIONAL, 3798 certificates Certificates OPTIONAL } 3800 Certificates ::= SEQUENCE { 3801 pKC [0] Certificate OPTIONAL, 3802 -- See [PROFILE] 3803 aC [1] SEQUENCE SIZE (1.. MAX) OF 3804 AttributeCertificate OPTIONAL, 3805 -- See [ACPROF] 3806 certPath [2] CertificateSet OPTIONAL } 3807 -- From [CMS] 3809 -- This defines the Delete GL Member control attribute 3811 id-skd-glDeleteMember OBJECT IDENTIFIER ::= { id-skd 4} 3813 GLDeleteMember ::= SEQUENCE { 3814 glName GeneralName, 3815 glMemberToDelete GeneralName } 3817 -- This defines the Delete GL Member control attribute 3819 id-skd-glRekey OBJECT IDENTIFIER ::= { id-skd 5} 3821 GLRekey ::= SEQUENCE { 3822 glName GeneralName, 3823 glAdministration GLAdministration OPTIONAL, 3824 glNewKeyAttributes GLNewKeyAttributes OPTIONAL, 3825 glRekeyAllGLKeys BOOLEAN OPTIONAL } 3827 GLNewKeyAttributes ::= SEQUENCE { 3828 rekeyControlledByGLO [0] BOOLEAN OPTIONAL, 3829 recipientsNotMutuallyAware [1] BOOLEAN OPTIONAL, 3830 duration [2] INTEGER OPTIONAL, 3831 generationCounter [3] INTEGER OPTIONAL, 3832 requestedAlgorithm [4] AlgorithmIdentifier OPTIONAL } 3834 -- This defines the Add and Delete GL Owner control attributes 3836 id-skd-glAddOwner OBJECT IDENTIFIER ::= { id-skd 6} 3838 id-skd-glRemoveOwner OBJECT IDENTIFIER ::= { id-skd 7} 3840 GLOwnerAdministration ::= SEQUENCE { 3841 glName GeneralName, 3842 glOwnerInfo GLOwnerInfo } 3844 -- This defines the GL Key Compromise control attribute. 3845 -- It has the simple type GeneralName. 3847 id-skd-glKeyCompromise OBJECT IDENTIFIER ::= { id-skd 8} 3849 GLKCompromise ::= GeneralName 3851 -- This defines the GL Key Refresh control attribute. 3853 id-skd-glkRefresh OBJECT IDENTIFIER ::= { id-skd 9} 3855 GLKRefresh ::= SEQUENCE { 3856 glName GeneralName, 3857 dates SEQUENCE SIZE (1..MAX) OF Date } 3859 Date ::= SEQUENCE { 3860 start GeneralizedTime, 3861 end GeneralizedTime OPTIONAL } 3863 -- This defines the GLA Query Request control attribute. 3865 id-skd-glaQueryRequest OBJECT IDENTIFIER ::= { id-skd 11} 3867 GLAQueryRequest ::= SEQUENCE { 3868 glaRequestType OBJECT IDENTIFIER, 3869 glaRequestValue ANY DEFINED BY glaRequestType } 3871 -- This defines the GLA Query Response control attribute. 3873 id-skd-glaQueryResponse OBJECT IDENTIFIER ::= { id-skd 12} 3875 GLAQueryResponse ::= SEQUENCE { 3876 glaResponseType OBJECT IDENTIFIER, 3877 glaResponseValue ANY DEFINED BY glaResponseType } 3879 -- This defines the GLA Request/Response (glaRR) arc for 3880 -- glaRequestType/glaResponseType. 3882 id-cmc-glaRR OBJECT IDENTIFIER ::= { 3883 iso(1) identified-organization(3) dod(6) internet(1) security(5) 3884 mechanisms(5) pkix(7) cmc(7) glaRR(99) } 3886 -- This defines the Algorithm Request 3888 id-cmc-gla-skdAlgRequest OBJECT IDENTIFIER ::= { id-cmc-glaRR 1 } 3890 SKDAlgRequest ::= NULL 3892 -- This defines the Algorithm Response 3893 id-cmc-gla-skdAlgResponse OBJECT IDENTIFIER ::= { id-cmc-glaRR 2 } 3895 -- Note that the response for algorithmSupported request is the 3896 -- smimeCapabilities attribute as defined in MsgSpec [MSG]. 3897 -- This defines the control attribute to request an updated 3898 -- certificate to the GLA. 3900 id-skd-glProvideCert OBJECT IDENTIFIER ::= { id-skd 13} 3902 GLManageCert ::= SEQUENCE { 3903 glName GeneralName, 3904 glMember GLMember } 3906 -- This defines the control attribute to return an updated 3907 -- certificate to the GLA. It has the type GLManageCert. 3909 id-skd-glManageCert OBJECT IDENTIFIER ::= { id-skd 14} 3911 -- This defines the control attribute to distribute the GL shared 3912 -- KEK. 3914 id-skd-glKey OBJECT IDENTIFIER ::= { id-skd 15} 3916 GLKey ::= SEQUENCE { 3917 glName GeneralName, 3918 glIdentifier KEKIdentifier, -- See [CMS] 3919 glkWrapped RecipientInfos, -- See [CMS] 3920 glkAlgorithm AlgorithmIdentifier, 3921 glkNotBefore GeneralizedTime, 3922 glkNotAfter GeneralizedTime } 3924 -- This defines the CMC error types 3926 id-cet-skdFailInfo OBJECT IDENTIFIER ::= { 3927 iso(1) identified-organization(3) dod(6) internet(1) security(5) 3928 mechanisms(5) pkix(7) cet(15) skdFailInfo(1) } 3930 SKDFailInfo ::= INTEGER { 3931 unspecified (0), 3932 closedGL (1), 3933 unsupportedDuration (2), 3934 noGLACertificate (3), 3935 invalidCert (4), 3936 unsupportedAlgorithm (5), 3937 noGLONameMatch (6), 3938 invalidGLName (7), 3939 nameAlreadyInUse (8), 3940 noSpam (9), 3941 deniedAccess (10), 3942 alreadyAMember (11), 3943 notAMember (12), 3944 alreadyAnOwner (13), 3945 notAnOwner (14) } 3947 END -- SMIMESymmetricKeyDistribution 3949 Author's Addresses 3951 Sean Turner 3953 IECA, Inc. 3954 3057 Nutley Street, Suite 106 3955 Fairfax, VA 22031 3956 USA 3958 Email: turners@ieca.com 3960 Full Copyright Statement 3962 Copyright (C) The IETF Trust (2008). 3964 This document is subject to the rights, licenses and restrictions 3965 contained in BCP 78, and except as set forth therein, the authors 3966 retain all their rights. 3968 This document and the information contained herein are provided on an 3969 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 3970 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 3971 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 3972 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 3973 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 3974 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 3976 Intellectual Property Statement 3978 The IETF takes no position regarding the validity or scope of any 3979 Intellectual Property Rights or other rights that might be claimed to 3980 pertain to the implementation or use of the technology described in 3981 this document or the extent to which any license under such rights 3982 might or might not be available; nor does it represent that it has 3983 made any independent effort to identify any such rights. Information 3984 on the procedures with respect to rights in RFC documents can be 3985 found in BCP 78 and BCP 79. 3987 Copies of IPR disclosures made to the IETF Secretariat and any 3988 assurances of licenses to be made available, or the result of an 3989 attempt made to obtain a general license or permission for the use of 3990 such proprietary rights by implementers or users of this 3991 specification can be obtained from the IETF on-line IPR repository at 3992 http://www.ietf.org/ipr. 3994 The IETF invites any interested party to bring to its attention any 3995 copyrights, patents or patent applications, or other proprietary 3996 rights that may cover technology that may be required to implement 3997 this standard. Please address the information to the IETF at 3998 ietf-ipr@ietf.org. 4000 Acknowledgment 4002 Funding for the RFC Editor function is currently provided by the 4003 Internet Society.