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