Subject: Comments on symkeydist-01

From: Sean Turner <[email-masked]>
Date: Thu, 10 Aug 2000 17:45:05 -0400

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