Re: Input desired on symkeydist?

["Housley, Russ" <rhousley@xxxxxxxxxxxxxxx>]

Sean:

Please post the updated draft.  I consider them early IETF Last Call
comments.

Russ


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".
>
>Fixed
>
> > 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".
>
>Fixed
>
> > 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".
>
>Fixed
>
> > Page 4, section 1.2, 2nd sentence, change "any one" to "anyone".
>
>Fixed
>
> > 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.
>
>Fixed
>
> > 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".
>
>Fixed
>
> > Page 5, Section 3, para 1, 4th sentence, change "setup" to "set 
> up".  Also fix
> > the "'"s in this paragraph.
>
>Fixed
>
> > Page 8, 1st para, last sentence, here's an example of the "o with 
> circumflex"
> > problem.
>
>Fixed
>
> > 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
>glOwnerName.
>
> > 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
> > CMC/CMS)?
>
>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".
>
>Fixed
>
> > Page 10, 11th bullet (Managed), change "they are" to "it is".
>
>Fixed
>
> > Page 11, 1st bullet (Closed), change "they are" to "it is".
>
>Fixed
>
> > Page 11, 4th bullet (recipientsNotMutuallyAware), change "to not be" to 
> "not
> > to be".
>
>FIxed
>
> > 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).
>
>Fixed
>
> > Page 19, 3rd bullet, which name form?  Also, place a period at the end 
> of this
> > sentence.
>
>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.
>
>Fixed
>
> > Page 20, last paragraph, last sentence, insert a comma between 
> "recipient" and
> > "you".
>
>Fixed
>
> > Page 21, 2nd bullet, change "FALSE" to "TRUE".
>
>Fixed
>
> > Page 21, 5th fullet, change "FALSE" to "TRUE".
>
>Fixed
>
> > Page 24, section 3.2.3, 2nd para, 1st sentence, insert a space between
> > "cMCStatusInfoEx" and "and".  They ran together.
>
>Fixed
>
> > Page 24, section 3.2.3, 2nd para, 1st sentence, change "FALSE" to
"TRUE".
>
>Fixed
>
> > 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 3.2.4.3, 2nd para, 1st sentence, change "aggratates" to
> > "aggragates".
>
>Fixed
>
> > 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.
>
>Fixed.




============================================================================
================
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. 
Thank You.
============================================================================
================