SMIME Working Group S. Turner Internet Draft IECA Document: draft-ietf-smime-symkeydist-03.txt March 2, 2001 Expires: September 2, 2001 S/MIME Symmetric Key Distribution Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [1]. This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This draft is being discussed on the 'ietf-smime' mailing list. To subscribe, send a message to ietf-smime-request@imc.org with the single word subscribe in the body of the message. There is a Web site for the mailing list at . Abstract This document describes a mechanism to manage (i.e., setup, distribute, and rekey) keys used with symmetric cryptographic algorithms. Also defined herein is a mechanism to organize users into groups to support distribution of encrypted content using symmetric cryptographic algorithms. The mechanism uses the Cryptographic Message Syntax (CMS) protocol [2] and Certificate Management Message over CMS (CMC) protocol [3] to manage the symmetric keys. Any member of the group can then later use this distributed shared key to decrypt other CMS encrypted objects with the symmetric key. This mechanism has been developed to support S/MIME Mail List Agents (MLAs). Turner 1 Internet-Draft S/MIME Symmetric Key Distribution March 2,2001 Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [4]. 1. INTRODUCTION....................................................3 1.1 APPLICABILITY TO E-MAIL........................................4 1.2 APPLICABILITY TO REPOSITORIES..................................4 2. ARCHITECTURE....................................................5 3. PROTOCOL INTERACTIONS...........................................6 3.1 CONTROL ATTRIBUTES.............................................7 3.1.1 GL USE KEK...................................................8 3.1.2 DELETE GL...................................................11 3.1.3 ADD GL MEMBER...............................................11 3.1.4 DELETE GL MEMBER............................................12 3.1.5 REKEY GL....................................................13 3.1.6 ADD GL OWNER................................................14 3.1.7 REMOVE GL OWNER.............................................14 3.1.8 GL KEY COMPROMISE...........................................14 3.1.9 GL KEY REFRESH..............................................15 3.1.10 GL SUCCESS INFORMATION.....................................15 3.1.11 GL FAIL INFORMATION........................................16 3.1.12 GLA QUERY REQUEST..........................................18 3.1.13 GLA QUERY RESPONSE.........................................18 3.1.14 PROVIDE CERT...............................................19 3.1.15 UPDATE CERT................................................20 3.1.16 GL KEY.....................................................21 3.2 USE OF CMC, CMS, AND PKIX.....................................22 3.2.1 PROTECTION LAYERS...........................................22 3.2.1.1 MINIMUM PROTECTION........................................23 3.2.1.2 ADDITIONAL PROTECTION.....................................23 3.2.2 COMBINING REQUESTS AND RESPONSES............................23 3.2.3 GLA GENERATED MESSAGES......................................25 3.2.4 CMC CONTROL ATTRIBUTES......................................26 3.2.5 RESUBMITTED GL MEMBER MESSAGES..............................27 3.2.6 PKIX........................................................28 4 ADMINISTRATIVE MESSAGES.........................................28 4.1 ASSIGN KEK TO GL..............................................28 4.2 DELETE GL FROM GLA............................................31 4.3 ADD MEMBERS TO GL.............................................33 4.3.1 GLO INITIATED ADDITIONS.....................................34 4.3.2 PROSPECTIVE MEMBER INITIATED ADDITIONS......................40 4.4 DELETE MEMBERS FROM GL........................................42 4.4.1 GLO INITIATED DELETIONS.....................................43 4.4.2 MEMBER INITIATED DELETIONS..................................47 4.5 REQUEST REKEY OF GL...........................................48 4.5.1 GLO INITIATED REKEY REQUESTS................................49 4.5.2 GLA INITIATED REKEY REQUESTS................................51 4.6 CHANGE GLO....................................................52 4.7 INDICATE KEK COMPROMISE.......................................54 4.7.1 GL MEMBER INITIATED KEK COMPROMISE MESSAGE..................55 Turner 2 Internet-Draft S/MIME Symmetric Key Distribution March 2,2001 4.7.2 GLO INITIATED KEK COMPROMISE MESSAGE........................56 4.8 REQUEST KEK REFRESH...........................................57 4.9 GLA QUERY REQUEST AND RESPONSE................................58 4.10 UPDATE MEMBER CERTIFICATE....................................60 4.10.1 GLO AND GLA INITIATED UPDATE MEMBER CERTIFICATE............60 4.10.2 GL MEMBER INITIATED UPDATE MEMBER CERTIFICATE..............62 5 DISTRIBUTION MESSAGE............................................63 5.1 DISTRIBUTION PROCESS..........................................64 6 ALGORITHMS......................................................64 6.1 KEK GENERATION ALGORITHM......................................65 6.2 SHARED KEK WRAP ALGORITHM.....................................65 6.3 SHARED KEK ALGORITHM..........................................65 7 TRANSPORT.......................................................65 8 USING THE GROUP KEY.............................................65 9 SECURITY CONSIDERATIONS.........................................66 10 REFERENCES.....................................................66 11 ACKNOWLEDGEMENTS...............................................66 12 AUTHOR'S ADDRESSES.............................................67 1. Introduction With the ever-expanding use of secure electronic communications (e.g., S/MIME [2]), users require a mechanism to distribute encrypted data to multiple recipients (i.e., a group of users). There are essentially two ways to encrypt the data for recipients: using asymmetric algorithms with public key certificates (PKCs) or symmetric algorithms with symmetric keys. With asymmetric algorithms, the originator forms an originator- determined content-encryption key (CEK) and encrypts the content, using a symmetric algorithm. Then, using an asymmetric algorithm and the recipient's PKCs, the originator generates per-recipient information that either (a) encrypts the CEK for a particular recipient (ktri ReipientInfo CHOICE), or (b) transfers sufficient parameters to enable a particular recipient to independently generate the same KEK (kari RecipientInfo CHOICE). If the group is large, the amount of per-recipient information required may take quite some time to generate, not to mention the time required to collect and validate the PKCs for each of the recipients. Each recipient identifies their per-recipient information and uses the private key associated with the public key of their PKC to decrypt the CEK and hence gain access to the encrypted content. With symmetric algorithms, the origination process is the same as with asymmetric algorithms except for what encrypts the CEK. Instead of using PKCs, the originator uses a previously distributed secret key-encryption key (KEK) to encrypt the CEK (kekri RecipientInfo CHOICE). Only one copy of the encrypted CEK is required because all the recipients already have the shared KEK needed to decrypt the CEK and hence gain access to the encrypted content. Turner 3 Internet-Draft S/MIME Symmetric Key Distribution March 2,2001 The security provided by the shared KEK is only as good as the sum of the techniques employed by each member of the group to keep the KEK secret from nonmembers. These techniques are beyond the scope of this document. Only the members of the list and the key manager should have the KEK in order to maintain the secrecy of the group. Access control to the information protected by the KEK is determined by the entity that encrypts the information, as all members of the group have access. If the entity that is performing the encryption wants to ensure some subset of the group does not gain access to the information either a different KEK should be used (shared with this smaller group) or asymmetric algorithms should be used. 1.1 Applicability to E-mail One primary audience for this distribution mechanism is e-mail. Distribution lists sometimes referred to as mail lists, have been defined to support distribution of messages to recipients subscribed to the mail list. There are two models for how the mail list can be used. If the originator is a member of the mail list, the originator sends messages encrypted with the shared KEK to the mail list (e.g., listserv or majordomo) and the message is distributed to the mail list members. If the originator is not a member of the mail list (does not have the shared KEK), the originator sends the message (encrypted for the MLA) to the mail list agent (MLA) and the MLA then forms the shared KEK needed to encrypt the message. In either case the recipients of the mail list use the previously distributed- shared KEK to decrypt the message. 1.2 Applicability to Repositories Objects can also be distributed via a repository (e.g., Light Weight Directory Protocol (LDAP) servers, X.500 Directory System Agents (DSAs), Web-based servers). If an object is stored in a repository encrypted with a symmetric key algorithm, any one with the shared KEK and access to that object can then decrypt that object. The encrypted object and the encrypted, shared KEK can be stored in the repository. Turner 4 Internet-Draft S/MIME Symmetric Key Distribution March 2,2001 2. Architecture Figure 1 depicts the architecture to support symmetric key distribution. The Group List Agent (GLA) supports two distinct functions with two different agents: - The Key Management Agent (KMA) which is responsible for generating the shared KEKs. - The Group Management Agent (GMA) which is responsible for managing the Group List (GL) to which the shared KEKs are distributed. +----------------------------------------------+ | Group List Agent | +-------+ | +------------+ + -----------------------+ | | Group | | | Key | | Group Management Agent | |<-->| List | | | Management |<-->| +------------+ | | | Owner | | | Agent | | | Group List | | | +-------+ | +------------+ | +------------+ | | | | / | \ | | | +------------------------+ | +----------------------------------------------+ / | \ +----------+ +---------+ +----------+ | Member 1 | | ... | | Member n | +----------+ +---------+ +----------+ Figure 1 - Key Distribution Architecture A GLA may support multiple KMAs. A GLA in general supports only one GMA, but the GMA may support multiple GLs. Multiple KMAs may support a GMA in the same fashion as GLAs support multiple KMAs. Assigning a particular KMA to a GL is beyond the scope of this document. Modeling real world GL implementations shows that there are very restrictive GLs, where a human determines GL membership, and very open GLs, where there are no restrictions on GL membership. To support this spectrum, the mechanism described herein supports both managed (i.e., where access control is applied) and unmanaged (i.e., where no access control is applied) GLs. The access control mechanism for managed lists is beyond the scope of this document. In either case, the GL must initially be constructed by an entity hereafter called the Group List Owner (GLO). There may be multiple entities who 'own' the GL and who are allowed to make changes the GLĘs properties or membership. The GLO determines if the GL will be managed or unmanaged and is the only entity that may delete the GL. GLO(s) may or may not be GL members. Turner 5 Internet-Draft S/MIME Symmetric Key Distribution March 2,2001 Though Figure 1 depicts the GLA as encompassing both the KMA and GMA functions, the two functions could be supported by the same entity or they could be supported by two different entities. If two entities are used, they could be located on one or two platforms. There is however a close relationship between the KMA and GMA functions. If the GMA stores all information pertaining to the GLs and the KMA merely generates keys, a corrupted GMA could cause havoc. To protect against a corrupted GMA, the KMA would be forced to double check the requests it receives to ensure the GMA did not tamper with them. These duplicative checks blur the functionality of the two components together. For this reason, the interactions between the KMA and GMA are beyond the scope of this document. Proprietary mechanisms may be used to separate the functions by strengthening the trust relationship between the two entities. Henceforth, the distinction between the two agents is omitted; the term GLA will be used to address both functions. It should be noted that corrupt GLA can always cause havoc. 3. Protocol Interactions There are existing mechanisms (e.g., listserv and majordomo) to support managing GLs; however, this document does not address securing these mechanisms, as they are not standardized. Instead, it defines protocol interactions, as depicted in Figure 2, used by the GL members, GLA, and GLO to manage GLs and distribute shared KEKs. The interactions have been divided into administration messages and distribution messages. The administrative messages are the request and response messages needed to setup the GL, delete the GL, add members to the GL, delete members of the GL, and request a group rekey, etc. The distribution messages are the messages that distribute the shared KEKs. The following sections describe the ASN.1 for both the administration and distribution messages. Section 4 describes how to use the administration messages and section 5 describes how to use the distribution messages. +-----+ +----------+ | GLO | <---+ +----> | Member 1 | +-----+ | | +----------+ | | +-----+ <------+ | +----------+ | GLA | <-------------+----> | ... | +-----+ | +----------+ | | +----------+ +----> | Member n | +----------+ Figure 2 - Protocol Interactions Turner 6 Internet-Draft S/MIME Symmetric Key Distribution March 2,2001 3.1 Control Attributes The messages are based on including control attributes in CMC's PKIData for requests and CMC's ResponseBody0 for responses. The content-types PKIData and PKIResponse are then encapsulated in CMS's SignedData or EnvelopedData, or a combination of the two (see section 3.2). The following are the control attributes defined in this document: Control Attribute OID Syntax ------------------- ----------- ----------------- glUseKEK id-skd 1 GLUseKEK glDelete id-skd 2 GeneralName glAddMember id-skd 3 GLAddMember glDeleteMember id-skd 4 GLDeleteMember glRekey id-skd 5 GLRekey glAddOwner id-skd 6 GLOwnerAdministration glRemoveOwner id-skd 7 GLOwnerAdministration glkCompromise id-skd 8 GeneralName glkRefresh id-skd 9 GLKRefresh glSuccessInfo id-skd 10 GLSuccessInfo glFailInfo id-skd 11 GLFailInfo glaQueryRequest id-skd 12 GLAQueryRequest glaQueryResponse id-skd 13 GLAQueryResponse glProvideCert id-skd 14 GLManageCert glUpdateCert id-skd 15 GLManageCert glKey id-skd 16 GLKey In the following conformance tables, the column headings have the following meanings: O for originate, R for receive, F for forward. There are three types of implementations: GLOs, GLAs, and GL members. The GLO is an optional component hence all of the messages for it are optional and the GLO forwarding messages to it or the GL member. The first table includes messages that MUST be implemented in order to be considered conformant to this document. The second table includes messages that MAY be implemented in order to be considered conformant to this document. Turner 7 Internet-Draft S/MIME Symmetric Key Distribution March 2,2001 Required Implementation Requirement | Control GLO | GLA | GL Member | Attribute O R |O R F | O R | -------- |------------------ |--------- |---------- MAY - |MUST - MAY | - MUST |glProvideCert MAY MAY | - MUST MAY | MUST - |glUpdateCert - - |MUST - - | - MUST |glKey - MAY |MUST - - | - MUST |glSucessInfo - MAY |MUST - - | - MUST |glFailInfo Optional Implementation Requirement | Control GLO | GLA | GL Member | Attribute O R |O R F | O R | -------- |------------------ |--------- |---------- MAY - | - MAY - | - - |glUseKEK MAY - | - MAY - | - - |glDelete MAY MAY | - MUST MAY | MUST - |glAddMember MAY MAY | - MUST MAY | MUST - |glDeleteMember MAY - | - MAY - | - - |glRekey MAY - | - MAY - | - - |glAddOwner MAY - | - MAY - | - - |glRemoveOwner MAY MAY | - MUST MAY | MUST - |glkCompromise MAY - | - MUST - | MUST - |glkRefresh MAY - | - SHOULD - | MAY - |glaQueryRequest - MAY |SHOULD - - | - MAY |glaQueryResponse glSuccessInfo, glFailInfo, glaQueryResponse, and gloResponse are responses and go into the PKIResponse content-type, all other control attributes are included in requests and go into the PKIData content-type. The exception is glUpdateCert which may be included in either PKIData or PKIResponse. 3.1.1 GL USE KEK The GLO uses glUseKEK to request that a shared KEK be assigned to a GL. glUseKEK messages MUST be signed by the GLO. The glUseKEK control attribute shall have the syntax GLUseKEK: GLUseKEK ::= SEQUENCE { glInfo GLInfo, glOwnerInfo SEQUENCE SIZE (1..MAX) OF GLOwnerInfo, glAdministration GLAdministration DEFAULT (1), glKeyAttributes GLKeyAttributes OPTIONAL } Turner 8 Internet-Draft S/MIME Symmetric Key Distribution March 2,2001 GLInfo ::= SEQUENCE { glName GeneralName, glAddress GeneralName } GLOwnerInfo ::= SEQUENCE { glOwnerName GeneralName, glOwnerAddress GeneralName } GLAdministration ::= INTEGER { unmanaged (0), managed (1), closed (2) } GLKeyAttributes ::= SEQUENCE { rekeyControlledByGLO [0] BOOLEAN DEFAULT FALSE, recipientsNotMutuallyAware [1] BOOLEAN DEFAULT TRUE, duration [2] INTEGER DEAULT (0), generationCounter [3] INTEGER DEFAULT (2), requestedAlgorithm [4] AlgorithmIdentifier DEFAULT (id-alg-CMS3DESwrap) } The fields in GLUseKEK have the following meaning: - glInfo indicates the GLĘs name in glName and the GLĘs address in glAddress. In some instances the glName and glAddress may be the same, but this is not always the case. Both the name and address MUST be unique for a given GLA. - glOwnerInfo indicates the GL ownerĘs name in glOwnerName and the GL ownerĘs address in glOwnerAddress. One of the names in glOwnerName MUST match one of the names in the certificate used to sign this SignedData.PKIData creating the GL (i.e., the immediate signer). - glAdministration indicates how the GL should be administered. The default is for the list to be managed. Three values are supported for glAdministration: - Unmanaged - When the GLO sets glAdministration to unmanaged, they are allowing prospective members to request being added and deleted from the GL without GLO intervention. - Managed - When the GLO sets glAdministration to managed, they are allowing prospective members to request being added to and deleted from the GL, but the request is redirected by the GLA to GLO for review. The GLO makes the determination as to whether to honor the request. - Closed - When the GLO sets glAdministration to closed, they are not allowing prospective members to request being added to or deleted from the GL. The GLA will only accept glAddMember Turner 9 Internet-Draft S/MIME Symmetric Key Distribution March 2,2001 and glDeleteMember requests from the GLO. It is GL policy as to whether to forward the request on to the GLO. - glKeyAttributes indicates the attributes the GLO wants the GLA to assign to the shared KEK. If this field is omitted, GL rekeys will be controlled by the GLA, the recipients are allowed to know about one another, the algorithm will Triple-DES (see paragrpah 7), the shared KEK will be valid for a calendar month (i.e., first of the month until the last day of the month), and two shared KEKs will be distributed initially. The fields in glKeyAttributes have the following meaning: - rekeyControlledByGLO indicates whether the GL rekey messages will be generated by the GLO or by the GLA. The default is for the GLA to control rekeys. If GL rekey is controlled by the GLA, the GL will continue to be rekeyed until the GLO deletes the GL or changes the GL rekey to be GLO controlled. - recipientsNotMutuallyAware indicates that the GLO wants the GLA to distribute the shared KEK individually for each of the GL members (i.e., a separate glKey message is sent to each recipient). The default is for separate glKey message to not be required. NOTE: This supports lists where one member does not know the identities of the other members. For example, a list is configured granting submit permissions to only one member. All other members are 'listening.' The security policy of the list does not allow the members to know who else is on the list. If a glKey is constructed for all of the GL members, information about each of the members may be derived from the information in RecipientInfos. To make sure the glkey message does not divulge information about the other recipients, a separate glKey message would be sent to each GL member. - duration indicates the length of time (in days) during which the shared KEK is considered valid. The value zero (0) indicates that the shared KEK is valid for a calendar month at UTC Zulu time zone. For example if the duration is zero (0), if the GL shared KEK is requested on July 24, the first key will be valid until the end of July and the next key will be valid for the entire month of August. If the value is not zero (0), the shared KEK will be valid for the number of days indicated by the value. For example, if the value of duration is seven (7) and the shared KEK is requested on Monday but not generated until Tuesday (2359); the shared KEKs will be valid from Tuesday (2359) to Tuesday (2359). The exact time of the day is determined when the key is generated. - generationCounter indicates the number of keys the GLO wants the GLA to distribute. To ensure uninterrupted function of the GL two (2) shared KEKs at a minimum MUST be initially Turner 10 Internet-Draft S/MIME Symmetric Key Distribution March 2,2001 distributed. The second shared KEK is distributed with the first shared KEK, so that when the first shared KEK is no longer valid the second key can be used. If the GLA controls rekey then it also indicates the number of shared KEKs the GLO wants outstanding at any one time. See sections 4.5 and 5 for more on rekey. - requestedAlgorithm indicates the algorithm and any parameters the GLO wants the GLA to use with the shared KEK. The parameters are conveyed via the SMIMECapabilities attribute see MSG {x}. See section 7 for more on algorithms. 3.1.2 Delete GL GLOs use glDelete to request that a GL be deleted from the GLA. The glDelete control attribute shall have the syntax GeneralName. The name of the GL to be deleted is included in GeneralName. The glDelete message MUST be signed by the GLO. 3.1.3 Add GL Member GLOs use glAddMember to request addition of new members and prospective GL members use glAddMember to request being added to the GL. The glAddMember message must be signed by either the GLO or the prospective GL member. The glAddMember control attribute shall have the syntax GLAddMember: GLAddMember ::= SEQUENCE { glName GeneralName, glMember GLMember } GLMember ::= SEQUENCE { glMemberName GeneralName, glMemberAddress GeneralName OPTIONAL, certificates Certificates OPTIONAL } Certificates ::= SEQUENCE { pKC Certificate OPTIONAL, -- See X.509 aC SEQUENCE SIZE (1.. MAX) OF AttributeCertificate OPTIONAL, -- See X.509 certificationPath CertificateSet OPTIONAL } -- From CMS [2] CertificateSet ::= SET SIZE (1..MAX) OF CertificateChoices Turner 11 Internet-Draft S/MIME Symmetric Key Distribution March 2,2001 CertificateChoices ::= CHOICE { certificate Certificate, -- See X.509 extendedCertificate [0] IMPLICIT ExtendedCertificate, -- Obsolete attrCert [1] IMPLICIT AttributeCertificate } -- See X.509 and X9.57 The fields in GLAddMembers have the following meaning: - glName indicates the name of the GL to which the member should be added. - glMember indicates the particulars for the GL member. Both of the following fields must be unique for a given GL: - glMemberName indicates the name of the GL member. - glMemberAddress indicates the GL memberĘs address. It MUST be included. Note: In some instances the glMemberName and glMemberAddress may be the same, but this is not always the case. - certificates MUST be included. It contains the following three fields: - certificates.pKC includes the member's encryption certificate that will be used to at least initially encrypt the shared KEK for that member. If the message is generated by a prospective GL member, the pKC MUST be included. If the message is generated by a GLO, the pKC SHOULD be included. - certificates.aC MAY be included to convey any attribute certificate associated with the memberĘs encryption certificate. - certificates.certificationPath MAY also be included to convey the certification path corresponding to the member's encryption and any non-member attribute certificates are placed in attrCert. The certification path is optional because it may already be included elsewhere in the message (e.g., in the outer CMS layer). 3.1.4 Delete GL Member GLOs use glDeleteMember to request deletion of GL members and GL members use glDeleteMember to request being removed from the GL. The glDeleteMember message must be signed by either the GLO or the Turner 12 Internet-Draft S/MIME Symmetric Key Distribution March 2,2001 prospective GL member. The glDeleteMember control attribute shall have the syntax GLDeleteMember: GLDeleteMember ::= SEQUENCE { glName GeneralName, glMemberToDelete GeneralName } The fields in GLDeleteMembers have the following meaning: - glName indicates the name of the GL from which the member should be removed. - glMemberToDelete indicates the name of the member to be deleted. 3.1.5 Rekey GL GLOs use the glRekey to request a GL rekey. The glRekey message MUST be signed by the GLO. The glRekey control attribute shall have the syntax GLRekey: GLRekey ::= SEQUENCE { glName GeneralName, glAdministration GLAdministration OPTIONAL, glNewKeyAttributes GLNewKeyAttributes OPTIONAL, glRekeyAllGLKeys BOOLEAN OPTIONAL } GLNewKeyAttributes ::= SEQUENCE { rekeyControlledByGLO [0] BOOLEAN OPTIONAL, recipientsNotMutuallyAware [1] BOOLEAN OPTIONAL, duration [2] INTEGER OPTIONAL, generationCounter [3] INTEGER OPTIONAL, requestedAlgorithm [4] AlgorithmIdentifier OPTIONAL } The fields in GLRekey have the following meaning: - glName indicates the name of the GL to be rekeyed. - glAdministration indicates if there is any change to how the GL should be administered. See section 3.1.1 for the three options. This field is only included if there is a change from the previously registered administered. - glNewKeyAttributes indicates whether the rekey of the GLO is controlled by the GLA or GL, what algorithm and parameters the GLO wishes to use, the duration of the key, and how many outstanding keys should be issued. The field is only included if there is a change from the previously registered glKeyAttributes. Turner 13 Internet-Draft S/MIME Symmetric Key Distribution March 2,2001 - glRekeyAllGLKeys indicates whether the GLO wants all of the outstanding GLĘs shared KEKs rekeyed. If it is set to TRUE then all outstanding KEKs MUST be issued. If it is set to FALSE then all outstanding KEKs need not be resissued. 3.1.6 Add GL Owner GLOs use the glAddOwner to request that a new GLO be allowed to administer the GL. The glAddOwner message MUST be signed a registered GLO. The glAddOwner control attribute shall have the syntax GLOwnerAdministration: GLOwnerAdministration ::= SEQUENCE { glName GeneralName, glOwnerInfo GLOwnerInfo } The fields in GLAddOwners have the following meaning: - glName indicates the name of the GL to which the new GLO should be associated. - glOwnerInfo indicates the name and address of the new GLO. 3.1.7 Remove GL Owner GLOs use the glRemoveOwner to request that a GLO be disassociated with the GL. The glRemoveOwner message MUST be signed by a registered GLO. The glRemoveOwner control attribute shall have the syntax GLOwnerAdministration: GLOwnerAdministration ::= SEQUENCE { glName GeneralName, glOwnerInfo GLOwnerInfo } The fields in GLRemoveOwners have the following meaning: - glName indicates the name of the GL to which the GLO should be disassociated. - glOwnerInfo indicates the name and address of the GLO to be removed. 3.1.8 GL Key Compromise GL members and GLOs use glkCompromise to indicate that the shared KEK possessed has been compromised. The glKeyCompromise control attribute shall have the syntax GeneralName. The name of the GL to which the compromised key is associated with is included in GeneralName. This message is always redirected by the GLA to the GLO Turner 14 Internet-Draft S/MIME Symmetric Key Distribution March 2,2001 for further action. The glkCompromise MUST NOT be included in an EnvelopedData generated with the compromised shared KEK. 3.1.9 GL Key Refresh GL members use the glkRefresh to request that the shared KEK be redistributed to them. The glkRefresh control attribute shall have the syntax GLKRefresh. GLKRefresh ::= { glName GeneralName, dates SEQUENCE (1..MAX) OF Date } Date ::= { start GeneralizedTime, end GeneralizedTime OPTIONAL } The fields in GLKRefresh have the following meaning: - glName indicates the name of the GL for which the GL member wants shared KEKs. - dates indicates a date range for keys the GL member wants. The start field indicates the first date the GL member wants and the end field indicates the last date. The end date MAY be omitted to indicate the GL member wants all keys from the specified start date to the current date. It should be noted that a procedural mechanism will be needed to restrict users from accessing messages that they are not allowed to access. 3.1.10 GL Success Information The GLA uses glSuccessInfo to indicate a successful result of an administrative message. A separate glSuccessInfo is returned for each action (e.g., if there are four successful glAddMember requests then four glSuccessInfo responses are generated). The glSuccessInfo message MUST be signed by the GLA. The glSucessInfo control attribute shall have the syntax GLSucessInfo: GLSuccessInfo ::= SEQUENCE { glInfo GLInfo, glIdentifier GLIdentifier, action Action } Action ::= SEQUENCE { actionCode ActionCode, glMemberName [0] GeneralName OPTIONAL, glOwnerName [1] GeneralName OPTIONAL } Turner 15 Internet-Draft S/MIME Symmetric Key Distribution March 2,2001 ActionCode ::= INTEGER { assignedKEK (0), deletedGL (1), addedMember (2), deletedMember (3), rekeyedGL (4), addedGLO (5), removedGLO (6) } The fields in GLSuccessInfo have the following meaning: - glInfo indicates the GLĘs name in glName and the GLĘs address in glAddress. - glIdentifier identifies GLĘs unique shared KEK. - action indicates the successfully performed action. action.actionCode indicates whether the shared KEK was assigned to the GL, whether the GL was deleted, whether a member was added to a GL, whether a member was deleted from a GL, whether the GL was rekeyed, whether a new GLO was added, and whether a GLO was removed. If members were added to a GL or deleted from a GL the members MUST be indicated in glMemberName and glOwnerName MUST be omitted. If a GLO was added to a GL or deleted from a GL, the GLO MUST be indicated in glOwnerName and glMemberName MUST be omitted. If a shared KEK was assigned to a GL or a GL was deleted both glOwnerName and glMemberName MUST be omitted. 3.1.11 GL Fail Information The GLA uses glFailInfo to indicate that there was a problem performing a requested action. A separate glFailInfo is returned for each action (e.g., if there are four denied glAddMember requests then four glFailInfo responses are generated). The glFailInfo message MUST be signed by the GLA. The glFailInfo control attribute shall have the syntax GLFailInfo: GLFailInfo ::= SEQUENCE { glName GeneralName, error Error } Error ::= SEQUENCE { errorCode ErrorCode, glMemberName [0] GeneralName OPTIONAL, glOwnerName [1] GeneralName OPTIONAL } Turner 16 Internet-Draft S/MIME Symmetric Key Distribution March 2,2001 ErrorCode ::= INTEGER { unspecified (0), closedGL (1) unsupportedDuration (2) noGLACertificate (3), invalidCert (4), unsupportedAlgorithm (5), noGLONameMatch (6), invalidGLName (7), nameAlreadyInUse (8), noSpam (9), deniedAccess (10), alreadyAMember (11), notAMember (12), alreadyAnOwner (13) notAnOwner (14) } The fields in GLFailInfo have the following meaning: - glName indicates the name of the GL to which the error corresponds. - error indicates the reason why the GLA was unable to perform the request. It also indicates the GL member or GLO to which the error corresponds. If members were not added to a GL or deleted from a GL the members MUST be indicated in glMemberName. If a GLO was not added to a GL or deleted from a GL, the GLO MUST be indicated in glOwnerName. The errors are returned under the following conditions: - unspecified indicates that the GLA is unable or unwilling to perform the requested action and does not want to indicate why. - closedGL indicates that members can only be added or deleted by the GLO. - unsupportedDuration indicates the GLA does not support generating keys that are valid for the requested duration. - noGLACertificate indicates that the GLA does not have a valid certificate. - invalidCert indicates the member's encryption certificate was not verifiable (i.e., signature did not validate, certificateĘs serial number present on a CRL, etc.). - unsupportedAlgorithm indicates the GLA does not support the requested algorithm. Turner 17 Internet-Draft S/MIME Symmetric Key Distribution March 2,2001 - noGLONameMatch indicates that one of the names in the certificate used to sign a request does not match the name of a registered GLO. - invalidGLName indicates the GLA does not support the glName present in the request. - nameAlreadyInUse indicates the glName is already assigned on the GLA. - noSpam indicates the prospective GL member did not sign the request (i.e., if the name in glMember.glMemberName does not match one of the names in the certificate used to sign the request). - alreadyAMember indicates the prospective GL member is already a GL member. - notAMember indicates the prospective non-GL member is not a GL member. - alreadyAnOwner indicates the prospective GLO is already a GLO. - notAnOwner indicates the prospective non-GLO is not a GLO. 3.1.12 GLA Query Request GLOs and GL members use the glaQueryRequest to ascertain information about the GLA. The glaQueryRequest control attribute shall have the syntax GLAQueryRequest: GLAQueryRequest ::= SEQUENCE { glaRequestType OBJECT IDENTIFIER, glaRequestValue ANY DEFINED BY glaResponseType } One request type is defined herein to support the GLO in determining the algorithms supported by the GLA: id-rt-algorithmSupported { id-tbd } There is no value defined for id-rt-algorithmSupported. Including the id-rt-algorithmSupport indicates that the GLO wishes to know the algorithms that the GLA supports. 3.1.13 GLA Query Response GLAĘs return the glaQueryResponse after receiving a GLAQueryRequest. The glaQueryResponse MUST be signed by a GLA. The glaQueryResponse control attribute shall have the syntax GLAQueryResponse: Turner 18 Internet-Draft S/MIME Symmetric Key Distribution March 2,2001 GLAQueryResponse ::= SEQUENCE { glaResponseType OBJECT IDENTIFIER, glaResponseValue ANY DEFINED BY glaResponseType } One response type is defined herein for the GLA to indicate the algorithms it supports: smimeCapabilities OBJECT IDENTIFIER ::= {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 15} -- Identifies the algorithms supported by the GLA (see MsgSpec [5]) 3.1.14 Provide Cert GLAs and GLOs use glProvideCert to request that a GL member provide an updated or new encryption certificate. The glProvideCert message MUST be signed by either GLA or GLO. If the GL memberĘs PKC has been revoked, the GLO or GLA MUST NOT use it to generate the EnvelopedData that encapsulates the glProvideCert request. The glProvideCert control attribute shall have the syntax GLManageCert: GLManageCert ::= SEQUENCE { glName GeneralName, glMember GLMember } The fields in GLManageCert have the following meaning: - glName indicates the name of the GL to which the GL memberĘs new certificate should be associated. - glMember indicates particulars for the GL member: - glMemberName indicates the GL memberĘs name. - glMemberAddress indicates the GL memberĘs address. It MAY be omitted. - certificates SHOULD be omitted. Turner 19 Internet-Draft S/MIME Symmetric Key Distribution March 2,2001 3.1.15 Update Cert GL members and GLOs use glUpdateCert to provide a new certificate for the GL. GL members may generate a glUpdateCert unsolicited or as a result of a glProvideCert message. GL members MUST sign the glUpdateCert. If the GL memberĘs encryption certificate has been revoked, the GL member MUST NOT use it to generate the EnvelopedData that encapsulates the glUpdateCert request or response. The glUpdateCert control attribute shall have the syntax GLManageCert: GLManageCert ::= SEQUENCE { glName GeneralName, glMember GLMember } The fields in GLManageCert have the following meaning: - glName indicates the name of the GL to which the GL memberĘs new certificate should be associated. - glMember indicates the particulars for the GL member: - glMemberName indicates the GL memberĘs name - glMemberAddress indicates the GL memberĘs address. It MAY be omitted. - certificates MAY be omitted if the GLManageCert message is sent to request the GL members certificate; else it MUST be included. It includes the following three fields: - certificates.pKC includes the member's encryption certificate that will be used to encrypt the shared KEK for that member. - certificates.aC MAY be included to convey any attribute certificate associated with the memberĘs encryption certificate. - certificates.certificationPath MAY also be included to convey the certification path corresponding to the member's encryption and attribute certificates. The certification path is optional because it may already be included elsewhere in the message (e.g., in the outer CMS layer). Turner 20 Internet-Draft S/MIME Symmetric Key Distribution March 2,2001 3.1.16 GL Key The GLA uses glKey to distribute the shared KEK. The glKey message MUST be signed by the GLA. The glKey control attribute shall have the syntax GLKey: GLKey ::= SEQUENCE { glName GeneralName, glIdentifier OCTET STRING, glkWrapped RecipientInfos, -- See CMS [2] glkAlgorithm AlgorithmIdentifier, glkNotBefore GeneralizedTime, glkNotAfter GeneralizedTime } The fields in GLKey have the following meaning: - glName is the name of the GL. - glIdentifier is the key identifier of the shared KEK. When GL members use the shared KEK to encrypt data objects for other GL members, they place the glIdentifier in RecipientInfo.kekri.kekid.keyIdentifier field. There are many ways to do this here are two options are provided to generate a unique key identifier. The first choice concatenates the GLAĘs subject name from the digital signature certificate used to sign the glKey message and counter. The second choice concatenates the GLAĘs subjectKeyIdentifier, from the digital signature certificate used to sign the glKey message, and a counter. - glkWrapped is the GL's wrapped shared KEK. The RecipientInfos shall be generated as specified in section 6.2 of CMS [2]. The ktri RecipientInfo choice MUST be supported. The key in the EncryptedKey field (i.e., the distributed shared KEK) MUST be generated according to the section concerning random number generation in the security considerations of CMS [2]. - glkAlgorithm identifies the algorithm the shared KEK is used with. The parameters are conveyed via the SMIMECapabilities attribute see MSG {x}. - glkNotBefore indicates the date at which the shared KEK is considered valid. GeneralizedTime values MUST be expressed UTC (Zulu) and MUST include seconds (i.e., times are YYYYMMDDHHMMSSZ), even where the number of seconds is zero. GeneralizedTime values MUST NOT include fractional seconds. - glkNotAfter indicates the date after which the shared KEK is considered invalid. GeneralizedTime values MUST be expressed UTC (Zulu) and MUST include seconds (i.e., times are YYYYMMDDHHMMSSZ), even where the number of seconds is zero. GeneralizedTime values MUST NOT include fractional seconds. Turner 21 Internet-Draft S/MIME Symmetric Key Distribution March 2,2001 If the glKey message is in response to a glUseKEK message: - The GLA MUST generate separate glKey messages for each recipient if glUseKEK.glKeyAttributes.recipientsNotMutuallyAware is set to FALSE. For each recipient you want to generate a message that contains that recipientĘs key (i.e., one message with one attribute). - The GLA MUST generate X number of glKey messages, where X is the value in glUseKEK.glKeyAttributes.generationCounter. If the glKey message is in response to a glRekey message: - The GLA MUST generate separate glKey messages for each recipient if glRekey.glNewKeyAttributes.recipientsNotMutuallyAware is set to FALSE. - The GLA MUST generate X number of glKey messages, where X is the value in glUseKEK.glKeyAttributes.generationCounter. - The GLA MUST generate X number of glKey messages, where X is the number of outstanding shared KEKs for the GL if glRekeyAllGLKeys is set to TRUE. If the glKey message was not in response to a glRekey or glUseKEK (e.g., where the GLA controls rekey): - The GLA MUST generate separate glKey messages for each recipient if glUseKEK.glNewKeyAttributes.recipientsNotMutuallyAware that set up the GL was set to FALSE. - The GLA MAY generate X glKey messages prior to the duration on the last outstanding shared KEK expiring, where X is the generationCounter minus one (1). Other distribution mechanisms may also be supported to support this functionality. 3.2 Use of CMC, CMS, and PKIX The following sections outline the use of CMC, CMS, and PKIX. 3.2.1 Protection Layers The following sections outline the protection required for the control attributes defined herein. Turner 22 Internet-Draft S/MIME Symmetric Key Distribution March 2,2001 3.2.1.1 Minimum Protection At a minimum, a SignedData MUST protect each request and response encapsulated in PKIData and PKIResponse. The following is a depiction of the minimum wrappings: Minimum Protection ------------------ SignedData PKIData or PKIResponse controlSequence Prior to taking any action on any request or response SignedData(s) MUST be processed according to CMS [2]. 3.2.1.2 Additional Protection An additional EnvelopedData MAY also be used to provide confidentiality of the request and response. An additional SignedData MAY also be added to provide authentication and integrity of the encapsulated EnvelopedData. The following is a depiction of the optional additional wrappings: Confidentiality Protection A&I of Confidentiality Protection -------------------------- --------------------------------- EnvelopedData SignedData SignedData EnvelopedData PKIData or PKIResponse SignedData controlSequence PKIData or PKIResponse controlSequence If an incoming message was encrypted, the confidentiality of the message MUST be preserved. All EnvelopedData objects MUST be processed as specified in CMS [2]. If the GLO or GL member applies confidentiality to a request, the EnvelopedData MUST be encrypted for the GLA. If the GLA is to forward the GL member request to the GLO, the GLA decrypts the EnvelopedData, strips the confidentiality layer off, and applies its own confidentiality layer for the GLO. 3.2.2 Combining Requests and Responses Multiple requests and response corresponding to a GL MAY be included in one PKIData.controlSequence or PKIResponse.controlSequence. Requests and responses for multiple GLs MAY be combined in one PKIData or PKIResponse by using PKIData.cmsSequence and PKIResponse.cmsSequence. A separate cmsSequence MUST be used for Turner 23 Internet-Draft S/MIME Symmetric Key Distribution March 2,2001 different GLs (i.e., requests corresponding to two different GLs are included in different cmsSequences). The following is a diagram depicting multiple requests and responses combined in one PKIData and PKIResponse: Multiple Request and Response Request Response ------- -------- SignedData SignedData PKIData PKIResponse cmsSequence cmsSequence SignedData SignedData PKIData PKIResponse controlSequence controlSequence One or more requests One or more responses corresponding to one GL. corresponding to one GL. SignedData SignedData PKIData PKIResponse controlSequence controlSequence One or more requests One or more responses corresponding to another GL. corresponding to another GL. When applying confidentiality to multiple requests and responses, all of the requests/response MAY be included in one EnvelopedData. The following is a depiction: Confidentiality of Multiple Requests and Responses Wrapped Together ---------------- EnvelopedData SignedData PKIData cmsSequence SignedData PKIResponse controlSequence Zero or more requests corresponding to one GL. SignedData PKIData controlSequence Zero or more requests corresponding to one GL. Turner 24 Internet-Draft S/MIME Symmetric Key Distribution March 2,2001 Certain combinations of requests in one PKIData.controlSequence and one PKIResponse.controlSequence are not allowed. The invalid combinations listed here MUST NOT be generated: Invalid Combinations --------------------------- glUseKEK & glDeleteMember glUseKEK & glRekey glUseKEK & glDelete glDelete & glAddMember glDelete & glDeleteMember glDelete & glRekey glDelete & glAddOwner glDelete & glRemoveOwner To avoid unnecessary errors, certain requests and responses should be processed prior to others. The following is the priority of message processing, if not listed it is an implementation decision as to which to process first: glUseKEK before glAddMember, glRekey before glAddMember, and glDeleteMember before glRekey. It should be noted that there is a priority but it does not imply an order. 3.2.3 GLA Generated Messages When the GLA generates a glSuccessInfo, it generates one for each request. action.actionCode values of assignedKEK, deletedGL, rekeyedGL, addedGLO, and deletedGLO are not returned to GL members. Likewise, when the GLA generates glFailInfo it generates one each request. error values of unsupportedDuration, unsupportedDeliveryMethod, unsupportedAlgorithm, noGLONameMatch, nameAlreadyInUse, alreadyAnOwner, notAnOwner are not returned to GL members. If GLKeyAttributes.recipientsNotMutuallyAware is set to FALSE, a separate PKIResponse.glSucessInfo, PKIResponse.glFailInfo, and PKIData.glKey MUST be generated for each recipient. It is valid to send one message with multiple attributes to the same recipient. If the GL has multiple GLOs, the GLA MUST send the glSuccessInfo and glFailInfo messages to the requesting GLO. The mechanism to determine which GLO made the request is beyond the scope of this document. Turner 25 Internet-Draft S/MIME Symmetric Key Distribution March 2,2001 If a GL is managed and the GLA receives a glAddMember, glDeleteMember, or glkCompromise message, the GLA redirects the request to the GLO for review. An additional, SignedData MUST be applied to the redirected request as follows: GLA Forwarded Requests ---------------------- SignedData PKIData cmsSequence PKIData controlSequence 3.2.4 CMC Control Attributes Certain control attributes defined in CMC [3] are allowed; they are as follows: cMCStatusInfo, transactionId, senderNonce, recipientNonce, and queryPending. cMCStatusInfo is used by GLAs to indicate to GLOs and GL members whether a request was or was not successfully completed. If the request was successful, the GLA returns a cMCStatusInfo response with cMCStatus.success and optionally other pertinent information in stutsString. If the response was not successful, the GLA returns a cMCStatusInfo response with cMCStatus.failed and optionally other pertinent information in statusString. When the GL is managed and the GLO has reviewed GL member initiated glAddMember, glDeleteMember, and glkComrpomise requests, the GLO uses cMCStatusInfo to indicate the success or failure of the request. If the request is allowed, cMCStatus.success is returned and statusString is optionally returned to convey additional information. If the request is denied, cMCStatus.failed is returned and statusString is optionally returned to convey additional information. cMCStatusInfo is used by GLOs, GLAs, and GL members to indicate that signature verification failed. If the signature failed to verify, the cMCStatusInfo control attribute MUST be returned indicating cMCStatus.failed and otherInfo.failInfo.badMessageCheck. If the signature over the outermost PKIData failed, the bodyList value is zero (0). If the signature over any other PKIData failed the bodyList value is the bodyPartId value from the request or response. cMCStatusInfo is also used by GLOs and GLAs to indicate that a request could not be performed immediately. If the request could not be processed immediately by the GLA or GLO, the cMCStatusInfo control attribute MUST be returned indicating cMCStatus.pending and otherInfo.pendInfo. When requests are redirected to the GLO for approval (for managed lists), the GLA MUST NOT return a cMCStatusInfo indicating query pending. Turner 26 Internet-Draft S/MIME Symmetric Key Distribution March 2,2001 cMCStatusInfo is also used by GLAs to indicate that a glaQueryRequest is not supported. If the glaQueryRequest is not supported, the cMCStatusInfo control attribute MUST be returned indicating cMCStatus.noSupport and statusString is optionally returned to convey additional information. transactionId MAY be included by GLOs, GLAs, or GL members to identify a given transaction. All subsequent requests and responses related to the original request MUST include the same transactionId control attribute. If GL members include a transactionId and the request is redirected to the GLO, the GLA MAY include an additional transactionId in the outer PKIData. If the GLA included an additional transactionId in the outer PKIData, when the GLO generates a cMCStatusInfo response it generates one for the GLA with the GLAĘs transactionId and one for the GL member with the GL memberĘs transactionId. The use of nonces (see section 5.6 of [3]) can be used to provide application-level replay prevention. If the originating message includes a senderNonce, the response to the message MUST include the received senderNonce value as the recipientNonce and a new value as a the senderNonce value in the response. If a GLA aggratates multiple messages together or forwards a message to a GLO, the GLA can optionally generate a new nonce value and include that in the wrapping message. When the response comes back from the GLO, the GLA builds a response to the originator(s) of the message(s) and deals with each of the nonce values from the originating messages. The following is the implementation requirement for the CMC control attributes: Implementation Requirement | Control GLO | GLA | GL Member |Attribute O R | O R F | O R | --------- | ----------------- |--------- | ---------- MUST MUST | MUST MUST - | MUSTMUST | cMCStatus MAY MAY | MAY MAY - | MAY MAY | transactionId MAY MAY | MAY MAY - | MAY MAY | senderNonce MAY MAY | MAY MAY - | MAY MAY | recepientNonce 3.2.5 Resubmitted GL Member Messages When the GL is managed, the GLA forwards the GL member requests to the GLO for GLO approval by creating a new request message containing the GL member request(s) as a cmsSequence item. If the GLO approves the request it can either add a new layer of wrapping and send it back to the GLA or create a new message sends it to the Turner 27 Internet-Draft S/MIME Symmetric Key Distribution March 2,2001 GLA. (Note in this case there are now 3 layers of PKIData messages with appropriate signing layers.) 3.2.6 PKIX Signatures, certificates, and CRLs are verified according to PKIX [6]. Name matching is performed according to PKIX [6]. All distinguished name forms must follow the UTF8String convention noted in PKIX [6]. A certificate per-GL would be issued to the GLA. GL policy may mandate that the GL memberĘs address be included in the GL memberĘs certificate. 4 Administrative Messages There are a number of administrative messages that must be performed to manage a GL. The following sections describe each of messages' request and response combinations in detail. The procedures defined in this section are not prescriptive. 4.1 Assign KEK To GL Prior to generating a group key, a GL MUST be setup and a shared KEK assigned to the GL. Figure 3 depicts the protocol interactions to setup and assign a shared KEK. Note that error messages are not depicted in Figure 3. +-----+ 1 2 +-----+ | GLA | <-------> | GLO | +-----+ +-----+ Figure 3 - Create Group List The process is as follows: 1 - The GLO is the entity responsible for requesting the creation of the GL. The GLO sends a SignedData.PKIData.controlSequence.glUseKEK request to the GLA (1 in Figure 3). The GLO MUST include: glName, glAddress, glOwnerName, glOwnerAddress, and glAdministration. The GLO MAY also include their preferences for the shared KEK in glKeyAttributes by indicating whether the GLO controls the rekey in rekeyControlledByGLO, whether separate glKey messages Turner 28 Internet-Draft S/MIME Symmetric Key Distribution March 2,2001 should be sent to each recipient in recipientsNotMutuallyAware, the requested algorithm to be used with the shared KEK in requestedAlgorithm, the duration of the shared KEK, and how many shared KEKs should be initially distributed in generationCounter. 1.a - If the GLO knows of members to be added to the GL, the glAddMember request(s) MAY be included in the same controlSequence as the glUseKEK request (see section 3.2.2). The GLO MUST indicate the same glName in the glAddMember request as in glUseKEK.glInfo.glName. Further glAddMember procedures are covered in section 4.3. 1.b - The GLO MAY optionally apply confidentiality to the request by encapsulating the SignedData.PKIData in an EnvelopedData (see section 3.2.1.2). 1.c - The GLO MAY also optionally apply another SignedData over the EnvelopedData (see section 3.2.1.2). 2 - Upon receipt of the request, the GLA verifies the signature on the inner most SignedData.PKIData. If an additional SignedData and/or EnvelopedData encapsulates the request (see sections 3.2.1.2 and 3.2.2), the GLA MUST verify the outer signature(s) and/or decrypt the outer layer(S) prior to verifying the signature on the inner most SignedData. 2.a - If the signatures do not verify, the GLA MUST return a cMCStatusInfo response indicating cMCStatus.failed and otherInfo.failInfo.badMessageCheck. 2.b ū Else if the signatures do verify but the GLA does not have a valid certificate, the GLA MUST return a glFailInfo.errorCode.noValidGLACertificate. Instead of immediately returning the error code, the GLA MAY attempt to get a certificate, possibly using CMC [3]. 2.c - Else the signatures do verify and the GLA does have a valid certificate, the GLA MUST check that one of the names in the certificate used to sign the request matches one of the names in glUseKEK.glOwnerInfo.glOwnerName. 2.c.1 - If the names do not match, the GLA MUST return a response indicating glFailInfo.errorCode.noGLONameMatch. Turner 29 Internet-Draft S/MIME Symmetric Key Distribution March 2,2001 2.c.2 - Else names do all match, the GLA MUST check that the glName and glAddress is not already in use. The GLA MUST also check any glAddMember included within the controlSequence with this glUseKEK. Further processing of the glAddMember is covered in section 4.3. 2.c.2.a - If the glName is already in use the GLA MUST return a response indicating glFailInfo.errorCode.nameAlreadyInUse. 2.c.2.b - Else the requestedAlgorithm is not supported, the GLA MUST return a response indicating glFailInfo.errorCode.unsupportedAlgorithm. 2.c.2.c - Else the duration is not supportable, determining this is beyond the scope of this document, the GLA MUST return a response indicating glFailInfo.errorCode.unsupportedDuration. 2.c.2.d - Else the GL is not supportable for other reasons, which the GLA does not wish to disclose, the GLA MUST return a response indicating glFailInfo.errorCode.unspecified. 2.c.2.e - Else the glName is not already in use, the duration is supportable, and the requestedAlgorithm is supported, the GLA MUST return a glSuccessInfo indicating the glName, the corresponding glIdentifier, and an action.actionCode.assignedKEK (2 in Figure 3). The GLA also takes administrative actions, which are beyond the scope of this document, to store the glName, glAddress, glKeyAttributes, glOwnerName, and glOwnerAddress. The GLA also sends a glKey message as described in section 5. 2.c.2.e.1 - The GLA MUST apply confidentiality to the response by encapsulating the SignedData.PKIResponse in an EnvelopedData if the request was encapsulated in an EnvelopedData (see section 3.2.1.2). 2.c.2.e.2 - The GLA MAY also optionally apply another SignedData over the EnvelopedData (see section 3.2.1.2). 3 - Upon receipt of the glSuccessInfo or glFailInfo responses, the GLO verifies the GLA's signature(s). If an additional SignedData and/or EnvelopedData encapsulates the response (see section 3.2.1.2 or 3.2.2), the GLO MUST verify the outer signature and/or decrypt the outer layer prior to verifying the signature on the inner most SignedData. 3.a - If the signatures do not verify, the GLO MUST return a cMCStatusInfo response indicating cMCStatus.failed and otherInfo.failInfo.badMessageCheck. Turner 30 Internet-Draft S/MIME Symmetric Key Distribution March 2,2001 3.b - Else the signatures do verify, the GLO MUST check that one of the names in the certificate used to sign the response matches the name of the GL. 3.b.1 ū If the GLĘs name does not match the name present in the certificate used to sign the message, the GLO should not believe the response. 3.b.2 ū Else the GLĘs name does match the name present in the certificate and: 3.b.2.a - If the signatures do verify and the response was glSuccessInfo, the GLO has successfully created the GL. 3.b.2.b - Else the signatures do verify and the response was glFailInfo, the GLO MAY reattempt to create the GL using the information provided in the glFailInfo response. The GLO may also use the glaQueryRequest to determine the algorithms and other characteristics supported by the GLA (see section 4.9). 4.2 Delete GL From GLA From time to time, there are instances when a GL is no longer needed. In this case the GLO must delete the GL. Figure 4 depicts that protocol interactions to delete a GL. +-----+ 1 2 +-----+ | GLA | <-------> | GLO | +-----+ +-----+ Figure 4 - Delete Group List The process is as follows: 1 - The GLO is the entity responsible for requesting the deletion of the GL. The GLO sends a SignedData.PKIData.controlSequence.glDelete request to the GLA (1 in Figure 4). The name of the GL to be deleted MUST be included in GeneralName. 1.a - The GLO MAY optionally apply confidentiality to the request by encapsulating the SignedData.PKIData in an EnvelopedData (see section 3.2.1.2). 1.b - The GLO MAY also optionally apply another SignedData over the EnvelopedData (see section 3.2.1.2). Turner 31 Internet-Draft S/MIME Symmetric Key Distribution March 2,2001 2 - Upon receipt of the request the GLA verifies the signature on the inner most SignedData.PKIData. If an additional SignedData and/or EnvelopedData encapsulates the request (see section 3.2.1.2 or 3.2.2), the GLA MUST verify the outer signature and/or decrypt the outer layer prior to verifying the signature on the inner most SignedData. 2.a - If the signatures do not verify, the GLA MUST return a cMCStatusInfo response indicating cMCStatus.failed and otherInfo.failInfo.badMessageCheck. 2.b - Else the signatures do verify, the GLA MUST make sure the GL is supported by checking the GLĘs Name matches a glName stored on the GLA. 2.b.1 - If the glName is not supported by the GLA, the GLA MUST return a response indicating glFailInfo.errorCode.invalidGLName. 2.b.2 - Else the glName is supported by the GLA, the GLA MUST ensure a registered GLO signed the glDelete request by checking if one of the names present in the digital signature certificate used to sign the glDelete request matches a registered GLO. 2.b.2.a - If the names do not match, the GLA MUST return a response indicating glFailInfo.errorCode.noGLONameMatch. 2.b.2.b - Else the names do match but the GL is not deletable for other reasons, which the GLA does not wish to disclose, the GLA MUST return a response indicating glFailInfo.errorCode.unspecified. Actions beyond the scope of this document must then be taken to delete the GL from the GLA. 2.b.2.c - Else the names do match, the GLA MUST return a glSuccessInfo indicating the glName, and an action.actionCode.deletedGL (2 in Figure 4). glMemberName and glOwnerName MUST be omitted. The GLA MUST not accept further requests for member additions, member deletions, or group rekeys for this GL. 2.b.2.c.1 - The GLA MUST apply confidentiality to the response by encapsulating the SignedData.PKIResponse in an EnvelopedData if the request was encapsulated in an EnvelopedData (see section 3.2.1.2). 2.b.2.c.2 - The GLA MAY also optionally apply another SignedData over the EnvelopedData (see section 3.2.1.2). 3 - Upon receipt of the glSuccessInfo or glFailInfo response, the GLO verifies the GLA's signature(s). If an additional Turner 32 Internet-Draft S/MIME Symmetric Key Distribution March 2,2001 SignedData and/or EnvelopedData encapsulates the response (see section 3.2.1.2 or 3.2.2), the GLO MUST verify the outer signature and/or decrypt the outer layer prior to verifying the signature on the inner most SignedData. 3.a - If the signatures do not verify, the GLO MUST return a cMCStatusInfo response indicating cMCStatus.failed and otherInfo.failInfo.badMessageCheck. 3.b - Else the signatures do verify, the GLO MUST check that one of the names in the certificate used to sign the response matches the name of the GL. 3.b.1 ū If the GLĘs name does not match the name present in the certificate used to sign the message, the GLO should not believe the response. 3.b.2 ū Else the GLĘs name does match the name present in the certificate and: 3.b.2.a - If the signatures do verify and the response was glSuccessInfo, the GLO has successfully deleted the GL. 3.b.2.b - Else the signatures do verify and the response was glFailInfo, the GLO MAY reattempt to delete the GL using the information provided in the glFailInfo response. 4.3 Add Members To GL To add members to GLs, either the GLO or prospective members use the glAddMember request. The GLA processes GLO and prospective GL member requests differently though. GLOs can submit the request at any time to add members to the GL, and the GLA, once it has verified the request came from a registered GLO, should process it. If a prospective member sends the request, the GLA needs to determine how the GL is administered. When the GLO initially configured the GL, they set the GL to be unmanaged, managed, or closed (see section 3.1.1). In the unmanaged case, the GLA merely processes the memberĘs request. For the managed case, the GLA forwards the requests from the prospective members to the GLO for review. Where there are multiple GLOs for a GL, which GLO the request is forwarded to is beyond the scope of this document. The GLO reviews the request and either rejects it or submits a reformed request to the GLA. In the closed case, the GLA will not accept requests from prospective members. The following sections describe the processing for the GLO(s), GLA, and prospective GL members depending on where the glAddMeber request originated, either from a GLO or from prospective members. Figure 5 depicts the protocol interactions for the three options. Note that the error messages are not depicted. Turner 33 Internet-Draft S/MIME Symmetric Key Distribution March 2,2001 +-----+ 2,B{A} 3 +----------+ | GLO | <--------+ +-------> | Member 1 | +-----+ | | +----------+ 1 | | +-----+ <--------+ | 3 +----------+ | GLA | A +-------> | ... | +-----+ <-------------+ +----------+ | | 3 +----------+ +-------> | Member n | +----------+ Figure 5 - Member Addition An important decision that needs to be made on a group by group basis is whether to rekey the group every time a new member is added. Typically, unmanaged GLs should not be rekeyed when a new member is added, as the overhead associated with rekeying the group becomes prohibitive, as the group becomes large. However, managed and closed GLs MAY be rekeyed to maintain the secrecy of the group. An option to rekeying managed or closed GLs when a member is added is to generate a new GL with a different group key. Group rekeying is discussed in sections 4.5 and 5. 4.3.1 GLO Initiated Additions The process for GLO initiated glAddMember requests is as follows: 1 - The GLO collects the pertinent information for the member(s) to be added (this may be done through an out of bands means). The GLO then sends a SignedData.PKIData.controlSequence with a separate glAddMember request for each member to the GLA (1 in Figure 5). The GLO MUST include: the GL name in glName, the member's name in glMember.glMemberName, the memberĘs address in glMember.glMemberAddress, and the member's encryption certificate in glMember.certificates.pKC. The GLO MAY also include any attribute certificates associated with the memberĘs encryption certificate in glMember.certificates.aC, and the certification path associated with the memberĘs encryption and attribute certificates in glMember.certificates.certificationPath. 1.a - The GLO MAY optionally apply confidentiality to the request by encapsulating the SignedData.PKIData in an EnvelopedData (see section 3.2.1.2). 1.b - The GLO MAY also optionally apply another SignedData over the EnvelopedData (see section 3.2.1.2). 2 - Upon receipt of the request, the GLA verifies the signature on the inner most SignedData.PKIData. If an additional SignedData Turner 34 Internet-Draft S/MIME Symmetric Key Distribution March 2,2001 and/or EnvelopedData encapsulates the request (see section 3.2.1.2 or 3.2.2), the GLA MUST verify the outer signature and/or decrypt the outer layer prior to verifying the signature on the inner most SignedData. 2.a - If the signatures do not verify, the GLA MUST return a cMCStatusInfo response indicating cMCStatus.failed and otherInfo.failInfo.badMessageCheck. 2.b - Else the signatures do verify, the glAddMember request is included in a controlSequence with the glUseKEK request, and the processing in section 4.1 item 2.e is successfully completed the GLA MUST return a glSuccessInfo indicating the glName, the corresponding glIdentifier, an action.actionCode.addedMember, and action.glMemberName (2 in Figure 5). 2.b.1 - The GLA MUST apply confidentiality to the response by encapsulating the SignedData.PKIData in an EnvelopedData if the request was encapsulated in an EnvelopedData (see section 3.2.1.2). 2.b.2 - The GLA MAY also optionally apply another SignedData over the EnvelopedData (see section 3.2.1.2). 2.c - Else the signatures do verify and the GLAddMember request is not included in a controlSequence with the GLCreate request, the GLA MUST make sure the GL is supported by checking that the glName matches a glName stored on the GLA. 2.c.1 - If the glName is not supported by the GLA, the GLA MUST return a response indicating glFailInfo.errorCode.invalidGLName. 2.c.2 - Else the glName is supported by the GLA, the GLA MUST check to see if the glMemberName is present on the GL. 2.c.2.a - If the glMemberName is present on the GL, the GLA MUST return a response indicating glFailInfo.errorCode.alreadyAMember. 2.c.2.b - Else the glMemberName is not present on the GL, the GLA MUST check how the GL is administered. 2.c.2.b.1 - If the GL is closed, the GLA MUST check that a registered GLO signed the request by checking that one of the names in the digital signature certificate used to sign the request matches a registered GLO. 2.c.2.b.1.a - If the names do not match, the GLA MUST return a response indicating glFailInfo.errorCode.noGLONameMatch. Turner 35 Internet-Draft S/MIME Symmetric Key Distribution March 2,2001 2.c.2.b.1.b - Else the names do match, the GLA MUST verify the member's encryption certificate. 2.c.2.b.1.b.1 - If the member's encryption certificate does not verify, the GLA MAY return a response indicating glFailInfo.errorCode.invalidCert to the GLO. If the GLA does not return a glFailInfo response, the GLA MUST issue a glProvideCert request (see section 4.10). 2.c.2.b.1.b.2 - Else the member's certificate does verify, the GLA MUST return a glSuccessInfo to the GLO indicating the glName, the corresponding glIdentifier, an action.actionCode.addedMember, and action.glMemberName (2 in Figure 5). The GLA also takes administrative actions, which are beyond the scope of this document, to add the member to the GL stored on the GLA. The GLA MUST also distribute the shared KEK to the member via the mechanism described in section 5. 2.c.2.b.1.b.2.a - The GLA MUST apply confidentiality to the response by encapsulating the SignedData.PKIData in an EnvelopedData if the request was encapsulated in an EnvelopedData (see section 3.2.1.2). 2.c.2.b.1.b.2.b - The GLA MAY also optionally apply another SignedData over the EnvelopedData (see section 3.2.1.2). 2.c.2.b.2 - Else the GL is managed, the GLA MUST check that either a registered GLO or the prospective member signed the request. For GLOs, one of the names in the certificate used to sign the request MUST match a registered GLO. For the prospective member, the name in glMember.glMemberName MUST match one of the names in the certificate used to sign the request. 2.c.2.b.2.a - If the signer is neither a registered GLO nor the prospective GL member, the GLA MUST return a response indicating glFailInfo.errorCode.noSpam. 2.c.2.b.2.b - Else the signer is a registered GLO, the GLA MUST verify the member's encryption certificate. 2.c.2.b.2.b.1 - If the member's certificate does not verify, the GLA MAY return a response indicating glFailInfo.errorCode.invalidCert. If the GLA does not return a glFailInfo response, the GLA MUST issue a glProvideCert request (see section 4.10). Turner 36 Internet-Draft S/MIME Symmetric Key Distribution March 2,2001 2.c.2.b.2.b.2 - Else the member's certificate does verify, the GLA MUST return glSuccessInfo indicating the glName, the corresponding glIdentifier, an action.actionCode.addedMember, and action.glMemberName to the GLO (2 in Figure 5). The GLA also takes administrative actions, which are beyond the scope of this document, to add the member to the GL stored on the GLA. The GLA MUST also distribute the shared KEK to the member via the mechanism described in section 5. The GL policy may mandate that the GL memberĘs address be included in the GL memberĘs certificate. 2.c.2.b.2.b.2.a - The GLA MUST apply confidentiality to the response by encapsulating the SignedData.PKIData in an EnvelopedData if the request was encapsulated in an EnvelopedData (see section 3.2.1.2). 2.c.2.b.2.b.2.b - The GLA MAY also optionally apply another SignedData over the EnvelopedData (see section 3.2.1.2). 2.c.2.b.2.c - Else the signer is the prospective member, the GLA MUST forward the glAddMember request (see section 3.2.3) to a registered GLO (B{A} in Figure 5). If there is more than one registered GLO, the GLO to which the request is forwarded to is beyond the scope of this document. Further processing of the forwarded request by GLOs is addressed in 3 of section 4.3.2. 2.c.2.b.2.c.1 - The GLA MUST apply confidentiality to the forwarded request by encapsulating the SignedData.PKIData in an EnvelopedData if the original request was encapsulated in an EnvelopedData (see section 3.2.1.2). 2.c.2.b.2.c.2 - The GLA MAY also optionally apply another SignedData over the EnvelopedData (see section 3.2.1.2). 2.c.2.b.3 - Else the GL is unmanaged, the GLA MUST check that either a registered GLO or the prospective member signed the request. For GLOs, one of the names in the certificate used to sign the request MUST match the name of a registered GLO. For the prospective member, the name in glMember.glMemberName MUST match one of the names in the certificate used to sign the request. Turner 37 Internet-Draft S/MIME Symmetric Key Distribution March 2,2001 2.c.2.b.3.a - If the signer is neither a registered GLO nor the prospective member, the GLA MUST return a response indicating glFailInfo.errorCode.noSpam. 2.c.2.b.3.b - Else the signer is either a registered GLO or the prospective member, the GLA MUST verify the member's encryption certificate. 2.c.2.b.3.b.1 - If the member's certificate does not verify, the GLA MAY return a response indicating glFailInfo.errorCode.invalidCert to either the GLO or the prospective member depending on where the request originated. If the GLA does not return a glFailInfo response, the GLA MUST issue a glProvideCert request (see section 4.10) to either the GLO or prospective member depending on where the request originated. 2.c.2.b.3.b.2 - Else the member's certificate does verify, the GLA MUST return a glSuccessInfo indicating the glName, the corresponding glIdentifier, an action.actionCode.addedMember, and action.glMemberName to the GLO (2 in Figure 5) if the GLO signed the request and to the GL member (3 in Figure 5) if the GL member signed the request. The GLA also takes administrative actions, which are beyond the scope of this document, to add the member to the GL stored on the GLA. The GLA MUST also distribute the shared KEK to the member via the mechanism described in section 5. 2.c.2.b.3.b.2.a - The GLA MUST apply confidentiality to the response by encapsulating the SignedData.PKIData in an EnvelopedData if the request was encapsulated in an EnvelopedData (see section 3.2.1.2). 2.c.2.b.3.b.2.b - The GLA MAY also optionally apply another SignedData over the EnvelopedData (see section 3.2.1.2). 3 - Upon receipt of the glSuccessInfo or glFailInfo response, the GLO verifies the GLA's signature(s). If an additional SignedData and/or EnvelopedData encapsulates the response (see section 3.2.1.2 or 3.2.2), the GLO MUST verify the outer signature and/or decrypt the outer layer prior to verifying the signature on the inner most SignedData. 3.a - If the signatures do not verify, the GLO MUST return a cMCStatusInfo response indicating cMCStatus.failed and otherInfo.failInfo.badMessageCheck. Turner 38 Internet-Draft S/MIME Symmetric Key Distribution March 2,2001 3.b - Else the signatures do verify, the GLO MUST check that one of the names in the certificate used to sign the response matches the name of the GL. 3.b.1 ū If the GLĘs name does not match the name present in the certificate used to sign the message, the GLO should not believe the response. 3.b.2 ū Else the GLĘs name does match the name present in the certificate and: 3.b.2.a - If the signatures do verify and the response is glSuccessInfo, the GLO has added the member to the GL. If member was added to a managed list and the original request was signed by the member, the GLO MUST send a cMCStatusInfo.cMCStatus.success to the GL member. 3.b.2.b - Else the GLO received a glFailInfo, for any reason, the GLO MAY reattempt to add the member to the GL using the information provided in the glFailInfo response. 4 - Upon receipt of the glSuccessInfo, glFailInfo, or cMCStatus response, the prospective member verifies the GLA's signatures or GLOĘs signatures. If an additional SignedData and/or EnvelopedData encapsulates the response (see section 3.2.1.2 or 3.2.2), the GLO MUST verify the outer signature and/or decrypt the outer layer prior to verifying the signature on the inner most SignedData. 4.a - If the signatures do not verify, the prospective member MUST return a cMCStatusInfo response indicating cMCStatus.failed and otherInfo.failInfo.badMessageCheck. 4.b - Else the signatures do verify, the GL member MUST check that one of the names in the certificate used to sign the response matches the name of the GL. 4.b.1 ū If the GLĘs name does not match the name present in the certificate used to sign the message, the GL member should not believe the response. 4.b.2 ū Else the GLĘs name does match the name present in the certificate and: 4.b.2.a - If the signatures do verify, the prospective member has been added to the GL. 4.b.2.b - Else the prospective member received a glFailInfo, for any reason, the prospective member MAY reattempt to add themselves to the GL using the information provided in the glFailInfo response. Turner 39 Internet-Draft S/MIME Symmetric Key Distribution March 2,2001 4.3.2 Prospective Member Initiated Additions The process for prospective member initiated glAddMember requests is as follows: 1 - The prospective GL member sends a SignedData.PKIData.controlSequence.glAddMember request to the GLA (A in Figure 5). The prospective GL member MUST include: the GL name in glName, their name in glMember.glMemberName, their address in glMember.glMemberAddress, and their encryption certificate in glMember.certificates.pKC. The prospective GL member MAY also include any attribute certificates associated with their encryption certificate in glMember.certificates.aC, and the certification path associated with their encryption and attribute certificates in glMember.certificates.certificationPath. 1.a - The prospective GL member MAY optionally apply confidentiality to the request by encapsulating the SignedData.PKIData in an EnvelopedData (see section 3.2.1.2). 1.b - The prospective GL member MAY also optionally apply another SignedData over the EnvelopedData (see section 3.2.1.2). 2 - Upon receipt of the request, the GLA verifies the request as per 2 in section 4.3.1. 3 - Upon receipt of the forwarded request, the GLO verifies the prospective GL memberĘs signature on the inner most SignedData.PKIData and the GLAĘs signature on the outer layer. If an EnvelopedData encapsulates the inner most layer (see section 3.2.1.2 or 3.2.2), the GLO MUST decrypt the outer layer prior to verifying the signature on the inner most SignedData. Note: For cases where the GL is closed and either a) a prospective member sends directly to the GLO or b) the GLA has mistakenly forwarded the request to the GLO, the GLO should first determine whether to honor the request. 3.a - If the signatures do not verify, the GLO MUST return a cMCStatusInfo response indicating cMCStatus.failed and otherInfo.failInfo.badMessageCheck. 3.b - Else the signatures do verify, the GLO MUST check to make sure one of the names in the certificate used to sign the request matches the name in glMember.glMemberName. 3.b.1 - If the names do not match, the GLO MAY send a SignedData.PKIResponse.controlSequence message back to the Turner 40 Internet-Draft S/MIME Symmetric Key Distribution March 2,2001 prospective member with cMCStatusInfo.cMCStatus.failed indicating why the prospective member was denied in cMCStausInfo.statusString. This stops people from adding people to GLs without their permission. 3.b.2 - Else the names do match, the GLO determines whether the prospective member is allowed to be added. The mechanism is beyond the scope of this document; however, the GLO should check to see that the glMember.glMemberName is not already on the GL. 3.b.2.a - If the GLO determines the prospective member is not allowed to join the GL, the GLO MAY return a SignedData.PKIResponse.controlSequence message back to the prospective member with cMCStatusInfo.cMCtatus.failed indicating why the prospective member was denied in cMCStatus.statusString. 3.b.2.b - Else GLO determines the prospective member is allowed to join the GL, the GLO MUST verify the member's encryption certificate. 3.b.2.b.1 - If the member's certificate does not verify, the GLO MAY return a SignedData.PKIResponse.controlSequence back to the prospective member with cMCStatusInfo.cMCtatus.failed indicating that the memberĘs encryption certificate did not verify in cMCStatus.statusString. If the GLO does not return a cMCStatusInfo response, the GLO MUST send a SignedData.PKIData.controlSequence.glProvideCert message to the prospective member requesting a new encryption certificate (see section 4.10). 3.b.2.b.2 - Else the member's certificate does verify, the GLO resubmits the glAddMember request (see section 3.2.5) to the GLA (1 in Figure 5). 3.b.2.b.2.a - The GLO MUST apply confidentiality to the new GLAddMember request by encapsulating the SignedData.PKIData in an EnvelopedData if the initial request was encapsulated in an EnvelopedData (see section 3.2.1.2). 3.b.2.b.2.b - The GLO MAY also optionally apply another SignedData over the EnvelopedData (see section 3.2.1.2). 4 - Processing continues as in 2 of section 4.3.1. Turner 41 Internet-Draft S/MIME Symmetric Key Distribution March 2,2001 4.4 Delete Members From GL To delete members from GLs, either the GLO or prospective non- members use the glDeleteMember request. The GLA processes GLO and prospective non-GL member requests differently. The GLO can submit the request at any time to delete members from the GL, and the GLA, once it has verified the request came from a registered GLO, should delete the member. If a prospective member sends the request, the GLA needs to determine how the GL is administered. When the GLO initially configured the GL, they set the GL to be unmanaged, managed, or closed (see section 3.1.1). In the unmanaged case, the GLA merely processes the memberĘs request. For the managed case, the GLA forwards the requests from the prospective members to the GLO for review. Where there are multiple GLOs for a GL, which GLO the request is forwarded to is beyond the scope of this document. The GLO reviews the request and either rejects it or submits a reformed request to the GLA. In the closed case, the GLA will not accept requests from prospective members. The following sections describe the processing for the GLO(s), GLA, and GL members depending on where the request originated, either from a GLO or from prospective non-members. Figure 6 depicts the protocol interactions for the three options. Note that the error messages are not depicted. +-----+ 2,B{A} 3 +----------+ | GLO | <--------+ +-------> | Member 1 | +-----+ | | +----------+ 1 | | +-----+ <--------+ | 3 +----------+ | GLA | A +-------> | ... | +-----+ <-------------+ +----------+ | | 3 +----------+ +-------> | Member n | +----------+ Figure 6 - Member Deletion If the member is not removed from the GL, they will continue to receive and be able to decrypt data protected with the shared KEK and will continue to receive rekeys. For unmanaged lists, there is no point to a group rekey because there is no guarantee that the member requesting to be removed has not already added themselves back on the GL under a different name. For managed and closed GLs, the GLO MUST take steps to ensure the member being deleted is not on the GL twice. After ensuring this, managed and closed GLs MUST be rekeyed to maintain the secrecy of the group. If the GLO is sure the member has been deleted the group rekey mechanism MUST be used to distribute the new key (see sections 4.5 and 5). Turner 42 Internet-Draft S/MIME Symmetric Key Distribution March 2,2001 4.4.1 GLO Initiated Deletions The process for GLO initiated glDeleteMember requests is as follows: 1 - The GLO collects the pertinent information for the member(s) to be deleted (this MAY be done through an out of bands means). The GLO then sends a SignedData.PKIData.controlSequence with a separate glDeleteMember request for each member to the GLA (1 in Figure 6). The GLO MUST include: the GL name in glName and the member's name in glMemberToDelete. If the GL from which the member is being deleted in a closed or managed GL, the GLO MUST also generate a glRekey request and include it with the glDeletemember request (see section 4.5). 1.a - The GLO MAY optionally apply confidentiality to the request by encapsulating the SignedData.PKIData in an EnvelopedData (see section 3.2.1.2). 1.b - The GLO MAY also optionally apply another SignedData over the EnvelopedData (see section 3.2.1.2). 2 - Upon receipt of the request, the GLA verifies the signature on the inner most SignedData.PKIData. If an additional SignedData and/or EnvelopedData encapsulates the request (see section 3.2.1.2 or 3.2.2), the GLA MUST verify the outer signature and/or decrypt the outer layer prior to verifying the signature on the inner most SignedData. 2.a - If the signatures do not verify, the GLA MUST return a cMCStatusInfo response indicating cMCStatus.failed and otherInfo.failInfo.badMessageCheck. 2.b - Else the signatures do verify, the GLA MUST make sure the GL is supported by the GLA by checking that the glName matches a glName stored on the GLA. 2.b.1 - If the glName is not supported by the GLA, the GLA MUST return a response indicating glFailInfo.errorCode.invalidGLName. 2.b.2 - Else the glName is supported by the GLA, the GLA MUST check to see if the glMemberName is present on the GL. 2.b.2.a - If the glMemberName is not present on the GL, the GLA MUST return a response indicating glFailInfo.errorCode.notAMember. 2.b.2.b - Else the glMemberName is already on the GL, the GLA MUST check how the GL is administered. Turner 43 Internet-Draft S/MIME Symmetric Key Distribution March 2,2001 2.b.2.b.1 - If the GL is closed, the GLA MUST check that the registered GLO signed the request by checking that one of the names in the digital signature certificate used to sign the request matches the registered GLO. 2.b.2.b.1.a - If the names do not match, the GLA MUST return a response indicating glFailInfo.errorCode.closed. 2.b.2.b.1.b - Else the names do match, the GLA MUST return a glSuccessInfo indicating the glName, the corresponding glIdentifier, an action.actionCode.deletedMember, and action.glMemberName (2 in Figure 5). The GLA also takes administrative actions, which are beyond the scope of this document, to delete the member with the GL stored on the GLA. Note that he GL MUST also be rekeyed as described in section 5. 2.b.2.b.1.b.1 - The GLA MUST apply confidentiality to the response by encapsulating the SignedData.PKIData in an EnvelopedData if the request was encapsulated in an EnvelopedData (see section 3.2.1.2). 2.b.2.b.1.b.2 - The GLA MAY also optionally apply another SignedData over the EnvelopedData (see section 3.2.1.2). 2.b.2.b.2 - Else the GL is managed, the GLA MUST check that either a registered GLO or the prospective member signed the request. For GLOs, one of the names in the certificate used to sign the request MUST match a registered GLO. For the prospective member, the name in glMember.glMemberName MUST match one of the names in the certificate used to sign the request. 2.b.2.b.2.a - If the signer is neither a registered GLO nor the prospective GL member, the GLA MUST return a response indicating glFailInfo.errorCode.noSpam. 2.b.2.b.2.b - Else the signer is a registered GLO, the GLA MUST return a glSuccessInfo to the GLO indicating the glName, the corresponding glIdentifier, an action.actionCode.deletedMember, and action.glMemberName (2 in Figure 6). The GLA also takes administrative actions, which are beyond the scope of this document, to delete the member with the GL stored on the GLA. Note that the GL will also be rekeyed as described in section 5. 2.b.2.b.2.b.1 - The GLA MUST apply confidentiality to the response by encapsulating the SignedData.PKIData in an Turner 44 Internet-Draft S/MIME Symmetric Key Distribution March 2,2001 EnvelopedData if the request was encapsulated in an EnvelopedData (see section 3.2.1.2). 2.b.2.b.2.b.2 - The GLA MAY also optionally apply another SignedData over the EnvelopedData (see section 3.2.1.2). 2.b.2.b.2.c - Else the signer is the prospective member, the GLA forwards the glDeleteMember request (see section 3.2.3) to the GLO (B{A} in Figure 6). If there is more than one registered GLO, the GLO to which the request is forwarded to is beyond the scope of this document. Further processing of the forwarded request by GLOs is addressed in 3 of section 4.4.2. 2.b.2.b.2.c.1 - The GLA MUST apply confidentiality to the forwarded request by encapsulating the SignedData.PKIData in an EnvelopedData if the request was encapsulated in an EnvelopedData (see section 3.2.1.2). 2.b.2.b.2.c.2 - The GLA MAY also optionally apply another SignedData over the EnvelopedData (see section 3.2.1.2). 2.b.2.b.3 - Else the GL is unmanaged, the GLA MUST check that either a registered GLO or the prospective member signed the request. For GLOs, one of the names in the certificate used to sign the request MUST match the name of a registered GLO. For the prospective member, the name in glMember.glMemberName MUST match one of the names in the certificate used to sign the request. 2.b.2.b.3.a - If the signer is neither the GLO nor the prospective member, the GLA MUST return a response indicating glFailInfo.errorCode.noSpam. 2.b.2.b.3.b - Else the signer is either a registered GLO or the member, the GLA MUST return a glSuccessInfo indicating the glName, the corresponding glIdentifier, an action.actionCode.deletedMember, and action.glMemberName to the GLO (2 in Figure 6) if the GLO signed the request and to the GL member (3 in Figure 6) if the GL member signed the request. The GLA also takes administrative actions, which are beyond the scope of this document, to delete the member with the GL stored on the GLA. 2.b.2.b.3.b.1 - The GLA MUST apply confidentiality to the response by encapsulating the SignedData.PKIData in an EnvelopedData if the request was encapsulated in an EnvelopedData (see section 3.2.1.2). Turner 45 Internet-Draft S/MIME Symmetric Key Distribution March 2,2001 2.b.2.b.3.b.2 - The GLA MAY also optionally apply another SignedData over the EnvelopedData (see section 3.2.1.2). 3 - Upon receipt of the glSuccessInfo or glFailInfo response, the GLO verifies the GLA's signatures. If an additional SignedData and/or EnvelopedData encapsulates the response (see section 3.2.1.2 or 3.2.2), the GLO MUST verify the outer signature and/or decrypt the outer layer prior to verifying the signature on the inner most SignedData. 3.a - If the signatures do not verify, the GLO MUST return a cMCStatusInfo response indicating cMCStatus.failed and otherInfo.failInfo.badMessageCheck. 3.b - Else the signatures do verify, the GLO MUST check that one of the names in the certificate used to sign the response matches the name of the GL. 3.b.1 ū If the GLĘs name does not match the name present in the certificate used to sign the message, the GLO should not believe the response. 3.b.2 ū Else the GLĘs name does match the name present in the certificate and: 3.b.2.a - If the signatures do verify and the response is glSuccessInfo, the GLO has deleted the member from the GL. If member was deleted from a managed list and the original request was signed by the member, the GLO MUST send a cMCStatusInfo.cMCStatus.success to the GL member. 3.b.2.b - Else the GLO received a glFailInfo, for any reason, the GLO may reattempt to delete the member from the GL using the information provided in the glFailInfo response. 4 - Upon receipt of the glSuccessInfo, glFailInfo, or cMCStatus response, the prospective member verifies the GLA's signature(s) or GLOĘs signature(s). If an additional SignedData and/or EnvelopedData encapsulates the response (see section 3.2.1.2 or 3.2.2), the GLO MUST verify the outer signature and/or decrypt the outer layer prior to verifying the signature on the inner most SignedData. 4.a - If the signatures do not verify, the prospective member MUST return a cMCStatusInfo response indicating cMCStatus.failed and otherInfo.failInfo.badMessageCheck. 4.b - Else the signatures do verify, the GL member MUST check that one of the names in the certificate used to sign the response matches the name of the GL. Turner 46 Internet-Draft S/MIME Symmetric Key Distribution March 2,2001 4.b.1 ū If the GLĘs name does not match the name present in the certificate used to sign the message, the GL member should not believe the response. 4.b.2 ū Else the GLĘs name does match the name present in the certificate and: 4.b.2.a - If the signature(s) does(do) verify, the prospective member has been deleted from the GL. 4.b.2.b - Else the prospective member received a glFailInfo, for any reason, the prospective member MAY reattempt to delete themselves from the GL using the information provided in the glFailInfo response. 4.4.2 Member Initiated Deletions The process for prospective non-member initiated glDeleteMember requests is as follows: 1 - The prospective non-GL member sends a SignedData.PKIData.controlSequence.glDeleteMember request to the GLA (A in Figure 6). The prospective non-GL member MUST include: the GL name in glName and their name in glMemberToDelete. 1.a - The prospective non-GL member MAY optionally apply confidentiality to the request by encapsulating the SignedData.PKIData in an EnvelopedData (see section 3.2.1.2). 1.b - The prospective non-GL member MAY also optionally apply another SignedData over the EnvelopedData (see section 3.2.1.2). 2 - Upon receipt of the request, the GLA verifies the request as per 2 in section 4.4.1. 3 - Upon receipt of the forwarded request, the GLO verifies the prospective non-memberĘs signature on the inner most SignedData.PKIData and the GLAĘs signature on the outer layer. If an EnvelopedData encapsulates the inner most layer (see section 3.2.1.2 or 3.2.2), the GLO MUST decrypt the outer layer prior to verifying the signature on the inner most SignedData. Note: For cases where the GL is closed and either a) a prospective member sends directly to the GLO or b) the GLA has mistakenly forwarded the request to the GLO, the GLO should first determine whether to honor the request. Turner 47 Internet-Draft S/MIME Symmetric Key Distribution March 2,2001 3.a - If the signatures do not verify, the GLO MUST return a cMCStatusInfo response indicating cMCStatus.failed and otherInfo.failInfo.badMessageCheck. 3.b - Else the signatures do verify, the GLO MUST check to make sure one of the names in the certificates used to sign the request matches the name in glMemberToDelete. 3.b.1 - If the names do not match, the GLO MAY send a SignedData.PKIResponse.controlSequence message back to the prospective member with cMCStatusInfo.cMCtatus.failed indicating why the prospective member was denied in cMCStatusInfo.statusString. This stops people from adding people to GLs without their permission. 3.b.2 - Else the names do match, the GLO resubmits the glDeleteMember request (see section 3.2.5) to the GLA (1 in Figure 6). The GLO MUST make sure the glMemberName is already on the GL. The GLO MUST also generate a glRekey request and include it with the GLDeleteMember request (see section 4.5). 3.b.2.a - The GLO MUST apply confidentiality to the new GLDeleteMember request by encapsulating the SignedData.PKIData in an EnvelopedData if the initial request was encapsulated in an EnvelopedData (see section 3.2.1.2). 3.b.2.b - The GLO MAY also optionally apply another SignedData over the EnvelopedData (see section 3.2.1.2). 4 - Further processing is as in 2 of section 4.4.1. 4.5 Request Rekey Of GL From time to time the GL will need to be rekeyed. Some situations are as follows: - When a member is removed from a closed or managed GL. In this case, the PKIData.controlSequence containing the glDeleteMember should contain a glRekey request. - Depending on policy, when a member is removed from an unmanaged GL. If the policy is to rekey the GL, the PKIData.controlSequence containing the glDeleteMember could also contain a glRekey request or an out of bands means could be used to tell the GLA to rekey the GL. Rekeying of unmanaged GLs when members are deleted is not advised. - When the current shared KEK has been compromised. Turner 48 Internet-Draft S/MIME Symmetric Key Distribution March 2,2001 - When the current shared KEK is about to expire. - If the GLO controls the GL rekey, the GLA should not assume that a new shared KEK should be distributed, but instead wait for the glRekey message. - If the GLA controls the GL rekey, the GLA should initiate a glKey message as specified in section 5. If the generationCounter (see section 3.1.1) is set to a value greater than one (1) and the GLO controls the GL rekey, the GLO may generate a glRekey any time before the last shared KEK has expired. To be on the safe side, the GLO should request a rekey one (1) duration before the last shared KEK expires. The GLA and GLO are the only entities allowed to initiate a GL rekey. The GLO indicated whether they are going control rekeys or whether the GLA is going to control rekeys when the assigned the shared KEK to GL (see section 3.1.1). The GLO MAY initiate a GL rekey at any time. The GLA MAY be configured to automatically rekey the GL prior to the expiration of the shared KEK (the length of time before the expiration is an implementation decision). The GLA can also automatically rekey GLĘs that have been compromised, but this is covered in section 5. Figure 7 depicts the protocol interactions to request a GL rekey. Note that error messages are not depicted. +-----+ 1 2,A +-----+ | GLA | <-------> | GLO | +-----+ +-----+ Figure 7 - GL Rekey Request 4.5.1 GLO Initiated Rekey Requests The process for GLO initiated glRekey requests is as follows: 1 - The GLO sends a SignedData.PKIData.controlSequence.glRekey request to the GLA (1 in Figure 7). The GLO MUST include the glName. If glAdministration and glKeyNewAttributes are omitted then there is no change from the previously registered GL values for these fields. If the GLO wants to force a rekey for all outstanding shared KEKs it includes the glRekeyAllGLKeys set to TRUE. 1.a - The GLO MAY optionally apply confidentiality to the request by encapsulating the SignedData.PKIData in an EnvelopedData (see section 3.2.1.2). 1.b - The GLO MAY also optionally apply another SignedData over the EnvelopedData (see section 3.2.1.2). Turner 49 Internet-Draft S/MIME Symmetric Key Distribution March 2,2001 2 - Upon receipt of the request, the GLA verifies the signature on the inner most SignedData.PKIData. If an additional SignedData and/or EnvelopedData encapsulates the request (see section 3.2.1.2 or 3.2.2), the GLA MUST verify the outer signature and/or decrypt the outer layer prior to verifying the signature on the inner most SignedData. 2.a - If the signatures do not verify, the GLA MUST return a cMCStatusInfo response indicating cMCStatus.failed and otherInfo.failInfo.badMessageCheck. 2.b - Else the signatures do verify, the GLA MUST make sure the GL is supported by the GLA by checking that the glName matches a glName stored on the GLA. 2.b.1 - If the glName present does not match a GL stored on the GLA, the GLA MUST return a response indicating glFailInfo.errorCode.invalidGLName. 2.b.2 - Else the glName present does match a GL stored on the GLA, the GLA MUST check that a registered GLO signed the request by checking that one of the names in the certificate used to sign the request is a registered GLO. 2.b.2.a - If the names do not match, the GLA MUST return a response indicating glFailInfo.errorCode.noGLONameMatch. 2.b.2.b - Else the names do match, the GLA MUST check the glNewKeyAttribute values. 2.b.2.b.1 - If the new value for requestedAlgorithm is not supported, the GLA MUST return a response indicating glFailInfo.errorCode.unsupportedAlgorithm 2.b.2.b.2 - Else the new value duration is not supportable, determining this is beyond the scope this document, the GLA MUST return a response indicating glFailInfo.errorCode.unsupportedDuration. 2.b.2.b.3 - Else the GL is not supportable for other reasons, which the GLA does not wish to disclose, the GLA MUST return a response indicating glFailInfo.errorCode.unspecified. 2.b.2.b.4 - Else the new requestedAlgorithm and duration are supportable or the glNewKeyAttributes was omitted, the GLA MUST return a glSuccessInfo to the GLO indicating the glName, the new glIdentifier, and an action.actionCode.rekeyedGL (2 in Figure 7). The GLA also uses the glKey message to distribute the rekey shared KEK (see section 5). Turner 50 Internet-Draft S/MIME Symmetric Key Distribution March 2,2001 2.b.2.b.4.a - The GLA MUST apply confidentiality to response by encapsulating the SignedData.PKIData in an EnvelopedData if the request was encapsulated in an EnvelopedData (see section 3.2.1.2). 2.b.2.b.4.b - The GLA MAY also optionally apply another SignedData over the EnvelopedData (see section 3.2.1.2). 3 - Upon receipt of the glSuccessInfo or glFailInfo response, the GLO verifies the GLA's signature(s). If an additional SignedData and/or EnvelopedData encapsulates the forwarded response (see section 3.2.1.2 or 3.2.2), the GLO MUST verify the outer signature and/or decrypt the forwarded response prior to verifying the signature on the inner most SignedData. 3.a - If the signatures do not verify, the GLO MUST return a cMCStatusInfo response indicating cMCStatus.failed and otherInfo.failInfo.badMessageCheck. 3.b - Else the signatures do verify, the GLO MUST check that one of the names in the certificate used to sign the response matches the name of the GL. 3.b.1 ū If the GLĘs name does not match the name present in the certificate used to sign the message, the GLO should not believe the response. 3.b.2 ū Else the GLĘs name does match the name present in the certificate and: 3.b.2.a - If the signatures verifies and the response is glSuccessInfo, the GLO has successfully rekeyed the GL. 3.b.2.b - Else the GLO received a glFailInfo, for any reason, the GLO may reattempt to rekey the GL using the information provided in the glFailInfo response. 4.5.2 GLA Initiated Rekey Requests If the GLA is in charge of rekeying the GL the GLA will automatically issue a glKey message (see section 5). In addition the GLA will generate a glSuccessInfo to indicate to the GL that a successful rekey has occurred. The process for GLA initiated rekey is as follows: 1 - The GLA MUST generate for all GLOs a SignedData.PKIData.controlSequence.glSuccessInfo indicating the glName, the new glIdentifier, and actionCode.rekeyedGL (A in Figure 7). glMemberName and glOwnerName are omitted. Turner 51 Internet-Draft S/MIME Symmetric Key Distribution March 2,2001 1.a - The GLA MAY optionally apply confidentiality to the request by encapsulating the SignedData.PKIData in an EnvelopedData (see section 3.2.1.2). 1.b - The GLA MAY also optionally apply another SignedData over the EnvelopedData (see section 3.2.1.2). 2 - Upon receipt of the glSuccessInfo response, the GLO verifies the GLA's signature(s). If an additional SignedData and/or EnvelopedData encapsulates the forwarded response (see section 3.2.1.2 or 3.2.2), the GLO MUST verify the outer signature and/or decrypt the outer layer prior to verifying the signature on the inner most SignedData. 2.a - If the signatures do not verify, the GLO MUST return a cMCStatusInfo response indicating cMCStatus.failed and otherInfo.failInfo.badMessageCheck. 2.b - Else the signatures do verify, the GLO MUST check that one of the names in the certificate used to sign the response matches the name of the GL. 2.b.1 ū If the GLĘs name does not match the name present in the certificate used to sign the message, the GLO should not believe the response. 2.b.2 ū Else the GLĘs name does match the name present in the certificate and and the response is glSuccessInfo, the GLO knows the GLA has successfully rekeyed the GL. 4.6 Change GLO Management of managed and closed GLs can become difficult for one GLO if the GL membership grows large. To support distributing the workload, GLAs support having GLs be managed by multiple GLOs. The glAddOwner and glRemoveOwner messages are designed to support adding and removing registered GLOs. Figure 8 depicts the protocol interactions to send glAddOwner and glRemoveOwner messages and the resulting response messages. +-----+ 1 2 +-----+ | GLA | <-------> | GLO | +-----+ +-----+ Figure 8 - GLO Add & Delete Owners The process for glAddOwner and glDeleteOwner is as follows: 1 - The GLO sends a SignedData.PKIData.controlSequence.glAddOwner or glRemoveOwner request to the GLA (1 in Figure 8). The GLO Turner 52 Internet-Draft S/MIME Symmetric Key Distribution March 2,2001 MUST include: the GL name in glName, the GLOĘs name in glOwnerName, and the GLOĘs address in glOwnerAddress. 1.a - The GLO MAY optionally apply confidentiality to the request by encapsulating the SignedData.PKIData in an EnvelopedData (see section 3.2.1.2). 1.b - The GLO MAY also optionally apply another SignedData over the EnvelopedData (see section 3.2.1.2). 2 - Upon receipt of the glAddOwner or glRemoveOwner request, the GLA verifies the GLO's signature(s). If an additional SignedData and/or EnvelopedData encapsulates the request (see section 3.2.1.2 or 3.2.2), the GLA MUST verify the outer signature and/or decrypt the outer layer prior to verifying the signature on the inner most SignedData. 2.a - If the signatures do not verify, the GLA MUST return a cMCStatusInfo response indicating cMCStatus.failed and otherInfo.failInfo.badMessageCheck. 2.b - Else the signatures do verify, the GLA MUST make sure the GL is supported by checking that the glName matches a glName stored on the GLA. 2.b.1 - If the glName is not supported by the GLA, the GLA MUST return a response indicating glFailInfo.errorCode.invalidGLName. 2.b.2 - Else the glName is supported by the GLA, the GLA MUST ensure a registered GLO signed the glAddOwner or glRemoveOwner request by checking that one of the names present in the digital signature certificate used to sign the glAddOwner or glDeleteOwner request matches the name of a registered GLO. 2.b.2.a - If the names do not match, the GLA MUST return a response indicating glFailInfo.errorCode.noGLONameMatch. 2.b.2.b - Else the names do match, the GLA MUST return a glSuccessInfo indicating the glName, the corresponding glIdentifier (for glAddOwner), an action.actionCode.addedGLO or removedGLO, and the respective GLO name in glOwnerName (2 in Figure 4). The GLA MUST also take administrative actions to associate the new glOwnerName with the GL in the case of glAddOwner or to disassociate the old glOwnerName with the GL in the cased of glRemoveOwner. 2.b.2.b.1 - The GLA MUST apply confidentiality to the response by encapsulating the SignedData.PKIResponse in an Turner 53 Internet-Draft S/MIME Symmetric Key Distribution March 2,2001 EnvelopedData if the request was encapsulated in an EnvelopedData (see section 3.2.1.2). 2.b.2.b.2 - The GLA MAY also optionally apply another SignedData over the EnvelopedData (see section 3.2.1.2). 3 - Upon receipt of the glSuccessInfo or glFailInfo response, the GLO verifies the GLA's signature(s). If an additional SignedData and/or EnvelopedData encapsulates the response (see section 3.2.1.2 or 3.2.2), the GLO MUST verify the outer signature and/or decrypt the outer layer prior to verifying the signature on the inner most SignedData. 3.a - If the signatures do not verify, the GLO MUST return a cMCStatusInfo response indicating cMCStatus.failed and otherInfo.failInfo.badMessageCheck. 3.b - Else the signatures do verify, the GLO MUST check that one of the names in the certificate used to sign the response matches the name of the GL. 3.b.1 ū If the GLĘs name does not match the name present in the certificate used to sign the message, the GLO should not believe the response. 3.b.2 ū Else the GLĘs name does match the name present in the certificate and: 3.b.2.a - If the signatures do verify and the response was glSuccessInfo, the GLO has successfully added or removed the GLO. 3.b.2.b - Else the signatures do verify and the response was glFailInfo, the GLO MAY reattempt to add or delete the GLO using the information provided in the glFailInfo response. 4.7 Indicate KEK Compromise The will be times when the shared KEK is compromised. GL members and GLOs use glkCompromise to tell the GLA that the shared KEK has been compromised. Figure 9 depicts the protocol interactions for GL Key Compromise. Turner 54 Internet-Draft S/MIME Symmetric Key Distribution March 2,2001 +-----+ 2{1} 4 +----------+ | GLO | <----------+ +-------> | Member 1 | +-----+ 5,3{1} | | +----------+ +-----+ <----------+ | 4 +----------+ | GLA | 1 +-------> | ... | +-----+ <---------------+ +----------+ | 4 +----------+ +-------> | Member n | +----------+ Figure 9 - GL Key Compromise 4.7.1 GL Member Initiated KEK Compromise Message The process for GL member initiated glkCompromise messages is as follows: 1 - The GL member sends a SignedData.PKIData.controlSequence.glkCompromise request to the GLA (1 in Figure 9). The GL member MUST include the GLĘs name in GeneralName. 1.a - The GL member MAY optionally apply confidentiality to the request by encapsulating the SignedData.PKIData in an EnvelopedData (see section 3.2.1.2). The glkCompromise MUST NOT be included in an EnvelopedData generated with the compromised shared KEK. 1.b - The GL member MAY also optionally apply another SignedData over the EnvelopedData (see section 3.2.1.2). 2 - Upon receipt of the glkCompromise request, the GLA verifies the GL member's signature(s). If an additional SignedData and/or EnvelopedData encapsulates the request (see section 3.2.1.2 or 3.2.2), the GLA MUST verify the outer signature and/or decrypt the outer layer prior to verifying the signature on the inner most SignedData. 2.a - If the signatures do not verify, the GLA MUST return a cMCStatusInfo response indicating cMCStatus.failed and otherInfo.failInfo.badMessageCheck. 2.b - Else the signatures do verify, the GLA MUST make sure the GL is supported by checking that the indicated GL name matches a glName stored on the GLA. 2.b.1 - If the glName is not supported by the GLA, the GLA MUST return a response indicating glFailInfo.errorCode.invalidGLName. 2.b.2 - Else the glName is supported by the GLA, the GLA MUST check who signed the request. For GLOs, one of the names Turner 55 Internet-Draft S/MIME Symmetric Key Distribution March 2,2001 in the certificate used to sign the request MUST match a registered GLO. For the prospective member, the name in glMember.glMemberName MUST match one of the names in the certificate used to sign the request. 2.b.2.a - If the GLO signed the request, the GLA MUST generate a glKey message as described in section 5 to rekey the GL (4 in Figure 9). 2.b.2.b - Else anyone else signed the request, the GLA MUST forward the glkCompromise message (see section 3.2.3) to the GLO (2{1} in Figure 9). If there is more than one GLO, to which GLO the request is forwarded is beyond the scope of this document. Further processing by the GLO is discussed in section 4.7.2. 4.7.2 GLO Initiated KEK Compromise Message The process for GLO initiated glkCompromise messages is as follows: 1 - The GLO either: 1.a - Generates the glkCompromise message itself by sending a SignedData.PKIData.controlSequence.glkCompromise request to the GLA (5 in Figure 9). The GLO MUST include the name of the GL in GeneralName. 1.a.1 - The GLO MAY optionally apply confidentiality to the request by encapsulating the SignedData.PKIData in an EnvelopedData (see section 3.2.1.2). The glkCompromise MUST NOT be included in an EnvelopedData generated with the compromised shared KEK. 1.a.2 - The GLO MAY also optionally apply another SignedData over the EnvelopedData (see section 3.2.1.2). 1.b - Verifies the GLAĘs and GL memberĘs signatures on the forwarded glkCompromise message. If an additional SignedData and/or EnvelopedData encapsulates the request (see section 3.2.1.2 or 3.2.2), the GLO MUST verify the outer signature and/or decrypt the outer layer prior to verifying the signature on the inner most SignedData. 1.b.1 - If the signatures do not verify, the GLO MUST return a cMCStatusInfo response indicating cMCStatus.failed and otherInfo.failInfo.badMessageCheck. 1.b.1.a - If the signatures do verify, the GLO MUST check the names in the certificate match the name of the signer (i.e., the name in the certificate used to sign the GL memberĘs request is the GL member). Turner 56 Internet-Draft S/MIME Symmetric Key Distribution March 2,2001 1.b.1.a.1 ū If either name does not match, the GLO should not trust the signer and it should not forward the message to the GLA. 1.b.1.a.2 ū Else the names do math, the signatures do verify, the GLO MUST determine whether to forward the glkCompromise message back to the GLA (3{1} in Figure 9). Further processing by the GLA is in 2 of section 4.7.1. The GLO MAY also return a response to the prospective member with cMCStatusInfo.cMCtatus.success indicating that the glkCompromise message was successfully received. 4.8 Request KEK Refresh There will be times when GL members have misplaced their shared KEK. The shared KEK is not compromised and a rekey of the entire GL is not necessary. GL members use the glkRefresh message to request that the shared KEK(s) be redistributed to them. Figure 10 depicts the protocol interactions for GL Key Refresh. +-----+ 1 2 +----------+ | GLA | <-----------> | Member | +-----+ +----------+ Figure 10 - GL KEK Refresh The process for glkRefresh is as follows: 1 - The GL member sends a SignedData.PKIData.controlSequence.glkRefresh request to the GLA (1 in Figure 10). The GL member MUST include name of the GL in GeneralName. 1.a - The GL member MAY optionally apply confidentiality to the request by encapsulating the SignedData.PKIData in an EnvelopedData (see section 3.2.1.2). 1.b - The GL member MAY also optionally apply another SignedData over the EnvelopedData (see section 3.2.1.2). 2 - Upon receipt of the glkRefresh request, the GLA verifies the GL member's signature(s). If an additional SignedData and/or EnvelopedData encapsulates the request (see section 3.2.1.2 or 3.2.2), the GLA MUST verify the outer signature and/or decrypt the outer layer prior to verifying the signature on the inner most SignedData. Turner 57 Internet-Draft S/MIME Symmetric Key Distribution March 2,2001 2.a - If the signatures do not verify, the GLA MUST return a cMCStatusInfo response indicating cMCStatus.failed and otherInfo.failInfo.badMessageCheck. 2.b - Else the signatures do verify, the GLA MUST make sure the GL is supported by checking that the GLĘs GeneralName matches a glName stored on the GLA. 2.b.1 - If the GLĘs name is not supported by the GLA, the GLA MUST return a response indicating glFailInfo.errorCode.invalidGLName. 2.b.2 - Else the glName is supported by the GLA, the GLA MUST ensure the GL member is on the GL. 2.b.2.a - If the glMemberName is not present on the GL, the GLA MUST return a response indicating glFailInfo.errorCode.noSpam. 2.b.2.b - Else the glMemberName is present on the GL, the GLA MUST return a glKey message (2 in Figure 10) as described in section 5. 4.9 GLA Query Request and Response There will be certain times when a GLO is having trouble setting up a GL because they do not know the algorithm(s) or some other characteristic that the GLA supports. There may also be times when prospective GL members or GL members need to know something about the GLA (these requests are not defined in the document). The glaQueryRequest and glaQueryResponse message have been defined to support determining this information. Figure 11 depicts the protocol interactions for glaQueryRequest and glaQueryResponse. +-----+ 1 2 +------------------+ | GLA | <-------> | GLO or GL Member | +-----+ +------------------+ Figure 11 - GLA Query Request & Response The process for glaQueryRequest and glaQueryResponse is as follows: 1 - The GLO, GL member, or prospective GL member sends a SignedData.PKIData.controlSequence.glaQueryRequest request to the GLA (1 in Figure 11). The GLO, GL member, or prospective GL member indicates the information they are interested in receiving from the GLA. 1.a - The GLO, GL member, or prospective GL member MAY optionally apply confidentiality to the request by encapsulating the Turner 58 Internet-Draft S/MIME Symmetric Key Distribution March 2,2001 SignedData.PKIData in an EnvelopedData (see section 3.2.1.2). 1.b - The GLO, GL member, or prospective GL member MAY also optionally apply another SignedData over the EnvelopedData (see section 3.2.1.2). 2 - Upon receipt of the glaQueryRequest, the GLA determines if it accepts glaQueryRequest messages. 2.a - If the GLA does not accept glaQueryRequest messages, the GLA MUST return a cMCStatusInfo response indicating cMCStatus.noSupport and any other information in statusString. 2.b - Else the GLA does accept GLAQueryRequests, the GLA MUST verify the GLO's, GL memberĘs, or prospective GL memberĘs signature(s). If an additional SignedData and/or EnvelopedData encapsulates the request (see section 3.2.1.2 or 3.2.2), the GLA MUST verify the outer signature and/or decrypt the outer layer prior to verifying the signature on the inner most SignedData. 2.b.1 - If the signatures do not verify, the GLA MUST return a cMCStatusInfo response indicating cMCStatus.failed and otherInfo.failInfo.badMessageCheck. 2.b.2 - Else the signatures do verify, the GLA MUST return a glaQueryResponse (2 in Figure 11) with the correct response if the glaRequestType is supported or return a cMCStatusInfo response indicating cMCStatus.noSupport if the glaRequestType is not supported. 2.b.2.a - The GLA MUST apply confidentiality to the response by encapsulating the SignedData.PKIResponse in an EnvelopedData if the request was encapsulated in an EnvelopedData (see section 3.2.1.2). 2.b.2.b - The GLA MAY also optionally apply another SignedData over the EnvelopedData (see section 3.2.1.2). 3 - Upon receipt of the glaQueryResponse, the GLO, GL member, or prospective GL member verifies the GLA's signature(s). If an additional SignedData and/or EnvelopedData encapsulates the response (see section 3.2.1.2 or 3.2.2), the GLO, GL member, or prospective GL member MUST verify the outer signature and/or decrypt the outer layer prior to verifying the signature on the inner most SignedData. 3.a - If the signatures do not verify, the GLO, GL member, or prospective GL member MUST return a cMCStatusInfo response Turner 59 Internet-Draft S/MIME Symmetric Key Distribution March 2,2001 indicating cMCStatus.failed and otherInfo.failInfo.badMessageCheck. 3.b - Else the signatures do verify, the GLO, GL member, or prospective GL member MUST check that one of the names in the certificate used to sign the response matches the name of the GL. 3.b.1 ū If the GLĘs name does not match the name present in the certificate used to sign the message, the GLO should not believe the response. 3.b.2 - Else the GLĘs name does match the name present in the certificate and the response was glaQueryResponse, the GLO, GL member, or prospective GL member may use the information contained therein. 4.10 Update Member Certificate When the GLO generates a glAddMember request, when the GLA generates a glKey message, or when the GLA processes a glAddMember there may be instances when GL memberĘs certificate has expired or is invalid. In these instances the GLO or GLA may request that the GL member provide a new certificate to avoid the GLA from being unable to generate a glKey message for the GL member. There may also be times when the GL member knows their certificate is about to expire or has been revoked and they will not be able to receive GL rekeys. 4.10.1 GLO and GLA Initiated Update Member Certificate The process for GLO initiated glUpdateCert is as follows: 1 - The GLO or GLA sends a SignedData.PKIData.controlSequence.glProvideCert request to the GL member. The GLO or GLA indicates the GL name in glName and the GL memberĘs name in glMemberName. 1.a - The GLO or GLA MAY optionally apply confidentiality to the request by encapsulating the SignedData.PKIData in an EnvelopedData (see section 3.2.1.2). If the GL memberĘs PKC has been revoked, the GLO or GLA MUST NOT use it to generate the EnvelopedData that encapsulates the glProvideCert request. 1.b - The GLO or GLA MAY also optionally apply another SignedData over the EnvelopedData (see section 3.2.1.2). 2 - Upon receipt of the glProvideCert message, the GL member verifies the GLOĘs or GLAĘs signature(s). If an additional SignedData and/or EnvelopedData encapsulates the response (see section 3.2.1.2 or 3.2.2), the GL member MUST verify the outer Turner 60 Internet-Draft S/MIME Symmetric Key Distribution March 2,2001 signature and/or decrypt the outer layer prior to verifying the signature on the inner most SignedData. 2.a - If the signatures do not verify, the GL member MUST return a cMCStatusInfo response indicating cMCStatus.failed and otherInfo.failInfo.badMessageCheck. 2.b - Else the signatures do verify, the GL member generates a Signed.PKIResponse.controlSequence.glUpdateCert that MUST include the GL name in glName, the member's name in glMember.glMemberName, their encryption certificate in glMember.certificates.pKC. The GL member MAY also include any attribute certificates associated with their encryption certificate in glMember.certificates.aC, and the certification path associated with their encryption and attribute certificates in glMember.certificates.certificationPath. 2.a - The GL member MAY optionally apply confidentiality to the request by encapsulating the SignedData.PKIResponse in an EnvelopedData (see section 3.2.1.2). If the GL memberĘs PKC has been revoked, the GL member MUST NOT use it to generate the EnvelopedData that encapsulates the glProvideCert request. 2.b - The GL member MAY also optionally apply another SignedData over the EnvelopedData (see section 3.2.1.2). 3 - Upon receipt of the glUpdateCert message, the GLO or GLA verifies the GL memberĘs signature(s). If an additional SignedData and/or EnvelopedData encapsulates the response (see section 3.2.1.2 or 3.2.2), the GL member MUST verify the outer signature and/or decrypt the outer layer prior to verifying the signature on the inner most SignedData. 3.a - If the signatures do not verify, the GLO or GLA MUST return a cMCStatusInfo response indicating cMCStatus.failed and otherInfo.failInfo.badMessageCheck. 3.b - Else the signatures do verify, the GLO or GLA MUST verify the memberĘs encryption certificate. 3.b.1 - If the memberĘs encryption certificate does not verify, the GLO MAY return either another glProvideCert request or a cMCStatusInfo with cMCStatus.failed and the reason why in cMCStatus.statusString. glProvideCert should be returned only a certain number of times because if the GL member does not have a valid certificate they will never be able to return one. 3.b.2 - Else the memberĘs encryption certificate does not verify, the GLA MAY return another glProvideCert request to the GL Turner 61 Internet-Draft S/MIME Symmetric Key Distribution March 2,2001 member or a cMCStatusInfo with cMCStatus.failed and the reason why in cMCStatus.statusString to the GLO. glProvideCert should be returned only a certain number of times because if the GL member does not have a valid certificate they will never be able to return one. 3.b.3 - Else the memberĘs encryption certificate does verify, the GLO or GLA will use it in subsequent glAddMember requests and glKey messages associated with the GL member. 4.10.2 GL Member Initiated Update Member Certificate The process for an unsolicited GL member glUpdateCert is as follows: 1 - The GL member sends a Signed.PKIData.controlSequence.glUpdateCert that MUST include the GL name in glName, the member's name in glMember.glMemberName, their encryption certificate in glMember.certificates.pKC. The GL member MAY also include any attribute certificates associated with their encryption certificate in glMember.certificates.aC, and the certification path associated with their encryption and attribute certificates in glMember.certificates.certificationPath. 1.a - The GL member MAY optionally apply confidentiality to the request by encapsulating the SignedData.PKIData in an EnvelopedData (see section 3.2.1.2). If the GL memberĘs PKC has been revoked, the GLO or GLA MUST NOT use it to generate the EnvelopedData that encapsulates the glProvideCert request. 1.b - The GL member MAY also optionally apply another SignedData over the EnvelopedData (see section 3.2.1.2). 2 - Upon receipt of the glUpdateCert message, the GLA verifies the GL memberĘs signature(s). If an additional SignedData and/or EnvelopedData encapsulates the response (see section 3.2.1.2 or 3.2.2), the GLA MUST verify the outer signature and/or decrypt the outer layer prior to verifying the signature on the inner most SignedData. 2.a - If the signatures do not verify, the GLA MUST return a cMCStatusInfo response indicating cMCStatus.failed and otherInfo.failInfo.badMessageCheck. 2.b - Else the signatures do verify, the GLA MUST verify the memberĘs encryption certificate. 2.b.1 - If the memberĘs encryption certificate does not verify, the GLA MAY return another glProvideCert request to the GL member or a cMCStatusInfo with cMCStatus.failed and the Turner 62 Internet-Draft S/MIME Symmetric Key Distribution March 2,2001 reason why in cMCStatus.statusString to the GLO. glProvideCert should be returned only a certain number of times because if the GL member does not have a valid certificate they will never be able to return one. 2.b.2 - Else the memberĘs encryption certificate does verify, the GLA will use it in subsequent glAddMember requests and glKey messages associated with the GL member. The GLA MUST also forward the glUpdateCert message to the GLO. 5 Distribution Message The GLA uses the glKey message to distribute new, shared KEK(s) after receiving glAddMember, glDeleteMember (for closed and managed GLs), glRekey, glkCompromise, or glkRefresh requests and returning a glSuccessInfo response for the respective request. Figure 12 depicts the protocol interactions to send out glKey messages. The procedures defined in this section MUST be implemented. 1 +----------+ +-------> | Member 1 | | +----------+ +-----+ | 1 +----------+ | GLA | ----+-------> | ... | +-----+ | +----------+ | 1 +----------+ +-------> | Member n | +----------+ Figure 12 - GL Key Distribution If the GL was setup with GLKeyAttributes.recipientsNotMutuallyAware set to FALSE, a separate glKey message MUST be sent to each GL member so as to not divulge information about the other GL members. When the glKey message is generated as a result of a: - glAddMember request, - glkComrpomise indication, - glkRefresh request, - glDeleteMember request with the GLĘs glAdministration set to managed or closed, - glRekey request with generationCounter set to zero (0) The GLA MUST use either the kari (see section 12.3.2 of CMS [2]) or ktri (see section 12.3.1 of CMS [2]) choice in glKey.glkWrapped.RecipientInfo to ensure only the intended recipients receive the shared KEK. The GLA MUST support the ktri choice. Turner 63 Internet-Draft S/MIME Symmetric Key Distribution March 2,2001 When the glKey message is generated as a result of a glRekey request with generationCounter greater than zero (0) or when the GLA controls rekeys, the GLA MAY use the kari, ktri, or kekri (see section 12.3.3 of CMS [2]) in glKey.glkWrapped.RecipientInfo to ensure only the intended recipients receive the shared KEK. The GLA MUST support the RecipientInfo.ktri choice. 5.1 Distribution Process When a glKey message is generated the process is as follows: 1 - The GLA MUST send a SignedData.PKIData.controlSequence.glKey to each member by including: glName, glIdentifier, glkWrapped, glkAlgorithm, glkNotBefore, and glkNotAfter. If the GLA can not generate a glKey message for the GL member because the GL memberĘs PKC has expired or is invalid, the GLA MAY send a glUpdateCert to the GL member requesting a new certificate be provided (see section 4.10). The number of glKey messages generated for the GL is described in section 3.1.16. 1.a - The GLA MAY optionally apply another confidentiality layer to the message by encapsulating the SignedData.PKIData in another EnvelopedData (see section 3.2.1.2). 1.b - The GLA MAY also optionally apply another SignedData over the EnvelopedData.SignedData.PKIData (see section 3.2.1.2). 2 - Upon receipt of the message, the GL members MUST verify the signature over the inner most SignedData.PKIData. If an additional SignedData and/or EnvelopedData encapsulates the message (see section 3.2.1.2 or 3.2.2), the GL Member MUST verify the outer signature and/or decrypt the outer layer prior to verifying the signature on the SignedData.PKIData.controlSequence.glKey. 2.a - If the signatures do not verify, the GL member MUST return a cMCStatusInfo response indicating cMCStatus.failed and otherInfo.failInfo.badMessageCheck. 2.b - Else the signatures do verify, the GL member process the RecipientInfos according to CMS [2]. Once unwrapped the GL member should store the shared KEK in a safe place. When stored, the glName, glIdentifier, and shared KEK should be associated. 6 Algorithms This section lists the algorithms that must be implemented. Additional algorithms that should be implemented are also included. Turner 64 Internet-Draft S/MIME Symmetric Key Distribution March 2,2001 6.1 KEK Generation Algorithm The shared KEK MUST be generated according to the security considerations section in CMS [2]. 6.2 Shared KEK Wrap Algorithm In the mechanisms described in sections 5, the shared KEK being distributed in glkWrapped MUST be protected by a key of equal or greater length (i.e., if a RC2 128-bit key is being distributed a key of 128-bits or greater must be used to protect the key). The algorithm object identifiers included in glkWrapped are as specified in 12.3 of CMS [2]. 6.3 Shared KEK Algorithm The shared KEK distributed and indicated in glkAlgorithm MUST support the symmetric key-encryption algorithms as specified in section 12.3.3 of CMS [2] 7 Transport SMTP [7] MUST be supported. All other transport mechanisms MAY be supported. 8 Using the Group Key This document was written with three specific scenarios in mind. Two to support mail list agents and one for general message distribution. Scenario 1 depicts the originator sending a public key (PK) protected message to a MLA who then uses the shared KEK (S) to redistribute the message to the members of the list. Scenario 2 depicts the originator sending a shared KEK protected message to a MLA who then redistributes the message to the members of the list (the MLA only adds additional recipients). Scenario 3 shows an originator sending a shared KEK protected message to a group of recipients without using the MLA. +----> +----> +----> PK +-----+ S | S +-----+ S | S | ----> | MLA | --+----> ----> | MLA | --+----> ----+----> +-----+ | +-----+ | | +----> +----> +----> Scenario 1 Scenario 2 Scenario 3 Turner 65 Internet-Draft S/MIME Symmetric Key Distribution March 2,2001 9 Security Considerations Only have GLOs that are trusted. Need to rekey closed and managed GLs if a member is deleted. GL members have to store some kind of information about who distributed the shared KEK to them so that they can make sure subsequent rekeys are originated from the same entity. Need to make sure you donĘt make the key size too small and duration long because people will have more time to attack the key. Need to make sure you donĘt make the generationCounter to large because people can attack the last key. If there are 14 keys outstanding each with a yearĘs duration attackers might be able determine the 14th key. 10 References 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. 2 Housley, R., "Cryptographic Message Syntax," RFC 2630, June 1999. 3 Myers, M., Liu, X., Schaad, J., Weinsten, J., "Certificate Management Message over CMS," draft-ietf-pkix-cmc-05.txt, July 1999. 4 Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 5 Ramsdale, B., "S/MIME Version 3 Message Specification," RFC 2633, June 1999. 6 Housley, R., Ford, W., Polk, W. and D. Solo, "Internet X.509 Public Key Infrastructure: Certificate and CRL Profile", RFC 2459, January 1999. 7 Postel, j., "Simple Mail Transport Protocol," RFC 821, August 1982. 11 Acknowledgements Thanks to Russ Housley and Jim Schaad for providing much of the background and review required to write this draft. Turner 66 Internet-Draft S/MIME Symmetric Key Distribution March 2,2001 12 Author's Addresses Sean Turner IECA, Inc. 9010 Edgepark Road Vienna, VA 22182 Phone: +1.703.628.3180 Email: turners@ieca.com Turner 67 Internet-Draft S/MIME Symmetric Key Distribution March 2,2001 Annex A: ASN.1 Module SMIMESymmetricKeyDistribution { TBD } DEFINITIONS IMPLICIT TAGS ::= BEGIN -- EXPORTS All -- -- The types and values defined in this module are exported for use -- in the other ASN.1 modules. Other applications may use them for -- their own purposes. IMPORTS -- Directory Authentication Framework (X.509) AlgorithmIdentifier, AttributeCertificate, Certificate, FROM AuthenticationFramework { joint-iso-itu-t ds(5) module(1) authenticationFramework(7) 3 } -- PKIX Part 1 - Implicit GeneralName FROM PKIX1Implicit88 {iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-pkix1-implicit-88(2)} -- Cryptographic Message Syntax RecipientInfos, id-alg-CMS3DESWrap FROM CryptographicMessageSyntax { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) modules(0) cms(1)}; -- This defines the GL Use KEK control attribute id-skd-glUseKEK OBJECT IDENTIFIER ::= { id-skd 1} GLUseKEK ::= SEQUENCE { glInfo GLInfo, glOwnerInfo SEQUENCE SIZE (1..MAX) OF GLOwnerInfo, glAdministration GLAdministration DEFAULT (1), glKeyAttributes GLKeyAttributes OPTIONAL } GLInfo ::= SEQUENCE { glName GeneralName, glAddress GeneralName } GLOwnerInfo ::= SEQUENCE { glOwnerName GeneralName, glOwnerAddress GeneralName } Turner 68 Internet-Draft S/MIME Symmetric Key Distribution March 2,2001 GLAdministration ::= INTEGER { unmanaged (0), managed (1), closed (2) } GLKeyAttributes ::= SEQUENCE { rekeyControlledByGLO [0] BOOLEAN DEFAULT FALSE, recipientsNotMutuallyAware [1] BOOLEAN DEFAULT TRUE, duration [2] INTEGER DEAULT (0), generationCounter [3] INTEGER DEFAULT (2), requestedAlgorithm [4] AlgorithmIdentifier DEFAULT (id-alg-CMS3DESwrap) } -- This defines the Delete GL control attribute. -- It has the simple type GeneralName. id-skd-glDelete OBJECT IDENTIFIER ::= { id-skd 2} -- This defines the Add GL Member control attribute id-skd-glAddMember OBJECT IDENTIFIER ::= { id-skd 3} GLAddMember ::= SEQUENCE { glName GeneralName, glMember GLMember } GLMember ::= SEQUENCE { glMemberName GeneralName, glMemberAddress GeneralName OPTIONAL, certificates Certificates OPTIONAL } Certificates ::= SEQUENCE { pKC Certificate OPTIONAL, -- See X.509 aC SEQUENCE SIZE (1.. MAX) OF AttributeCertificate OPTIONAL, -- See X.509 certificationPath CertificateSet OPTIONAL } -- From CMS [2] CertificateSet ::= SET SIZE (1..MAX) OF CertificateChoices CertificateChoices ::= CHOICE { certificate Certificate, -- See X.509 extendedCertificate [0] IMPLICIT ExtendedCertificate, -- Obsolete attrCert [1] IMPLICIT AttributeCertificate } -- See X.509 and X9.57 Turner 69 Internet-Draft S/MIME Symmetric Key Distribution March 2,2001 -- This defines the Delete GL Member control attribute id-skd-glDeleteMember OBJECT IDENTIFIER ::= { id-skd 4} GLDeleteMember ::= SEQUENCE { glName GeneralName, glMemberToDelete GeneralName } -- This defines the Delete GL Member control attribute id-skd-glRekey OBJECT IDENTIFIER ::= { id-skd 5} GLRekey ::= SEQUENCE { glName GeneralName, glAdministration GLAdministration OPTIONAL, glNewKeyAttributes GLNewKeyAttributes OPTIONAL, glRekeyAllGLKeys BOOLEAN OPTIONAL } GLNewKeyAttributes ::= SEQUENCE { rekeyControlledByGLO [0] BOOLEAN OPTIONAL, recipientsNotMutuallyAware [1] BOOLEAN OPTIONAL, duration [2] INTEGER OPTIONAL, generationCounter [3] INTEGER OPTIONAL, requestedAlgorithm [4] AlgorithmIdentifier OPTIONAL } -- This defines the Add and Delete GL Owner control attributes id-skd-glAddOwner OBJECT IDENTIFIER ::= { id-skd 6} id-skd-glRemoveOwner OBJECT IDENTIFIER ::= { id-skd 7} GLOwnerAdministration ::= SEQUENCE { glName GeneralName, glOwnerInfo GLOwnerInfo } -- This defines the GL Key Compromise control attribute. -- It has the simple type GeneralName. id-skd-glKeyCompromise OBJECT IDENTIFIER ::= { id-skd 8} -- This defines the GL Key Refresh control attribute. id-skd-glkRefresh OBJECT IDENTIFIER ::= { id-skd 9} GLKRefresh ::= { glName GeneralName, dates SEQUENCE (1..MAX) OF Date } Date ::= { start GeneralizedTime, end GeneralizedTime OPTIONAL } Turner 70 Internet-Draft S/MIME Symmetric Key Distribution March 2,2001 -- This defines the GLA Query Request control attribute. id-skd-glaQueryRequest OBJECT IDENTIFIER ::= { id-skd X} GLAQueryRequest ::= SEQUENCE { glaRequestType OBJECT IDENTIFIER, glaRequestValue ANY DEFINED BY glaResponseType } -- This defines the Algorithm Request id-rt-algorithmSupported { id-tbd } -- This defines the GLA Query Response control attribute. id-skd-glaQueryResponse OBJECT IDENTIFIER ::= { id-skd X} GLAQueryResponse ::= SEQUENCE { glaResponseType OBJECT IDENTIFIER, glaResponseValue ANY DEFINED BY glaResponseType } -- Note that the response for algorithmSupported request is the -- smimeCapabilities attribute as defined in MsgSpec [5]. -- This defines the control attribute to request an updated -- certificate to the GLA. id-skd-glProvideCert OBJECT IDENTIFIER ::= { id-skd X} GLManageCert ::= SEQUENCE { glName GeneralName, glMember GLMember } -- This defines the control attribute to return an updated -- certificate to the GLA. It has the type GLManageCert. id-skd-glManageCert OBJECT IDENTIFIER ::= { id-skd X} -- This defines the control attribute to distribute the GL shared -- KEK. id-skd-glKey OBJECT IDENTIFIER ::= { id-skd X} Turner 71 Internet-Draft S/MIME Symmetric Key Distribution March 2,2001 GLKey ::= SEQUENCE { glName GeneralName, glIdentifier OCTET STRING, glkWrapped RecipientInfos, -- See CMS [2] glkAlgorithm AlgorithmIdentifier, glkNotBefore GeneralizedTime, glkNotAfter GeneralizedTime } END -- SMIMESymmetricKeyDistribution September 2, 2001 Turner 72