SMIME Working Group S. Turner Internet Draft IECA Document: draft-ietf-smime-symkeydist-01.txt July 2000 Expires: January 14, 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 <http://www.imc.org/ietf-smime/>. 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 mechanisms use 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 July 14, 2000 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....................................................4 3. PROTOCOL INTERACTIONS...........................................6 3.1 CONTROL ATTRIBUTES.............................................7 3.1.1 GL USE KEK...................................................7 3.1.2 GL DELETE...................................................10 3.1.3 GL ADD MEMBERS..............................................10 3.1.4 GL DELETE MEMBERS...........................................11 3.1.5 GL REKEY....................................................12 3.1.6 GL ADD OWNER................................................13 3.1.7 GL REMOVE OWNER.............................................13 3.1.8 GL KEY COMPROMISE...........................................14 3.1.9 GL KEY REFRESH..............................................14 3.1.10 GL SUCCESS INFORMATION.....................................14 3.1.11 GL FAIL INFORMATION........................................15 3.1.12 GLA QUERY REQUEST..........................................17 3.1.13 GLA QUERY RESPONSE.........................................18 3.1.14 GL KEY.....................................................18 3.2 USE OF CMC, CMS, AND PKIX.....................................19 3.2.1 PROTECTION LAYERS...........................................19 3.2.1.1 MINIMUM PROTECTION........................................19 3.2.1.2 ADDITIONAL PROTECTION.....................................20 3.2.2 COMBINING REQUESTS AND RESPONSES............................20 3.2.3 GLA GENERATED MESSAGES......................................22 3.2.4 CMC CONTROL ATTRIBUTES......................................23 3.2.5 PKIX........................................................23 4 ADMINISTRATIVE MESSAGES.........................................23 4.1 ASSIGN KEK TO GL..............................................23 4.2 DELETE GL FROM GLA............................................26 4.3 ADD MEMBERS TO GL.............................................28 4.3.1 GLO INITIATED ADDITIONS.....................................29 4.3.2 PROSPECTIVE MEMBER INITIATED ADDITIONS......................34 4.4 DELETE MEMBERS FROM GL........................................36 4.4.1 GLO INITIATED DELETIONS.....................................37 4.4.2 MEMBER INITIATED DELETIONS..................................41 4.5 REQUEST REKEY OF GL...........................................42 4.5.1 GLO INITIATED REKEY REQUESTS................................43 4.5.2 GLA INITIATED REKEY REQUESTS................................45 4.6 CHANGE GLO....................................................45 4.7 INDICATE KEK COMPROMISE.......................................47 4.8 REQUEST KEK REFRESH...........................................49 4.9 GLA QUERY REQUEST AND RESPONSE................................50 5 DISTRIBUTION MESSAGE............................................52 5.1 DISTRIBUTION PROCESS..........................................53 Turner 2 Internet-Draft S/MIME Symmetric Key Distribution July 14, 2000 6 KEY WRAPPING....................................................53 7 ALGORITHMS......................................................54 8 TRANSPORT.......................................................54 9 USING THE GROUP KEY.............................................54 10 SCHEMA REQUIREMENTS............................................54 11 SECURITY CONSIDERATIONS........................................54 12 REFERENCES.....................................................55 13 ACKNOWLEDGEMENTS...............................................55 14 AUTHOR'S ADDRESSES.............................................55 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. 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 Turner 3 Internet-Draft S/MIME Symmetric Key Distribution July 14, 2000 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. 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. Turner 4 Internet-Draft S/MIME Symmetric Key Distribution July 14, 2000 +----------------------------------------------+ | 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. KMAs may be differentiated by the 'goodness' of the random number used to generate the shared KEK or the key management technique used to distribute the shared KEK. Outside the GLA, KMAs are differentiated by the digital signatures they apply to the messages they generate. 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. 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 Turner 5 Internet-Draft S/MIME Symmetric Key Distribution July 14, 2000 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. 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 paragraphs describe the ASN.1 for both the administration and distribution messages. Paragraph 4 describes how to use the administration messages and paragraph 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 July 14, 2000 3.1 Control Attributes The messages are based on including control attributes in CMC's PKIData.controlSequence for requests and CMC's ResponseBody.controlSequence for responses. The content-types PKIData and PKIResponse are then encapsulated in CMS's SignedData or EnvelopedData, or a combination of the two (see paragraph 3.2). The following are the control attributes defined in this document: Implementation Requirement Control Attribute OID Syntax -------------- ------------------ ----------- ----------------- MAY glUseKEK id-skd 1 GLUseKEK MAY glDelete id-skd 2 GLDelete MAY glAddMembers id-skd 3 GLAddMembers MAY glDeleteMembers id-skd 4 GLDeleteMembers MAY glRekey id-skd 5 GLRekey MAY glAddOwners id-skd 6 GLAddOwners MAY glRemoveOwners id-skd 7 GLRemoveOwners MAY glkCompromise id-skd 8 GLKCompromise SHOULD glkRefresh id-skd 9 GLKRefresh MAY glSuccessInfo id-skd 10 GLSuccessInfo MAY glFailInfo id-skd 11 GLFailInfo MAY glAQueryRequest id-skd 12 GLAQueryRequest MAY glAQueryResponse id-skd 13 GLAQueryResponse MUST glKey id-skd 14 GLKey GLSuccessInfo, GLFailInfo, and GLAQueryResponse are responses and go into the PKIResponse content-type, all other messages are requests and go into the PKIData content-type. 3.1.1 GL USE KEK The GLO uses GLUseKEK to request that a shared KEK be assigned to a GL. GLUseKEK ::= SEQUENCE { glName GeneralName, glOwner SEQUENCE SIZE (1..MAX) OF GeneralName, glAdministration GLAdministration, glDistributionMethod GLDistributionMethod, glKeyAttributes [0] GLKeyAttributes OPTIONAL } GLAdministration ::= INTEGER { unmanaged (0), managed (1), closed (2) } Turner 7 Internet-Draft S/MIME Symmetric Key Distribution July 14, 2000 GLDistributionMethod ::= CHOICE { rfc822Name [0] IA5String, x400Address ORAddress, directoryName Name, uniformResourceIdentifier [1] IA5String } GLKeyAttributes ::= SEQUENCE { rekeyControlledByGLO [0] BOOLEAN DEFAULT FALSE, recipientMutuallyAware [1] BOOLEAN DEFAULT TRUE, duration [2] INTEGER DEAULT (0), generationCounter [3] INTEGER DEFAULT {2}, requestedAlgorithm [4] AlgorithmIdentifier OPTIONAL } The fields in GLUseKEK have the following meaning: - glName is the name of the GL. The name MUST be unique for a given GLA. - glOwner indicates the owner of the GL. One of the names in glOwner MUST match one of the names in the certificate used to sign this SignedData.PKIData creating the GL (i.e., the immediate signer). Multiple GLOs MAY be indicated if glAdministration is set to managed or closed. - glAdministration indicates how the GL should be administered. The default is for the list to be unmanaged and to accept requests from prospective members. Three possibilities exist: - 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 and deleted from the GL, but the request is sent to GLO for review. The requests are redirected to the GLO. 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 and deleted from the GL. The GLA will only accept GLAddMembers and GLDeleteMembers requests from the GLO. - glDistributionMethod indicates the mechanism the GLA should distribute shared KEKs. Internet mail (rfc822Name) MUST be supported and X.400 (x400Address), X.500 (directoryName), and web (uniformResourceIdentifier) MAY be supported (see paragraph 8). - glKeyAttributes indicates the attributes the GLO wants the GLA to assign to the shared KEK. If the field is omitted, GL rekeys Turner 8 Internet-Draft S/MIME Symmetric Key Distribution July 14, 2000 will be controlled by the GLA, the recipients are allowed to know about one another, the algorithm will be as specified in paragraph 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. - recipientsMutuallyAware 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. 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 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. See paragraphs 4.5 and 5 for more on rekey. Turner 9 Internet-Draft S/MIME Symmetric Key Distribution July 14, 2000 - requestedAlgorithm indicates the algorithm and any parameters the GLO wants the GLA to use to generate the shared KEK. See paragraph 7 for more on algorithms. 3.1.2 GL Delete GLOs use GLDelete to request that a GL be deleted from the GLA. GLDelete ::= GLNameAndIdentifier GLNameAndIdentifier ::= SEQUENCE { glName GeneralName, glIdentifier GLIdentifier OPTIONAL } The fields in GLDelete have the following meaning: - glName indicates the name of the GL to be deleted. - glIdentifier indicates the identifier of the GL to be deleted. It MAY be omitted if it is unknown (e.g., the GLO hasn't received a GLSuccessInfo assigning the glIdentifier to the GL) or has been lost by the GLO. 3.1.3 GL Add Members GLOs use GLAddMembers to request addition of new members and prospective GL members' use GLAddMembers to request being added to the GL. GLAddMembers ::= SEQUENCE { glName GeneralName, glMembers SEQUENCE SIZE (1..MAX) OF GLMember, glIdentifier GLIdentifier OPTIONAL } GLMember ::= SEQUENCE { glMemberName GeneralName, certificates Certificates } Certificates ::= SEQUENCE { membersPKC Certificate, -- See X.509 membersAC SEQUENCE OF AttributeCertificate OPTIONAL, -- See X.509 certificationPath CertificateSet OPTIONAL } -- From CMS [2] CertificateSet ::= SET OF CertificateChoices Turner 10 Internet-Draft S/MIME Symmetric Key Distribution July 14, 2000 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. - glMembers indicates the particulars for the GL member(s) to be added to the GL. GLMemberName indicates the name of the GL member. certificates.membersPKC includes the member's encryption certificate that will be used to encrypt the shared KEK for that member. certificates.membersAC 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). - glIdentifier indicates the identifier of the GL to which the member should be added. It MAY be omitted if it is unknown (e.g., the GLO hasn't received a GLSuccessInfo assigning the glIdentifier to the GL) or has been lost by the GLO. The prospective GL member MAY omit this field. The GLO MUST omit the field if the GLAddMembers associated GLUseKEK message is included in the same SignedData.PKIData content-type. 3.1.4 GL Delete Members GLOs use GLDeleteMembers to request deletion of GL members and prospective non-GL members use GLDeleteMembers to request being removed from the GL. GLDeleteMembers ::= SEQUENCE { glName GeneralName, glMembersToDelete SEQUENCE SIZE (1..MAX) OF GeneralName, glIdentifier GLIdentifier OPTIONAL } The fields in GLDeleteMembers have the following meaning: - glName indicates the name of the GL from which the member should be removed. Turner 11 Internet-Draft S/MIME Symmetric Key Distribution July 14, 2000 - glMembersToDelete indicates the name of the member to be deleted. - glIdentifier indicates the identifier of the GL to which the member should be deleted. The prospective non-GL member MUST include the field. The GLO MAY omit this field if it is unknown (e.g., the GLO hasn't received a GLSuccessInfo assigning the glIdentifier to the GL) or has been lost by the GLO. 3.1.5 GL Rekey GLOs use the GLRekey to request a GL rekey. GLRekey ::= SEQUENCE { glName GeneralName, glIdentifier GLIdentifier, glOwner SEQUENCE SIZE (0..MAX) OF GeneralName, glAdministration GLAdministration OPTIONAL, glDistributionMethod GLDistributionMethod OPTIONAL, glKeyAttributes GLKeyAttributes OPTIONAL } The fields in GLRekey have the following meaning: - glName indicates the name of the GL to be rekeyed. - glIdentifier identifies the shared KEK to be rekeyed. - glOwner indicates the owner(s) of the GL. The field is only included if there is a change from the registered GLOs. - glAdministration indicates how the GL should be administered. See paragraph 3.1.1 for the three options. This field is only included if there is a change from the previously registered administered. - glDistributionMethod indicates the mechanism the shared KEK should be distributed. The field is only included if there is a change from the previously registered glDistributionMethod. - glKeyAttributes 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. If the value zero (0) is specified in generationCounter the GLO is indicating that it wants all of the outstanding GL shared KEKs rekeyed. For example, suppose the GLO used the GLUseKEK with duration set to two (2) and the GLRekey message is sent during the first duration with generationCounter set to zero (0). The GLA would know to generate a GLKey message Turner 12 Internet-Draft S/MIME Symmetric Key Distribution July 14, 2000 to replace both the shared KEK currently being used and the shared KEK for the second duration. 3.1.6 GL Add Owner GLOs use the GLAddOwners to request that a new GLO be allowed to administer the GL. These requests are only applicable to GLs that are managed (i.e., administered.managed) or closed (i.e., administered.closed). GLAddOwners ::= GLOwnerAdministration GLOwnerAdministration ::= SEQUENCE { glName GeneralName, glOwner SEQUENCE SIZE (1..MAX) OF GeneralName, glIdentifier GLIdentifier OPTIONAL } The fields in GLAddOwners have the following meaning: - glName indicates the name of the GL to which the new GLO should be associated. - glOwner indicates the name(s) of the new GLO(s). - glIdentifier optionally indicates the identifier of the GL to which the GLO should be associated. It MAY be omitted if it is unknown (e.g., the GLO hasn't received a GLSuccessInfo assigning the glIdentifier to the GL) or has been lost by the GLO 3.1.7 GL Remove Owner GLOs use the GLRemoveOwners to request that a GLO be disassociated with the GL. These requests are only applicable to managed GLs. GLRemoveOwners ::= GLOwnerAdministration The fields in GLRemoveOwners have the following meaning: - glName indicates the name of the GL to which the GLO should be disassociated. - glOwner indicates the name of the GLO. - glIdentifier optionally indicates the identifier of the GL to which the GLO should be disassociated. It MAY be omitted if it is unknown (e.g., the GLO hasn't received a GLSuccessInfo assigning the glIdentifier to the GL) or has been lost by the GLO Turner 13 Internet-Draft S/MIME Symmetric Key Distribution July 14, 2000 3.1.8 GL Key Compromise GL members use GLKCompromise to indicate that the shared KEK they possessed has been compromised. GLKCompromise ::= GLNameAndIdentifier The fields in GLKeyCompromise have the following meanings: - glName indicates the name of the GL. - glIdentifier indicates the identifier of the GL for which the shared KEK is associated. The GL members MAY omit this field if it is unknown. 3.1.9 GL Key Refresh GL members use the GLKRefresh to request that the shared KEK be redistributed to them. GLKRefresh ::= GLNameAndIdentifier The fields in GLKRefresh have to following meaning: - glName indicates the name of the GL. - glIdentifier indicates the identifier of the GL for which the shared KEK is associated. The GL members MAY omit this field if it is unknown. 3.1.10 GL Success Information The GLA uses GLSuccessInfo to indicate a successful result of an administrative message. GLSuccessInfo ::= SEQUENCE { glName GeneralName, glIdentifier GLIdentifier, action SEQUENCE SIZE (1..MAX) OF Action } ** With multiple GLOs do we want to indicate which GLO asked for the action to be performed? ** Action ::= SEQUENCE { actionCode ActionCode, glMemberName [0] GeneralName OPTIONAL, glOwnerName [1] GeneralName OPTIONAL } Turner 14 Internet-Draft S/MIME Symmetric Key Distribution July 14, 2000 ActionCode ::= INTEGER { assignedKEK (0), deletedGL (1), addedMember (2), deletedMember (3), rekeyedGL (4), addedGLO (5), removedGLO (6) } The fields in GLSuccessInfo have the following meaning: - glName indicates the name of the GL. - glIdentifier identifies the specific GL on the GLA (the GLA may support multiple GLs). - 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 or deleted to or from a specific GL, whether the GL rekeyed, whether a new GLO was added, and whether a GLO was deleted. If members were added or deleted from a GL the members MUST be indicated in glMemberName. If a GLO was added or deleted from the GL, the GLO(s) MUST be indicated in glOwnerName. 3.1.11 GL Fail Information The GLA uses GLFailInfo to indicate that there was a problem performing a requested action. GLFailInfo ::= SEQUENCE { glName GeneralName, error SEQUENCE SIZE (1..MAX) OF Error, glIdentifier GLIdentifier OPTIONAL } ** With multiple GLOs do we want to indicate which GLO asked for the action to be performed? ** Error ::= SEQUENCE { errorCode ErrorCode, glMemberName [0] GeneralName OPTIONAL, glOwnerName [1] GeneralName OPTIONAL } Turner 15 Internet-Draft S/MIME Symmetric Key Distribution July 14, 2000 ErrorCode ::= INTEGER { unspecified (0), closedGL (1) unsupportedDuration (2) unsupportedDistribtuionMethod (3), invalidCert (4), unsupportedAlgorithm (5), noGLONameMatch (6), invalidGLName (7), invalidGLNameGLIdentifierCombination (8), nameAlreadyInUse (9), noSpam (10), deniedAccess (11), alreadyAMember (12), notAMember (13), alreadyAnOwner (14) notAnOwner (15) } 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 the error corresponds to a GL member or GLO, a separate Error sequence MUST be used for each GL member or GLO. The errors are returned under the following conditions: - unspecified indicates that the GLA is unable to perform the requested action but is unwilling 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. - unsupportedDistribtuionMethod indicates that the GLA does not support any of the requested delivery methods. - invalidCert indicates the member's encryption certificate was not verifiable (i.e., signature did not validate, certificate present on a CRL, etc.) - unsupportedAlgorithm indicates the GLA does not support the requested algorithm. - noGLONameMatch indicates the name in one of the certificates used to sign a request does not match the name of the registered GLO. Turner 16 Internet-Draft S/MIME Symmetric Key Distribution July 14, 2000 - invalidGLName indicates the GLA does not support the glName present in the request. - invalidGLNameGLIdentifierCombination indicates the GLA does not support the glName and glIdentifier 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 glMembers.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-GL member is not a GLO. - glIdentifier identifies the specific GL. It MAY be omitted if the response is a result of a GLUseKEK request otherwise it MUST be present. 3.1.12 GLA Query Request GLOs use the GLQueryRequest to ascertain what type of GL the GLA supports. GLAQueryRequest ::= SEQUENCE SIZE (1..MAX) OF GLOQuestions GLOQuestions ::= INTEGER { supportedAlgorithms (0), distributionMethods (1) } The fields in GLAQueryRequest have the following meaning: - supportedAlgorithms indicates the GLO would like to know the algorithms the GLA supports for generating and distribution the shared KEK. - distributionMethod indicates the GLO would like to know the distribution methods the GLA supports for distributing the shared KEK. Turner 17 Internet-Draft S/MIME Symmetric Key Distribution July 14, 2000 3.1.13 GLA Query Response GLA's return the GLAQueryResponse after receiving a GLAQueryRequest. GLAQueryResponse ::= SEQUENCE { supportedAlgorithms SEQUENCE OF AlgorithmIdentifier OPTIONAL, distributionMethods SEQUENCE OF GLDistributionMethod OPTIONAL } The fields in GLAQueryResponse have the following meaning: - supportAlgorithms indicates the algorithm(s) and parameters that GLA supports for generating and distributing the shared KEK. - distributionMethod indicates the distribution method(s) the GLA supports for distribution the shared KEK. 3.1.14 GL Key The GLA uses GLKey to distribute the shared KEK. GLKey ::= SEQUENCE { glName GeneralName, glIdentifier GLIdentifier, glkWrapped RecipientInfos, -- See CMS [2] glkAlgorithm AlgorithmIdentifier, glkNotBefore GeneralizedTime, glkNotAfter GeneralizedTime } GLIdentifier ::= CHOICE { issuerNameAndCounter [0] IssuerNameAndCounter, keyIdentifierAndCounter [1] KeyIdentifierAndCounter } IssuerNameAndCounter ::= SEQUENCE { issuer GeneralName, counter INTEGER } KeyIdentifierAndCounter ::= SEQUENCE { keyIdentifier SubjectKeyIdentifier, counter INTEGER } SubjectKeyIdentifier ::= OCTET STRING The fields in GLKey have the following meaning: - glName is the name of the GL. - glIdentifier identifies the specific GL on the GLA (the GLA may support multiple GLs). Two options are provided. The issuerNameAndCounter alternative identifies the GLA's who Turner 18 Internet-Draft S/MIME Symmetric Key Distribution July 14, 2000 created shared KEK and a counter. The keyIdentifierAndCounter choice identifies the GLA's certificate that was used to encrypt the shared KEK for the GL members and a counter. In either case the counter is a monotonically increasing number. The keyIdentifierAndCounter choice MUST be supported. - glkWrapped is the GL's wrapped shared KEK. The RecipientInfos shall be generated as specified in paragraph 6.2 of CMS [2]. The kari RecipientInfo choice MUST be supported. The EncryptedKey field, which is the shared KEK, MUST be generated according to the paragraph concerning random number generation in the security considerations of CMS [2]. - glkAlgorithm identifies the algorithm the shared KEK is used with. - glkNotBefore indicates the date at which the shared KEK is considered valid. GeneralizedTime values MUST be expressed Greenwich Mean Time (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 Greenwich Mean Time (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. 3.2 Use of CMC, CMS, and PKIX 3.2.1 Protection Layers 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]. Turner 19 Internet-Draft S/MIME Symmetric Key Distribution July 14, 2000 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 corresponding outgoing message MUST also be encrypted. 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 supposed to forward the GL member request 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 responses MAY be combined in one PKIData or PKIResponse by using PKIData.cmsSequence and PKIResponse.cmsSequence. A separate cmsSequence MUST be used for 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: Turner 20 Internet-Draft S/MIME Symmetric Key Distribution July 14, 2000 Multiple Request and Response Request Response ------- -------- SignedData SignedData PKIData PKIResponse cmsSequence cmsSequence SignedData SignedData PKIData PKIResponse controlSequence controlSequence Zero or more requests Zero or more responses corresponding to one GL. corresponding to one GL. SignedData SignedData PKIData PKIResponse controlSequence controlSequence Zero or more requests Zero or more responses corresponding to one GL. corresponding to one GL. When applying confidentiality to multiple requests and responses, either each request or response MAY be encrypted individually or all of the requests/response MAY be included in one EnvelopedData. The following is a depiction of the choices using PKIData: Confidentiality of Multiple Requests and Responses Individually Wrapped Wrapped Together -------------------- ---------------- SignedData EnvelopedData PKIData SignedData cmsSequence PKIData EnvelopedData cmsSequence SignedData SignedData PKIData PKIResponse controlSequence controlSequence Zero or more requests Zero or more requests corresponding to one GL. corresponding to one GL. EnvelopedData SignedData SignedData PKIData PKIData controlSequence controlSequence Zero or more requests Zero or more requests corresponding to one GL. corresponding to one GL. Turner 21 Internet-Draft S/MIME Symmetric Key Distribution July 14, 2000 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 & GLDeleteMembers GLUseKEK & GLRekey GLUseKEK & GLDelete GLDelete & GLAddMembers GLDelete & GLDeleteMembers GLDelete & GLRekey GLDelete & GLAddOwners GLDelete & GLRemoveOwners GLFailInfo & GLKey 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 GLAddMembers, GLAddMembers before GLRekey, GLDeleteMembers before GLRekey, and GLSuccessInfo before GLKey. ** Need to think more about the priority of processing ** 3.2.3 GLA Generated Messages When the GLO generates a GLSuccessInfo, it generates one for the GL member and another for the GLO, depending on the actionCode. action.actionCode values of assignedKEK, deletedGL, rekeyedGL, addedGLO, and deletedGLO are not returned to GL members. Likewise, when the GLO generates GLFailInfo it generates one for the GL member and one for the GLO, depending on the actionCode. error values of unsupportedDuration, unsupportedDeliveryMethod, unsupportedAlgorithm, noGLONameMatch, nameAlreadyInUse, alreadyAnOwner, notAnOwner are not returned to GL members. Separate GLSucessInfo, GLFailInfo, and GLKey messages MUST be generated for each recipient if GL was setup with GLKeyAttributes.recipientMutuallyAware set to FALSE. If the GL has multiple GLOs, the GLA MUST send a copy of all GLSuccessInfo and GLFailInfo messages to each GLO. If a GL is managed and the GLA receives a prospective GL member add or delete request or the GLO receives a GLFailInfo from the GL. and the GL is managed, the GLA forwards the request to the GLO for review. An additional, SignedData MUST be applied to the forwarded request as follows: Turner 22 Internet-Draft S/MIME Symmetric Key Distribution July 14, 2000 GLA Forwarded Requests ---------------------- SignedData PKIData cmsSequence PKIData controlSequence 3.2.4 CMC Control Attributes ** Elaborate more ** Can use: CMCFailInfo.badMessageCheck - To indicate signature did not verify. transactionId - To track particular requests/responses. senderNonce and recipientNonce - For sequence integrity. 3.2.5 PKIX Signatures, certificates, and CRLs are verified according to PKIX [5]. Name matching is performed according to PKIX [5]. 4 Administrative Messages There are a number of administrative messages that must be performed to manage a GL: creating the GL, deleting the GL, adding members to the GL, deleting members from the GL, and requesting a group rekey. The following sections describe each of messages' request and response combinations in detail. The GLKRefresh procedures in paragraph 4.8 SHOULD be implemented all other procedures MAY be implemented. 4.1 Assign KEK To GL Prior to generating a group key, a GL MUST be setup. Figure 3 depicts the protocol interactions to setup a GL. Note that error messages are not depicted in Figure 3. +-----+ 1 2 +-----+ | GLA | <-------> | GLO | +-----+ +-----+ Figure 3 - Create Group List Turner 23 Internet-Draft S/MIME Symmetric Key Distribution July 14, 2000 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, glOwner, glAdministration, distributionMethod. 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 should be sent to each recipient in recipientMutuallyAware, 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 duration and generationCounter, respectively. a - If the GLO knows of members to be added to the GL, the GLAddMembers request MAY be included in the same controlSequence as the GLUseKEK request (see paragraph 3.2.2). The GLO MUST indicate the same glName in the GLAddMembers request as in GLUseKEK.glName. The GLO MUST also include the member's encryption certificate in certificate.membersPKC. The GLO MAY also include any attribute certificates associated with the member's encryption certificate in membersAC and the certification path for the member's encryption and attribute certificates. The GLO MUST omit the glIdentifier, as it is unknown at this point in the setup procedure. b - The GLO MAY optionally apply confidentiality to the request by encapsulating the SignedData.PKIData in an EnvelopedData (see paragraph 3.2.1.2). c - The GLO MAY also optionally apply another SignedData over the EnvelopedData (see paragraph 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 paragraph 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. a - If the signature(s) does(do) not verify, the GLA MUST return a response indicating CMCFailInfo.badMessageCheck. b - If the signature(s) does(do) verify, the GLA MUST check that one of the names in the certificate used to sign the request matches the name in CreateGL.glOwner. Turner 24 Internet-Draft S/MIME Symmetric Key Distribution July 14, 2000 1 - If the names do not match, the GLA MUST return a response indicating GLFailInfo.errorCode.noGLONameMatch. 2 - If names do all match, the GLA MUST ensure the combination of the requested glName is not already in use. The GLA MUST also check any GLAddMembers included within the controlSequence with this GLCreate. Further processing of the GLAddMembers is covered in paragraph 4.3. a - If the glName is already in use the GLA MUST return a response indicating GLFailInfo.errorCode.nameAlreadyInUse. b - If the requestedAlgorithm is not supported, the GLA MUST return a response indicating GLFailInfo.errorCode.unsupportedAlgorithm. c - If the duration is not supportable, determining this is beyond the scope of this document, the GLA MUST return a response indicating GLFailInfo.errorCode.unsupportedDuration. d - If 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. e - If the glName distribution is not already in use, the duration is supportable, and the requestedAlgorithm is supported, the GLA MUST return a GLSuccessInfo to all GLOs 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, distributionMethod, glOwner, and any member that has been added. 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 paragraph 3.2.1.2). 2 - The GLA MAY also optionally apply another SignedData over the EnvelopedData (see paragraph 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 paragraph 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. Turner 25 Internet-Draft S/MIME Symmetric Key Distribution July 14, 2000 a - If the signatures do not verify, the GLO MUST return a response indicating CMCFailInfo.badMessageCheck. b - If the signatures do verify and the response was GLSuccessInfo, the GLO has successfully created the GL. c - If 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 distribution methods supported by the GLA (see paragraph 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 GLO MUST include the name of the GL in glName. The GLO MAY also include the GL identifier glIdentifier. b - The GLO MAY optionally apply confidentiality to the request by encapsulating the SignedData.PKIData in an EnvelopedData (see paragraph 3.2.1.2). c - The GLO MAY also optionally apply another SignedData over the EnvelopedData (see paragraph 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 paragraph 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. a - If the signature(s) does(do) not verify, the GLA MUST return a response indicating CMCFailInfo.badMessageCheck. Turner 26 Internet-Draft S/MIME Symmetric Key Distribution July 14, 2000 b - If the signature(s) does(do) verify, the GLA MUST make sure the GL is supported by checking either that the glName is supported (in the case the glIdentifier is omitted) or that the combination of glName and glIdentifier matches a glName and glIdentifier combination stored on the GLA. 1 - If the glIdentifier is omitted and the glName is not supported by the GLA, the GLA MUST return a response indicating GLFailInfo.errorCode.invalidGLName. 2 - If the glName and glIdentifier are present and do not match a GL stored on the GLA, the GLA MUST return a response indicating GLFailInfo.errorCode.invalidGLNameGLIdentifierCombination. 3 - If the glIdentifier is omitted and the glName is supported by the GLA or if the glIdentifier/glName combination is supported by the GLA, the GLA MUST ensure a registered GLO signed the GLDelete request by checking if the name present in the digital signature certificate used to sign the GLDelete request matches one of the registered GLOs. a - If the names do not match, the GLA MUST return a response indicating GLFailInfo.errorCode.noGLONameMatch. b - If 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. c - If all the names do match, the GLA MUST return to all the GLOs a GLSucessInfo indicating the glName, the corresponding glIdentifier, and an action.actionCode.deletedGL (2 in Figure 4). The GLA MUST not accept further requests for member additions, member deletions, or group rekeys for this GL. 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 paragraph 3.2.1.2). 2 - The GLA MAY also optionally apply another SignedData over the EnvelopedData (see paragraph 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 paragraph 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. Turner 27 Internet-Draft S/MIME Symmetric Key Distribution July 14, 2000 a - If the signature(s) does(do) not verify, the GLO MUST return a response indicating CMCFailInfo.badMessageCheck. b - If the signatures do verify and the response was GLSuccessInfo, the GLO has successfully deleted the GL. c - If 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 GLAddMembers request. There are however different scenarios that should be supported. Either the GLO or prospective members may submit the GLAddMembers request to the GLA, but the GLA processes the requests differently. The GLO can submit the request at any time to add members to the GL, and the GLA, once it has verified the request came from the 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 paragraph 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. Where there are multiple GLOs for a GL, which GLO the request is forwarded to is beyond the scope of this document. In the closed case, the GLA will not accept requests from prospective members. The following paragraphs describe the processing required by the GLO, GLA, and prospective GL members depending on where the request originated, either from the GLO or from prospective members. Figure 5 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 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 Turner 28 Internet-Draft S/MIME Symmetric Key Distribution July 14, 2000 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 MUST be rekeyed to maintain the secrecy of the group. An option to rekeying the managed GLs when a member is added is to generate a new GL with a different group key. Group rekeying is discussed in paragraphs 4.5 and 5. 4.3.1 GLO Initiated Additions The process for GLO initiated GLAddMembers requests is as follows: 1 - The GLO collects the names and pertinent information for the members to be added (this MAY be done through an out of bands means). The GLO then sends a SignedData.PKIData.controlSequence.GLAddMembers request to the GLA (1 in Figure 5). The GLO MUST include: the GL name in glName, the member's name in glMembers.glMemberName, the member's encryption certificate in glMembers.certificates.membersPKC. The GLO MAY also include the GL identifier in glIdentifier, if known, any attribute certificates associated with the member's encryption certificate in glMembers.certificates.membersAC, and the certification path associated with the member's encryption and attribute certificates in glMembers.certificates.certificationPath. a - The GLO MAY optionally apply confidentiality to the request by encapsulating the SignedData.PKIData in an EnvelopedData (see paragraph 3.2.1.2). b - The GLO MAY also optionally apply another SignedData over the EnvelopedData (see paragraph 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 paragraph 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. a - If the signature(s) does(do) not verify, the GLA MUST return a response indicating CMCFailInfo.badMessageCheck. b - If the signature(s) does(do) verify, the GLAddMembers request is included in a controlSequence with the GLUseKEK request, and the processing of 2.b.2 is successfully completed the GLA MUST return to all GLOs a GLSuccessInfo indicating the glName, the corresponding glIdentifier, an action.actionCode.addedMember, and action.glMemberName (2 in Turner 29 Internet-Draft S/MIME Symmetric Key Distribution July 14, 2000 Figure 5). The response MUST be constructed as specified in paragraph 3.2.3. 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 paragraph 3.2.1.2). 2 - The GLA MAY also optionally apply another SignedData over the EnvelopedData (see paragraph 3.2.1.2). c - If the signature(s) does(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 either that the glName is supported (in the case the glIdentifier is omitted) or that the combination of glName and glIdentifier matches a glName and glIdentifier stored on the GLA. 1 - If the glIdentifier is omitted and the glName is not supported by the GLA, the GLA MUST return a response indicating GLFailInfo.errorCode.invalidGLName. 2 - If the glName and glIdentifier are present and do not match a GL stored on the GLA, the GLA MUST return a response indicating GLFailInfo.errorCode.invalidGLNameGLIdentifierCombination. 3 - If the glIdentifier is omitted and the glName is supported by the GLA or if the glIdentifier/glName combination is present and supported, the GLA MUST check to see if the glMemberName is present on the GL. a - If the glMemberName is present on the GL, the GLA MUST return a response indicating GLFailInfo.errorCode.alreadyAMember. b - If the glMemberName is not present on the GL, the GLA the GLA MUST check how the GL is administered. 1 - If the GL is closed, the GLA MUST check that GLO signed the request by checking that one of the names in the digital signature certificate used to sign the request matches one of the registered GLOs. a - If the names do not match, the GLA MUST return a response indicating GLFailInfo.errorCode.noGLONameMatch. b - If the names do match, the GLA MUST verify the member's encryption certificate. Turner 30 Internet-Draft S/MIME Symmetric Key Distribution July 14, 2000 1 - If the member's encryption certificate does not verify, the GLA MUST return a response indicating GLFailInfo.errorCode.invalidCert. 2 - If the member's certificate does verify, the GLA MUST return to all GLOs a GLSuccessInfo indicating the glName, the corresponding glIdentifier, an action.actionCode.addedMember, and action.glMemberName (2 in Figure 5). The response MUST be constructed as in paragraph 3.2.3. The GLA also takes administrative actions, which are beyond the scope of this document, to add the member with the GL stored on the GLA. The GLA will also distribute the shared KEK to the member via the mechanism described in paragraph 5. 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 paragraph 3.2.1.2). b - The GLA MAY also optionally apply another SignedData over the EnvelopedData (see paragraph 3.2.1.2). 2 - If the GL is managed, the GLA MUST check that either the GLO or the prospective member signed the request. For the GLO, one of the names in the certificate used to sign the request MUST match one of the registered GLOs. For the prospective member, the name in glMembers.glMemberName MUST match one of the names in the certificate used to sign the request. a _ If the signer is neither a registered GLO or the prospective GL member, the GLA MUST return a response indicating GLFailInfo.errorCode.noSpam. b - If the signer is the GLO, the GLA MUST verify the member's encryption certificate. 1 - If the member's certificate does not verify, the GLA MUST return a response indicating GLFailInfo.errorCode.invalidCert. 2 - If the member's certificate does verify, the GLA MUST return to all GLOs GLSuccessInfo indicating the glName, the corresponding glIdentifier, an action.actionCode.addedMember, and action.glMemberName to the GLO (2 in Figure 5). The response MUST be constructed as in paragraph 3.2.3. The GLA also takes administrative actions, Turner 31 Internet-Draft S/MIME Symmetric Key Distribution July 14, 2000 which are beyond the scope of this document, to add the member with the GL stored on the GLA. The GLA will also distribute the shared KEK to the member via the mechanism described in paragraph 5. 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 paragraph 3.2.1.2). b - The GLA MAY also optionally apply another SignedData over the EnvelopedData (see paragraph 3.2.1.2). c - If the signer is the prospective member, the GLA forwards the GLAddMembers request (see paragraph 3.2.3) to the GLO (B{A} in Figure 5). Which GLO the request is forwarded to is beyond the scope of this document. Further processing of the forwarded request by the GLO is addressed in 3 of paragraph 4.3.2. 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 paragraph 3.2.1.2). 2 - The GLA MAY also optionally apply another SignedData over the EnvelopedData (see paragraph 3.2.1.2). 3 - If the GL is unmanaged, the GLA MUST check that either the GLO or the prospective member signed the request. For the GLO, one of the names in the certificate used to sign the request MUST match one of the registered GLOs. For the prospective member, the name in glMembers.glMemberName MUST match one of the names in the certificate used to sign the request. a - If the signer is not the GLO or the prospective member, the GLA MUST return a response indicating GLFailInfo.errorCdoe.noSpam. b - If the signer is either the GLO or the prospective member, the GLA MUST verify the member's encryption certificate. 1 - If the member's certificate does not verify, the GLA MUST return a response indicating GLFailInfo.errorCode.invalidCert. Turner 32 Internet-Draft S/MIME Symmetric Key Distribution July 14, 2000 2 - If the member's certificate does verify, the GLA MUST return a GLSucessInfo 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 response MUST be constructed as in paragraph 3.2.3. The GLA also takes administrative actions, which are beyond the scope of this document, to add the member with the GL stored on the GLA. The GLA will also distribute the shared KEK to the member via the mechanism described in paragraph 5. a - 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 paragraph 3.2.1.2). b - The GLA MAY also optionally apply another SignedData over the EnvelopedData (see paragraph 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 paragraph 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. a - If the signature(s) does (do) not verify, the GLO MUST return a response indicating CMCFailInfo.badMessageCheck. b - If the signature(s) does(do) verify, the GLO has added the member to the GL. c - If 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 or GLFailInfo response, the prospective member verifies the GLA's signature(s). If an additional SignedData and/or EnvelopedData encapsulates the response (see paragraph 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. a - If the signatures do not verify, the prospective member MUST return a response indicating CMCFailInfo.badMessageCheck. Turner 33 Internet-Draft S/MIME Symmetric Key Distribution July 14, 2000 b - If the signatures do verify, the prospective member has been added to the GL. c - If 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. 4.3.2 Prospective Member Initiated Additions The process for prospective member initiated GLAddMembers requests is as follows: 1 - The prospective GL member sends a SignedData.PKIData.controlSequence.GLAddMembers request to the GLA (A in Figure 5). The prospective GL member MUST include: the GL name in glName, the member's name in glMembers.glMemberName, their encryption certificate in glMembers.certificates.membersPKC. The prospective GL member MAY also include the GL identifier in glIdentifier, if known, any attribute certificates associated with their encryption certificate in glMembers.certificates.membersAC, and the certification path associated with their encryption and attribute certificates in glMembers.certificates.certificationPath a - The prospective GL member MAY optionally apply confidentiality to the request by encapsulating the SignedData.PKIData in an EnvelopedData (see paragraph 3.2.1.2). b - The prospective GL member MAY also optionally apply another SignedData over the EnvelopedData (see paragraph 3.2.1.2). 2 - Upon receipt of the request, the GLA verifies the request as per 2 in paragraph 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 paragraph 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. a - If the signature(s) does(do) not verify, the GLO MUST return a response indicating CMCFailInfo.badMessageCheck. b - If the signature(s) does(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 glMembers.glMemberName. Turner 34 Internet-Draft S/MIME Symmetric Key Distribution July 14, 2000 1 - If the names do not match, the GLO may send a message back, which is out of scope, to the prospective member, depending on policy, to indicate that GL members can only add themselves lists. This stops people from adding people to GLs without their permission. 2 - If 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 glMembers.glMemberName is not already on the GL. a - If the GLO determines the prospective member is not allowed to join the GL, the GLO MAY return a message, which is beyond the scope of this document, to indicate why the prospective member is not allowed to join. b - If GLO determines the prospective member is allowed to join the GL, the GLO MUST verify the member's encryption certificate. 1 - If the member's certificate does not verify, the GLO MAY return a message, which is out of scope, to the prospective member indicating that their encryption certificate is not valid. 2 - If the member's certificate does verify, the GLO reforms GLAddMembers request (the prospective member's signature is discarded and the GLO applies their own signature) to the GLA (1 in Figure 5) by including: the GL name in glName, the member's name in glMembers.glMemberName, the member's encryption certificate in glMembers.certificates.membersPKC. The GLO MAY also include the GL identifier in glIdentifier, if known, any attribute certificates associated with the member's encryption certificate in glMembers.certificates.membersAC, and the certification path associated with the member's encryption and attribute certificates in glMembers.certificates.certificationPath. 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 paragraph 3.2.1.2). b - The GLO MAY also optionally apply another SignedData over the EnvelopedData (see paragraph 3.2.1.2). 4 - Processing continues as in 2 of paragraph 4.3.1. Turner 35 Internet-Draft S/MIME Symmetric Key Distribution July 14, 2000 4.4 Delete Members From GL To delete members from GLs, either the GLO or prospective non- members use the GLDeleteMembers request. There are however different scenarios that should be supported. Either the GLO or prospective members may submit the GLDeleteMembers request to the GLA, but the GLA processes the 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 the 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 paragraph 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. Where there are multiple GLOs for a GL, which GLO the request is forwarded to is beyond the scope of this document. In the closed case, the GLA will not accept requests from prospective members. The following paragraphs describe the processing required by the GLO, GLA, and prospective non-GL members depending on where the request originated, either from the GLO or from prospective 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 be able to receive and decrypt data protected with the shared KEK and will continue to receive shared KEK 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 list under a different name. For managed and closed GLs, the GLO MUST take steps to ensure the member being deleted is not on the list twice. After ensuring this, the managed GL MUST be rekeyed to maintain the secrecy of the group. If the GLO is sure the member has been deleted the group rekey mechanism MAY be used to distribute the new key (see paragraphs 4.5 and 5). Turner 36 Internet-Draft S/MIME Symmetric Key Distribution July 14, 2000 4.4.1 GLO Initiated Deletions The process for GLO initiated GLDeleteMembers requests is as follows: 1 - The GLO collects the names and pertinent information for the members to be deleted (this MAY be done through an out of bands means). The GLO then sends a SignedData.PKIData.controlSequence.GLDeleteMembers request to the GLA (1 in Figure 6). The GLO MUST include: the GL name in glName and the member's name in glMembersToDelete. The GLO MAY omit the glIdentifier if it is unknown. 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 paragraph 4.5). a - The GLO MAY optionally apply confidentiality to the request by encapsulating the SignedData.PKIData in an EnvelopedData (see paragraph 3.2.1.2). b - The GLO MAY also optionally apply another SignedData over the EnvelopedData (see paragraph 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 paragraph 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. a - If the signature(s) does(do) not verify, the GLA MUST return a response indicating CMCFailInfo.badMessageCheck. b - If the signature(s) does(do) verify, the GLA MUST make sure the GL is supported by the GLA by checking either that the glName is supported (in the case the glIdentifier is omitted) or that the combination of glName and glIdentifier matches a glName and glIdentifier stored on the GLA. 1 - If the glIdentifier is omitted and the glName is not supported by the GLA, the GLA MUST return a response indicating GLFailInfo.errorCode.invalidGLName. 2 - If the glName and glIdentifier are present and do not match a GL stored on the GLA, the GLA MUST return a response indicating GLFailInfo.errorCode.invalidGLNameGLIdentifierCombination. 3 - If the glIdentifier is omitted and the glName is supported by the GLA or if the glIdentifier/glName combination is Turner 37 Internet-Draft S/MIME Symmetric Key Distribution July 14, 2000 supported by the GLA, the GLA MUST check to see if the glMemberName is present on the GL. a - If the glMemberName is not present on the GL, the GLA MUST return a response indicating GLFailInfo.errorCode.notAMember. b - If the glMemberName is not already on the GL, the GLA MUST check how the GL is administered. 1 - If the GL is closed, the GLA MUST check that GLO signed the request by checking that one of the names in the digital signature certificate used to sign the request matches one of the registered GLOs. a - If the names do not match, the GLA MUST return a response indicating GLFailInfo.errorCode.noGLONameMatch. b - If the names do match, the GLA MUST return to all GLOs a GLSucessInfo indicating the glName, the corresponding glIdentifier, an action.actionCode.deletedMember, and action.glMemberName (2 in Figure 5). The response MUST be constructed as in paragraph 3.2.3. 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. The GLA will also rekey group as described in paragraph 5. 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 paragraph 3.2.1.2). 2 - The GLA MAY also optionally apply another SignedData over the EnvelopedData (see paragraph 3.2.1.2). 2 - If the GL is managed, the GLA MUST check that either the GLO or the prospective member signed the request. For the GLO, one of the names in the certificate used to sign the request MUST match one of the registered GLOs. For the prospective member, the name in glMembers.glMemberName MUST match one of the names in the certificate used to sign the request. a _ If the signer is neither a registered GLO or the prospective GL member, the GLA MUST return a response indicating GLFailInfo.errorCode.noSpam. Turner 38 Internet-Draft S/MIME Symmetric Key Distribution July 14, 2000 b - If the signer is the GLO, the GLA MUST return to all GLOs a GLSucessInfo indicating the glName, the corresponding glIdentifier, an action.actionCode.deletedMember, and action.glMemberName (2 in Figure 6). The response MUST be constructed as in paragraph 3.2.3. 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. The GLA will also rekey group as described in paragraph 5. 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 paragraph 3.2.1.2). 2 - The GLA MAY also optionally apply another SignedData over the EnvelopedData (see paragraph 3.2.1.2). c - If the signer is the prospective member, the GLA forwards the GLDeleteMembers request (see paragraph 3.2.3) to the GLO (B{A} in Figure 6). Which GLO the request is forwarded to is beyond the scope of this document. Further processing of the forwarded request by the GLO is addressed in 3 of paragraph 4.4.2. 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 paragraph 3.2.1.2). 2 - The GLA MAY also optionally apply another SignedData over the EnvelopedData (see paragraph 3.2.1.2). 3 - If the GL is unmanaged, the GLA MUST check that either the GLO or the prospective member signed the request. For the GLO, one of the names in the certificate used to sign the request MUST match one of the registered GLOs. For the prospective member, the name in glMembers.glMemberName MUST match one of the names in the certificate used to sign the request. a - If the signer is not the GLO or the prospective member, the GLA MUST return a response indicating GLFailInfo.errorCode.noSpam. b - If the signer is either the GLO or the member, the GLA MUST return a GLSucessInfo indicating the Turner 39 Internet-Draft S/MIME Symmetric Key Distribution July 14, 2000 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 response MUST be constructed as in paragraph 3.2.3. 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. 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 paragraph 3.2.1.2). 2 - The GLA MAY also optionally apply another SignedData over the EnvelopedData (see paragraph 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 paragraph 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. a - If the signature(s) does(do) not verify, the GLO MUST return a response indicating CMCFailInfo.badMessageCheck. b - If the signature(s) does(do) verify, the GLO has deleted the member from the GL. c - If 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 or GLFailInfo response, the prospective member verifies the GLA's signature(s). If an additional SignedData and/or EnvelopedData encapsulates the response (see paragraph 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. a - If the signature(s) does(do) not verify, the prospective member MUST return a response indicating CMCFailInfo.badMessageCheck. b - If the signature(s) does(do) verify, the prospective member has been deleted from the GL. c - If the prospective member received a GLFailInfo, for any reason, the prospective member MAY reattempt to delete Turner 40 Internet-Draft S/MIME Symmetric Key Distribution July 14, 2000 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 GLDeleteMembers requests is as follows: 1 - The prospective non-GL member sends a SignedData.PKIData.controlSequence.GLDeleteMembers request to the GLA (A in Figure 5). The prospective non-GL member MUST include: the GL name in glName and their name in glMembersToDelete. The prospective non-GL member MAY omit the glIdentifier if it is unknown. a - The prospective non-GL member MAY optionally apply confidentiality to the request by encapsulating the SignedData.PKIData in an EnvelopedData (see paragraph 3.2.1.2). b - The prospective non-GL member MAY also optionally apply another SignedData over the EnvelopedData (see paragraph 3.2.1.2). 2 - Upon receipt of the request, the GLA verifies the request as per 2 in paragraph 4.4.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 paragraph 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. a - If the signature(s) does(do) not verify, the GLO MUST return a response indicating CMCFailInfo.badMessageCheck. b - If the signature(s) does(do) verify, the GLO MUST check to make sure the name in one of the certificates used to sign the request is the entity indicated in glMembersToDelete. 1 - If the names do not match, the GLO may send a message back, which is out of scope, to the prospective member, depending on policy, to indicate that GL members can only add themselves lists. This stops people from adding people to GLs without their permission. 2 - If the names do match, the GLO deletes the member from the GL by sending the reformed GLDeleteMembers request (the prospective non-GL member's signature is stripped off and Turner 41 Internet-Draft S/MIME Symmetric Key Distribution July 14, 2000 the GLO signs it) to the GLA (1 in Figure 6). The GLO MUST make sure the glMemberName is already on the list and only on the list once. The GLO MUST also generate a GLRekey request and include it with the GLDeleteMember request (see paragraph 4.5). 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 paragraph 3.2.1.2). b - The GLO MAY also optionally apply another SignedData over the EnvelopedData (see paragraph 3.2.1.2). 4 - Further processing is as in 2 of paragraph 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 GLDeleteMembers 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 GLDeleteMembers 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. The GLA will automatically perform an rekey without waiting for approval from the GLO. - 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 paragraph 5. If the generationCounter (see paragraph 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 1 duration before the last shared KEK expires. Turner 42 Internet-Draft S/MIME Symmetric Key Distribution July 14, 2000 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 paragraph 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). 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 and the glIdentifier. The GLO MAY include change the glOwner, glAdministration, glDistributionMethod, and glKeyAttributes. If glOwner, glAdministration, glDistributionMethod, and glKeyAttributes 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 the glKeyAttributes.generationCounter MUST be set to zero (0) a - The GLO MAY optionally apply confidentiality to the request by encapsulating the SignedData.PKIData in an EnvelopedData (see paragraph 3.2.1.2). b - The GLO MAY also optionally apply another SignedData over the EnvelopedData (see paragraph 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 paragraph 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. a - If the signature(s) does(do) not verify, the GLA MUST return a response indicating CMCFailInfo.badMessageCheck. b - If the signature(s) does(do) verify, the GLA MUST make sure the GL is supported by the GLA by checking that that the Turner 43 Internet-Draft S/MIME Symmetric Key Distribution July 14, 2000 combination of glName and glIdentifier matches a glName and glIdentifier combination stored on the GLA. 1 - If the glName and glIdentifier present do not match a GL stored on the GLA, the GLA MUST return a response indicating GLFailInfo.errorCode.invalidGLNameGLIdentifierCombination. 2 - If the glName and glIdentifier present do 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. a - If the names do not match, the GLA MUST return a response indicating GLFailInfo.errorCode.noGLONameMatch. b - If all the names do match, the GLA MUST return to all GLOs a GLSucessInfo 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 paragraph 5). 1 - The GLA MUST apply confidentiality to response by encapsulating the SignedData.PKIData in an EnvelopedData if the request was encapsulated in an EnvelopedData (see paragraph 3.2.1.2). 2 - The GLA MAY also optionally apply another SignedData over the EnvelopedData (see paragraph 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 paragraph 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. a - If the signature(s) does(do) not verify, the GLO MUST return a response indicating CMCFailInfo.badMessageCheck. b - If the signatures verifies, the GLO has successfully rekeyed the GL. c - If the GLO received a GLFailInfo, for any reason, the GLO may reattempt to rekey the GL using the information provided in the GLFailInfo response. Turner 44 Internet-Draft S/MIME Symmetric Key Distribution July 14, 2000 4.5.2 GLA Initiated Rekey Requests If the GLA is in charge of rekeying the GL or if a GLKCompromise message has been properly processed (see paragraph 4.7) the GLA will automatically issue a GLKey message (see paragraph 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.GLSucessInfo indicating the glName, the new glIdentifier, and actionCode.rekeyedGL (A in Figure 7). a - The GLA MAY optionally apply confidentiality to the request by encapsulating the SignedData.PKIData in an EnvelopedData (see paragraph 3.2.1.2). b - The GLA MAY also optionally apply another SignedData over the EnvelopedData (see paragraph 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 paragraph 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. a - If the signatures do not verify, the GLO MUST return a response indicating CMCFailInfo.badMessageCheck. b - If the signatures verifies, 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 GL be managed by multiple GLOs. The GLAddOwners and GLRemoveOwners messages are designed to support adding and removing registered GLOs. Figure depicts the protocol interactions to send GLAddOwners and GLRemoveOwners messages and the resulting response messages. +-----+ 1 2 +-----+ | GLA | <-------> | GLO | +-----+ +-----+ Figure 8 _ GLO Add & Delete Owners Turner 45 Internet-Draft S/MIME Symmetric Key Distribution July 14, 2000 The process for GLAddOwners and GLDeleteOwners is as follows: 1 - The GLO sends a SignedData.PKIData.controlSequence.GLAddOwners or GLRemoveOwners request to the GLA (1 in Figure 8). The GLO MUST include: the GL name in glName, the GLO(s) in glOwner. The GLO MAY also include the glIdentifier. a - The GLO MAY optionally apply confidentiality to the request by encapsulating the SignedData.PKIData in an EnvelopedData (see paragraph 3.2.1.2). b - The GLO MAY also optionally apply another SignedData over the EnvelopedData (see paragraph 3.2.1.2). 2 _ Upon receipt of the GLAddOwners or GLRemoveOwners request, the GLA verifies the GLO's signature(s). If an additional SignedData and/or EnvelopedData encapsulates the request (see paragraph 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. a - If the signature(s) does(do) not verify, the GLA MUST return a response indicating CMCFailInfo.badMessageCheck. b - If the signature(s) does(do) verify, the GLA MUST make sure the GL is supported by checking either that the glName is supported (in the case the glIdentifier is omitted) or that the combination of glName and glIdentifier matches a glName and glIdentifier combination stored on the GLA. 1 - If the glIdentifier is omitted and the glName is not supported by the GLA, the GLA MUST return a response indicating GLFailInfo.errorCode.invalidGLName. 2 - If the glName and glIdentifier are present and do not match a GL stored on the GLA, the GLA MUST return a response indicating GLFailInfo.errorCode.invalidGLNameGLIdentifierCombination. 3 - If the glIdentifier is omitted and the glName is supported by the GLA or if the glIdentifier/glName combination is supported by the GLA, the GLA MUST ensure a registered GLO signed the GLAddOwners or GLRemoveOwners request by checking if the name present in the digital signature certificate used to sign the GLDelete request matches one of the registered GLOs. a - If the names do not match, the GLA MUST return a response indicating GLFailInfo.errorCode.noGLONameMatch. b - If the names do match, the GLA MUST return to all GLOs a GLSucessInfo indicating the glName, the corresponding Turner 46 Internet-Draft S/MIME Symmetric Key Distribution July 14, 2000 glIdentifier, 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 glOwner name with the GL in the case of GLAddOwners or to disassociate the old glOwner name with the GL in the cased of GLRemoveOwners. 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 paragraph 3.2.1.2). 2 - The GLA MAY also optionally apply another SignedData over the EnvelopedData (see paragraph 3.2.1.2). a - The GLO MAY optionally apply confidentiality to the request by encapsulating the SignedData.PKIData in an EnvelopedData (see paragraph 3.2.1.2). b - The GLO MAY also optionally apply another SignedData over the EnvelopedData (see paragraph 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 paragraph 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. a - If the signature(s) does(do) not verify, the GLO MUST return a response indicating CMCFailInfo.badMessageCheck. b - If the signatures do verify and the response was GLSuccessInfo, the GLO has successfully added or removed the GLO. c - If 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. The GL members use the GLKCompromise message to tell the GLA that the shared KEK has been compromised. Figure 9 depicts the protocol interactions for GL Key Compromise. Turner 47 Internet-Draft S/MIME Symmetric Key Distribution July 14, 2000 +-----+ 2 3 +----------+ | GLO | <--------+ +-------> | Member 1 | +-----+ | | +----------+ +-----+ ---------+ | 3 +----------+ | GLA | 1 +-------> | ... | +-----+ <-------------+ +----------+ | 3 +----------+ +-------> | Member n | +----------+ Figure 9 - GL Key Compromise The process for GLKCompromise 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 glName and MAY include glIdentifier. a - The GL member MAY optionally apply confidentiality to the request by encapsulating the SignedData.PKIData in an EnvelopedData (see paragraph 3.2.1.2). b - The GL member MAY also optionally apply another SignedData over the EnvelopedData (see paragraph 3.2.1.2). 2 _ Upon receipt of the GLKCompromise requst, the GLA verifies the GL member's signature(s). If an additional SignedData and/or EnvelopedData encapsulates the request (see paragraph 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. a - If the signature(s) does(do) not verify, the GLA MUST return a response indicating CMCFailInfo.badMessageCheck. b - If the signature(s) does(do) verify, the GLA MUST make sure the GL is supported by checking either that the glName is supported (in the case the glIdentifier is omitted) or that the combination of glName and glIdentifier matches a glName and glIdentifier combination stored on the GLA. 1 - If the glIdentifier is omitted and the glName is not supported by the GLA, the GLA MUST return a response indicating GLFailInfo.errorCode.invalidGLName. 2 - If the glName and glIdentifier are present and do not match a GL stored on the GLA, the GLA MUST return a response indicating GLFailInfo.errorCode.invalidGLNameGLIdentifierCombination. Turner 48 Internet-Draft S/MIME Symmetric Key Distribution July 14, 2000 3 - If the glIdentifier is omitted and the glName is supported by the GLA or if the glIdentifier/glName combination is supported by the GLA, the GLA MUST ensure the GL member is on the GL. a - If one of the names in the certificate used to sign the GLKCompromise is not present on the GL, the GLA MUST return a response indicating GLFailInfo.errorCode.noSpam. b - If one of the names in the certificate used to sign the GLKCompromise is present on the GL, the GLA MUST: 1 _ Generate a PKIData.cmsSequence for all GLOs (2 in Figure 9) containing the original GLKCompromise message and a PKIResponse.GLSuccessInfo indicating the glName, new glIdentifier, and an action.actionCode of rekeyedGL. 2 _ Generate a GLKey message as described in paragraph 5.1.2 to rekey the GL (3 in Figure 9) 4.8 Request KEK Refresh The will be times when the GL members have misplaced their shared KEK. In this the shared KEK is not compromised and a rekey of the entire GL is not necessary. The 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. 2 +----------+ +-------> | Member 1 | | +----------+ +-----+ 1 | 2 +----------+ | GLA | <---+-------> | ... | +-----+ | +----------+ | 2 +----------+ +-------> | Member n | +----------+ 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 glName and MAY include glIdentifier. Turner 49 Internet-Draft S/MIME Symmetric Key Distribution July 14, 2000 a - The GL member MAY optionally apply confidentiality to the request by encapsulating the SignedData.PKIData in an EnvelopedData (see paragraph 3.2.1.2). b - The GL member MAY also optionally apply another SignedData over the EnvelopedData (see paragraph 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 paragraph 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. a - If the signature(s) does(do) not verify, the GLA MUST return a response indicating CMCFailInfo.badMessageCheck. b - If the signature(s) does(do) verify, the GLA MUST make sure the GL is supported by checking either that the glName is supported (in the case the glIdentifier is omitted) or that the combination of glName and glIdentifier matches a glName and glIdentifier combination stored on the GLA. 1 - If the glIdentifier is omitted and the glName is not supported by the GLA, the GLA MUST return a response indicating GLFailInfo.errorCode.invalidGLName. 2 - If the glName and glIdentifier are present and do not match a GL stored on the GLA, the GLA MUST return a response indicating GLFailInfo.errorCode.invalidGLNameGLIdentifierCombination. 3 - If the glIdentifier is omitted and the glName is supported by the GLA or if the glIdentifier/glName combination is supported by the GLA, the GLA MUST ensure the GL member is on the GL. a - If the glMemberName is not present on the GL, the GLA MUST return a response indicating GLFailInfo.errorCode.noSpam. b - If the glMemberName is present on the GL, the GLA MUST return a GLKey message (2 in Figure 10) as described in paragraph 5.1.3. 4.9 GLA Query Request and Response There will be certain times when a GLO is having trouble setting up a GLO because they do not know the algorithm(s) or distribution method(s) the GLA supports. The GLAQueryRequest and GLAQueryResponse message have been defined to support the GLO determining this Turner 50 Internet-Draft S/MIME Symmetric Key Distribution July 14, 2000 information. Figure 11 depicts the protocol interactions for GLAQueryRequest and GLAQueryResponse. +-----+ 1 2 +-----+ | GLA | <-------> | GLO | +-----+ +-----+ Figure 11 - GLA Query Request & Response The process for GLAQueryRequest and GLAQueryResponse is as follows: 1 - The GLO sends a SignedData.PKIData.controlSequence.GLAQueryRequest request to the GLA (1 in Figure 11). The GLO indicates whether they are interested in determining what algorithms the GLA supports or what distributionMethods the GLA support or both. a - The GLO MAY optionally apply confidentiality to the request by encapsulating the SignedData.PKIData in an EnvelopedData (see paragraph 3.2.1.2). b - The GLO MAY also optionally apply another SignedData over the EnvelopedData (see paragraph 3.2.1.2). 2 _ Upon receipt of the GLQueryRequest, the GLA determines if it accepts GLAQueryRequests. a - If the GLA does not accept GLAQueryRequests, the GLA MUST return a response indicating GLFailInfo.unspecified. b - If the GLA does accept GLAQueryReuests, the GLA MUST verify the GLO's signature(s). If an additional SignedData and/or EnvelopedData encapsulates the request (see paragraph 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. 1 - If the signature(s) does(do) not verify, the GLA MUST return a response indicating CMCFailInfo.badMessageCheck. 2 - If the signature(s) does(do) verify, the GLA MUST return a GLAQueryResponse (2 in Figure 11) indicating the supportedAlgorithms, the distributionMethod, or both. 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 paragraph 3.2.1.2). b - The GLA MAY also optionally apply another SignedData over the EnvelopedData (see paragraph 3.2.1.2). Turner 51 Internet-Draft S/MIME Symmetric Key Distribution July 14, 2000 3 - Upon receipt of the GLAQueryResponse, the GLO verifies the GLA's signature(s). If an additional SignedData and/or EnvelopedData encapsulates the response (see paragraph 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. a - If the signature(s) does(do) not verify, the GLO MUST return a response indicating CMCFailInfo.badMessageCheck. b - If the signatures do verify and the response was GLAQueryResponse, the GLO may use the information contained therein to attempt to setup a GL or modify an existing GL. 5 Distribution Message The GLA uses the GLKey message to distribute new, shared KEK(s) after receiving GLAddMembers, GLDeleteMembers (for closed and managed GLs), GLRekey, GLKCompromise, or GLKRefresh requests and returning a GLSucessInfo response for the respective request. Figure 12 depicts the protocol interactions to send out GLKey messages. The procedures defined in this paragraph MUST be implemented. 1 +----------+ +-------> | Member 1 | | +----------+ +-----+ | 1 +----------+ | GLA | ----+-------> | ... | +-----+ | +----------+ | 1 +----------+ +-------> | Member n | +----------+ Figure 12 - GL Key Distribution If the GL was setup with GLKeyAttributes.recipientsMutuallyAware 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: - GLAddMembers request, - GLKComrpomise indicate, - GLKRefresh request, - GLDeleteMembers request with the the GL's glAdministration set to managed or closed, - GLKRekey request with generationCounter set to zero (0) The GLA MUST use either the kari (see paragraph 12.3.2 of CMS [2]) or ktri (see paragraph 12.3.1 of CMS [2]) choice in GLKey.glkWrapped.RecipientInfo to ensure only the intended Turner 52 Internet-Draft S/MIME Symmetric Key Distribution July 14, 2000 recipients receive the shared KEK. The GLA MUST support the RecipientInfo.kari choice. 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 paragraph 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.kari 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. **Need to be more detailed on how the values are derived as it depends on why and when the GLKey message is generated** a - The GLA MAY optionally apply another confidentiality layer to the message by encapsulating the SignedData.PKIData in another EnvelopedData (see paragraph 3.2.1.2). b - The GLA MAY also optionally apply another SignedData over the EnvelopedData.SignedData.PKIData (see paragraph 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 paragraph 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. a - If the signature(s) does(do) not verify, the GL member MUST return a response indicating CMCFailInfo.badMessageCheck. b - If the signature(s) does(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 Key Wrapping In the mechanisms described in paragraphs 5, the group key being distributed, in an EnvelopedData, MUST be protected by a key of equal or greater length (i.e., if a RC2 128-bit key is being Turner 53 Internet-Draft S/MIME Symmetric Key Distribution July 14, 2000 distributed a key of 128-bits or greater must be used to protect the key). 7 Algorithms Triple-DES is mandatory other are optional. 8 Transport SMTP must be supported. 9 Using the Group Key [Put in here how this can be used with SMIME MLAs.] 10 Schema Requirements [I think we need to specify some MAYs for support of object classes, etc. to support location of the GL and GLO in a repository. There are really two choices for the GL mhsDistributionList from RFC 1274 and addresslist from an Internet-Draft in the LDAPEXT WG. The only reason I can think of not using the one from RFC 1274 is that a MUST CONTAIN is mhsORAddress and we're should support SMTP. addressList (in the ID) doesn't have mhsORAddress as a must contain. The Owner in the both object classes though has the syntax directoryName. We might have to roll attribute for the Owner because I think it should probably have the GeneralName syntax instead of just directoryName.] [We can also define attributes that can be used to store the group key encrypted for an individual group member and for the encrypted object. Does anyone think this is useful/needed?] 11 Security Considerations Don't have too many GLOs because they could start willie nillie adding people you don't like. 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 then people can attack the last key. Turner 54 Internet-Draft S/MIME Symmetric Key Distribution July 14, 2000 12 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., Schadd, 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 Housley, R., Ford, W., Polk, W. and D. Solo, "Internet X.509 Public Key Infrastructure: Certificate and CRL Profile", RFC 2459, January 1999. 13 Acknowledgements Thanks to Russ Housley and Jim Schaad for providing much of the background and review required to write this draft. 14 Author's Addresses Sean Turner IECA, Inc. 9010 Edgepark Road Vienna, VA 22182 Phone: +1.703.628.3180 Email: turners@ieca.com Expires January 14, 2001 Turner 55
Datatracker
Report a datatracker bug
draft-ietf-smime-symkeydist-01
Internet-Draft
| Document | Document type |
This is an older version of an Internet-Draft that was ultimately published as RFC 5275.
Expired & archived
|
|
|---|---|---|---|
| Select version | |||
| Compare versions | |||
| Author | |||
| RFC stream |
|
||
| Other formats | |||
| Additional resources | Mailing list discussion |