CMS Symmetric Key Management and Distribution
Extracted elements (30)
CMC was chosen as the protocol foundation to avoid creating an entirely new protocol. Its layering model—control attributes included in a CMC message protected by CMS—provides the request/response structure needed for GL management without reinventing transport or protection primitives.
The interactions between the KMA and GMA components are explicitly left out of scope. Separating them would require the KMA to duplicate validation checks against a potentially corrupt GMA, blurring the functional boundary. Proprietary trust mechanisms are recommended to support separation.
The recipientsNotMutuallyAware flag was introduced to support GLs where policy prohibits members from knowing who else is on the list. A single consolidated glKey message would expose member identities through RecipientInfos, so separate per-recipient messages are required when this flag is TRUE.
Three GL administration modes (unmanaged, managed, closed) were defined to model the real-world spectrum from open lists—where any prospective member may self-enroll—to tightly controlled lists where the GLO solely determines membership. Access control enforcement is left to local policy.
GLA query request/response pairs are registered under the id-cmc-glaRR OID arc ({id-cmc 99}). This document defines one pair: id-cmc-gla-skdAlgRequest (NULL request) and id-cmc-gla-skdAlgResponse (smimeCapabilities response) for querying supported algorithms. Additional pairs may be defined in future documents.
Requests and responses for multiple GLs may be combined in one PKIData or PKIResponse using cmsSequence, but a separate cmsSequence MUST be used for each different GL. Processing priority is defined as: glUseKEK before glAddMember, glRekey before glAddMember, and glDeleteMember before glRekey.
All messages MUST include the signingTime attribute to enable application-level replay prevention. Recipients use this value to determine whether they have previously received the message.
At a minimum, a SignedData MUST protect each request and response encapsulated in PKIData and PKIResponse. All SignedData objects MUST be processed according to CMS before any action is taken.
Certain combinations of control attributes in one PKIData or PKIResponse MUST NOT be generated. Prohibited pairs include: glUseKEK with glDeleteMember/glRekey/glDelete; and glDelete with glAddMember/glDeleteMember/glRekey/glAddOwner/glRemoveOwner.
GeneralizedTime values in glkNotBefore and glkNotAfter MUST be expressed in UTC (Zulu) and MUST include seconds using the format YYYYMMDDHHMMSSZ, even when seconds are zero. GeneralizedTime values MUST NOT include fractional seconds.
glAddMember messages MUST be signed by either the GLO or the prospective GL member. glMemberAddress MUST be included. The certificates field MUST be included; if the request is generated by a prospective member, pKC MUST be present.
glUseKEK messages requesting KEK assignment to a GL MUST be signed by the GLO. Both glName and glAddress MUST be unique for a given GLA. One of the names in glOwnerName MUST match a name in the certificate used to sign the PKIData.
If a GL member's or GLO's encryption certificate has been revoked, the GLA or GLO MUST NOT use that certificate to generate the EnvelopedData encapsulating a glProvideCert request. Similarly, a GL member MUST NOT use a revoked encryption certificate to encapsulate a glUpdateCert request.
If a GLO or GL member applies confidentiality to a request, the EnvelopedData MUST include the GLA as a recipient. If the GLA forwards the request to the GLO, the GLA MUST decrypt the EnvelopedData, strip the confidentiality layer, and apply a new EnvelopedData with the GLO as recipient.
If signature verification fails over any control attribute other than cMCStatusInfoExt, a cMCStatusInfoExt MUST be returned with cMCStatus.failed and otherInfo.failInfo.badMessageCheck. If a request cannot be processed immediately, cMCStatusInfoExt MUST indicate cMCStatus.pending.
The glKey message distributing the shared KEK MUST be signed by the GLA. The ktri RecipientInfo CHOICE MUST be supported in glkWrapped. The key in EncryptedKey MUST be generated according to the random number generation guidance in the CMS security considerations.
To ensure uninterrupted GL operation, two (2) shared KEKs at minimum MUST be initially distributed; the second KEK is sent with the first so recipients have a ready successor when the first expires.
When GLKeyAttributes.recipientsNotMutuallyAware is TRUE, separate PKIResponse.cMCStatusInfoExt and PKIData.glKey messages MUST be generated for each recipient to prevent member identity disclosure through shared RecipientInfos.
When the GLA forwards a managed GL member request (glAddMember, glDeleteMember, or glkCompromise) to the GLO, an additional SignedData MUST be applied to the redirected request wrapping PKIData with a cmsSequence containing the original SignedData.PKIData.
Fourteen control attributes are defined under the id-skd OID arc (glUseKEK through glKey, id-skd 1–15 with gap at 10). They are carried in CMC PKIData (requests) or PKIResponse (responses), except glUpdateCert which may appear in either. Three entity types—GLO, GLA, and GL member—have distinct originate/receive/forward requirements for each attribute.
GLAdministration is an INTEGER with three values: unmanaged(0), which allows prospective members to self-add and self-delete without GLO intervention; managed(1), which redirects member requests to the GLO for approval; and closed(2), which allows only GLO-initiated additions and deletions. The default is managed(1).
GLKeyAttributes controls the shared KEK lifecycle: rekeyControlledByGLO (BOOLEAN DEFAULT FALSE), recipientsNotMutuallyAware (BOOLEAN DEFAULT TRUE), duration in days (INTEGER DEFAULT 0 means calendar month), generationCounter (INTEGER DEFAULT 2), and requestedAlgorithm (AlgorithmIdentifier DEFAULT id-aes128-wrap).
The GLA architecture separates two functions: the Key Management Agent (KMA), which generates shared KEKs, and the Group Management Agent (GMA), which manages the Group List membership. These may be co-located or deployed separately; their internal interaction is beyond the scope of this document.
This document registers fourteen control attribute OIDs under the id-skd arc and two query/response OIDs (id-cmc-gla-skdAlgRequest, id-cmc-gla-skdAlgResponse) under id-cmc-glaRR ({id-cmc 99}). It also registers the SKDFailInfo failure code OID id-cet-skdFailInfo under the PKIX cet arc.
A corrupt GLA can always cause havoc in the key distribution system. Even if KMA and GMA are separated, a corrupted GMA could manipulate requests sent to the KMA, forcing duplicative cross-checking that undermines the separation of functions.
GL members and GLOs MUST use glkCompromise to report a compromised shared KEK. The GLA always redirects the message to the GLO for further action. The glkCompromise message MAY itself be enclosed in an EnvelopedData generated using the compromised KEK.
GLKey is a SEQUENCE with glName (GeneralName), glIdentifier (KEKIdentifier with keyIdentifier OCTET STRING and optional date/other fields), glkWrapped (RecipientInfos from CMS), glkAlgorithm (AlgorithmIdentifier), glkNotBefore (GeneralizedTime), and glkNotAfter (GeneralizedTime). glkWrapped carries the wrapped shared KEK for a specific validity period.
GLKRefresh is a SEQUENCE with glName (GeneralName) and dates (SEQUENCE SIZE(1..MAX) OF Date). Each Date contains a start (GeneralizedTime) and optional end (GeneralizedTime); omitting end requests all keys from start to the current date.
GLUseKEK is a SEQUENCE containing glInfo (GLInfo with glName and glAddress GeneralNames), glOwnerInfo (SEQUENCE SIZE(1..MAX) OF GLOwnerInfo), glAdministration (GLAdministration DEFAULT 1), and optional glKeyAttributes. GLOwnerInfo carries glOwnerName, glOwnerAddress, and an optional Certificates structure with pKC, aC, and certPath fields.
SKDFailInfo is an INTEGER enumeration encoded in the ExtendedFailInfo field of cMCStatusInfoExt under OID id-cet-skdFailInfo. Values include unspecified(0), closedGL(1), unsupportedDuration(2), noGLACertificate(3), invalidCert(4), unsupportedAlgorithm(5), noGLONameMatch(6), invalidGLName(7), nameAlreadyInUse(8), noSpam(9), alreadyAMember(11), notAMember(12), alreadyAnOwner(13), notAnOwner(14).