All,
Here are the comments I've received off-line on the symmetric key
distribution draft:
General:
- Remove distributionMethod from messages. Whatever mechanism the GLA
supports is the mechanism the objects will be distributed to the GL
members.
- CMC expects a one-to-one relationship between control messages and
responses. glAddMembers, glRemoveMembers, glAddOwners, glRemoveOwners
should only support adding/removing one member/owner at a time.
glSuccessInfo and glFailInfo will also need to be changed accordingly.
- In section 4, glIdentifier is optional determining whether the GL is
supported by the GLA. Since the glName has to be unique for a given
GLA, the glName should be used to determine whether the GL is supported
by the GLA. Remove glIdentifier from glDelete, glAddMembers,
glDeleteMembers, glAddOwner, glDeleteOwner, glKeyCompromise, and
glKeyRefresh.
- glDelete, glAddOwners, glRemoveOwners, glkCompromise, and glkRefresh
have an unneeded layer of indirection. Please remove (e.g., GLDelete
::= GLNameAndIdentifier just make glDelete be GeneralName).
Para 1.1:
- Explicitly state that the the originator can use either the shared KEK
or the MLA's public key certificate to encrypt messages for the MLA.
Para 2 1st para below Figure 1
- The method of key archival would be a better way to differentiate
between multiple KMAs that support a single GLA.
Para 3.1
- A message to request old shared KEKs should be added. This would
allow new GL members to access messages encrypted under old KEKs. It
would support things such as list archives.
- A message for the GL member to indicate that they have a new PKC
should be added. This would help in distribution of messages.
- A message for the GLO to ask GL members for new certificates should be
added. This will help when the GL member's certificate has expired or
is revoked.
- Need to provide context for implementation column - what component
needs to implement what messages.
- Use lower case names to refer to the messages (i.e., glUseKEK vice
GLUseKEK).
para 3.1.1 - glUseKEK
- You defaulted everything but requestedAlgorithm - make default
algorithm 3DES.
- The default for glAdministration should be managed and accepts
requests. It seems strange to default secure group lists to be "open."
para 3.1.3 & 3.1.4 glAddMembers and glDeleteMembers
- Indicate in the first paragraph that the message must be signed by the
GLO or GL member.
para 3.1.5 glRekey
- Remove glOwner from the message. There should be one mechanism to
change the GL owner and that's glAddOwner.
- Not sure if the defaulting mechanism in
para 3.1.6 glAddOwner
- The gLAddOwner message is applicable to closed lists also. There is
still one owner, but when a GLO leaves a company, for example, there has
to be a mechanism to replace the old GLO with a new GLO.
para 3.1.8 glKeyCompromise
- Somewhere in the draft there is a statement that only the GLO or the
GLA can generate rekey messages. paragraph 4 indicates that if this
message is sent to the GLA by a GL member it initiates a rekey. The
message should be redirected to the GLO to maintain this model.
3.1.10 & 3.1.11 glSucessInfo and glFailInfo
- Refering to the note - Don't think we want to distribute sucess/fail
info to all GLOs. Just send the success/fail info to the requesting GLO
and let the other GLOs use the logs to figure out what happened.
3.1.12 & 3.1.13 glaQueryRequest & glaQueryResponse
- The mechansims should be extensible, as there are surely more things
the GLO would ask of the GLA than the supportedAlgorithms. Make it an
ANY definded by.
3.1.14 glKey
- glIdentifier is the shared KEK's key identifier. It should be an
OCTET STRING to match the keyIdentifier in RecipientInfo.kekri.
- Instead of the term Greenwich Mean Time use UTC.
3.2.2 Combining Request and Response
- Though the option to allow individual encryption of messages is
allowed, it is a bad practice. Please remove the description of
individually encrypting the messages.
- The order of processing for glAddMembers and gLRekey should be
reversed. Also, not sure why you;d care about processing glSucessInfo
before glKey.
4 Administrative Messages
- Clearly indicate that the eaxct procedures are not required only that
out must be supported.
4.1 Assign KEK to GL
- Make sure to add an error for the GLA to tell the GLO that it does not
have a certificate.
Cheers,
spt