RFC 5275
CMS Symmetric Key Management and Distribution
3. Protocol Interactions
There are existing mechanisms (e.g., listserv and majordomo) to manage 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(s) 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 set up the GL, delete the GL, add members to the GL, delete members of the GL, request a group rekey, add owners to the GL, remove owners of the GL, indicate a group key compromise, refresh a group key, interrogate the GLA, and update members' and owners' public key certificates. The distribution
messages are the messages that distribute the shared KEKs. The following sections describe the ASN.1 for both the administration and distribution messages. Section 4 describes how to use the administration messages, and Section 5 describes how to use the distribution messages. +-----+ +----------+ | GLO | <---+ +----> | Member 1 | +-----+ | | +----------+ | | +-----+ <------+ | +----------+ | GLA | <-------------+----> | ... | +-----+ | +----------+ | | +----------+ +----> | Member n | +----------+ Figure 2 - Protocol Interactions3.1. Control Attributes
To avoid creating an entirely new protocol, the Certificate Management over CMS (CMC) protocol was chosen as the foundation of this protocol. The main reason for the choice was the layering aspect provided by CMC where one or more control attributes are included in message, protected with CMS, to request or respond to a desired action. The CMC PKIData structure is used for requests, and the CMC PKIResponse structure is used for responses. The content- types PKIData and PKIResponse are then encapsulated in CMS's SignedData or EnvelopedData, or a combination of the two (see Section 3.2). The following are the control attributes defined in this document:
Control
Attribute OID Syntax
------------------- ----------- -----------------
glUseKEK id-skd 1 GLUseKEK
glDelete id-skd 2 GeneralName
glAddMember id-skd 3 GLAddMember
glDeleteMember id-skd 4 GLDeleteMember
glRekey id-skd 5 GLRekey
glAddOwner id-skd 6 GLOwnerAdministration
glRemoveOwner id-skd 7 GLOwnerAdministration
glkCompromise id-skd 8 GeneralName
glkRefresh id-skd 9 GLKRefresh
glaQueryRequest id-skd 11 GLAQueryRequest
glaQueryResponse id-skd 12 GLAQueryResponse
glProvideCert id-skd 13 GLManageCert
glUpdateCert id-skd 14 GLManageCert
glKey id-skd 15 GLKey
In the following conformance tables, the column headings have the
following meanings: O for originate, R for receive, and F for
forward. There are three types of implementations: GLOs, GLAs, and
GL members. The GLO is an optional component, hence all GLO O and
GLO R messages are optional, and GLA F messages are optional. The
first table includes messages that conformant implementations MUST
support. The second table includes messages that MAY be implemented.
The second table should be interpreted as follows: if the control
attribute is implemented by a component, then it must be implemented
as indicated. For example, if a GLA is implemented that supports the
glAddMember control attribute, then it MUST support receiving the
glAddMember message. Note that "-" means not applicable.
Required
Implementation Requirement | Control
GLO | GLA | GL Member | Attribute
O R | O R F | O R |
------- | ----------------- | --------- | ----------
MAY - | MUST - MAY | - MUST | glProvideCert
MAY MAY | - MUST MAY | MUST - | glUpdateCert
- - | MUST - - | - MUST | glKey
Optional
Implementation Requirement | Control
GLO | GLA | GL Member | Attribute
O R | O R F | O R |
------- | ----------------- | --------- | ----------
MAY - | - MAY - | - - | glUseKEK
MAY - | - MAY - | - - | glDelete
MAY MAY | - MUST MAY | MUST - | glAddMember
MAY MAY | - MUST MAY | MUST - | glDeleteMember
MAY - | - MAY - | - - | glRekey
MAY - | - MAY - | - - | glAddOwner
MAY - | - MAY - | - - | glRemoveOwner
MAY MAY | - MUST MAY | MUST - | glkCompromise
MAY - | - MUST - | MUST - | glkRefresh
MAY - | - SHOULD - | MAY - | glaQueryRequest
- MAY | SHOULD - - | - MAY | glaQueryResponse
glaQueryResponse is carried in the CMC PKIResponse content-type, all
other control attributes are carried in the CMC PKIData content-type.
The exception is glUpdateCert, which can be carried in either PKIData
or PKIResponse.
Success and failure messages use CMC (see Section 3.2.4).
3.1.1. GL Use KEK
The GLO uses glUseKEK to request that a shared KEK be assigned to a
GL. glUseKEK messages MUST be signed by the GLO. The glUseKEK
control attribute has the syntax GLUseKEK:
GLUseKEK ::= SEQUENCE {
glInfo GLInfo,
glOwnerInfo SEQUENCE SIZE (1..MAX) OF GLOwnerInfo,
glAdministration GLAdministration DEFAULT 1,
glKeyAttributes GLKeyAttributes OPTIONAL }
GLInfo ::= SEQUENCE {
glName GeneralName,
glAddress GeneralName }
GLOwnerInfo ::= SEQUENCE {
glOwnerName GeneralName,
glOwnerAddress GeneralName,
certificate Certificates OPTIONAL }
Certificates ::= SEQUENCE {
pKC [0] Certificate OPTIONAL,
-- See [PROFILE]
aC [1] SEQUENCE SIZE (1.. MAX) OF
AttributeCertificate OPTIONAL,
-- See [ACPROF]
certPath [2] CertificateSet OPTIONAL }
-- From [CMS]
-- CertificateSet and CertificateChoices are included only
-- for illustrative purposes as they are imported from [CMS].
CertificateSet ::= SET SIZE (1..MAX) OF CertificateChoices
-- CertificateChoices supports X.509 public key certificates in
-- certificates and v2 attribute certificates in v2AttrCert.
GLAdministration ::= INTEGER {
unmanaged (0),
managed (1),
closed (2) }
GLKeyAttributes ::= SEQUENCE {
rekeyControlledByGLO [0] BOOLEAN DEFAULT FALSE,
recipientsNotMutuallyAware [1] BOOLEAN DEFAULT TRUE,
duration [2] INTEGER DEFAULT 0,
generationCounter [3] INTEGER DEFAULT 2,
requestedAlgorithm [4] AlgorithmIdentifier
DEFAULT { id-aes128-wrap } }
The fields in GLUseKEK have the following meaning:
- glInfo indicates the name of the GL in glName and the address of
the GL in glAddress. The glName and glAddress can be the same,
but this is not always the case. Both the name and address MUST
be unique for a given GLA.
- glOwnerInfo indicates:
-- glOwnerName indicates the name of the owner of the GL. One
of the names in glOwnerName MUST match one of the names in
the certificate (either the subject distinguished name or one
of the subject alternative names) used to sign this
SignedData.PKIData creating the GL (i.e., the immediate
signer).
-- glOwnerAddress indicates the GL owner's address.
-- certificates MAY be included. It contains the following
three fields:
--- certificates.pKC includes the encryption certificate for
the GLO. It will be used to encrypt responses for the
GLO.
--- certificates.aC MAY be included to convey any attribute
certificate (see [ACPROF]) associated with the
encryption certificate of the GLO included in
certificates.pKC.
--- certificates.certPath MAY also be included to convey
certificates that might aid the recipient in
constructing valid certification paths for the
certificate provided in certificates.pKC and the
attribute certificates provided in certificates.aC.
Theses certificates are optional because they might
already be included elsewhere in the message (e.g., in
the outer CMS layer).
-- glAdministration indicates how the GL ought to be
administered. The default is for the list to be managed.
Three values are supported for glAdministration:
--- Unmanaged - When the GLO sets glAdministration to
unmanaged, it is allowing prospective members to request
addition and deletion from the GL without GLO
intervention.
--- Managed - When the GLO sets glAdministration to managed,
it is allowing prospective members to request addition
and deletion from the GL, but the request is redirected
by the GLA to GLO for review. The GLO makes the
determination as to whether to honor the request.
--- Closed - When the GLO sets glAdministration to closed,
it is not allowing prospective members to request
addition or deletion from the GL. The GLA will only
accept glAddMember and glDeleteMember requests from the
GLO.
-- glKeyAttributes indicates the attributes the GLO wants the
GLA to assign to the shared KEK. If this field is omitted,
GL rekeys will be controlled by the GLA, the recipients are
allowed to know about one another, the algorithm will be
AES-128 (see Section 7), the shared KEK will be valid for a
calendar month (i.e., first of the month until the last day
of the month), and two shared KEKs will be distributed
initially. The fields in glKeyAttributes have the following
meaning:
--- rekeyControlledByGLO indicates whether the GL rekey
messages will be generated by the GLO or by the GLA.
The default is for the GLA to control rekeys. If GL
rekey is controlled by the GLA, the GL will continue to
be rekeyed until the GLO deletes the GL or changes the
GL rekey to be GLO controlled.
--- recipientsNotMutuallyAware indicates that the GLO wants
the GLA to distribute the shared KEK individually for
each of the GL members (i.e., a separate glKey message
is sent to each recipient). The default is for separate
glKey message not to 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 in the UTC Zulu time zone. For example,
if the duration is zero (0), if the GL shared KEK is
requested on July 24, the first key will be valid until
the end of July and the next key will be valid for the
entire month of August. If the value is not zero (0),
the shared KEK will be valid for the number of days
indicated by the value. For example, if the value of
duration is seven (7) and the shared KEK is requested on
Monday but not generated until Tuesday (13 May 2008);
the shared KEKs will be valid from Tuesday (13 May 2008)
to Tuesday (20 May 2008). 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. If the GLA controls rekey, then it also
indicates the number of shared KEKs the GLO wants
outstanding at any one time. See Sections 4.5 and 5 for
more on rekey.
--- requestedAlgorithm indicates the algorithm and any
parameters the GLO wants the GLA to use with the shared
KEK. The parameters are conveyed via the
SMIMECapabilities attribute (see [MSG]). See Section 6
for more on algorithms.
3.1.2. Delete GL
GLOs use glDelete to request that a GL be deleted from the GLA. The
glDelete control attribute has the syntax GeneralName. The glDelete
message MUST be signed by the GLO. The name of the GL to be deleted
is included in GeneralName:
DeleteGL ::= GeneralName
3.1.3. Add GL Member
GLOs use the glAddMember to request addition of new members, and
prospective GL members use the glAddMember to request their own
addition to the GL. The glAddMember message MUST be signed by either
the GLO or the prospective GL member. The glAddMember control
attribute has the syntax GLAddMember:
GLAddMember ::= SEQUENCE {
glName GeneralName,
glMember GLMember }
GLMember ::= SEQUENCE {
glMemberName GeneralName,
glMemberAddress GeneralName OPTIONAL,
certificates Certificates OPTIONAL }
The fields in GLAddMembers have the following meaning:
- glName indicates the name of the GL to which the member should be
added.
- glMember indicates the particulars for the GL member. Both of
the following fields must be unique for a given GL:
-- glMemberName indicates the name of the GL member.
-- glMemberAddress indicates the GL member's address. It MUST
be included.
Note: In some instances, the glMemberName and glMemberAddress
may be the same, but this is not always the case.
-- certificates MUST be included. It contains the following
three fields:
--- certificates.pKC includes the member's encryption
certificate. It will be used, at least initially, to
encrypt the shared KEK for that member. If the message
is generated by a prospective GL member, the pKC MUST be
included. If the message is generated by a GLO, the pKC
SHOULD be included.
--- certificates.aC MAY be included to convey any attribute
certificate (see [ACPROF]) associated with the member's
encryption certificate.
--- certificates.certPath MAY also be included to convey
certificates that might aid the recipient in
constructing valid certification paths for the
certificate provided in certificates.pKC and the
attribute certificates provided in certificates.aC.
These certificates are optional because they might
already be included elsewhere in the message (e.g., in
the outer CMS layer).
3.1.4. Delete GL Member
GLOs use the glDeleteMember to request deletion of GL members, and GL
members use the glDeleteMember to request their own removal from the
GL. The glDeleteMember message MUST be signed by either the GLO or
the GL member. The glDeleteMember control attribute has the syntax
GLDeleteMember:
GLDeleteMember ::= SEQUENCE {
glName GeneralName,
glMemberToDelete GeneralName }
The fields in GLDeleteMembers have the following meaning:
- glName indicates the name of the GL from which the member should
be removed.
- glMemberToDelete indicates the name or address of the member to
be deleted.
3.1.5. Rekey GL
GLOs use the glRekey to request a GL rekey. The glRekey message MUST
be signed by the GLO. The glRekey control attribute has the syntax
GLRekey:
GLRekey ::= SEQUENCE {
glName GeneralName,
glAdministration GLAdministration OPTIONAL,
glNewKeyAttributes GLNewKeyAttributes OPTIONAL,
glRekeyAllGLKeys BOOLEAN OPTIONAL }
GLNewKeyAttributes ::= SEQUENCE {
rekeyControlledByGLO [0] BOOLEAN OPTIONAL,
recipientsNotMutuallyAware [1] BOOLEAN OPTIONAL,
duration [2] INTEGER OPTIONAL,
generationCounter [3] INTEGER OPTIONAL,
requestedAlgorithm [4] AlgorithmIdentifier OPTIONAL }
The fields in GLRekey have the following meaning:
- glName indicates the name of the GL to be rekeyed.
- glAdministration indicates if there is any change to how the GL
should be administered. See Section 3.1.1 for the three options.
This field is only included if there is a change from the
previously registered glAdministration.
- glNewKeyAttributes indicates whether the rekey of the GLO is
controlled by the GLA or GL, what algorithm and parameters the
GLO wishes to use, the duration of the key, and how many keys
will be issued. The field is only included if there is a change
from the previously registered glKeyAttributes.
- glRekeyAllGLKeys indicates whether the GLO wants all of the
outstanding GL's shared KEKs rekeyed. If it is set to TRUE then
all outstanding KEKs MUST be issued. If it is set to FALSE then
all outstanding KEKs need not be reissued.
3.1.6. Add GL Owner
GLOs use the glAddOwner to request that a new GLO be allowed to administer the GL. The glAddOwner message MUST be signed by a registered GLO. The glAddOwner control attribute has the syntax GLOwnerAdministration: GLOwnerAdministration ::= SEQUENCE { glName GeneralName, glOwnerInfo GLOwnerInfo } The fields in GLAddOwners have the following meaning: - glName indicates the name of the GL to which the new GLO should be associated. - glOwnerInfo indicates the name, address, and certificates of the new GLO. As this message includes names of new GLOs, the certificates.pKC MUST be included, and it MUST include the encryption certificate of the new GLO.3.1.7. Remove GL Owner
GLOs use the glRemoveOwner to request that a GLO be disassociated with the GL. The glRemoveOwner message MUST be signed by a registered GLO. The glRemoveOwner control attribute has the syntax GLOwnerAdministration: GLOwnerAdministration ::= SEQUENCE { glName GeneralName, glOwnerInfo GLOwnerInfo } The fields in GLRemoveOwners have the following meaning: - glName indicates the name of the GL to which the GLO should be disassociated. - glOwnerInfo indicates the name and address of the GLO to be removed. The certificates field SHOULD be omitted, as it will be ignored.3.1.8. GL Key Compromise
GL members and GLOs use glkCompromise to indicate that the shared KEK possessed has been compromised. The glKeyCompromise control attribute has the syntax GeneralName. This message is always redirected by the GLA to the GLO for further action. The glkCompromise MAY be included in an EnvelopedData generated with the
compromised shared KEK. The name of the GL to which the compromised key is associated is placed in GeneralName: GLKCompromise ::= GeneralName3.1.9. GL Key Refresh
GL members use the glkRefresh to request that the shared KEK be redistributed to them. The glkRefresh control attribute has the syntax GLKRefresh. GLKRefresh ::= SEQUENCE { glName GeneralName, dates SEQUENCE SIZE (1..MAX) OF Date } Date ::= SEQUENCE { start GeneralizedTime, end GeneralizedTime OPTIONAL } The fields in GLKRefresh have the following meaning: - glName indicates the name of the GL for which the GL member wants shared KEKs. - dates indicates a date range for keys the GL member wants. The start field indicates the first date the GL member wants and the end field indicates the last date. The end date MAY be omitted to indicate the GL member wants all keys from the specified start date to the current date. Note that a procedural mechanism is needed to restrict users from accessing messages that they are not allowed to access.3.1.10. GLA Query Request and Response
There are situations where GLOs and GL members may need to determine some information from the GLA about the GL. GLOs and GL members use the glaQueryRequest, defined in Section 3.1.10.1, to request information and GLAs use the glaQueryResponse, defined in Section 3.1.10.2, to return the requested information. Section 3.1.10.3 includes one request and response type and value; others may be defined in additional documents.3.1.10.1. GLA Query Request
GLOs and GL members use the glaQueryRequest to ascertain information about the GLA. The glaQueryRequest control attribute has the syntax GLAQueryRequest:
GLAQueryRequest ::= SEQUENCE {
glaRequestType OBJECT IDENTIFIER,
glaRequestValue ANY DEFINED BY glaRequestType }
3.1.10.2. GLA Query Response
GLAs return the glaQueryResponse after receiving a GLAQueryRequest.
The glaQueryResponse MUST be signed by a GLA. The glaQueryResponse
control attribute has the syntax GLAQueryResponse:
GLAQueryResponse ::= SEQUENCE {
glaResponseType OBJECT IDENTIFIER,
glaResponseValue ANY DEFINED BY glaResponseType }
3.1.10.3. Request and Response Types
Requests and responses are registered as a pair under the following
object identifier arc:
id-cmc-glaRR OBJECT IDENTIFIER ::= { id-cmc 99 }
This document defines one request/response pair for GL members and
GLOs to query the GLA for the list of algorithm it supports. The
following Object Identifier (OID) is included in the glaQueryType
field:
id-cmc-gla-skdAlgRequest OBJECT IDENTIFIER ::={ id-cmc-glaRR 1 }
SKDAlgRequest ::= NULL
If the GLA supports GLAQueryRequest and GLAQueryResponse messages,
the GLA may return the following OID in the glaQueryType field:
id-cmc-gla-skdAlgResponse OBJECT IDENTIFIER ::= { id-cmc-glaRR 2 }
The glaQueryValue has the form of the smimeCapabilities attributes as
defined in [MSG].
3.1.11. Provide Cert
GLAs and GLOs use the glProvideCert to request that a GL member
provide an updated or new encryption certificate. The glProvideCert
message MUST be signed by either GLA or GLO. If the GL member's PKC
has been revoked, the GLO or GLA MUST NOT use it to generate the
EnvelopedData that encapsulates the glProvideCert request. The
glProvideCert control attribute has the syntax GLManageCert:
GLManageCert ::= SEQUENCE {
glName GeneralName,
glMember GLMember }
The fields in GLManageCert have the following meaning:
- glName indicates the name of the GL to which the GL member's new
certificate is to be associated.
- glMember indicates particulars for the GL member:
-- glMemberName indicates the GL member's name.
-- glMemberAddress indicates the GL member's address. It MAY be
omitted.
-- certificates SHOULD be omitted.
3.1.12 Update Cert
GL members and GLOs use the glUpdateCert to provide a new certificate
for the GL. GL members can generate an unsolicited glUpdateCert or
generate a response glUpdateCert as a result of receiving a
glProvideCert message. GL members MUST sign the glUpdateCert. If
the GL member's encryption certificate has been revoked, the GL
member MUST NOT use it to generate the EnvelopedData that
encapsulates the glUpdateCert request or response. The glUpdateCert
control attribute has the syntax GLManageCert:
GLManageCert ::= SEQUENCE {
glName GeneralName,
glMember GLMember }
The fields in GLManageCert have the following meaning:
- glName indicates the name of the GL to which the GL member's new
certificate should be associated.
- glMember indicates the particulars for the GL member:
-- glMemberName indicates the GL member's name.
-- glMemberAddress indicates the GL member's address. It MAY be
omitted.
-- certificates MAY be omitted if the GLManageCert message is
sent to request the GL member's certificate; otherwise, it
MUST be included. It includes the following three fields:
--- certificates.pKC includes the member's encryption
certificate that will be used to encrypt the shared KEK
for that member.
--- certificates.aC MAY be included to convey one or more
attribute certificates associated with the member's
encryption certificate.
--- certificates.certPath MAY also be included to convey
certificates that might aid the recipient in
constructing valid certification paths for the
certificate provided in certificates.pKC and the
attribute certificates provided in certificates.aC.
These certificates are optional because they might
already be included elsewhere in the message (e.g., in
the outer CMS layer).
3.1.13. GL Key
The GLA uses the glKey to distribute the shared KEK. The glKey
message MUST be signed by the GLA. The glKey control attribute has
the syntax GLKey:
GLKey ::= SEQUENCE {
glName GeneralName,
glIdentifier KEKIdentifier, -- See [CMS]
glkWrapped RecipientInfos, -- See [CMS]
glkAlgorithm AlgorithmIdentifier,
glkNotBefore GeneralizedTime,
glkNotAfter GeneralizedTime }
-- KEKIdentifier is included only for illustrative purposes as
-- it is imported from [CMS].
KEKIdentifier ::= SEQUENCE {
keyIdentifier OCTET STRING,
date GeneralizedTime OPTIONAL,
other OtherKeyAttribute OPTIONAL }
The fields in GLKey have the following meaning:
- glName is the name of the GL.
- glIdentifier is the key identifier of the shared KEK. See
Section 6.2.3 of [CMS] for a description of the subfields.
- glkWrapped is the wrapped shared KEK for the GL for a particular
duration. The RecipientInfos MUST be generated as specified in
Section 6.2 of [CMS]. The ktri RecipientInfo choice MUST be
supported. The key in the EncryptedKey field (i.e., the
distributed shared KEK) MUST be generated according to the
section concerning random number generation in the security
considerations of [CMS].
- glkAlgorithm identifies the algorithm with which the shared KEK
is used. Since no encrypted data content is being conveyed at
this point, the parameters encoded with the algorithm should be
the structure defined for smimeCapabilities rather than encrypted
content.
- glkNotBefore indicates the date at which the shared KEK is
considered valid. GeneralizedTime values MUST be expressed in
UTC (Zulu) and MUST include seconds (i.e., times are
YYYYMMDDHHMMSSZ), even where the number of seconds is zero.
GeneralizedTime values MUST NOT include fractional seconds.
- glkNotAfter indicates the date after which the shared KEK is
considered invalid. GeneralizedTime values MUST be expressed in
UTC (Zulu) and MUST include seconds (i.e., times are
YYYYMMDDHHMMSSZ), even where the number of seconds is zero.
GeneralizedTime values MUST NOT include fractional seconds.
If the glKey message is in response to a glUseKEK message:
- The GLA MUST generate separate glKey messages for each recipient
if glUseKEK.glKeyAttributes.recipientsNotMutuallyAware is set to
TRUE. For each recipient, you want to generate a message that
contains that recipient's key (i.e., one message with one
attribute).
- The GLA MUST generate the requested number of glKey messages.
The value in glUseKEK.glKeyAttributes.generationCounter indicates
the number of glKey messages requested.
If the glKey message is in response to a glRekey message:
- The GLA MUST generate separate glKey messages for each recipient
if glRekey.glNewKeyAttributes.recipientsNotMutuallyAware is set
to TRUE.
- The GLA MUST generate the requested number of glKey messages.
The value in glUseKEK.glKeyAttributes.generationCounter indicates
the number of glKey messages requested.
- The GLA MUST generate one glKey message for each outstanding
shared KEKs for the GL when glRekeyAllGLKeys is set to TRUE.
If the glKey message was not in response to a glRekey or glUseKEK
(e.g., where the GLA controls rekey):
- The GLA MUST generate separate glKey messages for each recipient
when glUseKEK.glNewKeyAttributes.recipientsNotMutuallyAware that
set up the GL was set to TRUE.
- The GLA MAY generate glKey messages prior to the duration on the
last outstanding shared KEK expiring, where the number of glKey
messages generated is generationCounter minus one (1). Other
distribution mechanisms can also be supported to support this
functionality.
3.2. Use of CMC, CMS, and PKIX
The following sections outline the use of CMC, CMS, and the PKIX
certificate and CRL profile.
3.2.1. Protection Layers
The following sections outline the protection required for the
control attributes defined in this document.
Note: There are multiple ways to encapsulate SignedData and
EnvelopedData. The first is to use a MIME wrapper around each
ContentInfo, as specified in [MSG]. The second is not to use a MIME
wrapper around each ContentInfo, as specified in Transporting S/MIME
Objects in X.400 [X400TRANS].
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].
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: Authentication and Integrity Confidentiality Protection of Confidentiality Protection -------------------------- ----------------------------- EnvelopedData SignedData SignedData EnvelopedData PKIData or PKIResponse SignedData controlSequence PKIData or PKIResponse controlSequence If an incoming message is encrypted, the confidentiality of the message MUST be preserved. All EnvelopedData objects MUST be processed as specified in [CMS]. If a SignedData is added over an EnvelopedData, a ContentHints attribute SHOULD be added. See Section 2.9 of Extended Security Services for S/MIME [ESS]. If the GLO or GL member applies confidentiality to a request, the EnvelopedData MUST include the GLA as a recipient. If the GLA forwards the GL member request to the GLO, then the GLA MUST decrypt the EnvelopedData content, strip the confidentiality layer, and apply its own confidentiality layer as an EnvelopedData with the GLO as a recipient.3.2.2. Combining Requests and Responses
Multiple requests and responses corresponding to a GL MAY be included in one PKIData.controlSequence or PKIResponse.controlSequence. Requests and responses for multiple GLs MAY be combined in one PKIData or PKIResponse by using PKIData.cmsSequence and PKIResponse.cmsSequence. A separate cmsSequence MUST be used for different GLs. That is, requests corresponding to two different GLs are included in different cmsSequences. The following is a diagram depicting multiple requests and responses combined in one PKIData and PKIResponse:
Multiple Requests and Responses
Request Response
------- --------
SignedData SignedData
PKIData PKIResponse
cmsSequence cmsSequence
SignedData SignedData
PKIData PKIResponse
controlSequence controlSequence
One or more requests One or more responses
corresponding to one GL corresponding to one GL
SignedData SignedData
PKIData PKIResponse
controlSequence controlSequence
One or more requests One or more responses
corresponding to another GL corresponding to another GL
When applying confidentiality to multiple requests and responses, all
of the requests/responses MAY be included in one EnvelopedData. The
following is a depiction:
Confidentiality of Multiple Requests and Responses
Wrapped Together
----------------
EnvelopedData
SignedData
PKIData
cmsSequence
SignedData
PKIResponse
controlSequence
One or more requests
corresponding to one GL
SignedData
PKIData
controlSequence
One or more requests
corresponding to one GL
Certain combinations of requests in one PKIData.controlSequence and
one PKIResponse.controlSequence are not allowed. The invalid
combinations listed here MUST NOT be generated:
Invalid Combinations
---------------------------
glUseKEK & glDeleteMember
glUseKEK & glRekey
glUseKEK & glDelete
glDelete & glAddMember
glDelete & glDeleteMember
glDelete & glRekey
glDelete & glAddOwner
glDelete & glRemoveOwner
To avoid unnecessary errors, certain requests and responses SHOULD be
processed prior to others. The following is the priority of message
processing, if not listed it is an implementation decision as to
which to process first: glUseKEK before glAddMember, glRekey before
glAddMember, and glDeleteMember before glRekey. Note that there is a
processing priority, but it does not imply an ordering within the
content.
3.2.3. GLA Generated Messages
When the GLA generates a success or fail message, it generates one
for each request. SKDFailInfo values of unsupportedDuration,
unsupportedDeliveryMethod, unsupportedAlgorithm, noGLONameMatch,
nameAlreadyInUse, alreadyAnOwner, and notAnOwner are not returned to
GL members.
If GLKeyAttributes.recipientsNotMutuallyAware is set to TRUE, a
separate PKIResponse.cMCStatusInfoExt and PKIData.glKey MUST be
generated for each recipient. However, it is valid to send one
message with multiple attributes to the same recipient.
If the GL has multiple GLOs, the GLA MUST send cMCStatusInfoExt
messages to the requesting GLO. The mechanism to determine which GLO
made the request is beyond the scope of this document.
If a GL is managed and the GLA receives a glAddMember,
glDeleteMember, or glkCompromise message, the GLA redirects the
request to the GLO for review. An additional, SignedData MUST be
applied to the redirected request as follows:
GLA Forwarded Requests
----------------------
SignedData
PKIData
cmsSequence
SignedData
PKIData
controlSequence
3.2.4. CMC Control Attributes and CMS Signed Attributes
CMC carries control attributes as CMS signed attributes. These
attributes are defined in [CMC] and [CMS]. Some of these attributes
are REQUIRED; others are OPTIONAL. The required attributes are as
follows: cMCStatusInfoExt transactionId, senderNonce, recipientNonce,
queryPending, and signingTime. Other attributes can also be used;
however, their use is beyond the scope of this document. The
following sections specify requirements in addition to those already
specified in [CMC] and [CMS].
3.2.4.1. Using cMCStatusInfoExt
cMCStatusInfoExt is used by GLAs to indicate to GLOs and GL members
that a request was unsuccessful. Two classes of failure codes are
used within this document. Errors from the CMCFailInfo list, found
in Section 5.1.4 of CMC, are encoded as defined in CMC. Error codes
defined in this document are encoded using the ExtendedFailInfo field
of the cmcStatusInfoExt structure. If the same failure code applies
to multiple commands, a single cmcStatusInfoExt structure can be used
with multiple items in cMCStatusInfoExt.bodyList. The GLA MAY also
return other pertinent information in statusString. The SKDFailInfo
object identifier and value are:
id-cet-skdFailInfo OBJECT IDENTIFIER ::= { iso(1)
identified-organization(3) dod(6) internet(1) security(5)
mechanisms(5) pkix(7) cet(15) skdFailInfo(1) }
SKDFailInfo ::= INTEGER {
unspecified (0),
closedGL (1),
unsupportedDuration (2),
noGLACertificate (3),
invalidCert (4),
unsupportedAlgorithm (5),
noGLONameMatch (6),
invalidGLName (7),
nameAlreadyInUse (8),
noSpam (9),
-- obsolete (10),
alreadyAMember (11),
notAMember (12),
alreadyAnOwner (13),
notAnOwner (14) }
The values have the following meaning:
- unspecified indicates that the GLA is unable or unwilling to
perform the requested action and does not want to indicate the
reason.
- closedGL indicates that members can only be added or deleted by
the GLO.
- unsupportedDuration indicates that the GLA does not support
generating keys that are valid for the requested duration.
- noGLACertificate indicates that the GLA does not have a valid
certificate.
- invalidCert indicates that the member's encryption certificate
was not verifiable (i.e., signature did not validate,
certificate's serial number present on a CRL, the certificate
expired, etc.).
- unsupportedAlgorithm indicates the GLA does not support the
requested algorithm.
- noGLONameMatch indicates that one of the names in the certificate
used to sign a request does not match the name of a registered
GLO.
- invalidGLName indicates that the GLA does not support the glName
present in the request.
- nameAlreadyInUse indicates that the glName is already assigned on
the GLA.
- noSpam indicates that the prospective GL member did not sign the
request (i.e., if the name in glMember.glMemberName does not
match one of the names (either the subject distinguished name or
one of the subject alternative names) in the certificate used to
sign the request).
- alreadyAMember indicates that the prospective GL member is
already a GL member.
- notAMember indicates that the prospective GL member to be deleted
is not presently a GL member.
- alreadyAnOwner indicates that the prospective GLO is already a
GLO.
- notAnOwner indicates that the prospective GLO to be deleted is
not presently a GLO.
cMCStatusInfoExt is used by GLAs to indicate to GLOs and GL members
that a request was successfully completed. If the request was
successful, the GLA returns a cMCStatusInfoExt response with
cMCStatus.success and optionally other pertinent information in
statusString.
When the GL is managed and the GLO has reviewed GL member initiated
glAddMember, glDeleteMember, and glkComrpomise requests, the GLO uses
cMCStatusInfoExt to indicate the success or failure of the request.
If the request is allowed, cMCStatus.success is returned and
statusString is optionally returned to convey additional information.
If the request is denied, cMCStatus.failed is returned and
statusString is optionally returned to convey additional information.
Additionally, the appropriate SKDFailInfo can be included in
cMCStatusInfoExt.extendedFailInfo.
cMCStatusInfoExt is used by GLOs, GLAs, and GL members to indicate
that signature verification failed. If the signature failed to
verify over any control attribute except a cMCStatusInfoExt, a
cMCStatusInfoExt control attribute MUST be returned indicating
cMCStatus.failed and otherInfo.failInfo.badMessageCheck. If the
signature over the outermost PKIData failed, the bodyList value is
zero (0). If the signature over any other PKIData failed, the
bodyList value is the bodyPartId value from the request or response.
GLOs and GL members who receive cMCStatusInfoExt messages whose
signatures are invalid SHOULD generate a new request to avoid
badMessageCheck message loops.
cMCStatusInfoExt is also used by GLOs and GLAs to indicate that a
request could not be performed immediately. If the request could not
be processed immediately by the GLA or GLO, the cMCStatusInfoExt
control attribute MUST be returned indicating cMCStatus.pending and
otherInfo.pendInfo. When requests are redirected to the GLO for
approval (for managed lists), the GLA MUST NOT return a
cMCStatusInfoExt indicating query pending.
cMCStatusInfoExt is also used by GLAs to indicate that a glaQueryRequest is not supported. If the glaQueryRequest is not supported, the cMCStatusInfoExt control attribute MUST be returned indicating cMCStatus.noSupport and statusString is optionally returned to convey additional information. cMCStatusInfoExt is also used by GL members, GLOs, and GLAs to indicate that the signingTime (see Section 3.2.4.3) is not close enough to the locally specified time. If the local time is not close enough to the time specified in signingTime, a cMCStatus.failed and otherInfo.failInfo.badTime MAY be returned.3.2.4.2. Using transactionId
transactionId MAY be included by GLOs, GLAs, or GL members to identify a given transaction. All subsequent requests and responses related to the original request MUST include the same transactionId control attribute. If GL members include a transactionId and the request is redirected to the GLO, the GLA MAY include an additional transactionId in the outer PKIData. If the GLA included an additional transactionId in the outer PKIData, when the GLO generates a cMCStatusInfoExt response it generates one for the GLA with the GLA's transactionId and one for the GL member with the GL member's transactionId.3.2.4.3. Using Nonces and signingTime
The use of nonces (see Section 5.6 of [CMC]) and an indication of when the message was signed (see Section 11.3 of [CMS]) can be used to provide application-level replay prevention. To protect the GL, all messages MUST include the signingTime attribute. Message originators and recipients can then use the time provided in this attribute to determine whether they have previously received the message. If the originating message includes a senderNonce, the response to the message MUST include the received senderNonce value as the recipientNonce and a new value as the senderNonce value in the response. If a GLA aggregates multiple messages together or forwards a message to a GLO, the GLA MAY optionally generate a new nonce value and include that in the wrapping message. When the response comes back from the GLO, the GLA builds a response to the originator(s) of the message(s) and deals with each of the nonce values from the originating messages.
For these attributes, it is necessary to maintain state information on exchanges to compare one result to another. The time period for which this information is maintained is a local policy.3.2.4.4. CMC and CMS Attribute Support Requirements
The following are the implementation requirements for CMC control attributes and CMS signed attributes for an implementation to be considered conformant to this specification: Implementation Requirement | GLO | GLA | GL Member | Attribute O R | O R F | O R | --------- | ------------- | --------- | ---------- MUST MUST | MUST MUST - | MUST MUST | cMCStatusInfoExt MAY MAY | MUST MUST - | MAY MAY | transactionId MAY MAY | MUST MUST - | MAY MAY | senderNonce MAY MAY | MUST MUST - | MAY MAY | recepientNonce MUST MUST | MUST MUST - | MUST MUST | SKDFailInfo MUST MUST | MUST MUST - | MUST MUST | signingTime3.2.5. Resubmitted GL Member Messages
When the GL is managed, the GLA forwards the GL member requests to the GLO for GLO approval by creating a new request message containing the GL member request(s) as a cmsSequence item. If the GLO approves the request, it can either add a new layer of wrapping and send it back to the GLA or create a new message and send it to the GLA. (Note in this case there are now 3 layers of PKIData messages with appropriate signing layers.)3.2.6. PKIX Certificate and CRL Profile
Signatures, certificates, and CRLs are verified according to the PKIX profile [PROFILE]. Name matching is performed according to the PKIX profile [PROFILE]. All distinguished name forms must follow the UTF8String convention noted in the PKIX profile [PROFILE]. A certificate per GL would be issued to the GLA. GL policy may mandate that the GL member's address be included in the GL member's certificate.
(next page on part 3)
