Network Working Group S. Turner
Request for Comments: 5275 IECA
Category: Standards Track June 2008 CMS Symmetric Key Management and Distribution
Status of This Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
This document describes a mechanism to manage (i.e., set up,
distribute, and rekey) keys used with symmetric cryptographic
algorithms. Also defined herein is a mechanism to organize users
into groups to support distribution of encrypted content using
symmetric cryptographic algorithms. The mechanism uses the
Cryptographic Message Syntax (CMS) protocol and Certificate
Management over CMS (CMC) protocol 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 Secure/Multipurpose Internet
Mail Extensions (S/MIME) Mail List Agents (MLAs).
With the ever-expanding use of secure electronic communications
(e.g., S/MIME [MSG]), 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 RecipientInfo 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,
processing of the per-recipient information may take quite some time,
not to mention the time required to collect and validate the PKCs for
each of the recipients. Each recipient identifies its per-recipient
information and uses the private key associated with the public key
of its PKC to decrypt the CEK and hence gain access to the encrypted
With symmetric algorithms, the origination process is slightly
different. 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
The techniques to protect the shared KEK 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 confidentiality. 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 performing the encryption wants to ensure that some
subset of the group does not gain access to the information, either a
different KEK should be used (shared only with this smaller group) or
asymmetric algorithms should be used.
1.1. Conventions Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14, RFC 2119
1.2. Applicability to E-mail
One primary audience for this distribution mechanism is e-mail.
Distribution lists, sometimes referred to as mail lists, support the
distribution of messages to recipients subscribed to the mail list.
There are two models for how the mail list can be used. If the
originator is a member of the mail list, the originator sends
messages encrypted with the shared KEK to the mail list (e.g.,
listserv or majordomo) and the message is distributed to the mail
list members. If the originator is not a member of the mail list
(does not have the shared KEK), the originator sends the message
(encrypted for the MLA) to the Mail List Agent (MLA), and then the
MLA uses the shared KEK to encrypt the message for the members. In
either case, the recipients of the mail list use the previously
distributed-shared KEK to decrypt the message.
1.3. Applicability to Repositories
Objects can also be distributed via a repository (e.g., Lightweight
Directory Access Protocol (LDAP) servers, X.500 Directory System
Agents (DSAs), Web-based servers). If an object is stored in a
repository encrypted with a symmetric key algorithm, anyone with the
shared KEK and access to that object can then decrypt that object.
The encrypted object and the encrypted, shared KEK can be stored in
1.4. Using the Group Key
This document was written with three specific scenarios in mind: two
supporting Mail List Agents and one for general message distribution.
Scenario 1 depicts the originator sending a public key (PK) protected
message to an MLA who then uses the shared KEK(s) to redistribute the
message to the members of the list. Scenario 2 depicts the
originator sending a shared KEK protected message to an MLA who then
redistributes the message to the members of the list (the MLA only
adds additional recipients). The key used by the originator could be
a key shared either amongst all recipients or just between the member
and the MLA. Note that if the originator uses a key shared only with
the MLA, then the MLA will need to decrypt the message and reencrypt
the message for the list recipients. Scenario 3 shows an originator
sending a shared KEK protected message to a group of recipients
without an intermediate MLA.
+----> +----> +---->
PK +-----+ S | S +-----+ S | S |
----> | MLA | --+----> ----> | MLA | --+----> ----+---->
+-----+ | +-----+ | |
+----> +----> +---->
Scenario 1 Scenario 2 Scenario 3
Figure 1 depicts the architecture to support symmetric key
distribution. The Group List Agent (GLA) supports two distinct
functions with two different agents:
- The Key Management Agent (KMA), which is responsible for
generating the shared KEKs.
- The Group Management Agent (GMA), which is responsible for
managing the Group List (GL) to which the shared KEKs are
| Group List Agent | +-------+
| +------------+ + -----------------------+ | | Group |
| | Key | | Group Management Agent | |<-->| List |
| | Management |<-->| +------------+ | | | Owner |
| | Agent | | | Group List | | | +-------+
| +------------+ | +------------+ | |
| | / | \ | |
| +------------------------+ |
/ | \
/ | \
+----------+ +---------+ +----------+
| Member 1 | | ... | | Member n |
+----------+ +---------+ +----------+
Figure 1 - Key Distribution Architecture
A GLA may support multiple KMAs. A GLA in general supports only one
GMA, but the GMA may support multiple GLs. Multiple KMAs may support
a GMA in the same fashion as GLAs support multiple KMAs. Assigning a
particular KMA to a GL is beyond the scope of this document.
Modeling real-world GL implementations shows that there are very
restrictive GLs, where a human determines GL membership, and very
open GLs, where there are no restrictions on GL membership. To
support this spectrum, the mechanism described herein supports both
managed (i.e., where access control is applied) and unmanaged (i.e.,
where no access control is applied) GLs. The access control
mechanism for managed lists is beyond the scope of this document.
Note: If the distribution for the list is performed by an entity
other than the originator (e.g., an MLA distributing a mail message),
this entity can also enforce access control rules.
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 to 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. GLO(s) may also set up lists
that are closed, where the GLO solely determines GL membership.
Though Figure 1 depicts the GLA as encompassing both the KMA and GMA
functions, the two functions could be supported by the same entity or
they could be supported by two different entities. If two entities
are used, they could be located on one or two platforms. There is
however a close relationship between the KMA and GMA functions. If
the GMA stores all information pertaining to the GLs and the KMA
merely generates keys, a corrupted GMA could cause havoc. To protect
against a corrupted GMA, the KMA would be forced to double check the
requests it receives to ensure that the GMA did not tamper with them.
These duplicative checks blur the functionality of the two components
together. For this reason, the interactions between the KMA and GMA
are beyond the scope of this document.
Proprietary mechanisms may be used to separate the functions by
strengthening the trust relationship between the two entities.
Henceforth, the distinction between the two agents is not discussed
further; the term GLA will be used to address both functions. It
should be noted that a corrupt GLA can always cause havoc.