idnits 2.17.1 draft-ietf-smime-symkeydist-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 1080 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([CMS]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 4 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 205: '... and gkaResponse MAY be used between t...' RFC 2119 keyword, line 210: '...aRequest content-type, it MUST support...' RFC 2119 keyword, line 211: '...onse content-type. The GMA MAY support...' RFC 2119 keyword, line 214: '...he gkaRequest it MUST support forwardi...' RFC 2119 keyword, line 215: '...esponse. The GMA MAY support generatin...' (146 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- ** The document contains RFC2119-like boilerplate, but doesn't seem to mention RFC 2119. The boilerplate contains a reference [MUSTSHOULD], but that reference does not seem to mention RFC 2119 either. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: The GMA MUST not accept further requests from users (in the case of unadministered GLs) to be added or deleted from the GL. The GMA MUST forward the gkaRequest to the KMA. -- 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 (December 20, 1999) is 8894 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'MUSTSHOULD' is mentioned on line 88, but not defined -- Looks like a reference, but probably isn't: '0' on line 285 -- Looks like a reference, but probably isn't: '1' on line 286 -- Looks like a reference, but probably isn't: '2' on line 265 -- Looks like a reference, but probably isn't: '3' on line 266 -- Looks like a reference, but probably isn't: '4' on line 267 == Unused Reference: 'ESS' is defined on line 1039, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2630 (ref. 'CMS') (Obsoleted by RFC 3369, RFC 3370) ** Obsolete normative reference: RFC 2459 (ref. 'PROFILE') (Obsoleted by RFC 3280) Summary: 12 errors (**), 0 flaws (~~), 6 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 SMIME Working Group S. Turner 2 INTERNET DRAFT IECA 4 Expires in on 20 June, 2000 December 20, 1999 6 S/MIME Symmetric Key Distribution 7 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with all 12 provisions of Section 10 of RFC2026. 14 This document is an Internet-Draft. Internet-Drafts are working 15 documents of the Internet Engineering Task Force (IETF), its areas, and 16 its working groups. Note that other groups may also distribute working 17 documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of 6 months and 20 may be updated, replaced, or may become obsolete by other documents at 21 any time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt. 27 The list of current Internet-Drafts Shadow Directories can be accessed 28 at http://www.ietf.org/shadow.html.http://www.ietf.org/shadow.html. 30 Abstract 32 This document describes a mechanism to manage (i.e., setup, distribute, 33 and rekey) keys used with symmetric cryptographic algorithms. The 34 mechanisms use the CMSCryptographic Message Syntax (CMS) protocol [CMS] 35 to encrypt the key for each member of the group. Any member of the group 36 can then later use this key to decrypt other CMS encrypted objects with 37 the symmetric or 'group' key. 39 This draft is being discussed on the 'ietf-smime' mailing list. To 40 subscribe, send a message to: 41 ietf-smime-request@imc.org with the single word 42 subscribe in the body of the message. There is a Web site for the 43 mailing list at . 45 1 Introduction 47 With the ever expanding use of secure electronic communications (e.g., 48 S/MIME [CMS]), users require a mechanism to distribute encrypted data 49 to multiple recipients (i.e., a group of users). There are essentially 50 two ways to encrypt the data for the recipients: using asymmetric 51 algorithms with public key certificates (PKCs) or symmetric algorithms 52 with shared secret keys. With asymmetric algorithms, the encrypting user 53 forms an originator-determined content-encryption key (CEK) and encrypts 54 the content, using a symmetric algorithm. Then, using an asymmetric 55 algorithm and PKCs, the encrypting user generates per-recipient 56 information that either (a) encrypts the CEK for a particular recipient 57 (ktri ReipientInfo CHOICE), or (b) transfers sufficient parameters to 58 enable a particular recipient to independently generate the same CEK 59 (kari RecipientInfo CHOICE). If the group is large the number of per- 60 recipient information that needs to be generated may take quite some 61 time, not to mention the time required to collect the PKCs for each of 62 the recipients. With symmetric algorithms, all members of the group use 63 a previously shared distributed secret key-encryption key (KEK). The 64 originating user only needs to encrypt the content with the shared KEK, 65 which is then used by every member in the group to decrypt the message. 66 A mechanism is defined herein to support distribution of shared KEKs in 67 order to enable symmetric algorithms. 69 [ST - I interchangeable use group key to mean shared KEK. In the next 70 version I will use the term shared KEK through out the document.] 72 The security provided by the symmetric key is only as good as the sum of 73 the techniques employed by each member of the group to keep the 74 symmetric key secret from nonmembers. These techniques are beyond the 75 scope of this document. Only the members of the list and the key manager 76 should have the key in order to maintain the secrecy of the group. 77 Access control to the information protected by the symmetric key is 78 determined by the entity that encrypts the information, as all members 79 of the group have access. If the entity that is performing the 80 encryption wants to ensure some subset of the group does not gain access 81 to the information either a different symmetric key should be used 82 (shared with this smaller group) or asymmetric algorithms should be 83 used. 85 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 86 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 87 document are to be interpreted as described in [MUSTSHOULD]. 89 1.1 Applicability to E-mail 91 One primary audience for this distribution mechanism is e-mail. 92 Distribution lists sometimes referred to as mail lists, have been 93 defined to support distribution of messages to a group of recipients 94 subscribed to the originatormail list. There are two models for how the 95 mail list can be used. If the originator is a member of the mail list, 96 the originator sends the encrypted message with the symmetric KEK to the 97 mail list (e.g., listserv or majordomo) and the message is distributed 98 to the mail list members. If the originator is not a member of the mail 99 list (does not have the group key), the originator sends the message to 100 the mail list agent (MLA) and the MLA then forms the KEK key needed for 101 the message. In either case the recipients of the mail list use the 102 previously distributed group key to decrypt the message. 104 1.2 Applicability to Repositories 106 Objects can also be distributed via a repository (e.g., Light Weight 107 Directory Protocol (LDAP) servers, X.500 Directory System Agents (DSAs), 108 Web-based servers). If an object is stored in a repository, encrypted 109 with a symmetric key algorithm, any one with access to that object can 110 then decrypt that object. The encrypted object and the encrypted key can 111 be stored in the repository. 113 2. Architecture 115 Figure 1 depicts the architecture to support symmetric key distribution. 116 Two different functions are required: generating the keys and 117 distributing the keys. These functions are performed by two conceptually 118 different entities. The Key Management Agent (KMA) is responsible for 119 generating the keys and the Group Management Agent (GMA) holds the group 120 list (GL) to which it is responsible for distributing the keys. Either 121 the KMA or GMA MAY: 123 - Support one GL or multiple GLs; 124 - Be collocated one a single platform or on separate platforms. 126 GLs are managed either through an automated process or by a human (an GL 127 Owner). Members of the GLs require access to the symmetric key therefore 128 adding and removing members is an important part of maintaining the 129 security for the entire group. If the GL is managed through an automated 130 process, mechanisms, beyond the scope of this document, may be used to 131 limit the addition of new members (e.g., using an access control list) 132 or the GL may be configured to allow anyone to join or depart from the 133 GL. If the GL is managed by a human, messages, beyond the scope of this 134 document, may be sent between the new member and the GL Owner requesting 135 the new member be added to the GL. The GL Owner may then decide whether 136 the new member should be added or not or the GL Owner may simply add a 137 new member, knowing the new member requires access to the messages. The 138 GL Owner may or may not be a member of the GL, but the GL Owner is the 139 only person(s) able to add or delete a GL. 141 +----------------------+ 142 | Key Management Agent | 143 +----------------------+ 144 | 145 +------------------+ 146 | Group Management | 147 | Agent | 148 | +-------+ | 149 | | Group | | 150 | | List | | 151 | +-------+ | 152 | / | \ | 153 +------------------+ 154 / | \ 155 / | \ 156 +----------+ +---------+ +----------+ 157 | Member 1 | | ... | | Member n | 158 +----------+ +---------+ +----------+ 160 Figure 1 - Key Distribution Architecture 162 3 Protocol Interactions 164 A few basic interactions occur between the KMA, GMA, Members, and the 165 optional GL Owner (used if the list is not managed by an automated 166 process) to support the management of the symmetric keys used by the 167 group (henceforth referred to as the group key). Management includes the 168 steps required to setup the group key, add new members, delete members, 169 and distribute a new group key (i.e., rekey). The following sections 170 describe the procedures for each of the management functions. 172 [ST - Need to add what's mandatory to implement here - I think sending 173 and receiving gkDistribution messages; storing the distributed key; and 174 using the previously distributed key to decrypt future messages.] 176 3.1 Group Key Administration 178 Figure 2 depicts the scenarios for group key setup administration. Each 179 of the interactions depicted is discussed in paragraphs 3.1.1, 3.1.2, 180 3.1.3, and 3.1.4. 182 +----------+ +----------+ 183 | GL Owner | <---+ +----> | Member 1 | <--+ 184 +----------+ | | +----------+ | 185 | | | 186 +-----+ +-----+ <----+ | +----------+ | 187 | KMA | <----------> | GMA | <---------------+----> | ... | <--+ 188 +-----+ +-----+ | +----------+ | 189 | | | 190 | | +----------+ | 191 | +----> | Member n | <--+ 192 | +----------+ | 193 +----------------------------------------------------------------+ 195 Figure 2 - Group Key Setup 197 3.1.1 Request/Response Group Key Administration 199 There are a number of administrative functions that must be performed to 200 manage a GL: creating the GL, deleting the GL, adding members to the GL, 201 deleting members of the GL, and requesting a group rekey. The group key 202 administration request (gkaRequest) and group key administration 203 responses (gkaResponse) content-types, defined in paragraphs 3.1.1.1 and 204 3.1.1.2, are defined to support these administrative functions. The 205 gkaRequest and gkaResponse MAY be used between the GL Owner and the GMA 206 and between the GL Owner or GMA and the KMA to manage the GL. If the 207 message is from the GMA to the KMA, it may be on behalf of the GL Owner 208 or from the GL members. 210 If the GL Owner supports the gkaRequest content-type, it MUST support 211 the corresponding gkaResponse content-type. The GMA MAY support 212 forwarding the gkaRequest content-type from the GL Owner to the KMA and 213 the gkaResponse content-type from the KMA to the GL Owner. If the KMA 214 supports forwarding the gkaRequest it MUST support forwarding the 215 gkaResponse. The GMA MAY support generating the gkaRequest content-type 216 on behalf of prospective GL member or existing GL members. The KMA MAY 217 support receiving a gkaRequest content-type and generating a gkaResponse 218 content-type. If the KMA supports receiving the gkaRequest content-type 219 it must support generating the gkaResponse content-type. 221 3.1.1.1 Request For Group Key Administration 223 The gkaRequest content-type is defined to support conveying group key 224 administration requests from the GL Owner to the GMA or from the GMA to 225 the KMA. The gkaRequest content-type MUST be protected at a minimum by 226 id-signedData [CMS]. It MAY also be further enveloped by id- 227 envelopedData [CMS]. Other layers MAY also be used. The following object 228 identifier identifies the gkaRequest content-type: 230 id-ct-gkaRequest OBJECT IDENTIFIER ::= { TBD } 232 The gkaRequest content type MUST have ASN.1 type GKARequest: 234 GKARequest ::= SEQUENCE { 235 gkaRequestVersion GKARequestVersion, 236 gkAAction GKAAction, 237 transactionId TransactionId OPTIONAL} 239 GKAResquestVersion ::= INTEGER { v0(0) } 241 GKAAction ::= CHOICE { 242 createGL [0] GLInformation, 243 deleteGL [1] GLInformation, 244 addGLMembers [2] GLInformation, 245 deleteGLMembers [3] GLInformation, 246 rekeyGL [4] GLInformation } 248 GLInformation ::= SEQUENCE { 249 glName GeneralName, 250 glIdentifier [0] OCTET STRING OPTIONAL, 251 glMembers [1] SEQUENCE OF GLMember OPTIONAL, 252 glOwner [2] GLOwner OPTIONAL, 253 effectiveDate [3] EffectiveDate OPTIONAL, 254 distributionDate [4] GeneralizedTime OPTIONAL } 256 GLMember ::= SEQUENCE { 257 OPTIONAL,name GeneralName, 258 deliveryMethod [0] SEQUENCE OF DeliveryMethod OPTIONAL } 259 certificates [1] CertificateSet OPTIONAL, 260 crls [2] CertificateRevocationListsOPTIONAL } 262 DeliveryMethod ::= CHOICE { 263 rfc822Name [0] IA5String, 264 x400Address [1] ORAddress, 265 directoryName [2] Name, 266 uniformResourceIdentifier [3] IA5String, 267 iPAddress [4] OCTET STRING } 269 CertificateSet ::= SET OF CertificateChoices 271 CertificateChoices ::= CHOICE { 272 certificate Certificate, -- See X.509 273 extendedCertificate [0] IMPLICIT ExtendedCertificate, 274 -- Obsolete 275 attrCert [1] IMPLICIT AttributeCertificate } 276 -- See X.509 and X9.57 278 CertificateRevocationLists ::= SET OF CertificateList 280 GLOwner ::= SEQUENCE { 281 name GeneralName, 282 administered BOOLEAN DEFAULT FALSE OPTIONAL } 284 EffectiveDate ::= SEQUENCE { 285 notBefore [0] GeneralizedTime, 286 notAfter [1] GeneralizedTime OPTIONAL } 288 TransactionId ::= OCTET STRING 290 The fields in GKSResponse have the following meaning: 292 Note: The support requirement for the fields is determined by the action 293 being performed; therefore, the support requirements are indicated in 294 paragraphs 3.1.1.3 through 3.1.1.7, where the specific actions are 295 defined. 297 - version is the syntax version number. The version number MUST be 0. 299 - gkaAction indicates the action that the GL Owner requests the GMA 300 perform, thatthe GL Owner requests the KMA perform, or the GMA requests 301 the KMA perform. The GL Owner MAY request that either the KMA or GMA 302 create a GL (createGL), delete a GL (deleteGL), add a member to a 303 specific GL (addGLMembers), delete a member of a specific GL 304 (deleteGLMember), or rekey a GL (rekeyGL). When the GL Owner requests 305 the actions of the GMA the action MUST be forwarded to the KMA. The GMA 306 MAY request, on behalf of the GL members, that a member be added or 307 deleted, assuming the GL policy allows this function. All of the actions 308 have the same syntax (GLInformation). Different combinations of the 309 GLInformation are used to provide information necessary for the KMA or 310 GMA to perform its requested action. The field combinations are 311 discussed in 3.1.1.3 through 3.1.1.7, but fields in GLInformation have 312 the following meaning: 314 - glName is the name of the GL. 316 - glIdentifier is the GL identifier. The GL identifier identifies 317 the specific GL on the GMA (the GMA may support multiple GLs). It is 318 derived from the group key and is returned by the KMA. 320 - gkMembers is a collection of the member(s) that should be either 321 added or deleted from the GL. The member's name is a GeneralName. 322 deliveryMethod identifies the method by which and address or location to 323 which the KMA should distribute the group key. Only one choice for each 324 of the type is allowed (i.e., only one rfc822Name may appear for a given 325 member). certificates and crls are the member's certificate, associated 326 certificates, and associated certificate revocation lists (CRLs). 328 - glOwner is the owner of the GL. It identifies the entity that 329 controls the GL. It also indicates whether the GL is managed or 330 unmanaged. 332 - effectiveDate indicates the dates that the GL Owner wants the KMA 333 to set the gkNotBefore and gkNotAfter to (see paragraph 3.1.2). The 334 notBefore date indicates the date the GL Owner wants the key to become 335 effective and the notAfter indicates the date the GL Owner wants the key 336 to become invalid. 338 - distributionDate indicates the date that the GL Owner wants the 339 key distributed. 341 - transactionID supports the recipient of a response message to 342 correlate this with a previously issued request. For example, in the 343 case of a GMA, which supports multiple GLs, there may be many requests 344 "outstanding" at a given moment. 346 3.1.1.2 Response To Group Key Administration 348 Upon receipt of the gkaRequest content-type the KMA MUST use the 349 gkaResponse content-type to indicate the success or failure of the 350 request. The gkaResponse is not sent until after the KMA has determined 351 whether the member is able to receive the key. The KMA may not be able 352 to send the member a group key because either the deliveryMethod is 353 unsupported or the member's certificate is invalid. The id-gkaRequest 354 content-tye MUST be processed according to [CMS]. The KMA MUST validate 355 the member's certificate and associated certificates to the KMA trusted 356 CA according to [PROFILE] prior to sending a gkaResponse message 357 indicating success. The gkaResponse message MUST be protected at a 358 minimum by id-signedData [CMS]. Other layers MAY also be used. The 359 following object identifier identifies the gkaRequest content type: 361 id-ct-gkaResponse OBJECT IDENTIFIER ::= { TBD } 363 The gkaResponse content type MUST have ASN.1 type GKAResponse: 365 GKAResponse ::= SEQUENCE { 366 gkaResponseVersion GKAResponseVersion, 367 success BOOLEAN DEFAULT TRUE, 368 glIdentifier OCTET STRING OPTIONAL, 369 errorCode ErrorCode OPTIONAL, 370 transactionId TransactionId OPTIONAL, 371 supportDeliveryMethods DeliveryMethod OPTIONAL} 373 ErrorCode ::= INTEGER { 374 unspecified (0), 375 -- Unspecified indicates that the KMA is unable to 376 -- distribute a group key to the member, but the KMA is 377 -- unwilling to indicate why. 378 managedGL (1) 379 -- Indicates that members can only be added or deleted by the GL 380 -- Owner. It is sent back to the requestor if the entity requesting 381 -- an addition is not the GL Owner. 382 effectiveDateTooLong (2) 383 -- Returned if the KMA does not support generating keys that are 384 -- valid for the entire requested effective dates. 385 unsupportedDeliveryMethod (3), 386 -- Unsupported delivery method indicates that the KMA does 387 -- not support any of the requested delivery methods. 388 invalidCert (4), 389 -- Certificate for member was not verifiable (i.e., signature 390 -- did not validate, certificate present on a CRL, etc.) 391 } 393 GKAResponseVersion ::= INTEGER { v0(0) } 395 The fields in GKAResponse have the following meaning: 397 - version is the syntax version number. It MUST be 0. 399 - success indicates whether the KMA is able to send a group key to the 400 member. If the KMA is unable to distribute the group key to the member, 401 it MUST indicate an errorCode. 403 - glIdentifier indicate the GL identifier, derived from the group key. 405 - errorCode indicates the reason why the KMA was unable to distribute 406 a group key to the member. Reasons include unspecified, managedGL, 407 effectiveDateTooLong, unsupportedDeliveryMethod, and invalidCert. 409 - transactionID supports the recipient of a response message to 410 correlate this with a previously issued request. For example, in the 411 case of a GMA, which supports multiple GLs, there may be many requests 412 "outstanding" at a given moment. 414 - supportedDeliveryMethod MAY be included the indicate the delivery 415 methods the KMA supports. 417 3.1.1.3 Create Group 419 Prior to generating a group key, a GL MUST be setup. The GL Owner is 420 responsible for creating the GL (1 in Figure 3). The GL Owner MAY use a 421 proprietary mechanism (e.g., listserv or majordomo) or the group key 422 administration mechanism defined in the paragraph below to perform this 423 function. 425 +----------+ 2,4{3} 426 | GL Owner | <-----+ 427 +----------+ | 428 1 | 429 +-----+ 2{1} 3 +-----+ <-----+ 430 | KMA | <-------> | GMA | 431 +-----+ +-----+ 433 Figure 3 - Create Group List 435 If the GL Owner decides to use the gkaRequest content-type to setup the 436 GL on the GMA, the gkaRequest content-type MUST be submitted to the GMA 437 (1 in Figure 2) with the gkaAction.createGL CHOICE. The format for the 438 createGL CHOICE is as follows: 440 - glName MUST be included to indicate the name of the GL. The value 441 must be unique for a given distribution method. 443 - glIdentifier MUST be omitted as the value is derived from the group 444 key, which is not yet created. 446 - glMembers MAY be included to indicate the member(s) to be added. If 447 members are included the name of the member MUST be include in 448 GLMember.name. The delivery method MAY be included. If the GMA does not 449 support the requested delivery method an error MUST be returned. The 450 members certificates and crls MAY also be included. 452 - glOwner.name MUST be included to indicate the Owner of the GL. The 453 GL Owner is the only entity allowed to delete the GL (see paragraph 454 3.1.1.4). If the list is to be managed (i.e., only allow the GL Owner 455 to add or delete GL members) glOwner.administered MUST be set to TRUE; 456 otherwise, the list is considered to be unmanaged. The GMA MUST only 457 allow additions (see paragraph 3.1.1.5) to the GL if one of the glOwner 458 names matches one of the names associated with one of the certificates 459 used to sign the id-signedData. 461 - effectiveDate MAY be included to indicate the dates the GL Owner 462 wishes the key to become effective. If this field is omitted the GMA 463 assumes the gkNotBefore date (see paragraph 3.1.2) is the GMA's current 464 date. 466 - distributionDate MAY be included to indicate the date the GL Owner 467 wishes the key to be distributed. If the distributitionDate is omitted 468 the GMA assumes the group key should be distributed immediately. 470 The GMA then forwards the gkaRequest content-type to the KMA (2{1} in 471 Figure 3). An additional id-signedData or some other combination of id- 472 signedData and id-envelopedData MAY protect the forwarded content-type. 474 Upon receipt of the gkaRequest content-type, the KMA verifies the 475 gkaRequest content-type and returns a gkaResponse (3 in Figure 3). If 476 the GL can be created as requested, the KMA MUST return a gkaResponse to 477 the GMA indicating success and the glIdentifier of the newly created 478 list. If the GL can not be created as requested the KMA returns a 479 gkaResponse to the GMA indicating failure along with an errorCode. 481 If there are members included in the gkaRequest the KMA MUST use the 482 mechanism described in paragraph 3.2 to distribute the group key. 484 The GMA then forwards the gkaResponse content-type to the GL Owner (4{3} 485 in Figure 3). An additional id-signedData or some other combination of 486 id-signedData and id-envelopedData MAY protect the forwarded conent- 487 type. 489 3.1.1.4 Delete Group 491 To delete a GL (1 in Figure 4), the GL Owner MAY use a proprietary 492 mechanim (e.g., listserv or majordomo) or the group key administration 493 mechanism defined in the paragraph below to perform this function. Only 494 the GL Owner can request that a GL be deleted. 496 +----------+ 2,4{3} 497 | GL Owner | <-----+ 498 +----------+ | 499 1 | 500 +-----+ 2{1} 3 +-----+ <-----+ 501 | KMA | <-------> | GMA | 502 +-----+ +-----+ 504 Figure 4 - Delete Group List 506 If the GL Owner decides to use the gkaRequest content-type to delete the 507 GL, the gkaRequest content-type MUST be submitted to the GMA (1 in 508 Figure 2) with the gkaAction.deleteGL CHOICE. The format for the 509 deleteGL CHOICE is as follows: 511 - glName MUST be included to indicate the name of the GL to be 512 deleted. 514 - glIdentifier MUST be included to indicate the identifier of the GL 515 to be deleted. 517 - glMembers MUST be omitted. 519 - glOwner MUST be included to indicate the name of the GL Owner. 520 administered MUST be omitted. The name in this field MUST match one of 521 the names in one of the certificates used in content-type used to create 522 the group. 524 - effectiveDate MUST be omitted. 526 - distributionDate MUST be omitted. 528 The GMA MUST not accept further requests from users (in the case of 529 unadministered GLs) to be added or deleted from the GL. The GMA MUST 530 forward the gkaRequest to the KMA. 532 Upon receipt of the gkaRequest content-type, the KMA verifies the 533 gkaRequest content-type and returns a gkaResponse (3 in Figure 3) 534 indicating success and the glIdentifier of the deleted GL. errorCode and 535 supportedDeliveryMethods MUST be omitted. 537 The GMA then forwards the gkaResponse content-type to the GL Owner (4{3} 538 in Figure 3). An additional id-signedData or some other combination of 539 id-signedData and id-envelopedData MAY protect the forwarded conent- 540 type. 542 3.1.1.5 Add Group Members 544 GL setup indicates whether the GL is to be managed or unmanaged. In the 545 managed case, the GL Owner is the only entity allowed to request member 546 additions to the GL. In the unmanaged case, anyone can request to be 547 added to the GL. Figure 4 depicts the protocol interactions for the two 548 options. 550 +----------+ 7{6} 2,9{8b} +----------+ 8a 551 | GL Owner | <-+ +-------> | Member 1 | <--+ 552 +----------+ | | +----------+ | 553 1a | | | 554 +-----+ 4{1a},5 6,8b +-----+ <--+ | 2,9{8b} +----------+ 8a | 555 | KMA | <----------> | GMA | 1b,3 +-------> | ... | <--+ 556 +-----+ +-----+ <-------------+ +----------+ | 557 | | | 558 | | 2,9{8b} +----------+ 8a | 559 | +-------> | Member n | <--+ 560 | +----------+ | 561 +-----------------------------------------------------------------+ 563 Figure 4 - Member Addition 565 A decision that needs to be made on a group by group basis is whether to 566 rekey the group every time a new member is added. Typically, unmanaged 567 GLs should not be rekeyed when a new member is added, as the overhead 568 associated with rekeying the group becomes prohibitive as the group 569 becomes large. However, managed GLs may be rekeyed depending on group 570 policy. An option to rekeying the managed GLs when a member is added is 571 to generate a new GL with a different group key. 573 3.1.1.5.1 Managed GLs 575 The GL Owner MAY use a proprietary mechanism (e.g., listserv or 576 majordomo) or the group key administration mechanism defined below to 577 add new members to the GL. 579 If the GL Owner decides to use the gkaRequest content-type MUST be 580 submitted to the GMA (1a in Figure 4) with the gkaAction.addGLMembers 581 CHOICE. The format for the addGLMembers CHOICE is as follows: 583 - glName MUST be included to indicate the name of the GL. 585 - glIdentifier MUST be included to indicate the GK that should be 586 distributed to the new member. 588 - glMembers MUST be included to indicate the member(s) to be added. 589 The member(s) name(s) is included in GLMember.name. The delivery method 590 MAY be included. The members certificates and crls MAY also be included. 592 - glOwner.name MUST be included to indicate the Owner of the GL. It 593 MUST match the name one of the certificates used to sign this gkaRequest 594 creating the GL. 596 - effectiveDate MUST be omitted. The value has no meaning as the group 597 key has been previously setup. 599 - distributionDate MAY be included to indicate the date the GL Owner 600 wishes the key to be distributed to the new member(s). If the 601 distributitionDate is omitted the KMA assumes the group key should be 602 distributed immediately. 604 Upon receipt of the gkaRequest, the GMA MAY process the glMembers and 605 add the member(s) for the GL stored on the GMA. The GMA then forwards 606 the gkaRequest content-type to the KMA (4{1a} in Figure 4). An 607 additional id-signedData or some other combination of id-signedData and 608 id-envelopedData MAY protect the forwarded content-type. 610 Upon receipt of the gkaRequest content-type, the KMA verifies the 611 gkaRequest content-type and returns a gkaResponse (6 in Figure 4). If 612 the member can be added, the KMA MUST return a gkaResponse to the GMA 613 indicating success and the glIdentifier of the GL the member was added 614 to. If the member can not be added the KMA MUST return a gkaResponse to 615 the GMA indicating failure along with an errorCode indicating either 616 unsupportedDeliveryMethod or invalidCert. The supportDeliveryMethods MAY 617 also be included to assist the GL Owner in determining whether some 618 other delivery method could be used to distribute the key to the new 619 member. 621 The KMA also distributes the group key via the mechanism described in 622 paragraph 3.2. The KMA also distributes the group key via the mechanism 623 described in paragraph 3.1.3. The group key is either distributed 624 through the GMA (8b and 9{8b} in Figure 4) or directly to the members 625 (8a in Figure 4). 627 The GMA then forwards the gkaResponse content-type to the GL Owner (7{6} 628 in Figure 4). An additional id-signedData or some other combination of 629 id-signedData and id-envelopedData MAY protect the forwarded conent- 630 type. 632 3.1.1.5.2 Unmanaged GLs 634 For automated scenarios, members send a message (1b in Figure 4), which 635 MAY be unprotected (i.e., unsigned and unencrypted) or protected via id- 636 signedData, id-envelopedData, or tripled wrapped (i.e., signed and/or 637 encrypted) [CMS]. If the message is protected with id-envelopedData the 638 GMA MUST be one of the recipients. A confirmation message (2 in Figure 639 4) MAY be sent back to the member requesting confirmation of the initial 640 request to inhibit spamming (i.e., to avoid someone other than the 641 member requested the member be added to the list). The response to the 642 confirmation message (3 in Figure 4) indicates whether the member really 643 requested addition to the GL. The format for these messages indicated by 644 1b, 2, and 3 in Figure 4 are beyond the scope of this document. 646 The GMA MAY support generating a gkaRequest content-type to request 647 members be added. If the GMA supports generating the gkaRequest content- 648 type, it MUST be submitted to the KMA (5 in Figure 4) with the 649 gkaAction.addGLMembers CHOICE. The format for the addGLMembers CHOICE is 650 as follows 652 - glName MUST be included to indicate the name of the GL. 654 - glIdentifier MUST be included to indicate the GK that should be 655 distributed to the new member. 657 - glMembers MUST be included to indicate the member(s) to be added. 658 The member(s) name(s) is included in GLMember.name. The delivery method 659 MAY be included. The member's certificates and crls MAY also be 660 included. 662 - glOwner.name MUST be omitted. 664 - effectiveDate MUST be omitted. 666 - distributionDate MUST be omitted. 668 Upon receipt of the gkaRequest content-type, the KMA verifies the 669 gkaRequest content-type and returns a gkaResponse (6 in Figure 4). If 670 the member can be added, the KMA MUST return a gkaResponse to the GMA 671 indicating success and the glIdentifier of the GL the member was added 672 to. If the member can not be added the KMA MUST return a gkaResponse to 673 the GMA indicating failure along with an errorCode indicating 674 unspecified, managedGL, unsupportedDeliveryMethod, or invalidCert. The 675 supportDeliveryMethods MAY also be included to assist the GMA in 676 determining whether some other delivery method could be used to 677 distribute the key to the new member. 679 The KMA also distributes the group key via the mechanism described in 680 paragraph 3.2. The group key is either distributed through the GMA (8b 681 and 9{8b} in Figure 4) or directly to the members (8a in Figure 4). 683 3.1.1.6 Delete Group Members 685 GL setup indicates whether the GL is to be managed or unmanaged. In the 686 managed case, the GL Owner is the only entity allowed to request member 687 deletions to the GL. In the unmanaged case, anyone can request to be 688 removed from the GL. Figure 5 depicts the protocol interactions for the 689 two options. 691 +----------+ 7{6} 692 | GL Owner | <-+ 693 +----------+ | 694 1a | 695 +-----+ 4{1a},5 6,8b +-----+ <--+ +----------+ 696 | KMA | <----------> | GMA | 1b,3 2 | Member X | 697 +-----+ | | <----------------> +----------+ 698 | | | 9{8b},8a 699 | +-----+ ------+----------> +----------+ 700 | | | Member 1 | 701 | | +----------+ 702 +-------------------------------+ 703 | 9{8b},8a +----------+ 704 +----------> | Member n | 705 +----------+ 707 Figure 5 - Member Deletion 709 If the member is not removed from the GL, they will continue to be able 710 to receive and decrypt data protected with the group key and will 711 continue to receive group rekeys. Steps should be taken to ensure a new 712 group key is used (see paragraph 3.1.3). For unmanaged lists, there is 713 no point to a group rekey because there is no guarantee that the member 714 requesting to be removed hasn't already added themselves back on the 715 list under a different name. For managed GLs, the GL Owner must take 716 steps to ensure the member being deleted is not on the list twice. After 717 ensuring this, the managed GL MUST be rekeyed to maintain the secrecy of 718 the group. If the GL Owner is sure the member has been deleted the group 719 rekey mechanism MAY be used to distribute the new key (see paragraph 720 3.1.1.7). 722 3.1.1.6.1 Managed GLs 724 The GL Owner MAY use a proprietary mechanism (e.g., listserv or 725 majordomo) or the group key administration mechanism defined below to 726 delete members from the GL. 728 If the GL Owner decides to use the gkaRequest content-type MUST be 729 submitted to the GMA (1a in Figure 4) with the gkaAction.addGLMembers 730 CHOICE. The format for the addGLMembers CHOICE is as follows: 732 - glName MUST be included to indicate the name of the GL. 734 - glIdentifier MUST be included to indicate the GK that should be 735 distributed to the new member. 737 - glMembers MUST be included to indicate the member(s) to be deleted. 738 The member(s) name(s) is included in GLMember.name. The delivery method 739 MUST be omitted. The members certificates and crls MUST also be omitted. 741 - glOwner.name MUST be included to indicate the Owner of the GL. It 742 MUST match the name one of the certificates used to sign this 743 gkaRequest. 745 - effectiveDate MUST be omitted. The value has no meaning as the group 746 key has been previously setup. 748 - distributionDate MUST be omitted. 750 Upon receipt of the gkaRequest, the GMA MAY process the glMembers and 751 remove the member for the GL stored on the GMA. The GMA then forwards 752 the gkaRequest content-type to the KMA (4{1a} in Figure 5). An 753 additional id-signedData or some other combination of id-signedData and 754 id-envelopedData MAY protect the forwarded content-type. 756 Upon receipt of the gkaRequest content-type, the KMA verifies the 757 gkaRequest content-type and returns a gkaResponse (6 in Figure 4). The 758 KMA MUST return a gkaResponse to the GMA indicating success and the 759 glIdentifier of the GL the member was deleted from. 761 The GMA then forwards the gkaResponse back to the GL Owner (7{6} in 762 Figure 5). An additional id-signedData or some other combination of id- 763 signedData and id-envelopedData MAY protect the forwarded conent-type. 765 The KMA MUST also use the group key distribution mechanism defined in 766 paragraph 3.1.3 to provide the remaining members with a new group key. 768 3.1.1.6.2 Unmanaged GLs 770 For automated scenarios, members send a message (1b in Figure 4), which 771 MAY be unprotected (i.e., unsigned and unencrypted) or protected via id- 772 signedData, id-envelopedData, or tripled wrapped (i.e., signed and/or 773 encrypted) [CMS]. If the message is protected with id-envelopedData the 774 GMA MUST be one of the recipients. A confirmation message (2 in Figure 775 4) MAY be sent back to the member requesting confirmation of the initial 776 request to inhibit spamming (i.e., to avoid someone other than the 777 member requested the member be added to the list). The response to the 778 confirmation message (3 in Figure 4) indicates whether the member really 779 requested addition to the GL. The format for these messages indicated by 780 1b, 2, and 3 in Figure 4 are beyond the scope of this document. 782 The GMA MAY support generating a gkaRequest content-type to request 783 members be deleted. If the GMA supports generating the gkaRequest 784 content-type, it MUST be submitted to the KMA (5 in Figure 5) with the 785 gkaAction.addGLMembers CHOICE. The format for the addGLMembers CHOICE is 786 as follows 788 - glName MUST be included to indicate the name of the GL. 790 - glIdentifier MUST be included to indicate the GL the member should 791 be removed from. 793 - glMembers MUST be included to indicate the member(s) to be deleted. 794 The member(s) name(s) is included in GLMember.name. The deliveryMethod 795 MUST be omitted. The member's certificates and crls MUST also be 796 omitted. 798 - glOwner.name MUST be omitted. 800 - effectiveDate MUST be omitted. 802 - distributionDate MUST be omitted. 804 Upon receipt of the gkaRequest content-type, the KMA verifies the 805 gkaRequest content-type and returns a gkaResponse (6 in Figure 5). KMA 806 MUST return a gkaResponse to the GMA indicating success and the 807 glIdentifier of the GL the member was deleted from. 809 GL Policy will determine whether the GL is to be rekeyed. 811 3.1.1.7 Rekey Group 813 Situations arise where the GL needs a new key (i.e., group rekey). An 814 out of bands means, automatic rekeys by the KMA, or the mechanisms 815 defined below MAY be used to initiate a group rekey. Only the GL Owner 816 or KMA are allowed to initiate a group rekey. 818 +----------+ 4{3} 6{5b} +----------+ 5a 819 | GL Owner | <---+ +-------> | Member 1 | <--+ 820 +----------+ | | +----------+ | 821 1 | | | 822 +-----+ 2{1} 3,5b +-----+ <----+ | 6{5b} +----------+ 5a | 823 | KMA | <--------> | GMA | ----------------+-------> | ... | <--+ 824 +-----+ +-----+ | +----------+ | 825 | | | 826 | | 6{5b} +----------+ 5a | 827 | +-------> | Member n | <--+ 828 | +----------+ | 829 +-----------------------------------------------------------------+ 831 Figure 6 - Group Rekey 833 The GL Owner MAY generate a gkaRequest content-type and submitted it to 834 the GMA (1 in Figure 6) with the gkaAction.rekeyGL CHOICE. The format 835 for the rekeyGL CHOICE is as follows: 837 - glName MUST be included to indicate the name of the GL. 839 - glIdentifier MUST be included to indicate the GK that should be 840 rekeyed. 842 - glMembers MUST be omitted. 844 - glOwner.name MUST be included to indicate the Owner of the GL. It 845 MUST match the name one of the certificates used to sign this gkaRequest 846 and match one of the names in the certificates used to sign the 847 gkaRequest that created the GL. 849 - effectiveDate MAY be included to indicate the dates the GL Owner 850 wishes the new group key to become effective. If this field is omitted 851 the GMA assumes the gkNotBefore date (see paragraph 3.1.2) is the GMA's 852 current date. 854 - distributionDate MAY be included to indicate the date the GL Owner 855 wishes the key to be distributed. If the distributitionDate is omitted 856 the GMA assumes the group key should be distributed immediately. This 857 date MAY overlap with the existing effectiveDate to ensure 858 prepositioning the new group key before the old group key becomes 859 invalid. 861 The GMA then forwards the gkaRequest content-type to the KMA (2{1} in 862 Figure 3). An additional id-signedData or some other combination of id- 863 signedData and id-envelopedData MAY protect the forwarded content-type. 865 Upon receipt of the gkaRequest content-type, the KMA verifies the 866 gkaRequest content-type and returns a gkaResponse (3 in Figure 3). If 867 the GL can be rekeyed as requested, the KMA MUST return a gkaResponse to 868 the GMA indicating success and the glIdentifier of the new group key. If 869 the group key can not be rekeyed as requested the KMA returns a 870 gkaResponse to the GMA indicating failure along with an errorCode. 872 The GMA then forwards the gkaResponse content-type to the GL Owner (4{3} 873 in Figure 3). An additional id-signedData or some other combination of 874 id-signedData and id-envelopedData MAY protect the forwarded conent- 875 type. 877 The KMA also generates the group rekey MUST distribute the new group 878 through the mechanism described in paragraph 3.3. 880 3.2 Group Key Distribution 882 The KMA MUST support the initial distribution of the group key. It MAY 883 perform this distribution via an out of bands means, a repository, a 884 mail message, or some other means. The gkDistribution content-type is 885 defined to support electronic means of distributing the group key. If 886 the gkDistribution method is used, it MUST be protected in id- 887 envelopedData [CMS]. The gkDistribution content-type MUST be protected 888 on a per-recipient basis using the ktri RecipientInfo CHOICE. The kari 889 RecipientInfo choice MAY be used to protect the message for members. A 890 further id-signedData MAY also be applied. The KMA MAY send the 891 gkDistribution content-type either: 893 - Directly to each of the members (5a in Figure 6). 895 Note: The following option requires that the KMA be allowed to submit to 896 the GL. 898 - Through the GMA (6b an 6{5b} in Figure 6). If this option is used, 899 the KMA MAY apply an additional id-envelopedData and other layers (6 in 900 Figure 2) to protect the enveloped gkDistribution content-type for the 901 GMA. The GMA then distributes the inner most id-envelopedData to the 902 list based. The GMA MAY also apply a signature to the distributed id- 903 envelopedData. 905 The following object identifier identifies the gksDistribution content 906 type: 908 id-ct-gkDistribution OBJECT IDENTIFIER ::= { TBD } 910 The gkDistribution content type MUST have ASN.1 type GKDistribution: 912 GKDistribution :: = SEQUENCE { 913 version GKDistributionVersion, 914 glIdentifier OCTET STRING, 915 gk OCTET STRING, 916 gkNotBefore GeneralizedTime, 917 gkNotAfter GeneralizedTime } 919 [ST - I think we need to put in some kind of information about the 920 algorithm the key must be used for.] 922 GKDistributionVersion ::= INTEGER { v0(0) } 924 The fields in GKSDistribution have the following meaning: 926 - version is the syntax version number. It MUST be 0. 928 - glIdentifier is the GL identifier. The GL identifier identifies the 929 specific GL on the GMA (the GMA may support multiple GLs). Members use 930 the glIdentifier to choose the key to needed to decrypt an envelopedData 931 with the RecipientInfo.kekri.kekid.keyIdentifer. Two common methods for 932 generating key identifiers from the group key are: 934 (1) The keyIdentifier is composed of the 160-bit SHA-1 hash of the 935 value of the BIT STRING gk (excluding the tag, 936 length, and number of unused bits). 938 (2) The keyIdentifier is composed of a four bit type field with 939 the value 0100 followed by the least significant 60 bits of the 940 SHA-1 hash of the value of the BIT STRING gk. 942 - gk is the group key. 944 - gkNotBefore indicates the date at which the key is considered valid. 946 - gkNotAfter indicates the date at which the key is considered 947 invalid. 949 Members must support processing the id-envelopedData according to [CMS]. 951 3.3 Group Rekey Distribution 953 To support group rekey messages, three mechanisms are defined: 955 - Use the mechanism described in paragraph 3.1.3 (1a(5a in Figure 5)6) 956 to redistribute the key (i.e., generate a per-recipient token using the 957 ktri or kari RecipientInfoin the id-envelopedData encapsulating the 958 gkDistribution content-type). This may entail significant processing 959 compared with the other options below. 961 Note: The following two options require that the KMA be allowed to 962 submit the GMA. 964 - Generate id-encryptedData with the ktri orRecipientInfo choice kari 965 RecipientInfo choicewith the associated GMA(s) as the recipient(s) 966 (1b(5b in Figure 5)6) encapsulating a id-signedData (signed by the KMA) 967 which in turn encapsualtes an id-envelopedData with the kekri 968 RecipientInfo choice (includes the gkDistribution content-type). The GMA 969 then strips off the two outer layers andthen sends the inner most id- 970 envelopedData to the GL members. The GMA identifies the GL to which the 971 gkDistribution content-type should be submitted to 972 bytheKEKIdentifier.keyIdentifier. The GMA(s) MAY apply a new 973 encapsulating id-signedData. id-signedData. The KMA MAY use the kari 974 RecipientInfo choice to encapsulate the id-signedData (signed by the 975 KMA) which in turn encapsulates an id-envelopedData with the kekru 976 RecipientInfo choice (includes the gkDistribution content-type). 978 - Generate an id-envelopedData (includes the gkDistribution content- 979 type) with the kekri RecipientInfo choice for the GL and submit it to 980 the GMA. The id-envelopedData MAY have other layers (e.g., an id- 981 signedData) applied to it. The GMA identifies the GL to which the 982 gkDistributionthen distributes this content-type should be submitted to 983 by the KEKIdentifier.keyIdentifier.id-envelopedData to the GL. The GMA 984 MAY apply additional layers (e.g., an id-signedData) to the id- 985 envelopedData. 987 In all cases, the KMA MUST assign a new glIdentifier, use a new group 988 key in gk, and a new gkNotBefore and gkNotAfter dates. The old 989 gkNotAfter and new gkNotBefore MUST overlap by some configurable time, 990 T. T allows for the time required to distribute the new group key to 991 each of the GL members. If T is less than 0, then GL members may be 992 unable to use the group key to encrypt messages. 994 [The above case is only for entirely new keys to be distributed. Need to 995 add something in here about how to indicate that a new key, which is 996 derived from the old key, should be used.] 998 4 Key Wrapping 1000 In the mechanisms described in paragraphs 3.2 and 3.3, the group key 1001 being distributed, in an id-envelopedData, MUST be protected by a key of 1002 equal or greater length (i.e., if a RC2 128-bit key is being distributed 1003 a key of 128-bits or greater must be used to protect the key). 1005 5 Algorithms 1007 Triple-DES is mandatory other are optional. 1009 6. Using the Group Key 1011 [Put in here how this can be used with SMIME MLAs.] 1013 7. Schema Requirements 1015 [I think we need to specify some MAYs for support of object classes, 1016 etc. to support location of the GL and GL Owner in a repository. There 1017 are really two choices for the GL mhsDistributionList from RFC 1274 and 1018 addresslist from an Internet-Draft in the LDAPEXT WG. The only reason I 1019 can think of not using the one from RFC 1274 is that a MUST CONTAIN is 1020 mhsORAddress and we're should support SMTP. addressList (in the ID) 1021 doesn't have mhsORAddress as a must contain. The Owner in the both 1022 object classes though has the syntax directoryName. We might have to 1023 roll attribute for the Owner because I think it should probably have the 1024 GeneralName syntax instead of just directoryName.] 1026 [We can also define attributes that can be used to store the group key 1027 encrypted for an individual group member and for the encrypted object. 1028 Does anyone think this is useful/needed?] 1030 8. Acknowledgements 1032 Thanks to Russ Housley for providing much of the background and review 1033 required to write this draft. 1035 9. References 1037 [CMS] R. Housley, "Cryptographic Message Syntax," RFC 2630, June 1999. 1039 [ESS] P. Hoffman, "Enhanced Security Services for S/MIME," RFC 2534, 1040 June 1999. 1042 [PROFILE] Housley, R., Ford, W., Polk, W., and Solo, D., "Internet X.509 1043 Public Key Infrastructure Certificate and CRL Profile," RFC 2459, 1044 January 1999. 1046 10. Security Considerations 1048 TBSL 1050 [ Need to talk about the consequences of a compromised group KEK. ] 1052 11. Patents 1054 I don't hold any (on this or any other topic) does anyone know of any? 1056 12. Editor's Address 1058 Sean Turner IECA, Inc. 9010 Edgepark Road Vienna, VA 22182 Phone: (703) 1059 628-3180 E-Mail: turners@ieca.com 1061 Annex A - ASN.1 Module 1063 TBSL