Subject: Re: Input desired on symkeydist?

From: "Sean P. Turner" <[email-masked]>
Date: Wed, 12 Dec 2001 10:42:31 -0500

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.

---

From: "Housley, Russ" <[email-masked]>
Date: Wed, 12 Dec 2001 18:33:53 -0500

Sean:

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

Russ

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