draft-ietf-smime-symkeydist-00.txt   draft-ietf-smime-symkeydist-01.txt 
SMIME Working Group S. Turner
INTERNET DRAFT IECA
Expires in on 20 June, 2000 December 20, 1999 SMIME Working Group S. Turner
Internet Draft IECA
Document: draft-ietf-smime-symkeydist-01.txt July 2000
Expires: January 14, 2001
S/MIME Symmetric Key Distribution S/MIME Symmetric Key Distribution
<draft-ietf-smime-symkeydist-00.txt>
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with all This document is an Internet-Draft and is in full conformance with
provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026 [1].
This document is an Internet-Draft. Internet-Drafts are working This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, and documents of the Internet Engineering Task Force (IETF), its areas,
its working groups. Note that other groups may also distribute working and its working groups. Note that other groups may also distribute
documents as Internet-Drafts. working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of 6 months and Internet-Drafts are draft documents valid for a maximum of six
may be updated, replaced, or may become obsolete by other documents at months and may be updated, replaced, or obsoleted by other documents
any time. It is inappropriate to use Internet-Drafts as reference at any time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt
The list of current Internet-Drafts Shadow Directories can be accessed The list of Internet-Draft Shadow Directories can be accessed at
at http://www.ietf.org/shadow.html.http://www.ietf.org/shadow.html. 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 Abstract
This document describes a mechanism to manage (i.e., setup, distribute, This document describes a mechanism to manage (i.e., setup,
and rekey) keys used with symmetric cryptographic algorithms. The distribute, and rekey) keys used with symmetric cryptographic
mechanisms use the CMSCryptographic Message Syntax (CMS) protocol [CMS] algorithms. Also defined herein is a mechanism to organize users
to encrypt the key for each member of the group. Any member of the group into groups to support distribution of encrypted content using
can then later use this key to decrypt other CMS encrypted objects with symmetric cryptographic algorithms. The mechanisms use the
the symmetric or 'group' key. 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).
This draft is being discussed on the 'ietf-smime' mailing list. To Turner 1
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/>.
1 Introduction Conventions used in this document
With the ever expanding use of secure electronic communications (e.g., The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
S/MIME [CMS]), users require a mechanism to distribute encrypted data "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
to multiple recipients (i.e., a group of users). There are essentially this document are to be interpreted as described in RFC-2119 [4].
two ways to encrypt the data for the recipients: using asymmetric
algorithms with public key certificates (PKCs) or symmetric algorithms
with shared secret keys. With asymmetric algorithms, the encrypting user
forms an originator-determined content-encryption key (CEK) and encrypts
the content, using a symmetric algorithm. Then, using an asymmetric
algorithm and PKCs, the encrypting user 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 CEK
(kari RecipientInfo CHOICE). If the group is large the number of per-
recipient information that needs to be generated may take quite some
time, not to mention the time required to collect the PKCs for each of
the recipients. With symmetric algorithms, all members of the group use
a previously shared distributed secret key-encryption key (KEK). The
originating user only needs to encrypt the content with the shared KEK,
which is then used by every member in the group to decrypt the message.
A mechanism is defined herein to support distribution of shared KEKs in
order to enable symmetric algorithms.
[ST - I interchangeable use group key to mean shared KEK. In the next 1. INTRODUCTION....................................................3
version I will use the term shared KEK through out the document.] 1.1 APPLICABILITY TO E-MAIL........................................4
1.2 APPLICABILITY TO REPOSITORIES..................................4
2. ARCHITECTURE....................................................4
3. PROTOCOL INTERACTIONS...........................................6
3.1 CONTROL ATTRIBUTES.............................................7
3.1.1 GL USE KEK...................................................7
3.1.2 GL DELETE...................................................10
3.1.3 GL ADD MEMBERS..............................................10
3.1.4 GL DELETE MEMBERS...........................................11
3.1.5 GL REKEY....................................................12
3.1.6 GL ADD OWNER................................................13
3.1.7 GL REMOVE OWNER.............................................13
3.1.8 GL KEY COMPROMISE...........................................14
3.1.9 GL KEY REFRESH..............................................14
3.1.10 GL SUCCESS INFORMATION.....................................14
3.1.11 GL FAIL INFORMATION........................................15
3.1.12 GLA QUERY REQUEST..........................................17
3.1.13 GLA QUERY RESPONSE.........................................18
3.1.14 GL KEY.....................................................18
3.2 USE OF CMC, CMS, AND PKIX.....................................19
3.2.1 PROTECTION LAYERS...........................................19
3.2.1.1 MINIMUM PROTECTION........................................19
3.2.1.2 ADDITIONAL PROTECTION.....................................20
3.2.2 COMBINING REQUESTS AND RESPONSES............................20
3.2.3 GLA GENERATED MESSAGES......................................22
3.2.4 CMC CONTROL ATTRIBUTES......................................23
3.2.5 PKIX........................................................23
4 ADMINISTRATIVE MESSAGES.........................................23
4.1 ASSIGN KEK TO GL..............................................23
4.2 DELETE GL FROM GLA............................................26
4.3 ADD MEMBERS TO GL.............................................28
4.3.1 GLO INITIATED ADDITIONS.....................................29
4.3.2 PROSPECTIVE MEMBER INITIATED ADDITIONS......................34
4.4 DELETE MEMBERS FROM GL........................................36
4.4.1 GLO INITIATED DELETIONS.....................................37
4.4.2 MEMBER INITIATED DELETIONS..................................41
4.5 REQUEST REKEY OF GL...........................................42
4.5.1 GLO INITIATED REKEY REQUESTS................................43
4.5.2 GLA INITIATED REKEY REQUESTS................................45
4.6 CHANGE GLO....................................................45
4.7 INDICATE KEK COMPROMISE.......................................47
4.8 REQUEST KEK REFRESH...........................................49
4.9 GLA QUERY REQUEST AND RESPONSE................................50
5 DISTRIBUTION MESSAGE............................................52
5.1 DISTRIBUTION PROCESS..........................................53
The security provided by the symmetric key is only as good as the sum of Turner 2
the techniques employed by each member of the group to keep the 6 KEY WRAPPING....................................................53
symmetric key secret from nonmembers. These techniques are beyond the 7 ALGORITHMS......................................................54
scope of this document. Only the members of the list and the key manager 8 TRANSPORT.......................................................54
should have the key in order to maintain the secrecy of the group. 9 USING THE GROUP KEY.............................................54
Access control to the information protected by the symmetric key is 10 SCHEMA REQUIREMENTS............................................54
determined by the entity that encrypts the information, as all members 11 SECURITY CONSIDERATIONS........................................54
of the group have access. If the entity that is performing the 12 REFERENCES.....................................................55
encryption wants to ensure some subset of the group does not gain access 13 ACKNOWLEDGEMENTS...............................................55
to the information either a different symmetric key should be used 14 AUTHOR'S ADDRESSES.............................................55
(shared with this smaller group) or asymmetric algorithms should be
used.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 1. Introduction
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [MUSTSHOULD]. With the ever-expanding use of secure electronic communications
(e.g., S/MIME [2]), users require a mechanism to distribute
encrypted data to multiple recipients (i.e., a group of users).
There are essentially two ways to encrypt the data for recipients:
using asymmetric algorithms with public key certificates (PKCs) or
symmetric algorithms with symmetric keys.
With asymmetric algorithms, the originator forms an originator-
determined content-encryption key (CEK) and encrypts the content,
using a symmetric algorithm. Then, using an asymmetric algorithm and
the recipient's PKCs, the originator generates per-recipient
information that either (a) encrypts the CEK for a particular
recipient (ktri ReipientInfo CHOICE), or (b) transfers sufficient
parameters to enable a particular recipient to independently
generate the same KEK (kari RecipientInfo CHOICE). If the group is
large, the amount of per-recipient information required may take
quite some time to generate, not to mention the time required to
collect and validate the PKCs for each of the recipients. Each
recipient identifies their per-recipient information and uses the
private key associated with the public key of their PKC to decrypt
the CEK and hence gain access to the encrypted content.
With symmetric algorithms, the origination process is the same as
with asymmetric algorithms except for what encrypts the CEK. Instead
of using PKCs, the originator uses a previously distributed secret
key-encryption key (KEK) to encrypt the CEK (kekri RecipientInfo
CHOICE). Only one copy of the encrypted CEK is required because all
the recipients already have the shared KEK needed to decrypt the CEK
and hence gain access to the encrypted content.
The security provided by the shared KEK is only as good as the sum
of the techniques employed by each member of the group to keep the
KEK secret from nonmembers. These techniques are beyond the scope of
this document. Only the members of the list and the key manager
should have the KEK in order to maintain the secrecy of the group.
Access control to the information protected by the KEK is determined
by the entity that encrypts the information, as all members of the
group have access. If the entity that is performing the encryption
wants to ensure some subset of the group does not gain access to the
Turner 3
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 1.1 Applicability to E-mail
One primary audience for this distribution mechanism is e-mail. One primary audience for this distribution mechanism is e-mail.
Distribution lists sometimes referred to as mail lists, have been Distribution lists sometimes referred to as mail lists, have been
defined to support distribution of messages to a group of recipients defined to support distribution of messages to recipients subscribed
subscribed to the originatormail list. There are two models for how the to the mail list. There are two models for how the mail list can be
mail list can be used. If the originator is a member of the mail list, used. If the originator is a member of the mail list, the originator
the originator sends the encrypted message with the symmetric KEK to the sends messages encrypted with the shared KEK to the mail list (e.g.,
mail list (e.g., listserv or majordomo) and the message is distributed listserv or majordomo) and the message is distributed to the mail
to the mail list members. If the originator is not a member of the mail list members. If the originator is not a member of the mail list
list (does not have the group key), the originator sends the message to (does not have the shared KEK), the originator sends the message
the mail list agent (MLA) and the MLA then forms the KEK key needed for (encrypted for the MLA) to the mail list agent (MLA) and the MLA
the message. In either case the recipients of the mail list use the then forms the shared KEK needed to encrypt the message. In either
previously distributed group key to decrypt the message. case the recipients of the mail list use the previously distributed-
shared KEK to decrypt the message.
1.2 Applicability to Repositories 1.2 Applicability to Repositories
Objects can also be distributed via a repository (e.g., Light Weight Objects can also be distributed via a repository (e.g., Light Weight
Directory Protocol (LDAP) servers, X.500 Directory System Agents (DSAs), Directory Protocol (LDAP) servers, X.500 Directory System Agents
Web-based servers). If an object is stored in a repository, encrypted (DSAs), Web-based servers). If an object is stored in a repository
with a symmetric key algorithm, any one with access to that object can encrypted with a symmetric key algorithm, any one with the shared
then decrypt that object. The encrypted object and the encrypted key can KEK and access to that object can then decrypt that object. The
be stored in the repository. encrypted object and the encrypted, shared KEK can be stored in the
repository.
2. Architecture 2. Architecture
Figure 1 depicts the architecture to support symmetric key distribution. Figure 1 depicts the architecture to support symmetric key
Two different functions are required: generating the keys and distribution. The Group List Agent (GLA) supports two distinct
distributing the keys. These functions are performed by two conceptually functions with two different agents:
different entities. The Key Management Agent (KMA) is responsible for
generating the keys and the Group Management Agent (GMA) holds the group
list (GL) to which it is responsible for distributing the keys. Either
the KMA or GMA MAY:
- Support one GL or multiple GLs; - The Key Management Agent (KMA) which is responsible for
- Be collocated one a single platform or on separate platforms. generating the shared KEKs.
GLs are managed either through an automated process or by a human (an GL - The Group Management Agent (GMA) which is responsible for
Owner). Members of the GLs require access to the symmetric key therefore managing the Group List (GL) to which the shared KEKs are
adding and removing members is an important part of maintaining the distributed.
security for the entire group. If the GL is managed through an automated
process, mechanisms, beyond the scope of this document, may be used to
limit the addition of new members (e.g., using an access control list)
or the GL may be configured to allow anyone to join or depart from the
GL. If the GL is managed by a human, messages, beyond the scope of this
document, may be sent between the new member and the GL Owner requesting
the new member be added to the GL. The GL Owner may then decide whether
the new member should be added or not or the GL Owner may simply add a
new member, knowing the new member requires access to the messages. The
GL Owner may or may not be a member of the GL, but the GL Owner is the
only person(s) able to add or delete a GL.
+----------------------+ Turner 4
| Key Management Agent | +----------------------------------------------+
+----------------------+ | Group List Agent | +-------+
| | +------------+ + -----------------------+ | | Group |
+------------------+ | | Key | | Group Management Agent | |<-->| List |
| Group Management | | | Management |<-->| +------------+ | | | Owner |
| Agent | | | Agent | | | Group List | | | +-------+
| +-------+ | | +------------+ | +------------+ | |
| | Group | | | | / | \ | |
| | List | | | +------------------------+ |
| +-------+ | +----------------------------------------------+
| / | \ |
+------------------+
/ | \
/ | \ / | \
+----------+ +---------+ +----------+ +----------+ +---------+ +----------+
| Member 1 | | ... | | Member n | | Member 1 | | ... | | Member n |
+----------+ +---------+ +----------+ +----------+ +---------+ +----------+
Figure 1 - Key Distribution Architecture Figure 1 - Key Distribution Architecture
3 Protocol Interactions A GLA may support multiple KMAs. KMAs may be differentiated by the
'goodness' of the random number used to generate the shared KEK or
the key management technique used to distribute the shared KEK.
Outside the GLA, KMAs are differentiated by the digital signatures
they apply to the messages they generate.
A few basic interactions occur between the KMA, GMA, Members, and the A GLA in general supports only one GMA, but the GMA may support
optional GL Owner (used if the list is not managed by an automated multiple GLs. Multiple KMAs may support a GMA in the same fashion as
process) to support the management of the symmetric keys used by the GLAs support multiple KMAs. Assigning a particular KMA to a GL is
group (henceforth referred to as the group key). Management includes the beyond the scope of this document.
steps required to setup the group key, add new members, delete members,
and distribute a new group key (i.e., rekey). The following sections
describe the procedures for each of the management functions.
[ST - Need to add what's mandatory to implement here - I think sending Modeling real world GL implementations shows that there are very
and receiving gkDistribution messages; storing the distributed key; and restrictive GLs, where a human determines GL membership, and very
using the previously distributed key to decrypt future messages.] 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.
3.1 Group Key Administration 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.
Figure 2 depicts the scenarios for group key setup administration. Each Though Figure 1 depicts the GLA as encompassing both the KMA and GMA
of the interactions depicted is discussed in paragraphs 3.1.1, 3.1.2, functions, the two functions could be supported by the same entity
3.1.3, and 3.1.4. or they could be supported by two different entities. If two
entities are used, they could be located on one or two platforms.
There is however a close relationship between the KMA and GMA
functions. If the GMA stores all information pertaining to the GLs
and the KMA merely generates keys, a corrupted GMA could cause
havoc. To protect against a corrupted GMA, the KMA would be forced
+----------+ +----------+ Turner 5
| GL Owner | <---+ +----> | Member 1 | <--+ 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.
| KMA | <----------> | GMA | <---------------+----> | ... | <--+ 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.
| +----> | Member n | <--+
| +----------+ |
+----------------------------------------------------------------+
Figure 2 - Group Key Setup 3. Protocol Interactions
3.1.1 Request/Response Group Key Administration There are existing mechanisms (e.g., listserv and majordomo) to
support managing GLs; however, this document does not address
securing these mechanisms, as they are not standardized. Instead, it
defines protocol interactions, as depicted in Figure 2, used by the
GL members, GLA, and GLO to manage GLs and distribute shared KEKs.
The interactions have been divided into administration messages and
distribution messages. The administrative messages are the request
and response messages needed to setup the GL, delete the GL, add
members to the GL, delete members of the GL, and request a group
rekey, etc. The distribution messages are the messages that
distribute the shared KEKs. The following paragraphs describe the
ASN.1 for both the administration and distribution messages.
Paragraph 4 describes how to use the administration messages and
paragraph 5 describes how to use the distribution messages.
There are a number of administrative functions that must be performed to +-----+ +----------+
manage a GL: creating the GL, deleting the GL, adding members to the GL, | GLO | <---+ +----> | Member 1 |
deleting members of the GL, and requesting a group rekey. The group key +-----+ | | +----------+
administration request (gkaRequest) and group key administration | |
responses (gkaResponse) content-types, defined in paragraphs 3.1.1.1 and +-----+ <------+ | +----------+
3.1.1.2, are defined to support these administrative functions. The | GLA | <-------------+----> | ... |
gkaRequest and gkaResponse MAY be used between the GL Owner and the GMA +-----+ | +----------+
and between the GL Owner or GMA and the KMA to manage the GL. If the |
message is from the GMA to the KMA, it may be on behalf of the GL Owner | +----------+
or from the GL members. +----> | Member n |
+----------+
If the GL Owner supports the gkaRequest content-type, it MUST support Figure 2 - Protocol Interactions
the corresponding gkaResponse content-type. The GMA MAY support
forwarding the gkaRequest content-type from the GL Owner to the KMA and
the gkaResponse content-type from the KMA to the GL Owner. If the KMA
supports forwarding the gkaRequest it MUST support forwarding the
gkaResponse. The GMA MAY support generating the gkaRequest content-type
on behalf of prospective GL member or existing GL members. The KMA MAY
support receiving a gkaRequest content-type and generating a gkaResponse
content-type. If the KMA supports receiving the gkaRequest content-type
it must support generating the gkaResponse content-type.
3.1.1.1 Request For Group Key Administration Turner 6
The gkaRequest content-type is defined to support conveying group key 3.1 Control Attributes
administration requests from the GL Owner to the GMA or from the GMA to
the KMA. The gkaRequest content-type MUST be protected at a minimum by
id-signedData [CMS]. It MAY also be further enveloped by id-
envelopedData [CMS]. Other layers MAY also be used. The following object
identifier identifies the gkaRequest content-type:
id-ct-gkaRequest OBJECT IDENTIFIER ::= { TBD } The messages are based on including control attributes in CMC's
PKIData.controlSequence for requests and CMC's
ResponseBody.controlSequence for responses. The content-types
PKIData and PKIResponse are then encapsulated in CMS's SignedData or
EnvelopedData, or a combination of the two (see paragraph 3.2). The
following are the control attributes defined in this document:
The gkaRequest content type MUST have ASN.1 type GKARequest: Implementation
Requirement Control Attribute OID Syntax
-------------- ------------------ ----------- -----------------
MAY glUseKEK id-skd 1 GLUseKEK
MAY glDelete id-skd 2 GLDelete
MAY glAddMembers id-skd 3 GLAddMembers
MAY glDeleteMembers id-skd 4 GLDeleteMembers
MAY glRekey id-skd 5 GLRekey
MAY glAddOwners id-skd 6 GLAddOwners
MAY glRemoveOwners id-skd 7 GLRemoveOwners
MAY glkCompromise id-skd 8 GLKCompromise
SHOULD glkRefresh id-skd 9 GLKRefresh
MAY glSuccessInfo id-skd 10 GLSuccessInfo
MAY glFailInfo id-skd 11 GLFailInfo
MAY glAQueryRequest id-skd 12 GLAQueryRequest
MAY glAQueryResponse id-skd 13 GLAQueryResponse
MUST glKey id-skd 14 GLKey
GKARequest ::= SEQUENCE { GLSuccessInfo, GLFailInfo, and GLAQueryResponse are responses and go
gkaRequestVersion GKARequestVersion, into the PKIResponse content-type, all other messages are requests
gkAAction GKAAction, and go into the PKIData content-type.
transactionId TransactionId OPTIONAL}
GKAResquestVersion ::= INTEGER { v0(0) } 3.1.1 GL USE KEK
GKAAction ::= CHOICE { The GLO uses GLUseKEK to request that a shared KEK be assigned to a
createGL [0] GLInformation, GL.
deleteGL [1] GLInformation,
addGLMembers [2] GLInformation,
deleteGLMembers [3] GLInformation,
rekeyGL [4] GLInformation }
GLInformation ::= SEQUENCE { GLUseKEK ::= SEQUENCE {
glName GeneralName, glName GeneralName,
glIdentifier [0] OCTET STRING OPTIONAL, glOwner SEQUENCE SIZE (1..MAX) OF GeneralName,
glMembers [1] SEQUENCE OF GLMember OPTIONAL, glAdministration GLAdministration,
glOwner [2] GLOwner OPTIONAL, glDistributionMethod GLDistributionMethod,
effectiveDate [3] EffectiveDate OPTIONAL, glKeyAttributes [0] GLKeyAttributes OPTIONAL }
distributionDate [4] GeneralizedTime OPTIONAL }
GLMember ::= SEQUENCE { GLAdministration ::= INTEGER {
OPTIONAL,name GeneralName, unmanaged (0),
deliveryMethod [0] SEQUENCE OF DeliveryMethod OPTIONAL } managed (1),
certificates [1] CertificateSet OPTIONAL, closed (2) }
crls [2] CertificateRevocationListsOPTIONAL }
DeliveryMethod ::= CHOICE { Turner 7
GLDistributionMethod ::= CHOICE {
rfc822Name [0] IA5String, rfc822Name [0] IA5String,
x400Address [1] ORAddress, x400Address ORAddress,
directoryName [2] Name, directoryName Name,
uniformResourceIdentifier [3] IA5String, uniformResourceIdentifier [1] IA5String }
iPAddress [4] OCTET STRING }
GLKeyAttributes ::= SEQUENCE {
rekeyControlledByGLO [0] BOOLEAN DEFAULT FALSE,
recipientMutuallyAware [1] BOOLEAN DEFAULT TRUE,
duration [2] INTEGER DEAULT (0),
generationCounter [3] INTEGER DEFAULT {2},
requestedAlgorithm [4] AlgorithmIdentifier OPTIONAL }
The fields in GLUseKEK have the following meaning:
- glName is the name of the GL. The name MUST be unique for a
given GLA.
- glOwner indicates the owner of the GL. One of the names in
glOwner MUST match one of the names in the certificate used to
sign this SignedData.PKIData creating the GL (i.e., the
immediate signer). Multiple GLOs MAY be indicated if
glAdministration is set to managed or closed.
- glAdministration indicates how the GL should be administered.
The default is for the list to be unmanaged and to accept
requests from prospective members. Three possibilities exist:
- Unmanaged - When the GLO sets glAdministration to unmanaged,
they are allowing prospective members to request being added
and deleted from the GL without GLO intervention.
- Managed - When the GLO sets glAdministration to managed, they
are allowing prospective members to request being added and
deleted from the GL, but the request is sent to GLO for
review. The requests are redirected to the GLO. The GLO makes
the determination as to whether to honor the request.
- Closed - When the GLO sets glAdministration to closed, they
are not allowing prospective members to request being added
and deleted from the GL. The GLA will only accept GLAddMembers
and GLDeleteMembers requests from the GLO.
- glDistributionMethod indicates the mechanism the GLA should
distribute shared KEKs. Internet mail (rfc822Name) MUST be
supported and X.400 (x400Address), X.500 (directoryName), and
web (uniformResourceIdentifier) MAY be supported (see paragraph
8).
- glKeyAttributes indicates the attributes the GLO wants the GLA
to assign to the shared KEK. If the field is omitted, GL rekeys
Turner 8
will be controlled by the GLA, the recipients are allowed to
know about one another, the algorithm will be as specified in
paragraph 7, the shared KEK will be valid for a calendar month
(i.e., first of the month until the last day of the month), and
two shared KEKs will be distributed initially. The fields in
glKeyAttributes have the following meaning:
- rekeyControlledByGLO indicates whether the GL rekey messages
will be generated by the GLO or by the GLA. The default is for
the GLA to control rekeys. If GL rekey is controlled by the
GLA, the GL will continue to be rekeyed until the GLO deletes
the GL or changes the GL rekey to be GLO controlled.
- recipientsMutuallyAware indicates that the GLO wants the GLA
to distribute the shared KEK individually for each of the GL
members (i.e., a separate GLKey message is sent to each
recipient). The default is for separate GLKey message to not
be required.
NOTE: This supports lists where one member does not know the
identities of the other members. For example, a list is
configured granting submit permissions to only one member. All
other members are 'listening.' The security policy of the list
does not allow the members to know who else is on the list. If
a GLKey is constructed for all of the GL members, information
about each of the members may be derived from the information
in RecipientInfos. To make sure the GLKey message does not
divulge information about the other recipients, a separate
GLKey message would be sent to each GL member.
- duration indicates the length of time (in days) during which
the shared KEK is considered valid. The value zero (0)
indicates that the shared KEK is valid for a calendar month.
For example if the duration is zero (0), if the GL shared KEK
is requested on July 24, the first key will be valid until the
end of July and the next key will be valid for the entire
month of August. If the value is not zero (0), the shared KEK
will be valid for the number of days indicated by the value.
For example, if the value of duration is seven (7) and the
shared KEK is requested on Monday but not generated until
Tuesday (2359); the shared KEKs will be valid from Tuesday
(2359) to Tuesday (2359). The exact time of the day is
determined when the key is generated.
- generationCounter indicates the number of keys the GLO wants
the GLA to distribute. To ensure uninterrupted function of the
GL two (2) shared KEKs at a minimum MUST be initially
distributed. The second shared KEK is distributed with the
first shared KEK, so that when the first shared KEK is no
longer valid the second key can be used. See paragraphs 4.5
and 5 for more on rekey.
Turner 9
- requestedAlgorithm indicates the algorithm and any parameters
the GLO wants the GLA to use to generate the shared KEK. See
paragraph 7 for more on algorithms.
3.1.2 GL Delete
GLOs use GLDelete to request that a GL be deleted from the GLA.
GLDelete ::= GLNameAndIdentifier
GLNameAndIdentifier ::= SEQUENCE {
glName GeneralName,
glIdentifier GLIdentifier OPTIONAL }
The fields in GLDelete have the following meaning:
- glName indicates the name of the GL to be deleted.
- glIdentifier indicates the identifier of the GL to be deleted.
It MAY be omitted if it is unknown (e.g., the GLO hasn't
received a GLSuccessInfo assigning the glIdentifier to the GL)
or has been lost by the GLO.
3.1.3 GL Add Members
GLOs use GLAddMembers to request addition of new members and
prospective GL members' use GLAddMembers to request being added to
the GL.
GLAddMembers ::= SEQUENCE {
glName GeneralName,
glMembers SEQUENCE SIZE (1..MAX) OF GLMember,
glIdentifier GLIdentifier OPTIONAL }
GLMember ::= SEQUENCE {
glMemberName GeneralName,
certificates Certificates }
Certificates ::= SEQUENCE {
membersPKC Certificate,
-- See X.509
membersAC SEQUENCE OF AttributeCertificate OPTIONAL,
-- See X.509
certificationPath CertificateSet OPTIONAL }
-- From CMS [2]
CertificateSet ::= SET OF CertificateChoices CertificateSet ::= SET OF CertificateChoices
Turner 10
CertificateChoices ::= CHOICE { CertificateChoices ::= CHOICE {
certificate Certificate, -- See X.509 certificate Certificate, -- See X.509
extendedCertificate [0] IMPLICIT ExtendedCertificate, extendedCertificate [0] IMPLICIT ExtendedCertificate,
-- Obsolete -- Obsolete
attrCert [1] IMPLICIT AttributeCertificate } attrCert [1] IMPLICIT AttributeCertificate }
-- See X.509 and X9.57 -- See X.509 and X9.57
CertificateRevocationLists ::= SET OF CertificateList The fields in GLAddMembers have the following meaning:
GLOwner ::= SEQUENCE { - glName indicates the name of the GL to which the member should
name GeneralName, be added.
administered BOOLEAN DEFAULT FALSE OPTIONAL }
EffectiveDate ::= SEQUENCE { - glMembers indicates the particulars for the GL member(s) to be
notBefore [0] GeneralizedTime, added to the GL. GLMemberName indicates the name of the GL
notAfter [1] GeneralizedTime OPTIONAL } member. certificates.membersPKC includes the member's encryption
certificate that will be used to encrypt the shared KEK for that
member. certificates.membersAC MAY be included to convey any
attribute certificate associated with the member's encryption
certificate. certificates.certificationPath MAY also be included
to convey the certification path corresponding to the member's
encryption and attribute certificates. The certification path is
optional because it may already be included elsewhere in the
message (e.g., in the outer CMS layer).
TransactionId ::= OCTET STRING - glIdentifier indicates the identifier of the GL to which the
member should be added. It MAY be omitted if it is unknown
(e.g., the GLO hasn't received a GLSuccessInfo assigning the
glIdentifier to the GL) or has been lost by the GLO. The
prospective GL member MAY omit this field. The GLO MUST omit the
field if the GLAddMembers associated GLUseKEK message is
included in the same SignedData.PKIData content-type.
The fields in GKSResponse have the following meaning: 3.1.4 GL Delete Members
Note: The support requirement for the fields is determined by the action GLOs use GLDeleteMembers to request deletion of GL members and
being performed; therefore, the support requirements are indicated in prospective non-GL members use GLDeleteMembers to request being
paragraphs 3.1.1.3 through 3.1.1.7, where the specific actions are removed from the GL.
defined.
- version is the syntax version number. The version number MUST be 0. GLDeleteMembers ::= SEQUENCE {
glName GeneralName,
glMembersToDelete SEQUENCE SIZE (1..MAX) OF GeneralName,
glIdentifier GLIdentifier OPTIONAL }
- gkaAction indicates the action that the GL Owner requests the GMA The fields in GLDeleteMembers have the following meaning:
perform, thatthe GL Owner requests the KMA perform, or the GMA requests
the KMA perform. The GL Owner MAY request that either the KMA or GMA
create a GL (createGL), delete a GL (deleteGL), add a member to a
specific GL (addGLMembers), delete a member of a specific GL
(deleteGLMember), or rekey a GL (rekeyGL). When the GL Owner requests
the actions of the GMA the action MUST be forwarded to the KMA. The GMA
MAY request, on behalf of the GL members, that a member be added or
deleted, assuming the GL policy allows this function. All of the actions
have the same syntax (GLInformation). Different combinations of the
GLInformation are used to provide information necessary for the KMA or
GMA to perform its requested action. The field combinations are
discussed in 3.1.1.3 through 3.1.1.7, but fields in GLInformation have
the following meaning:
- glName is the name of the GL. - glName indicates the name of the GL from which the member should
be removed.
- glIdentifier is the GL identifier. The GL identifier identifies Turner 11
the specific GL on the GMA (the GMA may support multiple GLs). It is - glMembersToDelete indicates the name of the member to be
derived from the group key and is returned by the KMA. deleted.
- gkMembers is a collection of the member(s) that should be either - glIdentifier indicates the identifier of the GL to which the
added or deleted from the GL. The member's name is a GeneralName. member should be deleted. The prospective non-GL member MUST
deliveryMethod identifies the method by which and address or location to include the field. The GLO MAY omit this field if it is unknown
which the KMA should distribute the group key. Only one choice for each (e.g., the GLO hasn't received a GLSuccessInfo assigning the
of the type is allowed (i.e., only one rfc822Name may appear for a given glIdentifier to the GL) or has been lost by the GLO.
member). certificates and crls are the member's certificate, associated
certificates, and associated certificate revocation lists (CRLs).
- glOwner is the owner of the GL. It identifies the entity that 3.1.5 GL Rekey
controls the GL. It also indicates whether the GL is managed or
unmanaged.
- effectiveDate indicates the dates that the GL Owner wants the KMA GLOs use the GLRekey to request a GL rekey.
to set the gkNotBefore and gkNotAfter to (see paragraph 3.1.2). The
notBefore date indicates the date the GL Owner wants the key to become
effective and the notAfter indicates the date the GL Owner wants the key
to become invalid.
- distributionDate indicates the date that the GL Owner wants the GLRekey ::= SEQUENCE {
key distributed. glName GeneralName,
glIdentifier GLIdentifier,
glOwner SEQUENCE SIZE (0..MAX) OF GeneralName,
glAdministration GLAdministration OPTIONAL,
glDistributionMethod GLDistributionMethod OPTIONAL,
glKeyAttributes GLKeyAttributes OPTIONAL }
- transactionID supports the recipient of a response message to The fields in GLRekey have the following meaning:
correlate this with a previously issued request. For example, in the
case of a GMA, which supports multiple GLs, there may be many requests
"outstanding" at a given moment.
3.1.1.2 Response To Group Key Administration - glName indicates the name of the GL to be rekeyed.
Upon receipt of the gkaRequest content-type the KMA MUST use the - glIdentifier identifies the shared KEK to be rekeyed.
gkaResponse content-type to indicate the success or failure of the
request. The gkaResponse is not sent until after the KMA has determined
whether the member is able to receive the key. The KMA may not be able
to send the member a group key because either the deliveryMethod is
unsupported or the member's certificate is invalid. The id-gkaRequest
content-tye MUST be processed according to [CMS]. The KMA MUST validate
the member's certificate and associated certificates to the KMA trusted
CA according to [PROFILE] prior to sending a gkaResponse message
indicating success. The gkaResponse message MUST be protected at a
minimum by id-signedData [CMS]. Other layers MAY also be used. The
following object identifier identifies the gkaRequest content type:
id-ct-gkaResponse OBJECT IDENTIFIER ::= { TBD } - glOwner indicates the owner(s) of the GL. The field is only
included if there is a change from the registered GLOs.
The gkaResponse content type MUST have ASN.1 type GKAResponse: - glAdministration indicates how the GL should be administered.
See paragraph 3.1.1 for the three options. This field is only
included if there is a change from the previously registered
administered.
GKAResponse ::= SEQUENCE { - glDistributionMethod indicates the mechanism the shared KEK
gkaResponseVersion GKAResponseVersion, should be distributed. The field is only included if there is a
success BOOLEAN DEFAULT TRUE, change from the previously registered glDistributionMethod.
glIdentifier OCTET STRING OPTIONAL,
errorCode ErrorCode OPTIONAL, - glKeyAttributes indicates whether the rekey of the GLO is
transactionId TransactionId OPTIONAL, controlled by the GLA or GL, what algorithm and parameters the
supportDeliveryMethods DeliveryMethod OPTIONAL} GLO wishes to use, the duration of the key, and how many
outstanding keys should be issued. The field is only included if
there is a change from the previously registered
glKeyAttributes. If the value zero (0) is specified in
generationCounter the GLO is indicating that it wants all of the
outstanding GL shared KEKs rekeyed. For example, suppose the GLO
used the GLUseKEK with duration set to two (2) and the GLRekey
message is sent during the first duration with generationCounter
set to zero (0). The GLA would know to generate a GLKey message
Turner 12
to replace both the shared KEK currently being used and the
shared KEK for the second duration.
3.1.6 GL Add Owner
GLOs use the GLAddOwners to request that a new GLO be allowed to
administer the GL. These requests are only applicable to GLs that
are managed (i.e., administered.managed) or closed (i.e.,
administered.closed).
GLAddOwners ::= GLOwnerAdministration
GLOwnerAdministration ::= SEQUENCE {
glName GeneralName,
glOwner SEQUENCE SIZE (1..MAX) OF GeneralName,
glIdentifier GLIdentifier OPTIONAL }
The fields in GLAddOwners have the following meaning:
- glName indicates the name of the GL to which the new GLO should
be associated.
- glOwner indicates the name(s) of the new GLO(s).
- glIdentifier optionally indicates the identifier of the GL to
which the GLO should be associated. It MAY be omitted if it is
unknown (e.g., the GLO hasn't received a GLSuccessInfo assigning
the glIdentifier to the GL) or has been lost by the GLO
3.1.7 GL Remove Owner
GLOs use the GLRemoveOwners to request that a GLO be disassociated
with the GL. These requests are only applicable to managed GLs.
GLRemoveOwners ::= GLOwnerAdministration
The fields in GLRemoveOwners have the following meaning:
- glName indicates the name of the GL to which the GLO should be
disassociated.
- glOwner indicates the name of the GLO.
- glIdentifier optionally indicates the identifier of the GL to
which the GLO should be disassociated. It MAY be omitted if it
is unknown (e.g., the GLO hasn't received a GLSuccessInfo
assigning the glIdentifier to the GL) or has been lost by the
GLO
Turner 13
3.1.8 GL Key Compromise
GL members use GLKCompromise to indicate that the shared KEK they
possessed has been compromised.
GLKCompromise ::= GLNameAndIdentifier
The fields in GLKeyCompromise have the following meanings:
- glName indicates the name of the GL.
- glIdentifier indicates the identifier of the GL for which the
shared KEK is associated. The GL members MAY omit this field if
it is unknown.
3.1.9 GL Key Refresh
GL members use the GLKRefresh to request that the shared KEK be
redistributed to them.
GLKRefresh ::= GLNameAndIdentifier
The fields in GLKRefresh have to following meaning:
- glName indicates the name of the GL.
- glIdentifier indicates the identifier of the GL for which the
shared KEK is associated. The GL members MAY omit this field if
it is unknown.
3.1.10 GL Success Information
The GLA uses GLSuccessInfo to indicate a successful result of an
administrative message.
GLSuccessInfo ::= SEQUENCE {
glName GeneralName,
glIdentifier GLIdentifier,
action SEQUENCE SIZE (1..MAX) OF Action }
** With multiple GLOs do we want to indicate which GLO asked for the
action to be performed? **
Action ::= SEQUENCE {
actionCode ActionCode,
glMemberName [0] GeneralName OPTIONAL,
glOwnerName [1] GeneralName OPTIONAL }
Turner 14
ActionCode ::= INTEGER {
assignedKEK (0),
deletedGL (1),
addedMember (2),
deletedMember (3),
rekeyedGL (4),
addedGLO (5),
removedGLO (6) }
The fields in GLSuccessInfo have the following meaning:
- glName indicates the name of the GL.
- glIdentifier identifies the specific GL on the GLA (the GLA may
support multiple GLs).
- action indicates the successfully performed action.
action.actionCode indicates whether the shared KEK was assigned
to the GL, whether the GL was deleted, whether a member was
added or deleted to or from a specific GL, whether the GL
rekeyed, whether a new GLO was added, and whether a GLO was
deleted. If members were added or deleted from a GL the members
MUST be indicated in glMemberName. If a GLO was added or
deleted from the GL, the GLO(s) MUST be indicated in
glOwnerName.
3.1.11 GL Fail Information
The GLA uses GLFailInfo to indicate that there was a problem
performing a requested action.
GLFailInfo ::= SEQUENCE {
glName GeneralName,
error SEQUENCE SIZE (1..MAX) OF Error,
glIdentifier GLIdentifier OPTIONAL }
** With multiple GLOs do we want to indicate which GLO asked for the
action to be performed? **
Error ::= SEQUENCE {
errorCode ErrorCode,
glMemberName [0] GeneralName OPTIONAL,
glOwnerName [1] GeneralName OPTIONAL }
Turner 15
ErrorCode ::= INTEGER { ErrorCode ::= INTEGER {
unspecified (0), unspecified (0),
-- Unspecified indicates that the KMA is unable to closedGL (1)
-- distribute a group key to the member, but the KMA is unsupportedDuration (2)
-- unwilling to indicate why. unsupportedDistribtuionMethod (3),
managedGL (1)
-- Indicates that members can only be added or deleted by the GL
-- Owner. It is sent back to the requestor if the entity requesting
-- an addition is not the GL Owner.
effectiveDateTooLong (2)
-- Returned if the KMA does not support generating keys that are
-- valid for the entire requested effective dates.
unsupportedDeliveryMethod (3),
-- Unsupported delivery method indicates that the KMA does
-- not support any of the requested delivery methods.
invalidCert (4), invalidCert (4),
-- Certificate for member was not verifiable (i.e., signature unsupportedAlgorithm (5),
-- did not validate, certificate present on a CRL, etc.) noGLONameMatch (6),
} invalidGLName (7),
invalidGLNameGLIdentifierCombination (8),
nameAlreadyInUse (9),
noSpam (10),
deniedAccess (11),
alreadyAMember (12),
notAMember (13),
alreadyAnOwner (14)
notAnOwner (15) }
GKAResponseVersion ::= INTEGER { v0(0) } The fields in GLFailInfo have the following meaning:
The fields in GKAResponse have the following meaning: - glName indicates the name of the GL to which the error
corresponds.
- version is the syntax version number. It MUST be 0. - error indicates the reason why the GLA was unable to perform the
request. It also indicates the GL member or GLO to which the
error corresponds. If the error corresponds to a GL member or
GLO, a separate Error sequence MUST be used for each GL member
or GLO. The errors are returned under the following conditions:
- success indicates whether the KMA is able to send a group key to the - unspecified indicates that the GLA is unable to perform the
member. If the KMA is unable to distribute the group key to the member, requested action but is unwilling to indicate why.
it MUST indicate an errorCode.
- glIdentifier indicate the GL identifier, derived from the group key. - closedGL indicates that members can only be added or deleted
by the GLO.
- errorCode indicates the reason why the KMA was unable to distribute - unsupportedDuration indicates the GLA does not support
a group key to the member. Reasons include unspecified, managedGL, generating keys that are valid for the requested duration.
effectiveDateTooLong, unsupportedDeliveryMethod, and invalidCert.
- transactionID supports the recipient of a response message to - unsupportedDistribtuionMethod indicates that the GLA does not
correlate this with a previously issued request. For example, in the support any of the requested delivery methods.
case of a GMA, which supports multiple GLs, there may be many requests
"outstanding" at a given moment.
- supportedDeliveryMethod MAY be included the indicate the delivery - invalidCert indicates the member's encryption certificate was
methods the KMA supports. not verifiable (i.e., signature did not validate, certificate
present on a CRL, etc.)
3.1.1.3 Create Group - unsupportedAlgorithm indicates the GLA does not support the
requested algorithm.
Prior to generating a group key, a GL MUST be setup. The GL Owner is - noGLONameMatch indicates the name in one of the certificates
responsible for creating the GL (1 in Figure 3). The GL Owner MAY use a used to sign a request does not match the name of the
proprietary mechanism (e.g., listserv or majordomo) or the group key registered GLO.
administration mechanism defined in the paragraph below to perform this
function.
+----------+ 2,4{3} Turner 16
| GL Owner | <-----+ - invalidGLName indicates the GLA does not support the glName
+----------+ | present in the request.
1 |
+-----+ 2{1} 3 +-----+ <-----+ - invalidGLNameGLIdentifierCombination indicates the GLA does
| KMA | <-------> | GMA | not support the glName and glIdentifier present in the
request.
- nameAlreadyInUse indicates the glName is already assigned on
the GLA.
- noSpam indicates the prospective GL member did not sign the
request (i.e., if the name in glMembers.glMemberName does not
match one of the names in the certificate used to sign the
request).
- alreadyAMember indicates the prospective GL member is already
a GL member.
- notAMember indicates the prospective non-GL member is not a GL
member.
- alreadyAnOwner indicates the prospective GLO is already a GLO.
- notAnOwner indicates the prospective non-GL member is not a
GLO.
- glIdentifier identifies the specific GL. It MAY be omitted if
the response is a result of a GLUseKEK request otherwise it MUST
be present.
3.1.12 GLA Query Request
GLOs use the GLQueryRequest to ascertain what type of GL the GLA
supports.
GLAQueryRequest ::= SEQUENCE SIZE (1..MAX) OF GLOQuestions
GLOQuestions ::= INTEGER {
supportedAlgorithms (0),
distributionMethods (1) }
The fields in GLAQueryRequest have the following meaning:
- supportedAlgorithms indicates the GLO would like to know the
algorithms the GLA supports for generating and distribution the
shared KEK.
- distributionMethod indicates the GLO would like to know the
distribution methods the GLA supports for distributing the
shared KEK.
Turner 17
3.1.13 GLA Query Response
GLA's return the GLAQueryResponse after receiving a GLAQueryRequest.
GLAQueryResponse ::= SEQUENCE {
supportedAlgorithms SEQUENCE OF AlgorithmIdentifier OPTIONAL,
distributionMethods SEQUENCE OF GLDistributionMethod OPTIONAL }
The fields in GLAQueryResponse have the following meaning:
- supportAlgorithms indicates the algorithm(s) and parameters that
GLA supports for generating and distributing the shared KEK.
- distributionMethod indicates the distribution method(s) the GLA
supports for distribution the shared KEK.
3.1.14 GL Key
The GLA uses GLKey to distribute the shared KEK.
GLKey ::= SEQUENCE {
glName GeneralName,
glIdentifier GLIdentifier,
glkWrapped RecipientInfos, -- See CMS [2]
glkAlgorithm AlgorithmIdentifier,
glkNotBefore GeneralizedTime,
glkNotAfter GeneralizedTime }
GLIdentifier ::= CHOICE {
issuerNameAndCounter [0] IssuerNameAndCounter,
keyIdentifierAndCounter [1] KeyIdentifierAndCounter }
IssuerNameAndCounter ::= SEQUENCE {
issuer GeneralName,
counter INTEGER }
KeyIdentifierAndCounter ::= SEQUENCE {
keyIdentifier SubjectKeyIdentifier,
counter INTEGER }
SubjectKeyIdentifier ::= OCTET STRING
The fields in GLKey have the following meaning:
- glName is the name of the GL.
- glIdentifier identifies the specific GL on the GLA (the GLA may
support multiple GLs). Two options are provided. The
issuerNameAndCounter alternative identifies the GLA's who
Turner 18
created shared KEK and a counter. The keyIdentifierAndCounter
choice identifies the GLA's certificate that was used to encrypt
the shared KEK for the GL members and a counter. In either case
the counter is a monotonically increasing number. The
keyIdentifierAndCounter choice MUST be supported.
- glkWrapped is the GL's wrapped shared KEK. The RecipientInfos
shall be generated as specified in paragraph 6.2 of CMS [2]. The
kari RecipientInfo choice MUST be supported. The EncryptedKey
field, which is the shared KEK, MUST be generated according to
the paragraph concerning random number generation in the
security considerations of CMS [2].
- glkAlgorithm identifies the algorithm the shared KEK is used
with.
- glkNotBefore indicates the date at which the shared KEK is
considered valid. GeneralizedTime values MUST be expressed
Greenwich Mean Time (Zulu) and MUST include seconds (i.e., times
are YYYYMMDDHHMMSSZ), even where the number of seconds is zero.
GeneralizedTime values MUST NOT include fractional seconds.
- glkNotAfter indicates the date after which the shared KEK is
considered invalid. GeneralizedTime values MUST be expressed
Greenwich Mean Time (Zulu) and MUST include seconds (i.e., times
are YYYYMMDDHHMMSSZ), even where the number of seconds is zero.
GeneralizedTime values MUST NOT include fractional seconds.
3.2 Use of CMC, CMS, and PKIX
3.2.1 Protection Layers
3.2.1.1 Minimum Protection
At a minimum, a SignedData MUST protect each request and response
encapsulated in PKIData and PKIResponse. The following is a
depiction of the minimum wrappings:
Minimum Protection
------------------
SignedData
PKIData or PKIResponse
controlSequence
Prior to taking any action on any request or response SignedData(s)
MUST be processed according to CMS [2].
Turner 19
3.2.1.2 Additional Protection
An additional EnvelopedData MAY also be used to provide
confidentiality of the request and response. An additional
SignedData MAY also be added to provide authentication and integrity
of the encapsulated EnvelopedData. The following is a depiction of
the optional additional wrappings:
Confidentiality Protection A&I of Confidentiality Protection
-------------------------- ---------------------------------
EnvelopedData SignedData
SignedData EnvelopedData
PKIData or PKIResponse SignedData
controlSequence PKIData or PKIResponse
controlSequence
If an incoming message was encrypted, the corresponding outgoing
message MUST also be encrypted. All EnvelopedData objects MUST be
processed as specified in CMS [2].
If the GLO or GL member applies confidentiality to a request, the
EnvelopedData MUST be encrypted for the GLA. If the GLA is supposed
to forward the GL member request GLO, the GLA decrypts the
EnvelopedData, strips the confidentiality layer off, and applies its
own confidentiality layer for the GLO.
3.2.2 Combining Requests and Responses
Multiple requests and responses MAY be combined in one PKIData or
PKIResponse by using PKIData.cmsSequence and
PKIResponse.cmsSequence. A separate cmsSequence MUST be used for
different GLs (i.e., requests corresponding to two different GLs are
included in different cmsSequences). The following is a diagram
depicting multiple requests and responses combined in one PKIData
and PKIResponse:
Turner 20
Multiple Request and Response
Request Response
------- --------
SignedData SignedData
PKIData PKIResponse
cmsSequence cmsSequence
SignedData SignedData
PKIData PKIResponse
controlSequence controlSequence
Zero or more requests Zero or more responses
corresponding to one GL. corresponding to one GL.
SignedData SignedData
PKIData PKIResponse
controlSequence controlSequence
Zero or more requests Zero or more responses
corresponding to one GL. corresponding to one GL.
When applying confidentiality to multiple requests and responses,
either each request or response MAY be encrypted individually or all
of the requests/response MAY be included in one EnvelopedData. The
following is a depiction of the choices using PKIData:
Confidentiality of Multiple Requests and Responses
Individually Wrapped Wrapped Together
-------------------- ----------------
SignedData EnvelopedData
PKIData SignedData
cmsSequence PKIData
EnvelopedData cmsSequence
SignedData SignedData
PKIData PKIResponse
controlSequence controlSequence
Zero or more requests Zero or more requests
corresponding to one GL. corresponding to one GL.
EnvelopedData SignedData
SignedData PKIData
PKIData controlSequence
controlSequence Zero or more requests
Zero or more requests corresponding to one GL.
corresponding to one GL.
Turner 21
Certain combinations of requests in one PKIData.controlSequence and
one PKIResponse.controlSequence are not allowed. The invalid
combinations listed here MUST NOT be generated:
Invalid Combinations
---------------------------
GLUseKEK & GLDeleteMembers
GLUseKEK & GLRekey
GLUseKEK & GLDelete
GLDelete & GLAddMembers
GLDelete & GLDeleteMembers
GLDelete & GLRekey
GLDelete & GLAddOwners
GLDelete & GLRemoveOwners
GLFailInfo & GLKey
To avoid unnecessary errors, certain requests and responses should
be processed prior to others. The following is the priority of
message processing, if not listed it is an implementation decision
as to which to process first: GLUseKEK before GLAddMembers,
GLAddMembers before GLRekey, GLDeleteMembers before GLRekey, and
GLSuccessInfo before GLKey.
** Need to think more about the priority of processing **
3.2.3 GLA Generated Messages
When the GLO generates a GLSuccessInfo, it generates one for the GL
member and another for the GLO, depending on the actionCode.
action.actionCode values of assignedKEK, deletedGL, rekeyedGL,
addedGLO, and deletedGLO are not returned to GL members. Likewise,
when the GLO generates GLFailInfo it generates one for the GL member
and one for the GLO, depending on the actionCode. error values of
unsupportedDuration, unsupportedDeliveryMethod,
unsupportedAlgorithm, noGLONameMatch, nameAlreadyInUse,
alreadyAnOwner, notAnOwner are not returned to GL members.
Separate GLSucessInfo, GLFailInfo, and GLKey messages MUST be
generated for each recipient if GL was setup with
GLKeyAttributes.recipientMutuallyAware set to FALSE.
If the GL has multiple GLOs, the GLA MUST send a copy of all
GLSuccessInfo and GLFailInfo messages to each GLO.
If a GL is managed and the GLA receives a prospective GL member add
or delete request or the GLO receives a GLFailInfo from the GL. and
the GL is managed, the GLA forwards the request to the GLO for
review. An additional, SignedData MUST be applied to the forwarded
request as follows:
Turner 22
GLA Forwarded Requests
----------------------
SignedData
PKIData
cmsSequence
PKIData
controlSequence
3.2.4 CMC Control Attributes
** Elaborate more **
Can use:
CMCFailInfo.badMessageCheck - To indicate signature did not verify.
transactionId - To track particular requests/responses.
senderNonce and recipientNonce - For sequence integrity.
3.2.5 PKIX
Signatures, certificates, and CRLs are verified according to PKIX
[5].
Name matching is performed according to PKIX [5].
4 Administrative Messages
There are a number of administrative messages that must be performed
to manage a GL: creating the GL, deleting the GL, adding members to
the GL, deleting members from the GL, and requesting a group rekey.
The following sections describe each of messages' request and
response combinations in detail. The GLKRefresh procedures in
paragraph 4.8 SHOULD be implemented all other procedures MAY be
implemented.
4.1 Assign KEK To GL
Prior to generating a group key, a GL MUST be setup. Figure 3
depicts the protocol interactions to setup a GL. Note that error
messages are not depicted in Figure 3.
+-----+ 1 2 +-----+
| GLA | <-------> | GLO |
+-----+ +-----+ +-----+ +-----+
Figure 3 - Create Group List Figure 3 - Create Group List
If the GL Owner decides to use the gkaRequest content-type to setup the Turner 23
GL on the GMA, the gkaRequest content-type MUST be submitted to the GMA The process is as follows:
(1 in Figure 2) with the gkaAction.createGL CHOICE. The format for the
createGL CHOICE is as follows:
- glName MUST be included to indicate the name of the GL. The value 1 - The GLO is the entity responsible for requesting the creation
must be unique for a given distribution method. of the GL. The GLO sends a
SignedData.PKIData.controlSequence.GLUseKEK request to the GLA
(1 in Figure 3). The GLO MUST include: glName, glOwner,
glAdministration, distributionMethod. The GLO MAY also include
their preferences for the shared KEK in glKeyAttributes by
indicating whether the GLO controls the rekey in
rekeyControlledByGLO, whether separate GLKey messages should
be sent to each recipient in recipientMutuallyAware, the
requested algorithm to be used with the shared KEK in
requestedAlgorithm, the duration of the shared KEK, and how
many shared KEKs should be initially distributed in duration
and generationCounter, respectively.
- glIdentifier MUST be omitted as the value is derived from the group a - If the GLO knows of members to be added to the GL, the
key, which is not yet created. GLAddMembers request MAY be included in the same
controlSequence as the GLUseKEK request (see paragraph
3.2.2). The GLO MUST indicate the same glName in the
GLAddMembers request as in GLUseKEK.glName. The GLO MUST
also include the member's encryption certificate in
certificate.membersPKC. The GLO MAY also include any
attribute certificates associated with the member's
encryption certificate in membersAC and the certification
path for the member's encryption and attribute certificates.
The GLO MUST omit the glIdentifier, as it is unknown at this
point in the setup procedure.
- glMembers MAY be included to indicate the member(s) to be added. If b - The GLO MAY optionally apply confidentiality to the request
members are included the name of the member MUST be include in by encapsulating the SignedData.PKIData in an EnvelopedData
GLMember.name. The delivery method MAY be included. If the GMA does not (see paragraph 3.2.1.2).
support the requested delivery method an error MUST be returned. The
members certificates and crls MAY also be included.
- glOwner.name MUST be included to indicate the Owner of the GL. The c - The GLO MAY also optionally apply another SignedData over
GL Owner is the only entity allowed to delete the GL (see paragraph the EnvelopedData (see paragraph 3.2.1.2).
3.1.1.4). If the list is to be managed (i.e., only allow the GL Owner
to add or delete GL members) glOwner.administered MUST be set to TRUE;
otherwise, the list is considered to be unmanaged. The GMA MUST only
allow additions (see paragraph 3.1.1.5) to the GL if one of the glOwner
names matches one of the names associated with one of the certificates
used to sign the id-signedData.
- effectiveDate MAY be included to indicate the dates the GL Owner 2 - Upon receipt of the request, the GLA verifies the signature on
wishes the key to become effective. If this field is omitted the GMA the inner most SignedData.PKIData. If an additional SignedData
assumes the gkNotBefore date (see paragraph 3.1.2) is the GMA's current and/or EnvelopedData encapsulates the request (see paragraph
date. 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.
- distributionDate MAY be included to indicate the date the GL Owner a - If the signature(s) does(do) not verify, the GLA MUST return
wishes the key to be distributed. If the distributitionDate is omitted a response indicating CMCFailInfo.badMessageCheck.
the GMA assumes the group key should be distributed immediately.
The GMA then forwards the gkaRequest content-type to the KMA (2{1} in b - If the signature(s) does(do) verify, the GLA MUST check that
Figure 3). An additional id-signedData or some other combination of id- one of the names in the certificate used to sign the request
signedData and id-envelopedData MAY protect the forwarded content-type. matches the name in CreateGL.glOwner.
Upon receipt of the gkaRequest content-type, the KMA verifies the Turner 24
gkaRequest content-type and returns a gkaResponse (3 in Figure 3). If 1 - If the names do not match, the GLA MUST return a response
the GL can be created as requested, the KMA MUST return a gkaResponse to indicating GLFailInfo.errorCode.noGLONameMatch.
the GMA indicating success and the glIdentifier of the newly created
list. If the GL can not be created as requested the KMA returns a
gkaResponse to the GMA indicating failure along with an errorCode.
If there are members included in the gkaRequest the KMA MUST use the 2 - If names do all match, the GLA MUST ensure the combination
mechanism described in paragraph 3.2 to distribute the group key. of the requested glName is not already in use. The GLA
MUST also check any GLAddMembers included within the
controlSequence with this GLCreate. Further processing of
the GLAddMembers is covered in paragraph 4.3.
The GMA then forwards the gkaResponse content-type to the GL Owner (4{3} a - If the glName is already in use the GLA MUST return a
in Figure 3). An additional id-signedData or some other combination of response indicating
id-signedData and id-envelopedData MAY protect the forwarded conent- GLFailInfo.errorCode.nameAlreadyInUse.
type.
3.1.1.4 Delete Group b - If the requestedAlgorithm is not supported, the GLA MUST
return a response indicating
GLFailInfo.errorCode.unsupportedAlgorithm.
To delete a GL (1 in Figure 4), the GL Owner MAY use a proprietary c - If the duration is not supportable, determining this is
mechanim (e.g., listserv or majordomo) or the group key administration beyond the scope of this document, the GLA MUST return a
mechanism defined in the paragraph below to perform this function. Only response indicating
the GL Owner can request that a GL be deleted. GLFailInfo.errorCode.unsupportedDuration.
+----------+ 2,4{3} d - If the GL is not supportable for other reasons, which
| GL Owner | <-----+ the GLA does not wish to disclose, the GLA MUST return a
+----------+ | response indicating GLFailInfo.errorCode.unspecified.
1 |
+-----+ 2{1} 3 +-----+ <-----+ e - If the glName distribution is not already in use, the
| KMA | <-------> | GMA | duration is supportable, and the requestedAlgorithm is
supported, the GLA MUST return a GLSuccessInfo to all
GLOs indicating the glName, the corresponding
glIdentifier, and an action.actionCode.assignedKEK (2 in
Figure 3). The GLA also takes administrative actions,
which are beyond the scope of this document, to store
the glName, distributionMethod, glOwner, and any member
that has been added.
1 - The GLA MUST apply confidentiality to the response by
encapsulating the SignedData.PKIResponse in an
EnvelopedData if the request was encapsulated in an
EnvelopedData (see paragraph 3.2.1.2).
2 - The GLA MAY also optionally apply another SignedData
over the EnvelopedData (see paragraph 3.2.1.2).
3 - Upon receipt of the GLSuccessInfo or GLFailInfo responses, the
GLO verifies the GLA's signature(s). If an additional
SignedData and/or EnvelopedData encapsulates the response (see
paragraph 3.2.1.2 or 3.2.2), the GLO MUST verify the outer
signature and/or decrypt the outer layer prior to verifying
the signature on the inner most SignedData.
Turner 25
a - If the signatures do not verify, the GLO MUST return a
response indicating CMCFailInfo.badMessageCheck.
b - If the signatures do verify and the response was
GLSuccessInfo, the GLO has successfully created the GL.
c - If the signatures do verify and the response was GLFailInfo,
the GLO MAY reattempt to create the GL using the information
provided in the GLFailInfo response. The GLO may also use
the GLAQueryRequest to determine the algorithms and
distribution methods supported by the GLA (see paragraph
4.9).
4.2 Delete GL From GLA
From time to time, there are instances when a GL is no longer
needed. In this case the GLO must delete the GL. Figure 4 depicts
that protocol interactions to delete a GL.
+-----+ 1 2 +-----+
| GLA | <-------> | GLO |
+-----+ +-----+ +-----+ +-----+
Figure 4 - Delete Group List Figure 4 - Delete Group List
If the GL Owner decides to use the gkaRequest content-type to delete the The process is as follows:
GL, the gkaRequest content-type MUST be submitted to the GMA (1 in
Figure 2) with the gkaAction.deleteGL CHOICE. The format for the
deleteGL CHOICE is as follows:
- glName MUST be included to indicate the name of the GL to be 1 - The GLO is the entity responsible for requesting the deletion
deleted. of the GL. The GLO sends a
SignedData.PKIData.controlSequence.GLDelete request to the GLA
(1 in Figure 4). The GLO MUST include the name of the GL in
glName. The GLO MAY also include the GL identifier
glIdentifier.
- glIdentifier MUST be included to indicate the identifier of the GL b - The GLO MAY optionally apply confidentiality to the request
to be deleted. by encapsulating the SignedData.PKIData in an EnvelopedData
(see paragraph 3.2.1.2).
- glMembers MUST be omitted. c - The GLO MAY also optionally apply another SignedData over
the EnvelopedData (see paragraph 3.2.1.2).
- glOwner MUST be included to indicate the name of the GL Owner. 2 - Upon receipt of the request the GLA verifies the signature on
administered MUST be omitted. The name in this field MUST match one of the inner most SignedData.PKIData. If an additional SignedData
the names in one of the certificates used in content-type used to create and/or EnvelopedData encapsulates the request (see paragraph
the group. 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.
- effectiveDate MUST be omitted. a - If the signature(s) does(do) not verify, the GLA MUST return
a response indicating CMCFailInfo.badMessageCheck.
- distributionDate MUST be omitted. Turner 26
b - If the signature(s) does(do) verify, the GLA MUST make sure
the GL is supported by checking either that the glName is
supported (in the case the glIdentifier is omitted) or that
the combination of glName and glIdentifier matches a glName
and glIdentifier combination stored on the GLA.
The GMA MUST not accept further requests from users (in the case of 1 - If the glIdentifier is omitted and the glName is not
unadministered GLs) to be added or deleted from the GL. The GMA MUST supported by the GLA, the GLA MUST return a response
forward the gkaRequest to the KMA. indicating GLFailInfo.errorCode.invalidGLName.
Upon receipt of the gkaRequest content-type, the KMA verifies the 2 - If the glName and glIdentifier are present and do not
gkaRequest content-type and returns a gkaResponse (3 in Figure 3) match a GL stored on the GLA, the GLA MUST return a
indicating success and the glIdentifier of the deleted GL. errorCode and response indicating
supportedDeliveryMethods MUST be omitted. GLFailInfo.errorCode.invalidGLNameGLIdentifierCombination.
The GMA then forwards the gkaResponse content-type to the GL Owner (4{3} 3 - If the glIdentifier is omitted and the glName is supported
in Figure 3). An additional id-signedData or some other combination of by the GLA or if the glIdentifier/glName combination is
id-signedData and id-envelopedData MAY protect the forwarded conent- supported by the GLA, the GLA MUST ensure a registered GLO
type. signed the GLDelete request by checking if the name
present in the digital signature certificate used to sign
the GLDelete request matches one of the registered GLOs.
3.1.1.5 Add Group Members a - If the names do not match, the GLA MUST return a
response indicating GLFailInfo.errorCode.noGLONameMatch.
GL setup indicates whether the GL is to be managed or unmanaged. In the b - If the names do match but the GL is not deletable for
managed case, the GL Owner is the only entity allowed to request member other reasons, which the GLA does not wish to disclose,
additions to the GL. In the unmanaged case, anyone can request to be the GLA MUST return a response indicating
added to the GL. Figure 4 depicts the protocol interactions for the two GLFailInfo.errorCode.unspecified.
options.
+----------+ 7{6} 2,9{8b} +----------+ 8a c - If all the names do match, the GLA MUST return to all
| GL Owner | <-+ +-------> | Member 1 | <--+ the GLOs a GLSucessInfo indicating the glName, the
+----------+ | | +----------+ | corresponding glIdentifier, and an
1a | | | action.actionCode.deletedGL (2 in Figure 4). The GLA
+-----+ 4{1a},5 6,8b +-----+ <--+ | 2,9{8b} +----------+ 8a | MUST not accept further requests for member additions,
| KMA | <----------> | GMA | 1b,3 +-------> | ... | <--+ member deletions, or group rekeys for this GL.
+-----+ +-----+ <-------------+ +----------+ |
| | |
| | 2,9{8b} +----------+ 8a |
| +-------> | Member n | <--+
| +----------+ |
+-----------------------------------------------------------------+
Figure 4 - Member Addition 1 - The GLA MUST apply confidentiality to the response by
encapsulating the SignedData.PKIResponse in an
EnvelopedData if the request was encapsulated in an
EnvelopedData (see paragraph 3.2.1.2).
A decision that needs to be made on a group by group basis is whether to 2 - The GLA MAY also optionally apply another SignedData
rekey the group every time a new member is added. Typically, unmanaged over the EnvelopedData (see paragraph 3.2.1.2).
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 GLs may be rekeyed depending on group
policy. An option to rekeying the managed GLs when a member is added is
to generate a new GL with a different group key.
3.1.1.5.1 Managed GLs 3 - Upon receipt of the GLSuccessInfo or GLFailInfo response, the
GLO verifies the GLA's signature(s). If an additional
SignedData and/or EnvelopedData encapsulates the response (see
paragraph 3.2.1.2 or 3.2.2), the GLO MUST verify the outer
signature and/or decrypt the outer layer prior to verifying
the signature on the inner most SignedData.
The GL Owner MAY use a proprietary mechanism (e.g., listserv or Turner 27
majordomo) or the group key administration mechanism defined below to a - If the signature(s) does(do) not verify, the GLO MUST return
add new members to the GL. a response indicating CMCFailInfo.badMessageCheck.
If the GL Owner decides to use the gkaRequest content-type MUST be b - If the signatures do verify and the response was
submitted to the GMA (1a in Figure 4) with the gkaAction.addGLMembers GLSuccessInfo, the GLO has successfully deleted the GL.
CHOICE. The format for the addGLMembers CHOICE is as follows:
- glName MUST be included to indicate the name of the GL. c - If the signatures do verify and the response was GLFailInfo,
the GLO MAY reattempt to delete the GL using the information
provided in the GLFailInfo response.
- glIdentifier MUST be included to indicate the GK that should be 4.3 Add Members To GL
distributed to the new member.
- glMembers MUST be included to indicate the member(s) to be added. To add members to GLs, either the GLO or prospective members use the
The member(s) name(s) is included in GLMember.name. The delivery method GLAddMembers request. There are however different scenarios that
MAY be included. The members certificates and crls MAY also be included. should be supported. Either the GLO or prospective members may
submit the GLAddMembers request to the GLA, but the GLA processes
the requests differently. The GLO can submit the request at any time
to add members to the GL, and the GLA, once it has verified the
request came from the GLO should process it. If a prospective member
sends the request, the GLA needs to determine how the GL is
administered. When the GLO initially configured the GL, they set the
GL to be unmanaged, managed, or closed (see paragraph 3.1.1). In the
unmanaged case, the GLA merely processes the member's request. For
the managed case, the GLA forwards the requests from the prospective
members to the GLO. Where there are multiple GLOs for a GL, which
GLO the request is forwarded to is beyond the scope of this
document. In the closed case, the GLA will not accept requests from
prospective members. The following paragraphs describe the
processing required by the GLO, GLA, and prospective GL members
depending on where the request originated, either from the GLO or
from prospective members. Figure 5 depicts the protocol interactions
for the three options. Note that the error messages are not
depicted.
- glOwner.name MUST be included to indicate the Owner of the GL. It +-----+ 2,B{A} 3 +----------+
MUST match the name one of the certificates used to sign this gkaRequest | GLO | <--------+ +-------> | Member 1 |
creating the GL. +-----+ | | +----------+
1 | |
+-----+ <--------+ | 3 +----------+
| GLA | A +-------> | ... |
+-----+ <-------------+ +----------+
|
| 3 +----------+
+-------> | Member n |
+----------+
- effectiveDate MUST be omitted. The value has no meaning as the group Figure 5 - Member Addition
key has been previously setup.
- distributionDate MAY be included to indicate the date the GL Owner An important decision that needs to be made on a group by group
wishes the key to be distributed to the new member(s). If the basis is whether to rekey the group every time a new member is
distributitionDate is omitted the KMA assumes the group key should be
distributed immediately.
Upon receipt of the gkaRequest, the GMA MAY process the glMembers and Turner 28
add the member(s) for the GL stored on the GMA. The GMA then forwards added. Typically, unmanaged GLs should not be rekeyed when a new
the gkaRequest content-type to the KMA (4{1a} in Figure 4). An member is added, as the overhead associated with rekeying the group
additional id-signedData or some other combination of id-signedData and becomes prohibitive, as the group becomes large. However, managed
id-envelopedData MAY protect the forwarded content-type. and closed GLs MUST be rekeyed to maintain the secrecy of the group.
An option to rekeying the managed GLs when a member is added is to
generate a new GL with a different group key. Group rekeying is
discussed in paragraphs 4.5 and 5.
Upon receipt of the gkaRequest content-type, the KMA verifies the 4.3.1 GLO Initiated Additions
gkaRequest content-type and returns a gkaResponse (6 in Figure 4). If
the member can be added, the KMA MUST return a gkaResponse to the GMA
indicating success and the glIdentifier of the GL the member was added
to. If the member can not be added the KMA MUST return a gkaResponse to
the GMA indicating failure along with an errorCode indicating either
unsupportedDeliveryMethod or invalidCert. The supportDeliveryMethods MAY
also be included to assist the GL Owner in determining whether some
other delivery method could be used to distribute the key to the new
member.
The KMA also distributes the group key via the mechanism described in The process for GLO initiated GLAddMembers requests is as follows:
paragraph 3.2. The KMA also distributes the group key via the mechanism
described in paragraph 3.1.3. The group key is either distributed
through the GMA (8b and 9{8b} in Figure 4) or directly to the members
(8a in Figure 4).
The GMA then forwards the gkaResponse content-type to the GL Owner (7{6} 1 - The GLO collects the names and pertinent information for the
in Figure 4). An additional id-signedData or some other combination of members to be added (this MAY be done through an out of bands
id-signedData and id-envelopedData MAY protect the forwarded conent- means). The GLO then sends a
type. SignedData.PKIData.controlSequence.GLAddMembers request to the
GLA (1 in Figure 5). The GLO MUST include: the GL name in
glName, the member's name in glMembers.glMemberName, the
member's encryption certificate in
glMembers.certificates.membersPKC. The GLO MAY also include
the GL identifier in glIdentifier, if known, any attribute
certificates associated with the member's encryption
certificate in glMembers.certificates.membersAC, and the
certification path associated with the member's encryption and
attribute certificates in
glMembers.certificates.certificationPath.
3.1.1.5.2 Unmanaged GLs a - The GLO MAY optionally apply confidentiality to the request
by encapsulating the SignedData.PKIData in an EnvelopedData
(see paragraph 3.2.1.2).
For automated scenarios, members send a message (1b in Figure 4), which b - The GLO MAY also optionally apply another SignedData over
MAY be unprotected (i.e., unsigned and unencrypted) or protected via id- the EnvelopedData (see paragraph 3.2.1.2).
signedData, id-envelopedData, or tripled wrapped (i.e., signed and/or
encrypted) [CMS]. If the message is protected with id-envelopedData the
GMA MUST be one of the recipients. A confirmation message (2 in Figure
4) MAY be sent back to the member requesting confirmation of the initial
request to inhibit spamming (i.e., to avoid someone other than the
member requested the member be added to the list). The response to the
confirmation message (3 in Figure 4) indicates whether the member really
requested addition to the GL. The format for these messages indicated by
1b, 2, and 3 in Figure 4 are beyond the scope of this document.
The GMA MAY support generating a gkaRequest content-type to request 2 - Upon receipt of the request, the GLA verifies the signature on
members be added. If the GMA supports generating the gkaRequest content- the inner most SignedData.PKIData. If an additional SignedData
type, it MUST be submitted to the KMA (5 in Figure 4) with the and/or EnvelopedData encapsulates the request (see paragraph
gkaAction.addGLMembers CHOICE. The format for the addGLMembers CHOICE is 3.2.1.2 or 3.2.2), the GLA MUST verify the outer signature
as follows and/or decrypt the outer layer prior to verifying the
signature on the inner most SignedData.
- glName MUST be included to indicate the name of the GL. a - If the signature(s) does(do) not verify, the GLA MUST return
a response indicating CMCFailInfo.badMessageCheck.
- glIdentifier MUST be included to indicate the GK that should be b - If the signature(s) does(do) verify, the GLAddMembers
distributed to the new member. request is included in a controlSequence with the GLUseKEK
request, and the processing of 2.b.2 is successfully
completed the GLA MUST return to all GLOs a GLSuccessInfo
indicating the glName, the corresponding glIdentifier, an
action.actionCode.addedMember, and action.glMemberName (2 in
- glMembers MUST be included to indicate the member(s) to be added. Turner 29
The member(s) name(s) is included in GLMember.name. The delivery method Figure 5). The response MUST be constructed as specified in
MAY be included. The member's certificates and crls MAY also be paragraph 3.2.3.
included.
- glOwner.name MUST be omitted. 1 - The GLA MUST apply confidentiality to the response by
encapsulating the SignedData.PKIData in an EnvelopedData
if the request was encapsulated in an EnvelopedData (see
paragraph 3.2.1.2).
- effectiveDate MUST be omitted. 2 - The GLA MAY also optionally apply another SignedData over
the EnvelopedData (see paragraph 3.2.1.2).
- distributionDate MUST be omitted. c - If the signature(s) does(do) verify and the GLAddMember
request is not included in a controlSequence with the
GLCreate request, the GLA MUST make sure the GL is supported
by checking either that the glName is supported (in the case
the glIdentifier is omitted) or that the combination of
glName and glIdentifier matches a glName and glIdentifier
stored on the GLA.
Upon receipt of the gkaRequest content-type, the KMA verifies the 1 - If the glIdentifier is omitted and the glName is not
gkaRequest content-type and returns a gkaResponse (6 in Figure 4). If supported by the GLA, the GLA MUST return a response
the member can be added, the KMA MUST return a gkaResponse to the GMA indicating GLFailInfo.errorCode.invalidGLName.
indicating success and the glIdentifier of the GL the member was added
to. If the member can not be added the KMA MUST return a gkaResponse to
the GMA indicating failure along with an errorCode indicating
unspecified, managedGL, unsupportedDeliveryMethod, or invalidCert. The
supportDeliveryMethods MAY also be included to assist the GMA in
determining whether some other delivery method could be used to
distribute the key to the new member.
The KMA also distributes the group key via the mechanism described in 2 - If the glName and glIdentifier are present and do not
paragraph 3.2. The group key is either distributed through the GMA (8b match a GL stored on the GLA, the GLA MUST return a
and 9{8b} in Figure 4) or directly to the members (8a in Figure 4). response indicating
GLFailInfo.errorCode.invalidGLNameGLIdentifierCombination.
3.1.1.6 Delete Group Members 3 - If the glIdentifier is omitted and the glName is supported
by the GLA or if the glIdentifier/glName combination is
present and supported, the GLA MUST check to see if the
glMemberName is present on the GL.
GL setup indicates whether the GL is to be managed or unmanaged. In the a - If the glMemberName is present on the GL, the GLA MUST
managed case, the GL Owner is the only entity allowed to request member return a response indicating
deletions to the GL. In the unmanaged case, anyone can request to be GLFailInfo.errorCode.alreadyAMember.
removed from the GL. Figure 5 depicts the protocol interactions for the
two options.
+----------+ 7{6} b - If the glMemberName is not present on the GL, the GLA
| GL Owner | <-+ the GLA MUST check how the GL is administered.
+----------+ |
1a | 1 - If the GL is closed, the GLA MUST check that GLO
+-----+ 4{1a},5 6,8b +-----+ <--+ +----------+ signed the request by checking that one of the names
| KMA | <----------> | GMA | 1b,3 2 | Member X | in the digital signature certificate used to sign the
+-----+ | | <----------------> +----------+ request matches one of the registered GLOs.
| | | 9{8b},8a
| +-----+ ------+----------> +----------+ a - If the names do not match, the GLA MUST return a
| | | Member 1 | response indicating
| | +----------+ GLFailInfo.errorCode.noGLONameMatch.
+-------------------------------+
| 9{8b},8a +----------+ b - If the names do match, the GLA MUST verify the
+----------> | Member n | member's encryption certificate.
Turner 30
1 - If the member's encryption certificate does not
verify, the GLA MUST return a response indicating
GLFailInfo.errorCode.invalidCert.
2 - If the member's certificate does verify, the GLA
MUST return to all GLOs a GLSuccessInfo indicating
the glName, the corresponding glIdentifier, an
action.actionCode.addedMember, and
action.glMemberName (2 in Figure 5). The response
MUST be constructed as in paragraph 3.2.3. The GLA
also takes administrative actions, which are
beyond the scope of this document, to add the
member with the GL stored on the GLA. The GLA will
also distribute the shared KEK to the member via
the mechanism described in paragraph 5.
a - The GLA MUST apply confidentiality to the
response by encapsulating the SignedData.PKIData
in an EnvelopedData if the request was
encapsulated in an EnvelopedData (see paragraph
3.2.1.2).
b - The GLA MAY also optionally apply another
SignedData over the EnvelopedData (see paragraph
3.2.1.2).
2 - If the GL is managed, the GLA MUST check that either
the GLO or the prospective member signed the request.
For the GLO, one of the names in the certificate used
to sign the request MUST match one of the registered
GLOs. For the prospective member, the name in
glMembers.glMemberName MUST match one of the names in
the certificate used to sign the request.
a _ If the signer is neither a registered GLO or the
prospective GL member, the GLA MUST return a
response indicating GLFailInfo.errorCode.noSpam.
b - If the signer is the GLO, the GLA MUST verify the
member's encryption certificate.
1 - If the member's certificate does not verify, the
GLA MUST return a response indicating
GLFailInfo.errorCode.invalidCert.
2 - If the member's certificate does verify, the GLA
MUST return to all GLOs GLSuccessInfo indicating
the glName, the corresponding glIdentifier, an
action.actionCode.addedMember, and
action.glMemberName to the GLO (2 in Figure 5).
The response MUST be constructed as in paragraph
3.2.3. The GLA also takes administrative actions,
Turner 31
which are beyond the scope of this document, to
add the member with the GL stored on the GLA. The
GLA will also distribute the shared KEK to the
member via the mechanism described in paragraph 5.
a - The GLA MUST apply confidentiality to the
response by encapsulating the SignedData.PKIData
in an EnvelopedData if the request was
encapsulated in an EnvelopedData (see paragraph
3.2.1.2).
b - The GLA MAY also optionally apply another
SignedData over the EnvelopedData (see paragraph
3.2.1.2).
c - If the signer is the prospective member, the GLA
forwards the GLAddMembers request (see paragraph
3.2.3) to the GLO (B{A} in Figure 5). Which GLO the
request is forwarded to is beyond the scope of this
document. Further processing of the forwarded
request by the GLO is addressed in 3 of paragraph
4.3.2.
1 - The GLA MUST apply confidentiality to the
forwarded request by encapsulating the
SignedData.PKIData in an EnvelopedData if the
original request was encapsulated in an
EnvelopedData (see paragraph 3.2.1.2).
2 - The GLA MAY also optionally apply another
SignedData over the EnvelopedData (see paragraph
3.2.1.2).
3 - If the GL is unmanaged, the GLA MUST check that either
the GLO or the prospective member signed the request.
For the GLO, one of the names in the certificate used
to sign the request MUST match one of the registered
GLOs. For the prospective member, the name in
glMembers.glMemberName MUST match one of the names in
the certificate used to sign the request.
a - If the signer is not the GLO or the prospective
member, the GLA MUST return a response indicating
GLFailInfo.errorCdoe.noSpam.
b - If the signer is either the GLO or the prospective
member, the GLA MUST verify the member's encryption
certificate.
1 - If the member's certificate does not verify, the
GLA MUST return a response indicating
GLFailInfo.errorCode.invalidCert.
Turner 32
2 - If the member's certificate does verify, the GLA
MUST return a GLSucessInfo indicating the glName,
the corresponding glIdentifier, an
action.actionCode.addedMember, and
action.glMemberName to the GLO (2 in Figure 5) if
the GLO signed the request and to the GL member (3
in Figure 5) if the GL member signed the request.
The response MUST be constructed as in paragraph
3.2.3. The GLA also takes administrative actions,
which are beyond the scope of this document, to
add the member with the GL stored on the GLA. The
GLA will also distribute the shared KEK to the
member via the mechanism described in paragraph 5.
a - The GLA MUST apply confidentiality to the
forwarded request by encapsulating the
SignedData.PKIData in an EnvelopedData if the
request was encapsulated in an EnvelopedData
(see paragraph 3.2.1.2).
b - The GLA MAY also optionally apply another
SignedData over the EnvelopedData (see paragraph
3.2.1.2).
3 - Upon receipt of the GLSuccessInfo or GLFailInfo response, the
GLO verifies the GLA's signature(s). If an additional
SignedData and/or EnvelopedData encapsulates the response (see
paragraph 3.2.1.2 or 3.2.2), the GLO MUST verify the outer
signature and/or decrypt the outer layer prior to verifying
the signature on the inner most SignedData.
a - If the signature(s) does (do) not verify, the GLO MUST
return a response indicating CMCFailInfo.badMessageCheck.
b - If the signature(s) does(do) verify, the GLO has added the
member to the GL.
c - If the GLO received a GLFailInfo, for any reason, the GLO
MAY reattempt to add the member to the GL using the
information provided in the GLFailInfo response.
4 - Upon receipt of the GLSuccessInfo or GLFailInfo response, the
prospective member verifies the GLA's signature(s). If an
additional SignedData and/or EnvelopedData encapsulates the
response (see paragraph 3.2.1.2 or 3.2.2), the GLO MUST verify
the outer signature and/or decrypt the outer layer prior to
verifying the signature on the inner most SignedData.
a - If the signatures do not verify, the prospective member MUST
return a response indicating CMCFailInfo.badMessageCheck.
Turner 33
b - If the signatures do verify, the prospective member has been
added to the GL.
c - If the prospective member received a GLFailInfo, for any
reason, the prospective member MAY reattempt to add
themselves to the GL using the information provided in the
GLFailInfo response.
4.3.2 Prospective Member Initiated Additions
The process for prospective member initiated GLAddMembers requests
is as follows:
1 - The prospective GL member sends a
SignedData.PKIData.controlSequence.GLAddMembers request to the
GLA (A in Figure 5). The prospective GL member MUST include:
the GL name in glName, the member's name in
glMembers.glMemberName, their encryption certificate in
glMembers.certificates.membersPKC. The prospective GL member
MAY also include the GL identifier in glIdentifier, if known,
any attribute certificates associated with their encryption
certificate in glMembers.certificates.membersAC, and the
certification path associated with their encryption and
attribute certificates in
glMembers.certificates.certificationPath
a - The prospective GL member MAY optionally apply
confidentiality to the request by encapsulating the
SignedData.PKIData in an EnvelopedData (see paragraph
3.2.1.2).
b - The prospective GL member MAY also optionally apply another
SignedData over the EnvelopedData (see paragraph 3.2.1.2).
2 - Upon receipt of the request, the GLA verifies the request as
per 2 in paragraph 4.3.1.
3 - Upon receipt of the forwarded request, the GLO verifies the
prospective GL member's signature on the inner most
SignedData.PKIData and the GLA's signature on the outer layer.
If an EnvelopedData encapsulates the inner most layer (see
paragraph 3.2.1.2 or 3.2.2), the GLO MUST decrypt the outer
layer prior to verifying the signature on the inner most
SignedData.
a - If the signature(s) does(do) not verify, the GLO MUST return
a response indicating CMCFailInfo.badMessageCheck.
b - If the signature(s) does(do) verify, the GLO MUST check to
make sure one of the names in the certificate used to sign
the request matches the name in glMembers.glMemberName.
Turner 34
1 - If the names do not match, the GLO may send a message
back, which is out of scope, to the prospective member,
depending on policy, to indicate that GL members can only
add themselves lists. This stops people from adding
people to GLs without their permission.
2 - If the names do match, the GLO determines whether the
prospective member is allowed to be added. The mechanism
is beyond the scope of this document; however, the GLO
should check to see that the glMembers.glMemberName is not
already on the GL.
a - If the GLO determines the prospective member is not
allowed to join the GL, the GLO MAY return a message,
which is beyond the scope of this document, to indicate
why the prospective member is not allowed to join.
b - If GLO determines the prospective member is allowed to
join the GL, the GLO MUST verify the member's encryption
certificate.
1 - If the member's certificate does not verify, the GLO
MAY return a message, which is out of scope, to the
prospective member indicating that their encryption
certificate is not valid.
2 - If the member's certificate does verify, the GLO
reforms GLAddMembers request (the prospective member's
signature is discarded and the GLO applies their own
signature) to the GLA (1 in Figure 5) by including:
the GL name in glName, the member's name in
glMembers.glMemberName, the member's encryption
certificate in glMembers.certificates.membersPKC. The
GLO MAY also include the GL identifier in
glIdentifier, if known, any attribute certificates
associated with the member's encryption certificate in
glMembers.certificates.membersAC, and the
certification path associated with the member's
encryption and attribute certificates in
glMembers.certificates.certificationPath.
a - The GLO MUST apply confidentiality to the new
GLAddMember request by encapsulating the
SignedData.PKIData in an EnvelopedData if the
initial request was encapsulated in an EnvelopedData
(see paragraph 3.2.1.2).
b - The GLO MAY also optionally apply another SignedData
over the EnvelopedData (see paragraph 3.2.1.2).
4 - Processing continues as in 2 of paragraph 4.3.1.
Turner 35
4.4 Delete Members From GL
To delete members from GLs, either the GLO or prospective non-
members use the GLDeleteMembers request. There are however different
scenarios that should be supported. Either the GLO or prospective
members may submit the GLDeleteMembers request to the GLA, but the
GLA processes the requests differently. The GLO can submit the
request at any time to delete members from the GL, and the GLA, once
it has verified the request came from the GLO should delete the
member. If a prospective member sends the request, the GLA needs to
determine how the GL is administered. When the GLO initially
configured the GL, they set the GL to be unmanaged, managed, or
closed (see paragraph 3.1.1). In the unmanaged case, the GLA merely
processes the member's request. For the managed case, the GLA
forwards the requests from the prospective members to the GLO. Where
there are multiple GLOs for a GL, which GLO the request is forwarded
to is beyond the scope of this document. In the closed case, the GLA
will not accept requests from prospective members. The following
paragraphs describe the processing required by the GLO, GLA, and
prospective non-GL members depending on where the request
originated, either from the GLO or from prospective members. Figure
6 depicts the protocol interactions for the three options. Note that
the error messages are not depicted.
+-----+ 2,B{A} 3 +----------+
| GLO | <--------+ +-------> | Member 1 |
+-----+ | | +----------+
1 | |
+-----+ <--------+ | 3 +----------+
| GLA | A +-------> | ... |
+-----+ <-------------+ +----------+
|
| 3 +----------+
+-------> | Member n |
+----------+ +----------+
Figure 5 - Member Deletion Figure 6 - Member Deletion
If the member is not removed from the GL, they will continue to be able If the member is not removed from the GL, they will continue to be
to receive and decrypt data protected with the group key and will able to receive and decrypt data protected with the shared KEK and
continue to receive group rekeys. Steps should be taken to ensure a new will continue to receive shared KEK rekeys. For unmanaged lists,
group key is used (see paragraph 3.1.3). For unmanaged lists, there is there is no point to a group rekey because there is no guarantee
no point to a group rekey because there is no guarantee that the member that the member requesting to be removed has not already added
requesting to be removed hasn't already added themselves back on the themselves back on the list under a different name. For managed and
list under a different name. For managed GLs, the GL Owner must take closed GLs, the GLO MUST take steps to ensure the member being
steps to ensure the member being deleted is not on the list twice. After deleted is not on the list twice. After ensuring this, the managed
ensuring this, the managed GL MUST be rekeyed to maintain the secrecy of GL MUST be rekeyed to maintain the secrecy of the group. If the GLO
the group. If the GL Owner is sure the member has been deleted the group is sure the member has been deleted the group rekey mechanism MAY be
rekey mechanism MAY be used to distribute the new key (see paragraph used to distribute the new key (see paragraphs 4.5 and 5).
3.1.1.7).
3.1.1.6.1 Managed GLs Turner 36
The GL Owner MAY use a proprietary mechanism (e.g., listserv or 4.4.1 GLO Initiated Deletions
majordomo) or the group key administration mechanism defined below to
delete members from the GL.
If the GL Owner decides to use the gkaRequest content-type MUST be The process for GLO initiated GLDeleteMembers requests is as
submitted to the GMA (1a in Figure 4) with the gkaAction.addGLMembers follows:
CHOICE. The format for the addGLMembers CHOICE is as follows:
- glName MUST be included to indicate the name of the GL. 1 - The GLO collects the names and pertinent information for the
members to be deleted (this MAY be done through an out of
bands means). The GLO then sends a
SignedData.PKIData.controlSequence.GLDeleteMembers request to
the GLA (1 in Figure 6). The GLO MUST include: the GL name in
glName and the member's name in glMembersToDelete. The GLO MAY
omit the glIdentifier if it is unknown. If the GL from which
the member is being deleted in a closed or managed GL, the GLO
MUST also generate a GLRekey request and include it with the
GLDeleteMember request (see paragraph 4.5).
- glIdentifier MUST be included to indicate the GK that should be a - The GLO MAY optionally apply confidentiality to the request
distributed to the new member. by encapsulating the SignedData.PKIData in an EnvelopedData
(see paragraph 3.2.1.2).
- glMembers MUST be included to indicate the member(s) to be deleted. b - The GLO MAY also optionally apply another SignedData over
The member(s) name(s) is included in GLMember.name. The delivery method the EnvelopedData (see paragraph 3.2.1.2).
MUST be omitted. The members certificates and crls MUST also be omitted.
- glOwner.name MUST be included to indicate the Owner of the GL. It 2 - Upon receipt of the request, the GLA verifies the signature on
MUST match the name one of the certificates used to sign this the inner most SignedData.PKIData. If an additional SignedData
gkaRequest. and/or EnvelopedData encapsulates the request (see paragraph
3.2.1.2 or 3.2.2), the GLA MUST verify the outer signature
and/or decrypt the outer layer prior to verifying the
signature on the inner most SignedData.
- effectiveDate MUST be omitted. The value has no meaning as the group a - If the signature(s) does(do) not verify, the GLA MUST return
key has been previously setup. a response indicating CMCFailInfo.badMessageCheck.
- distributionDate MUST be omitted. b - If the signature(s) does(do) verify, the GLA MUST make sure
the GL is supported by the GLA by checking either that the
glName is supported (in the case the glIdentifier is
omitted) or that the combination of glName and glIdentifier
matches a glName and glIdentifier stored on the GLA.
Upon receipt of the gkaRequest, the GMA MAY process the glMembers and 1 - If the glIdentifier is omitted and the glName is not
remove the member for the GL stored on the GMA. The GMA then forwards supported by the GLA, the GLA MUST return a response
the gkaRequest content-type to the KMA (4{1a} in Figure 5). An indicating GLFailInfo.errorCode.invalidGLName.
additional id-signedData or some other combination of id-signedData and
id-envelopedData MAY protect the forwarded content-type.
Upon receipt of the gkaRequest content-type, the KMA verifies the 2 - If the glName and glIdentifier are present and do not
gkaRequest content-type and returns a gkaResponse (6 in Figure 4). The match a GL stored on the GLA, the GLA MUST return a
KMA MUST return a gkaResponse to the GMA indicating success and the response indicating
glIdentifier of the GL the member was deleted from. GLFailInfo.errorCode.invalidGLNameGLIdentifierCombination.
The GMA then forwards the gkaResponse back to the GL Owner (7{6} in 3 - If the glIdentifier is omitted and the glName is supported
Figure 5). An additional id-signedData or some other combination of id- by the GLA or if the glIdentifier/glName combination is
signedData and id-envelopedData MAY protect the forwarded conent-type.
The KMA MUST also use the group key distribution mechanism defined in Turner 37
paragraph 3.1.3 to provide the remaining members with a new group key. supported by the GLA, the GLA MUST check to see if the
glMemberName is present on the GL.
3.1.1.6.2 Unmanaged GLs a - If the glMemberName is not present on the GL, the GLA
MUST return a response indicating
GLFailInfo.errorCode.notAMember.
For automated scenarios, members send a message (1b in Figure 4), which b - If the glMemberName is not already on the GL, the GLA
MAY be unprotected (i.e., unsigned and unencrypted) or protected via id- MUST check how the GL is administered.
signedData, id-envelopedData, or tripled wrapped (i.e., signed and/or
encrypted) [CMS]. If the message is protected with id-envelopedData the
GMA MUST be one of the recipients. A confirmation message (2 in Figure
4) MAY be sent back to the member requesting confirmation of the initial
request to inhibit spamming (i.e., to avoid someone other than the
member requested the member be added to the list). The response to the
confirmation message (3 in Figure 4) indicates whether the member really
requested addition to the GL. The format for these messages indicated by
1b, 2, and 3 in Figure 4 are beyond the scope of this document.
The GMA MAY support generating a gkaRequest content-type to request 1 - If the GL is closed, the GLA MUST check that GLO
members be deleted. If the GMA supports generating the gkaRequest signed the request by checking that one of the names
content-type, it MUST be submitted to the KMA (5 in Figure 5) with the in the digital signature certificate used to sign the
gkaAction.addGLMembers CHOICE. The format for the addGLMembers CHOICE is request matches one of the registered GLOs.
as follows
- glName MUST be included to indicate the name of the GL. a - If the names do not match, the GLA MUST return a
response indicating
GLFailInfo.errorCode.noGLONameMatch.
- glIdentifier MUST be included to indicate the GL the member should b - If the names do match, the GLA MUST return to all
be removed from. GLOs a GLSucessInfo indicating the glName, the
corresponding glIdentifier, an
action.actionCode.deletedMember, and
action.glMemberName (2 in Figure 5). The response
MUST be constructed as in paragraph 3.2.3. The GLA
also takes administrative actions, which are beyond
the scope of this document, to delete the member
with the GL stored on the GLA. The GLA will also
rekey group as described in paragraph 5.
- glMembers MUST be included to indicate the member(s) to be deleted. 1 - The GLA MUST apply confidentiality to the response
The member(s) name(s) is included in GLMember.name. The deliveryMethod by encapsulating the SignedData.PKIData in an
MUST be omitted. The member's certificates and crls MUST also be EnvelopedData if the request was encapsulated in
omitted. an EnvelopedData (see paragraph 3.2.1.2).
- glOwner.name MUST be omitted. 2 - The GLA MAY also optionally apply another
SignedData over the EnvelopedData (see paragraph
3.2.1.2).
- effectiveDate MUST be omitted. 2 - If the GL is managed, the GLA MUST check that either
the GLO or the prospective member signed the request.
For the GLO, one of the names in the certificate used
to sign the request MUST match one of the registered
GLOs. For the prospective member, the name in
glMembers.glMemberName MUST match one of the names in
the certificate used to sign the request.
- distributionDate MUST be omitted. a _ If the signer is neither a registered GLO or the
prospective GL member, the GLA MUST return a
response indicating GLFailInfo.errorCode.noSpam.
Upon receipt of the gkaRequest content-type, the KMA verifies the Turner 38
gkaRequest content-type and returns a gkaResponse (6 in Figure 5). KMA b - If the signer is the GLO, the GLA MUST return to all
MUST return a gkaResponse to the GMA indicating success and the GLOs a GLSucessInfo indicating the glName, the
glIdentifier of the GL the member was deleted from. corresponding glIdentifier, an
action.actionCode.deletedMember, and
action.glMemberName (2 in Figure 6). The response
MUST be constructed as in paragraph 3.2.3. The GLA
also takes administrative actions, which are beyond
the scope of this document, to delete the member
with the GL stored on the GLA. The GLA will also
rekey group as described in paragraph 5.
GL Policy will determine whether the GL is to be rekeyed. 1 - The GLA MUST apply confidentiality to the response
by encapsulating the SignedData.PKIData in an
EnvelopedData if the request was encapsulated in
an EnvelopedData (see paragraph 3.2.1.2).
3.1.1.7 Rekey Group 2 - The GLA MAY also optionally apply another
SignedData over the EnvelopedData (see paragraph
3.2.1.2).
Situations arise where the GL needs a new key (i.e., group rekey). An c - If the signer is the prospective member, the GLA
out of bands means, automatic rekeys by the KMA, or the mechanisms forwards the GLDeleteMembers request (see paragraph
defined below MAY be used to initiate a group rekey. Only the GL Owner 3.2.3) to the GLO (B{A} in Figure 6). Which GLO the
or KMA are allowed to initiate a group rekey. request is forwarded to is beyond the scope of this
document. Further processing of the forwarded
request by the GLO is addressed in 3 of paragraph
4.4.2.
+----------+ 4{3} 6{5b} +----------+ 5a 1 - The GLA MUST apply confidentiality to the
| GL Owner | <---+ +-------> | Member 1 | <--+ forwarded request by encapsulating the
+----------+ | | +----------+ | SignedData.PKIData in an EnvelopedData if the
1 | | | request was encapsulated in an EnvelopedData (see
+-----+ 2{1} 3,5b +-----+ <----+ | 6{5b} +----------+ 5a | paragraph 3.2.1.2).
| KMA | <--------> | GMA | ----------------+-------> | ... | <--+
+-----+ +-----+ | +----------+ |
| | |
| | 6{5b} +----------+ 5a |
| +-------> | Member n | <--+
| +----------+ |
+-----------------------------------------------------------------+
Figure 6 - Group Rekey 2 - The GLA MAY also optionally apply another
SignedData over the EnvelopedData (see paragraph
3.2.1.2).
The GL Owner MAY generate a gkaRequest content-type and submitted it to 3 - If the GL is unmanaged, the GLA MUST check that either
the GMA (1 in Figure 6) with the gkaAction.rekeyGL CHOICE. The format the GLO or the prospective member signed the request.
for the rekeyGL CHOICE is as follows: For the GLO, one of the names in the certificate used
to sign the request MUST match one of the registered
GLOs. For the prospective member, the name in
glMembers.glMemberName MUST match one of the names in
the certificate used to sign the request.
- glName MUST be included to indicate the name of the GL. a - If the signer is not the GLO or the prospective
member, the GLA MUST return a response indicating
GLFailInfo.errorCode.noSpam.
- glIdentifier MUST be included to indicate the GK that should be b - If the signer is either the GLO or the member, the
rekeyed. GLA MUST return a GLSucessInfo indicating the
- glMembers MUST be omitted. Turner 39
glName, the corresponding glIdentifier, an
action.actionCode.deletedMember, and
action.glMemberName to the GLO (2 in Figure 6) if
the GLO signed the request and to the GL member (3
in Figure 6) if the GL member signed the request.
The response MUST be constructed as in paragraph
3.2.3. The GLA also takes administrative actions,
which are beyond the scope of this document, to
delete the member with the GL stored on the GLA.
- glOwner.name MUST be included to indicate the Owner of the GL. It 1 - The GLA MUST apply confidentiality to the response
MUST match the name one of the certificates used to sign this gkaRequest by encapsulating the SignedData.PKIData in an
and match one of the names in the certificates used to sign the EnvelopedData if the request was encapsulated in an
gkaRequest that created the GL. EnvelopedData (see paragraph 3.2.1.2).
- effectiveDate MAY be included to indicate the dates the GL Owner 2 - The GLA MAY also optionally apply another
wishes the new group key to become effective. If this field is omitted SignedData over the EnvelopedData (see paragraph
the GMA assumes the gkNotBefore date (see paragraph 3.1.2) is the GMA's 3.2.1.2).
current date.
- distributionDate MAY be included to indicate the date the GL Owner 3 - Upon receipt of the GLSuccessInfo or GLFailInfo response, the
wishes the key to be distributed. If the distributitionDate is omitted GLO verifies the GLA's signatures. If an additional SignedData
the GMA assumes the group key should be distributed immediately. This and/or EnvelopedData encapsulates the response (see paragraph
date MAY overlap with the existing effectiveDate to ensure 3.2.1.2 or 3.2.2), the GLO MUST verify the outer signature
prepositioning the new group key before the old group key becomes and/or decrypt the outer layer prior to verifying the
invalid. signature on the inner most SignedData.
The GMA then forwards the gkaRequest content-type to the KMA (2{1} in a - If the signature(s) does(do) not verify, the GLO MUST return
Figure 3). An additional id-signedData or some other combination of id- a response indicating CMCFailInfo.badMessageCheck.
signedData and id-envelopedData MAY protect the forwarded content-type.
Upon receipt of the gkaRequest content-type, the KMA verifies the b - If the signature(s) does(do) verify, the GLO has deleted the
gkaRequest content-type and returns a gkaResponse (3 in Figure 3). If member from the GL.
the GL can be rekeyed as requested, the KMA MUST return a gkaResponse to
the GMA indicating success and the glIdentifier of the new group key. If
the group key can not be rekeyed as requested the KMA returns a
gkaResponse to the GMA indicating failure along with an errorCode.
The GMA then forwards the gkaResponse content-type to the GL Owner (4{3} c - If the GLO received a GLFailInfo, for any reason, the GLO
in Figure 3). An additional id-signedData or some other combination of may reattempt to delete the member from the GL using the
id-signedData and id-envelopedData MAY protect the forwarded conent- information provided in the GLFailInfo response.
type.
The KMA also generates the group rekey MUST distribute the new group 4 - Upon receipt of the GLSuccessInfo or GLFailInfo response, the
through the mechanism described in paragraph 3.3. prospective member verifies the GLA's signature(s). If an
additional SignedData and/or EnvelopedData encapsulates the
response (see paragraph 3.2.1.2 or 3.2.2), the GLO MUST verify
the outer signature and/or decrypt the outer layer prior to
verifying the signature on the inner most SignedData.
3.2 Group Key Distribution a - If the signature(s) does(do) not verify, the prospective
member MUST return a response indicating
CMCFailInfo.badMessageCheck.
The KMA MUST support the initial distribution of the group key. It MAY b - If the signature(s) does(do) verify, the prospective member
perform this distribution via an out of bands means, a repository, a has been deleted from the GL.
mail message, or some other means. The gkDistribution content-type is
defined to support electronic means of distributing the group key. If
the gkDistribution method is used, it MUST be protected in id-
envelopedData [CMS]. The gkDistribution content-type MUST be protected
on a per-recipient basis using the ktri RecipientInfo CHOICE. The kari
RecipientInfo choice MAY be used to protect the message for members. A
further id-signedData MAY also be applied. The KMA MAY send the
gkDistribution content-type either:
- Directly to each of the members (5a in Figure 6). c - If the prospective member received a GLFailInfo, for any
reason, the prospective member MAY reattempt to delete
Note: The following option requires that the KMA be allowed to submit to Turner 40
themselves from the GL using the information provided in the
GLFailInfo response.
4.4.2 Member Initiated Deletions
The process for prospective non-member initiated GLDeleteMembers
requests is as follows:
1 - The prospective non-GL member sends a
SignedData.PKIData.controlSequence.GLDeleteMembers request to
the GLA (A in Figure 5). The prospective non-GL member MUST
include: the GL name in glName and their name in
glMembersToDelete. The prospective non-GL member MAY omit the
glIdentifier if it is unknown.
a - The prospective non-GL member MAY optionally apply
confidentiality to the request by encapsulating the
SignedData.PKIData in an EnvelopedData (see paragraph
3.2.1.2).
b - The prospective non-GL member MAY also optionally apply
another SignedData over the EnvelopedData (see paragraph
3.2.1.2).
2 - Upon receipt of the request, the GLA verifies the request as
per 2 in paragraph 4.4.1.
3 - Upon receipt of the forwarded request, the GLO verifies the
prospective GL member's signature on the inner most
SignedData.PKIData and the GLA's signature on the outer layer.
If an EnvelopedData encapsulates the inner most layer (see
paragraph 3.2.1.2 or 3.2.2), the GLO MUST decrypt the outer
layer prior to verifying the signature on the inner most
SignedData.
a - If the signature(s) does(do) not verify, the GLO MUST return
a response indicating CMCFailInfo.badMessageCheck.
b - If the signature(s) does(do) verify, the GLO MUST check to
make sure the name in one of the certificates used to sign
the request is the entity indicated in glMembersToDelete.
1 - If the names do not match, the GLO may send a message
back, which is out of scope, to the prospective member,
depending on policy, to indicate that GL members can only
add themselves lists. This stops people from adding
people to GLs without their permission.
2 - If the names do match, the GLO deletes the member from the
GL by sending the reformed GLDeleteMembers request (the
prospective non-GL member's signature is stripped off and
Turner 41
the GLO signs it) to the GLA (1 in Figure 6). The GLO MUST
make sure the glMemberName is already on the list and only
on the list once. The GLO MUST also generate a GLRekey
request and include it with the GLDeleteMember request
(see paragraph 4.5).
a - The GLO MUST apply confidentiality to the new
GLDeleteMember request by encapsulating the
SignedData.PKIData in an EnvelopedData if the initial
request was encapsulated in an EnvelopedData (see
paragraph 3.2.1.2).
b - The GLO MAY also optionally apply another SignedData
over the EnvelopedData (see paragraph 3.2.1.2).
4 - Further processing is as in 2 of paragraph 4.4.1.
4.5 Request Rekey Of GL
From time to time the GL will need to be rekeyed. Some situations
are as follows:
- When a member is removed from a closed or managed GL. In this
case, the PKIData.controlSequence containing the GLDeleteMembers
should contain a GLRekey request.
- Depending on policy, when a member is removed from an unmanaged
GL. If the policy is to rekey the GL, the
PKIData.controlSequence containing the GLDeleteMembers could
also contain a GLRekey request or an out of bands means could be
used to tell the GLA to rekey the GL. Rekeying of unmanaged GLs
when members are deleted is not advised.
- When the current shared KEK has been compromised. The GLA will
automatically perform an rekey without waiting for approval from
the GLO.
- When the current shared KEK is about to expire.
- If the GLO controls the GL rekey, the GLA should not assume
that a new shared KEK should be distributed, but instead wait
for the GLRekey message.
- If the GLA controls the GL rekey, the GLA should initiate a
GLKey message as specified in paragraph 5.
If the generationCounter (see paragraph 3.1.1) is set to a value
greater than one (1) and the GLO controls the GL rekey, the GLO may
generate a GLRekey any time before the last shared KEK has expired.
To be on the safe side, the GLO should request a rekey 1 duration
before the last shared KEK expires.
Turner 42
The GLA and GLO are the only entities allowed to initiate a GL
rekey. The GLO indicated whether they are going control rekeys or
whether the GLA is going to control rekeys when the assigned the
shared KEK to GL (see paragraph 3.1.1). The GLO MAY initiate a GL
rekey at any time. The GLA MAY be configured to automatically rekey
the GL prior to the expiration of the shared KEK (the length of time
before the expiration is an implementation decision). Figure 7
depicts the protocol interactions to request a GL rekey. Note that
error messages are not depicted.
+-----+ 1 2,A +-----+
| GLA | <-------> | GLO |
+-----+ +-----+
Figure 7 - GL Rekey Request
4.5.1 GLO Initiated Rekey Requests
The process for GLO initiated GLRekey requests is as follows:
1 - The GLO sends a SignedData.PKIData.controlSequence.GLRekey
request to the GLA (1 in Figure 7). The GLO MUST include the
glName and the glIdentifier. The GLO MAY include change the
glOwner, glAdministration, glDistributionMethod, and
glKeyAttributes. If glOwner, glAdministration,
glDistributionMethod, and glKeyAttributes are omitted then
there is no change from the previously registered GL values
for these fields. If the GLO wants to force a rekey for all
outstanding shared KEKs the glKeyAttributes.generationCounter
MUST be set to zero (0)
a - The GLO MAY optionally apply confidentiality to the request
by encapsulating the SignedData.PKIData in an EnvelopedData
(see paragraph 3.2.1.2).
b - The GLO MAY also optionally apply another SignedData over
the EnvelopedData (see paragraph 3.2.1.2).
2 - Upon receipt of the request, the GLA verifies the signature on
the inner most SignedData.PKIData. If an additional SignedData
and/or EnvelopedData encapsulates the request (see paragraph
3.2.1.2 or 3.2.2), the GLA MUST verify the outer signature
and/or decrypt the outer layer prior to verifying the
signature on the inner most SignedData.
a - If the signature(s) does(do) not verify, the GLA MUST return
a response indicating CMCFailInfo.badMessageCheck.
b - If the signature(s) does(do) verify, the GLA MUST make sure
the GL is supported by the GLA by checking that that the
Turner 43
combination of glName and glIdentifier matches a glName and
glIdentifier combination stored on the GLA.
1 - If the glName and glIdentifier present do not match a GL
stored on the GLA, the GLA MUST return a response
indicating
GLFailInfo.errorCode.invalidGLNameGLIdentifierCombination.
2 - If the glName and glIdentifier present do match a GL
stored on the GLA, the GLA MUST check that a registered
GLO signed the request by checking that one of the names
in the certificate used to sign the request is a
registered GLO.
a - If the names do not match, the GLA MUST return a
response indicating GLFailInfo.errorCode.noGLONameMatch.
b - If all the names do match, the GLA MUST return to all
GLOs a GLSucessInfo indicating the glName, the new
glIdentifier, and an action.actionCode.rekeyedGL (2 in
Figure 7). The GLA also uses the GLKey message to
distribute the rekey shared KEK (see paragraph 5).
1 - The GLA MUST apply confidentiality to response by
encapsulating the SignedData.PKIData in an
EnvelopedData if the request was encapsulated in an
EnvelopedData (see paragraph 3.2.1.2).
2 - The GLA MAY also optionally apply another SignedData
over the EnvelopedData (see paragraph 3.2.1.2).
3 - Upon receipt of the GLSuccessInfo or GLFailInfo response, the
GLO verifies the GLA's signature(s). If an additional
SignedData and/or EnvelopedData encapsulates the forwarded
response (see paragraph 3.2.1.2 or 3.2.2), the GLO MUST verify
the outer signature and/or decrypt the forwarded response
prior to verifying the signature on the inner most SignedData.
a - If the signature(s) does(do) not verify, the GLO MUST return
a response indicating CMCFailInfo.badMessageCheck.
b - If the signatures verifies, the GLO has successfully rekeyed
the GL. the GL.
- Through the GMA (6b an 6{5b} in Figure 6). If this option is used, c - If the GLO received a GLFailInfo, for any reason, the GLO
the KMA MAY apply an additional id-envelopedData and other layers (6 in may reattempt to rekey the GL using the information provided
Figure 2) to protect the enveloped gkDistribution content-type for the in the GLFailInfo response.
GMA. The GMA then distributes the inner most id-envelopedData to the
list based. The GMA MAY also apply a signature to the distributed id-
envelopedData.
The following object identifier identifies the gksDistribution content Turner 44
type:
id-ct-gkDistribution OBJECT IDENTIFIER ::= { TBD } 4.5.2 GLA Initiated Rekey Requests
The gkDistribution content type MUST have ASN.1 type GKDistribution: If the GLA is in charge of rekeying the GL or if a GLKCompromise
message has been properly processed (see paragraph 4.7) the GLA will
automatically issue a GLKey message (see paragraph 5). In addition
the GLA will generate a GLSuccessInfo to indicate to the GL that a
successful rekey has occurred. The process for GLA initiated rekey
is as follows:
GKDistribution :: = SEQUENCE { 1 _ The GLA MUST generate for all GLOs a
version GKDistributionVersion, SignedData.PKIData.controlSequence.GLSucessInfo indicating the
glIdentifier OCTET STRING, glName, the new glIdentifier, and actionCode.rekeyedGL (A in
gk OCTET STRING, Figure 7).
gkNotBefore GeneralizedTime,
gkNotAfter GeneralizedTime }
[ST - I think we need to put in some kind of information about the a - The GLA MAY optionally apply confidentiality to the request
algorithm the key must be used for.] by encapsulating the SignedData.PKIData in an EnvelopedData
(see paragraph 3.2.1.2).
GKDistributionVersion ::= INTEGER { v0(0) } b - The GLA MAY also optionally apply another SignedData over
the EnvelopedData (see paragraph 3.2.1.2).
The fields in GKSDistribution have the following meaning: 2 - Upon receipt of the GLSuccessInfo response, the GLO verifies
the GLA's signature(s). If an additional SignedData and/or
EnvelopedData encapsulates the forwarded response (see
paragraph 3.2.1.2 or 3.2.2), the GLO MUST verify the outer
signature and/or decrypt the outer layer prior to verifying
the signature on the inner most SignedData.
- version is the syntax version number. It MUST be 0. a - If the signatures do not verify, the GLO MUST return a
response indicating CMCFailInfo.badMessageCheck.
- glIdentifier is the GL identifier. The GL identifier identifies the b - If the signatures verifies, the GLO knows the GLA has
specific GL on the GMA (the GMA may support multiple GLs). Members use successfully rekeyed the GL.
the glIdentifier to choose the key to needed to decrypt an envelopedData
with the RecipientInfo.kekri.kekid.keyIdentifer. Two common methods for
generating key identifiers from the group key are:
(1) The keyIdentifier is composed of the 160-bit SHA-1 hash of the 4.6 Change GLO
value of the BIT STRING gk (excluding the tag,
length, and number of unused bits).
(2) The keyIdentifier is composed of a four bit type field with Management of managed and closed GLs can become difficult for one
the value 0100 followed by the least significant 60 bits of the GLO if the GL membership grows large. To support distributing the
SHA-1 hash of the value of the BIT STRING gk. workload, GLAs support having GL be managed by multiple GLOs. The
GLAddOwners and GLRemoveOwners messages are designed to support
adding and removing registered GLOs. Figure depicts the protocol
interactions to send GLAddOwners and GLRemoveOwners messages and the
resulting response messages.
- gk is the group key. +-----+ 1 2 +-----+
| GLA | <-------> | GLO |
+-----+ +-----+
- gkNotBefore indicates the date at which the key is considered valid. Figure 8 _ GLO Add & Delete Owners
- gkNotAfter indicates the date at which the key is considered Turner 45
invalid. The process for GLAddOwners and GLDeleteOwners is as follows:
Members must support processing the id-envelopedData according to [CMS]. 1 - The GLO sends a SignedData.PKIData.controlSequence.GLAddOwners
or GLRemoveOwners request to the GLA (1 in Figure 8). The GLO
MUST include: the GL name in glName, the GLO(s) in glOwner.
The GLO MAY also include the glIdentifier.
3.3 Group Rekey Distribution a - The GLO MAY optionally apply confidentiality to the request
by encapsulating the SignedData.PKIData in an EnvelopedData
(see paragraph 3.2.1.2).
To support group rekey messages, three mechanisms are defined: b - The GLO MAY also optionally apply another SignedData over
the EnvelopedData (see paragraph 3.2.1.2).
- Use the mechanism described in paragraph 3.1.3 (1a(5a in Figure 5)6) 2 _ Upon receipt of the GLAddOwners or GLRemoveOwners request, the
to redistribute the key (i.e., generate a per-recipient token using the GLA verifies the GLO's signature(s). If an additional
ktri or kari RecipientInfoin the id-envelopedData encapsulating the SignedData and/or EnvelopedData encapsulates the request (see
gkDistribution content-type). This may entail significant processing paragraph 3.2.1.2 or 3.2.2), the GLA MUST verify the outer
compared with the other options below. signature and/or decrypt the outer layer prior to verifying
the signature on the inner most SignedData.
Note: The following two options require that the KMA be allowed to a - If the signature(s) does(do) not verify, the GLA MUST return
submit the GMA. a response indicating CMCFailInfo.badMessageCheck.
- Generate id-encryptedData with the ktri orRecipientInfo choice kari b - If the signature(s) does(do) verify, the GLA MUST make sure
RecipientInfo choicewith the associated GMA(s) as the recipient(s) the GL is supported by checking either that the glName is
(1b(5b in Figure 5)6) encapsulating a id-signedData (signed by the KMA) supported (in the case the glIdentifier is omitted) or that
which in turn encapsualtes an id-envelopedData with the kekri the combination of glName and glIdentifier matches a glName
RecipientInfo choice (includes the gkDistribution content-type). The GMA and glIdentifier combination stored on the GLA.
then strips off the two outer layers andthen sends the inner most id-
envelopedData to the GL members. The GMA identifies the GL to which the
gkDistribution content-type should be submitted to
bytheKEKIdentifier.keyIdentifier. The GMA(s) MAY apply a new
encapsulating id-signedData. id-signedData. The KMA MAY use the kari
RecipientInfo choice to encapsulate the id-signedData (signed by the
KMA) which in turn encapsulates an id-envelopedData with the kekru
RecipientInfo choice (includes the gkDistribution content-type).
- Generate an id-envelopedData (includes the gkDistribution content- 1 - If the glIdentifier is omitted and the glName is not
type) with the kekri RecipientInfo choice for the GL and submit it to supported by the GLA, the GLA MUST return a response
the GMA. The id-envelopedData MAY have other layers (e.g., an id- indicating GLFailInfo.errorCode.invalidGLName.
signedData) applied to it. The GMA identifies the GL to which the
gkDistributionthen distributes this content-type should be submitted to
by the KEKIdentifier.keyIdentifier.id-envelopedData to the GL. The GMA
MAY apply additional layers (e.g., an id-signedData) to the id-
envelopedData.
In all cases, the KMA MUST assign a new glIdentifier, use a new group 2 - If the glName and glIdentifier are present and do not
key in gk, and a new gkNotBefore and gkNotAfter dates. The old match a GL stored on the GLA, the GLA MUST return a
gkNotAfter and new gkNotBefore MUST overlap by some configurable time, response indicating
T. T allows for the time required to distribute the new group key to GLFailInfo.errorCode.invalidGLNameGLIdentifierCombination.
each of the GL members. If T is less than 0, then GL members may be
unable to use the group key to encrypt messages.
[The above case is only for entirely new keys to be distributed. Need to 3 - If the glIdentifier is omitted and the glName is supported
add something in here about how to indicate that a new key, which is by the GLA or if the glIdentifier/glName combination is
derived from the old key, should be used.] supported by the GLA, the GLA MUST ensure a registered GLO
signed the GLAddOwners or GLRemoveOwners request by
checking if the name present in the digital signature
certificate used to sign the GLDelete request matches one
of the registered GLOs.
4 Key Wrapping a - If the names do not match, the GLA MUST return a
response indicating GLFailInfo.errorCode.noGLONameMatch.
In the mechanisms described in paragraphs 3.2 and 3.3, the group key b - If the names do match, the GLA MUST return to all GLOs a
being distributed, in an id-envelopedData, MUST be protected by a key of GLSucessInfo indicating the glName, the corresponding
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).
5 Algorithms Turner 46
glIdentifier, an action.actionCode.addedGLO or
removedGLO, and the respective GLO name in glOwnerName
(2 in Figure 4). The GLA MUST also take administrative
actions to associate the new glOwner name with the GL in
the case of GLAddOwners or to disassociate the old
glOwner name with the GL in the cased of GLRemoveOwners.
1 - The GLA MUST apply confidentiality to the response by
encapsulating the SignedData.PKIResponse in an
EnvelopedData if the request was encapsulated in an
EnvelopedData (see paragraph 3.2.1.2).
2 - The GLA MAY also optionally apply another SignedData
over the EnvelopedData (see paragraph 3.2.1.2).
a - The GLO MAY optionally apply confidentiality to the request
by encapsulating the SignedData.PKIData in an EnvelopedData
(see paragraph 3.2.1.2).
b - The GLO MAY also optionally apply another SignedData over
the EnvelopedData (see paragraph 3.2.1.2).
3 - Upon receipt of the GLSuccessInfo or GLFailInfo response, the
GLO verifies the GLA's signature(s). If an additional SignedData
and/or EnvelopedData encapsulates the response (see paragraph
3.2.1.2 or 3.2.2), the GLO MUST verify the outer signature
and/or decrypt the outer layer prior to verifying the signature
on the inner most SignedData.
a - If the signature(s) does(do) not verify, the GLO MUST return a
response indicating CMCFailInfo.badMessageCheck.
b - If the signatures do verify and the response was
GLSuccessInfo, the GLO has successfully added or removed the
GLO.
c - If the signatures do verify and the response was GLFailInfo,
the GLO MAY reattempt to add or delete the GLO using the
information provided in the GLFailInfo response.
4.7 Indicate KEK Compromise
The will be times when the shared KEK is compromised. The GL members
use the GLKCompromise message to tell the GLA that the shared KEK
has been compromised. Figure 9 depicts the protocol interactions for
GL Key Compromise.
Turner 47
+-----+ 2 3 +----------+
| GLO | <--------+ +-------> | Member 1 |
+-----+ | | +----------+
+-----+ ---------+ | 3 +----------+
| GLA | 1 +-------> | ... |
+-----+ <-------------+ +----------+
| 3 +----------+
+-------> | Member n |
+----------+
Figure 9 - GL Key Compromise
The process for GLKCompromise is as follows:
1 - The GL member sends a
SignedData.PKIData.controlSequence.GLKCompromise request to
the GLA (1 in Figure 9). The GL member MUST include glName and
MAY include glIdentifier.
a - The GL member MAY optionally apply confidentiality to the
request by encapsulating the SignedData.PKIData in an
EnvelopedData (see paragraph 3.2.1.2).
b - The GL member MAY also optionally apply another SignedData
over the EnvelopedData (see paragraph 3.2.1.2).
2 _ Upon receipt of the GLKCompromise requst, the GLA verifies the
GL member's signature(s). If an additional SignedData and/or
EnvelopedData encapsulates the request (see paragraph 3.2.1.2
or 3.2.2), the GLA MUST verify the outer signature and/or
decrypt the outer layer prior to verifying the signature on
the inner most SignedData.
a - If the signature(s) does(do) not verify, the GLA MUST return
a response indicating CMCFailInfo.badMessageCheck.
b - If the signature(s) does(do) verify, the GLA MUST make sure
the GL is supported by checking either that the glName is
supported (in the case the glIdentifier is omitted) or that
the combination of glName and glIdentifier matches a glName
and glIdentifier combination stored on the GLA.
1 - If the glIdentifier is omitted and the glName is not
supported by the GLA, the GLA MUST return a response
indicating GLFailInfo.errorCode.invalidGLName.
2 - If the glName and glIdentifier are present and do not
match a GL stored on the GLA, the GLA MUST return a
response indicating
GLFailInfo.errorCode.invalidGLNameGLIdentifierCombination.
Turner 48
3 - If the glIdentifier is omitted and the glName is supported
by the GLA or if the glIdentifier/glName combination is
supported by the GLA, the GLA MUST ensure the GL member is
on the GL.
a - If one of the names in the certificate used to sign the
GLKCompromise is not present on the GL, the GLA MUST
return a response indicating
GLFailInfo.errorCode.noSpam.
b - If one of the names in the certificate used to sign the
GLKCompromise is present on the GL, the GLA MUST:
1 _ Generate a PKIData.cmsSequence for all GLOs (2 in
Figure 9) containing the original GLKCompromise
message and a PKIResponse.GLSuccessInfo indicating the
glName, new glIdentifier, and an action.actionCode of
rekeyedGL.
2 _ Generate a GLKey message as described in paragraph
5.1.2 to rekey the GL (3 in Figure 9)
4.8 Request KEK Refresh
The will be times when the GL members have misplaced their shared
KEK. In this the shared KEK is not compromised and a rekey of the
entire GL is not necessary. The GL members use the GLKRefresh
message to request that the shared KEK(s) be redistributed to them.
Figure 10 depicts the protocol interactions for GL Key Refresh.
2 +----------+
+-------> | Member 1 |
| +----------+
+-----+ 1 | 2 +----------+
| GLA | <---+-------> | ... |
+-----+ | +----------+
| 2 +----------+
+-------> | Member n |
+----------+
Figure 10 - GL KEK Refresh
The process for GLKRefresh is as follows:
1 - The GL member sends a
SignedData.PKIData.controlSequence.GLKRefresh request to the
GLA (1 in Figure 10). The GL member MUST include glName and
MAY include glIdentifier.
Turner 49
a - The GL member MAY optionally apply confidentiality to the
request by encapsulating the SignedData.PKIData in an
EnvelopedData (see paragraph 3.2.1.2).
b - The GL member MAY also optionally apply another SignedData
over the EnvelopedData (see paragraph 3.2.1.2).
2 _ Upon receipt of the GLKRefresh request, the GLA verifies the
GL member's signature(s). If an additional SignedData and/or
EnvelopedData encapsulates the request (see paragraph 3.2.1.2
or 3.2.2), the GLA MUST verify the outer signature and/or
decrypt the outer layer prior to verifying the signature on
the inner most SignedData.
a - If the signature(s) does(do) not verify, the GLA MUST return
a response indicating CMCFailInfo.badMessageCheck.
b - If the signature(s) does(do) verify, the GLA MUST make sure
the GL is supported by checking either that the glName is
supported (in the case the glIdentifier is omitted) or that
the combination of glName and glIdentifier matches a glName
and glIdentifier combination stored on the GLA.
1 - If the glIdentifier is omitted and the glName is not
supported by the GLA, the GLA MUST return a response
indicating GLFailInfo.errorCode.invalidGLName.
2 - If the glName and glIdentifier are present and do not
match a GL stored on the GLA, the GLA MUST return a
response indicating
GLFailInfo.errorCode.invalidGLNameGLIdentifierCombination.
3 - If the glIdentifier is omitted and the glName is supported
by the GLA or if the glIdentifier/glName combination is
supported by the GLA, the GLA MUST ensure the GL member is
on the GL.
a - If the glMemberName is not present on the GL, the GLA
MUST return a response indicating
GLFailInfo.errorCode.noSpam.
b - If the glMemberName is present on the GL, the GLA MUST
return a GLKey message (2 in Figure 10) as described in
paragraph 5.1.3.
4.9 GLA Query Request and Response
There will be certain times when a GLO is having trouble setting up
a GLO because they do not know the algorithm(s) or distribution
method(s) the GLA supports. The GLAQueryRequest and GLAQueryResponse
message have been defined to support the GLO determining this
Turner 50
information. Figure 11 depicts the protocol interactions for
GLAQueryRequest and GLAQueryResponse.
+-----+ 1 2 +-----+
| GLA | <-------> | GLO |
+-----+ +-----+
Figure 11 - GLA Query Request & Response
The process for GLAQueryRequest and GLAQueryResponse is as follows:
1 - The GLO sends a
SignedData.PKIData.controlSequence.GLAQueryRequest request to
the GLA (1 in Figure 11). The GLO indicates whether they are
interested in determining what algorithms the GLA supports or
what distributionMethods the GLA support or both.
a - The GLO MAY optionally apply confidentiality to the request
by encapsulating the SignedData.PKIData in an EnvelopedData
(see paragraph 3.2.1.2).
b - The GLO MAY also optionally apply another SignedData over
the EnvelopedData (see paragraph 3.2.1.2).
2 _ Upon receipt of the GLQueryRequest, the GLA determines if it
accepts GLAQueryRequests.
a - If the GLA does not accept GLAQueryRequests, the GLA MUST
return a response indicating GLFailInfo.unspecified.
b - If the GLA does accept GLAQueryReuests, the GLA MUST verify
the GLO's signature(s). If an additional SignedData and/or
EnvelopedData encapsulates the request (see paragraph
3.2.1.2 or 3.2.2), the GLA MUST verify the outer signature
and/or decrypt the outer layer prior to verifying the
signature on the inner most SignedData.
1 - If the signature(s) does(do) not verify, the GLA MUST
return a response indicating CMCFailInfo.badMessageCheck.
2 - If the signature(s) does(do) verify, the GLA MUST return a
GLAQueryResponse (2 in Figure 11) indicating the
supportedAlgorithms, the distributionMethod, or both.
a - The GLA MUST apply confidentiality to the response by
encapsulating the SignedData.PKIResponse in an
EnvelopedData if the request was encapsulated in an
EnvelopedData (see paragraph 3.2.1.2).
b - The GLA MAY also optionally apply another SignedData
over the EnvelopedData (see paragraph 3.2.1.2).
Turner 51
3 - Upon receipt of the GLAQueryResponse, the GLO verifies the
GLA's signature(s). If an additional SignedData and/or
EnvelopedData encapsulates the response (see paragraph 3.2.1.2
or 3.2.2), the GLO MUST verify the outer signature and/or
decrypt the outer layer prior to verifying the signature on
the inner most SignedData.
a - If the signature(s) does(do) not verify, the GLO MUST return
a response indicating CMCFailInfo.badMessageCheck.
b - If the signatures do verify and the response was
GLAQueryResponse, the GLO may use the information contained
therein to attempt to setup a GL or modify an existing GL.
5 Distribution Message
The GLA uses the GLKey message to distribute new, shared KEK(s)
after receiving GLAddMembers, GLDeleteMembers (for closed and
managed GLs), GLRekey, GLKCompromise, or GLKRefresh requests and
returning a GLSucessInfo response for the respective request. Figure
12 depicts the protocol interactions to send out GLKey messages. The
procedures defined in this paragraph MUST be implemented.
1 +----------+
+-------> | Member 1 |
| +----------+
+-----+ | 1 +----------+
| GLA | ----+-------> | ... |
+-----+ | +----------+
| 1 +----------+
+-------> | Member n |
+----------+
Figure 12 - GL Key Distribution
If the GL was setup with GLKeyAttributes.recipientsMutuallyAware set
to FALSE, a separate GLKey message MUST be sent to each GL member so
as to not divulge information about the other GL members.
When the GLKey message is generated as a result of a:
- GLAddMembers request,
- GLKComrpomise indicate,
- GLKRefresh request,
- GLDeleteMembers request with the the GL's glAdministration set
to managed or closed,
- GLKRekey request with generationCounter set to zero (0)
The GLA MUST use either the kari (see paragraph 12.3.2 of CMS [2])
or ktri (see paragraph 12.3.1 of CMS [2]) choice in
GLKey.glkWrapped.RecipientInfo to ensure only the intended
Turner 52
recipients receive the shared KEK. The GLA MUST support the
RecipientInfo.kari choice.
When the GLKey message is generated as a result of a GLRekey request
with generationCounter greater than zero (0) or when the GLA
controls rekeys, the GLA MAY use the kari, ktri, or kekri (see
paragraph 12.3.3 of CMS [2]) in GLKey.glkWrapped.RecipientInfo to
ensure only the intended recipients receive the shared KEK. The GLA
MUST support the RecipientInfo.kari choice.
5.1 Distribution Process
When a GLKey message is generated the process is as follows:
1 _ The GLA MUST send a SignedData.PKIData.controlSequence.GLKey
to each member by including: glName, glIdentifier, glkWrapped,
glkAlgorithm, glkNotBefore, and glkNotAfter.
**Need to be more detailed on how the values are derived as it
depends on why and when the GLKey message is generated**
a - The GLA MAY optionally apply another confidentiality layer
to the message by encapsulating the SignedData.PKIData in
another EnvelopedData (see paragraph 3.2.1.2).
b - The GLA MAY also optionally apply another SignedData over
the EnvelopedData.SignedData.PKIData (see paragraph
3.2.1.2).
2 - Upon receipt of the message, the GL members MUST verify the
signature over the inner most SignedData.PKIData. If an
additional SignedData and/or EnvelopedData encapsulates the
message (see paragraph 3.2.1.2 or 3.2.2), the GL Member MUST
verify the outer signature and/or decrypt the outer layer
prior to verifying the signature on the
SignedData.PKIData.controlSequence.GLKey.
a - If the signature(s) does(do) not verify, the GL member MUST
return a response indicating CMCFailInfo.badMessageCheck.
b - If the signature(s) does(do) verify, the GL member process
the RecipientInfos according to CMS [2]. Once unwrapped the
GL member should store the shared KEK in a safe place. When
stored, the glName, glIdentifier, and shared KEK should be
associated.
6 Key Wrapping
In the mechanisms described in paragraphs 5, the group key being
distributed, in an EnvelopedData, MUST be protected by a key of
equal or greater length (i.e., if a RC2 128-bit key is being
Turner 53
distributed a key of 128-bits or greater must be used to protect the
key).
7 Algorithms
Triple-DES is mandatory other are optional. Triple-DES is mandatory other are optional.
6. Using the Group Key 8 Transport
SMTP must be supported.
9 Using the Group Key
[Put in here how this can be used with SMIME MLAs.] [Put in here how this can be used with SMIME MLAs.]
7. Schema Requirements 10 Schema Requirements
[I think we need to specify some MAYs for support of object classes, [I think we need to specify some MAYs for support of object classes,
etc. to support location of the GL and GL Owner in a repository. There etc. to support location of the GL and GLO in a repository. There
are really two choices for the GL mhsDistributionList from RFC 1274 and are really two choices for the GL mhsDistributionList from RFC 1274
addresslist from an Internet-Draft in the LDAPEXT WG. The only reason I and addresslist from an Internet-Draft in the LDAPEXT WG. The only
can think of not using the one from RFC 1274 is that a MUST CONTAIN is reason I can think of not using the one from RFC 1274 is that a MUST
mhsORAddress and we're should support SMTP. addressList (in the ID) CONTAIN is mhsORAddress and we're should support SMTP. addressList
doesn't have mhsORAddress as a must contain. The Owner in the both (in the ID) doesn't have mhsORAddress as a must contain. The Owner
object classes though has the syntax directoryName. We might have to in the both object classes though has the syntax directoryName. We
roll attribute for the Owner because I think it should probably have the might have to roll attribute for the Owner because I think it should
GeneralName syntax instead of just directoryName.] probably have the GeneralName syntax instead of just directoryName.]
[We can also define attributes that can be used to store the group key [We can also define attributes that can be used to store the group
encrypted for an individual group member and for the encrypted object. key encrypted for an individual group member and for the encrypted
Does anyone think this is useful/needed?] object. Does anyone think this is useful/needed?]
8. Acknowledgements 11 Security Considerations
Thanks to Russ Housley for providing much of the background and review Don't have too many GLOs because they could start willie nillie
required to write this draft. adding people you don't like.
9. References Need to rekey closed and managed GLs if a member is deleted.
[CMS] R. Housley, "Cryptographic Message Syntax," RFC 2630, June 1999. 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.
[ESS] P. Hoffman, "Enhanced Security Services for S/MIME," RFC 2534, Need to make sure you don't make the key size too small and duration
June 1999. long because people will have more time to attack the key.
[PROFILE] Housley, R., Ford, W., Polk, W., and Solo, D., "Internet X.509 Need to make sure you don't make the generationCounter to large
Public Key Infrastructure Certificate and CRL Profile," RFC 2459, because then people can attack the last key.
January 1999.
10. Security Considerations Turner 54
TBSL 12 References
[ Need to talk about the consequences of a compromised group KEK. ] 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP
9, RFC 2026, October 1996.
11. Patents 2 Housley, R., "Cryptographic Message Syntax," RFC 2630, June 1999.
I don't hold any (on this or any other topic) does anyone know of any? 3 Myers, M., Liu, X., Schadd, J., Weinsten, J., "Certificate
Management Message over CMS," draft-ietf-pkix-cmc-05.txt, July
1999.
12. Editor's Address 4 Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
Sean Turner IECA, Inc. 9010 Edgepark Road Vienna, VA 22182 Phone: (703) 5 Housley, R., Ford, W., Polk, W. and D. Solo, "Internet X.509
628-3180 E-Mail: turners@ieca.com Public Key Infrastructure: Certificate and CRL Profile", RFC
2459, January 1999.
Annex A - ASN.1 Module 13 Acknowledgements
TBSL Thanks to Russ Housley and Jim Schaad for providing much of the
background and review required to write this draft.
14 Author's Addresses
Sean Turner
IECA, Inc.
9010 Edgepark Road
Vienna, VA 22182
Phone: +1.703.628.3180
Email: turners@ieca.com
Expires January 14, 2001
Turner 55
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/