draft-ietf-smime-symkeydist-07.txt   draft-ietf-smime-symkeydist-08.txt 
SMIME Working Group S. Turner SMIME Working Group S. Turner
Internet Draft IECA Internet Draft IECA
Document: draft-ietf-smime-symkeydist-07.txt January 2002 Document: draft-ietf-smime-symkeydist-08.txt December 2002
Expires: July 2001 Expires: June 2003
CMS Symmetric Key Management and Distribution CMS Symmetric Key Management and Distribution
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026 [1]. all provisions of Section 10 of RFC2026.
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, documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts. working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents months and may be updated, replaced, or obsoleted by other documents
at 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."
skipping to change at line 42 skipping to change at line 42
single word subscribe in the body of the message. There is a Web 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/>. site for the mailing list at <http://www.imc.org/ietf-smime/>.
Abstract Abstract
This document describes a mechanism to manage (i.e., setup, This document describes a mechanism to manage (i.e., setup,
distribute, and rekey) keys used with symmetric cryptographic distribute, and rekey) keys used with symmetric cryptographic
algorithms. Also defined herein is a mechanism to organize users algorithms. Also defined herein is a mechanism to organize users
into groups to support distribution of encrypted content using into groups to support distribution of encrypted content using
symmetric cryptographic algorithms. The mechanism uses the symmetric cryptographic algorithms. The mechanism uses the
Cryptographic Message Syntax (CMS) protocol [2] and Certificate Cryptographic Message Syntax (CMS) protocol [CMS] and Certificate
Management Message over CMS (CMC) protocol [3] to manage the Management Message over CMS (CMC) protocol [CMC] to manage the
symmetric keys. Any member of the group can then later use this symmetric keys. Any member of the group can then later use this
distributed shared key to decrypt other CMS encrypted objects with distributed shared key to decrypt other CMS encrypted objects with
the symmetric key. This mechanism has been developed to support the symmetric key. This mechanism has been developed to support
S/MIME Mail List Agents (MLAs). S/MIME Mail List Agents (MLAs).
Turner 1 Turner 1
And Distribution And Distribution
Conventions used in this document Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119 [4]. document are to be interpreted as described in RFC-2119 [STDWORDS].
1 INTRODUCTION.....................................................3 1 INTRODUCTION.....................................................3
1.1 APPLICABILITY TO E-MAIL........................................4 1.1 APPLICABILITY TO E-MAIL........................................4
1.2 APPLICABILITY TO REPOSITORIES..................................4 1.2 APPLICABILITY TO REPOSITORIES..................................4
1.3 USING THE GROUP KEY............................................4 1.3 USING THE GROUP KEY............................................4
2 ARCHITECTURE.....................................................5 2 ARCHITECTURE.....................................................5
3 PROTOCOL INTERACTIONS............................................6 3 PROTOCOL INTERACTIONS............................................6
3.1 CONTROL ATTRIBUTES.............................................8 3.1 CONTROL ATTRIBUTES.............................................8
3.1.1 GL USE KEK...................................................9 3.1.1 GL USE KEK...................................................9
3.1.2 DELETE GL...................................................13 3.1.2 DELETE GL...................................................13
3.1.3 ADD GL MEMBER...............................................13 3.1.3 ADD GL MEMBER...............................................13
3.1.4 DELETE GL MEMBER............................................14 3.1.4 DELETE GL MEMBER............................................14
3.1.5 REKEY GL....................................................15 3.1.5 REKEY GL....................................................15
3.1.6 ADD GL OWNER................................................16 3.1.6 ADD GL OWNER................................................15
3.1.7 REMOVE GL OWNER.............................................16 3.1.7 REMOVE GL OWNER.............................................16
3.1.8 GL KEY COMPROMISE...........................................17 3.1.8 GL KEY COMPROMISE...........................................16
3.1.9 GL KEY REFRESH..............................................17 3.1.9 GL KEY REFRESH..............................................16
3.1.10 GLA QUERY REQUEST AND RESPONSE.............................17 3.1.10 GLA QUERY REQUEST AND RESPONSE.............................17
3.1.10.1 GLA QUERY REQUEST........................................18 3.1.10.1 GLA QUERY REQUEST........................................17
3.1.10.2 GLA QUERY RESPONSE.......................................18 3.1.10.2 GLA QUERY RESPONSE.......................................17
3.1.10.3 REQUEST AND RESPONSE TYPES...............................18 3.1.10.3 REQUEST AND RESPONSE TYPES...............................18
3.1.12 PROVIDE CERT...............................................18 3.1.12 PROVIDE CERT...............................................18
3.1.13 UPDATE CERT................................................19 3.1.13 UPDATE CERT................................................19
3.1.14 GL KEY.....................................................20 3.1.14 GL KEY.....................................................20
3.2 USE OF CMC, CMS, AND PKIX.....................................22 3.2 USE OF CMC, CMS, AND PKIX.....................................21
3.2.1 PROTECTION LAYERS...........................................22 3.2.1 PROTECTION LAYERS...........................................22
3.2.1.1 MINIMUM PROTECTION........................................22 3.2.1.1 MINIMUM PROTECTION........................................22
3.2.1.2 ADDITIONAL PROTECTION.....................................23 3.2.1.2 ADDITIONAL PROTECTION.....................................22
3.2.2 COMBINING REQUESTS AND RESPONSES............................24 3.2.2 COMBINING REQUESTS AND RESPONSES............................23
3.2.3 GLA GENERATED MESSAGES......................................25 3.2.3 GLA GENERATED MESSAGES......................................24
3.2.4 CMC CONTROL ATTRIBUTES......................................26 3.2.4 CMC CONTROL ATTRIBUTES AND CMS SIGNED ATTRIBUTES............25
3.2.4.1 USING CMCSTATUSINFOEXT....................................26 3.2.4.1 USING CMCSTATUSINFOEXT....................................25
3.2.4.2 USING TRANSACTIONID.......................................29 3.2.4.2 USING TRANSACTIONID.......................................28
3.2.4.3 USING NONCES..............................................29 3.2.4.3 USING NONCES AND SIGNINGTIME..............................28
3.2.4.4 CMC ATTRIBUTE SUPPORT REQUIREMENTS........................29 3.2.4.4 CMC AND CMS ATTRIBUTE SUPPORT REQUIREMENTS................29
3.2.5 RESUBMITTED GL MEMBER MESSAGES..............................30 3.2.5 RESUBMITTED GL MEMBER MESSAGES..............................29
3.2.6 PKIX CERTIFICATE AND CRL PROFILE............................30 3.2.6 PKIX CERTIFICATE AND CRL PROFILE............................29
4 ADMINISTRATIVE MESSAGES.........................................30 4 ADMINISTRATIVE MESSAGES.........................................30
4.1 ASSIGN KEK TO GL..............................................30 4.1 ASSIGN KEK TO GL..............................................30
4.2 DELETE GL FROM GLA............................................33 4.2 DELETE GL FROM GLA............................................33
4.3 ADD MEMBERS TO GL.............................................35 4.3 ADD MEMBERS TO GL.............................................36
4.3.1 GLO INITIATED ADDITIONS.....................................36 4.3.1 GLO INITIATED ADDITIONS.....................................37
4.3.2 PROSPECTIVE MEMBER INITIATED ADDITIONS......................42 4.3.2 PROSPECTIVE MEMBER INITIATED ADDITIONS......................43
4.4 DELETE MEMBERS FROM GL........................................44 4.4 DELETE MEMBERS FROM GL........................................45
4.4.1 GLO INITIATED DELETIONS.....................................45 4.4.1 GLO INITIATED DELETIONS.....................................46
4.4.2 MEMBER INITIATED DELETIONS..................................49 4.4.2 MEMBER INITIATED DELETIONS..................................51
4.5 REQUEST REKEY OF GL...........................................50 4.5 REQUEST REKEY OF GL...........................................53
Turner 2 Turner Expires June 2003 2
And Distribution And Distribution
4.5.1 GLO INITIATED REKEY REQUESTS................................51 4.5.1 GLO INITIATED REKEY REQUESTS................................54
4.5.2 GLA INITIATED REKEY REQUESTS................................54 4.5.2 GLA INITIATED REKEY REQUESTS................................56
4.6 CHANGE GLO....................................................54 4.6 CHANGE GLO....................................................57
4.7 INDICATE KEK COMPROMISE.......................................56 4.7 INDICATE KEK COMPROMISE.......................................60
4.7.1 GL MEMBER INITIATED KEK COMPROMISE MESSAGE..................57 4.7.1 GL MEMBER INITIATED KEK COMPROMISE MESSAGE..................60
4.7.2 GLO INITIATED KEK COMPROMISE MESSAGE........................58 4.7.2 GLO INITIATED KEK COMPROMISE MESSAGE........................61
4.8 REQUEST KEK REFRESH...........................................59 4.8 REQUEST KEK REFRESH...........................................63
4.9 GLA QUERY REQUEST AND RESPONSE................................60 4.9 GLA QUERY REQUEST AND RESPONSE................................64
4.10 UPDATE MEMBER CERTIFICATE....................................62 4.10 UPDATE MEMBER CERTIFICATE....................................66
4.10.1 GLO AND GLA INITIATED UPDATE MEMBER CERTIFICATE............62 4.10.1 GLO AND GLA INITIATED UPDATE MEMBER CERTIFICATE............67
4.10.2 GL MEMBER INITIATED UPDATE MEMBER CERTIFICATE..............64 4.10.2 GL MEMBER INITIATED UPDATE MEMBER CERTIFICATE..............69
5 DISTRIBUTION MESSAGE............................................65 5 DISTRIBUTION MESSAGE............................................70
5.1 DISTRIBUTION PROCESS..........................................66 5.1 DISTRIBUTION PROCESS..........................................71
6 ALGORITHMS......................................................67 6 ALGORITHMS......................................................72
6.1 KEK GENERATION ALGORITHM......................................67 6.1 KEK GENERATION ALGORITHM......................................72
6.2 SHARED KEK WRAP ALGORITHM.....................................67 6.2 SHARED KEK WRAP ALGORITHM.....................................72
6.3 SHARED KEK ALGORITHM..........................................67 6.3 SHARED KEK ALGORITHM..........................................72
7 MESSAGE TRANSPORT...............................................68 7 MESSAGE TRANSPORT...............................................73
8 SECURITY CONSIDERATIONS.........................................68 8 SECURITY CONSIDERATIONS.........................................73
9 REFERENCES......................................................69 9 REFERENCES......................................................74
10 ACKNOWLEDGEMENTS...............................................69 9.1 INFORMATIVE...................................................74
11 AUTHOR'S ADDRESSES.............................................70 9.1 NORMATIVE.....................................................74
ANNEX A: ASN.1 MODULE.............................................71 10 ACKNOWLEDGEMENTS...............................................75
11 AUTHOR'S ADDRESSES.............................................75
ANNEX A: ASN.1 MODULE.............................................76
1 Introduction 1 Introduction
With the ever-expanding use of secure electronic communications With the ever-expanding use of secure electronic communications
(e.g., S/MIME [2]), users require a mechanism to distribute (e.g., S/MIME [MSG]), users require a mechanism to distribute
encrypted data to multiple recipients (i.e., a group of users). encrypted data to multiple recipients (i.e., a group of users).
There are essentially two ways to encrypt the data for recipients: There are essentially two ways to encrypt the data for recipients:
using asymmetric algorithms with public key certificates (PKCs) or using asymmetric algorithms with public key certificates (PKCs) or
symmetric algorithms with symmetric keys. symmetric algorithms with symmetric keys.
With asymmetric algorithms, the originator forms an originator- With asymmetric algorithms, the originator forms an originator-
determined content-encryption key (CEK) and encrypts the content, determined content-encryption key (CEK) and encrypts the content,
using a symmetric algorithm. Then, using an asymmetric algorithm and using a symmetric algorithm. Then, using an asymmetric algorithm and
the recipient's PKCs, the originator generates per-recipient the recipient's PKCs, the originator generates per-recipient
information that either (a) encrypts the CEK for a particular information that either (a) encrypts the CEK for a particular
recipient (ktri RecipientInfo CHOICE), or (b) transfers sufficient recipient (ktri RecipientInfo CHOICE), or (b) transfers sufficient
parameters to enable a particular recipient to independently parameters to enable a particular recipient to independently
generate the same KEK (kari RecipientInfo CHOICE). If the group is generate the same KEK (kari RecipientInfo CHOICE). If the group is
large, processing of the per-recipient information may take quite large, processing of the per-recipient information may take quite
some time, not to mention the time required to collect and validate some time, not to mention the time required to collect and validate
the PKCs for each of the recipients. Each recipient identifies its the PKCs for each of the recipients. Each recipient identifies its
per-recipient information and uses the private key associated with per-recipient information and uses the private key associated with
the public key of its PKC to decrypt the CEK and hence gain access the public key of its PKC to decrypt the CEK and hence gain access
to the encrypted content. to the encrypted content.
Turner Expires June 2003 3
And Distribution
With symmetric algorithms, the origination process is slightly With symmetric algorithms, the origination process is slightly
different. Instead of using PKCs, the originator uses a previously different. Instead of using PKCs, the originator uses a previously
distributed secret key-encryption key (KEK) to encrypt the CEK distributed secret key-encryption key (KEK) to encrypt the CEK
Turner 3
And Distribution
(kekri RecipientInfo CHOICE). Only one copy of the encrypted CEK is (kekri RecipientInfo CHOICE). Only one copy of the encrypted CEK is
required because all the recipients already have the shared KEK required because all the recipients already have the shared KEK
needed to decrypt the CEK and hence gain access to the encrypted needed to decrypt the CEK and hence gain access to the encrypted
content. content.
These techniques to protect the shared KEK are beyond the scope of The techniques to protect the shared KEK are beyond the scope of
this document. Only the members of the list and the key manager this document. Only the members of the list and the key manager
should have the KEK in order to maintain confidentiality. Access should have the KEK in order to maintain confidentiality. Access
control to the information protected by the KEK is determined by the control to the information protected by the KEK is determined by the
entity that encrypts the information, as all members of the group entity that encrypts the information, as all members of the group
have access. If the entity that is performing the encryption wants have access. If the entity that is performing the encryption wants
to ensure some subset of the group does not gain access to the to ensure some subset of the group does not gain access to the
information either a different KEK should be used (shared only with information either a different KEK should be used (shared only with
this smaller group) or asymmetric algorithms should be used. this smaller group) or asymmetric algorithms should be used.
1.1 Applicability to E-mail 1.1 Applicability to E-mail
skipping to change at line 209 skipping to change at line 210
encrypted with a symmetric key algorithm, anyone with the shared KEK encrypted with a symmetric key algorithm, anyone with the shared KEK
and access to that object can then decrypt that object. The and access to that object can then decrypt that object. The
encrypted object and the encrypted, shared KEK can be stored in the encrypted object and the encrypted, shared KEK can be stored in the
repository. repository.
1.3 Using the Group Key 1.3 Using the Group Key
This document was written with three specific scenarios in mind: two This document was written with three specific scenarios in mind: two
supporting mail list agents and one for general message supporting mail list agents and one for general message
distribution. Scenario 1 depicts the originator sending a public key distribution. Scenario 1 depicts the originator sending a public key
(PK) protected message to a MLA who then uses the shared KEK (S) to
redistribute the message to the members of the list. Scenario 2
depicts the originator sending a shared KEK protected message to a
Turner 4 Turner Expires June 2003 4
And Distribution And Distribution
(PK) protected message to a MLA who then uses the shared KEK(s) to
redistribute the message to the members of the list. Scenario 2
depicts the originator sending a shared KEK protected message to a
MLA who then redistributes the message to the members of the list MLA who then redistributes the message to the members of the list
(the MLA only adds additional recipients). The key used by the (the MLA only adds additional recipients). The key used by the
originator could either be a key shared amongst all recipients or originator could either be a key shared amongst all recipients or
just between the member and the MLA. Note that if the originator use just between the member and the MLA. Note that if the originator use
a key shared only with the MLA, then the MLA will need to decrypt a key shared only with the MLA, then the MLA will need to decrypt
the message and rencrypt the message for the list recipients. the message and rencrypt the message for the list recipients.
Scenario 3 shows an originator sending a shared KEK protected Scenario 3 shows an originator sending a shared KEK protected
message to a group of recipients without an intermediate MLA. message to a group of recipients without an intermediate MLA.
+----> +----> +----> +----> +----> +---->
skipping to change at line 264 skipping to change at line 265
| +------------------------+ | | +------------------------+ |
+----------------------------------------------+ +----------------------------------------------+
/ | \ / | \
/ | \ / | \
+----------+ +---------+ +----------+ +----------+ +---------+ +----------+
| Member 1 | | ... | | Member n | | Member 1 | | ... | | Member n |
+----------+ +---------+ +----------+ +----------+ +---------+ +----------+
Figure 1 - Key Distribution Architecture Figure 1 - Key Distribution Architecture
A GLA may support multiple KMAs. A GLA in general supports only one Turner Expires June 2003 5
GMA, but the GMA may support multiple GLs. Multiple KMAs may support
Turner 5
And Distribution And Distribution
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 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. particular KMA to a GL is beyond the scope of this document.
Modeling real world GL implementations shows that there are very Modeling real world GL implementations shows that there are very
restrictive GLs, where a human determines GL membership, and very restrictive GLs, where a human determines GL membership, and very
open GLs, where there are no restrictions on GL membership. To open GLs, where there are no restrictions on GL membership. To
support this spectrum, the mechanism described herein supports both support this spectrum, the mechanism described herein supports both
managed (i.e., where access control is applied) and unmanaged (i.e., managed (i.e., where access control is applied) and unmanaged (i.e.,
where no access control is applied) GLs. The access control where no access control is applied) GLs. The access control
mechanism for managed lists is beyond the scope of this document. mechanism for managed lists is beyond the scope of this document.
skipping to change at line 318 skipping to change at line 318
should be noted that corrupt GLA can always cause havoc. should be noted that corrupt GLA can always cause havoc.
3 Protocol Interactions 3 Protocol Interactions
There are existing mechanisms (e.g., listserv and majordomo) to There are existing mechanisms (e.g., listserv and majordomo) to
manage GLs; however, this document does not address securing these manage GLs; however, this document does not address securing these
mechanisms, as they are not standardized. Instead, it defines mechanisms, as they are not standardized. Instead, it defines
protocol interactions, as depicted in Figure 2, used by the GL protocol interactions, as depicted in Figure 2, used by the GL
members, GLA, and GLO(s) to manage GLs and distribute shared KEKs. members, GLA, and GLO(s) to manage GLs and distribute shared KEKs.
The interactions have been divided into administration messages and 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, request a group rekey,
Turner 6 Turner Expires June 2003 6
And Distribution And Distribution
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, request a group rekey,
add owners to the GL, remove owners of the GL, indicate a group key add owners to the GL, remove owners of the GL, indicate a group key
compromise, refresh a group key, interrogate the GLA, and update compromise, refresh a group key, interrogate the GLA, and update
member's and owner's public key certificates. The distribution member's and owner's public key certificates. The distribution
messages are the messages that distribute the shared KEKs. The messages are the messages that distribute the shared KEKs. The
following sections describe the ASN.1 for both the administration following sections describe the ASN.1 for both the administration
and distribution messages. Section 4 describes how to use the and distribution messages. Section 4 describes how to use the
administration messages, and section 5 describes how to use the administration messages, and section 5 describes how to use the
distribution messages. distribution messages.
+-----+ +----------+ +-----+ +----------+
skipping to change at line 348 skipping to change at line 348
+-----+ <------+ | +----------+ +-----+ <------+ | +----------+
| GLA | <-------------+----> | ... | | GLA | <-------------+----> | ... |
+-----+ | +----------+ +-----+ | +----------+
| |
| +----------+ | +----------+
+----> | Member n | +----> | Member n |
+----------+ +----------+
Figure 2 - Protocol Interactions Figure 2 - Protocol Interactions
Turner 7 Turner Expires June 2003 7
And Distribution And Distribution
3.1 Control Attributes 3.1 Control Attributes
To avoid creating an entirely new protocol, the Certificate To avoid creating an entirely new protocol, the Certificate
Management Messages over CMS (CMC) protocol was chosen as the Management Messages over CMS (CMC) protocol was chosen as the
foundation of this protocol. The main reason for the choice was the foundation of this protocol. The main reason for the choice was the
layering aspect provided by CMC where one or more control attributes layering aspect provided by CMC where one or more control attributes
are included in message, protected with CMS, to request or respond are included in message, protected with CMS, to request or respond
to a desired action. The CMC PKIData structure is used for requests, to a desired action. The CMC PKIData structure is used for requests,
skipping to change at line 394 skipping to change at line 394
following meanings: O for originate, R for receive, and F for following meanings: O for originate, R for receive, and F for
forward. There are three types of implementations: GLOs, GLAs, and forward. There are three types of implementations: GLOs, GLAs, and
GL members. The GLO is an optional component hence all GLO O and GLO 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 R messages are optional, and GLA F messages are optional. The first
table includes messages that conformant implementions MUST support. table includes messages that conformant implementions MUST support.
The second table includes messages that MAY be implemented. The The second table includes messages that MAY be implemented. The
second table should be interpreted as follows: if the control second table should be interpreted as follows: if the control
attribute is implemented by a component then it must be implemented attribute is implemented by a component then it must be implemented
as indicated. For example, if a GLA is implemented that supports the as indicated. For example, if a GLA is implemented that supports the
glAddMember control attribute, then it MUST support receiving the glAddMember control attribute, then it MUST support receiving the
glAddMember message. Note that - means not applicable. glAddMember message. Note that "-" means not applicable.
Turner 8 Turner Expires June 2003 8
And Distribution And Distribution
Required Required
Implementation Requirement | Control Implementation Requirement | Control
GLO | GLA | GL Member | Attribute GLO | GLA | GL Member | Attribute
O R | O R F | O R | O R | O R F | O R |
------- | ----------------- | --------- | ---------- ------- | ----------------- | --------- | ----------
MAY - | MUST - MAY | - MUST | glProvideCert MAY - | MUST - MAY | - MUST | glProvideCert
MAY MAY | - MUST MAY | MUST - | glUpdateCert MAY MAY | - MUST MAY | MUST - | glUpdateCert
- - | MUST - - | - MUST | glKey - - | MUST - - | - MUST | glKey
skipping to change at line 444 skipping to change at line 444
The GLO uses glUseKEK to request that a shared KEK be assigned to a 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 GL. glUseKEK messages MUST be signed by the GLO. The glUseKEK
control attribute has the syntax GLUseKEK: control attribute has the syntax GLUseKEK:
GLUseKEK ::= SEQUENCE { GLUseKEK ::= SEQUENCE {
glInfo GLInfo, glInfo GLInfo,
glOwnerInfo SEQUENCE SIZE (1..MAX) OF GLOwnerInfo, glOwnerInfo SEQUENCE SIZE (1..MAX) OF GLOwnerInfo,
glAdministration GLAdministration DEFAULT 1, glAdministration GLAdministration DEFAULT 1,
glKeyAttributes GLKeyAttributes OPTIONAL } glKeyAttributes GLKeyAttributes OPTIONAL }
Turner 9 Turner Expires June 2003 9
And Distribution And Distribution
GLInfo ::= SEQUENCE { GLInfo ::= SEQUENCE {
glName GeneralName, glName GeneralName,
glAddress GeneralName } glAddress GeneralName }
GLOwnerInfo ::= SEQUENCE { GLOwnerInfo ::= SEQUENCE {
glOwnerName GeneralName, glOwnerName GeneralName,
glOwnerAddress GeneralName, glOwnerAddress GeneralName,
certificate Certificates OPTIONAL } certificate Certificates OPTIONAL }
Certificates ::= SEQUENCE { Certificates ::= SEQUENCE {
pKC [0] Certificate OPTIONAL, pKC [0] Certificate OPTIONAL,
-- See PKIX [5] -- See [PROFILE]
aC [1] SEQUENCE SIZE (1.. MAX) OF aC [1] SEQUENCE SIZE (1.. MAX) OF
AttributeCertificate OPTIONAL, AttributeCertificate OPTIONAL,
-- See ACPROF [6] -- See [ACPROF]
certPath [2] CertificateSet OPTIONAL } certPath [2] CertificateSet OPTIONAL }
-- From CMS [2] -- From [CMS]
-- CertificateSet and CertificateChoices are included only -- CertificateSet and CertificateChoices are included only
-- for illustrative purposes as they are imported from CMS [2]. -- for illustrative purposes as they are imported from [CMS].
CertificateSet ::= SET SIZE (1..MAX) OF CertificateChoices CertificateSet ::= SET SIZE (1..MAX) OF CertificateChoices
-- CertificateChoices supports X.509 public key certificates in -- CertificateChoices supports X.509 public key certificates in
-- certificates and v2 attribute certificates in v2AttrCert. -- certificates and v2 attribute certificates in v2AttrCert.
GLAdministration ::= INTEGER { GLAdministration ::= INTEGER {
unmanaged (0), unmanaged (0),
managed (1), managed (1),
closed (2) } closed (2) }
skipping to change at line 499 skipping to change at line 499
the GL in glAddress. The glName and glAddress can be the same, 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 but this is not always the case. Both the name and address MUST
be unique for a given GLA. be unique for a given GLA.
- glOwnerInfo indicates: - glOwnerInfo indicates:
- glOwnerName indicates the name of the owner of the GL. One of - glOwnerName indicates the name of the owner of the GL. One of
the names in glOwnerName MUST match one of the names in the the names in glOwnerName MUST match one of the names in the
certificate (either the subject distinguished name or one of certificate (either the subject distinguished name or one of
Turner 10 Turner Expires June 2003 10
And Distribution And Distribution
the subject alternative names) used to sign this the subject alternative names) used to sign this
SignedData.PKIData creating the GL (i.e., the immediate SignedData.PKIData creating the GL (i.e., the immediate
signer). signer).
- glOwnerAddress indicates the address of the owner of the GL. - glOwnerAddress indicates the address of the owner of the GL.
- certificates MAY be included. It contains the following three - certificates MAY be included. It contains the following three
fields: fields:
- certificates.pKC includes the encryption certificate for the - certificates.pKC includes the encryption certificate for the
GLO. It will be used to encrypt responses for the GLO. GLO. It will be used to encrypt responses for the GLO.
- certificates.aC MAY be included to convey any attribute - certificates.aC MAY be included to convey any attribute
certificate (see AC Profile [6]) associated with the certificate (see [ACPROF]) associated with the encryption
encryption certificate of the GLO included in certificate of the GLO included in certificates.pKC.
certificates.pKC.
- certificates.certPath MAY also be included to convey - certificates.certPath MAY also be included to convey
certificates that might aid the recipient in constructing certificates that might aid the recipient in constructing
valid certification paths for the certificate provided in valid certification paths for the certificate provided in
certificates.pKC and the attribute certificates provided in certificates.pKC and the attribute certificates provided in
certificates.aC. Theses certificates are optional because certificates.aC. Theses certificates are optional because
they might already be included elsewhere in the message they might already be included elsewhere in the message
(e.g., in the outer CMS layer). (e.g., in the outer CMS layer).
- glAdministration indicates how the GL ought to be administered. - glAdministration indicates how the GL ought to be administered.
skipping to change at line 555 skipping to change at line 554
- glKeyAttributes indicates the attributes the GLO wants the GLA - glKeyAttributes indicates the attributes the GLO wants the GLA
to assign to the shared KEK. If this field is omitted, GL rekeys to assign to the shared KEK. If this field is omitted, GL rekeys
will be controlled by the GLA, the recipients are allowed to will be controlled by the GLA, the recipients are allowed to
know about one another, the algorithm will be Triple-DES (see know about one another, the algorithm will be Triple-DES (see
paragrpah 7), the shared KEK will be valid for a calendar month paragrpah 7), the shared KEK will be valid for a calendar month
(i.e., first of the month until the last day of the month), and (i.e., first of the month until the last day of the month), and
two shared KEKs will be distributed initially. The fields in two shared KEKs will be distributed initially. The fields in
glKeyAttributes have the following meaning: glKeyAttributes have the following meaning:
Turner 11 Turner Expires June 2003 11
And Distribution And Distribution
- rekeyControlledByGLO indicates whether the GL rekey messages - rekeyControlledByGLO indicates whether the GL rekey messages
will be generated by the GLO or by the GLA. The default is for 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 the GLA to control rekeys. If GL rekey is controlled by the
GLA, the GL will continue to be rekeyed until the GLO deletes GLA, the GL will continue to be rekeyed until the GLO deletes
the GL or changes the GL rekey to be GLO controlled. the GL or changes the GL rekey to be GLO controlled.
- recipientsNotMutuallyAware indicates that the GLO wants the - recipientsNotMutuallyAware indicates that the GLO wants the
GLA to distribute the shared KEK individually for each of the GLA to distribute the shared KEK individually for each of the
skipping to change at line 608 skipping to change at line 607
distributed. The second shared KEK is distributed with the distributed. The second shared KEK is distributed with the
first shared KEK, so that when the first shared KEK is no first shared KEK, so that when the first shared KEK is no
longer valid the second key can be used. If the GLA controls longer valid the second key can be used. If the GLA controls
rekey then it also indicates the number of shared KEKs the GLO 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 wants outstanding at any one time. See sections 4.5 and 5 for
more on rekey. more on rekey.
- requestedAlgorithm indicates the algorithm and any parameters - requestedAlgorithm indicates the algorithm and any parameters
the GLO wants the GLA to use with the shared KEK. The the GLO wants the GLA to use with the shared KEK. The
parameters are conveyed via the SMIMECapabilities attribute parameters are conveyed via the SMIMECapabilities attribute
(see MSG [7]). See section 6 for more on algorithms. (see [MSG]). See section 6 for more on algorithms.
Turner 12 Turner Expires June 2003 12
And Distribution And Distribution
3.1.2 Delete GL 3.1.2 Delete GL
GLOs use glDelete to request that a GL be deleted from the GLA. The GLOs use glDelete to request that a GL be deleted from the GLA. The
glDelete control attribute has the syntax GeneralName. The glDelete glDelete control attribute has the syntax GeneralName. The glDelete
message MUST be signed by the GLO. The name of the GL to be deleted message MUST be signed by the GLO. The name of the GL to be deleted
is included in GeneralName: is included in GeneralName:
DeleteGL ::= GeneralName DeleteGL ::= GeneralName
skipping to change at line 641 skipping to change at line 640
glName GeneralName, glName GeneralName,
glMember GLMember } glMember GLMember }
GLMember ::= SEQUENCE { GLMember ::= SEQUENCE {
glMemberName GeneralName, glMemberName GeneralName,
glMemberAddress GeneralName OPTIONAL, glMemberAddress GeneralName OPTIONAL,
certificates Certificates OPTIONAL } certificates Certificates OPTIONAL }
Certificates ::= SEQUENCE { Certificates ::= SEQUENCE {
pKC [0] Certificate OPTIONAL, pKC [0] Certificate OPTIONAL,
-- See PKIX [5] -- See [PROFILE]
aC [1] SEQUENCE SIZE (1.. MAX) OF aC [1] SEQUENCE SIZE (1.. MAX) OF
AttributeCertificate OPTIONAL, AttributeCertificate OPTIONAL,
-- See ACPROF [6] -- See [ACPROF]
certPath [2] CertificateSet OPTIONAL } certPath [2] CertificateSet OPTIONAL }
-- From CMS [2] -- From [CMS]
-- CertificateSet and CertificateChoices are included only -- CertificateSet and CertificateChoices are included only
-- for illustrative purposes as they are imported from CMS [2]. -- for illustrative purposes as they are imported from [CMS].
CertificateSet ::= SET SIZE (1..MAX) OF CertificateChoices CertificateSet ::= SET SIZE (1..MAX) OF CertificateChoices
-- CertificateChoices supports X.509 public key certificates in -- CertificateChoices supports X.509 public key certificates in
-- certificates and v2 attribute certificates in v2AttrCert. -- certificates and v2 attribute certificates in v2AttrCert.
The fields in GLAddMembers have the following meaning: The fields in GLAddMembers have the following meaning:
- glName indicates the name of the GL to which the member should - glName indicates the name of the GL to which the member should
be added. be added.
Turner 13
And Distribution
- glMember indicates the particulars for the GL member. Both of - glMember indicates the particulars for the GL member. Both of
the following fields must be unique for a given GL: the following fields must be unique for a given GL:
Turner Expires June 2003 13
And Distribution
- glMemberName indicates the name of the GL member. - glMemberName indicates the name of the GL member.
- glMemberAddress indicates the GL member's address. It MUST be - glMemberAddress indicates the GL member's address. It MUST be
included. included.
Note: In some instances the glMemberName and glMemberAddress Note: In some instances the glMemberName and glMemberAddress
may be the same, but this is not always the case. may be the same, but this is not always the case.
- certificates MUST be included. It contains the following three - certificates MUST be included. It contains the following three
fields: fields:
- certificates.pKC includes the member's encryption - certificates.pKC includes the member's encryption
certificate. It will be used, at least initially, to encrypt certificate. It will be used, at least initially, to encrypt
the shared KEK for that member. If the message is generated the shared KEK for that member. If the message is generated
by a prospective GL member, the pKC MUST be included. If the by a prospective GL member, the pKC MUST be included. If the
message is generated by a GLO, the pKC SHOULD be included. message is generated by a GLO, the pKC SHOULD be included.
- certificates.aC MAY be included to convey any attribute - certificates.aC MAY be included to convey any attribute
certificate (see AC Profile [6]) associated with the certificate (see [ACPROF]) associated with the member's
member's encryption certificate. encryption certificate.
- certificates.certPath MAY also be included to convey - certificates.certPath MAY also be included to convey
certificates that might aid the recipient in constructing certificates that might aid the recipient in constructing
valid certification paths for the certificate provided in valid certification paths for the certificate provided in
certificates.pKC and the attribute certificates provided in certificates.pKC and the attribute certificates provided in
certificates.aC. These certificates are optional because certificates.aC. These certificates are optional because
they might already be included elsewhere in the message they might already be included elsewhere in the message
(e.g., in the outer CMS layer). (e.g., in the outer CMS layer).
3.1.4 Delete GL Member 3.1.4 Delete GL Member
skipping to change at line 713 skipping to change at line 712
GLDeleteMember ::= SEQUENCE { GLDeleteMember ::= SEQUENCE {
glName GeneralName, glName GeneralName,
glMemberToDelete GeneralName } glMemberToDelete GeneralName }
The fields in GLDeleteMembers have the following meaning: The fields in GLDeleteMembers have the following meaning:
- glName indicates the name of the GL from which the member should - glName indicates the name of the GL from which the member should
be removed. be removed.
Turner 14
And Distribution
- glMemberToDelete indicates the name or address of the member to - glMemberToDelete indicates the name or address of the member to
be deleted. be deleted.
Turner Expires June 2003 14
And Distribution
3.1.5 Rekey GL 3.1.5 Rekey GL
GLOs use the glRekey to request a GL rekey. The glRekey message MUST 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 be signed by the GLO. The glRekey control attribute has the syntax
GLRekey: GLRekey:
GLRekey ::= SEQUENCE { GLRekey ::= SEQUENCE {
glName GeneralName, glName GeneralName,
glAdministration GLAdministration OPTIONAL, glAdministration GLAdministration OPTIONAL,
glNewKeyAttributes GLNewKeyAttributes OPTIONAL, glNewKeyAttributes GLNewKeyAttributes OPTIONAL,
skipping to change at line 758 skipping to change at line 757
controlled by the GLA or GL, what algorithm and parameters the controlled by the GLA or GL, what algorithm and parameters the
GLO wishes to use, the duration of the key, and how many keys 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 will be issued. The field is only included if there is a change
from the previously registered glKeyAttributes. from the previously registered glKeyAttributes.
- glRekeyAllGLKeys indicates whether the GLO wants all of the - glRekeyAllGLKeys indicates whether the GLO wants all of the
outstanding GL's shared KEKs rekeyed. If it is set to TRUE then 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 MUST be issued. If it is set to FALSE then
all outstanding KEKs need not be resissued. all outstanding KEKs need not be resissued.
Turner 15
And Distribution
3.1.6 Add GL Owner 3.1.6 Add GL Owner
GLOs use the glAddOwner to request that a new GLO be allowed to GLOs use the glAddOwner to request that a new GLO be allowed to
administer the GL. The glAddOwner message MUST be signed by a administer the GL. The glAddOwner message MUST be signed by a
registered GLO. The glAddOwner control attribute has the syntax registered GLO. The glAddOwner control attribute has the syntax
GLOwnerAdministration: GLOwnerAdministration:
GLOwnerAdministration ::= SEQUENCE { GLOwnerAdministration ::= SEQUENCE {
glName GeneralName, glName GeneralName,
glOwnerInfo GLOwnerInfo } glOwnerInfo GLOwnerInfo }
Turner Expires June 2003 15
And Distribution
The fields in GLAddOwners have the following meaning: The fields in GLAddOwners have the following meaning:
- glName indicates the name of the GL to which the new GLO should - glName indicates the name of the GL to which the new GLO should
be associated. be associated.
- glOwnerInfo indicates the name, address, and certificates of the - glOwnerInfo indicates the name, address, and certificates of the
new GLO. As this message includes names of new GLOs, the new GLO. As this message includes names of new GLOs, the
certificates.pKC MUST be included, and it MUST include the certificates.pKC MUST be included, and it MUST include the
encryption certificate of the new GLO. encryption certificate of the new GLO.
skipping to change at line 802 skipping to change at line 801
The fields in GLRemoveOwners have the following meaning: The fields in GLRemoveOwners have the following meaning:
- glName indicates the name of the GL to which the GLO should be - glName indicates the name of the GL to which the GLO should be
disassociated. disassociated.
- glOwnerInfo indicates the name and address of the GLO to be - glOwnerInfo indicates the name and address of the GLO to be
removed. The certificates field SHOULD be omitted, as it will be removed. The certificates field SHOULD be omitted, as it will be
ignored. ignored.
Turner 16
And Distribution
3.1.8 GL Key Compromise 3.1.8 GL Key Compromise
GL members and GLOs use glkCompromise to indicate that the shared GL members and GLOs use glkCompromise to indicate that the shared
KEK possessed has been compromised. The glKeyCompromise control KEK possessed has been compromised. The glKeyCompromise control
attribute has the syntax GeneralName. This message is always attribute has the syntax GeneralName. This message is always
redirected by the GLA to the GLO for further action. The redirected by the GLA to the GLO for further action. The
glkCompromise MAY be included in an EnvelopedData generated with the glkCompromise MAY be included in an EnvelopedData generated with the
compromised shared KEK. The name of the GL to which the compromised compromised shared KEK. The name of the GL to which the compromised
key is associated with is placed in GeneralName: key is associated with is placed in GeneralName:
GLKCompromise ::= GeneralName GLKCompromise ::= GeneralName
3.1.9 GL Key Refresh 3.1.9 GL Key Refresh
GL members use the glkRefresh to request that the shared KEK be GL members use the glkRefresh to request that the shared KEK be
redistributed to them. The glkRefresh control attribute has the redistributed to them. The glkRefresh control attribute has the
syntax GLKRefresh. syntax GLKRefresh.
Turner Expires June 2003 16
And Distribution
GLKRefresh ::= SEQUENCE { GLKRefresh ::= SEQUENCE {
glName GeneralName, glName GeneralName,
dates SEQUENCE SIZE (1..MAX) OF Date } dates SEQUENCE SIZE (1..MAX) OF Date }
Date ::= SEQUENCE { Date ::= SEQUENCE {
start GeneralizedTime, start GeneralizedTime,
end GeneralizedTime OPTIONAL } end GeneralizedTime OPTIONAL }
The fields in GLKRefresh have the following meaning: The fields in GLKRefresh have the following meaning:
skipping to change at line 854 skipping to change at line 853
3.1.10 GLA Query Request and Response 3.1.10 GLA Query Request and Response
There are situations where GLOs and GL members may need to determine 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 some information from the GLA about the GL. GLOs and GL members use
the glaQueryRequest, defined in section 3.1.10.1, to request the glaQueryRequest, defined in section 3.1.10.1, to request
information and GLAs use the glaQueryResponse, defined in section information and GLAs use the glaQueryResponse, defined in section
3.1.10.2, to return the requested information. Section 3.1.10.3 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 includes one request and response type and value; others may be
defined in additional documents. defined in additional documents.
Turner 17
And Distribution
3.1.10.1 GLA Query Request 3.1.10.1 GLA Query Request
GLOs and GL members use the glaQueryRequest to ascertain information GLOs and GL members use the glaQueryRequest to ascertain information
about the GLA. The glaQueryRequest control attribute has the syntax about the GLA. The glaQueryRequest control attribute has the syntax
GLAQueryRequest: GLAQueryRequest:
GLAQueryRequest ::= SEQUENCE { GLAQueryRequest ::= SEQUENCE {
glaRequestType OBJECT IDENTIFIER, glaRequestType OBJECT IDENTIFIER,
glaRequestValue ANY DEFINED BY glaRequestType } glaRequestValue ANY DEFINED BY glaRequestType }
3.1.10.2 GLA Query Response 3.1.10.2 GLA Query Response
GLAs return the glaQueryResponse after receiving a GLAQueryRequest. GLAs return the glaQueryResponse after receiving a GLAQueryRequest.
The glaQueryResponse MUST be signed by a GLA. The glaQueryResponse The glaQueryResponse MUST be signed by a GLA. The glaQueryResponse
control attribute has the syntax GLAQueryResponse: control attribute has the syntax GLAQueryResponse:
Turner Expires June 2003 17
And Distribution
GLAQueryResponse ::= SEQUENCE { GLAQueryResponse ::= SEQUENCE {
glaResponseType OBJECT IDENTIFIER, glaResponseType OBJECT IDENTIFIER,
glaResponseValue ANY DEFINED BY glaResponseType } glaResponseValue ANY DEFINED BY glaResponseType }
3.1.10.3 Request and Response Types 3.1.10.3 Request and Response Types
Request and Responses are registered as a pair under the following Request and Responses are registered as a pair under the following
object identifier arc: object identifier arc:
id-cmc-glaRR OBJECT IDENTIFIER ::= { id-cmc 99 } id-cmc-glaRR OBJECT IDENTIFIER ::= { id-cmc 99 }
skipping to change at line 899 skipping to change at line 898
id-cmc-gla-skdAlgRequest OBJECT IDENTIFIER ::={ id-cmc-glaRR 1 } id-cmc-gla-skdAlgRequest OBJECT IDENTIFIER ::={ id-cmc-glaRR 1 }
SKDAlgRequest ::= NULL SKDAlgRequest ::= NULL
If the GLA supports GLAQueryRequest and GLAQueryResponse messages, If the GLA supports GLAQueryRequest and GLAQueryResponse messages,
the GLA may return the following OID in the glaQueryType field: the GLA may return the following OID in the glaQueryType field:
id-cmc-gla-skdAlgResponse OBJECT IDENTIFIER ::= { id-cmc-glaRR 2 } id-cmc-gla-skdAlgResponse OBJECT IDENTIFIER ::= { id-cmc-glaRR 2 }
The glaQueryValue has the form of the smimeCapabilities attributes The glaQueryValue has the form of the smimeCapabilities attributes
as defined in MSG [7]. as defined in [MSG].
3.1.12 Provide Cert 3.1.12 Provide Cert
GLAs and GLOs use the glProvideCert to request that a GL member GLAs and GLOs use the glProvideCert to request that a GL member
provide an updated or new encryption certificate. The glProvideCert provide an updated or new encryption certificate. The glProvideCert
message MUST be signed by either GLA or GLO. If the GL member's PKC message MUST be signed by either GLA or GLO. If the GL member's PKC
Turner 18
And Distribution
has been revoked, the GLO or GLA MUST NOT use it to generate the has been revoked, the GLO or GLA MUST NOT use it to generate the
EnvelopedData that encapsulates the glProvideCert request. The EnvelopedData that encapsulates the glProvideCert request. The
glProvideCert control attribute has the syntax GLManageCert: glProvideCert control attribute has the syntax GLManageCert:
GLManageCert ::= SEQUENCE { GLManageCert ::= SEQUENCE {
glName GeneralName, glName GeneralName,
glMember GLMember } glMember GLMember }
The fields in GLManageCert have the following meaning: The fields in GLManageCert have the following meaning:
- glName indicates the name of the GL to which the GL member's new - glName indicates the name of the GL to which the GL member's new
certificate is to be associated. certificate is to be associated.
- glMember indicates particulars for the GL member: - glMember indicates particulars for the GL member:
- glMemberName indicates the GL member's name. - glMemberName indicates the GL member's name.
Turner Expires June 2003 18
And Distribution
- glMemberAddress indicates the GL member's address. It MAY be - glMemberAddress indicates the GL member's address. It MAY be
omitted. omitted.
- certificates SHOULD be omitted. - certificates SHOULD be omitted.
3.1.13 Update Cert 3.1.13 Update Cert
GL members and GLOs use the glUpdateCert to provide a new GL members and GLOs use the glUpdateCert to provide a new
certificate for the GL. GL members can generate an unsolicited certificate for the GL. GL members can generate an unsolicited
glUpdateCert or generate a response glUpdateCert as a result of glUpdateCert or generate a response glUpdateCert as a result of
skipping to change at line 959 skipping to change at line 957
- glName indicates the name of the GL to which the GL member's new - glName indicates the name of the GL to which the GL member's new
certificate should be associated. certificate should be associated.
- glMember indicates the particulars for the GL member: - glMember indicates the particulars for the GL member:
- glMemberName indicates the GL member's name. - glMemberName indicates the GL member's name.
- glMemberAddress indicates the GL member's address. It MAY be - glMemberAddress indicates the GL member's address. It MAY be
omitted. omitted.
Turner 19
And Distribution
- certificates MAY be omitted if the GLManageCert message is - certificates MAY be omitted if the GLManageCert message is
sent to request the GL member's certificate; otherwise, it sent to request the GL member's certificate; otherwise, it
MUST be included. It includes the following three fields: MUST be included. It includes the following three fields:
- certificates.pKC includes the member's encryption - certificates.pKC includes the member's encryption
certificate that will be used to encrypt the shared KEK for certificate that will be used to encrypt the shared KEK for
that member. that member.
- certificates.aC MAY be included to convey one or more - certificates.aC MAY be included to convey one or more
attribute certificate associated with the member's attribute certificate associated with the member's
encryption certificate. encryption certificate.
- certificates.certPath MAY also be included to convey - certificates.certPath MAY also be included to convey
certificates that might aid the recipient in constructing certificates that might aid the recipient in constructing
valid certification paths for the certificate provided in valid certification paths for the certificate provided in
certificates.pKC and the attribute certificates provided in certificates.pKC and the attribute certificates provided in
certificates.aC. These certificates is optional because they certificates.aC. These certificates is optional because they
Turner Expires June 2003 19
And Distribution
might already be included elsewhere in the message (e.g., in might already be included elsewhere in the message (e.g., in
the outer CMS layer). the outer CMS layer).
3.1.14 GL Key 3.1.14 GL Key
The GLA uses the glKey to distribute the shared KEK. The glKey The GLA uses the glKey to distribute the shared KEK. The glKey
message MUST be signed by the GLA. The glKey control attribute has message MUST be signed by the GLA. The glKey control attribute has
the syntax GLKey: the syntax GLKey:
GLKey ::= SEQUENCE { GLKey ::= SEQUENCE {
glName GeneralName, glName GeneralName,
glIdentifier KEKIdentifier, -- See CMS [2] glIdentifier KEKIdentifier, -- See [CMS]
glkWrapped RecipientInfos, -- See CMS [2] glkWrapped RecipientInfos, -- See [CMS]
glkAlgorithm AlgorithmIdentifier, glkAlgorithm AlgorithmIdentifier,
glkNotBefore GeneralizedTime, glkNotBefore GeneralizedTime,
glkNotAfter GeneralizedTime } glkNotAfter GeneralizedTime }
-- KEKIdentifier is included only for illustrative purposes as -- KEKIdentifier is included only for illustrative purposes as
-- it is imported from CMS [2]. -- it is imported from [CMS].
KEKIdentifier ::= SEQUENCE { KEKIdentifier ::= SEQUENCE {
keyIdentifier OCTET STRING, keyIdentifier OCTET STRING,
date GeneralizedTime OPTIONAL, date GeneralizedTime OPTIONAL,
other OtherKeyAttribute OPTIONAL } other OtherKeyAttribute OPTIONAL }
The fields in GLKey have the following meaning: The fields in GLKey have the following meaning:
- glName is the name of the GL. - glName is the name of the GL.
- glIdentifier is the key identifier of the shared KEK. See - glIdentifier is the key identifier of the shared KEK. See
paragraph 6.2.3 of CMS [2] for a description of the subfields. paragraph 6.2.3 of [CMS] for a description of the subfields.
Turner 20
And Distribution
- glkWrapped is the wrapped shared KEK for the GL for a particular - glkWrapped is the wrapped shared KEK for the GL for a particular
duration. The RecipientInfos MUST be generated as specified in duration. The RecipientInfos MUST be generated as specified in
section 6.2 of CMS [2]. The ktri RecipientInfo choice MUST be section 6.2 of [CMS]. The ktri RecipientInfo choice MUST be
supported. The key in the EncryptedKey field (i.e., the supported. The key in the EncryptedKey field (i.e., the
distributed shared KEK) MUST be generated according to the distributed shared KEK) MUST be generated according to the
section concerning random number generation in the security section concerning random number generation in the security
considerations of CMS [2]. considerations of [CMS].
- glkAlgorithm identifies the algorithm the shared KEK is used - glkAlgorithm identifies the algorithm the shared KEK is used
with. Since no encrypted data content is being conveyed at this with. Since no encrypted data content is being conveyed at this
point, the parameters encoded with the algorithm should be the point, the parameters encoded with the algorithm should be the
structure defined for smimeCapabilities rather than encrypted structure defined for smimeCapabilities rather than encrypted
content. content.
- glkNotBefore indicates the date at which the shared KEK is - glkNotBefore indicates the date at which the shared KEK is
considered valid. GeneralizedTime values MUST be expressed in considered valid. GeneralizedTime values MUST be expressed in
UTC (Zulu) and MUST include seconds (i.e., times are UTC (Zulu) and MUST include seconds (i.e., times are
Turner Expires June 2003 20
And Distribution
YYYYMMDDHHMMSSZ), even where the number of seconds is zero. YYYYMMDDHHMMSSZ), even where the number of seconds is zero.
GeneralizedTime values MUST NOT include fractional seconds. GeneralizedTime values MUST NOT include fractional seconds.
- glkNotAfter indicates the date after which the shared KEK is - glkNotAfter indicates the date after which the shared KEK is
considered invalid. GeneralizedTime values MUST be expressed in considered invalid. GeneralizedTime values MUST be expressed in
UTC (Zulu) and MUST include seconds (i.e., times are UTC (Zulu) and MUST include seconds (i.e., times are
YYYYMMDDHHMMSSZ), even where the number of seconds is zero. YYYYMMDDHHMMSSZ), even where the number of seconds is zero.
GeneralizedTime values MUST NOT include fractional seconds. GeneralizedTime values MUST NOT include fractional seconds.
If the glKey message is in response to a glUseKEK message: If the glKey message is in response to a glUseKEK message:
skipping to change at line 1065 skipping to change at line 1065
if glRekey.glNewKeyAttributes.recipientsNotMutuallyAware is set if glRekey.glNewKeyAttributes.recipientsNotMutuallyAware is set
to TRUE. to TRUE.
- The GLA MUST generate the requested number of glKey messages. - The GLA MUST generate the requested number of glKey messages.
The value in glUseKEK.glKeyAttributes.generationCounter The value in glUseKEK.glKeyAttributes.generationCounter
indicates the number of glKey messages requested. indicates the number of glKey messages requested.
- The GLA MUST generate one glKey messagefor each outstanding - The GLA MUST generate one glKey messagefor each outstanding
shared KEKs for the GL when glRekeyAllGLKeys is set to TRUE. shared KEKs for the GL when glRekeyAllGLKeys is set to TRUE.
Turner 21
And Distribution
If the glKey message was not in response to a glRekey or glUseKEK If the glKey message was not in response to a glRekey or glUseKEK
(e.g., where the GLA controls rekey): (e.g., where the GLA controls rekey):
- The GLA MUST generate separate glKey messages for each recipient - The GLA MUST generate separate glKey messages for each recipient
when glUseKEK.glNewKeyAttributes.recipientsNotMutuallyAware that when glUseKEK.glNewKeyAttributes.recipientsNotMutuallyAware that
set up the GL was set to TRUE. set up the GL was set to TRUE.
- The GLA MAY generate glKey messages prior to the duration on the - The GLA MAY generate glKey messages prior to the duration on the
last outstanding shared KEK expiring, where the number of glKey last outstanding shared KEK expiring, where the number of glKey
messages generated is generationCounter minus one (1). Other messages generated is generationCounter minus one (1). Other
distribution mechanisms can also be supported to support this distribution mechanisms can also be supported to support this
functionality. functionality.
3.2 Use of CMC, CMS, and PKIX 3.2 Use of CMC, CMS, and PKIX
The following sections outline the use of CMC, CMS, and the PKIX The following sections outline the use of CMC, CMS, and the PKIX
certificate and CRL profile. certificate and CRL profile.
Turner Expires June 2003 21
And Distribution
3.2.1 Protection Layers 3.2.1 Protection Layers
The following sections outline the protection required for the The following sections outline the protection required for the
control attributes defined in this document. control attributes defined in this document.
Note: There are multiple ways to encapsulate SignedData and Note: There are multiple ways to encapsulate SignedData and
EnvelopedData. The first is to use a MIME wrapper around each EnvelopedData. The first is to use a MIME wrapper around each
ContentInfo, as specified in MSG [7]. The second is to not use a ContentInfo, as specified in [MSG]. The second is to not use a MIME
MIME wrapper around each ContentInfo, as specified in Transporting wrapper around each ContentInfo, as specified in Transporting S/MIME
S/MIME Objects in X.400 [8]. Objects in X.400 [X400TRANS].
3.2.1.1 Minimum Protection 3.2.1.1 Minimum Protection
At a minimum, a SignedData MUST protect each request and response At a minimum, a SignedData MUST protect each request and response
encapsulated in PKIData and PKIResponse. The following is a encapsulated in PKIData and PKIResponse. The following is a
depiction of the minimum wrappings: depiction of the minimum wrappings:
Minimum Protection Minimum Protection
------------------ ------------------
SignedData SignedData
PKIData or PKIResponse PKIData or PKIResponse
controlSequence controlSequence
Prior to taking any action on any request or response SignedData(s) Prior to taking any action on any request or response SignedData(s)
MUST be processed according to CMS [2]. MUST be processed according to [CMS].
Turner 22
And Distribution
3.2.1.2 Additional Protection 3.2.1.2 Additional Protection
An additional EnvelopedData MAY also be used to provide An additional EnvelopedData MAY also be used to provide
confidentiality of the request and response. An additional confidentiality of the request and response. An additional
SignedData MAY also be added to provide authentication and integrity SignedData MAY also be added to provide authentication and integrity
of the encapsulated EnvelopedData. The following is a depiction of of the encapsulated EnvelopedData. The following is a depiction of
the optional additional wrappings: the optional additional wrappings:
Authentication and Integrity Authentication and Integrity
Confidentiality Protection of Confidentiality Protection Confidentiality Protection of Confidentiality Protection
-------------------------- ----------------------------- -------------------------- -----------------------------
EnvelopedData SignedData EnvelopedData SignedData
SignedData EnvelopedData SignedData EnvelopedData
PKIData or PKIResponse SignedData PKIData or PKIResponse SignedData
controlSequence PKIData or PKIResponse controlSequence PKIData or PKIResponse
controlSequence controlSequence
If an incoming message is encrypted, the confidentiality of the If an incoming message is encrypted, the confidentiality of the
message MUST be preserved. All EnvelopedData objects MUST be message MUST be preserved. All EnvelopedData objects MUST be
processed as specified in CMS [2]. If a SignedData is added over an processed as specified in [CMS]. If a SignedData is added over an
Turner Expires June 2003 22
And Distribution
EnvelopedData, a ContentHints attribute SHOULD be added. See EnvelopedData, a ContentHints attribute SHOULD be added. See
paragraph 2.9 of Extended Security Services for S/MIME [9]. paragraph 2.9 of Extended Security Services for S/MIME [ESS].
If the GLO or GL member applies confidentiality to a request, the If the GLO or GL member applies confidentiality to a request, the
EnvelopedData MUST include the GLA as a recipient. If the GLA EnvelopedData MUST include the GLA as a recipient. If the GLA
forwards the GL member request to the GLO, then the GLA MUST decrypt forwards the GL member request to the GLO, then the GLA MUST decrypt
the EnvelopedData content, strip the confidentiality layer, and the EnvelopedData content, strip the confidentiality layer, and
apply its own confidentiality layer as an EnvelopedData with the GLO apply its own confidentiality layer as an EnvelopedData with the GLO
as a recipient. as a recipient.
Turner 23
And Distribution
3.2.2 Combining Requests and Responses 3.2.2 Combining Requests and Responses
Multiple requests and response corresponding to a GL MAY be included Multiple requests and response corresponding to a GL MAY be included
in one PKIData.controlSequence or PKIResponse.controlSequence. in one PKIData.controlSequence or PKIResponse.controlSequence.
Requests and responses for multiple GLs MAY be combined in one Requests and responses for multiple GLs MAY be combined in one
PKIData or PKIResponse by using PKIData.cmsSequence and PKIData or PKIResponse by using PKIData.cmsSequence and
PKIResponse.cmsSequence. A separate cmsSequence MUST be used for PKIResponse.cmsSequence. A separate cmsSequence MUST be used for
different GLs. That is, requests corresponding to two different GLs different GLs. That is, requests corresponding to two different GLs
are included in different cmsSequences. The following is a diagram are included in different cmsSequences. The following is a diagram
depicting multiple requests and responses combined in one PKIData depicting multiple requests and responses combined in one PKIData
skipping to change at line 1177 skipping to change at line 1175
PKIData PKIResponse PKIData PKIResponse
controlSequence controlSequence controlSequence controlSequence
One or more requests One or more responses One or more requests One or more responses
corresponding to one GL corresponding to one GL corresponding to one GL corresponding to one GL
SignedData SignedData SignedData SignedData
PKIData PKIResponse PKIData PKIResponse
controlSequence controlSequence controlSequence controlSequence
One or more requests One or more responses One or more requests One or more responses
corresponding to another GL corresponding to another GL corresponding to another GL corresponding to another GL
Turner Expires June 2003 23
And Distribution
When applying confidentiality to multiple requests and responses, When applying confidentiality to multiple requests and responses,
all of the requests/response MAY be included in one EnvelopedData. all of the requests/response MAY be included in one EnvelopedData.
The following is a depiction: The following is a depiction:
Confidentiality of Multiple Requests and Responses Confidentiality of Multiple Requests and Responses
Wrapped Together Wrapped Together
---------------- ----------------
EnvelopedData EnvelopedData
SignedData SignedData
PKIData PKIData
skipping to change at line 1199 skipping to change at line 1200
PKIResponse PKIResponse
controlSequence controlSequence
One or more requests One or more requests
corresponding to one GL corresponding to one GL
SignedData SignedData
PKIData PKIData
controlSequence controlSequence
One or more requests One or more requests
corresponding to one GL corresponding to one GL
Turner 24
And Distribution
Certain combinations of requests in one PKIData.controlSequence and Certain combinations of requests in one PKIData.controlSequence and
one PKIResponse.controlSequence are not allowed. The invalid one PKIResponse.controlSequence are not allowed. The invalid
combinations listed here MUST NOT be generated: combinations listed here MUST NOT be generated:
Invalid Combinations Invalid Combinations
--------------------------- ---------------------------
glUseKEK & glDeleteMember glUseKEK & glDeleteMember
glUseKEK & glRekey glUseKEK & glRekey
glUseKEK & glDelete glUseKEK & glDelete
glDelete & glAddMember glDelete & glAddMember
skipping to change at line 1229 skipping to change at line 1227
message processing, if not listed it is an implementation decision message processing, if not listed it is an implementation decision
as to which to process first: glUseKEK before glAddMember, glRekey as to which to process first: glUseKEK before glAddMember, glRekey
before glAddMember, and glDeleteMember before glRekey. Note that before glAddMember, and glDeleteMember before glRekey. Note that
there is a processing priority but it does not imply an ordering there is a processing priority but it does not imply an ordering
within the content. within the content.
3.2.3 GLA Generated Messages 3.2.3 GLA Generated Messages
When the GLA generates a success or fail message, it generates one When the GLA generates a success or fail message, it generates one
for each request. SKDFailInfo values of unsupportedDuration, for each request. SKDFailInfo values of unsupportedDuration,
Turner Expires June 2003 24
And Distribution
unsupportedDeliveryMethod, unsupportedAlgorithm, noGLONameMatch, unsupportedDeliveryMethod, unsupportedAlgorithm, noGLONameMatch,
nameAlreadyInUse, alreadyAnOwner, notAnOwner are not returned to GL nameAlreadyInUse, alreadyAnOwner, notAnOwner are not returned to GL
members. members.
If GLKeyAttributes.recipientsNotMutuallyAware is set to TRUE, a If GLKeyAttributes.recipientsNotMutuallyAware is set to TRUE, a
separate PKIResponse.cMCStatusInfoExt and PKIData.glKey MUST be separate PKIResponse.cMCStatusInfoExt and PKIData.glKey MUST be
generated for each recipient. However, it is valid to send one generated for each recipient. However, it is valid to send one
message with multiple attributes to the same recipient. message with multiple attributes to the same recipient.
If the GL has multiple GLOs, the GLA MUST send cMCStatusInfoExt If the GL has multiple GLOs, the GLA MUST send cMCStatusInfoExt
messages to the requesting GLO. The mechanism to determine which GLO messages to the requesting GLO. The mechanism to determine which GLO
made the request is beyond the scope of this document. made the request is beyond the scope of this document.
Turner 25
And Distribution
If a GL is managed and the GLA receives a glAddMember, If a GL is managed and the GLA receives a glAddMember,
glDeleteMember, or glkCompromise message, the GLA redirects the glDeleteMember, or glkCompromise message, the GLA redirects the
request to the GLO for review. An additional, SignedData MUST be request to the GLO for review. An additional, SignedData MUST be
applied to the redirected request as follows: applied to the redirected request as follows:
GLA Forwarded Requests GLA Forwarded Requests
---------------------- ----------------------
SignedData SignedData
PKIData PKIData
cmsSequence cmsSequence
SignedData SignedData
PKIData PKIData
controlSequence controlSequence
3.2.4 CMC Control Attributes 3.2.4 CMC Control Attributes and CMS Signed Attributes
Certain control attributes defined in CMC [3] are allowed; they are CMC carries control attributes as CMS signed attributes. These
as follows: cMCStatusInfoExt transactionId, senderNonce, attributes are defined in [CMC] and [CMS]. Some of these attributes
recipientNonce, and queryPending. 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 3.2.4.1 Using cMCStatusInfoExt
cMCStatusInfoExt is used by GLAs to indicate to GLOs and GL members cMCStatusInfoExt is used by GLAs to indicate to GLOs and GL members
that a request was unsuccessful. Two classes of failure codes are that a request was unsuccessful. Two classes of failure codes are
used within this document. Errors from the CMCFailInfo list, found 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 in section 5.1.4 of CMC, are encoded as defined in CMC. Error codes
defined in this document are encoded using the ExtendedFailInfo defined in this document are encoded using the ExtendedFailInfo
field of the cmcStatusInfoExt structure. If the same failure code field of the cmcStatusInfoExt structure. If the same failure code
applies to multiple commands, a single cmcStatusInfoExt structure applies to multiple commands, a single cmcStatusInfoExt structure
can be used with multiple items in cMCStatusInfoExt.bodyList. The can be used with multiple items in cMCStatusInfoExt.bodyList. The
GLA MAY also return other pertinent information in statusString. The GLA MAY also return other pertinent information in statusString. The
SKDFailInfo object identifier and value are: SKDFailInfo object identifier and value are:
Turner Expires June 2003 25
And Distribution
id-cet-skdFailInfo OBJECT IDENTIFIER ::= { iso(1) id-cet-skdFailInfo OBJECT IDENTIFIER ::= { iso(1)
identified-organization(3) dod(6) internet(1) security(5) identified-organization(3) dod(6) internet(1) security(5)
mechanisms(5) pkix(7) cet(15) skdFailInfo(1) } mechanisms(5) pkix(7) cet(15) skdFailInfo(1) }
Turner 26
And Distribution
SKDFailInfo ::= INTEGER { SKDFailInfo ::= INTEGER {
unspecified (0), unspecified (0),
closedGL (1), closedGL (1),
unsupportedDuration (2), unsupportedDuration (2),
noGLACertificate (3), noGLACertificate (3),
invalidCert (4), invalidCert (4),
unsupportedAlgorithm (5), unsupportedAlgorithm (5),
noGLONameMatch (6), noGLONameMatch (6),
invalidGLName (7), invalidGLName (7),
nameAlreadyInUse (8), nameAlreadyInUse (8),
skipping to change at line 1331 skipping to change at line 1335
- unsupportedAlgorithm indicates the GLA does not support the - unsupportedAlgorithm indicates the GLA does not support the
requested algorithm. requested algorithm.
- noGLONameMatch indicates that one of the names in the - noGLONameMatch indicates that one of the names in the
certificate used to sign a request does not match the name of a certificate used to sign a request does not match the name of a
registered GLO. registered GLO.
- invalidGLName indicates the GLA does not support the glName - invalidGLName indicates the GLA does not support the glName
present in the request. present in the request.
Turner Expires June 2003 26
And Distribution
- nameAlreadyInUse indicates the glName is already assigned on the - nameAlreadyInUse indicates the glName is already assigned on the
GLA. GLA.
- noSpam indicates the prospective GL member did not sign the - noSpam indicates the prospective GL member did not sign the
request (i.e., if the name in glMember.glMemberName does not request (i.e., if the name in glMember.glMemberName does not
match one of the names (either the subject distinguished name or match one of the names (either the subject distinguished name or
Turner 27
And Distribution
one of the subject alternative names) in the certificate used to one of the subject alternative names) in the certificate used to
sign the request). sign the request).
- alreadyAMember indicates the prospective GL member is already a - alreadyAMember indicates the prospective GL member is already a
GL member. GL member.
- notAMember indicates the prospective GL member to be deleted is - notAMember indicates the prospective GL member to be deleted is
not presently a GL member. not presently a GL member.
- alreadyAnOwner indicates the prospective GLO is already a GLO. - alreadyAnOwner indicates the prospective GLO is already a GLO.
skipping to change at line 1387 skipping to change at line 1390
zero (0). If the signature over any other PKIData failed the zero (0). If the signature over any other PKIData failed the
bodyList value is the bodyPartId value from the request or response. bodyList value is the bodyPartId value from the request or response.
GLOs and GL members who receive cMCStatusInfoExt messages whose GLOs and GL members who receive cMCStatusInfoExt messages whose
signatures are invalid SHOULD generate a new request to avoid signatures are invalid SHOULD generate a new request to avoid
badMessageCheck message loops. badMessageCheck message loops.
cMCStatusInfoExt is also used by GLOs and GLAs to indicate that a cMCStatusInfoExt is also used by GLOs and GLAs to indicate that a
request could not be performed immediately. If the request could not request could not be performed immediately. If the request could not
be processed immediately by the GLA or GLO, the cMCStatusInfoExt be processed immediately by the GLA or GLO, the cMCStatusInfoExt
control attribute MUST be returned indicating cMCStatus.pending and control attribute MUST be returned indicating cMCStatus.pending and
Turner Expires June 2003 27
And Distribution
otherInfo.pendInfo. When requests are redirected to the GLO for otherInfo.pendInfo. When requests are redirected to the GLO for
approval (for managed lists), the GLA MUST NOT return a approval (for managed lists), the GLA MUST NOT return a
cMCStatusInfoExt indicating query pending. cMCStatusInfoExt indicating query pending.
cMCStatusInfoExt is also used by GLAs to indicate that a cMCStatusInfoExt is also used by GLAs to indicate that a
glaQueryRequest is not supported. If the glaQueryRequest is not glaQueryRequest is not supported. If the glaQueryRequest is not
Turner 28
And Distribution
supported, the cMCStatusInfoExt control attribute MUST be returned supported, the cMCStatusInfoExt control attribute MUST be returned
indicating cMCStatus.noSupport and statusString is optionally indicating cMCStatus.noSupport and statusString is optionally
returned to convey additional information. 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 3.2.4.2 Using transactionId
transactionId MAY be included by GLOs, GLAs, or GL members to transactionId MAY be included by GLOs, GLAs, or GL members to
identify a given transaction. All subsequent requests and responses identify a given transaction. All subsequent requests and responses
related to the original request MUST include the same transactionId related to the original request MUST include the same transactionId
control attribute. If GL members include a transactionId and the control attribute. If GL members include a transactionId and the
request is redirected to the GLO, the GLA MAY include an additional request is redirected to the GLO, the GLA MAY include an additional
transactionId in the outer PKIData. If the GLA included an transactionId in the outer PKIData. If the GLA included an
additional transactionId in the outer PKIData, when the GLO additional transactionId in the outer PKIData, when the GLO
generates a cMCStatusInfoExt response it generates one for the GLA generates a cMCStatusInfoExt response it generates one for the GLA
with the GLA's transactionId and one for the GL member with the GL with the GLA's transactionId and one for the GL member with the GL
member's transactionId. member's transactionId.
3.2.4.3 Using nonces 3.2.4.3 Using nonces and signingTime
The use of nonces (see section 5.6 of [3]) can be used to provide The use of nonces (see section 5.6 of [CMC]) and an indication of
application-level replay prevention. If the originating message when the message was signed (see section 11.3 of [CMS]) can be used
includes a senderNonce, the response to the message MUST include the to provide application-level replay prevention.
received senderNonce value as the recipientNonce and a new value as
the senderNonce value in the response. 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 aggragates multiple messages together or forwards a message If a GLA aggragates multiple messages together or forwards a message
to a GLO, the GLA MAY optionally generate a new nonce value and to a GLO, the GLA MAY optionally generate a new nonce value and
include that in the wrapping message. When the response comes back 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 from the GLO, the GLA builds a response to the originator(s) of the
Turner Expires June 2003 28
And Distribution
message(s) and deals with each of the nonce values from the message(s) and deals with each of the nonce values from the
originating messages. originating messages.
3.2.4.4 CMC Attribute Support Requirements 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 in a local policy.
3.2.4.4 CMC and CMS Attribute Support Requirements
The following are the implementation requirements for CMC control The following are the implementation requirements for CMC control
attributes for an implementation be considered conformant to this attributes and CMS signed attributes for an implementation be
specification: considered conformant to this specification:
Required Implementation Requirement |
Implementation Requirement | Control
GLO | GLA | GL Member | Attribute GLO | GLA | GL Member | Attribute
O R | O R F | O R | O R | O R F | O R |
--------- | ------------- | --------- | ---------- --------- | ------------- | --------- | ----------
MUST MUST | MUST MUST - | MUST MUST | cMCStatusInfoExt MUST MUST | MUST MUST - | MUST MUST | cMCStatusInfoExt
MAY MAY | MAY MAY - | MAY MAY | transactionId MAY MAY | MAY MAY - | MAY MAY | transactionId
MAY MAY | MAY MAY - | MAY MAY | senderNonce MAY MAY | MAY MAY - | MAY MAY | senderNonce
MAY MAY | MAY MAY - | MAY MAY | recepientNonce MAY MAY | MAY MAY - | MAY MAY | recepientNonce
MUST MUST | MUST MUST - | MUST MUST | SKDFailInfo MUST MUST | MUST MUST - | MUST MUST | SKDFailInfo
MUST MUST | MUST MUST - | MUST MUST | signingTime
Turner 29
And Distribution
3.2.5 Resubmitted GL Member Messages 3.2.5 Resubmitted GL Member Messages
When the GL is managed, the GLA forwards the GL member requests to When the GL is managed, the GLA forwards the GL member requests to
the GLO for GLO approval by creating a new request message the GLO for GLO approval by creating a new request message
containing the GL member request(s) as a cmsSequence item. If the 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 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 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 the GLA. (Note in this case there are now 3 layers of PKIData
messages with appropriate signing layers.) messages with appropriate signing layers.)
3.2.6 PKIX Certificate and CRL Profile 3.2.6 PKIX Certificate and CRL Profile
Signatures, certificates, and CRLs are verified according to the Signatures, certificates, and CRLs are verified according to the
PKIX profile [5]. PKIX profile [PROFILE].
Name matching is performed according to the PKIX profile [5]. Name matching is performed according to the PKIX profile [PROFILE].
All distinguished name forms must follow the UTF8String convention All distinguished name forms must follow the UTF8String convention
noted in the PKIX profile [5]. noted in the PKIX profile [PROFILE].
A certificate per-GL would be issued to the GLA. A certificate per-GL would be issued to the GLA.
GL policy may mandate that the GL member's address be included in GL policy may mandate that the GL member's address be included in
the GL member's certificate. the GL member's certificate.
Turner Expires June 2003 29
And Distribution
4 Administrative Messages 4 Administrative Messages
There are a number of administrative messages that must be performed There are a number of administrative messages that must be performed
to manage a GL. The following sections describe each request and to manage a GL. The following sections describe each request and
response message combination in detail. The procedures defined in response message combination in detail. The procedures defined in
this section are not prescriptive. this section are not prescriptive.
4.1 Assign KEK To GL 4.1 Assign KEK To GL
Prior to generating a group key, a GL needs to be setup and a shared Prior to generating a group key, a GL needs to be setup and a shared
KEK assigned to the GL. Figure 3 depicts the protocol interactions KEK assigned to the GL. Figure 3 depicts the protocol interactions
to setup and assign a shared KEK. Note that error messages are not to setup and assign a shared KEK. Note that error messages are not
depicted in Figure 3. depicted in Figure 3. Additionally, behavior for the optional
transactionId, senderNonce, and recipientNonce CMC control
attributes is not addressed in these procedures.
+-----+ 1 2 +-----+ +-----+ 1 2 +-----+
| GLA | <-------> | GLO | | GLA | <-------> | GLO |
+-----+ +-----+ +-----+ +-----+
Figure 3 - Create Group List Figure 3 - Create Group List
Turner 30
And Distribution
The process is as follows: The process is as follows:
1 - The GLO is the entity responsible for requesting the creation 1 - The GLO is the entity responsible for requesting the creation
of the GL. The GLO sends a of the GL. The GLO sends a
SignedData.PKIData.controlSequence.glUseKEK request to the GLA SignedData.PKIData.controlSequence.glUseKEK request to the GLA
(1 in Figure 3). The GLO MUST include: glName, glAddress, (1 in Figure 3). The GLO MUST include: glName, glAddress,
glOwnerName, glOwnerAddress, and glAdministration. The GLO MAY glOwnerName, glOwnerAddress, and glAdministration. The GLO MAY
also include their preferences for the shared KEK in also include their preferences for the shared KEK in
glKeyAttributes by indicating whether the GLO controls the glKeyAttributes by indicating whether the GLO controls the
rekey in rekeyControlledByGLO, whether separate glKey messages rekey in rekeyControlledByGLO, whether separate glKey messages
should be sent to each recipient in should be sent to each recipient in
recipientsNotMutuallyAware, the requested algorithm to be used recipientsNotMutuallyAware, the requested algorithm to be used
with the shared KEK in requestedAlgorithm, the duration of the with the shared KEK in requestedAlgorithm, the duration of the
shared KEK, and how many shared KEKs should be initially shared KEK, and how many shared KEKs should be initially
distributed in generationCounter. distributed in generationCounter. The GLO MUST also include
the signingTime attribute with this request.
1.a - If the GLO knows of members to be added to the GL, the 1.a - If the GLO knows of members to be added to the GL, the
glAddMember request(s) MAY be included in the same glAddMember request(s) MAY be included in the same
controlSequence as the glUseKEK request (see section 3.2.2). controlSequence as the glUseKEK request (see section 3.2.2).
The GLO indicates the same glName in the glAddMember request The GLO indicates the same glName in the glAddMember request
as in glUseKEK.glInfo.glName. Further glAddMember procedures as in glUseKEK.glInfo.glName. Further glAddMember procedures
are covered in section 4.3. are covered in section 4.3.
1.b - The GLO can apply confidentiality to the request by 1.b - The GLO can apply confidentiality to the request by
encapsulating the SignedData.PKIData in an EnvelopedData encapsulating the SignedData.PKIData in an EnvelopedData
(see section 3.2.1.2). (see section 3.2.1.2).
Turner Expires June 2003 30
And Distribution
1.c - The GLO can also optionally apply another SignedData over 1.c - The GLO can also optionally apply another SignedData over
the EnvelopedData (see section 3.2.1.2). the EnvelopedData (see section 3.2.1.2).
2 - Upon receipt of the request, the GLA verifies the signature on 2 - Upon receipt of the request, the GLA checks the signingTime
the inner most SignedData.PKIData. If an additional SignedData and verifies the signature on the inner most
and/or EnvelopedData encapsulates the request (see sections SignedData.PKIData. If an additional SignedData and/or
3.2.1.2 and 3.2.2), the GLA verifies the outer signature(s) EnvelopedData encapsulates the request (see sections 3.2.1.2
and/or decrypt the outer layer(S) prior to verifying the and 3.2.2), the GLA verifies the outer signature(s) and/or
signature on the inner most SignedData. decrypt the outer layer(s) prior to verifying the signature on
the inner most SignedData.
2.a - If the signatures do not verify, the GLA returns a 2.a - If the signingTime attribute value is not within the locally
cMCStatusInfoExt response indicating cMCStatus.failed and accepted time window, the GLA MAY return a response
otherInfo.failInfo.badMessageCheck. indicating cMCStatus.failed and otherInfo.failInfo.badTime
and a signingTime attribute.
2.b Else if the signatures do verify but the GLA does not have a 2.b - Else if signature processing continues and if the signatures
do not verify, the GLA returns a cMCStatusInfoExt response
indicating cMCStatus.failed and
otherInfo.failInfo.badMessageCheck. Additionally, a
signingTime attribute is included with the response.
2.c Else if the signatures do verify but the GLA does not have a
valid certificate, the GLA returns a cMCStatusInfoExt with valid certificate, the GLA returns a cMCStatusInfoExt with
cMCStatus.failed and otherInfo.extendedFailInfo.SKDFailInfo cMCStatus.failed and otherInfo.extendedFailInfo.SKDFailInfo
value of noValidGLACertificate. Instead of immediately value of noValidGLACertificate. Additionally, a signingTime
returning the error code, the GLA attempts to get a attribute is included with the response. Instead of
certificate, possibly using CMC [3]. immediately returning the error code, the GLA attempts to
get a certificate, possibly using [CMC].
2.c - Else the signatures are valid and the GLA does have a valid 2.d - Else the signatures are valid and the GLA does have a valid
certificate, the GLA checks that one of the names in the certificate, the GLA checks that one of the names in the
certificate used to sign the request matches one of the certificate used to sign the request matches one of the
names in glUseKEK.glOwnerInfo.glOwnerName. names in glUseKEK.glOwnerInfo.glOwnerName.
Turner 31 2.d.1 - If the names do not match, the GLA returns a response
And Distribution
2.c.1 - If the names do not match, the GLA returns a response
indicating cMCStatusInfoExt with cMCStatus.failed and indicating cMCStatusInfoExt with cMCStatus.failed and
otherInfo.extendedFailInfo.SKDFailInfo value of otherInfo.extendedFailInfo.SKDFailInfo value of
noGLONameMatch. noGLONameMatch. Additionally, a signingTime attribute is
included with the response.
2.c.2 - Else if the names all match, the GLA checks that the 2.d.2 - Else if the names all match, the GLA checks that the
glName and glAddress is not already in use. The GLA also glName and glAddress is not already in use. The GLA also
checks any glAddMember included within the controlSequence checks any glAddMember included within the controlSequence
with this glUseKEK. Further processing of the glAddMember with this glUseKEK. Further processing of the glAddMember
is covered in section 4.3. is covered in section 4.3.
2.c.2.a - If the glName is already in use the GLA returns a 2.d.2.a - If the glName is already in use the GLA returns a
response indicating cMCStatusInfoExt with response indicating cMCStatusInfoExt with
cMCStatus.failed and cMCStatus.failed and
otherInfo.extendedFailInfo.SKDFailInfo value of otherInfo.extendedFailInfo.SKDFailInfo value of
nameAlreadyInUse.
2.c.2.b - Else if the requestedAlgorithm is not supported, the GLA Turner Expires June 2003 31
And Distribution
nameAlreadyInUse. Additionally, a signingTime attribute
is included with the response.
2.d.2.b - Else if the requestedAlgorithm is not supported, the GLA
returns a response indicating cMCStatusInfoExt with returns a response indicating cMCStatusInfoExt with
cMCStatus.failed and cMCStatus.failed and
otherInfo.extendedFailInfo.SKDFailInfo value of otherInfo.extendedFailInfo.SKDFailInfo value of
unsupportedAlgorithm. unsupportedAlgorithm. Additionally, a signingTime
attribute is included with the response.
2.c.2.c - Else if the duration cannot be supported, determining 2.d.2.c - Else if the duration cannot be supported, determining
this is beyond the scope of this document, the GLA this is beyond the scope of this document, the GLA
returns a response indicating cMCStatusInfoExt with returns a response indicating cMCStatusInfoExt with
cMCStatus.failed and cMCStatus.failed and
otherInfo.extendedFailInfo.SKDFailInfo value of otherInfo.extendedFailInfo.SKDFailInfo value of
unsupportedDuration. unsupportedDuration. Additionally, a signingTime
attribute is included with the response.
2.c.2.d - Else if the GL cannot be supported for other reasons, 2.d.2.d - Else if the GL cannot be supported for other reasons,
which the GLA does not wish to disclose, the GLA returns which the GLA does not wish to disclose, the GLA returns
a response indicating cMCStatusInfoExt with a response indicating cMCStatusInfoExt with
cMCStatus.failed and cMCStatus.failed and
otherInfo.extendedFailInfo.SKDFailInfo value of otherInfo.extendedFailInfo.SKDFailInfo value of
unspecified. unspecified. Additionally, a signingTime attribute is
included with the response.
2.c.2.e - Else if the glName is not already in use, the duration 2.d.2.e - Else if the glName is not already in use, the duration
can be supported, and the requestedAlgorithm is can be supported, and the requestedAlgorithm is
supported, the GLA MUST return a cMCStatusInfoExt supported, the GLA MUST return a cMCStatusInfoExt
indicating cMCStatus.success (2 in Figure 3). The GLA indicating cMCStatus.success and a signingTime
also takes administrative actions, which are beyond the attribute. (2 in Figure 3). The GLA also takes
scope of this document, to store the glName, glAddress, administrative actions, which are beyond the scope of
this document, to store the glName, glAddress,
glKeyAttributes, glOwnerName, and glOwnerAddress. The glKeyAttributes, glOwnerName, and glOwnerAddress. The
GLA also sends a glKey message as described in section GLA also sends a glKey message as described in section
5. 5.
2.c.2.e.1 - The GLA can apply confidentiality to the response by 2.d.2.e.1 - The GLA can apply confidentiality to the response by
encapsulating the SignedData.PKIResponse in an encapsulating the SignedData.PKIResponse in an
EnvelopedData if the request was encapsulated in an EnvelopedData if the request was encapsulated in an
EnvelopedData (see section 3.2.1.2). EnvelopedData (see section 3.2.1.2).
Turner 32 2.d.2.e.2 - The GLA can also optionally apply another SignedData
And Distribution
2.c.2.e.2 - The GLA can also optionally apply another SignedData
over the EnvelopedData (see section 3.2.1.2). over the EnvelopedData (see section 3.2.1.2).
3 - Upon receipt of the cMCStatusInfoExt responses, the GLO 3 - Upon receipt of the cMCStatusInfoExt responses, the GLO checks
verifies the GLA signature(s). If an additional SignedData the signingTime and verifies the GLA signature(s). If an
and/or EnvelopedData encapsulates the response (see section additional SignedData and/or EnvelopedData encapsulates the
3.2.1.2 or 3.2.2), the GLO verifies the outer signature and/or response (see section 3.2.1.2 or 3.2.2), the GLO verifies the
decrypt the outer layer prior to verifying the signature on outer signature and/or decrypt the outer layer prior to
the inner most SignedData. verifying the signature on the inner most SignedData.
3.a - If the signatures do verify, the GLO MUST check that one of Turner Expires June 2003 32
the names in the certificate used to sign the response And Distribution
matches the name of the GL.
3.a.1 If the name of the GL does not match the name present in 3.a - If the signingTime attribute value is not within the locally
accepted time window, the GLO MAY return a response
indicating cMCStatus.failed and otherInfo.failInfo.badTime
and a signingTime attribute.
3.b - Else if signature processing continues and if the signatures
do verify, the GLO MUST check that one of the names in the
certificate used to sign the response matches the name of
the GL.
3.b.1 - If the name of the GL does not match the name present in
the certificate used to sign the message, the GLO should the certificate used to sign the message, the GLO should
not believe the response. not believe the response.
3.a.2 Else if the name of the GL does match the name present in 3.b.2 - Else if the name of the GL does match the name present in
the certificate and: the certificate and:
3.a.2.a - If the signatures do verify and the response was 3.b.2.a - If the signatures do verify and the response was
cMCStatusInfoExt indicating cMCStatus.success, the GLO cMCStatusInfoExt indicating cMCStatus.success, the GLO
has successfully created the GL. has successfully created the GL.
3.a.2.b - Else if the signatures are valid and the response is 3.b.2.b - Else if the signatures are valid and the response is
cMCStatusInfoExt.cMCStatus.failed with any reason, the cMCStatusInfoExt.cMCStatus.failed with any reason, the
GLO can reattempt to create the GL using the information GLO can reattempt to create the GL using the information
provided in the response. The GLO can also use the provided in the response. The GLO can also use the
glaQueryRequest to determine the algorithms and other glaQueryRequest to determine the algorithms and other
characteristics supported by the GLA (see section 4.9). characteristics supported by the GLA (see section 4.9).
4.2 Delete GL From GLA 4.2 Delete GL From GLA
From time to time, there are instances when a GL is no longer From time to time, there are instances when a GL is no longer
needed. In this case, the GLO deletes the GL. Figure 4 depicts that needed. In this case, the GLO deletes the GL. Figure 4 depicts that
protocol interactions to delete a GL. protocol interactions to delete a GL. Note that behavior for the
optional transactionId, senderNonce, and recipientNonce CMC control
attributes is not addressed in these procedures.
+-----+ 1 2 +-----+ +-----+ 1 2 +-----+
| GLA | <-------> | GLO | | GLA | <-------> | GLO |
+-----+ +-----+ +-----+ +-----+
Figure 4 - Delete Group List Figure 4 - Delete Group List
The process is as follows: The process is as follows:
1 - The GLO is responsible for requesting the deletion of the GL. 1 - The GLO is responsible for requesting the deletion of the GL.
The GLO sends a SignedData.PKIData.controlSequence.glDelete The GLO sends a SignedData.PKIData.controlSequence.glDelete
request to the GLA (1 in Figure 4). The name of the GL to be
deleted is included in GeneralName. The GLO MUST also include
the signingTime attribute and can also include a transactionId
and senderNonce attributes.
Turner 33 Turner Expires June 2003 33
And Distribution And Distribution
request to the GLA (1 in Figure 4). The name of the GL to be
deleted is included in GeneralName.
1.a - The GLO can optionally apply confidentiality to the request 1.a - The GLO can optionally apply confidentiality to the request
by encapsulating the SignedData.PKIData in an EnvelopedData by encapsulating the SignedData.PKIData in an EnvelopedData
(see section 3.2.1.2). (see section 3.2.1.2).
1.b - The GLO MAY can also optionally apply another SignedData 1.b - The GLO MAY optionally apply another SignedData over the
over the EnvelopedData (see section 3.2.1.2). EnvelopedData (see section 3.2.1.2).
2 - Upon receipt of the request the GLA verifies the signature on 2 - Upon receipt of the request the GLA checks the signingTime and
the inner most SignedData.PKIData. If an additional SignedData verifies the signature on the inner most SignedData.PKIData.
and/or EnvelopedData encapsulates the request (see section If an additional SignedData and/or EnvelopedData encapsulates
3.2.1.2 or 3.2.2), the GLA verifies the outer signature and/or the request (see section 3.2.1.2 or 3.2.2), the GLA verifies
decrypt the outer layer prior to verifying the signature on the outer signature and/or decrypt the outer layer prior to
the inner most SignedData. verifying the signature on the inner most SignedData.
2.a - If the signatures cannot be verified, the GLA returns a 2.a - If the signingTime attribute value is not within the locally
cMCStatusInfoExt response indicating cMCStatus.failed and accepted time window, the GLA MAY return a response
otherInfo.failInfo.badMessageCheck. indicating cMCStatus.failed and otherInfo.failInfo.badTime
and a signingTime attribute.
2.b - Else if the signatures verify, the GLA makes sure the GL is 2.b - Else if signature processing continues and if the signatures
cannot be verified, the GLA returns a cMCStatusInfoExt
response indicating cMCStatus.failed and
otherInfo.failInfo.badMessageCheck. Additionally, a
signingTime attribute is included with the response.
2.c - Else if the signatures verify, the GLA makes sure the GL is
supported by checking the name of the GL matches a glName supported by checking the name of the GL matches a glName
stored on the GLA. stored on the GLA.
2.b.1 - If the glName is not supported by the GLA, the GLA returns 2.c.1 - If the glName is not supported by the GLA, the GLA returns
a response indicating cMCStatusInfoExt with a response indicating cMCStatusInfoExt with
cMCStatus.failed and cMCStatus.failed and
otherInfo.extendedFailInfo.SKDFailInfo value of otherInfo.extendedFailInfo.SKDFailInfo value of
invalidGLName. invalidGLName. Additionally, a signingTime attribute is
included with the response.
2.b.2 - Else if the glName is supported by the GLA, the GLA 2.c.2 - Else if the glName is supported by the GLA, the GLA
ensures a registered GLO signed the glDelete request by ensures a registered GLO signed the glDelete request by
checking if one of the names present in the digital checking if one of the names present in the digital
signature certificate used to sign the glDelete request signature certificate used to sign the glDelete request
matches a registered GLO. matches a registered GLO.
2.b.2.a - If the names do not match, the GLA returns a response 2.c.2.a - If the names do not match, the GLA returns a response
indicating cMCStatusInfoExt with cMCStatus.failed and indicating cMCStatusInfoExt with cMCStatus.failed and
otherInfo.extendedFailInfo.SKDFailInfo value of otherInfo.extendedFailInfo.SKDFailInfo value of
noGLONameMatch. noGLONameMatch. Additionally, a signingTime attribute is
included with the response.
2.b.2.b - Else if the names do match, but the GL cannot be deleted 2.c.2.b - Else if the names do match, but the GL cannot be deleted
for other reasons, which the GLA does not wish to for other reasons, which the GLA does not wish to
disclose, the GLA returns a response indicating disclose, the GLA returns a response indicating
cMCStatusInfoExt with cMCStatus.failed and
otherInfo.extendedFailInfo.SKDFailInfo value of
unspecified. Actions beyond the scope of this document
must then be taken to delete the GL from the GLA.
2.b.2.c - Else if the names do match, the GLA returns a Turner Expires June 2003 34
cMCStatusInfoExt indicating cMCStatus.success (2 in
Turner 34
And Distribution And Distribution
Figure 4). The GLA ought not accept further requests for cMCStatusInfoExt with cMCStatus.failed and
member additions, member deletions, or group rekeys for otherInfo.extendedFailInfo.SKDFailInfo value of
this GL. unspecified. Additionally, a signingTime attribute is
included with the response. Actions beyond the scope of
this document must then be taken to delete the GL from
the GLA.
2.b.2.c.1 - The GLA can apply confidentiality to the response by 2.c.2.c - Else if the names do match, the GLA returns a
cMCStatusInfoExt indicating cMCStatus.success and a
signingTime attribute (2 in Figure 4). The GLA ought not
accept further requests for member additions, member
deletions, or group rekeys for this GL.
2.c.2.c.1 - The GLA can apply confidentiality to the response by
encapsulating the SignedData.PKIResponse in an encapsulating the SignedData.PKIResponse in an
EnvelopedData if the request was encapsulated in an EnvelopedData if the request was encapsulated in an
EnvelopedData (see section 3.2.1.2). EnvelopedData (see section 3.2.1.2).
2.b.2.c.2 - The GLA MAY can also optionally apply another 2.c.2.c.2 - The GLA MAY optionally apply another SignedData over
SignedData over the EnvelopedData (see section the EnvelopedData (see section 3.2.1.2).
3.2.1.2).
3 - Upon receipt of the cMCStatusInfoExt response, the GLO 3 - Upon receipt of the cMCStatusInfoExt response, the GLO checks
verifies the GLA signature(s). If an additional SignedData the signingTime and verifies the GLA signature(s). If an
and/or EnvelopedData encapsulates the response (see section additional SignedData and/or EnvelopedData encapsulates the
3.2.1.2 or 3.2.2), the GLO verifies the outer signature and/or response (see section 3.2.1.2 or 3.2.2), the GLO verifies the
decrypt the outer layer prior to verifying the signature on outer signature and/or decrypt the outer layer prior to
the inner most SignedData. verifying the signature on the inner most SignedData.
3.a - If the signatures verify, the GLO checks that one of the 3.a - If the signingTime attribute value is not within the locally
names in the certificate used to sign the response matches accepted time window, the GLO MAY return a response
the name of the GL. indicating cMCStatus.failed and otherInfo.failInfo.badTime
and a signingTime attribute.
3.a.1 If the name of the GL does not match the name present in 3.b - Else if signature processing continues and if the signatures
verify, the GLO checks that one of the names in the
certificate used to sign the response matches the name of
the GL.
3.b.1 If the name of the GL does not match the name present in
the certificate used to sign the message, the GLO should the certificate used to sign the message, the GLO should
not believe the response. not believe the response.
3.a.2 Else if the name of the GL does match the name present in 3.b.2 Else if the name of the GL does match the name present in
the certificate and: the certificate and:
3.a.2.a - If the signatures verify and the response was 3.b.2.a - If the signatures verify and the response was
cMCStatusInfoExt indicating cMCStatus.success, the GLO cMCStatusInfoExt indicating cMCStatus.success, the GLO
has successfully deleted the GL. has successfully deleted the GL.
3.a.2.b - Else if the signatures do verify and the response was 3.b.2.b - Else if the signatures do verify and the response was
cMCStatusInfoExt.cMCStatus.failed with any reason, the cMCStatusInfoExt.cMCStatus.failed with any reason, the
Turner Expires June 2003 35
And Distribution
GLO can reattempt to delete the GL using the information GLO can reattempt to delete the GL using the information
provided in the response. provided in the response.
4.3 Add Members To GL 4.3 Add Members To GL
To add members to GLs, either the GLO or prospective members use the To add members to GLs, either the GLO or prospective members use the
glAddMember request. The GLA processes GLO and prospective GL member glAddMember request. The GLA processes GLO and prospective GL member
requests differently though. GLOs can submit the request at any time requests differently though. GLOs can submit the request at any time
to add members to the GL, and the GLA, once it has verified the to add members to the GL, and the GLA, once it has verified the
request came from a registered GLO, should process it. If a request came from a registered GLO, should process it. If a
prospective member sends the request, the GLA needs to determine how prospective member sends the request, the GLA needs to determine how
the GL is administered. When the GLO initially configured the GL, the GL is administered. When the GLO initially configured the GL,
they set the GL to be unmanaged, managed, or closed (see section they set the GL to be unmanaged, managed, or closed (see section
3.1.1). In the unmanaged case, the GLA merely processes the member's 3.1.1). In the unmanaged case, the GLA merely processes the member's
Turner 35
And Distribution
request. For the managed case, the GLA forwards the requests from request. For the managed case, the GLA forwards the requests from
the prospective members to the GLO for review. Where there are the prospective members to the GLO for review. Where there are
multiple GLOs for a GL, which GLO the request is forwarded to is multiple GLOs for a GL, which GLO the request is forwarded to is
beyond the scope of this document. The GLO reviews the request and beyond the scope of this document. The GLO reviews the request and
either rejects it or submits a reformed request to the GLA. In the either rejects it or submits a reformed request to the GLA. In the
closed case, the GLA will not accept requests from prospective closed case, the GLA will not accept requests from prospective
members. The following sections describe the processing for the members. The following sections describe the processing for the
GLO(s), GLA, and prospective GL members depending on where the GLO(s), GLA, and prospective GL members depending on where the
glAddMeber request originated, either from a GLO or from prospective glAddMeber request originated, either from a GLO or from prospective
members. Figure 5 depicts the protocol interactions for the three members. Figure 5 depicts the protocol interactions for the three
options. Note that the error messages are not depicted. options. Note that the error messages are not depicted.
Additionally, note that behavior for the optional transactionId,
senderNonce, and recipientNonce CMC control attributes is not
addressed in these procedures.
+-----+ 2,B{A} 3 +----------+ +-----+ 2,B{A} 3 +----------+
| GLO | <--------+ +-------> | Member 1 | | GLO | <--------+ +-------> | Member 1 |
+-----+ | | +----------+ +-----+ | | +----------+
1 | | 1 | |
+-----+ <--------+ | 3 +----------+ +-----+ <--------+ | 3 +----------+
| GLA | A +-------> | ... | | GLA | A +-------> | ... |
+-----+ <-------------+ +----------+ +-----+ <-------------+ +----------+
| |
| 3 +----------+ | 3 +----------+
skipping to change at line 1805 skipping to change at line 1877
Figure 5 - Member Addition Figure 5 - Member Addition
An important decision that needs to be made on a group by group An important decision that needs to be made on a group by group
basis is whether to rekey the group every time a new member is basis is whether to rekey the group every time a new member is
added. Typically, unmanaged GLs should not be rekeyed when a new added. Typically, unmanaged GLs should not be rekeyed when a new
member is added, as the overhead associated with rekeying the group member is added, as the overhead associated with rekeying the group
becomes prohibitive, as the group becomes large. However, managed becomes prohibitive, as the group becomes large. However, managed
and closed GLs can be rekeyed to maintain the confidentiality of the and closed GLs can be rekeyed to maintain the confidentiality of the
traffic sent by group members. An option to rekeying managed or traffic sent by group members. An option to rekeying managed or
closed GLs when a member is added is to generate a new GL with a closed GLs when a member is added is to generate a new GL with a
Turner Expires June 2003 36
And Distribution
different group key. Group rekeying is discussed in sections 4.5 and different group key. Group rekeying is discussed in sections 4.5 and
5. 5.
4.3.1 GLO Initiated Additions 4.3.1 GLO Initiated Additions
The process for GLO initiated glAddMember requests is as follows: The process for GLO initiated glAddMember requests is as follows:
1 - The GLO collects the pertinent information for the member(s) 1 - The GLO collects the pertinent information for the member(s)
to be added (this may be done through an out of bands means). to be added (this may be done through an out of bands means).
The GLO then sends a SignedData.PKIData.controlSequence with a The GLO then sends a SignedData.PKIData.controlSequence with a
separate glAddMember request for each member to the GLA (1 in separate glAddMember request for each member to the GLA (1 in
Figure 5). The GLO includes: the GL name in glName, the Figure 5). The GLO includes: the GL name in glName, the
member's name in glMember.glMemberName, the member's address member's name in glMember.glMemberName, the member's address
in glMember.glMemberAddress, and the member's encryption in glMember.glMemberAddress, and the member's encryption
certificate in glMember.certificates.pKC. The GLO can also certificate in glMember.certificates.pKC. The GLO can also
include any attribute certificates associated with the include any attribute certificates associated with the
member's encryption certificate in glMember.certificates.aC, member's encryption certificate in glMember.certificates.aC,
Turner 36
And Distribution
and the certification path associated with the member's and the certification path associated with the member's
encryption and attribute certificates in encryption and attribute certificates in
glMember.certificates.certPath. glMember.certificates.certPath. The GLO MUST also include the
signingTime attribute with this request.
1.a - The GLO can optionally apply confidentiality to the request 1.a - The GLO can optionally apply confidentiality to the request
by encapsulating the SignedData.PKIData in an EnvelopedData by encapsulating the SignedData.PKIData in an EnvelopedData
(see section 3.2.1.2). (see section 3.2.1.2).
1.b - The GLO can also optionally apply another SignedData over 1.b - The GLO can also optionally apply another SignedData over
the EnvelopedData (see section 3.2.1.2). the EnvelopedData (see section 3.2.1.2).
2 - Upon receipt of the request, the GLA verifies the signature on 2 - Upon receipt of the request, the GLA checks the signingTime
the inner most SignedData.PKIData. If an additional SignedData and verifies the signature on the inner most
and/or EnvelopedData encapsulates the request (see section SignedData.PKIData. If an additional SignedData and/or
3.2.1.2 or 3.2.2), the GLA verifies the outer signature and/or EnvelopedData encapsulates the request (see section 3.2.1.2 or
decrypt the outer layer prior to verifying the signature on 3.2.2), the GLA verifies the outer signature and/or decrypt
the inner most SignedData. the outer layer prior to verifying the signature on the inner
most SignedData.
2.a - If the signatures cannot be verified, the GLA returns a 2.a - If the signingTime attribute value is not within the locally
cMCStatusInfoExt response indicating cMCStatus.failed and accepted time window, the GLA MAY return a response
otherInfo.failInfo.badMessageCheck. indicating cMCStatus.failed and otherInfo.failInfo.badTime
and a signingTime attribute.
2.b - Else if the signatures verify, the glAddMember request is 2.b - Else if signature processing continues and if the signatures
cannot be verified, the GLA returns a cMCStatusInfoExt
response indicating cMCStatus.failed and
otherInfo.failInfo.badMessageCheck. Additionally, a
signingTime attribute is included with the response.
2.c - Else if the signatures verify, the glAddMember request is
included in a controlSequence with the glUseKEK request, and included in a controlSequence with the glUseKEK request, and
the processing in section 4.1 item 2.e is successfully the processing in section 4.1 item 2.e is successfully
Turner Expires June 2003 37
And Distribution
completed the GLA returns a cMCStatusInfoExt indicating completed the GLA returns a cMCStatusInfoExt indicating
cMCStatus.success (2 in Figure 5). cMCStatus.success and a signingTime attribute (2 in Figure
5).
2.b.1 - The GLA can apply confidentiality to the response by 2.c.1 - The GLA can apply confidentiality to the response by
encapsulating the SignedData.PKIData in an EnvelopedData encapsulating the SignedData.PKIData in an EnvelopedData
if the request was encapsulated in an EnvelopedData (see if the request was encapsulated in an EnvelopedData (see
section 3.2.1.2). section 3.2.1.2).
2.b.2 - The GLA can also optionally apply another SignedData over 2.c.2 - The GLA can also optionally apply another SignedData over
the EnvelopedData (see section 3.2.1.2). the EnvelopedData (see section 3.2.1.2).
2.c - Else if the signatures verify and the GLAddMember request is 2.d - Else if the signatures verify and the GLAddMember request is
not included in a controlSequence with the GLCreate request, not included in a controlSequence with the GLCreate request,
the GLA makes sure the GL is supported by checking that the the GLA makes sure the GL is supported by checking that the
glName matches a glName stored on the GLA. glName matches a glName stored on the GLA.
2.c.1 - If the glName is not supported by the GLA, the GLA returns 2.d.1 - If the glName is not supported by the GLA, the GLA returns
a response indicating cMCStatusInfoExt with a response indicating cMCStatusInfoExt with
cMCStatus.failed and cMCStatus.failed and
otherInfo.extendedFailInfo.SKDFailInfo value of otherInfo.extendedFailInfo.SKDFailInfo value of
invalidGLName. invalidGLName. Additionally, a signingTime attribute is
included with the response.
2.c.2 - Else if the glName is supported by the GLA, the GLA checks 2.d.2 - Else if the glName is supported by the GLA, the GLA checks
to see if the glMemberName is present on the GL. to see if the glMemberName is present on the GL.
2.c.2.a - If the glMemberName is present on the GL, the GLA 2.d.2.a - If the glMemberName is present on the GL, the GLA
returns a response indicating cMCStatusInfoExt with returns a response indicating cMCStatusInfoExt with
Turner 37
And Distribution
cMCStatus.failed and cMCStatus.failed and
otherInfo.extendedFailInfo.SKDFailInfo value of otherInfo.extendedFailInfo.SKDFailInfo value of
alreadyAMember. alreadyAMember. Additionally, a signingTime attribute is
included with the response.
2.c.2.b - Else if the glMemberName is not present on the GL, the 2.d.2.b - Else if the glMemberName is not present on the GL, the
GLA checks how the GL is administered. GLA checks how the GL is administered.
2.c.2.b.1 - If the GL is closed, the GLA checks that a registered 2.d.2.b.1 - If the GL is closed, the GLA checks that a registered
GLO signed the request by checking that one of the GLO signed the request by checking that one of the
names in the digital signature certificate used to names in the digital signature certificate used to
sign the request matches a registered GLO. sign the request matches a registered GLO.
2.c.2.b.1.a - If the names do not match, the GLA returns a 2.d.2.b.1.a - If the names do not match, the GLA returns a
response indicating cMCStatusInfoExt with response indicating cMCStatusInfoExt with
cMCStatus.failed and cMCStatus.failed and
otherInfo.extendedFailInfo.SKDFailInfo value of otherInfo.extendedFailInfo.SKDFailInfo value of
noGLONameMatch. noGLONameMatch. Additionally, a signingTime
attribute is included with the response.
2.c.2.b.1.b - Else if the names match, the GLA verifies the 2.d.2.b.1.b - Else if the names match, the GLA verifies the
member's encryption certificate. member's encryption certificate.
2.c.2.b.1.b.1 - If the member's encryption certificate cannot be Turner Expires June 2003 38
And Distribution
2.d.2.b.1.b.1 - If the member's encryption certificate cannot be
verified, the GLA can return a response indicating verified, the GLA can return a response indicating
cMCStatusInfoExt with cMCStatus.failed and cMCStatusInfoExt with cMCStatus.failed and
otherInfo.extendedFailInfo.SKDFailInfo value of otherInfo.extendedFailInfo.SKDFailInfo value of
invalidCert to the GLO. If the GLA does not return invalidCert to the GLO. Additionally, a
a cMCStatusInfoExt.cMCStatus.failed response, the signingTime attribute is included with the
response. If the GLA does not return a
cMCStatusInfoExt.cMCStatus.failed response, the
GLA issues a glProvideCert request (see section GLA issues a glProvideCert request (see section
4.10). 4.10).
2.c.2.b.1.b.2 - Else if the member's certificate verifies, the GLA 2.d.2.b.1.b.2 - Else if the member's certificate verifies, the GLA
returns a cMCStatusInfoExt indicating returns a cMCStatusInfoExt indicating
cMCStatus.success (2 in Figure 5). The GLA also cMCStatus.success and a signingTime attribute (2
takes administrative actions, which are beyond the in Figure 5). The GLA also takes administrative
scope of this document, to add the member to the actions, which are beyond the scope of this
GL stored on the GLA. The GLA also distributes the document, to add the member to the GL stored on
shared KEK to the member via the mechanism the GLA. The GLA also distributes the shared KEK
described in section 5. to the member via the mechanism described in
section 5.
2.c.2.b.1.b.2.a - The GLA applies confidentiality to the response 2.d.2.b.1.b.2.a - The GLA applies confidentiality to the response
by encapsulating the SignedData.PKIData in an by encapsulating the SignedData.PKIData in an
EnvelopedData if the request was encapsulated in EnvelopedData if the request was encapsulated in
an EnvelopedData (see section 3.2.1.2). an EnvelopedData (see section 3.2.1.2).
2.c.2.b.1.b.2.b - The GLA can also optionally apply another 2.d.2.b.1.b.2.b - The GLA can also optionally apply another
SignedData over the EnvelopedData (see section SignedData over the EnvelopedData (see section
3.2.1.2). 3.2.1.2).
2.c.2.b.2 - Else if the GL is managed, the GLA checks that either 2.d.2.b.2 - Else if the GL is managed, the GLA checks that either
a registered GLO or the prospective member signed the a registered GLO or the prospective member signed the
request. For GLOs, one of the names in the certificate request. For GLOs, one of the names in the certificate
used to sign the request needs to match a registered used to sign the request needs to match a registered
Turner 38
And Distribution
GLO. For the prospective member, the name in GLO. For the prospective member, the name in
glMember.glMemberName needs to match one of the names glMember.glMemberName needs to match one of the names
in the certificate used to sign the request. in the certificate used to sign the request.
2.c.2.b.2.a - If the signer is neither a registered GLO nor the 2.d.2.b.2.a - If the signer is neither a registered GLO nor the
prospective GL member, the GLA returns a response prospective GL member, the GLA returns a response
indicating cMCStatusInfoExt with cMCStatus.failed indicating cMCStatusInfoExt with cMCStatus.failed
and otherInfo.extendedFailInfo.SKDFailInfo value of and otherInfo.extendedFailInfo.SKDFailInfo value of
noSpam. noSpam. Additionally, a signingTime attribute is
included with the response.
2.c.2.b.2.b Else if the signer is a registered GLO, the GLA 2.d.2.b.2.b - Else if the signer is a registered GLO, the GLA
verifies the member's encryption certificate. verifies the member's encryption certificate.
2.c.2.b.2.b.1 - If the member's certificate cannot be verified, 2.d.2.b.2.b.1 - If the member's certificate cannot be verified,
the GLA can return a response indicating the GLA can return a response indicating
cMCStatusInfoExt with cMCStatus.failed and cMCStatusInfoExt with cMCStatus.failed and
otherInfo.extendedFailInfo.SKDFailInfo value of otherInfo.extendedFailInfo.SKDFailInfo value of
invalidCert. If the GLA does not return a
cMCStatus.failed response, the GLA MUST issue a
glProvideCert request (see section 4.10).
2.c.2.b.2.b.2 - Else if the member's certificate verifies, the GLA Turner Expires June 2003 39
And Distribution
invalidCert. Additionally, a signingTime attribute
is included with the response. If the GLA does not
return a cMCStatus.failed response, the GLA MUST
issue a glProvideCert request (see section 4.10).
2.d.2.b.2.b.2 - Else if the member's certificate verifies, the GLA
MUST return a cMCStatusInfoExt indicating MUST return a cMCStatusInfoExt indicating
cMCStatus.success to the GLO (2 in Figure 5). The cMCStatus.success and a signingTime attribute to
GLA also takes administrative actions, which are the GLO (2 in Figure 5). The GLA also takes
beyond the scope of this document, to add the administrative actions, which are beyond the scope
member to the GL stored on the GLA. The GLA also of this document, to add the member to the GL
distributes the shared KEK to the member via the stored on the GLA. The GLA also distributes the
mechanism described in section 5. The GL policy shared KEK to the member via the mechanism
may mandate that the GL member's address be described in section 5. The GL policy may mandate
included in the GL member's certificate. that the GL member's address be included in the GL
member's certificate.
2.c.2.b.2.b.2.a - The GLA applies confidentiality to the response 2.d.2.b.2.b.2.a - The GLA applies confidentiality to the response
by encapsulating the SignedData.PKIData in an by encapsulating the SignedData.PKIData in an
EnvelopedData if the request was encapsulated in EnvelopedData if the request was encapsulated in
an EnvelopedData (see section 3.2.1.2). an EnvelopedData (see section 3.2.1.2).
2.c.2.b.2.b.2.b - The GLA can also optionally apply another 2.d.2.b.2.b.2.b - The GLA can also optionally apply another
SignedData over the EnvelopedData (see section SignedData over the EnvelopedData (see section
3.2.1.2). 3.2.1.2).
2.c.2.b.2.c - Else if the signer is the prospective member, the 2.d.2.b.2.c - Else if the signer is the prospective member, the
GLA forwards the glAddMember request (see section GLA forwards the glAddMember request (see section
3.2.3) to a registered GLO (B{A} in Figure 5). If 3.2.3) to a registered GLO (B{A} in Figure 5). If
there is more than one registered GLO, the GLO to there is more than one registered GLO, the GLO to
which the request is forwarded to is beyond the which the request is forwarded to is beyond the
scope of this document. Further processing of the scope of this document. Further processing of the
forwarded request by GLOs is addressed in 3 of forwarded request by GLOs is addressed in 3 of
section 4.3.2. section 4.3.2.
2.c.2.b.2.c.1 - The GLA applies confidentiality to the forwarded 2.d.2.b.2.c.1 - The GLA applies confidentiality to the forwarded
request by encapsulating the SignedData.PKIData in request by encapsulating the SignedData.PKIData in
Turner 39
And Distribution
an EnvelopedData if the original request was an EnvelopedData if the original request was
encapsulated in an EnvelopedData (see section encapsulated in an EnvelopedData (see section
3.2.1.2). 3.2.1.2).
2.c.2.b.2.c.2 - The GLA can also optionally apply another 2.d.2.b.2.c.2 - The GLA can also optionally apply another
SignedData over the EnvelopedData (see section SignedData over the EnvelopedData (see section
3.2.1.2). 3.2.1.2).
2.c.2.b.3 - Else if the GL is unmanaged, the GLA checks that 2.d.2.b.3 - Else if the GL is unmanaged, the GLA checks that
either a registered GLO or the prospective member either a registered GLO or the prospective member
signed the request. For GLOs, one of the names in the signed the request. For GLOs, one of the names in the
certificate used to sign the request needs tp match certificate used to sign the request needs tp match
the name of a registered GLO. For the prospective the name of a registered GLO. For the prospective
member, the name in glMember.glMemberName needs to member, the name in glMember.glMemberName needs to
Turner Expires June 2003 40
And Distribution
match one of the names in the certificate used to sign match one of the names in the certificate used to sign
the request. the request.
2.c.2.b.3.a - If the signer is neither a registered GLO nor the 2.d.2.b.3.a - If the signer is neither a registered GLO nor the
prospective member, the GLA returns a response prospective member, the GLA returns a response
indicating cMCStatusInfoExt with cMCStatus.failed indicating cMCStatusInfoExt with cMCStatus.failed
and otherInfo.extendedFailInfo.SKDFailInfo value of and otherInfo.extendedFailInfo.SKDFailInfo value of
noSpam. noSpam. Additionally, a signingTime attribute is
included with the response.
2.c.2.b.3.b - Else if the signer is either a registered GLO or the 2.d.2.b.3.b - Else if the signer is either a registered GLO or the
prospective member, the GLA verifies the member's prospective member, the GLA verifies the member's
encryption certificate. encryption certificate.
2.c.2.b.3.b.1 - If the member's certificate cannot be verified, 2.d.2.b.3.b.1 - If the member's certificate cannot be verified,
the GLA can return a response indicating the GLA can return a response indicating
cMCStatusInfoExt with cMCStatus.failed and cMCStatusInfoExt with cMCStatus.failed and
otherInfo.extendedFailInfo.SKDFailInfo value of otherInfo.extendedFailInfo.SKDFailInfo value of
invalidCert to either the GLO or the prospective invalidCert and a signingTime attribute to either
member depending on where the request originated. the GLO or the prospective member depending on
If the GLA does not return a cMCStatus.failed where the request originated. If the GLA does not
response, the GLA issues a glProvideCert request return a cMCStatus.failed response, the GLA issues
(see section 4.10) to either the GLO or a glProvideCert request (see section 4.10) to
prospective member depending on where the request either the GLO or prospective member depending on
originated. where the request originated.
2.c.2.b.3.b.2 - Else if the member's certificate verifies, the GLA 2.d.2.b.3.b.2 - Else if the member's certificate verifies, the GLA
returns a cMCStatusInfoExt indicating returns a cMCStatusInfoExt indicating
cMCStatus.success to the GLO (2 in Figure 5) if cMCStatus.success and a signingTime attribute to
the GLO signed the request and to the GL member (3 the GLO (2 in Figure 5) if the GLO signed the
in Figure 5) if the GL member signed the request. request and to the GL member (3 in Figure 5) if
The GLA also takes administrative actions, which the GL member signed the request. The GLA also
are beyond the scope of this document, to add the takes administrative actions, which are beyond the
member to the GL stored on the GLA. The GLA also scope of this document, to add the member to the
distributes the shared KEK to the member via the GL stored on the GLA. The GLA also distributes the
mechanism described in section 5. shared KEK to the member via the mechanism
described in section 5.
2.c.2.b.3.b.2.a - The GLA applies confidentiality to the response 2.d.2.b.3.b.2.a - The GLA applies confidentiality to the response
by encapsulating the SignedData.PKIData in an by encapsulating the SignedData.PKIData in an
Turner 40
And Distribution
EnvelopedData if the request was encapsulated in EnvelopedData if the request was encapsulated in
an EnvelopedData (see section 3.2.1.2). an EnvelopedData (see section 3.2.1.2).
2.c.2.b.3.b.2.b - The GLA can also optionally apply another 2.d.2.b.3.b.2.b - The GLA can also optionally apply another
SignedData over the EnvelopedData (see section SignedData over the EnvelopedData (see section
3.2.1.2). 3.2.1.2).
3 - Upon receipt of the cMCStatusInfoExt response, the GLO 3 - Upon receipt of the cMCStatusInfoExt response, the GLO checks
verifies the GLA signature(s). If an additional SignedData the signingTime and verifies the GLA signature(s). If an
and/or EnvelopedData encapsulates the response (see section additional SignedData and/or EnvelopedData encapsulates the
3.2.1.2 or 3.2.2), the GLO verifies the outer signature and/or response (see section 3.2.1.2 or 3.2.2), the GLO verifies the
decrypt the outer layer prior to verifying the signature on
the inner most SignedData.
3.a - If the signatures verify, the GLO checks that one of the Turner Expires June 2003 41
names in the certificate used to sign the response matches And Distribution
the name of the GL.
3.a.1 If the name of the GL does not match the name present in outer signature and/or decrypt the outer layer prior to
verifying the signature on the inner most SignedData.
3.a - If the signingTime attribute value is not within the locally
accepted time window, the GLO MAY return a response
indicating cMCStatus.failed and otherInfo.failInfo.badTime
and a signingTime attribute.
3.b - Else if signature processing continues and if the signatures
verify, the GLO checks that one of the names in the
certificate used to sign the response matches the name of
the GL.
3.b.1 If the name of the GL does not match the name present in
the certificate used to sign the message, the GLO should the certificate used to sign the message, the GLO should
not believe the response. not believe the response.
3.a.2 Else if the name of the GL matches the name present in the 3.b.2 Else if the name of the GL matches the name present in the
certificate and: certificate and:
3.a.2.a - If the signatures verify and the response is 3.b.2.a - If the signatures verify and the response is
cMCStatusInfoExt indicating cMCStatus.success, the GLA cMCStatusInfoExt indicating cMCStatus.success, the GLA
has added the member to the GL. If member was added to a has added the member to the GL. If member was added to a
managed list and the original request was signed by the managed list and the original request was signed by the
member, the GLO sends a member, the GLO sends a
cMCStatusInfoExt.cMCStatus.success to the GL member. cMCStatusInfoExt.cMCStatus.success and a signingTime
attribute to the GL member.
3.a.2.b - Else if the GLO received a 3.b.2.b - Else if the GLO received a
cMCStatusInfoExt.cMCStatus.failed with any reason, the cMCStatusInfoExt.cMCStatus.failed with any reason, the
GLO can reattempt to add the member to the GL using the GLO can reattempt to add the member to the GL using the
information provided in the response. information provided in the response.
4 - Upon receipt of the cMCStatusInfoExt response, the prospective 4 - Upon receipt of the cMCStatusInfoExt response, the prospective
member verifies the GLA signatures or GLO signatures. If an member checks the signingTime and verifies the GLA signatures
additional SignedData and/or EnvelopedData encapsulates the or GLO signatures. If an additional SignedData and/or
response (see section 3.2.1.2 or 3.2.2), the GLO verifies the EnvelopedData encapsulates the response (see section 3.2.1.2
outer signature and/or decrypt the outer layer prior to or 3.2.2), the GLO verifies the outer signature and/or decrypt
verifying the signature on the inner most SignedData. the outer layer prior to verifying the signature on the inner
most SignedData.
4.a - If the signatures verify, the GL member checks that one of 4.a - If the signingTime attribute value is not within the locally
the names in the certificate used to sign the response accepted time window, the prospective member MAY return a
matches the name of the GL. response indicating cMCStatus.failed and
otherInfo.failInfo.badTime and a signingTime attribute.
4.a.1 If the name of the GL does not match the name present in 4.b - Else if signature processing continues and if the signatures
the certificate used to sign the message, the GL member verify, the GL member checks that one of the names in the
should not believe the response. certificate used to sign the response matches the name of
the GL.
Turner 41 Turner Expires June 2003 42
And Distribution And Distribution
4.a.2 Else if the name of the GL matches the name present in the 4.b.1 - If the name of the GL does not match the name present in
the certificate used to sign the message, the GL member
should not believe the response.
4.b.2 Else if the name of the GL matches the name present in the
certificate and: certificate and:
4.a.2.a - If the signatures verify, the prospective member has 4.b.2.a - If the signatures verify, the prospective member has
been added to the GL. been added to the GL.
4.a.2.b - Else if the prospective member received a 4.b.2.b - Else if the prospective member received a
cMCStatusInfoExt.cMCStatus.failed, for any reason, the cMCStatusInfoExt.cMCStatus.failed, for any reason, the
prospective member MAY reattempt to add themselves to prospective member MAY reattempt to add themselves to
the GL using the information provided in the response. the GL using the information provided in the response.
4.3.2 Prospective Member Initiated Additions 4.3.2 Prospective Member Initiated Additions
The process for prospective member initiated glAddMember requests is The process for prospective member initiated glAddMember requests is
as follows: as follows:
1 - The prospective GL member sends a 1 - The prospective GL member sends a
SignedData.PKIData.controlSequence.glAddMember request to the SignedData.PKIData.controlSequence.glAddMember request to the
GLA (A in Figure 5). The prospective GL member includes: the GLA (A in Figure 5). The prospective GL member includes: the
GL name in glName, their name in glMember.glMemberName, their GL name in glName, their name in glMember.glMemberName, their
address in glMember.glMemberAddress, and their encryption address in glMember.glMemberAddress, and their encryption
certificate in glMember.certificates.pKC. The prospective GL certificate in glMember.certificates.pKC. The prospective GL
member can also include any attribute certificates associated member can also include any attribute certificates associated
with their encryption certificate in glMember.certificates.aC, with their encryption certificate in glMember.certificates.aC,
and the certification path associated with their encryption and the certification path associated with their encryption
and attribute certificates in glMember.certificates.certPath. and attribute certificates in glMember.certificates.certPath.
The prosepective member MUST also include the signingTime
attribute with this request.
1.a - The prospective GL member can optionally apply 1.a - The prospective GL member can optionally apply
confidentiality to the request by encapsulating the confidentiality to the request by encapsulating the
SignedData.PKIData in an EnvelopedData (see section SignedData.PKIData in an EnvelopedData (see section
3.2.1.2). 3.2.1.2).
1.b - The prospective GL member MAY can also optionally apply 1.b - The prospective GL member MAY optionally apply another
another SignedData over the EnvelopedData (see section SignedData over the EnvelopedData (see section 3.2.1.2).
3.2.1.2).
2 - Upon receipt of the request, the GLA verifies the request as 2 - Upon receipt of the request, the GLA verifies the request as
per 2 in section 4.3.1. per 2 in section 4.3.1.
3 - Upon receipt of the forwarded request, the GLO verifies the 3 - Upon receipt of the forwarded request, the GLO checks the
prospective GL member signature on the inner most signingTime and verifies the prospective GL member signature
SignedData.PKIData and the GLA signature on the outer layer. on the inner most SignedData.PKIData and the GLA signature on
If an EnvelopedData encapsulates the inner most layer (see the outer layer. If an EnvelopedData encapsulates the inner
section 3.2.1.2 or 3.2.2), the GLO decrypts the outer layer most layer (see section 3.2.1.2 or 3.2.2), the GLO decrypts
prior to verifying the signature on the inner most SignedData. the outer layer prior to verifying the signature on the inner
most SignedData.
Turner Expires June 2003 43
And Distribution
Note: For cases where the GL is closed and either a) a Note: For cases where the GL is closed and either a) a
prospective member sends directly to the GLO or b) the GLA has prospective member sends directly to the GLO or b) the GLA has
mistakenly forwarded the request to the GLO, the GLO should mistakenly forwarded the request to the GLO, the GLO should
first determine whether to honor the request. first determine whether to honor the request.
Turner 42 3.a - If the signingTime attribute value is not within the locally
And Distribution accepted time window, the GLO MAY return a response
indicating cMCStatus.failed and otherInfo.failInfo.badTime.
3.a - If the signatures verify, the GLO checks to make sure one of 3.b - Else if signature processing continues and if the signatures
the names in the certificate used to sign the request verify, the GLO checks to make sure one of the names in the
matches the name in glMember.glMemberName. certificate used to sign the request matches the name in
glMember.glMemberName.
3.a.1 - If the names do not match, the GLO sends a 3.b.1 - If the names do not match, the GLO sends a
SignedData.PKIResponse.controlSequence message back to the SignedData.PKIResponse.controlSequence message back to the
prospective member with cMCStatusInfoExt.cMCStatus.failed prospective member with cMCStatusInfoExt.cMCStatus.failed
indicating why the prospective member was denied in indicating why the prospective member was denied in
cMCStausInfo.statusString. This stops people from adding cMCStausInfo.statusString. This stops people from adding
people to GLs without their permission. people to GLs without their permission. Additionally, a
signingTime attribute is included with the response.
3.a.2 - Else if the names match, the GLO determines whether the 3.b.2 - Else if the names match, the GLO determines whether the
prospective member is allowed to be added. The mechanism prospective member is allowed to be added. The mechanism
is beyond the scope of this document; however, the GLO is beyond the scope of this document; however, the GLO
should check to see that the glMember.glMemberName is not should check to see that the glMember.glMemberName is not
already on the GL. already on the GL.
3.a.2.a - If the GLO determines the prospective member is not 3.b.2.a - If the GLO determines the prospective member is not
allowed to join the GL, the GLO can return a allowed to join the GL, the GLO can return a
SignedData.PKIResponse.controlSequence message back to SignedData.PKIResponse.controlSequence message back to
the prospective member with the prospective member with
cMCStatusInfoExt.cMCtatus.failed indicating why the cMCStatusInfoExt.cMCtatus.failed indicating why the
prospective member was denied in cMCStatus.statusString. prospective member was denied in cMCStatus.statusString.
Additionally, a signingTime attribute is included with
the response.
3.a.2.b - Else if GLO determines the prospective member is allowed 3.b.2.b - Else if GLO determines the prospective member is allowed
to join the GL, the GLO verifies the member's encryption to join the GL, the GLO verifies the member's encryption
certificate. certificate.
3.a.2.b.1 - If the member's certificate cannot be verified, the 3.b.2.b.1 - If the member's certificate cannot be verified, the
GLO returns a SignedData.PKIResponse.controlSequence GLO returns a SignedData.PKIResponse.controlSequence
back to the prospective member with back to the prospective member with
cMCStatusInfoExt.cMCtatus.failed indicating that the cMCStatusInfoExt.cMCtatus.failed indicating that the
member's encryption certificate did not verify in member's encryption certificate did not verify in
cMCStatus.statusString. If the GLO does not return a cMCStatus.statusString. Additionally, a signingTime
cMCStatusInfoExt response, the GLO sends a attribute is included with the response. If the GLO
does not return a cMCStatusInfoExt response, the GLO
sends a
SignedData.PKIData.controlSequence.glProvideCert SignedData.PKIData.controlSequence.glProvideCert
Turner Expires June 2003 44
And Distribution
message to the prospective member requesting a new message to the prospective member requesting a new
encryption certificate (see section 4.10). encryption certificate (see section 4.10).
3.a.2.b.2 - Else if the member's certificate verifies, the GLO 3.b.2.b.2 - Else if the member's certificate verifies, the GLO
resubmits the glAddMember request (see section 3.2.5) resubmits the glAddMember request (see section 3.2.5)
to the GLA (1 in Figure 5). to the GLA (1 in Figure 5).
3.a.2.b.2.a - The GLO applies confidentiality to the new 3.b.2.b.2.a - The GLO applies confidentiality to the new
GLAddMember request by encapsulating the GLAddMember request by encapsulating the
SignedData.PKIData in an EnvelopedData if the SignedData.PKIData in an EnvelopedData if the
initial request was encapsulated in an EnvelopedData initial request was encapsulated in an EnvelopedData
(see section 3.2.1.2). (see section 3.2.1.2).
3.a.2.b.2.b - The GLO can also optionally apply another SignedData 3.b.2.b.2.b - The GLO can also optionally apply another SignedData
over the EnvelopedData (see section 3.2.1.2). over the EnvelopedData (see section 3.2.1.2).
Turner 43
And Distribution
4 - Processing continues as in 2 of section 4.3.1. 4 - Processing continues as in 2 of section 4.3.1.
4.4 Delete Members From GL 4.4 Delete Members From GL
To delete members from GLs, either the GLO or members to be removed To delete members from GLs, either the GLO or members to be removed
use the glDeleteMember request. The GLA processes GLO and members use the glDeleteMember request. The GLA processes GLO and members
requesting their own removal make requests differently. The GLO can requesting their own removal make requests differently. The GLO can
submit the request at any time to delete members from the GL, and submit the request at any time to delete members from the GL, and
the GLA, once it has verified the request came from a registered the GLA, once it has verified the request came from a registered
GLO, should delete the member. If a member sends the request, the GLO, should delete the member. If a member sends the request, the
skipping to change at line 2237 skipping to change at line 2360
GLA merely processes the member's request. For the managed case, the GLA merely processes the member's request. For the managed case, the
GLA forwards the requests from the member to the GLO for review. GLA forwards the requests from the member to the GLO for review.
Where there are multiple GLOs for a GL, which GLO the request is Where there are multiple GLOs for a GL, which GLO the request is
forwarded to is beyond the scope of this document. The GLO reviews forwarded to is beyond the scope of this document. The GLO reviews
the request and either rejects it or submits a reformed request to the request and either rejects it or submits a reformed request to
the GLA. In the closed case, the GLA will not accept requests from the GLA. In the closed case, the GLA will not accept requests from
members. The following sections describe the processing for the members. The following sections describe the processing for the
GLO(s), GLA, and GL members depending on where the request GLO(s), GLA, and GL members depending on where the request
originated, either from a GLO or from members wanting to be removed. originated, either from a GLO or from members wanting to be removed.
Figure 6 depicts the protocol interactions for the three options. Figure 6 depicts the protocol interactions for the three options.
Note that the error messages are not depicted. Note that the error messages are not depicted. Additionally,
behavior for the optional transactionId, senderNonce, and
recipientNonce CMC control attributes is not addressed in these
procedures.
Turner Expires June 2003 45
And Distribution
+-----+ 2,B{A} 3 +----------+ +-----+ 2,B{A} 3 +----------+
| GLO | <--------+ +-------> | Member 1 | | GLO | <--------+ +-------> | Member 1 |
+-----+ | | +----------+ +-----+ | | +----------+
1 | | 1 | |
+-----+ <--------+ | 3 +----------+ +-----+ <--------+ | 3 +----------+
| GLA | A +-------> | ... | | GLA | A +-------> | ... |
+-----+ <-------------+ +----------+ +-----+ <-------------+ +----------+
| |
| 3 +----------+ | 3 +----------+
skipping to change at line 2266 skipping to change at line 2395
no point to a group rekey because there is no guarantee that the no point to a group rekey because there is no guarantee that the
member requesting to be removed has not already added themselves member requesting to be removed has not already added themselves
back on the GL under a different name. For managed and closed GLs, back on the GL under a different name. For managed and closed GLs,
the GLO needs to take steps to ensure the member being deleted is the GLO needs to take steps to ensure the member being deleted is
not on the GL twice. After ensuring this, managed and closed GLs can not on the GL twice. After ensuring this, managed and closed GLs can
be rekeyed to maintain the confidentiality of the traffic sent by be rekeyed to maintain the confidentiality of the traffic sent by
group members. If the GLO is sure the member has been deleted the group members. If the GLO is sure the member has been deleted the
group rekey mechanism can be used to distribute the new key (see group rekey mechanism can be used to distribute the new key (see
sections 4.5 and 5). sections 4.5 and 5).
Turner 44
And Distribution
4.4.1 GLO Initiated Deletions 4.4.1 GLO Initiated Deletions
The process for GLO initiated glDeleteMember requests is as follows: The process for GLO initiated glDeleteMember requests is as follows:
1 - The GLO collects the pertinent information for the member(s) 1 - The GLO collects the pertinent information for the member(s)
to be deleted (this can be done through an out of bands to be deleted (this can be done through an out of bands
means). The GLO then sends a means). The GLO then sends a
SignedData.PKIData.controlSequence with a separate SignedData.PKIData.controlSequence with a separate
glDeleteMember request for each member to the GLA (1 in Figure glDeleteMember request for each member to the GLA (1 in Figure
6). The GLO MUST include: the GL name in glName and the 6). The GLO MUST include: the GL name in glName and the
member's name in glMemberToDelete. If the GL from which the member's name in glMemberToDelete. If the GL from which the
member is being deleted in a closed or managed GL, the GLO member is being deleted in a closed or managed GL, the GLO
MUST also generate a glRekey request and include it with the MUST also generate a glRekey request and include it with the
glDeletemember request (see section 4.5). glDeletemember request (see section 4.5). The GLO MUST also
include the signingTime attribute with this request.
1.a - The GLO can optionally apply confidentiality to the request 1.a - The GLO can optionally apply confidentiality to the request
by encapsulating the SignedData.PKIData in an EnvelopedData by encapsulating the SignedData.PKIData in an EnvelopedData
(see section 3.2.1.2). (see section 3.2.1.2).
1.b - The GLO can also optionally apply another SignedData over 1.b - The GLO can also optionally apply another SignedData over
the EnvelopedData (see section 3.2.1.2). the EnvelopedData (see section 3.2.1.2).
2 - Upon receipt of the request, the GLA verifies the signature on Turner Expires June 2003 46
the inner most SignedData.PKIData. If an additional SignedData And Distribution
and/or EnvelopedData encapsulates the request (see section
3.2.1.2 or 3.2.2), the GLA verifies the outer signature and/or
decrypt the outer layer prior to verifying the signature on
the inner most SignedData.
2.a - If the signatures cannot be verified, the GLA returns a 2 - Upon receipt of the request, the GLA checks the signingTime
cMCStatusInfoExt response indicating cMCStatus.failed and attribute and verifies the signature on the inner most
otherInfo.failInfo.badMessageCheck. SignedData.PKIData. If an additional SignedData and/or
EnvelopedData encapsulates the request (see section 3.2.1.2 or
3.2.2), the GLA verifies the outer signature and/or decrypt
the outer layer prior to verifying the signature on the inner
most SignedData.
2.b - Else if the signatures verify, the GLA makes sure the GL is 2.a - If the signingTime attribute value is not within the locally
accepted time window, the GLA MAY return a response
indicating cMCStatus.failed and otherInfo.failInfo.badTime
and a signingTime attribute.
2.b - Else if signature processing continues and if the signatures
cannot be verified, the GLA returns a cMCStatusInfoExt
response indicating cMCStatus.failed and
otherInfo.failInfo.badMessageCheck. Additionally, a
signingTime attribute is included with the response.
2.c - Else if the signatures verify, the GLA makes sure the GL is
supported by the GLA by checking that the glName matches a supported by the GLA by checking that the glName matches a
glName stored on the GLA. glName stored on the GLA.
2.b.1 - If the glName is not supported by the GLA, the GLA returns 2.c.1 - If the glName is not supported by the GLA, the GLA returns
a response indicating cMCStatusInfoExt with a response indicating cMCStatusInfoExt with
cMCStatus.failed and cMCStatus.failed and
otherInfo.extendedFailInfo.SKDFailInfo value of otherInfo.extendedFailInfo.SKDFailInfo value of
invalidGLName. invalidGLName. Additionally, a signingTime attribute is
included with the response.
2.b.2 - Else if the glName is supported by the GLA, the GLA checks 2.c.2 - Else if the glName is supported by the GLA, the GLA checks
to see if the glMemberName is present on the GL. to see if the glMemberName is present on the GL.
2.b.2.a - If the glMemberName is not present on the GL, the GLA 2.c.2.a - If the glMemberName is not present on the GL, the GLA
returns a response indicating cMCStatusInfoExt with returns a response indicating cMCStatusInfoExt with
cMCStatus.failed and cMCStatus.failed and
Turner 45
And Distribution
otherInfo.extendedFailInfo.SKDFailInfo value of otherInfo.extendedFailInfo.SKDFailInfo value of
notAMember. notAMember. Additionally, a signingTime attribute is
included with the response.
2.b.2.b - Else if the glMemberName is already on the GL, the GLA 2.c.2.b - Else if the glMemberName is already on the GL, the GLA
checks how the GL is administered. checks how the GL is administered.
2.b.2.b.1 - If the GL is closed, the GLA checks that the 2.c.2.b.1 - If the GL is closed, the GLA checks that the
registered GLO signed the request by checking that one registered GLO signed the request by checking that one
of the names in the digital signature certificate used of the names in the digital signature certificate used
to sign the request matches the registered GLO. to sign the request matches the registered GLO.
2.b.2.b.1.a - If the names do not match, the GLA returns a 2.c.2.b.1.a - If the names do not match, the GLA returns a
response indicating cMCStatusInfoExt with response indicating cMCStatusInfoExt with
cMCStatus.failed and cMCStatus.failed and
otherInfo.extendedFailInfo.SKDFailInfo value of otherInfo.extendedFailInfo.SKDFailInfo value of
closedGL.
2.b.2.b.1.b - Else if the names do match, the GLA returns a Turner Expires June 2003 47
cMCStatusInfoExt.cMCStatus.success (2 in Figure 5). And Distribution
The GLA also takes administrative actions, which are
beyond the scope of this document, to delete the
member with the GL stored on the GLA. Note that he
GL also needs to be rekeyed as described in section
5.
2.b.2.b.1.b.1 - The GLA applies confidentiality to the response by closedGL. Additionally, a signingTime attribute is
included with the response.
2.c.2.b.1.b - Else if the names do match, the GLA returns a
cMCStatusInfoExt.cMCStatus.success and a signingTime
attribute (2 in Figure 5). The GLA also takes
administrative actions, which are beyond the scope
of this document, to delete the member with the GL
stored on the GLA. Note that he GL also needs to be
rekeyed as described in section 5.
2.c.2.b.1.b.1 - The GLA applies confidentiality to the response by
encapsulating the SignedData.PKIData in an encapsulating the SignedData.PKIData in an
EnvelopedData if the request was encapsulated in EnvelopedData if the request was encapsulated in
an EnvelopedData (see section 3.2.1.2). an EnvelopedData (see section 3.2.1.2).
2.b.2.b.1.b.2 - The GLA can also optionally apply another 2.c.2.b.1.b.2 - The GLA can also optionally apply another
SignedData over the EnvelopedData (see section SignedData over the EnvelopedData (see section
3.2.1.2). 3.2.1.2).
2.b.2.b.2 - Else if the GL is managed, the GLA checks that either 2.c.2.b.2 - Else if the GL is managed, the GLA checks that either
a registered GLO or the prospective member signed the a registered GLO or the prospective member signed the
request. For GLOs, one of the names in the certificate request. For GLOs, one of the names in the certificate
used to sign the request needs to match a registered used to sign the request needs to match a registered
GLO. For the prospective member, the name in GLO. For the prospective member, the name in
glMember.glMemberName needs to match one of the names glMember.glMemberName needs to match one of the names
in the certificate used to sign the request. in the certificate used to sign the request.
2.b.2.b.2.a - If the signer is neither a registered GLO nor the 2.c.2.b.2.a - If the signer is neither a registered GLO nor the
prospective GL member, the GLA returns a response prospective GL member, the GLA returns a response
indicating cMCStatusInfoExt with cMCStatus.failed indicating cMCStatusInfoExt with cMCStatus.failed
and otherInfo.extendedFailInfo.SKDFailInfo value of and otherInfo.extendedFailInfo.SKDFailInfo value of
noSpam. noSpam. Additionally, a signingTime attribute is
included with the response.
2.b.2.b.2.b - Else if the signer is a registered GLO, the GLA
returns a cMCStatusInfoExt.cMCStatus.success (2 in
Figure 6). The GLA also takes administrative
actions, which are beyond the scope of this
Turner 46
And Distribution
document, to delete the member with the GL stored on 2.c.2.b.2.b - Else if the signer is a registered GLO, the GLA
the GLA. Note that the GL will also be rekeyed as returns a cMCStatusInfoExt.cMCStatus.success and a
described in section 5. signingTime attribute(2 in Figure 6). The GLA also
takes administrative actions, which are beyond the
scope of this document, to delete the member with
the GL stored on the GLA. Note that the GL will also
be rekeyed as described in section 5.
2.b.2.b.2.b.1 - The GLA applies confidentiality to the response by 2.c.2.b.2.b.1 - The GLA applies confidentiality to the response by
encapsulating the SignedData.PKIData in an encapsulating the SignedData.PKIData in an
EnvelopedData if the request was encapsulated in EnvelopedData if the request was encapsulated in
an EnvelopedData (see section 3.2.1.2). an EnvelopedData (see section 3.2.1.2).
2.b.2.b.2.b.2 - The GLA can also optionally apply another 2.c.2.b.2.b.2 - The GLA can also optionally apply another
SignedData over the EnvelopedData (see section SignedData over the EnvelopedData (see section
3.2.1.2). 3.2.1.2).
2.b.2.b.2.c - Else if the signer is the prospective member, the Turner Expires June 2003 48
And Distribution
2.c.2.b.2.c - Else if the signer is the prospective member, the
GLA forwards the glDeleteMember request (see section GLA forwards the glDeleteMember request (see section
3.2.3) to the GLO (B{A} in Figure 6). If there is 3.2.3) to the GLO (B{A} in Figure 6). If there is
more than one registered GLO, the GLO to which the more than one registered GLO, the GLO to which the
request is forwarded to is beyond the scope of this request is forwarded to is beyond the scope of this
document. Further processing of the forwarded document. Further processing of the forwarded
request by GLOs is addressed in 3 of section 4.4.2. request by GLOs is addressed in 3 of section 4.4.2.
2.b.2.b.2.c.1 - The GLA applies confidentiality to the forwarded 2.c.2.b.2.c.1 - The GLA applies confidentiality to the forwarded
request by encapsulating the SignedData.PKIData in request by encapsulating the SignedData.PKIData in
an EnvelopedData if the request was encapsulated an EnvelopedData if the request was encapsulated
in an EnvelopedData (see section 3.2.1.2). in an EnvelopedData (see section 3.2.1.2).
2.b.2.b.2.c.2 - The GLA can also optionally apply another 2.c.2.b.2.c.2 - The GLA can also optionally apply another
SignedData over the EnvelopedData (see section SignedData over the EnvelopedData (see section
3.2.1.2). 3.2.1.2).
2.b.2.b.3 - Else if the GL is unmanaged, the GLA checks that 2.c.2.b.3 - Else if the GL is unmanaged, the GLA checks that
either a registered GLO or the prospective member either a registered GLO or the prospective member
signed the request. For GLOs, one of the names in the signed the request. For GLOs, one of the names in the
certificate used to sign the request needs to match certificate used to sign the request needs to match
the name of a registered GLO. For the prospective the name of a registered GLO. For the prospective
member, the name in glMember.glMemberName needs to member, the name in glMember.glMemberName needs to
match one of the names in the certificate used to sign match one of the names in the certificate used to sign
the request. the request.
2.b.2.b.3.a - If the signer is neither the GLO nor the prospective 2.c.2.b.3.a - If the signer is neither the GLO nor the prospective
member, the GLA returns a response indicating member, the GLA returns a response indicating
cMCStatusInfoExt with cMCStatus.failed and cMCStatusInfoExt with cMCStatus.failed and
otherInfo.extendedFailInfo.SKDFailInfo value of otherInfo.extendedFailInfo.SKDFailInfo value of
noSpam. noSpam. Additionally, a signingTime attribute is
included with the response.
2.b.2.b.3.b - Else if the signer is either a registered GLO or the 2.c.2.b.3.b - Else if the signer is either a registered GLO or the
member, the GLA returns a member, the GLA returns a
cMCStatusInfoExt.cMCStatus.success to the GLO (2 in cMCStatusInfoExt.cMCStatus.success and a signingTime
Figure 6) if the GLO signed the request and to the attribute to the GLO (2 in Figure 6) if the GLO
GL member (3 in Figure 6) if the GL member signed signed the request and to the GL member (3 in Figure
the request. The GLA also takes administrative 6) if the GL member signed the request. The GLA also
actions, which are beyond the scope of this takes administrative actions, which are beyond the
scope of this document, to delete the member with
Turner 47 the GL stored on the GLA.
And Distribution
document, to delete the member with the GL stored on
the GLA.
2.b.2.b.3.b.1 - The GLA applies confidentiality to the response by 2.c.2.b.3.b.1 - The GLA applies confidentiality to the response by
encapsulating the SignedData.PKIData in an encapsulating the SignedData.PKIData in an
EnvelopedData if the request was encapsulated in EnvelopedData if the request was encapsulated in
an EnvelopedData (see section 3.2.1.2). an EnvelopedData (see section 3.2.1.2).
2.b.2.b.3.b.2 - The GLA can also optionally apply another 2.c.2.b.3.b.2 - The GLA can also optionally apply another
SignedData over the EnvelopedData (see section SignedData over the EnvelopedData (see section
3.2.1.2). 3.2.1.2).
3 - Upon receipt of the cMCStatusInfoExt response, the GLO Turner Expires June 2003 49
verifies the GLA signatures. If an additional SignedData And Distribution
and/or EnvelopedData encapsulates the response (see section
3.2.1.2 or 3.2.2), the GLO verifies the outer signature and/or
decrypt the outer layer prior to verifying the signature on
the inner most SignedData.
3.a - If the signatures do verify, the GLO checks that one of the 3 - Upon receipt of the cMCStatusInfoExt response, the GLO checks
names in the certificate used to sign the response matches the signingTime and verifies the GLA signatures. If an
the name of the GL. additional SignedData and/or EnvelopedData encapsulates the
response (see section 3.2.1.2 or 3.2.2), the GLO verifies the
outer signature and/or decrypt the outer layer prior to
verifying the signature on the inner most SignedData.
3.a.1 If the name of the GL does not match the name present in 3.a - If the signingTime attribute value is not within the locally
accepted time window, the GLO MAY return a response
indicating cMCStatus.failed and otherInfo.failInfo.badTime
and a signingTime attribute.
3.b - Else if signature processing continues and if the signatures
do verify, the GLO checks that one of the names in the
certificate used to sign the response matches the name of
the GL.
3.b.1 If the name of the GL does not match the name present in
the certificate used to sign the message, the GLO should the certificate used to sign the message, the GLO should
not believe the response. not believe the response.
3.a.2 Else if the name of the GL matches the name present in the 3.b.2 Else if the name of the GL matches the name present in the
certificate and: certificate and:
3.a.2.a - If the signatures verify and the response is 3.b.2.a - If the signatures verify and the response is
cMCStatusInfoExt.cMCStatus.success, the GLO has deleted cMCStatusInfoExt.cMCStatus.success, the GLO has deleted
the member from the GL. If member was deleted from a the member from the GL. If member was deleted from a
managed list and the original request was signed by the managed list and the original request was signed by the
member, the GLO sends a member, the GLO sends a
cMCStatusInfoExt.cMCStatus.success to the GL member. cMCStatusInfoExt.cMCStatus.success and a signingTime
attribute to the GL member.
3.a.2.b - Else if the GLO received a 3.b.2.b - Else if the GLO received a
cMCStatusInfoExt.cMCStatus.failed with any reason, the cMCStatusInfoExt.cMCStatus.failed with any reason, the
GLO may reattempt to delete the member from the GL using GLO may reattempt to delete the member from the GL using
the information provided in the response. the information provided in the response.
4 - Upon receipt of the cMCStatusInfoExt response, the member 4 - Upon receipt of the cMCStatusInfoExt response, the member
verifies the GLA signature(s) or GLO signature(s). If an checks the signingTime and verifies the GLA signature(s) or
additional SignedData and/or EnvelopedData encapsulates the GLO signature(s). If an additional SignedData and/or
response (see section 3.2.1.2 or 3.2.2), the GLO verifies the EnvelopedData encapsulates the response (see section 3.2.1.2
outer signature and/or decrypt the outer layer prior to or 3.2.2), the GLO verifies the outer signature and/or decrypt
verifying the signature on the inner most SignedData. the outer layer prior to verifying the signature on the inner
most SignedData.
4.a - If the signatures verify, the GL member checks that one of 4.b - If the signingTime attribute value is not within the locally
the names in the certificate used to sign the response accepted time window, the prospective member MAY return a
matches the name of the GL. response indicating cMCStatus.failed and
otherInfo.failInfo.badTime and a signingTime attribute.
Turner 48 4.b - Else if signature processing continues and if the signatures
verify, the GL member checks that one of the names in the
Turner Expires June 2003 50
And Distribution And Distribution
4.a.1 If the name of the GL does not match the name present in certificate used to sign the response matches the name of
the GL.
4.b.1 If the name of the GL does not match the name present in
the certificate used to sign the message, the GL member the certificate used to sign the message, the GL member
should not believe the response. should not believe the response.
4.a.2 Else if the name of the GL matches the name present in the 4.b.2 Else if the name of the GL matches the name present in the
certificate and: certificate and:
4.a.2.a - If the signature(s) verify, the member has been deleted 4.b.2.a - If the signature(s) verify, the member has been deleted
from the GL. from the GL.
4.a.2.b - Else if the member received a 4.b.2.b - Else if the member received a
cMCStatusInfoExt.cMCStatus.failed with any reason, the cMCStatusInfoExt.cMCStatus.failed with any reason, the
member can reattempt to delete themselves from the GL member can reattempt to delete themselves from the GL
using the information provided in the response. using the information provided in the response.
4.4.2 Member Initiated Deletions 4.4.2 Member Initiated Deletions
The process for member initiated deletion of their own membership The process for member initiated deletion of their own membership
using the glDeleteMember requests is as follows: using the glDeleteMember requests is as follows:
1 - The member sends a 1 - The member sends a
SignedData.PKIData.controlSequence.glDeleteMember request to SignedData.PKIData.controlSequence.glDeleteMember request to
the GLA (A in Figure 6). The member includes: the name of the the GLA (A in Figure 6). The member includes: the name of the
GL in glName and their own name in glMemberToDelete. GL in glName and their own name in glMemberToDelete. The GL
member MUST also include the signingTime attribute with this
request.
1.a - The member can optionally apply confidentiality to the 1.a - The member can optionally apply confidentiality to the
request by encapsulating the SignedData.PKIData in an request by encapsulating the SignedData.PKIData in an
EnvelopedData (see section 3.2.1.2). EnvelopedData (see section 3.2.1.2).
1.b - The member can also optionally apply another SignedData over 1.b - The member can also optionally apply another SignedData over
the EnvelopedData (see section 3.2.1.2). the EnvelopedData (see section 3.2.1.2).
2 - Upon receipt of the request, the GLA verifies the request as 2 - Upon receipt of the request, the GLA verifies the request as
per 2 in section 4.4.1. per 2 in section 4.4.1.
3 - Upon receipt of the forwarded request, the GLO verifies the 3 - Upon receipt of the forwarded request, the GLO checks the
member signature on the inner most SignedData.PKIData and the signingTime and verifies the member signature on the inner
GLA signature on the outer layer. If an EnvelopedData most SignedData.PKIData and the GLA signature on the outer
encapsulates the inner most layer (see section 3.2.1.2 or layer. If an EnvelopedData encapsulates the inner most layer
3.2.2), the GLO decrypts the outer layer prior to verifying (see section 3.2.1.2 or 3.2.2), the GLO decrypts the outer
the signature on the inner most SignedData. layer prior to verifying the signature on the inner most
SignedData.
Note: For cases where the GL is closed and either (a) a Note: For cases where the GL is closed and either (a) a
prospective member sends directly to the GLO or (b) the GLA prospective member sends directly to the GLO or (b) the GLA
Turner Expires June 2003 51
And Distribution
has mistakenly forwarded the request to the GLO, the GLO has mistakenly forwarded the request to the GLO, the GLO
should first determine whether to honor the request. should first determine whether to honor the request.
3.a - If the signatures cannot be verified, the GLO returns a 3.a - If the signingTime attribute value is not within the locally
cMCStatusInfoExt response indicating cMCStatus.failed and accepted time window, the GLO MAY return a response
otherInfo.failInfo.badMessageCheck. indicating cMCStatus.failed and otherInfo.failInfo.badTime
and a signingTime attribute.
Turner 49 3.b - Else if signature processing continues if the signatures
And Distribution cannot be verified, the GLO returns a cMCStatusInfoExt
response indicating cMCStatus.failed and
otherInfo.failInfo.badMessageCheck and a signingTime
attribute.
3.b - Else if the signatures verify, the GLO checks to make sure 3.c - Else if the signatures verify, the GLO checks to make sure
one of the names in the certificates used to sign the one of the names in the certificates used to sign the
request matches the name in glMemberToDelete. request matches the name in glMemberToDelete.
3.b.1 - If the names match, the GLO sends a 3.c.1 - If the names match, the GLO sends a
SignedData.PKIResponse.controlSequence message back to the SignedData.PKIResponse.controlSequence message back to the
prospective member with cMCStatusInfoExt.cMCtatus.failed prospective member with cMCStatusInfoExt.cMCtatus.failed
indicating why the prospective member was denied in indicating why the prospective member was denied in
cMCStatusInfoExt.statusString. This stops people from cMCStatusInfoExt.statusString. This stops people from
adding people to GLs without their permission. adding people to GLs without their permission.
Additionally, a signingTime attribute is included with the
response.
3.b.2 - Else if the names match, the GLO resubmits the 3.c.2 - Else if the names match, the GLO resubmits the
glDeleteMember request (see section 3.2.5) to the GLA (1 glDeleteMember request (see section 3.2.5) to the GLA (1
in Figure 6). The GLO makes sure the glMemberName is in Figure 6). The GLO makes sure the glMemberName is
already on the GL. The GLO also generates a glRekey already on the GL. The GLO also generates a glRekey
request and include it with the GLDeleteMember request request and include it with the GLDeleteMember request
(see section 4.5). (see section 4.5).
3.b.2.a - The GLO applies confidentiality to the new 3.c.2.a - The GLO applies confidentiality to the new
GLDeleteMember request by encapsulating the GLDeleteMember request by encapsulating the
SignedData.PKIData in an EnvelopedData if the initial SignedData.PKIData in an EnvelopedData if the initial
request was encapsulated in an EnvelopedData (see request was encapsulated in an EnvelopedData (see
section 3.2.1.2). section 3.2.1.2).
3.b.2.b - The GLO can also optionally apply another SignedData 3.c.2.b - The GLO can also optionally apply another SignedData
over the EnvelopedData (see section 3.2.1.2). over the EnvelopedData (see section 3.2.1.2).
4 - Further processing is as in 2 of section 4.4.1. 4 - Further processing is as in 2 of section 4.4.1.
Turner Expires June 2003 52
And Distribution
4.5 Request Rekey Of GL 4.5 Request Rekey Of GL
From time to time, the GL will need to be rekeyed. Some situations From time to time, the GL will need to be rekeyed. Some situations
follow: follow:
- When a member is removed from a closed or managed GL. In this - When a member is removed from a closed or managed GL. In this
case, the PKIData.controlSequence containing the glDeleteMember case, the PKIData.controlSequence containing the glDeleteMember
ought to contain a glRekey request. ought to contain a glRekey request.
- Depending on policy, when a member is removed from an unmanaged - Depending on policy, when a member is removed from an unmanaged
GL. If the policy is to rekey the GL, the GL. If the policy is to rekey the GL, the
PKIData.controlSequence containing the glDeleteMember could also PKIData.controlSequence containing the glDeleteMember could also
contain a glRekey request or an out of bands means could be used 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 to tell the GLA to rekey the GL. Rekeying of unmanaged GLs when
members are deleted is not advised. members are deleted is not advised.
- When the current shared KEK has been compromised. - When the current shared KEK has been compromised.
Turner 50
And Distribution
- When the current shared KEK is about to expire. Consider two - When the current shared KEK is about to expire. Consider two
cases: cases:
- If the GLO controls the GL rekey, the GLA should not assume - If the GLO controls the GL rekey, the GLA should not assume
that a new shared KEK should be distributed, but instead wait that a new shared KEK should be distributed, but instead wait
for the glRekey message. for the glRekey message.
- If the GLA controls the GL rekey, the GLA should initiate a - If the GLA controls the GL rekey, the GLA should initiate a
glKey message as specified in section 5. glKey message as specified in section 5.
skipping to change at line 2620 skipping to change at line 2789
The GLA and GLO are the only entities allowed to initiate a GL The GLA and GLO are the only entities allowed to initiate a GL
rekey. The GLO indicated whether they are going to control rekeys or rekey. The GLO indicated whether they are going to control rekeys or
whether the GLA is going to control rekeys when they assigned the whether the GLA is going to control rekeys when they assigned the
shared KEK to GL (see section 3.1.1). The GLO initiates a GL rekey shared KEK to GL (see section 3.1.1). The GLO initiates a GL rekey
at any time. The GLA can be configured to automatically rekey the GL at any time. The GLA can be configured to automatically rekey the GL
prior to the expiration of the shared KEK (the length of time before prior to the expiration of the shared KEK (the length of time before
the expiration is an implementation decision). The GLA can also the expiration is an implementation decision). The GLA can also
automatically rekey GLs that have been compromised, but this is automatically rekey GLs that have been compromised, but this is
covered in section 5. Figure 7 depicts the protocol interactions to covered in section 5. Figure 7 depicts the protocol interactions to
request a GL rekey. Note that error messages are not depicted. request a GL rekey. Note that error messages are not depicted.
Additionally, behavior for the optional transactionId, senderNonce,
and recipientNonce CMC control attributes is not addressed in these
procedures.
+-----+ 1 2,A +-----+ +-----+ 1 2,A +-----+
| GLA | <-------> | GLO | | GLA | <-------> | GLO |
+-----+ +-----+ +-----+ +-----+
Turner Expires June 2003 53
And Distribution
Figure 7 - GL Rekey Request Figure 7 - GL Rekey Request
4.5.1 GLO Initiated Rekey Requests 4.5.1 GLO Initiated Rekey Requests
The process for GLO initiated glRekey requests is as follows: The process for GLO initiated glRekey requests is as follows:
1 - The GLO sends a SignedData.PKIData.controlSequence.glRekey 1 - The GLO sends a SignedData.PKIData.controlSequence.glRekey
request to the GLA (1 in Figure 7). The GLO includes the request to the GLA (1 in Figure 7). The GLO includes the
glName. If glAdministration and glKeyNewAttributes are omitted glName. If glAdministration and glKeyNewAttributes are omitted
then there is no change from the previously registered GL then there is no change from the previously registered GL
values for these fields. If the GLO wants to force a rekey for values for these fields. If the GLO wants to force a rekey for
all outstanding shared KEKs it includes the glRekeyAllGLKeys all outstanding shared KEKs it includes the glRekeyAllGLKeys
set to TRUE. set to TRUE. The GLO MUST also include a signingTime attribute
is included with this request.
1.a - The GLO can optionally apply confidentiality to the request 1.a - The GLO can optionally apply confidentiality to the request
by encapsulating the SignedData.PKIData in an EnvelopedData by encapsulating the SignedData.PKIData in an EnvelopedData
(see section 3.2.1.2). (see section 3.2.1.2).
1.b - The GLO can also optionally apply another SignedData over 1.b - The GLO can also optionally apply another SignedData over
the EnvelopedData (see section 3.2.1.2). the EnvelopedData (see section 3.2.1.2).
Turner 51 2 - Upon receipt of the request, the GLA checks the signingTime
And Distribution and verifies the signature on the inner most
SignedData.PKIData. If an additional SignedData and/or
EnvelopedData encapsulates the request (see section 3.2.1.2 or
3.2.2), the GLA verifies the outer signature and/or decrypt
the outer layer prior to verifying the signature on the inner
most SignedData.
2 - Upon receipt of the request, the GLA verifies the signature on 2.a - If the signingTime attribute value is not within the locally
the inner most SignedData.PKIData. If an additional SignedData accepted time window, the GLA MAY return a response
and/or EnvelopedData encapsulates the request (see section indicating cMCStatus.failed and otherInfo.failInfo.badTime
3.2.1.2 or 3.2.2), the GLA verifies the outer signature and/or and a signingTime attribute.
decrypt the outer layer prior to verifying the signature on
the inner most SignedData.
2.a - If the signatures do not verify, the GLA returns a 2.c - Else if signature processing continues and if the signatures
cMCStatusInfoExt response indicating cMCStatus.failed and do not verify, the GLA returns a cMCStatusInfoExt response
otherInfo.failInfo.badMessageCheck. indicating cMCStatus.failed and
otherInfo.failInfo.badMessageCheck. Additionally, a
signingTime attribute is included with the response.
2.b - Else if the signatures do verify, the GLA makes sure the GL 2.c - Else if the signatures do verify, the GLA makes sure the GL
is supported by the GLA by checking that the glName matches is supported by the GLA by checking that the glName matches
a glName stored on the GLA. a glName stored on the GLA.
2.b.1 - If the glName present does not match a GL stored on the 2.c.1 - If the glName present does not match a GL stored on the
GLA, the GLA returns a response indicating GLA, the GLA returns a response indicating
cMCStatusInfoExt with cMCStatus.failed and cMCStatusInfoExt with cMCStatus.failed and
otherInfo.extendedFailInfo.SKDFailInfo value of otherInfo.extendedFailInfo.SKDFailInfo value of
invalidGLName. invalidGLName. Additionally, a signingTime attribute is
included with the response.
2.b.2 - Else if the glName present matches a GL stored on the GLA, Turner Expires June 2003 54
And Distribution
2.c.2 - Else if the glName present matches a GL stored on the GLA,
the GLA checks that a registered GLO signed the request by the GLA checks that a registered GLO signed the request by
checking that one of the names in the certificate used to checking that one of the names in the certificate used to
sign the request is a registered GLO. sign the request is a registered GLO.
2.b.2.a - If the names do not match, the GLA returns a response 2.c.2.a - If the names do not match, the GLA returns a response
indicating cMCStatusInfoExt with cMCStatus.failed and indicating cMCStatusInfoExt with cMCStatus.failed and
otherInfo.extendedFailInfo.SKDFailInfo value of otherInfo.extendedFailInfo.SKDFailInfo value of
noGLONameMatch. noGLONameMatch. Additionally, a signingTime attribute is
included with the response.
2.b.2.b - Else if the names match, the GLA checks the 2.c.2.b - Else if the names match, the GLA checks the
glNewKeyAttribute values. glNewKeyAttribute values.
2.b.2.b.1 - If the new value for requestedAlgorithm is not 2.c.2.b.1 - If the new value for requestedAlgorithm is not
supported, the GLA returns a response indicating supported, the GLA returns a response indicating
cMCStatusInfoExt with cMCStatus.failed and cMCStatusInfoExt with cMCStatus.failed and
otherInfo.extendedFailInfo.SKDFailInfo value of otherInfo.extendedFailInfo.SKDFailInfo value of
unsupportedAlgorithm. unsupportedAlgorithm. Additionally, a signingTime
attribute is included with the response.
2.b.2.b.2 - Else if the new value duration is not supportable, 2.c.2.b.2 - Else if the new value duration is not supportable,
determining this is beyond the scope this document, determining this is beyond the scope this document,
the GLA returns a response indicating cMCStatusInfoExt the GLA returns a response indicating cMCStatusInfoExt
with cMCStatus.failed and with cMCStatus.failed and
otherInfo.extendedFailInfo.SKDFailInfo value of otherInfo.extendedFailInfo.SKDFailInfo value of
unsupportedDuration. unsupportedDuration. Additionally, a signingTime
attribute is included with the response.
2.b.2.b.3 - Else if the GL is not supportable for other reasons, 2.c.2.b.3 - Else if the GL is not supportable for other reasons,
which the GLA does not wish to disclose, the GLA which the GLA does not wish to disclose, the GLA
returns a response indicating cMCStatusInfoExt with returns a response indicating cMCStatusInfoExt with
cMCStatus.failed and cMCStatus.failed and
Turner 52
And Distribution
otherInfo.extendedFailInfo.SKDFailInfo value of otherInfo.extendedFailInfo.SKDFailInfo value of
unspecified. unspecified. Additionally, a signingTime attribute is
included with the response.
2.b.2.b.4 - Else if the new requestedAlgorithm and duration are 2.c.2.b.4 - Else if the new requestedAlgorithm and duration are
supportable or the glNewKeyAttributes was omitted, the supportable or the glNewKeyAttributes was omitted, the
GLA returns a cMCStatusInfoExt.cMCStatus.success (2 in GLA returns a cMCStatusInfoExt.cMCStatus.success and a
Figure 7). The GLA also uses the glKey message to sigingTime attribute (2 in Figure 7). The GLA also
distribute the rekey shared KEK (see section 5). uses the glKey message to distribute the rekey shared
KEK (see section 5).
2.b.2.b.4.a - The GLA applies confidentiality to response by 2.c.2.b.4.a - The GLA applies confidentiality to response by
encapsulating the SignedData.PKIData in an encapsulating the SignedData.PKIData in an
EnvelopedData if the request was encapsulated in an EnvelopedData if the request was encapsulated in an
EnvelopedData (see section 3.2.1.2). EnvelopedData (see section 3.2.1.2).
2.b.2.b.4.b - The GLA can also optionally apply another SignedData 2.c.2.b.4.b - The GLA can also optionally apply another SignedData
over the EnvelopedData (see section 3.2.1.2). over the EnvelopedData (see section 3.2.1.2).
3 - Upon receipt of the cMCStatusInfoExt response, the GLO Turner Expires June 2003 55
verifies the GLA signature(s). If an additional SignedData And Distribution
and/or EnvelopedData encapsulates the forwarded response (see
section 3.2.1.2 or 3.2.2), the GLO verifies the outer
signature and/or decrypt the forwarded response prior to
verifying the signature on the inner most SignedData.
3.a - If the signatures verify, the GLO checks that one of the 3 - Upon receipt of the cMCStatusInfoExt response, the GLO checks
names in the certificate used to sign the response matches the signingTime and verifies the GLA signature(s). If an
the name of the GL. additional SignedData and/or EnvelopedData encapsulates the
forwarded response (see section 3.2.1.2 or 3.2.2), the GLO
verifies the outer signature and/or decrypt the forwarded
response prior to verifying the signature on the inner most
SignedData.
3.a.1 If the name of the GL does not match the name present in 3.a - If the signingTime attribute value is not within the locally
accepted time window, the GLA MAY return a response
indicating cMCStatus.failed and otherInfo.failInfo.badTime
and a signingTime attribute.
3.b - Else if signature processing continues and if the signatures
verify, the GLO checks that one of the names in the
certificate used to sign the response matches the name of
the GL.
3.b.1 - If the name of the GL does not match the name present in
the certificate used to sign the message, the GLO should the certificate used to sign the message, the GLO should
not believe the response. not believe the response.
3.a.2 Else if the name of the GL matches the name present in the 3.b.2 - Else if the name of the GL matches the name present in the
certificate and: certificate and:
3.a.2.a - If the signatures verify and the response is 3.b.2.a - If the signatures verify and the response is
cMCStatusInfoExt.cMCStatus.success, the GLO has cMCStatusInfoExt.cMCStatus.success, the GLO has
successfully rekeyed the GL. successfully rekeyed the GL.
3.a.2.b Else if the GLO received a 3.b.2.b - Else if the GLO received a
cMCStatusInfoExt.cMCStatus.failed with any reason, the cMCStatusInfoExt.cMCStatus.failed with any reason, the
GLO can reattempt to rekey the GL using the information GLO can reattempt to rekey the GL using the information
provided in the response. provided in the response.
Turner 53
And Distribution
4.5.2 GLA Initiated Rekey Requests 4.5.2 GLA Initiated Rekey Requests
If the GLA is in charge of rekeying the GL the GLA will If the GLA is in charge of rekeying the GL the GLA will
automatically issue a glKey message (see section 5). In addition the automatically issue a glKey message (see section 5). In addition the
GLA will generate a cMCStatusInfoExt to indicate to the GL that a GLA will generate a cMCStatusInfoExt to indicate to the GL that a
successful rekey has occurred. The process for GLA initiated rekey successful rekey has occurred. The process for GLA initiated rekey
is as follows: is as follows:
1 - The GLA generates for all GLOs a 1 - The GLA generates for all GLOs a
SignedData.PKIData.controlSequence.cMCStatusInfoExt.cMCStatus. SignedData.PKIData.controlSequence.cMCStatusInfoExt.cMCStatus.
success (A in Figure 7). success and includes a signingTime attribute (A in Figure 7).
1.a - The GLA can optionally apply confidentiality to the request 1.a - The GLA can optionally apply confidentiality to the request
by encapsulating the SignedData.PKIData in an EnvelopedData by encapsulating the SignedData.PKIData in an EnvelopedData
(see section 3.2.1.2). (see section 3.2.1.2).
Turner Expires June 2003 56
And Distribution
1.b - The GLA can also optionally apply another SignedData over 1.b - The GLA can also optionally apply another SignedData over
the EnvelopedData (see section 3.2.1.2). the EnvelopedData (see section 3.2.1.2).
2 - Upon receipt of the cMCStatusInfoExt.cMCStatus.success 2 - Upon receipt of the cMCStatusInfoExt.cMCStatus.success
response, the GLO verifies the GLA signature(s). If an response, the GLO checks the signingTime and verifies the GLA
additional SignedData and/or EnvelopedData encapsulates the signature(s). If an additional SignedData and/or EnvelopedData
forwarded response (see section 3.2.1.2 or 3.2.2), the GLO encapsulates the forwarded response (see section 3.2.1.2 or
MUST verify the outer signature and/or decrypt the outer layer 3.2.2), the GLO MUST verify the outer signature and/or decrypt
prior to verifying the signature on the inner most SignedData. the outer layer prior to verifying the signature on the inner
most SignedData.
2.a - If the signatures verify, the GLO checks that one of the 2.a - If the signingTime attribute value is not within the locally
names in the certificate used to sign the response matches accepted time window, the GLO MAY return a response
the name of the GL. indicating cMCStatus.failed and otherInfo.failInfo.badTime
and a signingTime attribute.
2.a.1 If the name of the GL does not match the name present in 2.b - Else if signature processing continues and if the signatures
verify, the GLO checks that one of the names in the
certificate used to sign the response matches the name of
the GL.
2.b.1 - If the name of the GL does not match the name present in
the certificate used to sign the message, the GLO ought the certificate used to sign the message, the GLO ought
not believe the response. not believe the response.
2.a.2 Else if the name of the GL does match the name present in 2.b.2 - Else if the name of the GL does match the name present in
the certificate and and the response is the certificate and and the response is
cMCStatusInfoExt.cMCStatus.success, the GLO knows the GLA cMCStatusInfoExt.cMCStatus.success, the GLO knows the GLA
has successfully rekeyed the GL. has successfully rekeyed the GL.
4.6 Change GLO 4.6 Change GLO
Management of managed and closed GLs can become difficult for one Management of managed and closed GLs can become difficult for one
GLO if the GL membership grows large. To support distributing the GLO if the GL membership grows large. To support distributing the
workload, GLAs support having GLs be managed by multiple GLOs. The workload, GLAs support having GLs be managed by multiple GLOs. The
glAddOwner and glRemoveOwner messages are designed to support adding glAddOwner and glRemoveOwner messages are designed to support adding
and removing registered GLOs. Figure 8 depicts the protocol and removing registered GLOs. Figure 8 depicts the protocol
interactions to send glAddOwner and glRemoveOwner messages and the interactions to send glAddOwner and glRemoveOwner messages and the
resulting response messages. resulting response messages. Note that error messages are not shown.
Additionally, behavior for the optional transactionId, senderNonce,
Turner 54 and recipientNonce CMC control attributes is not addressed in these
And Distribution procedures.
+-----+ 1 2 +-----+ +-----+ 1 2 +-----+
| GLA | <-------> | GLO | | GLA | <-------> | GLO |
+-----+ +-----+ +-----+ +-----+
Figure 8 - GLO Add & Delete Owners Figure 8 - GLO Add & Delete Owners
Turner Expires June 2003 57
And Distribution
The process for glAddOwner and glDeleteOwner is as follows: The process for glAddOwner and glDeleteOwner is as follows:
1 - The GLO sends a SignedData.PKIData.controlSequence.glAddOwner 1 - The GLO sends a SignedData.PKIData.controlSequence.glAddOwner
or glRemoveOwner request to the GLA (1 in Figure 8). The GLO or glRemoveOwner request to the GLA (1 in Figure 8). The GLO
includes: the GL name in glName, the name and address of the includes: the GL name in glName, the name and address of the
GLO in glOwnerName and glOwnerAddress, respectively. GLO in glOwnerName and glOwnerAddress, respectively. The GLO
MUST also include the signingTime attribute with this request.
1.a - The GLO can optionally apply confidentiality to the request 1.a - The GLO can optionally apply confidentiality to the request
by encapsulating the SignedData.PKIData in an EnvelopedData by encapsulating the SignedData.PKIData in an EnvelopedData
(see section 3.2.1.2). (see section 3.2.1.2).
1.b - The GLO can also optionally apply another SignedData over 1.b - The GLO can also optionally apply another SignedData over
the EnvelopedData (see section 3.2.1.2). the EnvelopedData (see section 3.2.1.2).
2 - Upon receipt of the glAddOwner or glRemoveOwner request, the 2 - Upon receipt of the glAddOwner or glRemoveOwner request, the
GLA verifies the GLO signature(s). If an additional SignedData GLA checks the signingTime and verifies the GLO signature(s).
and/or EnvelopedData encapsulates the request (see section If an additional SignedData and/or EnvelopedData encapsulates
3.2.1.2 or 3.2.2), the GLA verifies the outer signature and/or the request (see section 3.2.1.2 or 3.2.2), the GLA verifies
decrypt the outer layer prior to verifying the signature on the outer signature and/or decrypt the outer layer prior to
the inner most SignedData. verifying the signature on the inner most SignedData.
2.a - If the signatures cannot verified, the GLA returns a 2.a - If the signingTime attribute value is not within the locally
cMCStatusInfoExt response indicating cMCStatus.failed and accepted time window, the GLA MAY return a response
otherInfo.failInfo.badMessageCheck. indicating cMCStatus.failed and otherInfo.failInfo.badTime
and a signingTime attribute.
2.b - Else if the signatures verify, the GLA makes sure the GL is 2.b - Else if signature processing continues and if the signatures
cannot verified, the GLA returns a cMCStatusInfoExt response
indicating cMCStatus.failed and
otherInfo.failInfo.badMessageCheck. Additionally, a
signingTime attribute is included with the response.
2.c - Else if the signatures verify, the GLA makes sure the GL is
supported by checking that the glName matches a glName supported by checking that the glName matches a glName
stored on the GLA. stored on the GLA.
2.b.1 - If the glName is not supported by the GLA, the GLA returns 2.c.1 - If the glName is not supported by the GLA, the GLA returns
a response indicating cMCStatusInfoExt with a response indicating cMCStatusInfoExt with
cMCStatus.failed and cMCStatus.failed and
otherInfo.extendedFailInfo.SKDFailInfo value of otherInfo.extendedFailInfo.SKDFailInfo value of
invalidGLName. invalidGLName. Additionally, a signingTime attribute is
included with the response.
2.b.2 - Else if the glName is supported by the GLA, the GLA 2.c.2 - Else if the glName is supported by the GLA, the GLA
ensures a registered GLO signed the glAddOwner or ensures a registered GLO signed the glAddOwner or
glRemoveOwner request by checking that one of the names glRemoveOwner request by checking that one of the names
present in the digital signature certificate used to sign present in the digital signature certificate used to sign
the glAddOwner or glDeleteOwner request matches the name the glAddOwner or glDeleteOwner request matches the name
of a registered GLO. of a registered GLO.
2.b.2.a - If the names do not match, the GLA returns a response Turner Expires June 2003 58
And Distribution
2.c.2.a - If the names do not match, the GLA returns a response
indicating cMCStatusInfoExt with cMCStatus.failed and indicating cMCStatusInfoExt with cMCStatus.failed and
otherInfo.extendedFailInfo.SKDFailInfo value of otherInfo.extendedFailInfo.SKDFailInfo value of
noGLONameMatch. noGLONameMatch. Additionally, a signingTime attribute is
included with the response.
Turner 55
And Distribution
2.b.2.b - Else if the names match, the GLA returns a 2.c.2.b - Else if the names match, the GLA returns a
cMCStatusInfoExt.cMCStatus.success (2 in Figure 4). The cMCStatusInfoExt.cMCStatus.success and a signingTime
GLA also takes administrative actions to associate the attribute (2 in Figure 4). The GLA also takes
new glOwnerName with the GL in the case of glAddOwner or administrative actions to associate the new glOwnerName
to disassociate the old glOwnerName with the GL in the with the GL in the case of glAddOwner or to disassociate
cased of glRemoveOwner. the old glOwnerName with the GL in the cased of
glRemoveOwner.
2.b.2.b.1 - The GLA applies confidentiality to the response by 2.c.2.b.1 - The GLA applies confidentiality to the response by
encapsulating the SignedData.PKIResponse in an encapsulating the SignedData.PKIResponse in an
EnvelopedData if the request was encapsulated in an EnvelopedData if the request was encapsulated in an
EnvelopedData (see section 3.2.1.2). EnvelopedData (see section 3.2.1.2).
2.b.2.b.2 - The GLA can also optionally apply another SignedData 2.c.2.b.2 - The GLA can also optionally apply another SignedData
over the EnvelopedData (see section 3.2.1.2). over the EnvelopedData (see section 3.2.1.2).
3 - Upon receipt of the cMCStatusInfoExt response, the GLO 3 - Upon receipt of the cMCStatusInfoExt response, the GLO checks
verifies the GLA's signature(s). If an additional SignedData the signingTime and verifies the GLA's signature(s). If an
and/or EnvelopedData encapsulates the response (see section additional SignedData and/or EnvelopedData encapsulates the
3.2.1.2 or 3.2.2), the GLO verifies the outer signature and/or response (see section 3.2.1.2 or 3.2.2), the GLO verifies the
decrypt the outer layer prior to verifying the signature on outer signature and/or decrypt the outer layer prior to
the inner most SignedData. verifying the signature on the inner most SignedData.
3.a - If the signatures verify, the GLO checks that one of the 3.a - If the signingTime attribute value is not within the locally
names in the certificate used to sign the response matches accepted time window, the GLO MAY return a response
the name of the GL. indicating cMCStatus.failed and otherInfo.failInfo.badTime
and a signingTime attribute.
3.a.1 If the name of GL does not match the name present in the 3.b - Else if signature processing continues and if the signatures
verify, the GLO checks that one of the names in the
certificate used to sign the response matches the name of
the GL.
3.b.1 If the name of GL does not match the name present in the
certificate used to sign the message, the GLO should not certificate used to sign the message, the GLO should not
believe the response. believe the response.
3.a.2 Else if the name of the GL does match the name present in 3.b.2 Else if the name of the GL does match the name present in
the certificate and: the certificate and:
3.a.2.a - If the signatures verify and the response was 3.b.2.a - If the signatures verify and the response was
cMCStatusInfoExt.cMCStatus.success, the GLO has cMCStatusInfoExt.cMCStatus.success, the GLO has
successfully added or removed the GLO. successfully added or removed the GLO.
3.a.2.b - Else if the signatures verify and the response was 3.b.2.b - Else if the signatures verify and the response was
cMCStatusInfoExt.cMCStatus.failed with any reason, the cMCStatusInfoExt.cMCStatus.failed with any reason, the
Turner Expires June 2003 59
And Distribution
GLO can reattempt to add or delete the GLO using the GLO can reattempt to add or delete the GLO using the
information provided in the response. information provided in the response.
4.7 Indicate KEK Compromise 4.7 Indicate KEK Compromise
There will be times when the shared KEK is compromised. GL members There will be times when the shared KEK is compromised. GL members
and GLOs use glkCompromise to tell the GLA that the shared KEK has and GLOs use glkCompromise to tell the GLA that the shared KEK has
been compromised. Figure 9 depicts the protocol interactions for GL been compromised. Figure 9 depicts the protocol interactions for GL
Key Compromise. Key Compromise. Note that error messages are not shown.
Additionally, behavior for the optional transactionId, senderNonce,
Turner 56 and recipientNonce CMC control attributes is not addressed in these
And Distribution procedures.
+-----+ 2{1} 4 +----------+ +-----+ 2{1} 4 +----------+
| GLO | <----------+ +-------> | Member 1 | | GLO | <----------+ +-------> | Member 1 |
+-----+ 5,3{1} | | +----------+ +-----+ 5,3{1} | | +----------+
+-----+ <----------+ | 4 +----------+ +-----+ <----------+ | 4 +----------+
| GLA | 1 +-------> | ... | | GLA | 1 +-------> | ... |
+-----+ <---------------+ +----------+ +-----+ <---------------+ +----------+
| 4 +----------+ | 4 +----------+
+-------> | Member n | +-------> | Member n |
+----------+ +----------+
skipping to change at line 2931 skipping to change at line 3158
Figure 9 - GL Key Compromise Figure 9 - GL Key Compromise
4.7.1 GL Member Initiated KEK Compromise Message 4.7.1 GL Member Initiated KEK Compromise Message
The process for GL member initiated glkCompromise messages is as The process for GL member initiated glkCompromise messages is as
follows: follows:
1 - The GL member sends a 1 - The GL member sends a
SignedData.PKIData.controlSequence.glkCompromise request to SignedData.PKIData.controlSequence.glkCompromise request to
the GLA (1 in Figure 9). The GL member includes the name of the GLA (1 in Figure 9). The GL member includes the name of
the GL in GeneralName. the GL in GeneralName. The GL member MUST also include the
signingTime attribute with this request.
1.a - The GL member can optionally apply confidentiality to the 1.a - The GL member can optionally apply confidentiality to the
request by encapsulating the SignedData.PKIData in an request by encapsulating the SignedData.PKIData in an
EnvelopedData (see section 3.2.1.2). The glkCompromise can EnvelopedData (see section 3.2.1.2). The glkCompromise can
be included in an EnvelopedData generated with the be included in an EnvelopedData generated with the
compromised shared KEK. compromised shared KEK.
1.b - The GL member can also optionally apply another SignedData 1.b - The GL member can also optionally apply another SignedData
over the EnvelopedData (see section 3.2.1.2). over the EnvelopedData (see section 3.2.1.2).
2 - Upon receipt of the glkCompromise request, the GLA verifies 2 - Upon receipt of the glkCompromise request, the GLA checks the
the GL member signature(s). If an additional SignedData and/or signingTime and verifies the GL member signature(s). If an
EnvelopedData encapsulates the request (see section 3.2.1.2 or additional SignedData and/or EnvelopedData encapsulates the
3.2.2), the GLA verifies the outer signature and/or decrypt request (see section 3.2.1.2 or 3.2.2), the GLA verifies the
the outer layer prior to verifying the signature on the inner outer signature and/or decrypt the outer layer prior to
most SignedData. verifying the signature on the inner most SignedData.
2.a - If the signatures cannotbe verified, the GLA returns a Turner Expires June 2003 60
cMCStatusInfoExt response indicating cMCStatus.failed and And Distribution
otherInfo.failInfo.badMessageCheck.
2.b - Else if the signatures verify, the GLA makes sure the GL is 2.a - If the signingTime attribute value is not within the locally
accepted time window, the GLA MAY return a response
indicating cMCStatus.failed and otherInfo.failInfo.badTime
and a signingTime attribute.
2.b - Else if signature processing continues and if the signatures
cannotbe verified, the GLA returns a cMCStatusInfoExt
response indicating cMCStatus.failed and
otherInfo.failInfo.badMessageCheck. Additionally, a
signingTime attribute is included with the response.
2.c - Else if the signatures verify, the GLA makes sure the GL is
supported by checking that the indicated GL name matches a supported by checking that the indicated GL name matches a
glName stored on the GLA. glName stored on the GLA.
2.b.1 - If the glName is not supported by the GLA, the GLA returns 2.c.1 - If the glName is not supported by the GLA, the GLA returns
a response indicating cMCStatusInfoExt with a response indicating cMCStatusInfoExt with
cMCStatus.failed and cMCStatus.failed and
otherInfo.extendedFailInfo.SKDFailInfo value of otherInfo.extendedFailInfo.SKDFailInfo value of
invalidGLName. invalidGLName. Additionally, a signingTime attribute is
included with the response.
Turner 57
And Distribution
2.b.2 - Else if the glName is supported by the GLA, the GLA checks 2.c.2 - Else if the glName is supported by the GLA, the GLA checks
who signed the request. For GLOs, one of the names in the who signed the request. For GLOs, one of the names in the
certificate used to sign the request needs to match a certificate used to sign the request needs to match a
registered GLO. For the member, the name in registered GLO. For the member, the name in
glMember.glMemberName needs to match one of the names in glMember.glMemberName needs to match one of the names in
the certificate used to sign the request. the certificate used to sign the request.
2.b.2.a - If the GLO signed the request, the GLA generates a glKey 2.c.2.a - If the GLO signed the request, the GLA generates a glKey
message as described in section 5 to rekey the GL (4 in message as described in section 5 to rekey the GL (4 in
Figure 9). Figure 9).
2.b.2.b - Else if someone other than the GLO signed the request, 2.c.2.b - Else if someone other than the GLO signed the request,
the GLA forwards the glkCompromise message (see section the GLA forwards the glkCompromise message (see section
3.2.3) to the GLO (2{1} in Figure 9). If there is more 3.2.3) to the GLO (2{1} in Figure 9). If there is more
than one GLO, to which GLO the request is forwarded is than one GLO, to which GLO the request is forwarded is
beyond the scope of this document. Further processing by beyond the scope of this document. Further processing by
the GLO is discussed in section 4.7.2. the GLO is discussed in section 4.7.2.
4.7.2 GLO Initiated KEK Compromise Message 4.7.2 GLO Initiated KEK Compromise Message
The process for GLO initiated glkCompromise messages is as follows: The process for GLO initiated glkCompromise messages is as follows:
1 - The GLO either: 1 - The GLO either:
1.a - Generates the glkCompromise message itself by sending a 1.a - Generates the glkCompromise message itself by sending a
SignedData.PKIData.controlSequence.glkCompromise request to SignedData.PKIData.controlSequence.glkCompromise request to
the GLA (5 in Figure 9). The GLO includes the name of the GL the GLA (5 in Figure 9). The GLO includes the name of the GL
in GeneralName.
Turner Expires June 2003 61
And Distribution
in GeneralName. The GLO MUST also include a signingTime
attribute with this request.
1.a.1 - The GLO can optionally apply confidentiality to the 1.a.1 - The GLO can optionally apply confidentiality to the
request by encapsulating the SignedData.PKIData in an request by encapsulating the SignedData.PKIData in an
EnvelopedData (see section 3.2.1.2). The glkCompromise can EnvelopedData (see section 3.2.1.2). The glkCompromise can
be included in an EnvelopedData generated with the be included in an EnvelopedData generated with the
compromised shared KEK. compromised shared KEK.
1.a.2 - The GLO can also optionally apply another SignedData over 1.a.2 - The GLO can also optionally apply another SignedData over
the EnvelopedData (see section 3.2.1.2). the EnvelopedData (see section 3.2.1.2).
1.b Otherwise, verifies the GLA and GL member signatures on the 1.b Otherwise, checks the signingTime and verifies the GLA and
forwarded glkCompromise message. If an additional SignedData GL member signatures on the forwarded glkCompromise message.
and/or EnvelopedData encapsulates the request (see section If an additional SignedData and/or EnvelopedData
3.2.1.2 or 3.2.2), the GLO verifies the outer signature encapsulates the request (see section 3.2.1.2 or 3.2.2), the
and/or decrypt the outer layer prior to verifying the GLO verifies the outer signature and/or decrypt the outer
signature on the inner most SignedData. layer prior to verifying the signature on the inner most
SignedData.
1.b.1 - If the signatures cannot be verified, the GLO returns a 1.b.1 - If the signingTime attribute value is not within the
locally accepted time window, the GLO MAY return a
response indicating cMCStatus.failed and
otherInfo.failInfo.badTime and a signingTime attribute.
1.b.2 - Else if signature processing continues and if the
signatures cannot be verified, the GLO returns a
cMCStatusInfoExt response indicating cMCStatus.failed and cMCStatusInfoExt response indicating cMCStatus.failed and
otherInfo.failInfo.badMessageCheck. otherInfo.failInfo.badMessageCheck. Additionally, a
signingTime attribute is included with the response.
1.b.1.a - If the signatures verify, the GLO checks the names in 1.b.2.a - If the signatures verify, the GLO checks the names in
the certificate match the name of the signer (i.e., the the certificate match the name of the signer (i.e., the
Turner 58
And Distribution
name in the certificate used to sign the GL member's name in the certificate used to sign the GL member's
request is the GL member). request is the GL member).
1.b.1.a.1 If either name does not match, the GLO ought not trust 1.b.2.a.1 If either name does not match, the GLO ought not trust
the signer and it ought not forward the message to the the signer and it ought not forward the message to the
GLA. GLA.
1.b.1.a.2 Else if the names match and the signatures verify, the 1.b.2.a.2 Else if the names match and the signatures verify, the
GLO determines whether to forward the glkCompromise GLO determines whether to forward the glkCompromise
message back to the GLA (3{1} in Figure 9). Further message back to the GLA (3{1} in Figure 9). Further
processing by the GLA is in 2 of section 4.7.1. The processing by the GLA is in 2 of section 4.7.1. The
GLO can also return a response to the prospective GLO can also return a response to the prospective
member with cMCStatusInfoExt.cMCtatus.success member with cMCStatusInfoExt.cMCtatus.success
indicating that the glkCompromise message was indicating that the glkCompromise message was
successfully received. successfully received.
Turner Expires June 2003 62
And Distribution
4.8 Request KEK Refresh 4.8 Request KEK Refresh
There will be times when GL members have unrecoverably lost their There will be times when GL members have unrecoverably lost their
shared KEK. The shared KEK is not compromised and a rekey of the shared KEK. The shared KEK is not compromised and a rekey of the
entire GL is not necessary. GL members use the glkRefresh message to entire GL is not necessary. GL members use the glkRefresh message to
request that the shared KEK(s) be redistributed to them. Figure 10 request that the shared KEK(s) be redistributed to them. Figure 10
depicts the protocol interactions for GL Key Refresh. depicts the protocol interactions for GL Key Refresh. Note that
error messages are not shown. Additionally, behavior for the
optional transactionId, senderNonce, and recipientNonce CMC control
attributes is not addressed in these procedures.
+-----+ 1 2 +----------+ +-----+ 1 2 +----------+
| GLA | <-----------> | Member | | GLA | <-----------> | Member |
+-----+ +----------+ +-----+ +----------+
Figure 10 - GL KEK Refresh Figure 10 - GL KEK Refresh
The process for glkRefresh is as follows: The process for glkRefresh is as follows:
1 - The GL member sends a 1 - The GL member sends a
SignedData.PKIData.controlSequence.glkRefresh request to the SignedData.PKIData.controlSequence.glkRefresh request to the
GLA (1 in Figure 10). The GL member includes name of the GL in GLA (1 in Figure 10). The GL member includes name of the GL in
GeneralName. GeneralName. The GL member MUST also include a signingTime
attribute with this request.
1.a - The GL member can optionally apply confidentiality to the 1.a - The GL member can optionally apply confidentiality to the
request by encapsulating the SignedData.PKIData in an request by encapsulating the SignedData.PKIData in an
EnvelopedData (see section 3.2.1.2). EnvelopedData (see section 3.2.1.2).
1.b - The GL member can also optionally apply another SignedData 1.b - The GL member can also optionally apply another SignedData
over the EnvelopedData (see section 3.2.1.2). over the EnvelopedData (see section 3.2.1.2).
2 - Upon receipt of the glkRefresh request, the GLA verifies the 2 - Upon receipt of the glkRefresh request, the GLA checks the
GL member signature(s). If an additional SignedData and/or signingTime and verifies the GL member signature(s). If an
EnvelopedData encapsulates the request (see section 3.2.1.2 or additional SignedData and/or EnvelopedData encapsulates the
3.2.2), the GLA verifies the outer signature and/or decrypt request (see section 3.2.1.2 or 3.2.2), the GLA verifies the
the outer layer prior to verifying the signature on the inner outer signature and/or decrypt the outer layer prior to
most SignedData. verifying the signature on the inner most SignedData.
Turner 59 2.a - If the signingTime attribute value is not within the locally
And Distribution accepted time window, the GLA MAY return a response
indicating cMCStatus.failed and otherInfo.failInfo.badTime
and a signingTime attribute.
2.a - If the signatures cannot be verified, the GLA returns a 2.b - Else if signature processing continues and if the signatures
cMCStatusInfoExt response indicating cMCStatus.failed and cannot be verified, the GLA returns a cMCStatusInfoExt
otherInfo.failInfo.badMessageCheck. response indicating cMCStatus.failed and
otherInfo.failInfo.badMessageCheck. Additionally, a
signingTime attribute is included with the response.
2.b - Else if the signatures verify, the GLA makes sure the GL is Turner Expires June 2003 63
And Distribution
2.c - Else if the signatures verify, the GLA makes sure the GL is
supported by checking that the GLGeneralName matches a supported by checking that the GLGeneralName matches a
glName stored on the GLA. glName stored on the GLA.
2.b.1 - If the name of the GL is not supported by the GLA, the GLA 2.c.1 - If the name of the GL is not supported by the GLA, the GLA
returns a response indicating cMCStatusInfoExt with returns a response indicating cMCStatusInfoExt with
cMCStatus.failed and cMCStatus.failed and
otherInfo.extendedFailInfo.SKDFailInfo value of otherInfo.extendedFailInfo.SKDFailInfo value of
invalidGLName. invalidGLName. Additionally, a signingTime attribute is
included with the response.
2.b.2 Else if the glName is supported by the GLA, the GLA 2.c.2 - Else if the glName is supported by the GLA, the GLA
ensures the GL member is on the GL. ensures the GL member is on the GL.
2.b.2.a - If the glMemberName is not present on the GL, the GLA 2.c.2.a - If the glMemberName is not present on the GL, the GLA
returns a response indicating cMCStatusInfoExt with returns a response indicating cMCStatusInfoExt with
cMCStatus.failed and cMCStatus.failed and
otherInfo.extendedFailInfo.SKDFailInfo value of noSpam. otherInfo.extendedFailInfo.SKDFailInfo value of noSpam.
Additionally, a signingTime attribute is included with
the response.
2.b.2.b - Else if the glMemberName is present on the GL, the GLA 2.c.2.b - Else if the glMemberName is present on the GL, the GLA
returns a cMCStatusInfoExt.cMCStatus.success and a glKey returns a cMCStatusInfoExt.cMCStatus.success, a
message (2 in Figure 10) as described in section 5. signingTime attribute, and a glKey message (2 in Figure
10) as described in section 5.
4.9 GLA Query Request and Response 4.9 GLA Query Request and Response
There will be certain times when a GLO is having trouble setting up There will be certain times when a GLO is having trouble setting up
a GL because they do not know the algorithm(s) or some other a GL because they do not know the algorithm(s) or some other
characteristic that the GLA supports. There can also be times when characteristic that the GLA supports. There can also be times when
prospective GL members or GL members need to know something about prospective GL members or GL members need to know something about
the GLA (these requests are not defined in the document). The the GLA (these requests are not defined in the document). The
glaQueryRequest and glaQueryResponse message have been defined to glaQueryRequest and glaQueryResponse message have been defined to
support determining this information. Figure 11 depicts the protocol support determining this information. Figure 11 depicts the protocol
interactions for glaQueryRequest and glaQueryResponse. interactions for glaQueryRequest and glaQueryResponse. Note error
messages are not shown. Additionally, behavior for the optional
transactionId, senderNonce, and recipientNonce CMC control
attributes is not addressed in these procedures.
+-----+ 1 2 +------------------+ +-----+ 1 2 +------------------+
| GLA | <-------> | GLO or GL Member | | GLA | <-------> | GLO or GL Member |
+-----+ +------------------+ +-----+ +------------------+
Figure 11 - GLA Query Request & Response Figure 11 - GLA Query Request & Response
The process for glaQueryRequest and glaQueryResponse is as follows: The process for glaQueryRequest and glaQueryResponse is as follows:
1 - The GLO, GL member, or prospective GL member sends a 1 - The GLO, GL member, or prospective GL member sends a
SignedData.PKIData.controlSequence.glaQueryRequest request to SignedData.PKIData.controlSequence.glaQueryRequest request to
the GLA (1 in Figure 11). The GLO, GL member, or prospective
Turner 60 Turner Expires June 2003 64
And Distribution And Distribution
the GLA (1 in Figure 11). The GLO, GL member, or prospective
GL member indicates the information they are interested in GL member indicates the information they are interested in
receiving from the GLA. receiving from the GLA. Additionally, a signingTime attribute
is included with this request.
1.a - The GLO, GL member, or prospective GL member can optionally 1.a - The GLO, GL member, or prospective GL member can optionally
apply confidentiality to the request by encapsulating the apply confidentiality to the request by encapsulating the
SignedData.PKIData in an EnvelopedData (see section SignedData.PKIData in an EnvelopedData (see section
3.2.1.2). 3.2.1.2).
1.b - The GLO, GL member, or prospective GL member can also 1.b - The GLO, GL member, or prospective GL member can also
optionally apply another SignedData over the EnvelopedData optionally apply another SignedData over the EnvelopedData
(see section 3.2.1.2). (see section 3.2.1.2).
2 - Upon receipt of the glaQueryRequest, the GLA determines if it 2 - Upon receipt of the glaQueryRequest, the GLA determines if it
accepts glaQueryRequest messages. accepts glaQueryRequest messages.
2.a - If the GLA does not accept glaQueryRequest messages, the GLA 2.a - If the GLA does not accept glaQueryRequest messages, the GLA
returns a cMCStatusInfoExt response indicating returns a cMCStatusInfoExt response indicating
cMCStatus.noSupport and any other information in cMCStatus.noSupport and any other information in
statusString. statusString.
2.b - Else if the GLA does accept GLAQueryRequests, the GLA 2.b - Else if the GLA does accept GLAQueryRequests, the GLA checks
verifies the GLO, GL member, or prospective GL member the signingTime and verifies the GLO, GL member, or
signature(s). If an additional SignedData and/or prospective GL member signature(s). If an additional
EnvelopedData encapsulates the request (see section 3.2.1.2 SignedData and/or EnvelopedData encapsulates the request
or 3.2.2), the GLA verifies the outer signature and/or (see section 3.2.1.2 or 3.2.2), the GLA verifies the outer
decrypt the outer layer prior to verifying the signature on signature and/or decrypt the outer layer prior to verifying
the inner most SignedData. the signature on the inner most SignedData.
2.b.1 - If the signatures cannot be verified, the GLA returns a 2.b.1 - If the signingTime attribute value is not within the
locally accepted time window, the GLA MAY return a
response indicating cMCStatus.failed and
otherInfo.failInfo.badTime and a signingTime attribute.
2.b.2 - Else if the signature processing continues and if the
signatures cannot be verified, the GLA returns a
cMCStatusInfoExt response indicating cMCStatus.failed and cMCStatusInfoExt response indicating cMCStatus.failed and
otherInfo.failInfo.badMessageCheck. otherInfo.failInfo.badMessageCheck. Additionally, a
signingTime attribute is included with the response.
2.b.2 - Else if the signatures verify, the GLA returns a 2.b.3 - Else if the signatures verify, the GLA returns a
glaQueryResponse (2 in Figure 11) with the correct glaQueryResponse (2 in Figure 11) with the correct
response if the glaRequestType is supported or return a response if the glaRequestType is supported or return a
cMCStatusInfoExt response indicating cMCStatus.noSupport cMCStatusInfoExt response indicating cMCStatus.noSupport
if the glaRequestType is not supported. if the glaRequestType is not supported. Additionally, a
signingTime attribute is included with the response.
2.b.2.a - The GLA applies confidentiality to the response by 2.b.3.a - The GLA applies confidentiality to the response by
encapsulating the SignedData.PKIResponse in an encapsulating the SignedData.PKIResponse in an
EnvelopedData if the request was encapsulated in an EnvelopedData if the request was encapsulated in an
EnvelopedData (see section 3.2.1.2). EnvelopedData (see section 3.2.1.2).
2.b.2.b - The GLA can also optionally apply another SignedData Turner Expires June 2003 65
And Distribution
2.b.3.b - The GLA can also optionally apply another SignedData
over the EnvelopedData (see section 3.2.1.2). over the EnvelopedData (see section 3.2.1.2).
3 - Upon receipt of the glaQueryResponse, the GLO, GL member, or 3 - Upon receipt of the glaQueryResponse, the GLO, GL member, or
prospective GL member verifies the GLA signature(s). If an prospective GL member checks the signingTime and verifies the
additional SignedData and/or EnvelopedData encapsulates the GLA signature(s). If an additional SignedData and/or
response (see section 3.2.1.2 or 3.2.2), the GLO, GL member, EnvelopedData encapsulates the response (see section 3.2.1.2
or prospective GL member verifies the outer signature and/or or 3.2.2), the GLO, GL member, or prospective GL member
verifies the outer signature and/or decrypt the outer layer
Turner 61 prior to verifying the signature on the inner most SignedData.
And Distribution
decrypt the outer layer prior to verifying the signature on 3.a - If the signingTime attribute value is not within the locally
the inner most SignedData. accepted time window, the GLO, GL member, or prospective GL
member MAY return a response indicating cMCStatus.failed and
otherInfo.failInfo.badTime and a signingTime attribute.
3.a - If the signatures do not verify, the GLO, GL member, or 3.b - Else if signature processing continues and if the signatures
prospective GL member returns a cMCStatusInfoExt response do not verify, the GLO, GL member, or prospective GL member
indicating cMCStatus.failed and returns a cMCStatusInfoExt response indicating
otherInfo.failInfo.badMessageCheck. cMCStatus.failed and otherInfo.failInfo.badMessageCheck.
Additionally, a signingTime attribute is included with the
response.
3.b - Else if the signatures verify, then the GLO, GL member, or 3.c - Else if the signatures verify, then the GLO, GL member, or
prospective GL member checks that one of the names in the prospective GL member checks that one of the names in the
certificate used to sign the response matches the name of certificate used to sign the response matches the name of
the GL. the GL.
3.b.1 If the name of the GL does not match the name present in 3.c.1 If the name of the GL does not match the name present in
the certificate used to sign the message, the GLO ought the certificate used to sign the message, the GLO ought
not believe the response. not believe the response.
3.b.2 - Else if the name of the GL matches the name present in the 3.c.2 - Else if the name of the GL matches the name present in the
certificate and the response was glaQueryResponse, then certificate and the response was glaQueryResponse, then
the GLO, GL member, or prospective GL member may use the the GLO, GL member, or prospective GL member may use the
information contained therein. information contained therein.
4.10 Update Member Certificate 4.10 Update Member Certificate
When the GLO generates a glAddMember request, when the GLA generates When the GLO generates a glAddMember request, when the GLA generates
a glKey message, or when the GLA processes a glAddMember there can a glKey message, or when the GLA processes a glAddMember there can
be instances when GL member's certificate has expired or is invalid. be instances when GL member's certificate has expired or is invalid.
In these instances the GLO or GLA may request that the GL member In these instances the GLO or GLA may request that the GL member
provide a new certificate to avoid the GLA from being unable to provide a new certificate to avoid the GLA from being unable to
generate a glKey message for the GL member. There might also be generate a glKey message for the GL member. There might also be
times when the GL member knows their certificate is about to expire times when the GL member knows their certificate is about to expire
or has been revoked and they will not be able to receive GL rekeys. or has been revoked and they will not be able to receive GL rekeys.
Behavior for the optional transactionId, senderNonce, and
recipientNonce CMC control attributes is not addressed in these
procedures.
Turner Expires June 2003 66
And Distribution
4.10.1 GLO and GLA Initiated Update Member Certificate 4.10.1 GLO and GLA Initiated Update Member Certificate
The process for GLO initiated glUpdateCert is as follows: The process for GLO initiated glUpdateCert is as follows:
1 - The GLO or GLA sends a 1 - The GLO or GLA sends a
SignedData.PKIData.controlSequence.glProvideCert request to SignedData.PKIData.controlSequence.glProvideCert request to
the GL member. The GLO or GLA indicates the GL name in glName the GL member. The GLO or GLA indicates the GL name in glName
and the GL member name in glMemberName. and the GL member name in glMemberName. Additionally, a
signingTime attribute is included with this request.
1.a - The GLO or GLA can optionally apply confidentiality to the 1.a - The GLO or GLA can optionally apply confidentiality to the
request by encapsulating the SignedData.PKIData in an request by encapsulating the SignedData.PKIData in an
EnvelopedData (see section 3.2.1.2). If the GL member's PKC EnvelopedData (see section 3.2.1.2). If the GL member's PKC
has been revoked, the GLO or GLA ought not use it to has been revoked, the GLO or GLA ought not use it to
generate the EnvelopedData that encapsulates the generate the EnvelopedData that encapsulates the
glProvideCert request. glProvideCert request.
1.b - The GLO or GLA can also optionally apply another SignedData 1.b - The GLO or GLA can also optionally apply another SignedData
over the EnvelopedData (see section 3.2.1.2). over the EnvelopedData (see section 3.2.1.2).
Turner 62
And Distribution
2 - Upon receipt of the glProvideCert message, the GL member 2 - Upon receipt of the glProvideCert message, the GL member
verifies the GLO or GLA signature(s). If an additional checks the signingTime and verifies the GLO or GLA
SignedData and/or EnvelopedData encapsulates the response (see signature(s). If an additional SignedData and/or EnvelopedData
section 3.2.1.2 or 3.2.2), the GL member verifies the outer encapsulates the response (see section 3.2.1.2 or 3.2.2), the
signature and/or decrypt the outer layer prior to verifying GL member verifies the outer signature and/or decrypt the
the signature on the inner most SignedData. outer layer prior to verifying the signature on the inner most
SignedData.
2.a - If the signatures cannot be verified, the GL member returns 2.a - If the signingTime attribute value is not within the locally
a cMCStatusInfoExt response indicating cMCStatus.failed and accepted time window, the GL member MAY return a response
otherInfo.failInfo.badMessageCheck. indicating cMCStatus.failed and otherInfo.failInfo.badTime
and a signingTime attribute.
2.b - Else if the signatures verify, the GL member generates a 2.b - Else if signature processing continues and if the signatures
cannot be verified, the GL member returns a cMCStatusInfoExt
response indicating cMCStatus.failed and
otherInfo.failInfo.badMessageCheck. Additionally, a
signingTime attribute is included with the response.
2.c - Else if the signatures verify, the GL member generates a
Signed.PKIResponse.controlSequence.glUpdateCert that Signed.PKIResponse.controlSequence.glUpdateCert that
includes the GL name in glName, the member name in includes the GL name in glName, the member name in
glMember.glMemberName, their encryption certificate in glMember.glMemberName, their encryption certificate in
glMember.certificates.pKC. The GL member can also include glMember.certificates.pKC. The GL member can also include
any attribute certificates associated with their encryption any attribute certificates associated with their encryption
certificate in glMember.certificates.aC, and the certificate in glMember.certificates.aC, and the
certification path associated with their encryption and certification path associated with their encryption and
attribute certificates in glMember.certificates.certPath. attribute certificates in glMember.certificates.certPath.
Additionally, a signingTime attribute is included with the
response.
2.a - The GL member can optionally apply confidentiality to the Turner Expires June 2003 67
And Distribution
2.c.1 - The GL member can optionally apply confidentiality to the
request by encapsulating the SignedData.PKIResponse in an request by encapsulating the SignedData.PKIResponse in an
EnvelopedData (see section 3.2.1.2). If the GL member's PKC EnvelopedData (see section 3.2.1.2). If the GL member's
has been revoked, the GL member ought not use it to generate PKC has been revoked, the GL member ought not use it to
the EnvelopedData that encapsulates the glProvideCert generate the EnvelopedData that encapsulates the
request. glProvideCert request.
2.b - The GL member can also optionally apply another SignedData 2.c.2 - The GL member can also optionally apply another SignedData
over the EnvelopedData (see section 3.2.1.2). over the EnvelopedData (see section 3.2.1.2).
3 - Upon receipt of the glUpdateCert message, the GLO or GLA 3 - Upon receipt of the glUpdateCert message, the GLO or GLA
verifies the GL member signature(s). If an additional checks the signingTime and verifies the GL member
SignedData and/or EnvelopedData encapsulates the response (see signature(s). If an additional SignedData and/or EnvelopedData
section 3.2.1.2 or 3.2.2), the GL member verifies the outer encapsulates the response (see section 3.2.1.2 or 3.2.2), the
signature and/or decrypt the outer layer prior to verifying GL member verifies the outer signature and/or decrypt the
the signature on the inner most SignedData. outer layer prior to verifying the signature on the inner most
SignedData.
3.a - If the signatures cannot be verified, the GLO or GLA returns 3.a - If the signingTime attribute value is not within the locally
a cMCStatusInfoExt response indicating cMCStatus.failed and accepted time window, the GLO or GLA MAY return a response
otherInfo.failInfo.badMessageCheck. indicating cMCStatus.failed and otherInfo.failInfo.badTime
and a signingTime attribute.
3.b - Else if the signatures verify, the GLO or GLA verifies the 3.b - Else if signature processing continues and if the signatures
cannot be verified, the GLO or GLA returns a
cMCStatusInfoExt response indicating cMCStatus.failed and
otherInfo.failInfo.badMessageCheck. Additionally, a
signingTime attribute is included with the response.
3.c - Else if the signatures verify, the GLO or GLA verifies the
member's encryption certificate. member's encryption certificate.
3.b.1 - If the member's encryption certificate cannot be verified, 3.c.1 - If the member's encryption certificate cannot be verified,
the GLO returns either another glProvideCert request or a the GLO returns either another glProvideCert request or a
cMCStatusInfoExt with cMCStatus.failed and the reason why cMCStatusInfoExt with cMCStatus.failed and the reason why
in cMCStatus.statusString. glProvideCert should be in cMCStatus.statusString. glProvideCert should be
returned only a certain number of times because if the GL returned only a certain number of times because if the GL
Turner 63
And Distribution
member does not have a valid certificate they will never member does not have a valid certificate they will never
be able to return one. be able to return one. Additionally, a signingTime
attribute is included with either response.
3.b.2 - Else if the member's encryption certificate cannot be 3.c.2 - Else if the member's encryption certificate cannot be
verified, the GLA returns another glProvideCert request to verified, the GLA returns another glProvideCert request to
the GL member or a cMCStatusInfoExt with cMCStatus.failed the GL member or a cMCStatusInfoExt with cMCStatus.failed
and the reason why in cMCStatus.statusString to the GLO. and the reason why in cMCStatus.statusString to the GLO.
glProvideCert should be returned only a certain number of glProvideCert should be returned only a certain number of
times because if the GL member does not have a valid times because if the GL member does not have a valid
certificate they will never be able to return one. certificate they will never be able to return one.
Additionally, a signingTime attribute is included with the
response.
3.b.3 - Else if the member's encryption certificate verifies, the Turner Expires June 2003 68
And Distribution
3.c.3 - Else if the member's encryption certificate verifies, the
GLO or GLA will use it in subsequent glAddMember requests GLO or GLA will use it in subsequent glAddMember requests
and glKey messages associated with the GL member. and glKey messages associated with the GL member.
4.10.2 GL Member Initiated Update Member Certificate 4.10.2 GL Member Initiated Update Member Certificate
The process for an unsolicited GL member glUpdateCert is as follows: The process for an unsolicited GL member glUpdateCert is as follows:
1 - The GL member sends a 1 - The GL member sends a
Signed.PKIData.controlSequence.glUpdateCert that includes the Signed.PKIData.controlSequence.glUpdateCert that includes the
GL name in glName, the member name in glMember.glMemberName, GL name in glName, the member name in glMember.glMemberName,
their encryption certificate in glMember.certificates.pKC. The their encryption certificate in glMember.certificates.pKC. The
GL member can also include any attribute certificates GL member can also include any attribute certificates
associated with their encryption certificate in associated with their encryption certificate in
glMember.certificates.aC, and the certification path glMember.certificates.aC, and the certification path
associated with their encryption and attribute certificates in associated with their encryption and attribute certificates in
glMember.certificates.certPath. glMember.certificates.certPath. The GL member MUST also
include a signingTime attribute with this request.
1.a - The GL member can optionally apply confidentiality to the 1.a - The GL member can optionally apply confidentiality to the
request by encapsulating the SignedData.PKIData in an request by encapsulating the SignedData.PKIData in an
EnvelopedData (see section 3.2.1.2). If the GL member's PKC EnvelopedData (see section 3.2.1.2). If the GL member's PKC
has been revoked, the GLO or GLA ought not use it to has been revoked, the GLO or GLA ought not use it to
generate the EnvelopedData that encapsulates the generate the EnvelopedData that encapsulates the
glProvideCert request. glProvideCert request.
1.b - The GL member can also optionally apply another SignedData 1.b - The GL member can also optionally apply another SignedData
over the EnvelopedData (see section 3.2.1.2). over the EnvelopedData (see section 3.2.1.2).
2 - Upon receipt of the glUpdateCert message, the GLA verifies the 2 - Upon receipt of the glUpdateCert message, the GLA checks the
GL member signature(s). If an additional SignedData and/or signingTime and verifies the GL member signature(s). If an
EnvelopedData encapsulates the response (see section 3.2.1.2 additional SignedData and/or EnvelopedData encapsulates the
or 3.2.2), the GLA verifies the outer signature and/or decrypt response (see section 3.2.1.2 or 3.2.2), the GLA verifies the
the outer layer prior to verifying the signature on the inner outer signature and/or decrypt the outer layer prior to
most SignedData. verifying the signature on the inner most SignedData.
2.a - If the signatures cannot be verified, the GLA returns a 2.a - If the signingTime attribute value is not within the locally
cMCStatusInfoExt response indicating cMCStatus.failed and accepted time window, the GLA MAY return a response
otherInfo.failInfo.badMessageCheck. indicating cMCStatus.failed and otherInfo.failInfo.badTime
and a signingTime attribute.
Turner 64 2.b - Else if signature processing continues and if the signatures
And Distribution cannot be verified, the GLA returns a cMCStatusInfoExt
response indicating cMCStatus.failed and
otherInfo.failInfo.badMessageCheck.
2.b - Else if the signatures verify, the GLA verifies the member's 2.c - Else if the signatures verify, the GLA verifies the member's
encryption certificate. encryption certificate.
2.b.1 - If the member's encryption certificate cannot be verified, 2.c.1 - If the member's encryption certificate cannot be verified,
the GLA returns another glProvideCert request to the GL the GLA returns another glProvideCert request to the GL
Turner Expires June 2003 69
And Distribution
member or a cMCStatusInfoExt with cMCStatus.failed and the member or a cMCStatusInfoExt with cMCStatus.failed and the
reason why in cMCStatus.statusString to the GLO. reason why in cMCStatus.statusString to the GLO.
glProvideCert ought not be returned indefinitely; if the glProvideCert ought not be returned indefinitely; if the
GL member does not have a valid certificate they will GL member does not have a valid certificate they will
never be able to return one. never be able to return one. Additionally, a signingTime
attribute is included with the response.
2.b.2 - Else if the member's encryption certificate verifies, the 2.c.2 - Else if the member's encryption certificate verifies, the
GLA will use it in subsequent glAddMember requests and GLA will use it in subsequent glAddMember requests and
glKey messages associated with the GL member. The GLA also glKey messages associated with the GL member. The GLA also
forwards the glUpdateCert message to the GLO. forwards the glUpdateCert message to the GLO.
5 Distribution Message 5 Distribution Message
The GLA uses the glKey message to distribute new, shared KEK(s) The GLA uses the glKey message to distribute new, shared KEK(s)
after receiving glAddMember, glDeleteMember (for closed and managed after receiving glAddMember, glDeleteMember (for closed and managed
GLs), glRekey, glkCompromise, or glkRefresh requests and returning a GLs), glRekey, glkCompromise, or glkRefresh requests and returning a
cMCStatusInfoExt response for the respective request. Figure 12 cMCStatusInfoExt response for the respective request. Figure 12
depicts the protocol interactions to send out glKey messages. Unlike depicts the protocol interactions to send out glKey messages. Unlike
the procedures defined for the administrative messages, the the procedures defined for the administrative messages, the
procedures defined in this section MUST be implemented by GLAs for procedures defined in this section MUST be implemented by GLAs for
origination and by GL members on reception. origination and by GL members on reception. Note that error messages
are not shown. Additionally, behavior for the optional
transactionId, senderNonce, and recipientNonce CMC control
attributes is not addressed in these procedures.
1 +----------+ 1 +----------+
+-------> | Member 1 | +-------> | Member 1 |
| +----------+ | +----------+
+-----+ | 1 +----------+ +-----+ | 1 +----------+
| GLA | ----+-------> | ... | | GLA | ----+-------> | ... |
+-----+ | +----------+ +-----+ | +----------+
| 1 +----------+ | 1 +----------+
+-------> | Member n | +-------> | Member n |
+----------+ +----------+
Figure 12 - GL Key Distribution Figure 12 - GL Key Distribution
If the GL was setup with GLKeyAttributes.recipientsNotMutuallyAware If the GL was setup with GLKeyAttributes.recipientsNotMutuallyAware
set to TRUE, a separate glKey message MUST be sent to each GL member set to TRUE, a separate glKey message MUST be sent to each GL member
so as to not divulge information about the other GL members. so as to not divulge information about the other GL members.
Turner 65
And Distribution
When the glKey message is generated as a result of a: When the glKey message is generated as a result of a:
- glAddMember request, - glAddMember request,
- glkComrpomise indication, - glkComrpomise indication,
- glkRefresh request, - glkRefresh request,
- glDeleteMember request with the GL's glAdministration set to - glDeleteMember request with the GL's glAdministration set to
managed or closed, and managed or closed, and
- glRekey request with generationCounter set to zero (0). - glRekey request with generationCounter set to zero (0).
The GLA MUST use either the kari (see section 12.3.2 of CMS [2]) or Turner Expires June 2003 70
ktri (see section 12.3.1 of CMS [2]) choice in And Distribution
The GLA MUST use either the kari (see section 12.3.2 of [CMS]) or
ktri (see section 12.3.1 of [CMS]) choice in
glKey.glkWrapped.RecipientInfo to ensure only the intended glKey.glkWrapped.RecipientInfo to ensure only the intended
recipients receive the shared KEK. The GLA MUST support the ktri recipients receive the shared KEK. The GLA MUST support the ktri
choice. choice.
When the glKey message is generated as a result of a glRekey request When the glKey message is generated as a result of a glRekey request
with generationCounter greater than zero (0) or when the GLA with generationCounter greater than zero (0) or when the GLA
controls rekeys, the GLA MAY use the kari, ktri, or kekri (see controls rekeys, the GLA MAY use the kari, ktri, or kekri (see
section 12.3.3 of CMS [2]) in glKey.glkWrapped.RecipientInfo to section 12.3.3 of [CMS]) in glKey.glkWrapped.RecipientInfo to ensure
ensure only the intended recipients receive the shared KEK. The GLA only the intended recipients receive the shared KEK. The GLA MUST
MUST support the RecipientInfo.ktri choice. support the RecipientInfo.ktri choice.
5.1 Distribution Process 5.1 Distribution Process
When a glKey message is generated the process is as follows: When a glKey message is generated the process is as follows:
1 - The GLA MUST send a SignedData.PKIData.controlSequence.glKey 1 - The GLA MUST send a SignedData.PKIData.controlSequence.glKey
to each member by including: glName, glIdentifier, glkWrapped, to each member by including: glName, glIdentifier, glkWrapped,
glkAlgorithm, glkNotBefore, and glkNotAfter. If the GLA can glkAlgorithm, glkNotBefore, and glkNotAfter. If the GLA can
not generate a glKey message for the GL member because the GL not generate a glKey message for the GL member because the GL
member's PKC has expired or is otherwise invalid, the GLA MAY member's PKC has expired or is otherwise invalid, the GLA MAY
send a glUpdateCert to the GL member requesting a new send a glUpdateCert to the GL member requesting a new
certificate be provided (see section 4.10). The number of certificate be provided (see section 4.10). The number of
glKey messages generated for the GL is described in section glKey messages generated for the GL is described in section
3.1.16. 3.1.16. Additionally, a signingTime attribute is included with
the distribution message(s).
1.a - The GLA MAY optionally apply another confidentiality layer 1.a - The GLA MAY optionally apply another confidentiality layer
to the message by encapsulating the SignedData.PKIData in to the message by encapsulating the SignedData.PKIData in
another EnvelopedData (see section 3.2.1.2). another EnvelopedData (see section 3.2.1.2).
1.b - The GLA MAY also optionally apply another SignedData over 1.b - The GLA MAY also optionally apply another SignedData over
the EnvelopedData.SignedData.PKIData (see section 3.2.1.2). the EnvelopedData.SignedData.PKIData (see section 3.2.1.2).
2 - Upon receipt of the glKey message, the GL members MUST verify 2 - Upon receipt of the glKey message, the GL members MUST check
the signature over the inner most SignedData.PKIData. If an the signingTime and verify the signature over the inner most
additional SignedData and/or EnvelopedData encapsulates the SignedData.PKIData. If an additional SignedData and/or
message (see section 3.2.1.2 or 3.2.2), the GL Member MUST EnvelopedData encapsulates the message (see section 3.2.1.2 or
verify the outer signature and/or decrypt the outer layer 3.2.2), the GL Member MUST verify the outer signature and/or
prior to verifying the signature on the decrypt the outer layer prior to verifying the signature on
SignedData.PKIData.controlSequence.glKey. the SignedData.PKIData.controlSequence.glKey.
Turner 66 2.a - If the signingTime attribute value is not within the locally
accepted time window, the GLA MAY return a response
indicating cMCStatus.failed and otherInfo.failInfo.badTime
and a signingTime attribute.
2.b - Else if signature processing continues and if the signatures
cannot be verified, the GL member MUST return a
Turner Expires June 2003 71
And Distribution And Distribution
2.a - If the signatures cannot be verified, the GL member MUST cMCStatusInfoExt response indicating cMCStatus.failed and
return a cMCStatusInfoExt response indicating otherInfo.failInfo.badMessageCheck. Additionally, a
cMCStatus.failed and otherInfo.failInfo.badMessageCheck. signingTime attribute is included with the response.
2.b - Else if the signatures verify, the GL member process the 2.c - Else if the signatures verify, the GL member process the
RecipientInfos according to CMS [2]. Once unwrapped the GL RecipientInfos according to [CMS]. Once unwrapped the GL
member should store the shared KEK in a safe place. When member should store the shared KEK in a safe place. When
stored, the glName, glIdentifier, and shared KEK should be stored, the glName, glIdentifier, and shared KEK should be
associated. Additionally, the GL member MUST return a associated. Additionally, the GL member MUST return a
cMCStatusInfoExt indicating cMCStatus.success to tell the cMCStatusInfoExt indicating cMCStatus.success to tell the
GLA the KEK was received. GLA the KEK was received.
6 Algorithms 6 Algorithms
This section lists the algorithms that MUST be implemented. This section lists the algorithms that MUST be implemented.
Additional algorithms that SHOULD be implemented are also included. Additional algorithms that SHOULD be implemented are also included.
skipping to change at line 3473 skipping to change at line 3802
Implementations MUST randomly generate content-encryption keys, Implementations MUST randomly generate content-encryption keys,
message-authentication keys, initialization vectors (IVs), and message-authentication keys, initialization vectors (IVs), and
padding. Also, the generation of public/private key pairs relies on padding. Also, the generation of public/private key pairs relies on
a random numbers. The use of inadequate pseudo-random number a random numbers. The use of inadequate pseudo-random number
generators (PRNGs) to generate cryptographic keys can result in generators (PRNGs) to generate cryptographic keys can result in
little or no security. An attacker may find it much easier to little or no security. An attacker may find it much easier to
reproduce the PRNG environment that produced the keys, searching the reproduce the PRNG environment that produced the keys, searching the
resulting small set of possibilities, rather than brute force resulting small set of possibilities, rather than brute force
searching the whole key space. The generation of quality random searching the whole key space. The generation of quality random
numbers is difficult. RFC 1750 [10] offers important guidance in numbers is difficult. RFC 1750 [RANDOM] offers important guidance
this area, and Appendix 3 of FIPS Pub 186 [11] provides one quality in this area, and Appendix 3 of FIPS Pub 186 [FIPS] provides one
PRNG technique. quality PRNG technique.
6.2 Shared KEK Wrap Algorithm 6.2 Shared KEK Wrap Algorithm
In the mechanisms described in sections 5, the shared KEK being In the mechanisms described in sections 5, the shared KEK being
distributed in glkWrapped MUST be protected by a key of equal or distributed in glkWrapped MUST be protected by a key of equal or
greater length (i.e., if a RC2 128-bit key is being distributed a 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). key of 128-bits or greater must be used to protect the key).
The algorithm object identifiers included in glkWrapped are as The algorithm object identifiers included in glkWrapped are as
specified in AlgSpec [12]. specified in AlgSpec [CMSALG].
6.3 Shared KEK Algorithm 6.3 Shared KEK Algorithm
The shared KEK distributed and indicated in glkAlgorithm MUST The shared KEK distributed and indicated in glkAlgorithm MUST
support the symmetric key-encryption algorithms as specified in support the symmetric key-encryption algorithms as specified in
section AlgSpec [12]. section AlgSpec [CMSALG].
Turner 67 Turner Expires June 2003 72
And Distribution And Distribution
7 Message Transport 7 Message Transport
SMTP [13] MUST be supported. Other transport mechanisms MAY also be SMTP [SMTP] MUST be supported. Other transport mechanisms MAY also
supported. be supported.
8 Security Considerations 8 Security Considerations
As GLOs control setting up and tearing down the GL, rekeying the GL, As GLOs control setting up and tearing down the GL, rekeying the GL,
and can control member additions and deletions, GLOs play an and can control member additions and deletions, GLOs play an
important role in the management of the GL, and only trusted GLOs important role in the management of the GL, and only "trusted" GLOs
should be used. should be used.
If a member is deleted or removed from a closed or a managed GL, the If a member is deleted or removed from a closed or a managed GL, the
GL needs to be rekeyed. If the GL is not rekeyed after a member is GL needs to be rekeyed. If the GL is not rekeyed after a member is
removed or deleted, the member still posses the group key and will removed or deleted, the member still posses the group key and will
be able to continue to decrypt any messages that can be obtained. be able to continue to decrypt any messages that can be obtained.
Members who store KEKs MUST associate the name of the GLA that Members who store KEKs MUST associate the name of the GLA that
distributed the key so that the members can make sure subsequent distributed the key so that the members can make sure subsequent
rekeys are originated from the same entity. rekeys are originated from the same entity.
skipping to change at line 3545 skipping to change at line 3874
An attacker can attack the group's shared KEK by attacking one An attacker can attack the group's shared KEK by attacking one
member's copy of the shared KEK or attacking multiple member's member's copy of the shared KEK or attacking multiple member's
copies of the shared KEK. For the attacker it may be easier to copies of the shared KEK. For the attacker it may be easier to
either attack the group member with the weakest security protecting either attack the group member with the weakest security protecting
their copy of the shared KEK or by attacking multiple group members. their copy of the shared KEK or by attacking multiple group members.
An aggregation of the information gathered during the attack(s) may An aggregation of the information gathered during the attack(s) may
lead to the compromise of the group's shared KEK. Mechanisms to lead to the compromise of the group's shared KEK. Mechanisms to
protect the shared KEK should be commensurate with value of the data protect the shared KEK should be commensurate with value of the data
being protected. being protected.
Turner 68 Turner Expires June 2003 73
And Distribution And Distribution
The nonce and signingTime attributes are used to protect against
replay attacks. However, these provisions are only helpful if
entities maintain state information about the messages they have
sent or received for comparison. If sufficient information is not
maintained on each exchange, nonces and signingTime are not helpful.
Local policy determines the amount and duration of state information
that is maintained. Additionally, without a unified time source,
there is the possibility of clocks drifting. Local policy determines
the acceptable difference between the local time and signingTime,
which must compensate for unsynchronized clock. Implementations MUST
handle messages with siginingTime attributes that indicate they were
created in the future.
9 References 9 References
1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9.1 Informative
9, RFC 2026, October 1996.
2 Housley, R., "Cryptographic Message Syntax," draft-ietf-smime- [STDWORDS] Bradner, S., "Key words for use in RFCs to Indicate
rfc2630bis-01.txt, April 2001. Requirement Levels", BCP 14, RFC 2119, March 1997.
3 Myers, M., Liu, X., Schaad, J., Weinsten, J., "Certificate [X400TRANS] Hoffman, P., and C. Bonatti, "Transporting S/MIME
Management Message over CMS," draft-ietf-pkix-2797-bis-00.txt, Objects in X.400", draft-ietf-smime-x400transport-05.txt, November
April 2001. 2002.
4 Bradner, S., "Key words for use in RFCs to Indicate Requirement [RANDOM] Eastlake, D., Crocker, S. and J. Schiller, "Randomness
Levels", BCP 14, RFC 2119, March 1997. Recommendations for Security", RFC 1750, December 1994.
5 Housley, R., Ford, W., Polk, W. and D. Solo, "Internet X.509 [FIPS] National Institute of Standards and Technology. FIPS Pub 186:
Public Key Infrastructure: Certificate and CRL Profile", draft- Digital Signature Standard. 19 May 1994.
ietf-pkix-new-part1-06.txt, 8 March 2001.
6 Farrell, S., Housley, R., An Internet Attribute Certificate 9.1 Normative
Profile for Authorization, draft-ietf-pkix-acx.509prof-06.txt,
10 January 2001.
7 Ramsdale, B., "S/MIME Version 3 Message Specification," TBD. [CMS] Housley, R., "Cryptographic Message Syntax," RFC 3369, August
2002.
8 Hoffman, P., and C. Bonatti, Transporting S/MIME Objects in [CMC] Myers, M., Liu, X., Schaad, J., Weinsten, J., "Certificate
X.400, draft-ietf-smime-x400transport-02.txt, May 2000. Management Message over CMS," draft-ietf-pkix-2797-bis-00.txt, April
2001.
9 Hoffman, P., Extended Security Services for S/MIME, RFC 2634, [PROFILE] Housley, R., Ford, W., Polk, W. and D. Solo, "Internet
June 1999. X.509 Public Key Infrastructure: Certificate and CRL Profile", RFC
3280, April 2002.
10 Eastlake, D., Crocker, S. and J. Schiller, "Randomness [ACPROF] Farrell, S., Housley, R., "An Internet Attribute
Recommendations for Security", RFC 1750, December 1994. Certificate Profile for Authorization", RFC 3281, April 2002.
11 National Institute of Standards and Technology. FIPS Pub 186: [MSG] Ramsdale, B., "S/MIME Version 3 Message Specification," RFC
Digital Signature Standard. 19 May 1994. 2633, June 1999.
12 Housley, R., Cryptographic Message Syntax (CMS) Algorithms, Turner Expires June 2003 74
draft-ietf-smime-cmsalg-01.txt, July 2001. And Distribution
13 Postel, j., "Simple Mail Transport Protocol," RFC 821, August [ESS] Hoffman, P., "Extended Security Services for S/MIME", RFC
2634, June 1999.
[CMSALG] 11 Housley, R., "Cryptographic Message Syntax (CMS)
Algorithms", RFC 3370, August 2002.
[SMTP] Postel, j., "Simple Mail Transport Protocol," RFC 821, August
1982. 1982.
10 Acknowledgements 10 Acknowledgements
Thanks to Russ Housley and Jim Schaad for providing much of the Thanks to Russ Housley and Jim Schaad for providing much of the
background and review required to write this document. background and review required to write this document.
Turner 69
And Distribution
11 Author's Addresses 11 Author's Addresses
Sean Turner Sean Turner
IECA, Inc. IECA, Inc.
9010 Edgepark Road
Vienna, VA 22182
Phone: +1.703.628.3180 Phone: +1.703.628.3180
Email: turners@ieca.com Email: turners@ieca.com
Turner 70 Turner Expires June 2003 75
And Distribution And Distribution
Annex A: ASN.1 Module Annex A: ASN.1 Module
SMIMESymmetricKeyDistribution SMIMESymmetricKeyDistribution
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
smime(16) modules(0) symkeydist(12) } smime(16) modules(0) symkeydist(12) }
DEFINITIONS IMPLICIT TAGS ::= DEFINITIONS IMPLICIT TAGS ::=
BEGIN BEGIN
skipping to change at line 3662 skipping to change at line 4004
-- This defines the GL symmetric key distribution object identifier -- This defines the GL symmetric key distribution object identifier
-- arc. -- arc.
id-skd OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) id-skd OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) skd(8) } rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) skd(8) }
-- This defines the GL Use KEK control attribute -- This defines the GL Use KEK control attribute
id-skd-glUseKEK OBJECT IDENTIFIER ::= { id-skd 1} id-skd-glUseKEK OBJECT IDENTIFIER ::= { id-skd 1}
Turner 71 Turner Expires June 2003 76
And Distribution And Distribution
GLUseKEK ::= SEQUENCE { GLUseKEK ::= SEQUENCE {
glInfo GLInfo, glInfo GLInfo,
glOwnerInfo SEQUENCE SIZE (1..MAX) OF GLOwnerInfo, glOwnerInfo SEQUENCE SIZE (1..MAX) OF GLOwnerInfo,
glAdministration GLAdministration DEFAULT 1, glAdministration GLAdministration DEFAULT 1,
glKeyAttributes GLKeyAttributes OPTIONAL } glKeyAttributes GLKeyAttributes OPTIONAL }
GLInfo ::= SEQUENCE { GLInfo ::= SEQUENCE {
glName GeneralName, glName GeneralName,
skipping to change at line 3713 skipping to change at line 4055
GLAddMember ::= SEQUENCE { GLAddMember ::= SEQUENCE {
glName GeneralName, glName GeneralName,
glMember GLMember } glMember GLMember }
GLMember ::= SEQUENCE { GLMember ::= SEQUENCE {
glMemberName GeneralName, glMemberName GeneralName,
glMemberAddress GeneralName OPTIONAL, glMemberAddress GeneralName OPTIONAL,
certificates Certificates OPTIONAL } certificates Certificates OPTIONAL }
Turner 72 Turner Expires June 2003 77
And Distribution And Distribution
Certificates ::= SEQUENCE { Certificates ::= SEQUENCE {
pKC [0] Certificate OPTIONAL, pKC [0] Certificate OPTIONAL,
-- See PKIX [5] -- See [PROFILE]
aC [1] SEQUENCE SIZE (1.. MAX) OF aC [1] SEQUENCE SIZE (1.. MAX) OF
AttributeCertificate OPTIONAL, AttributeCertificate OPTIONAL,
-- See ACPROF [6] -- See [ACPROF]
certPath [2] CertificateSet OPTIONAL } certPath [2] CertificateSet OPTIONAL }
-- From CMS [2] -- From [CMS]
-- This defines the Delete GL Member control attribute -- This defines the Delete GL Member control attribute
id-skd-glDeleteMember OBJECT IDENTIFIER ::= { id-skd 4} id-skd-glDeleteMember OBJECT IDENTIFIER ::= { id-skd 4}
GLDeleteMember ::= SEQUENCE { GLDeleteMember ::= SEQUENCE {
glName GeneralName, glName GeneralName,
glMemberToDelete GeneralName } glMemberToDelete GeneralName }
-- This defines the Delete GL Member control attribute -- This defines the Delete GL Member control attribute
skipping to change at line 3766 skipping to change at line 4108
glName GeneralName, glName GeneralName,
glOwnerInfo GLOwnerInfo } glOwnerInfo GLOwnerInfo }
-- This defines the GL Key Compromise control attribute. -- This defines the GL Key Compromise control attribute.
-- It has the simple type GeneralName. -- It has the simple type GeneralName.
id-skd-glKeyCompromise OBJECT IDENTIFIER ::= { id-skd 8} id-skd-glKeyCompromise OBJECT IDENTIFIER ::= { id-skd 8}
GLKCompromise ::= GeneralName GLKCompromise ::= GeneralName
Turner 73 Turner Expires June 2003 78
And Distribution And Distribution
-- This defines the GL Key Refresh control attribute. -- This defines the GL Key Refresh control attribute.
id-skd-glkRefresh OBJECT IDENTIFIER ::= { id-skd 9} id-skd-glkRefresh OBJECT IDENTIFIER ::= { id-skd 9}
GLKRefresh ::= SEQUENCE { GLKRefresh ::= SEQUENCE {
glName GeneralName, glName GeneralName,
dates SEQUENCE SIZE (1..MAX) OF Date } dates SEQUENCE SIZE (1..MAX) OF Date }
skipping to change at line 3815 skipping to change at line 4157
id-cmc-gla-skdAlgRequest OBJECT IDENTIFIER ::= { id-cmc-glaRR 1 } id-cmc-gla-skdAlgRequest OBJECT IDENTIFIER ::= { id-cmc-glaRR 1 }
SKDAlgRequest ::= NULL SKDAlgRequest ::= NULL
-- This defines the Algorithm Response -- This defines the Algorithm Response
id-cmc-gla-skdAlgResponse OBJECT IDENTIFIER ::= { id-cmc-glaRR 2 } id-cmc-gla-skdAlgResponse OBJECT IDENTIFIER ::= { id-cmc-glaRR 2 }
-- Note that the response for algorithmSupported request is the -- Note that the response for algorithmSupported request is the
-- smimeCapabilities attribute as defined in MsgSpec [7]. -- smimeCapabilities attribute as defined in MsgSpec [MSG].
Turner 74 Turner Expires June 2003 79
And Distribution And Distribution
-- This defines the control attribute to request an updated -- This defines the control attribute to request an updated
-- certificate to the GLA. -- certificate to the GLA.
id-skd-glProvideCert OBJECT IDENTIFIER ::= { id-skd 13} id-skd-glProvideCert OBJECT IDENTIFIER ::= { id-skd 13}
GLManageCert ::= SEQUENCE { GLManageCert ::= SEQUENCE {
glName GeneralName, glName GeneralName,
glMember GLMember } glMember GLMember }
skipping to change at line 3841 skipping to change at line 4183
id-skd-glManageCert OBJECT IDENTIFIER ::= { id-skd 14} id-skd-glManageCert OBJECT IDENTIFIER ::= { id-skd 14}
-- This defines the control attribute to distribute the GL shared -- This defines the control attribute to distribute the GL shared
-- KEK. -- KEK.
id-skd-glKey OBJECT IDENTIFIER ::= { id-skd 15} id-skd-glKey OBJECT IDENTIFIER ::= { id-skd 15}
GLKey ::= SEQUENCE { GLKey ::= SEQUENCE {
glName GeneralName, glName GeneralName,
glIdentifier KEKIdentifier, -- See CMS [2] glIdentifier KEKIdentifier, -- See [CMS]
glkWrapped RecipientInfos, -- See CMS [2] glkWrapped RecipientInfos, -- See [CMS]
glkAlgorithm AlgorithmIdentifier, glkAlgorithm AlgorithmIdentifier,
glkNotBefore GeneralizedTime, glkNotBefore GeneralizedTime,
glkNotAfter GeneralizedTime } glkNotAfter GeneralizedTime }
Turner 75 Turner Expires June 2003 80
And Distribution And Distribution
-- This defines the CMC error types -- This defines the CMC error types
id-cet-skdFailInfo OBJECT IDENTIFIER ::= { iso(1) id-cet-skdFailInfo OBJECT IDENTIFIER ::= { iso(1)
identified-organization(3) dod(6) internet(1) security(5) identified-organization(3) dod(6) internet(1) security(5)
mechanisms(5) pkix(7) cet(15) skdFailInfo(1) } mechanisms(5) pkix(7) cet(15) skdFailInfo(1) }
SKDFailInfo ::= INTEGER { SKDFailInfo ::= INTEGER {
unspecified (0), unspecified (0),
skipping to change at line 3875 skipping to change at line 4217
nameAlreadyInUse (8), nameAlreadyInUse (8),
noSpam (9), noSpam (9),
deniedAccess (10), deniedAccess (10),
alreadyAMember (11), alreadyAMember (11),
notAMember (12), notAMember (12),
alreadyAnOwner (13), alreadyAnOwner (13),
notAnOwner (14) } notAnOwner (14) }
END -- SMIMESymmetricKeyDistribution END -- SMIMESymmetricKeyDistribution
Expires 20 December 2001 Expires June 2003
Turner 76 Turner Expires June 2003 81
 End of changes. 

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