Re: Input desired on symkeydist?
Please post the updated draft. I consider them early IETF Last Call
At 10:42 AM 12/12/2001 -0500, Sean P. Turner wrote:
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
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
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
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
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
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
edited the document in an editor which does not always put out pure
particular, your "'" comes out as a combined AE character. Some of the
quotes (") come out as an "o" with a circumflex over it. You might want
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
Page 9, GLInfo, why did you include both the glName and glAddress here
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
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
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
did a cut-and-paste from later in the document. In particular, you
"that member" -- which member? Also, adding another GLO is not
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
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
Page 13, certificates.aC, it seems odd to include attribute certificates
modify an encryption certificate when extensions in the encryption
might be more appropriate. This argument is academic -- I do not have
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
this is supposed to match the GL member's name or address (GeneralName
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
of controls, such as changing list attributes while rekeying the list.
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
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
the preferred form.
The one they used to sign up with.
Page 20, last paragraph, change "FALSE" to "TRUE". This seems to be a
throughout the document. As I understand it, the attribute
"recipientsNotMutually- Aware" would be set to TRUE when it is desired
the recipients are not aware of each other, and thus a separate glKey
should be generated for each recipient.
Page 20, last paragraph, last sentence, insert a comma between
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
Page 24, overall problem, change "cMCStatusInfoEx" to "cMCStatusInfoExt"
throughout the document. Both forms appear in the draft on the IETF
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 22.214.171.124, 2nd para, 1st sentence, change "aggratates" to
Page 30, 2.b, immediately following the number/letter indicator is a "u
circumflex". I presume this is supposed to be a "-", but may be your
processors substitution for an em-dash or en-dash.
This e-mail, its content and any files transmitted with it are intended
solely for the addressee(s) and are PRIVILEGED and
CONFIDENTIAL. Access by any other party is unauthorized without the express
prior written permission of the sender. If
you have received this e-mail in error you may not copy, disclose to any
third party or use the contents, attachments or
information in any way, Please delete all copies of the e-mail and the
attachment(s), if any and notify the sender.