[Top] [All Lists]

Re: Input desired on symkeydist?

2001-12-12 09:54:34

Here are some editorial comments on the symkeydist-06 draft.  I'll defer
to Russ as to how to handle these.

"Yee, Peter" wrote:

Page 3, para 2, 2nd sentence, change "ReipientInfo" to "RecipientInfo".


Page 3, para 2, metadiscussion, is it appropriate to jump in with ktri and
kari this early in the document?

I thought it was a good lead in to explain the difference between the
ktri | kari and kekri.  I figured most people from the S/MIME group
would be fully aware of the other two choices but maybe not the kekri.

Page 3, para 2, last sentence, change (twice) "their" to "its".


Page 4, para 1, you state that the security provided "is only as good as the
sum...".  I content that it "is only as good as the weakest protection
mechanism employed."  The KEK only has to be retrieved from the holder with
the weakest protections to be compromised.

We're basically trying to say it's the sum of weakest people on the
list. Unfortunately, right now the english is escaping me.

Page 4, section 1.2, 1st sentence, change "Light Weight" to "Lightweight".


Page 4, section 1.2, 2nd sentence, change "any one" to "anyone".


Page 5, scenario 2, are the "S" keys the same.  I don't believe so, in which
case I would label one "S1" and the other "S2".

Actually I was thinking they were, but they don't have to be the same.
They could be different.  Is it worth adding: 
"The key used by the originator could either be a key shared amongst all
recipients or just between the member and the MLA. If the originator use
a key shared only with the MLA, then the MLA will need to decrypt the
message and rencrypt the message for the list recipients."

Page 5, Figure 1, the picture needs a bit of patching so that the lines
connecting the GL to the members actually align.


Page 5, 2nd para, 2nd sentence, the "'" seems to be damaged.  You probably
edited the document in an editor which does not always put out pure ASCII. In
particular, your "'" comes out as a combined AE character.  Some of the double
quotes (") come out as an "o" with a circumflex over it.  You might want to
patch these throughout the document before final submission.

As it turns out I had "smart quotes" turned on which ended up being the
dumb thing to do. I'll scrub the document and make they get fixed.

Page 5, 2nd para, 4 sentence, change "setup" to "set up".


Page 5, Section 3, para 1, 4th sentence, change "setup" to "set up".  Also fix
the "'"s in this paragraph.


Page 8, 1st para, last sentence, here's an example of the "o with circumflex"


Page 9, GLInfo, why did you include both the glName and glAddress here but not
in GLAddMember, for example?

Well I figured it would be helpful as the name does not always provide
enough information to allow you to contact them.  I was also trying
desperately trying to avoid any issues with name forms.

Page 9, GLOwnerInfo.glOwnerName, do you wish to note that this name for is
constrained to match that found in the owner's certificate?

I think I meant to move the 2nd sentence in the glOwnerAddress to

Page 9, GLOwnerInfo.glOwnerAddress, do you wish to constrain the GeneralName
form used?

No :) We're trying to be application independent.

Page 9, Certificates, would it be useful to include CRLs as well (ala

You would include the CRLs in the outer CMS envelope.  Or they could put
in the CRLDP.  I guess we were just trying to keep it small.

Page 10, 6th bullet, this paragraph does not make sense.  It looks like you
did a cut-and-paste from later in the document.  In particular, you talk about
"that member" -- which member?  Also, adding another GLO is not performed by
this control so why have a discussion about adding another GLO here?  Plus an
encryption certificate seems inappropriate since a GLO does not need to be a
member of GL, right?

"that member" should have been "that GLO".  The 2nd to last sentence
shouldn't be there as you are correct that this attribute no longer can
be used to add new GLOs. I ended up replacing the last two sentences
with: "It will be used to encrypt responses for the GLO."

Page 10, 10th bullet (Unmanaged), change "they are" to "it is".


Page 10, 11th bullet (Managed), change "they are" to "it is".


Page 11, 1st bullet (Closed), change "they are" to "it is".


Page 11, 4th bullet (recipientsNotMutuallyAware), change "to not be" to "not
to be".


Page 13, certificates.aC, it seems odd to include attribute certificates to
modify an encryption certificate when extensions in the encryption certificate
might be more appropriate.  This argument is academic -- I do not have an
example of needing this functionality either way.

No action required :)  I'm not trying to be sneaky - basically since we
used CertificateSet from CMS it's a field that I had to describe.

Page 14, section 3.1.4, GLDeleteMember.glMemberToDelete, it is not apparent if
this is supposed to match the GL member's name or address (GeneralName being
sufficiently ambiguous).  This would be a good place to note which one.

To be honest I think it doesn't matter which one gets put there.  When a
person is added to the GL both the address and name had to be included. 
So when you delete a member either can be used. I did modify the
sentence to say it could either be the name or address.

Page 14, metadiscussion, overall issue: there seems to be a lot of compositing
of controls, such as changing list attributes while rekeying the list.  I
think these functions should be decomposed into separate controls.

I guess my idea was to keep it simple.  Since almost all of the fields
are optional you only need to include the ones that you want to change. 
I think it's just an organizational thing.

Page 15, 2nd bullet, what does "outstanding" mean?

Outstanding refers to keys that were predistributed.  When you set up
the GLO you can have X number of keys distributed (where X is specified
in generationCounter).  It shouldn't be in the glNewKeyAttributes
bullet, but it should be in glRekeyAllGLKeys bullet.

Page 16, section 3.1.8, last sentence, change "included" to "placed".  I
believe GLKCompromise is complete and not partial (inclusive).


Page 19, 3rd bullet, which name form?  Also, place a period at the end of this

The GLA is only going to have the name form that GLO or GL member
provided.  The GLO is going to have the one that the either the GL
member provided or one that he found in the directory.  I'm not sure
where it's ambiguous.

Page 19, metadiscussion, general comment: use of GeneralName should specify
the preferred form.

The one they used to sign up with.

Page 20, last paragraph, change "FALSE" to "TRUE".  This seems to be a problem
throughout the document.  As I understand it, the attribute
"recipientsNotMutually- Aware" would be set to TRUE when it is desired that
the recipients are not aware of each other, and thus a separate glKey message
should be generated for each recipient.


Page 20, last paragraph, last sentence, insert a comma between "recipient" and


Page 21, 2nd bullet, change "FALSE" to "TRUE".


Page 21, 5th fullet, change "FALSE" to "TRUE".


Page 24, section 3.2.3, 2nd para, 1st sentence, insert a space between
"cMCStatusInfoEx" and "and".  They ran together.


Page 24, section 3.2.3, 2nd para, 1st sentence, change "FALSE" to "TRUE".


Page 24, overall problem, change "cMCStatusInfoEx" to "cMCStatusInfoExt"
throughout the document.  Both forms appear in the draft on the IETF servers,
however, the "Ex" form only appears twice and does not appear to be the
canonical form (i.e., in the ASN.1).

Global replace of InfoEx with InfoExt

Page 28, section, 2nd para, 1st sentence, change "aggratates" to


Page 30, 2.b, immediately following the number/letter indicator is a "u with
circumflex". I presume this is supposed to be a "-", but may be your word
processors substitution for an em-dash or en-dash.


<Prev in Thread] Current Thread [Next in Thread>