draft-ietf-smime-symkeydist-08.txt   draft-ietf-smime-symkeydist-09.txt 
SMIME Working Group S. Turner SMIME Working Group S. Turner
Internet Draft IECA Internet Draft IECA
Document: draft-ietf-smime-symkeydist-08.txt December 2002 Document: draft-ietf-smime-symkeydist-09.txt January 2003
Expires: June 2003 Expires: July 2003
CMS Symmetric Key Management and Distribution CMS Symmetric Key Management and Distribution
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
This document is an Internet-Draft. Internet-Drafts are working This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, documents of the Internet Engineering Task Force (IETF), its areas,
skipping to change at line 105 skipping to change at line 105
4.1 ASSIGN KEK TO GL..............................................30 4.1 ASSIGN KEK TO GL..............................................30
4.2 DELETE GL FROM GLA............................................33 4.2 DELETE GL FROM GLA............................................33
4.3 ADD MEMBERS TO GL.............................................36 4.3 ADD MEMBERS TO GL.............................................36
4.3.1 GLO INITIATED ADDITIONS.....................................37 4.3.1 GLO INITIATED ADDITIONS.....................................37
4.3.2 PROSPECTIVE MEMBER INITIATED ADDITIONS......................43 4.3.2 PROSPECTIVE MEMBER INITIATED ADDITIONS......................43
4.4 DELETE MEMBERS FROM GL........................................45 4.4 DELETE MEMBERS FROM GL........................................45
4.4.1 GLO INITIATED DELETIONS.....................................46 4.4.1 GLO INITIATED DELETIONS.....................................46
4.4.2 MEMBER INITIATED DELETIONS..................................51 4.4.2 MEMBER INITIATED DELETIONS..................................51
4.5 REQUEST REKEY OF GL...........................................53 4.5 REQUEST REKEY OF GL...........................................53
Turner Expires June 2003 2 Turner Expires July 2003 2
And Distribution And Distribution
4.5.1 GLO INITIATED REKEY REQUESTS................................54 4.5.1 GLO INITIATED REKEY REQUESTS................................54
4.5.2 GLA INITIATED REKEY REQUESTS................................56 4.5.2 GLA INITIATED REKEY REQUESTS................................56
4.6 CHANGE GLO....................................................57 4.6 CHANGE GLO....................................................57
4.7 INDICATE KEK COMPROMISE.......................................60 4.7 INDICATE KEK COMPROMISE.......................................60
4.7.1 GL MEMBER INITIATED KEK COMPROMISE MESSAGE..................60 4.7.1 GL MEMBER INITIATED KEK COMPROMISE MESSAGE..................60
4.7.2 GLO INITIATED KEK COMPROMISE MESSAGE........................61 4.7.2 GLO INITIATED KEK COMPROMISE MESSAGE........................61
4.8 REQUEST KEK REFRESH...........................................63 4.8 REQUEST KEK REFRESH...........................................63
4.9 GLA QUERY REQUEST AND RESPONSE................................64 4.9 GLA QUERY REQUEST AND RESPONSE................................64
skipping to change at line 158 skipping to change at line 158
recipient (ktri RecipientInfo CHOICE), or (b) transfers sufficient recipient (ktri RecipientInfo CHOICE), or (b) transfers sufficient
parameters to enable a particular recipient to independently parameters to enable a particular recipient to independently
generate the same KEK (kari RecipientInfo CHOICE). If the group is generate the same KEK (kari RecipientInfo CHOICE). If the group is
large, processing of the per-recipient information may take quite large, processing of the per-recipient information may take quite
some time, not to mention the time required to collect and validate some time, not to mention the time required to collect and validate
the PKCs for each of the recipients. Each recipient identifies its the PKCs for each of the recipients. Each recipient identifies its
per-recipient information and uses the private key associated with per-recipient information and uses the private key associated with
the public key of its PKC to decrypt the CEK and hence gain access the public key of its PKC to decrypt the CEK and hence gain access
to the encrypted content. to the encrypted content.
Turner Expires June 2003 3 Turner Expires July 2003 3
And Distribution And Distribution
With symmetric algorithms, the origination process is slightly With symmetric algorithms, the origination process is slightly
different. Instead of using PKCs, the originator uses a previously different. Instead of using PKCs, the originator uses a previously
distributed secret key-encryption key (KEK) to encrypt the CEK distributed secret key-encryption key (KEK) to encrypt the CEK
(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.
skipping to change at line 211 skipping to change at line 211
and access to that object can then decrypt that object. The and access to that object can then decrypt that object. The
encrypted object and the encrypted, shared KEK can be stored in the encrypted object and the encrypted, shared KEK can be stored in the
repository. repository.
1.3 Using the Group Key 1.3 Using the Group Key
This document was written with three specific scenarios in mind: two This document was written with three specific scenarios in mind: two
supporting mail list agents and one for general message supporting mail list agents and one for general message
distribution. Scenario 1 depicts the originator sending a public key distribution. Scenario 1 depicts the originator sending a public key
Turner Expires June 2003 4 Turner Expires July 2003 4
And Distribution And Distribution
(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
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). The key used by the (the MLA only adds additional recipients). The key used by the
originator could either be a key shared amongst all recipients or originator could either be a key shared amongst all recipients or
just between the member and the MLA. Note that if the originator use just between the member and the MLA. Note that if the originator use
a key shared only with the MLA, then the MLA will need to decrypt a key shared only with the MLA, then the MLA will need to decrypt
skipping to change at line 265 skipping to change at line 265
| +------------------------+ | | +------------------------+ |
+----------------------------------------------+ +----------------------------------------------+
/ | \ / | \
/ | \ / | \
+----------+ +---------+ +----------+ +----------+ +---------+ +----------+
| Member 1 | | ... | | Member n | | Member 1 | | ... | | Member n |
+----------+ +---------+ +----------+ +----------+ +---------+ +----------+
Figure 1 - Key Distribution Architecture Figure 1 - Key Distribution Architecture
Turner Expires June 2003 5 Turner Expires July 2003 5
And Distribution And Distribution
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.
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
skipping to change at line 319 skipping to change at line 319
3 Protocol Interactions 3 Protocol Interactions
There are existing mechanisms (e.g., listserv and majordomo) to There are existing mechanisms (e.g., listserv and majordomo) to
manage GLs; however, this document does not address securing these manage GLs; however, this document does not address securing these
mechanisms, as they are not standardized. Instead, it defines mechanisms, as they are not standardized. Instead, it defines
protocol interactions, as depicted in Figure 2, used by the GL protocol interactions, as depicted in Figure 2, used by the GL
members, GLA, and GLO(s) to manage GLs and distribute shared KEKs. members, GLA, and GLO(s) to manage GLs and distribute shared KEKs.
The interactions have been divided into administration messages and The interactions have been divided into administration messages and
Turner Expires June 2003 6 Turner Expires July 2003 6
And Distribution And Distribution
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
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
skipping to change at line 348 skipping to change at line 348
+-----+ <------+ | +----------+ +-----+ <------+ | +----------+
| GLA | <-------------+----> | ... | | GLA | <-------------+----> | ... |
+-----+ | +----------+ +-----+ | +----------+
| |
| +----------+ | +----------+
+----> | Member n | +----> | Member n |
+----------+ +----------+
Figure 2 - Protocol Interactions Figure 2 - Protocol Interactions
Turner Expires June 2003 7 Turner Expires July 2003 7
And Distribution And Distribution
3.1 Control Attributes 3.1 Control Attributes
To avoid creating an entirely new protocol, the Certificate To avoid creating an entirely new protocol, the Certificate
Management Messages over CMS (CMC) protocol was chosen as the Management Messages over CMS (CMC) protocol was chosen as the
foundation of this protocol. The main reason for the choice was the foundation of this protocol. The main reason for the choice was the
layering aspect provided by CMC where one or more control attributes layering aspect provided by CMC where one or more control attributes
are included in message, protected with CMS, to request or respond are included in message, protected with CMS, to request or respond
to a desired action. The CMC PKIData structure is used for requests, to a desired action. The CMC PKIData structure is used for requests,
skipping to change at line 396 skipping to change at line 396
GL members. The GLO is an optional component hence all GLO O and GLO GL members. The GLO is an optional component hence all GLO O and GLO
R messages are optional, and GLA F messages are optional. The first R messages are optional, and GLA F messages are optional. The first
table includes messages that conformant implementions MUST support. table includes messages that conformant implementions MUST support.
The second table includes messages that MAY be implemented. The The second table includes messages that MAY be implemented. The
second table should be interpreted as follows: if the control second table should be interpreted as follows: if the control
attribute is implemented by a component then it must be implemented attribute is implemented by a component then it must be implemented
as indicated. For example, if a GLA is implemented that supports the as indicated. For example, if a GLA is implemented that supports the
glAddMember control attribute, then it MUST support receiving the glAddMember control attribute, then it MUST support receiving the
glAddMember message. Note that "-" means not applicable. glAddMember message. Note that "-" means not applicable.
Turner Expires June 2003 8 Turner Expires July 2003 8
And Distribution And Distribution
Required Required
Implementation Requirement | Control Implementation Requirement | Control
GLO | GLA | GL Member | Attribute GLO | GLA | GL Member | Attribute
O R | O R F | O R | O R | O R F | O R |
------- | ----------------- | --------- | ---------- ------- | ----------------- | --------- | ----------
MAY - | MUST - MAY | - MUST | glProvideCert MAY - | MUST - MAY | - MUST | glProvideCert
MAY MAY | - MUST MAY | MUST - | glUpdateCert MAY MAY | - MUST MAY | MUST - | glUpdateCert
- - | MUST - - | - MUST | glKey - - | MUST - - | - MUST | glKey
skipping to change at line 444 skipping to change at line 444
The GLO uses glUseKEK to request that a shared KEK be assigned to a The GLO uses glUseKEK to request that a shared KEK be assigned to a
GL. glUseKEK messages MUST be signed by the GLO. The glUseKEK GL. glUseKEK messages MUST be signed by the GLO. The glUseKEK
control attribute has the syntax GLUseKEK: control attribute has the syntax GLUseKEK:
GLUseKEK ::= SEQUENCE { GLUseKEK ::= SEQUENCE {
glInfo GLInfo, glInfo GLInfo,
glOwnerInfo SEQUENCE SIZE (1..MAX) OF GLOwnerInfo, glOwnerInfo SEQUENCE SIZE (1..MAX) OF GLOwnerInfo,
glAdministration GLAdministration DEFAULT 1, glAdministration GLAdministration DEFAULT 1,
glKeyAttributes GLKeyAttributes OPTIONAL } glKeyAttributes GLKeyAttributes OPTIONAL }
Turner Expires June 2003 9 Turner Expires July 2003 9
And Distribution And Distribution
GLInfo ::= SEQUENCE { GLInfo ::= SEQUENCE {
glName GeneralName, glName GeneralName,
glAddress GeneralName } glAddress GeneralName }
GLOwnerInfo ::= SEQUENCE { GLOwnerInfo ::= SEQUENCE {
glOwnerName GeneralName, glOwnerName GeneralName,
glOwnerAddress GeneralName, glOwnerAddress GeneralName,
certificate Certificates OPTIONAL } certificate Certificates OPTIONAL }
skipping to change at line 499 skipping to change at line 499
the GL in glAddress. The glName and glAddress can be the same, the GL in glAddress. The glName and glAddress can be the same,
but this is not always the case. Both the name and address MUST but this is not always the case. Both the name and address MUST
be unique for a given GLA. be unique for a given GLA.
- glOwnerInfo indicates: - glOwnerInfo indicates:
- glOwnerName indicates the name of the owner of the GL. One of - glOwnerName indicates the name of the owner of the GL. One of
the names in glOwnerName MUST match one of the names in the the names in glOwnerName MUST match one of the names in the
certificate (either the subject distinguished name or one of certificate (either the subject distinguished name or one of
Turner Expires June 2003 10 Turner Expires July 2003 10
And Distribution And Distribution
the subject alternative names) used to sign this the subject alternative names) used to sign this
SignedData.PKIData creating the GL (i.e., the immediate SignedData.PKIData creating the GL (i.e., the immediate
signer). signer).
- glOwnerAddress indicates the address of the owner of the GL. - glOwnerAddress indicates the address of the owner of the GL.
- certificates MAY be included. It contains the following three - certificates MAY be included. It contains the following three
fields: fields:
skipping to change at line 554 skipping to change at line 554
- glKeyAttributes indicates the attributes the GLO wants the GLA - glKeyAttributes indicates the attributes the GLO wants the GLA
to assign to the shared KEK. If this field is omitted, GL rekeys to assign to the shared KEK. If this field is omitted, GL rekeys
will be controlled by the GLA, the recipients are allowed to will be controlled by the GLA, the recipients are allowed to
know about one another, the algorithm will be Triple-DES (see know about one another, the algorithm will be Triple-DES (see
paragrpah 7), the shared KEK will be valid for a calendar month paragrpah 7), the shared KEK will be valid for a calendar month
(i.e., first of the month until the last day of the month), and (i.e., first of the month until the last day of the month), and
two shared KEKs will be distributed initially. The fields in two shared KEKs will be distributed initially. The fields in
glKeyAttributes have the following meaning: glKeyAttributes have the following meaning:
Turner Expires June 2003 11 Turner Expires July 2003 11
And Distribution And Distribution
- rekeyControlledByGLO indicates whether the GL rekey messages - rekeyControlledByGLO indicates whether the GL rekey messages
will be generated by the GLO or by the GLA. The default is for will be generated by the GLO or by the GLA. The default is for
the GLA to control rekeys. If GL rekey is controlled by the the GLA to control rekeys. If GL rekey is controlled by the
GLA, the GL will continue to be rekeyed until the GLO deletes GLA, the GL will continue to be rekeyed until the GLO deletes
the GL or changes the GL rekey to be GLO controlled. the GL or changes the GL rekey to be GLO controlled.
- recipientsNotMutuallyAware indicates that the GLO wants the - recipientsNotMutuallyAware indicates that the GLO wants the
GLA to distribute the shared KEK individually for each of the GLA to distribute the shared KEK individually for each of the
skipping to change at line 609 skipping to change at line 609
longer valid the second key can be used. If the GLA controls longer valid the second key can be used. If the GLA controls
rekey then it also indicates the number of shared KEKs the GLO rekey then it also indicates the number of shared KEKs the GLO
wants outstanding at any one time. See sections 4.5 and 5 for wants outstanding at any one time. See sections 4.5 and 5 for
more on rekey. more on rekey.
- requestedAlgorithm indicates the algorithm and any parameters - requestedAlgorithm indicates the algorithm and any parameters
the GLO wants the GLA to use with the shared KEK. The the GLO wants the GLA to use with the shared KEK. The
parameters are conveyed via the SMIMECapabilities attribute parameters are conveyed via the SMIMECapabilities attribute
(see [MSG]). See section 6 for more on algorithms. (see [MSG]). See section 6 for more on algorithms.
Turner Expires June 2003 12 Turner Expires July 2003 12
And Distribution And Distribution
3.1.2 Delete GL 3.1.2 Delete GL
GLOs use glDelete to request that a GL be deleted from the GLA. The GLOs use glDelete to request that a GL be deleted from the GLA. The
glDelete control attribute has the syntax GeneralName. The glDelete glDelete control attribute has the syntax GeneralName. The glDelete
message MUST be signed by the GLO. The name of the GL to be deleted message MUST be signed by the GLO. The name of the GL to be deleted
is included in GeneralName: is included in GeneralName:
DeleteGL ::= GeneralName DeleteGL ::= GeneralName
skipping to change at line 663 skipping to change at line 663
-- certificates and v2 attribute certificates in v2AttrCert. -- certificates and v2 attribute certificates in v2AttrCert.
The fields in GLAddMembers have the following meaning: The fields in GLAddMembers have the following meaning:
- glName indicates the name of the GL to which the member should - glName indicates the name of the GL to which the member should
be added. be added.
- glMember indicates the particulars for the GL member. Both of - glMember indicates the particulars for the GL member. Both of
the following fields must be unique for a given GL: the following fields must be unique for a given GL:
Turner Expires June 2003 13 Turner Expires July 2003 13
And Distribution And Distribution
- glMemberName indicates the name of the GL member. - glMemberName indicates the name of the GL member.
- glMemberAddress indicates the GL member's address. It MUST be - glMemberAddress indicates the GL member's address. It MUST be
included. included.
Note: In some instances the glMemberName and glMemberAddress Note: In some instances the glMemberName and glMemberAddress
may be the same, but this is not always the case. may be the same, but this is not always the case.
skipping to change at line 715 skipping to change at line 715
glMemberToDelete GeneralName } glMemberToDelete GeneralName }
The fields in GLDeleteMembers have the following meaning: The fields in GLDeleteMembers have the following meaning:
- glName indicates the name of the GL from which the member should - glName indicates the name of the GL from which the member should
be removed. be removed.
- glMemberToDelete indicates the name or address of the member to - glMemberToDelete indicates the name or address of the member to
be deleted. be deleted.
Turner Expires June 2003 14 Turner Expires July 2003 14
And Distribution And Distribution
3.1.5 Rekey GL 3.1.5 Rekey GL
GLOs use the glRekey to request a GL rekey. The glRekey message MUST GLOs use the glRekey to request a GL rekey. The glRekey message MUST
be signed by the GLO. The glRekey control attribute has the syntax be signed by the GLO. The glRekey control attribute has the syntax
GLRekey: GLRekey:
GLRekey ::= SEQUENCE { GLRekey ::= SEQUENCE {
glName GeneralName, glName GeneralName,
skipping to change at line 768 skipping to change at line 768
GLOs use the glAddOwner to request that a new GLO be allowed to GLOs use the glAddOwner to request that a new GLO be allowed to
administer the GL. The glAddOwner message MUST be signed by a administer the GL. The glAddOwner message MUST be signed by a
registered GLO. The glAddOwner control attribute has the syntax registered GLO. The glAddOwner control attribute has the syntax
GLOwnerAdministration: GLOwnerAdministration:
GLOwnerAdministration ::= SEQUENCE { GLOwnerAdministration ::= SEQUENCE {
glName GeneralName, glName GeneralName,
glOwnerInfo GLOwnerInfo } glOwnerInfo GLOwnerInfo }
Turner Expires June 2003 15 Turner Expires July 2003 15
And Distribution And Distribution
The fields in GLAddOwners have the following meaning: The fields in GLAddOwners have the following meaning:
- glName indicates the name of the GL to which the new GLO should - glName indicates the name of the GL to which the new GLO should
be associated. be associated.
- glOwnerInfo indicates the name, address, and certificates of the - glOwnerInfo indicates the name, address, and certificates of the
new GLO. As this message includes names of new GLOs, the new GLO. As this message includes names of new GLOs, the
certificates.pKC MUST be included, and it MUST include the certificates.pKC MUST be included, and it MUST include the
skipping to change at line 819 skipping to change at line 819
key is associated with is placed in GeneralName: key is associated with is placed in GeneralName:
GLKCompromise ::= GeneralName GLKCompromise ::= GeneralName
3.1.9 GL Key Refresh 3.1.9 GL Key Refresh
GL members use the glkRefresh to request that the shared KEK be GL members use the glkRefresh to request that the shared KEK be
redistributed to them. The glkRefresh control attribute has the redistributed to them. The glkRefresh control attribute has the
syntax GLKRefresh. syntax GLKRefresh.
Turner Expires June 2003 16 Turner Expires July 2003 16
And Distribution And Distribution
GLKRefresh ::= SEQUENCE { GLKRefresh ::= SEQUENCE {
glName GeneralName, glName GeneralName,
dates SEQUENCE SIZE (1..MAX) OF Date } dates SEQUENCE SIZE (1..MAX) OF Date }
Date ::= SEQUENCE { Date ::= SEQUENCE {
start GeneralizedTime, start GeneralizedTime,
end GeneralizedTime OPTIONAL } end GeneralizedTime OPTIONAL }
skipping to change at line 869 skipping to change at line 869
GLAQueryRequest ::= SEQUENCE { GLAQueryRequest ::= SEQUENCE {
glaRequestType OBJECT IDENTIFIER, glaRequestType OBJECT IDENTIFIER,
glaRequestValue ANY DEFINED BY glaRequestType } glaRequestValue ANY DEFINED BY glaRequestType }
3.1.10.2 GLA Query Response 3.1.10.2 GLA Query Response
GLAs return the glaQueryResponse after receiving a GLAQueryRequest. GLAs return the glaQueryResponse after receiving a GLAQueryRequest.
The glaQueryResponse MUST be signed by a GLA. The glaQueryResponse The glaQueryResponse MUST be signed by a GLA. The glaQueryResponse
control attribute has the syntax GLAQueryResponse: control attribute has the syntax GLAQueryResponse:
Turner Expires June 2003 17 Turner Expires July 2003 17
And Distribution And Distribution
GLAQueryResponse ::= SEQUENCE { GLAQueryResponse ::= SEQUENCE {
glaResponseType OBJECT IDENTIFIER, glaResponseType OBJECT IDENTIFIER,
glaResponseValue ANY DEFINED BY glaResponseType } glaResponseValue ANY DEFINED BY glaResponseType }
3.1.10.3 Request and Response Types 3.1.10.3 Request and Response Types
Request and Responses are registered as a pair under the following Request and Responses are registered as a pair under the following
object identifier arc: object identifier arc:
skipping to change at line 922 skipping to change at line 922
The fields in GLManageCert have the following meaning: The fields in GLManageCert have the following meaning:
- glName indicates the name of the GL to which the GL member's new - glName indicates the name of the GL to which the GL member's new
certificate is to be associated. certificate is to be associated.
- glMember indicates particulars for the GL member: - glMember indicates particulars for the GL member:
- glMemberName indicates the GL member's name. - glMemberName indicates the GL member's name.
Turner Expires June 2003 18 Turner Expires July 2003 18
And Distribution And Distribution
- glMemberAddress indicates the GL member's address. It MAY be - glMemberAddress indicates the GL member's address. It MAY be
omitted. omitted.
- certificates SHOULD be omitted. - certificates SHOULD be omitted.
3.1.13 Update Cert 3.1.13 Update Cert
GL members and GLOs use the glUpdateCert to provide a new GL members and GLOs use the glUpdateCert to provide a new
skipping to change at line 975 skipping to change at line 975
- certificates.aC MAY be included to convey one or more - certificates.aC MAY be included to convey one or more
attribute certificate associated with the member's attribute certificate associated with the member's
encryption certificate. encryption certificate.
- certificates.certPath MAY also be included to convey - certificates.certPath MAY also be included to convey
certificates that might aid the recipient in constructing certificates that might aid the recipient in constructing
valid certification paths for the certificate provided in valid certification paths for the certificate provided in
certificates.pKC and the attribute certificates provided in certificates.pKC and the attribute certificates provided in
certificates.aC. These certificates is optional because they certificates.aC. These certificates is optional because they
Turner Expires June 2003 19 Turner Expires July 2003 19
And Distribution And Distribution
might already be included elsewhere in the message (e.g., in might already be included elsewhere in the message (e.g., in
the outer CMS layer). the outer CMS layer).
3.1.14 GL Key 3.1.14 GL Key
The GLA uses the glKey to distribute the shared KEK. The glKey The GLA uses the glKey to distribute the shared KEK. The glKey
message MUST be signed by the GLA. The glKey control attribute has message MUST be signed by the GLA. The glKey control attribute has
the syntax GLKey: the syntax GLKey:
skipping to change at line 1028 skipping to change at line 1028
- glkAlgorithm identifies the algorithm the shared KEK is used - glkAlgorithm identifies the algorithm the shared KEK is used
with. Since no encrypted data content is being conveyed at this with. Since no encrypted data content is being conveyed at this
point, the parameters encoded with the algorithm should be the point, the parameters encoded with the algorithm should be the
structure defined for smimeCapabilities rather than encrypted structure defined for smimeCapabilities rather than encrypted
content. content.
- glkNotBefore indicates the date at which the shared KEK is - glkNotBefore indicates the date at which the shared KEK is
considered valid. GeneralizedTime values MUST be expressed in considered valid. GeneralizedTime values MUST be expressed in
UTC (Zulu) and MUST include seconds (i.e., times are UTC (Zulu) and MUST include seconds (i.e., times are
Turner Expires June 2003 20 Turner Expires July 2003 20
And Distribution And Distribution
YYYYMMDDHHMMSSZ), even where the number of seconds is zero. YYYYMMDDHHMMSSZ), even where the number of seconds is zero.
GeneralizedTime values MUST NOT include fractional seconds. GeneralizedTime values MUST NOT include fractional seconds.
- glkNotAfter indicates the date after which the shared KEK is - glkNotAfter indicates the date after which the shared KEK is
considered invalid. GeneralizedTime values MUST be expressed in considered invalid. GeneralizedTime values MUST be expressed in
UTC (Zulu) and MUST include seconds (i.e., times are UTC (Zulu) and MUST include seconds (i.e., times are
YYYYMMDDHHMMSSZ), even where the number of seconds is zero. YYYYMMDDHHMMSSZ), even where the number of seconds is zero.
GeneralizedTime values MUST NOT include fractional seconds. GeneralizedTime values MUST NOT include fractional seconds.
skipping to change at line 1083 skipping to change at line 1083
last outstanding shared KEK expiring, where the number of glKey last outstanding shared KEK expiring, where the number of glKey
messages generated is generationCounter minus one (1). Other messages generated is generationCounter minus one (1). Other
distribution mechanisms can also be supported to support this distribution mechanisms can also be supported to support this
functionality. functionality.
3.2 Use of CMC, CMS, and PKIX 3.2 Use of CMC, CMS, and PKIX
The following sections outline the use of CMC, CMS, and the PKIX The following sections outline the use of CMC, CMS, and the PKIX
certificate and CRL profile. certificate and CRL profile.
Turner Expires June 2003 21 Turner Expires July 2003 21
And Distribution And Distribution
3.2.1 Protection Layers 3.2.1 Protection Layers
The following sections outline the protection required for the The following sections outline the protection required for the
control attributes defined in this document. control attributes defined in this document.
Note: There are multiple ways to encapsulate SignedData and Note: There are multiple ways to encapsulate SignedData and
EnvelopedData. The first is to use a MIME wrapper around each EnvelopedData. The first is to use a MIME wrapper around each
ContentInfo, as specified in [MSG]. The second is to not use a MIME ContentInfo, as specified in [MSG]. The second is to not use a MIME
skipping to change at line 1133 skipping to change at line 1133
EnvelopedData SignedData EnvelopedData SignedData
SignedData EnvelopedData SignedData EnvelopedData
PKIData or PKIResponse SignedData PKIData or PKIResponse SignedData
controlSequence PKIData or PKIResponse controlSequence PKIData or PKIResponse
controlSequence controlSequence
If an incoming message is encrypted, the confidentiality of the If an incoming message is encrypted, the confidentiality of the
message MUST be preserved. All EnvelopedData objects MUST be message MUST be preserved. All EnvelopedData objects MUST be
processed as specified in [CMS]. If a SignedData is added over an processed as specified in [CMS]. If a SignedData is added over an
Turner Expires June 2003 22 Turner Expires July 2003 22
And Distribution And Distribution
EnvelopedData, a ContentHints attribute SHOULD be added. See EnvelopedData, a ContentHints attribute SHOULD be added. See
paragraph 2.9 of Extended Security Services for S/MIME [ESS]. paragraph 2.9 of Extended Security Services for S/MIME [ESS].
If the GLO or GL member applies confidentiality to a request, the If the GLO or GL member applies confidentiality to a request, the
EnvelopedData MUST include the GLA as a recipient. If the GLA EnvelopedData MUST include the GLA as a recipient. If the GLA
forwards the GL member request to the GLO, then the GLA MUST decrypt forwards the GL member request to the GLO, then the GLA MUST decrypt
the EnvelopedData content, strip the confidentiality layer, and the EnvelopedData content, strip the confidentiality layer, and
apply its own confidentiality layer as an EnvelopedData with the GLO apply its own confidentiality layer as an EnvelopedData with the GLO
skipping to change at line 1175 skipping to change at line 1175
PKIData PKIResponse PKIData PKIResponse
controlSequence controlSequence controlSequence controlSequence
One or more requests One or more responses One or more requests One or more responses
corresponding to one GL corresponding to one GL corresponding to one GL corresponding to one GL
SignedData SignedData SignedData SignedData
PKIData PKIResponse PKIData PKIResponse
controlSequence controlSequence controlSequence controlSequence
One or more requests One or more responses One or more requests One or more responses
corresponding to another GL corresponding to another GL corresponding to another GL corresponding to another GL
Turner Expires June 2003 23 Turner Expires July 2003 23
And Distribution And Distribution
When applying confidentiality to multiple requests and responses, When applying confidentiality to multiple requests and responses,
all of the requests/response MAY be included in one EnvelopedData. all of the requests/response MAY be included in one EnvelopedData.
The following is a depiction: The following is a depiction:
Confidentiality of Multiple Requests and Responses Confidentiality of Multiple Requests and Responses
Wrapped Together Wrapped Together
---------------- ----------------
EnvelopedData EnvelopedData
skipping to change at line 1228 skipping to change at line 1228
as to which to process first: glUseKEK before glAddMember, glRekey as to which to process first: glUseKEK before glAddMember, glRekey
before glAddMember, and glDeleteMember before glRekey. Note that before glAddMember, and glDeleteMember before glRekey. Note that
there is a processing priority but it does not imply an ordering there is a processing priority but it does not imply an ordering
within the content. within the content.
3.2.3 GLA Generated Messages 3.2.3 GLA Generated Messages
When the GLA generates a success or fail message, it generates one When the GLA generates a success or fail message, it generates one
for each request. SKDFailInfo values of unsupportedDuration, for each request. SKDFailInfo values of unsupportedDuration,
Turner Expires June 2003 24 Turner Expires July 2003 24
And Distribution And Distribution
unsupportedDeliveryMethod, unsupportedAlgorithm, noGLONameMatch, unsupportedDeliveryMethod, unsupportedAlgorithm, noGLONameMatch,
nameAlreadyInUse, alreadyAnOwner, notAnOwner are not returned to GL nameAlreadyInUse, alreadyAnOwner, notAnOwner are not returned to GL
members. members.
If GLKeyAttributes.recipientsNotMutuallyAware is set to TRUE, a If GLKeyAttributes.recipientsNotMutuallyAware is set to TRUE, a
separate PKIResponse.cMCStatusInfoExt and PKIData.glKey MUST be separate PKIResponse.cMCStatusInfoExt and PKIData.glKey MUST be
generated for each recipient. However, it is valid to send one generated for each recipient. However, it is valid to send one
message with multiple attributes to the same recipient. message with multiple attributes to the same recipient.
skipping to change at line 1282 skipping to change at line 1282
that a request was unsuccessful. Two classes of failure codes are that a request was unsuccessful. Two classes of failure codes are
used within this document. Errors from the CMCFailInfo list, found used within this document. Errors from the CMCFailInfo list, found
in section 5.1.4 of CMC, are encoded as defined in CMC. Error codes in section 5.1.4 of CMC, are encoded as defined in CMC. Error codes
defined in this document are encoded using the ExtendedFailInfo defined in this document are encoded using the ExtendedFailInfo
field of the cmcStatusInfoExt structure. If the same failure code field of the cmcStatusInfoExt structure. If the same failure code
applies to multiple commands, a single cmcStatusInfoExt structure applies to multiple commands, a single cmcStatusInfoExt structure
can be used with multiple items in cMCStatusInfoExt.bodyList. The can be used with multiple items in cMCStatusInfoExt.bodyList. The
GLA MAY also return other pertinent information in statusString. The GLA MAY also return other pertinent information in statusString. The
SKDFailInfo object identifier and value are: SKDFailInfo object identifier and value are:
Turner Expires June 2003 25 Turner Expires July 2003 25
And Distribution And Distribution
id-cet-skdFailInfo OBJECT IDENTIFIER ::= { iso(1) id-cet-skdFailInfo OBJECT IDENTIFIER ::= { iso(1)
identified-organization(3) dod(6) internet(1) security(5) identified-organization(3) dod(6) internet(1) security(5)
mechanisms(5) pkix(7) cet(15) skdFailInfo(1) } mechanisms(5) pkix(7) cet(15) skdFailInfo(1) }
SKDFailInfo ::= INTEGER { SKDFailInfo ::= INTEGER {
unspecified (0), unspecified (0),
closedGL (1), closedGL (1),
unsupportedDuration (2), unsupportedDuration (2),
skipping to change at line 1335 skipping to change at line 1335
- unsupportedAlgorithm indicates the GLA does not support the - unsupportedAlgorithm indicates the GLA does not support the
requested algorithm. requested algorithm.
- noGLONameMatch indicates that one of the names in the - noGLONameMatch indicates that one of the names in the
certificate used to sign a request does not match the name of a certificate used to sign a request does not match the name of a
registered GLO. registered GLO.
- invalidGLName indicates the GLA does not support the glName - invalidGLName indicates the GLA does not support the glName
present in the request. present in the request.
Turner Expires June 2003 26 Turner Expires July 2003 26
And Distribution And Distribution
- nameAlreadyInUse indicates the glName is already assigned on the - nameAlreadyInUse indicates the glName is already assigned on the
GLA. GLA.
- noSpam indicates the prospective GL member did not sign the - noSpam indicates the prospective GL member did not sign the
request (i.e., if the name in glMember.glMemberName does not request (i.e., if the name in glMember.glMemberName does not
match one of the names (either the subject distinguished name or match one of the names (either the subject distinguished name or
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).
skipping to change at line 1391 skipping to change at line 1391
bodyList value is the bodyPartId value from the request or response. bodyList value is the bodyPartId value from the request or response.
GLOs and GL members who receive cMCStatusInfoExt messages whose GLOs and GL members who receive cMCStatusInfoExt messages whose
signatures are invalid SHOULD generate a new request to avoid signatures are invalid SHOULD generate a new request to avoid
badMessageCheck message loops. badMessageCheck message loops.
cMCStatusInfoExt is also used by GLOs and GLAs to indicate that a cMCStatusInfoExt is also used by GLOs and GLAs to indicate that a
request could not be performed immediately. If the request could not request could not be performed immediately. If the request could not
be processed immediately by the GLA or GLO, the cMCStatusInfoExt be processed immediately by the GLA or GLO, the cMCStatusInfoExt
control attribute MUST be returned indicating cMCStatus.pending and control attribute MUST be returned indicating cMCStatus.pending and
Turner Expires June 2003 27 Turner Expires July 2003 27
And Distribution And Distribution
otherInfo.pendInfo. When requests are redirected to the GLO for otherInfo.pendInfo. When requests are redirected to the GLO for
approval (for managed lists), the GLA MUST NOT return a approval (for managed lists), the GLA MUST NOT return a
cMCStatusInfoExt indicating query pending. cMCStatusInfoExt indicating query pending.
cMCStatusInfoExt is also used by GLAs to indicate that a cMCStatusInfoExt is also used by GLAs to indicate that a
glaQueryRequest is not supported. If the glaQueryRequest is not glaQueryRequest is not supported. If the glaQueryRequest is not
supported, the cMCStatusInfoExt control attribute MUST be returned supported, the cMCStatusInfoExt control attribute MUST be returned
indicating cMCStatus.noSupport and statusString is optionally indicating cMCStatus.noSupport and statusString is optionally
skipping to change at line 1444 skipping to change at line 1444
If the originating message includes a senderNonce, the response to If the originating message includes a senderNonce, the response to
the message MUST include the received senderNonce value as the the message MUST include the received senderNonce value as the
recipientNonce and a new value as the senderNonce value in the recipientNonce and a new value as the senderNonce value in the
response. response.
If a GLA aggragates multiple messages together or forwards a message If a GLA aggragates multiple messages together or forwards a message
to a GLO, the GLA MAY optionally generate a new nonce value and to a GLO, the GLA MAY optionally generate a new nonce value and
include that in the wrapping message. When the response comes back include that in the wrapping message. When the response comes back
from the GLO, the GLA builds a response to the originator(s) of the from the GLO, the GLA builds a response to the originator(s) of the
Turner Expires June 2003 28 Turner Expires July 2003 28
And Distribution And Distribution
message(s) and deals with each of the nonce values from the message(s) and deals with each of the nonce values from the
originating messages. originating messages.
For these attributes it is necessary to maintain state information For these attributes it is necessary to maintain state information
on exchanges to compare one result to another. The time period for on exchanges to compare one result to another. The time period for
which this information is maintained in a local policy. which this information is maintained in a local policy.
3.2.4.4 CMC and CMS Attribute Support Requirements 3.2.4.4 CMC and CMS Attribute Support Requirements
The following are the implementation requirements for CMC control The following are the implementation requirements for CMC control
attributes and CMS signed attributes for an implementation be attributes and CMS signed attributes for an implementation be
considered conformant to this specification: considered conformant to this specification:
Implementation Requirement | Implementation Requirement |
GLO | GLA | GL Member | Attribute GLO | GLA | GL Member | Attribute
O R | O R F | O R | O R | O R F | O R |
--------- | ------------- | --------- | ---------- --------- | ------------- | --------- | ----------
MUST MUST | MUST MUST - | MUST MUST | cMCStatusInfoExt MUST MUST | MUST MUST - | MUST MUST | cMCStatusInfoExt
MAY MAY | MAY MAY - | MAY MAY | transactionId MAY MAY | MUST MUST - | MAY MAY | transactionId
MAY MAY | MAY MAY - | MAY MAY | senderNonce MAY MAY | MUST MUST - | MAY MAY | senderNonce
MAY MAY | MAY MAY - | MAY MAY | recepientNonce MAY MAY | MUST MUST - | MAY MAY | recepientNonce
MUST MUST | MUST MUST - | MUST MUST | SKDFailInfo MUST MUST | MUST MUST - | MUST MUST | SKDFailInfo
MUST MUST | MUST MUST - | MUST MUST | signingTime MUST MUST | MUST MUST - | MUST MUST | signingTime
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
skipping to change at line 1496 skipping to change at line 1496
Name matching is performed according to the PKIX profile [PROFILE]. Name matching is performed according to the PKIX profile [PROFILE].
All distinguished name forms must follow the UTF8String convention All distinguished name forms must follow the UTF8String convention
noted in the PKIX profile [PROFILE]. noted in the PKIX profile [PROFILE].
A certificate per-GL would be issued to the GLA. A certificate per-GL would be issued to the GLA.
GL policy may mandate that the GL member's address be included in GL policy may mandate that the GL member's address be included in
the GL member's certificate. the GL member's certificate.
Turner Expires June 2003 29 Turner Expires July 2003 29
And Distribution And Distribution
4 Administrative Messages 4 Administrative Messages
There are a number of administrative messages that must be performed There are a number of administrative messages that must be performed
to manage a GL. The following sections describe each request and to manage a GL. The following sections describe each request and
response message combination in detail. The procedures defined in response message combination in detail. The procedures defined in
this section are not prescriptive. this section are not prescriptive.
4.1 Assign KEK To GL 4.1 Assign KEK To GL
skipping to change at line 1549 skipping to change at line 1549
glAddMember request(s) MAY be included in the same glAddMember request(s) MAY be included in the same
controlSequence as the glUseKEK request (see section 3.2.2). controlSequence as the glUseKEK request (see section 3.2.2).
The GLO indicates the same glName in the glAddMember request The GLO indicates the same glName in the glAddMember request
as in glUseKEK.glInfo.glName. Further glAddMember procedures as in glUseKEK.glInfo.glName. Further glAddMember procedures
are covered in section 4.3. are covered in section 4.3.
1.b - The GLO can apply confidentiality to the request by 1.b - The GLO can apply confidentiality to the request by
encapsulating the SignedData.PKIData in an EnvelopedData encapsulating the SignedData.PKIData in an EnvelopedData
(see section 3.2.1.2). (see section 3.2.1.2).
Turner Expires June 2003 30 Turner Expires July 2003 30
And Distribution And Distribution
1.c - The GLO can also optionally apply another SignedData over 1.c - The GLO can also optionally apply another SignedData over
the EnvelopedData (see section 3.2.1.2). the EnvelopedData (see section 3.2.1.2).
2 - Upon receipt of the request, the GLA checks the signingTime 2 - Upon receipt of the request, the GLA checks the signingTime
and verifies the signature on the inner most and verifies the signature on the inner most
SignedData.PKIData. If an additional SignedData and/or SignedData.PKIData. If an additional SignedData and/or
EnvelopedData encapsulates the request (see sections 3.2.1.2 EnvelopedData encapsulates the request (see sections 3.2.1.2
and 3.2.2), the GLA verifies the outer signature(s) and/or and 3.2.2), the GLA verifies the outer signature(s) and/or
skipping to change at line 1604 skipping to change at line 1604
glName and glAddress is not already in use. The GLA also glName and glAddress is not already in use. The GLA also
checks any glAddMember included within the controlSequence checks any glAddMember included within the controlSequence
with this glUseKEK. Further processing of the glAddMember with this glUseKEK. Further processing of the glAddMember
is covered in section 4.3. is covered in section 4.3.
2.d.2.a - If the glName is already in use the GLA returns a 2.d.2.a - If the glName is already in use the GLA returns a
response indicating cMCStatusInfoExt with response indicating cMCStatusInfoExt with
cMCStatus.failed and cMCStatus.failed and
otherInfo.extendedFailInfo.SKDFailInfo value of otherInfo.extendedFailInfo.SKDFailInfo value of
Turner Expires June 2003 31 Turner Expires July 2003 31
And Distribution And Distribution
nameAlreadyInUse. Additionally, a signingTime attribute nameAlreadyInUse. Additionally, a signingTime attribute
is included with the response. is included with the response.
2.d.2.b - Else if the requestedAlgorithm is not supported, the GLA 2.d.2.b - Else if the requestedAlgorithm is not supported, the GLA
returns a response indicating cMCStatusInfoExt with returns a response indicating cMCStatusInfoExt with
cMCStatus.failed and cMCStatus.failed and
otherInfo.extendedFailInfo.SKDFailInfo value of otherInfo.extendedFailInfo.SKDFailInfo value of
unsupportedAlgorithm. Additionally, a signingTime unsupportedAlgorithm. Additionally, a signingTime
skipping to change at line 1659 skipping to change at line 1659
2.d.2.e.2 - The GLA can also optionally apply another SignedData 2.d.2.e.2 - The GLA can also optionally apply another SignedData
over the EnvelopedData (see section 3.2.1.2). over the EnvelopedData (see section 3.2.1.2).
3 - Upon receipt of the cMCStatusInfoExt responses, the GLO checks 3 - Upon receipt of the cMCStatusInfoExt responses, the GLO checks
the signingTime and verifies the GLA signature(s). If an the signingTime and 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 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.
Turner Expires June 2003 32 Turner Expires July 2003 32
And Distribution And Distribution
3.a - If the signingTime attribute value is not within the locally 3.a - If the signingTime attribute value is not within the locally
accepted time window, the GLO MAY return a response accepted time window, the GLO MAY return a response
indicating cMCStatus.failed and otherInfo.failInfo.badTime indicating cMCStatus.failed and otherInfo.failInfo.badTime
and a signingTime attribute. and a signingTime attribute.
3.b - Else if signature processing continues and if the signatures 3.b - Else if signature processing continues and if the signatures
do verify, the GLO MUST check that one of the names in the do verify, the GLO MUST check that one of the names in the
certificate used to sign the response matches the name of certificate used to sign the response matches the name of
skipping to change at line 1713 skipping to change at line 1713
The process is as follows: The process is as follows:
1 - The GLO is responsible for requesting the deletion of the GL. 1 - The GLO is responsible for requesting the deletion of the GL.
The GLO sends a SignedData.PKIData.controlSequence.glDelete The GLO sends a SignedData.PKIData.controlSequence.glDelete
request to the GLA (1 in Figure 4). The name of the GL to be request to the GLA (1 in Figure 4). The name of the GL to be
deleted is included in GeneralName. The GLO MUST also include deleted is included in GeneralName. The GLO MUST also include
the signingTime attribute and can also include a transactionId the signingTime attribute and can also include a transactionId
and senderNonce attributes. and senderNonce attributes.
Turner Expires June 2003 33 Turner Expires July 2003 33
And Distribution And Distribution
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 optionally apply another SignedData over the 1.b - The GLO MAY optionally apply another SignedData over the
EnvelopedData (see section 3.2.1.2). EnvelopedData (see section 3.2.1.2).
2 - Upon receipt of the request the GLA checks the signingTime and 2 - Upon receipt of the request the GLA checks the signingTime and
skipping to change at line 1768 skipping to change at line 1768
2.c.2.a - If the names do not match, the GLA returns a response 2.c.2.a - If the names do not match, the GLA returns a response
indicating cMCStatusInfoExt with cMCStatus.failed and indicating cMCStatusInfoExt with cMCStatus.failed and
otherInfo.extendedFailInfo.SKDFailInfo value of otherInfo.extendedFailInfo.SKDFailInfo value of
noGLONameMatch. Additionally, a signingTime attribute is noGLONameMatch. Additionally, a signingTime attribute is
included with the response. included with the response.
2.c.2.b - Else if the names do match, but the GL cannot be deleted 2.c.2.b - Else if the names do match, but the GL cannot be deleted
for other reasons, which the GLA does not wish to for other reasons, which the GLA does not wish to
disclose, the GLA returns a response indicating disclose, the GLA returns a response indicating
Turner Expires June 2003 34 Turner Expires July 2003 34
And Distribution And Distribution
cMCStatusInfoExt with cMCStatus.failed and cMCStatusInfoExt with cMCStatus.failed and
otherInfo.extendedFailInfo.SKDFailInfo value of otherInfo.extendedFailInfo.SKDFailInfo value of
unspecified. Additionally, a signingTime attribute is unspecified. Additionally, a signingTime attribute is
included with the response. Actions beyond the scope of included with the response. Actions beyond the scope of
this document must then be taken to delete the GL from this document must then be taken to delete the GL from
the GLA. the GLA.
2.c.2.c - Else if the names do match, the GLA returns a 2.c.2.c - Else if the names do match, the GLA returns a
skipping to change at line 1823 skipping to change at line 1823
3.b.2 Else if the name of the GL does match the name present in 3.b.2 Else if the name of the GL does match the name present in
the certificate and: the certificate and:
3.b.2.a - If the signatures verify and the response was 3.b.2.a - If the signatures verify and the response was
cMCStatusInfoExt indicating cMCStatus.success, the GLO cMCStatusInfoExt indicating cMCStatus.success, the GLO
has successfully deleted the GL. has successfully deleted the GL.
3.b.2.b - Else if the signatures do verify and the response was 3.b.2.b - Else if the signatures do verify and the response was
cMCStatusInfoExt.cMCStatus.failed with any reason, the cMCStatusInfoExt.cMCStatus.failed with any reason, the
Turner Expires June 2003 35 Turner Expires July 2003 35
And Distribution And Distribution
GLO can reattempt to delete the GL using the information GLO can reattempt to delete the GL using the information
provided in the response. provided in the response.
4.3 Add Members To GL 4.3 Add Members To GL
To add members to GLs, either the GLO or prospective members use the To add members to GLs, either the GLO or prospective members use the
glAddMember request. The GLA processes GLO and prospective GL member glAddMember request. The GLA processes GLO and prospective GL member
requests differently though. GLOs can submit the request at any time requests differently though. GLOs can submit the request at any time
skipping to change at line 1878 skipping to change at line 1878
An important decision that needs to be made on a group by group An important decision that needs to be made on a group by group
basis is whether to rekey the group every time a new member is basis is whether to rekey the group every time a new member is
added. Typically, unmanaged GLs should not be rekeyed when a new added. Typically, unmanaged GLs should not be rekeyed when a new
member is added, as the overhead associated with rekeying the group member is added, as the overhead associated with rekeying the group
becomes prohibitive, as the group becomes large. However, managed becomes prohibitive, as the group becomes large. However, managed
and closed GLs can be rekeyed to maintain the confidentiality of the and closed GLs can be rekeyed to maintain the confidentiality of the
traffic sent by group members. An option to rekeying managed or traffic sent by group members. An option to rekeying managed or
closed GLs when a member is added is to generate a new GL with a closed GLs when a member is added is to generate a new GL with a
Turner Expires June 2003 36 Turner Expires July 2003 36
And Distribution And Distribution
different group key. Group rekeying is discussed in sections 4.5 and different group key. Group rekeying is discussed in sections 4.5 and
5. 5.
4.3.1 GLO Initiated Additions 4.3.1 GLO Initiated Additions
The process for GLO initiated glAddMember requests is as follows: The process for GLO initiated glAddMember requests is as follows:
1 - The GLO collects the pertinent information for the member(s) 1 - The GLO collects the pertinent information for the member(s)
skipping to change at line 1933 skipping to change at line 1933
2.b - Else if signature processing continues and if the signatures 2.b - Else if signature processing continues and if the signatures
cannot be verified, the GLA returns a cMCStatusInfoExt cannot be verified, the GLA returns a cMCStatusInfoExt
response indicating cMCStatus.failed and response indicating cMCStatus.failed and
otherInfo.failInfo.badMessageCheck. Additionally, a otherInfo.failInfo.badMessageCheck. Additionally, a
signingTime attribute is included with the response. signingTime attribute is included with the response.
2.c - Else if the signatures verify, the glAddMember request is 2.c - Else if the signatures verify, the glAddMember request is
included in a controlSequence with the glUseKEK request, and included in a controlSequence with the glUseKEK request, and
the processing in section 4.1 item 2.e is successfully the processing in section 4.1 item 2.e is successfully
Turner Expires June 2003 37 Turner Expires July 2003 37
And Distribution And Distribution
completed the GLA returns a cMCStatusInfoExt indicating completed the GLA returns a cMCStatusInfoExt indicating
cMCStatus.success and a signingTime attribute (2 in Figure cMCStatus.success and a signingTime attribute (2 in Figure
5). 5).
2.c.1 - The GLA can apply confidentiality to the response by 2.c.1 - The GLA can apply confidentiality to the response by
encapsulating the SignedData.PKIData in an EnvelopedData encapsulating the SignedData.PKIData in an EnvelopedData
if the request was encapsulated in an EnvelopedData (see if the request was encapsulated in an EnvelopedData (see
section 3.2.1.2). section 3.2.1.2).
skipping to change at line 1988 skipping to change at line 1988
2.d.2.b.1.a - If the names do not match, the GLA returns a 2.d.2.b.1.a - If the names do not match, the GLA returns a
response indicating cMCStatusInfoExt with response indicating cMCStatusInfoExt with
cMCStatus.failed and cMCStatus.failed and
otherInfo.extendedFailInfo.SKDFailInfo value of otherInfo.extendedFailInfo.SKDFailInfo value of
noGLONameMatch. Additionally, a signingTime noGLONameMatch. Additionally, a signingTime
attribute is included with the response. attribute is included with the response.
2.d.2.b.1.b - Else if the names match, the GLA verifies the 2.d.2.b.1.b - Else if the names match, the GLA verifies the
member's encryption certificate. member's encryption certificate.
Turner Expires June 2003 38 Turner Expires July 2003 38
And Distribution And Distribution
2.d.2.b.1.b.1 - If the member's encryption certificate cannot be 2.d.2.b.1.b.1 - If the member's encryption certificate cannot be
verified, the GLA can return a response indicating verified, the GLA can return a response indicating
cMCStatusInfoExt with cMCStatus.failed and cMCStatusInfoExt with cMCStatus.failed and
otherInfo.extendedFailInfo.SKDFailInfo value of otherInfo.extendedFailInfo.SKDFailInfo value of
invalidCert to the GLO. Additionally, a invalidCert to the GLO. Additionally, a
signingTime attribute is included with the signingTime attribute is included with the
response. If the GLA does not return a response. If the GLA does not return a
cMCStatusInfoExt.cMCStatus.failed response, the cMCStatusInfoExt.cMCStatus.failed response, the
skipping to change at line 2044 skipping to change at line 2044
included with the response. included with the response.
2.d.2.b.2.b - Else if the signer is a registered GLO, the GLA 2.d.2.b.2.b - Else if the signer is a registered GLO, the GLA
verifies the member's encryption certificate. verifies the member's encryption certificate.
2.d.2.b.2.b.1 - If the member's certificate cannot be verified, 2.d.2.b.2.b.1 - If the member's certificate cannot be verified,
the GLA can return a response indicating the GLA can return a response indicating
cMCStatusInfoExt with cMCStatus.failed and cMCStatusInfoExt with cMCStatus.failed and
otherInfo.extendedFailInfo.SKDFailInfo value of otherInfo.extendedFailInfo.SKDFailInfo value of
Turner Expires June 2003 39 Turner Expires July 2003 39
And Distribution And Distribution
invalidCert. Additionally, a signingTime attribute invalidCert. Additionally, a signingTime attribute
is included with the response. If the GLA does not is included with the response. If the GLA does not
return a cMCStatus.failed response, the GLA MUST return a cMCStatus.failed response, the GLA MUST
issue a glProvideCert request (see section 4.10). issue a glProvideCert request (see section 4.10).
2.d.2.b.2.b.2 - Else if the member's certificate verifies, the GLA 2.d.2.b.2.b.2 - Else if the member's certificate verifies, the GLA
MUST return a cMCStatusInfoExt indicating MUST return a cMCStatusInfoExt indicating
cMCStatus.success and a signingTime attribute to cMCStatus.success and a signingTime attribute to
skipping to change at line 2099 skipping to change at line 2099
SignedData over the EnvelopedData (see section SignedData over the EnvelopedData (see section
3.2.1.2). 3.2.1.2).
2.d.2.b.3 - Else if the GL is unmanaged, the GLA checks that 2.d.2.b.3 - Else if the GL is unmanaged, the GLA checks that
either a registered GLO or the prospective member either a registered GLO or the prospective member
signed the request. For GLOs, one of the names in the signed the request. For GLOs, one of the names in the
certificate used to sign the request needs tp match certificate used to sign the request needs tp match
the name of a registered GLO. For the prospective the name of a registered GLO. For the prospective
member, the name in glMember.glMemberName needs to member, the name in glMember.glMemberName needs to
Turner Expires June 2003 40 Turner Expires July 2003 40
And Distribution And Distribution
match one of the names in the certificate used to sign match one of the names in the certificate used to sign
the request. the request.
2.d.2.b.3.a - If the signer is neither a registered GLO nor the 2.d.2.b.3.a - If the signer is neither a registered GLO nor the
prospective member, the GLA returns a response prospective member, the GLA returns a response
indicating cMCStatusInfoExt with cMCStatus.failed indicating cMCStatusInfoExt with cMCStatus.failed
and otherInfo.extendedFailInfo.SKDFailInfo value of and otherInfo.extendedFailInfo.SKDFailInfo value of
noSpam. Additionally, a signingTime attribute is noSpam. Additionally, a signingTime attribute is
skipping to change at line 2154 skipping to change at line 2154
2.d.2.b.3.b.2.b - The GLA can also optionally apply another 2.d.2.b.3.b.2.b - The GLA can also optionally apply another
SignedData over the EnvelopedData (see section SignedData over the EnvelopedData (see section
3.2.1.2). 3.2.1.2).
3 - Upon receipt of the cMCStatusInfoExt response, the GLO checks 3 - Upon receipt of the cMCStatusInfoExt response, the GLO checks
the signingTime and verifies the GLA signature(s). If an the signingTime and 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 verifies the response (see section 3.2.1.2 or 3.2.2), the GLO verifies the
Turner Expires June 2003 41 Turner Expires July 2003 41
And Distribution And Distribution
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.
3.a - If the signingTime attribute value is not within the locally 3.a - If the signingTime attribute value is not within the locally
accepted time window, the GLO MAY return a response accepted time window, the GLO MAY return a response
indicating cMCStatus.failed and otherInfo.failInfo.badTime indicating cMCStatus.failed and otherInfo.failInfo.badTime
and a signingTime attribute. and a signingTime attribute.
skipping to change at line 2208 skipping to change at line 2208
4.a - If the signingTime attribute value is not within the locally 4.a - If the signingTime attribute value is not within the locally
accepted time window, the prospective member MAY return a accepted time window, the prospective member MAY return a
response indicating cMCStatus.failed and response indicating cMCStatus.failed and
otherInfo.failInfo.badTime and a signingTime attribute. otherInfo.failInfo.badTime and a signingTime attribute.
4.b - Else if signature processing continues and if the signatures 4.b - Else if signature processing continues and if the signatures
verify, the GL member checks that one of the names in the verify, the GL member checks that one of the names in the
certificate used to sign the response matches the name of certificate used to sign the response matches the name of
the GL. the GL.
Turner Expires June 2003 42 Turner Expires July 2003 42
And Distribution And Distribution
4.b.1 - If the name of the GL does not match the name present in 4.b.1 - If the name of the GL does not match the name present in
the certificate used to sign the message, the GL member the certificate used to sign the message, the GL member
should not believe the response. should not believe the response.
4.b.2 Else if the name of the GL matches the name present in the 4.b.2 Else if the name of the GL matches the name present in the
certificate and: certificate and:
4.b.2.a - If the signatures verify, the prospective member has 4.b.2.a - If the signatures verify, the prospective member has
skipping to change at line 2263 skipping to change at line 2263
per 2 in section 4.3.1. per 2 in section 4.3.1.
3 - Upon receipt of the forwarded request, the GLO checks the 3 - Upon receipt of the forwarded request, the GLO checks the
signingTime and verifies the prospective GL member signature signingTime and verifies the prospective GL member signature
on the inner most SignedData.PKIData and the GLA signature on on the inner most SignedData.PKIData and the GLA signature on
the outer layer. If an EnvelopedData encapsulates the inner the outer layer. If an EnvelopedData encapsulates the inner
most layer (see section 3.2.1.2 or 3.2.2), the GLO decrypts most layer (see section 3.2.1.2 or 3.2.2), the GLO decrypts
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 Expires June 2003 43 Turner Expires July 2003 43
And Distribution And Distribution
Note: For cases where the GL is closed and either a) a Note: For cases where the GL is closed and either a) a
prospective member sends directly to the GLO or b) the GLA has prospective member sends directly to the GLO or b) the GLA has
mistakenly forwarded the request to the GLO, the GLO should mistakenly forwarded the request to the GLO, the GLO should
first determine whether to honor the request. first determine whether to honor the request.
3.a - If the signingTime attribute value is not within the locally 3.a - If the signingTime attribute value is not within the locally
accepted time window, the GLO MAY return a response accepted time window, the GLO MAY return a response
indicating cMCStatus.failed and otherInfo.failInfo.badTime. indicating cMCStatus.failed and otherInfo.failInfo.badTime.
skipping to change at line 2318 skipping to change at line 2318
GLO returns a SignedData.PKIResponse.controlSequence GLO returns a SignedData.PKIResponse.controlSequence
back to the prospective member with back to the prospective member with
cMCStatusInfoExt.cMCtatus.failed indicating that the cMCStatusInfoExt.cMCtatus.failed indicating that the
member's encryption certificate did not verify in member's encryption certificate did not verify in
cMCStatus.statusString. Additionally, a signingTime cMCStatus.statusString. Additionally, a signingTime
attribute is included with the response. If the GLO attribute is included with the response. If the GLO
does not return a cMCStatusInfoExt response, the GLO does not return a cMCStatusInfoExt response, the GLO
sends a sends a
SignedData.PKIData.controlSequence.glProvideCert SignedData.PKIData.controlSequence.glProvideCert
Turner Expires June 2003 44 Turner Expires July 2003 44
And Distribution And Distribution
message to the prospective member requesting a new message to the prospective member requesting a new
encryption certificate (see section 4.10). encryption certificate (see section 4.10).
3.b.2.b.2 - Else if the member's certificate verifies, the GLO 3.b.2.b.2 - Else if the member's certificate verifies, the GLO
resubmits the glAddMember request (see section 3.2.5) resubmits the glAddMember request (see section 3.2.5)
to the GLA (1 in Figure 5). to the GLA (1 in Figure 5).
3.b.2.b.2.a - The GLO applies confidentiality to the new 3.b.2.b.2.a - The GLO applies confidentiality to the new
skipping to change at line 2365 skipping to change at line 2365
the GLA. In the closed case, the GLA will not accept requests from the GLA. In the closed case, the GLA will not accept requests from
members. The following sections describe the processing for the members. The following sections describe the processing for the
GLO(s), GLA, and GL members depending on where the request GLO(s), GLA, and GL members depending on where the request
originated, either from a GLO or from members wanting to be removed. originated, either from a GLO or from members wanting to be removed.
Figure 6 depicts the protocol interactions for the three options. Figure 6 depicts the protocol interactions for the three options.
Note that the error messages are not depicted. Additionally, Note that the error messages are not depicted. Additionally,
behavior for the optional transactionId, senderNonce, and behavior for the optional transactionId, senderNonce, and
recipientNonce CMC control attributes is not addressed in these recipientNonce CMC control attributes is not addressed in these
procedures. procedures.
Turner Expires June 2003 45 Turner Expires July 2003 45
And Distribution And Distribution
+-----+ 2,B{A} 3 +----------+ +-----+ 2,B{A} 3 +----------+
| GLO | <--------+ +-------> | Member 1 | | GLO | <--------+ +-------> | Member 1 |
+-----+ | | +----------+ +-----+ | | +----------+
1 | | 1 | |
+-----+ <--------+ | 3 +----------+ +-----+ <--------+ | 3 +----------+
| GLA | A +-------> | ... | | GLA | A +-------> | ... |
+-----+ <-------------+ +----------+ +-----+ <-------------+ +----------+
| |
skipping to change at line 2418 skipping to change at line 2418
glDeletemember request (see section 4.5). The GLO MUST also glDeletemember request (see section 4.5). The GLO MUST also
include the signingTime attribute with this request. include the signingTime attribute with this request.
1.a - The GLO can optionally apply confidentiality to the request 1.a - The GLO can optionally apply confidentiality to the request
by encapsulating the SignedData.PKIData in an EnvelopedData by encapsulating the SignedData.PKIData in an EnvelopedData
(see section 3.2.1.2). (see section 3.2.1.2).
1.b - The GLO can also optionally apply another SignedData over 1.b - The GLO can also optionally apply another SignedData over
the EnvelopedData (see section 3.2.1.2). the EnvelopedData (see section 3.2.1.2).
Turner Expires June 2003 46 Turner Expires July 2003 46
And Distribution And Distribution
2 - Upon receipt of the request, the GLA checks the signingTime 2 - Upon receipt of the request, the GLA checks the signingTime
attribute and verifies the signature on the inner most attribute and verifies the signature on the inner most
SignedData.PKIData. If an additional SignedData and/or SignedData.PKIData. 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.
skipping to change at line 2474 skipping to change at line 2474
2.c.2.b.1 - If the GL is closed, the GLA checks that the 2.c.2.b.1 - If the GL is closed, the GLA checks that the
registered GLO signed the request by checking that one registered GLO signed the request by checking that one
of the names in the digital signature certificate used of the names in the digital signature certificate used
to sign the request matches the registered GLO. to sign the request matches the registered GLO.
2.c.2.b.1.a - If the names do not match, the GLA returns a 2.c.2.b.1.a - If the names do not match, the GLA returns a
response indicating cMCStatusInfoExt with response indicating cMCStatusInfoExt with
cMCStatus.failed and cMCStatus.failed and
otherInfo.extendedFailInfo.SKDFailInfo value of otherInfo.extendedFailInfo.SKDFailInfo value of
Turner Expires June 2003 47 Turner Expires July 2003 47
And Distribution And Distribution
closedGL. Additionally, a signingTime attribute is closedGL. Additionally, a signingTime attribute is
included with the response. included with the response.
2.c.2.b.1.b - Else if the names do match, the GLA returns a 2.c.2.b.1.b - Else if the names do match, the GLA returns a
cMCStatusInfoExt.cMCStatus.success and a signingTime cMCStatusInfoExt.cMCStatus.success and a signingTime
attribute (2 in Figure 5). The GLA also takes attribute (2 in Figure 5). The GLA also takes
administrative actions, which are beyond the scope administrative actions, which are beyond the scope
of this document, to delete the member with the GL of this document, to delete the member with the GL
skipping to change at line 2529 skipping to change at line 2529
2.c.2.b.2.b.1 - The GLA applies confidentiality to the response by 2.c.2.b.2.b.1 - The GLA applies confidentiality to the response by
encapsulating the SignedData.PKIData in an encapsulating the SignedData.PKIData in an
EnvelopedData if the request was encapsulated in EnvelopedData if the request was encapsulated in
an EnvelopedData (see section 3.2.1.2). an EnvelopedData (see section 3.2.1.2).
2.c.2.b.2.b.2 - The GLA can also optionally apply another 2.c.2.b.2.b.2 - The GLA can also optionally apply another
SignedData over the EnvelopedData (see section SignedData over the EnvelopedData (see section
3.2.1.2). 3.2.1.2).
Turner Expires June 2003 48 Turner Expires July 2003 48
And Distribution And Distribution
2.c.2.b.2.c - Else if the signer is the prospective member, the 2.c.2.b.2.c - Else if the signer is the prospective member, the
GLA forwards the glDeleteMember request (see section GLA forwards the glDeleteMember request (see section
3.2.3) to the GLO (B{A} in Figure 6). If there is 3.2.3) to the GLO (B{A} in Figure 6). If there is
more than one registered GLO, the GLO to which the more than one registered GLO, the GLO to which the
request is forwarded to is beyond the scope of this request is forwarded to is beyond the scope of this
document. Further processing of the forwarded document. Further processing of the forwarded
request by GLOs is addressed in 3 of section 4.4.2. request by GLOs is addressed in 3 of section 4.4.2.
skipping to change at line 2584 skipping to change at line 2584
2.c.2.b.3.b.1 - The GLA applies confidentiality to the response by 2.c.2.b.3.b.1 - The GLA applies confidentiality to the response by
encapsulating the SignedData.PKIData in an encapsulating the SignedData.PKIData in an
EnvelopedData if the request was encapsulated in EnvelopedData if the request was encapsulated in
an EnvelopedData (see section 3.2.1.2). an EnvelopedData (see section 3.2.1.2).
2.c.2.b.3.b.2 - The GLA can also optionally apply another 2.c.2.b.3.b.2 - The GLA can also optionally apply another
SignedData over the EnvelopedData (see section SignedData over the EnvelopedData (see section
3.2.1.2). 3.2.1.2).
Turner Expires June 2003 49 Turner Expires July 2003 49
And Distribution And Distribution
3 - Upon receipt of the cMCStatusInfoExt response, the GLO checks 3 - Upon receipt of the cMCStatusInfoExt response, the GLO checks
the signingTime and verifies the GLA signatures. If an the signingTime and verifies the GLA signatures. 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 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.
3.a - If the signingTime attribute value is not within the locally 3.a - If the signingTime attribute value is not within the locally
skipping to change at line 2640 skipping to change at line 2640
most SignedData. most SignedData.
4.b - If the signingTime attribute value is not within the locally 4.b - If the signingTime attribute value is not within the locally
accepted time window, the prospective member MAY return a accepted time window, the prospective member MAY return a
response indicating cMCStatus.failed and response indicating cMCStatus.failed and
otherInfo.failInfo.badTime and a signingTime attribute. otherInfo.failInfo.badTime and a signingTime attribute.
4.b - Else if signature processing continues and if the signatures 4.b - Else if signature processing continues and if the signatures
verify, the GL member checks that one of the names in the verify, the GL member checks that one of the names in the
Turner Expires June 2003 50 Turner Expires July 2003 50
And Distribution And Distribution
certificate used to sign the response matches the name of certificate used to sign the response matches the name of
the GL. the GL.
4.b.1 If the name of the GL does not match the name present in 4.b.1 If the name of the GL does not match the name present in
the certificate used to sign the message, the GL member the certificate used to sign the message, the GL member
should not believe the response. should not believe the response.
4.b.2 Else if the name of the GL matches the name present in the 4.b.2 Else if the name of the GL matches the name present in the
skipping to change at line 2694 skipping to change at line 2694
signingTime and verifies the member signature on the inner signingTime and verifies the member signature on the inner
most SignedData.PKIData and the GLA signature on the outer most SignedData.PKIData and the GLA signature on the outer
layer. If an EnvelopedData encapsulates the inner most layer layer. If an EnvelopedData encapsulates the inner most layer
(see section 3.2.1.2 or 3.2.2), the GLO decrypts the outer (see section 3.2.1.2 or 3.2.2), the GLO decrypts the outer
layer prior to verifying the signature on the inner most layer prior to verifying the signature on the inner most
SignedData. SignedData.
Note: For cases where the GL is closed and either (a) a Note: For cases where the GL is closed and either (a) a
prospective member sends directly to the GLO or (b) the GLA prospective member sends directly to the GLO or (b) the GLA
Turner Expires June 2003 51 Turner Expires July 2003 51
And Distribution And Distribution
has mistakenly forwarded the request to the GLO, the GLO has mistakenly forwarded the request to the GLO, the GLO
should first determine whether to honor the request. should first determine whether to honor the request.
3.a - If the signingTime attribute value is not within the locally 3.a - If the signingTime attribute value is not within the locally
accepted time window, the GLO MAY return a response accepted time window, the GLO MAY return a response
indicating cMCStatus.failed and otherInfo.failInfo.badTime indicating cMCStatus.failed and otherInfo.failInfo.badTime
and a signingTime attribute. and a signingTime attribute.
skipping to change at line 2742 skipping to change at line 2742
GLDeleteMember request by encapsulating the GLDeleteMember request by encapsulating the
SignedData.PKIData in an EnvelopedData if the initial SignedData.PKIData in an EnvelopedData if the initial
request was encapsulated in an EnvelopedData (see request was encapsulated in an EnvelopedData (see
section 3.2.1.2). section 3.2.1.2).
3.c.2.b - The GLO can also optionally apply another SignedData 3.c.2.b - The GLO can also optionally apply another SignedData
over the EnvelopedData (see section 3.2.1.2). over the EnvelopedData (see section 3.2.1.2).
4 - Further processing is as in 2 of section 4.4.1. 4 - Further processing is as in 2 of section 4.4.1.
Turner Expires June 2003 52 Turner Expires July 2003 52
And Distribution And Distribution
4.5 Request Rekey Of GL 4.5 Request Rekey Of GL
From time to time, the GL will need to be rekeyed. Some situations From time to time, the GL will need to be rekeyed. Some situations
follow: follow:
- When a member is removed from a closed or managed GL. In this - When a member is removed from a closed or managed GL. In this
case, the PKIData.controlSequence containing the glDeleteMember case, the PKIData.controlSequence containing the glDeleteMember
ought to contain a glRekey request. ought to contain a glRekey request.
skipping to change at line 2797 skipping to change at line 2797
covered in section 5. Figure 7 depicts the protocol interactions to covered in section 5. Figure 7 depicts the protocol interactions to
request a GL rekey. Note that error messages are not depicted. request a GL rekey. Note that error messages are not depicted.
Additionally, behavior for the optional transactionId, senderNonce, Additionally, behavior for the optional transactionId, senderNonce,
and recipientNonce CMC control attributes is not addressed in these and recipientNonce CMC control attributes is not addressed in these
procedures. procedures.
+-----+ 1 2,A +-----+ +-----+ 1 2,A +-----+
| GLA | <-------> | GLO | | GLA | <-------> | GLO |
+-----+ +-----+ +-----+ +-----+
Turner Expires June 2003 53 Turner Expires July 2003 53
And Distribution And Distribution
Figure 7 - GL Rekey Request Figure 7 - GL Rekey Request
4.5.1 GLO Initiated Rekey Requests 4.5.1 GLO Initiated Rekey Requests
The process for GLO initiated glRekey requests is as follows: The process for GLO initiated glRekey requests is as follows:
1 - The GLO sends a SignedData.PKIData.controlSequence.glRekey 1 - The GLO sends a SignedData.PKIData.controlSequence.glRekey
request to the GLA (1 in Figure 7). The GLO includes the request to the GLA (1 in Figure 7). The GLO includes the
skipping to change at line 2852 skipping to change at line 2852
is supported by the GLA by checking that the glName matches is supported by the GLA by checking that the glName matches
a glName stored on the GLA. a glName stored on the GLA.
2.c.1 - If the glName present does not match a GL stored on the 2.c.1 - If the glName present does not match a GL stored on the
GLA, the GLA returns a response indicating GLA, the GLA returns a response indicating
cMCStatusInfoExt with cMCStatus.failed and cMCStatusInfoExt with cMCStatus.failed and
otherInfo.extendedFailInfo.SKDFailInfo value of otherInfo.extendedFailInfo.SKDFailInfo value of
invalidGLName. Additionally, a signingTime attribute is invalidGLName. Additionally, a signingTime attribute is
included with the response. included with the response.
Turner Expires June 2003 54 Turner Expires July 2003 54
And Distribution And Distribution
2.c.2 - Else if the glName present matches a GL stored on the GLA, 2.c.2 - Else if the glName present matches a GL stored on the GLA,
the GLA checks that a registered GLO signed the request by the GLA checks that a registered GLO signed the request by
checking that one of the names in the certificate used to checking that one of the names in the certificate used to
sign the request is a registered GLO. sign the request is a registered GLO.
2.c.2.a - If the names do not match, the GLA returns a response 2.c.2.a - If the names do not match, the GLA returns a response
indicating cMCStatusInfoExt with cMCStatus.failed and indicating cMCStatusInfoExt with cMCStatus.failed and
otherInfo.extendedFailInfo.SKDFailInfo value of otherInfo.extendedFailInfo.SKDFailInfo value of
skipping to change at line 2907 skipping to change at line 2907
KEK (see section 5). KEK (see section 5).
2.c.2.b.4.a - The GLA applies confidentiality to response by 2.c.2.b.4.a - The GLA applies confidentiality to response by
encapsulating the SignedData.PKIData in an encapsulating the SignedData.PKIData in an
EnvelopedData if the request was encapsulated in an EnvelopedData if the request was encapsulated in an
EnvelopedData (see section 3.2.1.2). EnvelopedData (see section 3.2.1.2).
2.c.2.b.4.b - The GLA can also optionally apply another SignedData 2.c.2.b.4.b - The GLA can also optionally apply another SignedData
over the EnvelopedData (see section 3.2.1.2). over the EnvelopedData (see section 3.2.1.2).
Turner Expires June 2003 55 Turner Expires July 2003 55
And Distribution And Distribution
3 - Upon receipt of the cMCStatusInfoExt response, the GLO checks 3 - Upon receipt of the cMCStatusInfoExt response, the GLO checks
the signingTime and verifies the GLA signature(s). If an the signingTime and verifies the GLA signature(s). If an
additional SignedData and/or EnvelopedData encapsulates the additional SignedData and/or EnvelopedData encapsulates the
forwarded response (see section 3.2.1.2 or 3.2.2), the GLO forwarded response (see section 3.2.1.2 or 3.2.2), the GLO
verifies the outer signature and/or decrypt the forwarded verifies the outer signature and/or decrypt the forwarded
response prior to verifying the signature on the inner most response prior to verifying the signature on the inner most
SignedData. SignedData.
skipping to change at line 2960 skipping to change at line 2960
is as follows: is as follows:
1 - The GLA generates for all GLOs a 1 - The GLA generates for all GLOs a
SignedData.PKIData.controlSequence.cMCStatusInfoExt.cMCStatus. SignedData.PKIData.controlSequence.cMCStatusInfoExt.cMCStatus.
success and includes a signingTime attribute (A in Figure 7). success and includes a signingTime attribute (A in Figure 7).
1.a - The GLA can optionally apply confidentiality to the request 1.a - The GLA can optionally apply confidentiality to the request
by encapsulating the SignedData.PKIData in an EnvelopedData by encapsulating the SignedData.PKIData in an EnvelopedData
(see section 3.2.1.2). (see section 3.2.1.2).
Turner Expires June 2003 56 Turner Expires July 2003 56
And Distribution And Distribution
1.b - The GLA can also optionally apply another SignedData over 1.b - The GLA can also optionally apply another SignedData over
the EnvelopedData (see section 3.2.1.2). the EnvelopedData (see section 3.2.1.2).
2 - Upon receipt of the cMCStatusInfoExt.cMCStatus.success 2 - Upon receipt of the cMCStatusInfoExt.cMCStatus.success
response, the GLO checks the signingTime and verifies the GLA response, the GLO checks the signingTime and verifies the GLA
signature(s). If an additional SignedData and/or EnvelopedData signature(s). If an additional SignedData and/or EnvelopedData
encapsulates the forwarded response (see section 3.2.1.2 or encapsulates the forwarded response (see section 3.2.1.2 or
3.2.2), the GLO MUST verify the outer signature and/or decrypt 3.2.2), the GLO MUST verify the outer signature and/or decrypt
skipping to change at line 3012 skipping to change at line 3012
Additionally, behavior for the optional transactionId, senderNonce, Additionally, behavior for the optional transactionId, senderNonce,
and recipientNonce CMC control attributes is not addressed in these and recipientNonce CMC control attributes is not addressed in these
procedures. procedures.
+-----+ 1 2 +-----+ +-----+ 1 2 +-----+
| GLA | <-------> | GLO | | GLA | <-------> | GLO |
+-----+ +-----+ +-----+ +-----+
Figure 8 - GLO Add & Delete Owners Figure 8 - GLO Add & Delete Owners
Turner Expires June 2003 57 Turner Expires July 2003 57
And Distribution And Distribution
The process for glAddOwner and glDeleteOwner is as follows: The process for glAddOwner and glDeleteOwner is as follows:
1 - The GLO sends a SignedData.PKIData.controlSequence.glAddOwner 1 - The GLO sends a SignedData.PKIData.controlSequence.glAddOwner
or glRemoveOwner request to the GLA (1 in Figure 8). The GLO or glRemoveOwner request to the GLA (1 in Figure 8). The GLO
includes: the GL name in glName, the name and address of the includes: the GL name in glName, the name and address of the
GLO in glOwnerName and glOwnerAddress, respectively. The GLO GLO in glOwnerName and glOwnerAddress, respectively. The GLO
MUST also include the signingTime attribute with this request. MUST also include the signingTime attribute with this request.
skipping to change at line 3066 skipping to change at line 3066
invalidGLName. Additionally, a signingTime attribute is invalidGLName. Additionally, a signingTime attribute is
included with the response. included with the response.
2.c.2 - Else if the glName is supported by the GLA, the GLA 2.c.2 - Else if the glName is supported by the GLA, the GLA
ensures a registered GLO signed the glAddOwner or ensures a registered GLO signed the glAddOwner or
glRemoveOwner request by checking that one of the names glRemoveOwner request by checking that one of the names
present in the digital signature certificate used to sign present in the digital signature certificate used to sign
the glAddOwner or glDeleteOwner request matches the name the glAddOwner or glDeleteOwner request matches the name
of a registered GLO. of a registered GLO.
Turner Expires June 2003 58 Turner Expires July 2003 58
And Distribution And Distribution
2.c.2.a - If the names do not match, the GLA returns a response 2.c.2.a - If the names do not match, the GLA returns a response
indicating cMCStatusInfoExt with cMCStatus.failed and indicating cMCStatusInfoExt with cMCStatus.failed and
otherInfo.extendedFailInfo.SKDFailInfo value of otherInfo.extendedFailInfo.SKDFailInfo value of
noGLONameMatch. Additionally, a signingTime attribute is noGLONameMatch. Additionally, a signingTime attribute is
included with the response. included with the response.
2.c.2.b - Else if the names match, the GLA returns a 2.c.2.b - Else if the names match, the GLA returns a
cMCStatusInfoExt.cMCStatus.success and a signingTime cMCStatusInfoExt.cMCStatus.success and a signingTime
skipping to change at line 3122 skipping to change at line 3122
3.b.2 Else if the name of the GL does match the name present in 3.b.2 Else if the name of the GL does match the name present in
the certificate and: the certificate and:
3.b.2.a - If the signatures verify and the response was 3.b.2.a - If the signatures verify and the response was
cMCStatusInfoExt.cMCStatus.success, the GLO has cMCStatusInfoExt.cMCStatus.success, the GLO has
successfully added or removed the GLO. successfully added or removed the GLO.
3.b.2.b - Else if the signatures verify and the response was 3.b.2.b - Else if the signatures verify and the response was
cMCStatusInfoExt.cMCStatus.failed with any reason, the cMCStatusInfoExt.cMCStatus.failed with any reason, the
Turner Expires June 2003 59 Turner Expires July 2003 59
And Distribution And Distribution
GLO can reattempt to add or delete the GLO using the GLO can reattempt to add or delete the GLO using the
information provided in the response. information provided in the response.
4.7 Indicate KEK Compromise 4.7 Indicate KEK Compromise
There will be times when the shared KEK is compromised. GL members There will be times when the shared KEK is compromised. GL members
and GLOs use glkCompromise to tell the GLA that the shared KEK has and GLOs use glkCompromise to tell the GLA that the shared KEK has
been compromised. Figure 9 depicts the protocol interactions for GL been compromised. Figure 9 depicts the protocol interactions for GL
skipping to change at line 3177 skipping to change at line 3177
1.b - The GL member can also optionally apply another SignedData 1.b - The GL member can also optionally apply another SignedData
over the EnvelopedData (see section 3.2.1.2). over the EnvelopedData (see section 3.2.1.2).
2 - Upon receipt of the glkCompromise request, the GLA checks the 2 - Upon receipt of the glkCompromise request, the GLA checks the
signingTime and verifies the GL member signature(s). If an signingTime and verifies the GL member signature(s). If an
additional SignedData and/or EnvelopedData encapsulates the additional SignedData and/or EnvelopedData encapsulates the
request (see section 3.2.1.2 or 3.2.2), the GLA verifies the request (see section 3.2.1.2 or 3.2.2), the GLA verifies the
outer signature and/or decrypt the outer layer prior to 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.
Turner Expires June 2003 60 Turner Expires July 2003 60
And Distribution And Distribution
2.a - If the signingTime attribute value is not within the locally 2.a - If the signingTime attribute value is not within the locally
accepted time window, the GLA MAY return a response accepted time window, the GLA MAY return a response
indicating cMCStatus.failed and otherInfo.failInfo.badTime indicating cMCStatus.failed and otherInfo.failInfo.badTime
and a signingTime attribute. and a signingTime attribute.
2.b - Else if signature processing continues and if the signatures 2.b - Else if signature processing continues and if the signatures
cannotbe verified, the GLA returns a cMCStatusInfoExt cannotbe verified, the GLA returns a cMCStatusInfoExt
response indicating cMCStatus.failed and response indicating cMCStatus.failed and
skipping to change at line 3230 skipping to change at line 3230
4.7.2 GLO Initiated KEK Compromise Message 4.7.2 GLO Initiated KEK Compromise Message
The process for GLO initiated glkCompromise messages is as follows: The process for GLO initiated glkCompromise messages is as follows:
1 - The GLO either: 1 - The GLO either:
1.a - Generates the glkCompromise message itself by sending a 1.a - Generates the glkCompromise message itself by sending a
SignedData.PKIData.controlSequence.glkCompromise request to SignedData.PKIData.controlSequence.glkCompromise request to
the GLA (5 in Figure 9). The GLO includes the name of the GL the GLA (5 in Figure 9). The GLO includes the name of the GL
Turner Expires June 2003 61 Turner Expires July 2003 61
And Distribution And Distribution
in GeneralName. The GLO MUST also include a signingTime in GeneralName. The GLO MUST also include a signingTime
attribute with this request. attribute with this request.
1.a.1 - The GLO can optionally apply confidentiality to the 1.a.1 - The GLO can optionally apply confidentiality to the
request by encapsulating the SignedData.PKIData in an request by encapsulating the SignedData.PKIData in an
EnvelopedData (see section 3.2.1.2). The glkCompromise can EnvelopedData (see section 3.2.1.2). The glkCompromise can
be included in an EnvelopedData generated with the be included in an EnvelopedData generated with the
compromised shared KEK. compromised shared KEK.
skipping to change at line 3282 skipping to change at line 3282
1.b.2.a.2 Else if the names match and the signatures verify, the 1.b.2.a.2 Else if the names match and the signatures verify, the
GLO determines whether to forward the glkCompromise GLO determines whether to forward the glkCompromise
message back to the GLA (3{1} in Figure 9). Further message back to the GLA (3{1} in Figure 9). Further
processing by the GLA is in 2 of section 4.7.1. The processing by the GLA is in 2 of section 4.7.1. The
GLO can also return a response to the prospective GLO can also return a response to the prospective
member with cMCStatusInfoExt.cMCtatus.success member with cMCStatusInfoExt.cMCtatus.success
indicating that the glkCompromise message was indicating that the glkCompromise message was
successfully received. successfully received.
Turner Expires June 2003 62 Turner Expires July 2003 62
And Distribution And Distribution
4.8 Request KEK Refresh 4.8 Request KEK Refresh
There will be times when GL members have unrecoverably lost their There will be times when GL members have unrecoverably lost their
shared KEK. The shared KEK is not compromised and a rekey of the shared KEK. The shared KEK is not compromised and a rekey of the
entire GL is not necessary. GL members use the glkRefresh message to entire GL is not necessary. GL members use the glkRefresh message to
request that the shared KEK(s) be redistributed to them. Figure 10 request that the shared KEK(s) be redistributed to them. Figure 10
depicts the protocol interactions for GL Key Refresh. Note that depicts the protocol interactions for GL Key Refresh. Note that
error messages are not shown. Additionally, behavior for the error messages are not shown. Additionally, behavior for the
skipping to change at line 3335 skipping to change at line 3335
accepted time window, the GLA MAY return a response accepted time window, the GLA MAY return a response
indicating cMCStatus.failed and otherInfo.failInfo.badTime indicating cMCStatus.failed and otherInfo.failInfo.badTime
and a signingTime attribute. and a signingTime attribute.
2.b - Else if signature processing continues and if the signatures 2.b - Else if signature processing continues and if the signatures
cannot be verified, the GLA returns a cMCStatusInfoExt cannot be verified, the GLA returns a cMCStatusInfoExt
response indicating cMCStatus.failed and response indicating cMCStatus.failed and
otherInfo.failInfo.badMessageCheck. Additionally, a otherInfo.failInfo.badMessageCheck. Additionally, a
signingTime attribute is included with the response. signingTime attribute is included with the response.
Turner Expires June 2003 63 Turner Expires July 2003 63
And Distribution And Distribution
2.c - Else if the signatures verify, the GLA makes sure the GL is 2.c - Else if the signatures verify, the GLA makes sure the GL is
supported by checking that the GLGeneralName matches a supported by checking that the GLGeneralName matches a
glName stored on the GLA. glName stored on the GLA.
2.c.1 - If the name of the GL is not supported by the GLA, the GLA 2.c.1 - If the name of the GL is not supported by the GLA, the GLA
returns a response indicating cMCStatusInfoExt with returns a response indicating cMCStatusInfoExt with
cMCStatus.failed and cMCStatus.failed and
otherInfo.extendedFailInfo.SKDFailInfo value of otherInfo.extendedFailInfo.SKDFailInfo value of
skipping to change at line 3389 skipping to change at line 3389
| GLA | <-------> | GLO or GL Member | | GLA | <-------> | GLO or GL Member |
+-----+ +------------------+ +-----+ +------------------+
Figure 11 - GLA Query Request & Response Figure 11 - GLA Query Request & Response
The process for glaQueryRequest and glaQueryResponse is as follows: The process for glaQueryRequest and glaQueryResponse is as follows:
1 - The GLO, GL member, or prospective GL member sends a 1 - The GLO, GL member, or prospective GL member sends a
SignedData.PKIData.controlSequence.glaQueryRequest request to SignedData.PKIData.controlSequence.glaQueryRequest request to
Turner Expires June 2003 64 Turner Expires July 2003 64
And Distribution And Distribution
the GLA (1 in Figure 11). The GLO, GL member, or prospective the GLA (1 in Figure 11). The GLO, GL member, or prospective
GL member indicates the information they are interested in GL member indicates the information they are interested in
receiving from the GLA. Additionally, a signingTime attribute receiving from the GLA. Additionally, a signingTime attribute
is included with this request. is included with this request.
1.a - The GLO, GL member, or prospective GL member can optionally 1.a - The GLO, GL member, or prospective GL member can optionally
apply confidentiality to the request by encapsulating the apply confidentiality to the request by encapsulating the
SignedData.PKIData in an EnvelopedData (see section SignedData.PKIData in an EnvelopedData (see section
skipping to change at line 3445 skipping to change at line 3445
response if the glaRequestType is supported or return a response if the glaRequestType is supported or return a
cMCStatusInfoExt response indicating cMCStatus.noSupport cMCStatusInfoExt response indicating cMCStatus.noSupport
if the glaRequestType is not supported. Additionally, a if the glaRequestType is not supported. Additionally, a
signingTime attribute is included with the response. signingTime attribute is included with the response.
2.b.3.a - The GLA applies confidentiality to the response by 2.b.3.a - The GLA applies confidentiality to the response by
encapsulating the SignedData.PKIResponse in an encapsulating the SignedData.PKIResponse in an
EnvelopedData if the request was encapsulated in an EnvelopedData if the request was encapsulated in an
EnvelopedData (see section 3.2.1.2). EnvelopedData (see section 3.2.1.2).
Turner Expires June 2003 65 Turner Expires July 2003 65
And Distribution And Distribution
2.b.3.b - The GLA can also optionally apply another SignedData 2.b.3.b - The GLA can also optionally apply another SignedData
over the EnvelopedData (see section 3.2.1.2). over the EnvelopedData (see section 3.2.1.2).
3 - Upon receipt of the glaQueryResponse, the GLO, GL member, or 3 - Upon receipt of the glaQueryResponse, the GLO, GL member, or
prospective GL member checks the signingTime and verifies the prospective GL member checks the signingTime and verifies the
GLA signature(s). If an additional SignedData and/or 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
or 3.2.2), the GLO, GL member, or prospective GL member or 3.2.2), the GLO, GL member, or prospective GL member
skipping to change at line 3499 skipping to change at line 3499
be instances when GL member's certificate has expired or is invalid. be instances when GL member's certificate has expired or is invalid.
In these instances the GLO or GLA may request that the GL member In these instances the GLO or GLA may request that the GL member
provide a new certificate to avoid the GLA from being unable to provide a new certificate to avoid the GLA from being unable to
generate a glKey message for the GL member. There might also be generate a glKey message for the GL member. There might also be
times when the GL member knows their certificate is about to expire times when the GL member knows their certificate is about to expire
or has been revoked and they will not be able to receive GL rekeys. or has been revoked and they will not be able to receive GL rekeys.
Behavior for the optional transactionId, senderNonce, and Behavior for the optional transactionId, senderNonce, and
recipientNonce CMC control attributes is not addressed in these recipientNonce CMC control attributes is not addressed in these
procedures. procedures.
Turner Expires June 2003 66 Turner Expires July 2003 66
And Distribution And Distribution
4.10.1 GLO and GLA Initiated Update Member Certificate 4.10.1 GLO and GLA Initiated Update Member Certificate
The process for GLO initiated glUpdateCert is as follows: The process for GLO initiated glUpdateCert is as follows:
1 - The GLO or GLA sends a 1 - The GLO or GLA sends a
SignedData.PKIData.controlSequence.glProvideCert request to SignedData.PKIData.controlSequence.glProvideCert request to
the GL member. The GLO or GLA indicates the GL name in glName the GL member. The GLO or GLA indicates the GL name in glName
and the GL member name in glMemberName. Additionally, a and the GL member name in glMemberName. Additionally, a
skipping to change at line 3553 skipping to change at line 3553
includes the GL name in glName, the member name in includes the GL name in glName, the member name in
glMember.glMemberName, their encryption certificate in glMember.glMemberName, their encryption certificate in
glMember.certificates.pKC. The GL member can also include glMember.certificates.pKC. The GL member can also include
any attribute certificates associated with their encryption any attribute certificates associated with their encryption
certificate in glMember.certificates.aC, and the certificate in glMember.certificates.aC, and the
certification path associated with their encryption and certification path associated with their encryption and
attribute certificates in glMember.certificates.certPath. attribute certificates in glMember.certificates.certPath.
Additionally, a signingTime attribute is included with the Additionally, a signingTime attribute is included with the
response. response.
Turner Expires June 2003 67 Turner Expires July 2003 67
And Distribution And Distribution
2.c.1 - The GL member can optionally apply confidentiality to the 2.c.1 - The GL member can optionally apply confidentiality to the
request by encapsulating the SignedData.PKIResponse in an request by encapsulating the SignedData.PKIResponse in an
EnvelopedData (see section 3.2.1.2). If the GL member's EnvelopedData (see section 3.2.1.2). If the GL member's
PKC has been revoked, the GL member ought not use it to PKC has been revoked, the GL member ought not use it to
generate the EnvelopedData that encapsulates the generate the EnvelopedData that encapsulates the
glProvideCert request. glProvideCert request.
2.c.2 - The GL member can also optionally apply another SignedData 2.c.2 - The GL member can also optionally apply another SignedData
skipping to change at line 3607 skipping to change at line 3607
3.c.2 - Else if the member's encryption certificate cannot be 3.c.2 - Else if the member's encryption certificate cannot be
verified, the GLA returns another glProvideCert request to verified, the GLA returns another glProvideCert request to
the GL member or a cMCStatusInfoExt with cMCStatus.failed the GL member or a cMCStatusInfoExt with cMCStatus.failed
and the reason why in cMCStatus.statusString to the GLO. and the reason why in cMCStatus.statusString to the GLO.
glProvideCert should be returned only a certain number of glProvideCert should be returned only a certain number of
times because if the GL member does not have a valid times because if the GL member does not have a valid
certificate they will never be able to return one. certificate they will never be able to return one.
Additionally, a signingTime attribute is included with the Additionally, a signingTime attribute is included with the
response. response.
Turner Expires June 2003 68 Turner Expires July 2003 68
And Distribution And Distribution
3.c.3 - Else if the member's encryption certificate verifies, the 3.c.3 - Else if the member's encryption certificate verifies, the
GLO or GLA will use it in subsequent glAddMember requests GLO or GLA will use it in subsequent glAddMember requests
and glKey messages associated with the GL member. and glKey messages associated with the GL member.
4.10.2 GL Member Initiated Update Member Certificate 4.10.2 GL Member Initiated Update Member Certificate
The process for an unsolicited GL member glUpdateCert is as follows: The process for an unsolicited GL member glUpdateCert is as follows:
skipping to change at line 3662 skipping to change at line 3662
cannot be verified, the GLA returns a cMCStatusInfoExt cannot be verified, the GLA returns a cMCStatusInfoExt
response indicating cMCStatus.failed and response indicating cMCStatus.failed and
otherInfo.failInfo.badMessageCheck. otherInfo.failInfo.badMessageCheck.
2.c - Else if the signatures verify, the GLA verifies the member's 2.c - Else if the signatures verify, the GLA verifies the member's
encryption certificate. encryption certificate.
2.c.1 - If the member's encryption certificate cannot be verified, 2.c.1 - If the member's encryption certificate cannot be verified,
the GLA returns another glProvideCert request to the GL the GLA returns another glProvideCert request to the GL
Turner Expires June 2003 69 Turner Expires July 2003 69
And Distribution And Distribution
member or a cMCStatusInfoExt with cMCStatus.failed and the member or a cMCStatusInfoExt with cMCStatus.failed and the
reason why in cMCStatus.statusString to the GLO. reason why in cMCStatus.statusString to the GLO.
glProvideCert ought not be returned indefinitely; if the glProvideCert ought not be returned indefinitely; if the
GL member does not have a valid certificate they will GL member does not have a valid certificate they will
never be able to return one. Additionally, a signingTime never be able to return one. Additionally, a signingTime
attribute is included with the response. attribute is included with the response.
2.c.2 - Else if the member's encryption certificate verifies, the 2.c.2 - Else if the member's encryption certificate verifies, the
skipping to change at line 3716 skipping to change at line 3716
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).
Turner Expires June 2003 70 Turner Expires July 2003 70
And Distribution And Distribution
The GLA MUST use either the kari (see section 12.3.2 of [CMS]) or The GLA MUST use either the kari (see section 12.3.2 of [CMS]) or
ktri (see section 12.3.1 of [CMS]) choice in ktri (see section 12.3.1 of [CMS]) choice in
glKey.glkWrapped.RecipientInfo to ensure only the intended glKey.glkWrapped.RecipientInfo to ensure only the intended
recipients receive the shared KEK. The GLA MUST support the ktri recipients receive the shared KEK. The GLA MUST support the ktri
choice. choice.
When the glKey message is generated as a result of a glRekey request When the glKey message is generated as a result of a glRekey request
with generationCounter greater than zero (0) or when the GLA with generationCounter greater than zero (0) or when the GLA
skipping to change at line 3770 skipping to change at line 3770
the SignedData.PKIData.controlSequence.glKey. the SignedData.PKIData.controlSequence.glKey.
2.a - If the signingTime attribute value is not within the locally 2.a - If the signingTime attribute value is not within the locally
accepted time window, the GLA MAY return a response accepted time window, the GLA MAY return a response
indicating cMCStatus.failed and otherInfo.failInfo.badTime indicating cMCStatus.failed and otherInfo.failInfo.badTime
and a signingTime attribute. and a signingTime attribute.
2.b - Else if signature processing continues and if the signatures 2.b - Else if signature processing continues and if the signatures
cannot be verified, the GL member MUST return a cannot be verified, the GL member MUST return a
Turner Expires June 2003 71 Turner Expires July 2003 71
And Distribution And Distribution
cMCStatusInfoExt response indicating cMCStatus.failed and cMCStatusInfoExt response indicating cMCStatus.failed and
otherInfo.failInfo.badMessageCheck. Additionally, a otherInfo.failInfo.badMessageCheck. Additionally, a
signingTime attribute is included with the response. signingTime attribute is included with the response.
2.c - Else if the signatures verify, the GL member process the 2.c - Else if the signatures verify, the GL member process the
RecipientInfos according to [CMS]. Once unwrapped the GL RecipientInfos according to [CMS]. Once unwrapped the GL
member should store the shared KEK in a safe place. When member should store the shared KEK in a safe place. When
stored, the glName, glIdentifier, and shared KEK should be stored, the glName, glIdentifier, and shared KEK should be
skipping to change at line 3822 skipping to change at line 3822
The algorithm object identifiers included in glkWrapped are as The algorithm object identifiers included in glkWrapped are as
specified in AlgSpec [CMSALG]. specified in AlgSpec [CMSALG].
6.3 Shared KEK Algorithm 6.3 Shared KEK Algorithm
The shared KEK distributed and indicated in glkAlgorithm MUST The shared KEK distributed and indicated in glkAlgorithm MUST
support the symmetric key-encryption algorithms as specified in support the symmetric key-encryption algorithms as specified in
section AlgSpec [CMSALG]. section AlgSpec [CMSALG].
Turner Expires June 2003 72 Turner Expires July 2003 72
And Distribution And Distribution
7 Message Transport 7 Message Transport
SMTP [SMTP] MUST be supported. Other transport mechanisms MAY also SMTP [SMTP] MUST be supported. Other transport mechanisms MAY also
be supported. be supported.
8 Security Considerations 8 Security Considerations
As GLOs control setting up and tearing down the GL, rekeying the GL, As GLOs control setting up and tearing down the GL, rekeying the GL,
skipping to change at line 3874 skipping to change at line 3874
An attacker can attack the group's shared KEK by attacking one An attacker can attack the group's shared KEK by attacking one
member's copy of the shared KEK or attacking multiple member's member's copy of the shared KEK or attacking multiple member's
copies of the shared KEK. For the attacker it may be easier to copies of the shared KEK. For the attacker it may be easier to
either attack the group member with the weakest security protecting either attack the group member with the weakest security protecting
their copy of the shared KEK or by attacking multiple group members. their copy of the shared KEK or by attacking multiple group members.
An aggregation of the information gathered during the attack(s) may An aggregation of the information gathered during the attack(s) may
lead to the compromise of the group's shared KEK. Mechanisms to lead to the compromise of the group's shared KEK. Mechanisms to
protect the shared KEK should be commensurate with value of the data protect the shared KEK should be commensurate with value of the data
being protected. being protected.
Turner Expires June 2003 73 Turner Expires July 2003 73
And Distribution And Distribution
The nonce and signingTime attributes are used to protect against The nonce and signingTime attributes are used to protect against
replay attacks. However, these provisions are only helpful if replay attacks. However, these provisions are only helpful if
entities maintain state information about the messages they have entities maintain state information about the messages they have
sent or received for comparison. If sufficient information is not sent or received for comparison. If sufficient information is not
maintained on each exchange, nonces and signingTime are not helpful. maintained on each exchange, nonces and signingTime are not helpful.
Local policy determines the amount and duration of state information Local policy determines the amount and duration of state information
that is maintained. Additionally, without a unified time source, that is maintained. Additionally, without a unified time source,
there is the possibility of clocks drifting. Local policy determines there is the possibility of clocks drifting. Local policy determines
skipping to change at line 3926 skipping to change at line 3926
[PROFILE] Housley, R., Ford, W., Polk, W. and D. Solo, "Internet [PROFILE] Housley, R., Ford, W., Polk, W. and D. Solo, "Internet
X.509 Public Key Infrastructure: Certificate and CRL Profile", RFC X.509 Public Key Infrastructure: Certificate and CRL Profile", RFC
3280, April 2002. 3280, April 2002.
[ACPROF] Farrell, S., Housley, R., "An Internet Attribute [ACPROF] Farrell, S., Housley, R., "An Internet Attribute
Certificate Profile for Authorization", RFC 3281, April 2002. Certificate Profile for Authorization", RFC 3281, April 2002.
[MSG] Ramsdale, B., "S/MIME Version 3 Message Specification," RFC [MSG] Ramsdale, B., "S/MIME Version 3 Message Specification," RFC
2633, June 1999. 2633, June 1999.
Turner Expires June 2003 74 Turner Expires July 2003 74
And Distribution And Distribution
[ESS] Hoffman, P., "Extended Security Services for S/MIME", RFC [ESS] Hoffman, P., "Extended Security Services for S/MIME", RFC
2634, June 1999. 2634, June 1999.
[CMSALG] 11 Housley, R., "Cryptographic Message Syntax (CMS) [CMSALG] 11 Housley, R., "Cryptographic Message Syntax (CMS)
Algorithms", RFC 3370, August 2002. Algorithms", RFC 3370, August 2002.
[SMTP] Postel, j., "Simple Mail Transport Protocol," RFC 821, August [SMTP] Postel, j., "Simple Mail Transport Protocol," RFC 821, August
1982. 1982.
skipping to change at line 3950 skipping to change at line 3950
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.
11 Author's Addresses 11 Author's Addresses
Sean Turner Sean Turner
IECA, Inc. IECA, Inc.
Phone: +1.703.628.3180 Phone: +1.703.628.3180
Email: turners@ieca.com Email: turners@ieca.com
Turner Expires June 2003 75 Turner Expires July 2003 75
And Distribution And Distribution
Annex A: ASN.1 Module Annex A: ASN.1 Module
SMIMESymmetricKeyDistribution SMIMESymmetricKeyDistribution
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
smime(16) modules(0) symkeydist(12) } smime(16) modules(0) symkeydist(12) }
DEFINITIONS IMPLICIT TAGS ::= DEFINITIONS IMPLICIT TAGS ::=
BEGIN BEGIN
skipping to change at line 4004 skipping to change at line 4004
-- This defines the GL symmetric key distribution object identifier -- This defines the GL symmetric key distribution object identifier
-- arc. -- arc.
id-skd OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) id-skd OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) skd(8) } rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) skd(8) }
-- This defines the GL Use KEK control attribute -- This defines the GL Use KEK control attribute
id-skd-glUseKEK OBJECT IDENTIFIER ::= { id-skd 1} id-skd-glUseKEK OBJECT IDENTIFIER ::= { id-skd 1}
Turner Expires June 2003 76 Turner Expires July 2003 76
And Distribution And Distribution
GLUseKEK ::= SEQUENCE { GLUseKEK ::= SEQUENCE {
glInfo GLInfo, glInfo GLInfo,
glOwnerInfo SEQUENCE SIZE (1..MAX) OF GLOwnerInfo, glOwnerInfo SEQUENCE SIZE (1..MAX) OF GLOwnerInfo,
glAdministration GLAdministration DEFAULT 1, glAdministration GLAdministration DEFAULT 1,
glKeyAttributes GLKeyAttributes OPTIONAL } glKeyAttributes GLKeyAttributes OPTIONAL }
GLInfo ::= SEQUENCE { GLInfo ::= SEQUENCE {
glName GeneralName, glName GeneralName,
skipping to change at line 4055 skipping to change at line 4055
GLAddMember ::= SEQUENCE { GLAddMember ::= SEQUENCE {
glName GeneralName, glName GeneralName,
glMember GLMember } glMember GLMember }
GLMember ::= SEQUENCE { GLMember ::= SEQUENCE {
glMemberName GeneralName, glMemberName GeneralName,
glMemberAddress GeneralName OPTIONAL, glMemberAddress GeneralName OPTIONAL,
certificates Certificates OPTIONAL } certificates Certificates OPTIONAL }
Turner Expires June 2003 77 Turner Expires July 2003 77
And Distribution And Distribution
Certificates ::= SEQUENCE { Certificates ::= SEQUENCE {
pKC [0] Certificate OPTIONAL, pKC [0] Certificate OPTIONAL,
-- See [PROFILE] -- See [PROFILE]
aC [1] SEQUENCE SIZE (1.. MAX) OF aC [1] SEQUENCE SIZE (1.. MAX) OF
AttributeCertificate OPTIONAL, AttributeCertificate OPTIONAL,
-- See [ACPROF] -- See [ACPROF]
certPath [2] CertificateSet OPTIONAL } certPath [2] CertificateSet OPTIONAL }
-- From [CMS] -- From [CMS]
skipping to change at line 4108 skipping to change at line 4108
glName GeneralName, glName GeneralName,
glOwnerInfo GLOwnerInfo } glOwnerInfo GLOwnerInfo }
-- This defines the GL Key Compromise control attribute. -- This defines the GL Key Compromise control attribute.
-- It has the simple type GeneralName. -- It has the simple type GeneralName.
id-skd-glKeyCompromise OBJECT IDENTIFIER ::= { id-skd 8} id-skd-glKeyCompromise OBJECT IDENTIFIER ::= { id-skd 8}
GLKCompromise ::= GeneralName GLKCompromise ::= GeneralName
Turner Expires June 2003 78 Turner Expires July 2003 78
And Distribution And Distribution
-- This defines the GL Key Refresh control attribute. -- This defines the GL Key Refresh control attribute.
id-skd-glkRefresh OBJECT IDENTIFIER ::= { id-skd 9} id-skd-glkRefresh OBJECT IDENTIFIER ::= { id-skd 9}
GLKRefresh ::= SEQUENCE { GLKRefresh ::= SEQUENCE {
glName GeneralName, glName GeneralName,
dates SEQUENCE SIZE (1..MAX) OF Date } dates SEQUENCE SIZE (1..MAX) OF Date }
skipping to change at line 4159 skipping to change at line 4159
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 [MSG]. -- smimeCapabilities attribute as defined in MsgSpec [MSG].
Turner Expires June 2003 79 Turner Expires July 2003 79
And Distribution And Distribution
-- This defines the control attribute to request an updated -- This defines the control attribute to request an updated
-- certificate to the GLA. -- certificate to the GLA.
id-skd-glProvideCert OBJECT IDENTIFIER ::= { id-skd 13} id-skd-glProvideCert OBJECT IDENTIFIER ::= { id-skd 13}
GLManageCert ::= SEQUENCE { GLManageCert ::= SEQUENCE {
glName GeneralName, glName GeneralName,
glMember GLMember } glMember GLMember }
skipping to change at line 4189 skipping to change at line 4189
id-skd-glKey OBJECT IDENTIFIER ::= { id-skd 15} id-skd-glKey OBJECT IDENTIFIER ::= { id-skd 15}
GLKey ::= SEQUENCE { GLKey ::= SEQUENCE {
glName GeneralName, glName GeneralName,
glIdentifier KEKIdentifier, -- See [CMS] glIdentifier KEKIdentifier, -- See [CMS]
glkWrapped RecipientInfos, -- See [CMS] glkWrapped RecipientInfos, -- See [CMS]
glkAlgorithm AlgorithmIdentifier, glkAlgorithm AlgorithmIdentifier,
glkNotBefore GeneralizedTime, glkNotBefore GeneralizedTime,
glkNotAfter GeneralizedTime } glkNotAfter GeneralizedTime }
Turner Expires June 2003 80 Turner Expires July 2003 80
And Distribution And Distribution
-- This defines the CMC error types -- This defines the CMC error types
id-cet-skdFailInfo OBJECT IDENTIFIER ::= { iso(1) id-cet-skdFailInfo OBJECT IDENTIFIER ::= { iso(1)
identified-organization(3) dod(6) internet(1) security(5) identified-organization(3) dod(6) internet(1) security(5)
mechanisms(5) pkix(7) cet(15) skdFailInfo(1) } mechanisms(5) pkix(7) cet(15) skdFailInfo(1) }
SKDFailInfo ::= INTEGER { SKDFailInfo ::= INTEGER {
unspecified (0), unspecified (0),
skipping to change at line 4217 skipping to change at line 4217
nameAlreadyInUse (8), nameAlreadyInUse (8),
noSpam (9), noSpam (9),
deniedAccess (10), deniedAccess (10),
alreadyAMember (11), alreadyAMember (11),
notAMember (12), notAMember (12),
alreadyAnOwner (13), alreadyAnOwner (13),
notAnOwner (14) } notAnOwner (14) }
END -- SMIMESymmetricKeyDistribution END -- SMIMESymmetricKeyDistribution
Expires June 2003 Expires July 2003
Turner Expires June 2003 81 Turner Expires July 2003 81
 End of changes. 

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