draft-ietf-smime-symkeydist-05.txt   draft-ietf-smime-symkeydist-06.txt 
SMIME Working Group S. Turner SMIME Working Group S. Turner
Internet Draft IECA Internet Draft IECA
Document: draft-ietf-smime-symkeydist-05.txt July 2001 Document: draft-ietf-smime-symkeydist-06.txt August 2001
Expires: December 20, 2001 Expires: January 20, 2001
S/MIME Symmetric Key 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 [1].
This document is an Internet-Draft. Internet-Drafts are working This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, 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.
skipping to change at line 50 skipping to change at line 50
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 [2] and Certificate
Management Message over CMS (CMC) protocol [3] to manage the Management Message over CMS (CMC) protocol [3] 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
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 [4].
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
skipping to change at line 105 skipping to change at line 106
4.2 DELETE GL FROM GLA............................................32 4.2 DELETE GL FROM GLA............................................32
4.3 ADD MEMBERS TO GL.............................................34 4.3 ADD MEMBERS TO GL.............................................34
4.3.1 GLO INITIATED ADDITIONS.....................................35 4.3.1 GLO INITIATED ADDITIONS.....................................35
4.3.2 PROSPECTIVE MEMBER INITIATED ADDITIONS......................41 4.3.2 PROSPECTIVE MEMBER INITIATED ADDITIONS......................41
4.4 DELETE MEMBERS FROM GL........................................43 4.4 DELETE MEMBERS FROM GL........................................43
4.4.1 GLO INITIATED DELETIONS.....................................44 4.4.1 GLO INITIATED DELETIONS.....................................44
4.4.2 MEMBER INITIATED DELETIONS..................................48 4.4.2 MEMBER INITIATED DELETIONS..................................48
4.5 REQUEST REKEY OF GL...........................................49 4.5 REQUEST REKEY OF GL...........................................49
Turner 2 Turner 2
And Distribution
4.5.1 GLO INITIATED REKEY REQUESTS................................50 4.5.1 GLO INITIATED REKEY REQUESTS................................50
4.5.2 GLA INITIATED REKEY REQUESTS................................53 4.5.2 GLA INITIATED REKEY REQUESTS................................53
4.6 CHANGE GLO....................................................53 4.6 CHANGE GLO....................................................53
4.7 INDICATE KEK COMPROMISE.......................................55 4.7 INDICATE KEK COMPROMISE.......................................55
4.7.1 GL MEMBER INITIATED KEK COMPROMISE MESSAGE..................56 4.7.1 GL MEMBER INITIATED KEK COMPROMISE MESSAGE..................56
4.7.2 GLO INITIATED KEK COMPROMISE MESSAGE........................57 4.7.2 GLO INITIATED KEK COMPROMISE MESSAGE........................57
4.8 REQUEST KEK REFRESH...........................................58 4.8 REQUEST KEK REFRESH...........................................58
4.9 GLA QUERY REQUEST AND RESPONSE................................59 4.9 GLA QUERY REQUEST AND RESPONSE................................59
4.10 UPDATE MEMBER CERTIFICATE....................................61 4.10 UPDATE MEMBER CERTIFICATE....................................61
4.10.1 GLO AND GLA INITIATED UPDATE MEMBER CERTIFICATE............61 4.10.1 GLO AND GLA INITIATED UPDATE MEMBER CERTIFICATE............61
skipping to change at line 158 skipping to change at line 161
the PKCs for each of the recipients. Each recipient identifies their the PKCs for each of the recipients. Each recipient identifies their
per-recipient information and uses the private key associated with per-recipient information and uses the private key associated with
the public key of their PKC to decrypt the CEK and hence gain access the public key of their PKC to decrypt the CEK and hence gain access
to the encrypted content. to the encrypted content.
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 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.
The security provided by the shared KEK is only as good as the sum The security provided by the shared KEK is only as good as the sum
of the techniques employed by each member of the group to keep the of the techniques employed by each member of the group to keep the
KEK secret from nonmembers. These techniques are beyond the scope of KEK secret from nonmembers. These techniques 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
skipping to change at line 209 skipping to change at line 214
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 (PK) protected message to a MLA who then uses the shared KEK (S) to
Turner 4 Turner 4
And Distribution
redistribute the message to the members of the list. Scenario 2 redistribute the message to the members of the list. Scenario 2
depicts the originator sending a shared KEK protected message to a 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). Scenario 3 shows an (the MLA only adds additional recipients). Scenario 3 shows an
originator sending a shared KEK protected message to a group of originator sending a shared KEK protected message to a group of
recipients without an intermediate MLA. recipients without an intermediate MLA.
+----> +----> +----> +----> +----> +---->
PK +-----+ S | S +-----+ S | S | PK +-----+ S | S +-----+ S | S |
----> | MLA | --+----> ----> | MLA | --+----> ----+----> ----> | MLA | --+----> ----> | MLA | --+----> ----+---->
skipping to change at line 260 skipping to change at line 267
+----------+ +---------+ +----------+ +----------+ +---------+ +----------+
Figure 1 - Key Distribution Architecture Figure 1 - Key Distribution Architecture
A GLA may support multiple KMAs. A GLA in general supports only one 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 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.
Turner 5 Turner 5
And Distribution
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.
Note: If the distribution for the list is performed by an entity Note: If the distribution for the list is performed by an entity
other than the originator (e.g., an MLA distributing a mail other than the originator (e.g., an MLA distributing a mail
message), this entity can also enforce access control rules. message), this entity can also enforce access control rules.
skipping to change at line 313 skipping to change at line 322
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 distribution messages. The administrative messages are the request
and response messages needed to setup the GL, delete the GL, add 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, 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
Turner 6 Turner 6
And 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.
+-----+ +----------+ +-----+ +----------+
| GLO | <---+ +----> | Member 1 | | GLO | <---+ +----> | Member 1 |
+-----+ | | +----------+ +-----+ | | +----------+
| | | |
skipping to change at line 366 skipping to change at line 377
glRemoveOwner id-skd 7 GLOwnerAdministration glRemoveOwner id-skd 7 GLOwnerAdministration
glkCompromise id-skd 8 GeneralName glkCompromise id-skd 8 GeneralName
glkRefresh id-skd 9 GLKRefresh glkRefresh id-skd 9 GLKRefresh
glaQueryRequest id-skd 11 GLAQueryRequest glaQueryRequest id-skd 11 GLAQueryRequest
glaQueryResponse id-skd 12 GLAQueryResponse glaQueryResponse id-skd 12 GLAQueryResponse
glProvideCert id-skd 13 GLManageCert glProvideCert id-skd 13 GLManageCert
glUpdateCert id-skd 14 GLManageCert glUpdateCert id-skd 14 GLManageCert
glKey id-skd 15 GLKey glKey id-skd 15 GLKey
Turner 7 Turner 7
And Distribution
In the following conformance tables, the column headings have the In the following conformance tables, the column headings have the
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
skipping to change at line 413 skipping to change at line 426
- MAY | SHOULD - - | - MAY | glaQueryResponse - MAY | SHOULD - - | - MAY | glaQueryResponse
glaQueryResponse and gloResponse are carried in the CMC PKIResponse glaQueryResponse and gloResponse are carried in the CMC PKIResponse
content-type, all other control attributes are carried in the CMC content-type, all other control attributes are carried in the CMC
PKIData content-type. The exception is glUpdateCert which can be PKIData content-type. The exception is glUpdateCert which can be
carried in either PKIData or PKIResponse. carried in either PKIData or PKIResponse.
Success and failure messages use CMC (see section 3.2.4). Success and failure messages use CMC (see section 3.2.4).
Turner 8 Turner 8
And Distribution
3.1.1 GL USE KEK 3.1.1 GL USE KEK
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,
skipping to change at line 466 skipping to change at line 480
GLKeyAttributes ::= SEQUENCE { GLKeyAttributes ::= SEQUENCE {
rekeyControlledByGLO [0] BOOLEAN DEFAULT FALSE, rekeyControlledByGLO [0] BOOLEAN DEFAULT FALSE,
recipientsNotMutuallyAware [1] BOOLEAN DEFAULT TRUE, recipientsNotMutuallyAware [1] BOOLEAN DEFAULT TRUE,
duration [2] INTEGER DEFAULT 0, duration [2] INTEGER DEFAULT 0,
generationCounter [3] INTEGER DEFAULT 2, generationCounter [3] INTEGER DEFAULT 2,
requestedAlgorithm [4] AlgorithmIdentifier requestedAlgorithm [4] AlgorithmIdentifier
DEFAULT id-alg-CMS3DESwrap } DEFAULT id-alg-CMS3DESwrap }
Turner 9 Turner 9
And Distribution
The fields in GLUseKEK have the following meaning: The fields in GLUseKEK have the following meaning:
- glInfo indicates the name of the GL in glName and the address of - glInfo indicates the name of the GL in glName and the address of
the GL in glAddress. The glName and glAddress can be the same, 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. - glOwnerName indicates the name of the owner of the GL.
skipping to change at line 520 skipping to change at line 536
supported for glAdministration: supported for glAdministration:
- Unmanaged - When the GLO sets glAdministration to unmanaged, - Unmanaged - When the GLO sets glAdministration to unmanaged,
they are allowing prospective members to request addition and they are allowing prospective members to request addition and
deletion from the GL without GLO intervention. deletion from the GL without GLO intervention.
- Managed - When the GLO sets glAdministration to managed, they - Managed - When the GLO sets glAdministration to managed, they
are allowing prospective members to request addition and are allowing prospective members to request addition and
Turner 10 Turner 10
And Distribution
deletion from the GL, but the request is redirected by the GLA deletion from the GL, but the request is redirected by the GLA
to GLO for review. The GLO makes the determination as to to GLO for review. The GLO makes the determination as to
whether to honor the request. whether to honor the request.
- Closed - When the GLO sets glAdministration to closed, they - Closed - When the GLO sets glAdministration to closed, they
are not allowing prospective members to request addition or are not allowing prospective members to request addition or
deletion from the GL. The GLA will only accept glAddMember and deletion from the GL. The GLA will only accept glAddMember and
glDeleteMember requests from the GLO. glDeleteMember requests from the GLO.
- glKeyAttributes indicates the attributes the GLO wants the GLA - glKeyAttributes indicates the attributes the GLO wants the GLA
skipping to change at line 574 skipping to change at line 592
the UTC Zulu time zone. For example if the duration is zero the UTC Zulu time zone. For example if the duration is zero
(0), if the GL shared KEK is requested on July 24, the first (0), if the GL shared KEK is requested on July 24, the first
key will be valid until the end of July and the next key will key will be valid until the end of July and the next key will
be valid for the entire month of August. If the value is not be valid for the entire month of August. If the value is not
zero (0), the shared KEK will be valid for the number of days zero (0), the shared KEK will be valid for the number of days
indicated by the value. For example, if the value of duration indicated by the value. For example, if the value of duration
is seven (7) and the shared KEK is requested on Monday but not is seven (7) and the shared KEK is requested on Monday but not
generated until Tuesday (2359); the shared KEKs will be valid generated until Tuesday (2359); the shared KEKs will be valid
Turner 11 Turner 11
And Distribution
from Tuesday (2359) to Tuesday (2359). The exact time of the from Tuesday (2359) to Tuesday (2359). The exact time of the
day is determined when the key is generated. day is determined when the key is generated.
- generationCounter indicates the number of keys the GLO wants - generationCounter indicates the number of keys the GLO wants
the GLA to distribute. To ensure uninterrupted function of the the GLA to distribute. To ensure uninterrupted function of the
GL two (2) shared KEKs at a minimum MUST be initially GL two (2) shared KEKs at a minimum MUST be initially
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
skipping to change at line 619 skipping to change at line 639
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 12 Turner 12
And Distribution
Certificates ::= SEQUENCE { Certificates ::= SEQUENCE {
pKC [0] Certificate OPTIONAL, pKC [0] Certificate OPTIONAL,
-- See PKIX [5] -- See PKIX [5]
aC [1] SEQUENCE SIZE (1.. MAX) OF aC [1] SEQUENCE SIZE (1.. MAX) OF
AttributeCertificate OPTIONAL, AttributeCertificate OPTIONAL,
-- See ACPROF [6] -- See ACPROF [6]
certPath [2] CertificateSet OPTIONAL } certPath [2] CertificateSet OPTIONAL }
-- From CMS [2] -- From CMS [2]
-- CertificateSet and CertificateChoices are included only -- CertificateSet and CertificateChoices are included only
skipping to change at line 672 skipping to change at line 694
certificate (see AC Profile [6]) associated with the certificate (see AC Profile [6]) associated with the
memberĘs encryption certificate. memberĘs 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
Turner 13 Turner 13
And Distribution
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
GLOs use the glDeleteMember to request deletion of GL members, and GLOs use the glDeleteMember to request deletion of GL members, and
GL members use the glDeleteMember to request their own removal from GL members use the glDeleteMember to request their own removal from
the GL. The glDeleteMember message MUST be signed by either the GLO the GL. The glDeleteMember message MUST be signed by either the GLO
or the GL member. The glDeleteMember control attribute has the or the GL member. The glDeleteMember control attribute has the
syntax GLDeleteMember: syntax GLDeleteMember:
skipping to change at line 721 skipping to change at line 745
requestedAlgorithm [4] AlgorithmIdentifier OPTIONAL } requestedAlgorithm [4] AlgorithmIdentifier OPTIONAL }
The fields in GLRekey have the following meaning: The fields in GLRekey have the following meaning:
- glName indicates the name of the GL to be rekeyed. - glName indicates the name of the GL to be rekeyed.
- glAdministration indicates if there is any change to how the GL - glAdministration indicates if there is any change to how the GL
should be administered. See section 3.1.1 for the three options. should be administered. See section 3.1.1 for the three options.
Turner 14 Turner 14
And Distribution
This field is only included if there is a change from the This field is only included if there is a change from the
previously registered administered. previously registered administered.
- glNewKeyAttributes indicates whether the rekey of the GLO is - glNewKeyAttributes indicates whether the rekey of the GLO is
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 GLO wishes to use, the duration of the key, and how many
outstanding keys will be issued. The field is only included if outstanding keys will be issued. The field is only included if
there is a change from the previously registered there is a change from the previously registered
glKeyAttributes. glKeyAttributes.
skipping to change at line 769 skipping to change at line 795
GLOs use the glRemoveOwner to request that a GLO be disassociated GLOs use the glRemoveOwner to request that a GLO be disassociated
with the GL. The glRemoveOwner message MUST be signed by a with the GL. The glRemoveOwner message MUST be signed by a
registered GLO. The glRemoveOwner control attribute has the syntax registered GLO. The glRemoveOwner control attribute has the syntax
GLOwnerAdministration: GLOwnerAdministration:
GLOwnerAdministration ::= SEQUENCE { GLOwnerAdministration ::= SEQUENCE {
glName GeneralName, glName GeneralName,
glOwnerInfo GLOwnerInfo } glOwnerInfo GLOwnerInfo }
Turner 15 Turner 15
And Distribution
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.
3.1.8 GL Key Compromise 3.1.8 GL Key Compromise
skipping to change at line 818 skipping to change at line 846
- dates indicates a date range for keys the GL member wants. The - dates indicates a date range for keys the GL member wants. The
start field indicates the first date the GL member wants and the start field indicates the first date the GL member wants and the
end field indicates the last date. The end date MAY be omitted end field indicates the last date. The end date MAY be omitted
to indicate the GL member wants all keys from the specified to indicate the GL member wants all keys from the specified
start date to the current date. Note that a procedural mechanism start date to the current date. Note that a procedural mechanism
is needed to restrict users from accessing messages that they is needed to restrict users from accessing messages that they
are not allowed to access. are not allowed to access.
Turner 16 Turner 16
And Distribution
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.
skipping to change at line 866 skipping to change at line 895
This document defines one request/response pair for GL members and This document defines one request/response pair for GL members and
GLOs to query the GLA for the list of algorithm it supports. The GLOs to query the GLA for the list of algorithm it supports. The
following object identifier (OID) is included in the glaQueryType following object identifier (OID) is included in the glaQueryType
field: field:
id-cmc-gla-skdAlgRequest OBJECT IDENTIFIER ::={ id-cmc-glaRR 1 } id-cmc-gla-skdAlgRequest OBJECT IDENTIFIER ::={ id-cmc-glaRR 1 }
SKDAlgRequest ::= NULL SKDAlgRequest ::= NULL
Turner 17 Turner 17
And Distribution
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 [7].
3.1.12 Provide Cert 3.1.12 Provide Cert
skipping to change at line 917 skipping to change at line 948
glUpdateCert. If the GL memberĘs encryption certificate has been glUpdateCert. If the GL memberĘs encryption certificate has been
revoked, the GL member MUST NOT use it to generate the EnvelopedData revoked, the GL member MUST NOT use it to generate the EnvelopedData
that encapsulates the glUpdateCert request or response. The that encapsulates the glUpdateCert request or response. The
glUpdateCert control attribute has the syntax GLManageCert: glUpdateCert control attribute has the syntax GLManageCert:
GLManageCert ::= SEQUENCE { GLManageCert ::= SEQUENCE {
glName GeneralName, glName GeneralName,
glMember GLMember } glMember GLMember }
Turner 18 Turner 18
And Distribution
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 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
skipping to change at line 964 skipping to change at line 997
GLKey ::= SEQUENCE { GLKey ::= SEQUENCE {
glName GeneralName, glName GeneralName,
glIdentifier KEKIdentifier, -- See CMS [2] glIdentifier KEKIdentifier, -- See CMS [2]
glkWrapped RecipientInfos, -- See CMS [2] glkWrapped RecipientInfos, -- See CMS [2]
glkAlgorithm AlgorithmIdentifier, glkAlgorithm AlgorithmIdentifier,
glkNotBefore GeneralizedTime, glkNotBefore GeneralizedTime,
glkNotAfter GeneralizedTime } glkNotAfter GeneralizedTime }
Turner 19 Turner 19
And Distribution
-- 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 [2].
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:
skipping to change at line 1014 skipping to change at line 1049
If the glKey message is in response to a glUseKEK message: If the glKey message is in response to a glUseKEK message:
- The GLA MUST generate separate glKey messages for each recipient - The GLA MUST generate separate glKey messages for each recipient
if glUseKEK.glKeyAttributes.recipientsNotMutuallyAware is set to if glUseKEK.glKeyAttributes.recipientsNotMutuallyAware is set to
FALSE. For each recipient you want to generate a message that FALSE. For each recipient you want to generate a message that
contains that recipientĘs key (i.e., one message with one contains that recipientĘs key (i.e., one message with one
attribute). attribute).
Turner 20 Turner 20
And Distribution
- 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.
If the glKey message is in response to a glRekey message: If the glKey message is in response to a glRekey message:
- The GLA MUST generate separate glKey messages for each recipient - The GLA MUST generate separate glKey messages for each recipient
if glRekey.glNewKeyAttributes.recipientsNotMutuallyAware is set if glRekey.glNewKeyAttributes.recipientsNotMutuallyAware is set
to FALSE. to FALSE.
skipping to change at line 1061 skipping to change at line 1098
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 [7]. The second is to not use a
MIME wrapper around each ContentInfo, as specified in Transporting MIME wrapper around each ContentInfo, as specified in Transporting
S/MIME Objects in X.400 [8]. S/MIME Objects in X.400 [8].
Turner 21 Turner 21
And Distribution
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
skipping to change at line 1108 skipping to change at line 1146
paragraph 2.9 of Extended Security Services for S/MIME [9]. paragraph 2.9 of Extended Security Services for S/MIME [9].
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 22 Turner 22
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
skipping to change at line 1161 skipping to change at line 1200
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 23 Turner 23
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 1202 skipping to change at line 1243
If GLKeyAttributes.recipientsNotMutuallyAware is set to FALSE, a If GLKeyAttributes.recipientsNotMutuallyAware is set to FALSE, a
separate PKIResponse.cMCStatusInfoExand PKIData.glKey MUST be separate PKIResponse.cMCStatusInfoExand 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 cMCStatusInfoEx If the GL has multiple GLOs, the GLA MUST send cMCStatusInfoEx
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 24 Turner 24
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
skipping to change at line 1240 skipping to change at line 1283
applies to multiple commands, a single cmcStatusInfoEx structure can applies to multiple commands, a single cmcStatusInfoEx structure can
be used with multiple items in cMCStatusInfoEx.bodyList. The GLA MAY be used with multiple items in cMCStatusInfoEx.bodyList. The GLA MAY
also return other pertinent information in statusString. The also return other pertinent information in statusString. The
SKDFailInfo object identifier and value are: SKDFailInfo object identifier and value are:
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 25 Turner 25
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 1294 skipping to change at line 1339
present in the request. present in the request.
- 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 26 Turner 26
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 1348 skipping to change at line 1395
be processed immediately by the GLA or GLO, the cMCStatusInfoEx be processed immediately by the GLA or GLO, the cMCStatusInfoEx
control attribute MUST be returned indicating cMCStatus.pending and control attribute MUST be returned indicating cMCStatus.pending and
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
cMCStatusInfoEx indicating query pending. cMCStatusInfoEx indicating query pending.
cMCStatusInfoEx is also used by GLAs to indicate that a cMCStatusInfoEx 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 27 Turner 27
And Distribution
supported, the cMCStatusInfoEx control attribute MUST be returned supported, the cMCStatusInfoEx 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.
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
skipping to change at line 1398 skipping to change at line 1447
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 | cMCStatusinfoEx MUST MUST | MUST MUST - | MUST MUST | cMCStatusinfoEx
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
Turner 28 Turner 28
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.)
skipping to change at line 1445 skipping to change at line 1495
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.
+-----+ 1 2 +-----+ +-----+ 1 2 +-----+
| GLA | <-------> | GLO | | GLA | <-------> | GLO |
+-----+ +-----+ +-----+ +-----+
Figure 3 - Create Group List Figure 3 - Create Group List
Turner 29 Turner 29
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
skipping to change at line 1499 skipping to change at line 1551
value of noValidGLACertificate. Instead of immediately value of noValidGLACertificate. Instead of immediately
returning the error code, the GLA attempts to get a returning the error code, the GLA attempts to get a
certificate, possibly using CMC [3]. certificate, possibly using CMC [3].
2.c - Else the signatures are valid and the GLA does have a valid 2.c - 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 30 Turner 30
And Distribution
2.c.1 - If the names do not match, the GLA returns a response 2.c.1 - If the names do not match, the GLA returns a response
indicating cMCStatusInfoEx with cMCStatus.failed and indicating cMCStatusInfoEx with cMCStatus.failed and
otherInfo.extendedFailInfo.SKDFailInfo value of otherInfo.extendedFailInfo.SKDFailInfo value of
noGLONameMatch. noGLONameMatch.
2.c.2 - Else if the names all match, the GLA checks that the 2.c.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.
skipping to change at line 1552 skipping to change at line 1606
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.c.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 31 Turner 31
And Distribution
2.c.2.e.2 - The GLA can also optionally apply another SignedData 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 cMCStatusInfoEx responses, the GLO 3 - Upon receipt of the cMCStatusInfoEx responses, the GLO
verifies the GLA signature(s). If an additional SignedData verifies the GLA signature(s). If an additional SignedData
and/or EnvelopedData encapsulates the response (see section and/or EnvelopedData encapsulates the response (see section
3.2.1.2 or 3.2.2), the GLO verifies the outer signature and/or 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 decrypt the outer layer prior to verifying the signature on
the inner most SignedData. the inner most SignedData.
skipping to change at line 1602 skipping to change at line 1658
+-----+ +-----+ +-----+ +-----+
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
Turner 32 Turner 32
And Distribution
request to the GLA (1 in Figure 4). The name of the GL to be request to the GLA (1 in Figure 4). The name of the GL to be
deleted is included in GeneralName. 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 can also optionally apply another SignedData
over the EnvelopedData (see section 3.2.1.2). over the EnvelopedData (see section 3.2.1.2).
skipping to change at line 1656 skipping to change at line 1714
disclose, the GLA returns a response indicating disclose, the GLA returns a response indicating
cMCStatusInfoEx with cMCStatus.failed and cMCStatusInfoEx with cMCStatus.failed and
otherInfo.extendedFailInfo.SKDFailInfo value of otherInfo.extendedFailInfo.SKDFailInfo value of
unspecified. Actions beyond the scope of this document unspecified. Actions beyond the scope of this document
must then be taken to delete the GL from the GLA. 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 2.b.2.c - Else if the names do match, the GLA returns a
cMCStatusInfoEx indicating cMCStatus.success (2 in cMCStatusInfoEx indicating cMCStatus.success (2 in
Turner 33 Turner 33
And Distribution
Figure 4). The GLA ought not accept further requests for Figure 4). The GLA ought not accept further requests for
member additions, member deletions, or group rekeys for member additions, member deletions, or group rekeys for
this GL. this GL.
2.b.2.c.1 - The GLA can apply confidentiality to the response by 2.b.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.b.2.c.2 - The GLA MAY can also optionally apply another
skipping to change at line 1709 skipping to change at line 1769
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 34 Turner 34
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
skipping to change at line 1762 skipping to change at line 1824
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 35 Turner 35
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.
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).
skipping to change at line 1816 skipping to change at line 1880
otherInfo.extendedFailInfo.SKDFailInfo value of otherInfo.extendedFailInfo.SKDFailInfo value of
invalidGLName. invalidGLName.
2.c.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.c.2.a - If the glMemberName is present on the GL, the GLA 2.c.2.a - If the glMemberName is present on the GL, the GLA
returns a response indicating cMCStatusInfoEx with returns a response indicating cMCStatusInfoEx with
Turner 36 Turner 36
And Distribution
cMCStatus.failed and cMCStatus.failed and
otherInfo.extendedFailInfo.SKDFailInfo value of otherInfo.extendedFailInfo.SKDFailInfo value of
alreadyAMember. alreadyAMember.
2.c.2.b - Else if the glMemberName is not present on the GL, the 2.c.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.c.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
skipping to change at line 1870 skipping to change at line 1936
2.c.2.b.1.b.2.b - The GLA can also optionally apply another 2.c.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.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
Turner 37 Turner 37
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.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 cMCStatusInfoEx with cMCStatus.failed and indicating cMCStatusInfoEx with cMCStatus.failed and
otherInfo.extendedFailInfo.SKDFailInfo value of otherInfo.extendedFailInfo.SKDFailInfo value of
noSpam. noSpam.
skipping to change at line 1924 skipping to change at line 1992
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.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
Turner 38 Turner 38
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.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.c.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
skipping to change at line 1978 skipping to change at line 2048
The GLA also takes administrative actions, which The GLA also takes administrative actions, which
are beyond the scope of this document, to add the are beyond the scope of this document, to add the
member to the GL stored on the GLA. The GLA also member to the GL stored on the GLA. The GLA also
distributes the shared KEK to the member via the distributes the shared KEK to the member via the
mechanism described in section 5. mechanism described in section 5.
2.c.2.b.3.b.2.a - The GLA applies confidentiality to the response 2.c.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 39 Turner 39
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.c.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 cMCStatusInfoEx response, the GLO verifies 3 - Upon receipt of the cMCStatusInfoEx response, the GLO verifies
the GLA signature(s). If an additional SignedData and/or the GLA signature(s). If an additional SignedData and/or
EnvelopedData encapsulates the response (see section 3.2.1.2 EnvelopedData encapsulates the response (see section 3.2.1.2
skipping to change at line 2031 skipping to change at line 2103
4.a - If the signatures verify, the GL member checks that one of 4.a - If the signatures verify, the GL member checks that one of
the names in the certificate used to sign the response the names in the certificate used to sign the response
matches the name of the GL. matches the name of the GL.
4.a.1 ū If the name of the GL does not match the name present in 4.a.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.
Turner 40 Turner 40
And Distribution
4.a.2 ū Else if the name of the GL matches the name present in the 4.a.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.a.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.a.2.b - Else if the prospective member received a
cMCStatusInfoEx.cMCStatus.failed, for any reason, the cMCStatusInfoEx.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.
skipping to change at line 2083 skipping to change at line 2157
If an EnvelopedData encapsulates the inner most layer (see If an EnvelopedData encapsulates the inner most layer (see
section 3.2.1.2 or 3.2.2), the GLO decrypts the outer layer section 3.2.1.2 or 3.2.2), the GLO decrypts the outer layer
prior to verifying the signature on the inner most SignedData. 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 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 41 Turner 41
And Distribution
3.a - If the signatures verify, the GLO checks to make sure one of 3.a - If the signatures verify, the GLO checks to make sure one of
the names in the certificate used to sign the request the names in the certificate used to sign the request
matches the name in glMember.glMemberName. matches the name in glMember.glMemberName.
3.a.1 - If the names do not match, the GLO sends a 3.a.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 cMCStatusInfoEx.cMCStatus.failed prospective member with cMCStatusInfoEx.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.
skipping to change at line 2136 skipping to change at line 2212
3.a.2.b.2.a - The GLO applies confidentiality to the new 3.a.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.a.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 42 Turner 42
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 2189 skipping to change at line 2267
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 43 Turner 43
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
skipping to change at line 2241 skipping to change at line 2320
invalidGLName. invalidGLName.
2.b.2 - Else if the glName is supported by the GLA, the GLA checks 2.b.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.b.2.a - If the glMemberName is not present on the GL, the GLA
returns a response indicating cMCStatusInfoEx with returns a response indicating cMCStatusInfoEx with
cMCStatus.failed and cMCStatus.failed and
Turner 44 Turner 44
And Distribution
otherInfo.extendedFailInfo.SKDFailInfo value of otherInfo.extendedFailInfo.SKDFailInfo value of
notAMember. notAMember.
2.b.2.b - Else if the glMemberName is already on the GL, the GLA 2.b.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.b.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.
skipping to change at line 2295 skipping to change at line 2376
indicating cMCStatusInfoEx with cMCStatus.failed and indicating cMCStatusInfoEx with cMCStatus.failed and
otherInfo.extendedFailInfo.SKDFailInfo value of otherInfo.extendedFailInfo.SKDFailInfo value of
noSpam. noSpam.
2.b.2.b.2.b - Else if the signer is a registered GLO, the GLA 2.b.2.b.2.b - Else if the signer is a registered GLO, the GLA
returns a cMCStatusInfoEx.cMCStatus.success (2 in returns a cMCStatusInfoEx.cMCStatus.success (2 in
Figure 6). The GLA also takes administrative Figure 6). The GLA also takes administrative
actions, which are beyond the scope of this actions, which are beyond the scope of this
Turner 45 Turner 45
And Distribution
document, to delete the member with the GL stored on document, to delete the member with the GL stored on
the GLA. Note that the GL will also be rekeyed as the GLA. Note that the GL will also be rekeyed as
described in section 5. described in section 5.
2.b.2.b.2.b.1 - The GLA applies confidentiality to the response by 2.b.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.b.2.b.2.b.2 - The GLA can also optionally apply another
skipping to change at line 2349 skipping to change at line 2432
2.b.2.b.3.b - Else if the signer is either a registered GLO or the 2.b.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
cMCStatusInfoEx.cMCStatus.success to the GLO (2 in cMCStatusInfoEx.cMCStatus.success to the GLO (2 in
Figure 6) if the GLO signed the request and to the Figure 6) if the GLO signed the request and to the
GL member (3 in Figure 6) if the GL member signed GL member (3 in Figure 6) if the GL member signed
the request. The GLA also takes administrative the request. The GLA also takes administrative
actions, which are beyond the scope of this actions, which are beyond the scope of this
Turner 46 Turner 46
And Distribution
document, to delete the member with the GL stored on document, to delete the member with the GL stored on
the GLA. the GLA.
2.b.2.b.3.b.1 - The GLA applies confidentiality to the response by 2.b.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.b.2.b.3.b.2 - The GLA can also optionally apply another
SignedData over the EnvelopedData (see section SignedData over the EnvelopedData (see section
skipping to change at line 2403 skipping to change at line 2488
additional SignedData and/or EnvelopedData encapsulates the additional SignedData and/or EnvelopedData encapsulates the
response (see section 3.2.1.2 or 3.2.2), the GLO verifies 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 outer signature and/or decrypt the outer layer prior to
verifying the signature on the inner most SignedData. 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 signatures verify, the GL member checks that one of
the names in the certificate used to sign the response the names in the certificate used to sign the response
matches the name of the GL. matches the name of the GL.
Turner 47 Turner 47
And Distribution
4.a.1 ū If the name of the GL does not match the name present in 4.a.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.a.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.a.2.a - If the signature(s) verify, the member has been deleted
from the GL. from the GL.
skipping to change at line 2455 skipping to change at line 2542
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
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 signatures cannot be verified, the GLO returns a
cMCStatusInfoEx response indicating cMCStatus.failed and cMCStatusInfoEx response indicating cMCStatus.failed and
otherInfo.failInfo.badMessageCheck. otherInfo.failInfo.badMessageCheck.
Turner 48 Turner 48
And Distribution
3.b - Else if the signatures verify, the GLO checks to make sure 3.b - 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.b.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 cMCStatusInfoEx.cMCtatus.failed prospective member with cMCStatusInfoEx.cMCtatus.failed
indicating why the prospective member was denied in indicating why the prospective member was denied in
cMCStatusInfoEx.statusString. This stops people from cMCStatusInfoEx.statusString. This stops people from
adding people to GLs without their permission. adding people to GLs without their permission.
skipping to change at line 2506 skipping to change at line 2595
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.
- When the current shared KEK is about to expire. Consider two - When the current shared KEK is about to expire. Consider two
cases: cases:
Turner 49 Turner 49
And Distribution
- 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.
If the generationCounter (see section 3.1.1) is set to a value If the generationCounter (see section 3.1.1) is set to a value
greater than one (1) and the GLO controls the GL rekey, the GLO may greater than one (1) and the GLO controls the GL rekey, the GLO may
generate a glRekey any time before the last shared KEK has expired. generate a glRekey any time before the last shared KEK has expired.
skipping to change at line 2559 skipping to change at line 2650
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 verifies the signature on
the inner most SignedData.PKIData. If an additional SignedData the inner most SignedData.PKIData. If an additional SignedData
Turner 50 Turner 50
And Distribution
and/or EnvelopedData encapsulates the request (see section and/or EnvelopedData encapsulates the request (see section
3.2.1.2 or 3.2.2), the GLA verifies the outer signature and/or 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 decrypt the outer layer prior to verifying the signature on
the inner most SignedData. the inner most SignedData.
2.a - If the signatures do not verify, the GLA returns a 2.a - If the signatures do not verify, the GLA returns a
cMCStatusInfoEx response indicating cMCStatus.failed and cMCStatusInfoEx response indicating cMCStatus.failed and
otherInfo.failInfo.badMessageCheck. otherInfo.failInfo.badMessageCheck.
2.b - Else if the signatures do verify, the GLA makes sure the GL 2.b - Else if the signatures do verify, the GLA makes sure the GL
skipping to change at line 2612 skipping to change at line 2705
unsupportedDuration. unsupportedDuration.
2.b.2.b.3 - Else if the GL is not supportable for other reasons, 2.b.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 cMCStatusInfoEx with returns a response indicating cMCStatusInfoEx with
cMCStatus.failed and cMCStatus.failed and
otherInfo.extendedFailInfo.SKDFailInfo value of otherInfo.extendedFailInfo.SKDFailInfo value of
unspecified. unspecified.
Turner 51 Turner 51
And Distribution
2.b.2.b.4 - Else if the new requestedAlgorithm and duration are 2.b.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 cMCStatusInfoEx.cMCStatus.success (2 in GLA returns a cMCStatusInfoEx.cMCStatus.success (2 in
Figure 7). The GLA also uses the glKey message to Figure 7). The GLA also uses the glKey message to
distribute the rekey shared KEK (see section 5). distribute the rekey shared KEK (see section 5).
2.b.2.b.4.a - The GLA applies confidentiality to response by 2.b.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).
skipping to change at line 2654 skipping to change at line 2749
3.a.2.a - If the signatures verify and the response is 3.a.2.a - If the signatures verify and the response is
cMCStatusInfoEx.cMCStatus.success, the GLO has cMCStatusInfoEx.cMCStatus.success, the GLO has
successfully rekeyed the GL. successfully rekeyed the GL.
3.a.2.b ū Else if the GLO received a 3.a.2.b ū Else if the GLO received a
cMCStatusInfoEx.cMCStatus.failed with any reason, the cMCStatusInfoEx.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 52 Turner 52
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 cMCStatusInfoEx to indicate to the GL that a GLA will generate a cMCStatusInfoEx 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
skipping to change at line 2705 skipping to change at line 2801
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.
Turner 53 Turner 53
And Distribution
+-----+ 1 2 +-----+ +-----+ 1 2 +-----+
| GLA | <-------> | GLO | | GLA | <-------> | GLO |
+-----+ +-----+ +-----+ +-----+
Figure 8 - GLO Add & Delete Owners Figure 8 - GLO Add & Delete Owners
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
skipping to change at line 2759 skipping to change at line 2857
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 2.b.2.a - If the names do not match, the GLA returns a response
indicating cMCStatusInfoEx with cMCStatus.failed and indicating cMCStatusInfoEx with cMCStatus.failed and
otherInfo.extendedFailInfo.SKDFailInfo value of otherInfo.extendedFailInfo.SKDFailInfo value of
noGLONameMatch. noGLONameMatch.
Turner 54 Turner 54
And Distribution
2.b.2.b - Else if the names match, the GLA returns a 2.b.2.b - Else if the names match, the GLA returns a
cMCStatusInfoEx.cMCStatus.success (2 in Figure 4). The cMCStatusInfoEx.cMCStatus.success (2 in Figure 4). The
GLA also takes administrative actions to associate the GLA also takes administrative actions to associate the
new glOwnerName with the GL in the case of glAddOwner or new glOwnerName with the GL in the case of glAddOwner or
to disassociate the old glOwnerName with the GL in the to disassociate the old glOwnerName with the GL in the
cased of glRemoveOwner. cased of glRemoveOwner.
2.b.2.b.1 - The GLA applies confidentiality to the response by 2.b.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
skipping to change at line 2809 skipping to change at line 2909
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.
Turner 55 Turner 55
And Distribution
+-----+ 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 2862 skipping to change at line 2964
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.b.1 - If the glName is not supported by the GLA, the GLA returns
a response indicating cMCStatusInfoEx with a response indicating cMCStatusInfoEx with
cMCStatus.failed and cMCStatus.failed and
otherInfo.extendedFailInfo.SKDFailInfo value of otherInfo.extendedFailInfo.SKDFailInfo value of
invalidGLName. invalidGLName.
Turner 56 Turner 56
And Distribution
2.b.2 - Else if the glName is supported by the GLA, the GLA checks 2.b.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.b.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).
skipping to change at line 2915 skipping to change at line 3019
signature on the inner most SignedData. signature on the inner most SignedData.
1.b.1 - If the signatures cannot be verified, the GLO returns a 1.b.1 - If the signatures cannot be verified, the GLO returns a
cMCStatusInfoEx response indicating cMCStatus.failed and cMCStatusInfoEx response indicating cMCStatus.failed and
otherInfo.failInfo.badMessageCheck. otherInfo.failInfo.badMessageCheck.
1.b.1.a - If the signatures verify, the GLO checks the names in 1.b.1.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 57 Turner 57
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.1.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.1.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
skipping to change at line 2967 skipping to change at line 3073
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 verifies the
GL member signature(s). If an additional SignedData and/or GL member signature(s). If an additional SignedData and/or
EnvelopedData encapsulates the request (see section 3.2.1.2 or EnvelopedData encapsulates the request (see section 3.2.1.2 or
3.2.2), the GLA verifies the outer signature and/or decrypt 3.2.2), the GLA verifies the outer signature and/or decrypt
the outer layer prior to verifying the signature on the inner the outer layer prior to verifying the signature on the inner
most SignedData. most SignedData.
Turner 58 Turner 58
And Distribution
2.a - If the signatures cannot be verified, the GLA returns a 2.a - If the signatures cannot be verified, the GLA returns a
cMCStatusInfoEx response indicating cMCStatus.failed and cMCStatusInfoEx response indicating cMCStatus.failed and
otherInfo.failInfo.badMessageCheck. otherInfo.failInfo.badMessageCheck.
2.b - Else if the signatures verify, the GLA makes sure the GL is 2.b - 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.b.1 - If the name of the GL is not supported by the GLA, the GLA
returns a response indicating cMCStatusInfoEx with returns a response indicating cMCStatusInfoEx with
skipping to change at line 3017 skipping to change at line 3125
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 the GLA (1 in Figure 11). The GLO, GL member, or prospective
Turner 59 Turner 59
And Distribution
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.
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
skipping to change at line 3070 skipping to change at line 3180
2.b.2.b - The GLA can also optionally apply another SignedData 2.b.2.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 verifies the GLA signature(s). If an
additional SignedData and/or EnvelopedData encapsulates the additional SignedData and/or EnvelopedData encapsulates the
response (see section 3.2.1.2 or 3.2.2), the GLO, GL member, response (see section 3.2.1.2 or 3.2.2), the GLO, GL member,
or prospective GL member verifies the outer signature and/or or prospective GL member verifies the outer signature and/or
Turner 60 Turner 60
And Distribution
decrypt the outer layer prior to verifying the signature on decrypt the outer layer prior to verifying the signature on
the inner most SignedData. the inner most SignedData.
3.a - If the signatures do not verify, the GLO, GL member, or 3.a - If the signatures do not verify, the GLO, GL member, or
prospective GL member returns a cMCStatusInfoEx response prospective GL member returns a cMCStatusInfoEx response
indicating cMCStatus.failed and indicating cMCStatus.failed and
otherInfo.failInfo.badMessageCheck. otherInfo.failInfo.badMessageCheck.
3.b - Else if the signatures verify, then the GLO, GL member, or 3.b - 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
skipping to change at line 3123 skipping to change at line 3235
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 61 Turner 61
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 verifies the GLO or GLA signature(s). If an additional
SignedData and/or EnvelopedData encapsulates the response (see SignedData and/or EnvelopedData encapsulates the response (see
section 3.2.1.2 or 3.2.2), the GL member verifies the outer section 3.2.1.2 or 3.2.2), the GL member verifies the outer
signature and/or decrypt the outer layer prior to verifying signature and/or decrypt the outer layer prior to verifying
the signature on the inner most SignedData. the signature on the inner most SignedData.
2.a - If the signatures cannot be verified, the GL member returns 2.a - If the signatures cannot be verified, the GL member returns
a cMCStatusInfoEx response indicating cMCStatus.failed and a cMCStatusInfoEx response indicating cMCStatus.failed and
otherInfo.failInfo.badMessageCheck. otherInfo.failInfo.badMessageCheck.
skipping to change at line 3175 skipping to change at line 3289
3.b - Else if the signatures verify, the GLO or GLA verifies the 3.b - 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.b.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
cMCStatusInfoEx with cMCStatus.failed and the reason why cMCStatusInfoEx 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 62 Turner 62
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.
3.b.2 - Else if the memberĘs encryption certificate cannot be 3.b.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 cMCStatusInfoEx with cMCStatus.failed the GL member or a cMCStatusInfoEx 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.
skipping to change at line 3226 skipping to change at line 3342
EnvelopedData encapsulates the response (see section 3.2.1.2 EnvelopedData encapsulates the response (see section 3.2.1.2
or 3.2.2), the GLA verifies the outer signature and/or decrypt or 3.2.2), the GLA verifies the outer signature and/or decrypt
the outer layer prior to verifying the signature on the inner the outer layer prior to verifying the signature on the inner
most SignedData. most SignedData.
2.a - If the signatures cannot be verified, the GLA returns a 2.a - If the signatures cannot be verified, the GLA returns a
cMCStatusInfoEx response indicating cMCStatus.failed and cMCStatusInfoEx response indicating cMCStatus.failed and
otherInfo.failInfo.badMessageCheck. otherInfo.failInfo.badMessageCheck.
Turner 63 Turner 63
And Distribution
2.b - Else if the signatures verify, the GLA verifies the memberĘs 2.b - 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.b.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
member or a cMCStatusInfoEx with cMCStatus.failed and the member or a cMCStatusInfoEx 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.
skipping to change at line 3270 skipping to change at line 3388
+-------> | 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 FALSE, a separate glKey message MUST be sent to each GL set to FALSE, a separate glKey message MUST be sent to each GL
member so as to not divulge information about the other GL members. member so as to not divulge information about the other GL members.
Turner 64 Turner 64
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 The GLA MUST use either the kari (see section 12.3.2 of CMS [2]) or
skipping to change at line 3322 skipping to change at line 3442
2 - Upon receipt of the glKey message, the GL members MUST verify 2 - Upon receipt of the glKey message, the GL members MUST verify
the signature over the inner most SignedData.PKIData. If an the signature over the inner most SignedData.PKIData. If an
additional SignedData and/or EnvelopedData encapsulates the additional SignedData and/or EnvelopedData encapsulates the
message (see section 3.2.1.2 or 3.2.2), the GL Member MUST message (see section 3.2.1.2 or 3.2.2), the GL Member MUST
verify the outer signature and/or decrypt the outer layer verify the outer signature and/or decrypt the outer layer
prior to verifying the signature on the prior to verifying the signature on the
SignedData.PKIData.controlSequence.glKey. SignedData.PKIData.controlSequence.glKey.
Turner 65 Turner 65
And Distribution
2.a - If the signatures cannot be verified, the GL member MUST 2.a - If the signatures cannot be verified, the GL member MUST
return a cMCStatusInfoEx response indicating return a cMCStatusInfoEx response indicating
cMCStatus.failed and otherInfo.failInfo.badMessageCheck. cMCStatus.failed and otherInfo.failInfo.badMessageCheck.
2.b - Else if the signatures verify, the GL member process the 2.b - Else if the signatures verify, the GL member process the
RecipientInfos according to CMS [2]. Once unwrapped the GL RecipientInfos according to CMS [2]. 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
cMCStatusInfoEx indicating cMCStatus.success to tell the GLA cMCStatusInfoEx indicating cMCStatus.success to tell the GLA
skipping to change at line 3372 skipping to change at line 3494
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 [12].
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 [12].
Turner 66 Turner 66
And Distribution
7 Message Transport 7 Message Transport
SMTP [13] MUST be supported. Other transport mechanisms MAY also be SMTP [13] MUST be supported. Other transport mechanisms MAY also be
supported. 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
skipping to change at line 3421 skipping to change at line 3544
9 References 9 References
1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP
9, RFC 2026, October 1996. 9, RFC 2026, October 1996.
2 Housley, R., "Cryptographic Message Syntax," draft-ietf-smime- 2 Housley, R., "Cryptographic Message Syntax," draft-ietf-smime-
rfc2630bis-01.txt, April 2001. rfc2630bis-01.txt, April 2001.
Turner 67 Turner 67
And Distribution
3 Myers, M., Liu, X., Schaad, J., Weinsten, J., "Certificate 3 Myers, M., Liu, X., Schaad, J., Weinsten, J., "Certificate
Management Message over CMS," draft-ietf-pkix-2797-bis-00.txt, Management Message over CMS," draft-ietf-pkix-2797-bis-00.txt,
April 2001. April 2001.
4 Bradner, S., "Key words for use in RFCs to Indicate Requirement 4 Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
5 Housley, R., Ford, W., Polk, W. and D. Solo, "Internet X.509 5 Housley, R., Ford, W., Polk, W. and D. Solo, "Internet X.509
Public Key Infrastructure: Certificate and CRL Profile", draft- Public Key Infrastructure: Certificate and CRL Profile", draft-
ietf-pkix-new-part1-06.txt, 8 March 2001. ietf-pkix-new-part1-06.txt, 8 March 2001.
skipping to change at line 3462 skipping to change at line 3587
13 Postel, j., "Simple Mail Transport Protocol," RFC 821, August 13 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 68 Turner 68
And Distribution
11 Author's Addresses 11 Author's Addresses
Sean Turner Sean Turner
IECA, Inc. IECA, Inc.
9010 Edgepark Road 9010 Edgepark Road
Vienna, VA 22182 Vienna, VA 22182
Phone: +1.703.628.3180 Phone: +1.703.628.3180
Email: turners@ieca.com Email: turners@ieca.com
Turner 69 Turner 69
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 3526 skipping to change at line 3653
-- 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 70 Turner 70
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,
glAddress GeneralName } glAddress GeneralName }
skipping to change at line 3575 skipping to change at line 3704
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 71 Turner 71
And Distribution
Certificates ::= SEQUENCE { Certificates ::= SEQUENCE {
pKC [0] Certificate OPTIONAL, pKC [0] Certificate OPTIONAL,
-- See PKIX [5] -- See PKIX [5]
aC [1] SEQUENCE SIZE (1.. MAX) OF aC [1] SEQUENCE SIZE (1.. MAX) OF
AttributeCertificate OPTIONAL, AttributeCertificate OPTIONAL,
-- See ACPROF [6] -- See ACPROF [6]
certPath [2] CertificateSet OPTIONAL } certPath [2] CertificateSet OPTIONAL }
-- From CMS [2] -- From CMS [2]
-- This defines the Delete GL Member control attribute -- This defines the Delete GL Member control attribute
skipping to change at line 3626 skipping to change at line 3757
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 72 Turner 72
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 }
Date ::= SEQUENCE { Date ::= SEQUENCE {
start GeneralizedTime, start GeneralizedTime,
skipping to change at line 3675 skipping to change at line 3808
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 [7].
Turner 73 Turner 73
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 }
-- This defines the control attribute to return an updated -- This defines the control attribute to return an updated
skipping to change at line 3703 skipping to change at line 3838
GLKey ::= SEQUENCE { GLKey ::= SEQUENCE {
glName GeneralName, glName GeneralName,
glIdentifier KEKIdentifier, -- See CMS [2] glIdentifier KEKIdentifier, -- See CMS [2]
glkWrapped RecipientInfos, -- See CMS [2] glkWrapped RecipientInfos, -- See CMS [2]
glkAlgorithm AlgorithmIdentifier, glkAlgorithm AlgorithmIdentifier,
glkNotBefore GeneralizedTime, glkNotBefore GeneralizedTime,
glkNotAfter GeneralizedTime } glkNotAfter GeneralizedTime }
Turner 74 Turner 74
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),
closedGL (1), closedGL (1),
unsupportedDuration (2), unsupportedDuration (2),
 End of changes. 

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