ietf-smime
[Top] [All Lists]

comments on draft-ietf-smime-symkeydist-02.txt

2001-03-21 12:30:42
All,

Here were the comments that I received on
draft-ietf-smime-symkeydist-02.txt (used these to generate the current
-03 version):

Line 359 - upper case glAddMember as Syntax

Okay

Line 379 - Define what O, R and F mean.

Modified paragraph before conformance tables to indicate that O is
originate, R is receive, and F if forward.

Line 379 - In pre-table text.  GLO and GLA/O are MAY.  Then up some MAYs
to MUST within the table

After some discussion, I decided to split the tables to indicate the
required messages and optional messages and to rewrite the paragraph
that came before the tables.  I also changed "N/A" to "-" for
readability reasons.  GLOs are now clearly indicated as an optional
implementation.  Hopefully people will let me know if I got it right.

Line 379 - Add new column to GLA F-GLO and F-GLM?

I think after the changes I made a result of the other columns aren't
needed (or maybe I didn't understand why they were needed in the first
place).

Line 420 - [0] is not needed unless another optional item is to be
added.

Removed it.

Line 441 - Can't be both default and optional

Removed the "OPTIONAL"

Line 449 - Both name and address unique or combination is unique - be
specific.

I want to make sure the GL name and the address is unique for a given
GLA.

Line 500 - Text and title are reverse sense of each other.

Ended up changing the titles to be more "user friendly."

Line 522 - Are dates & times to be UTC or local?

I made them UTC.

Line 546 - Appears to be more the generation algorithm and not the CEK
algorithm from the text description

I ended up changing the sentence to say: "requestedAlgorithm indicates
the algorithm and any parameters the GLO wants the GLA to use with the
shared KEK. "

Line 585 - SEQUENCE (1..MAX) OF ...

Added the (1..MAX)

Line 590 - either import or ditto above

okay ... decided to copy above.

Line 605 - glMember.glmemberName and glMember.glMemberAddress must be
unique

Added a sentence to indicate that the two must unique.

Line 605 - Formatting - break down sub-field items into bulleted list

okay

Line 624 - Simplify "and GL members use glDeleteMember to request..."

okay

Line 680 - Why use special value of generationCounter rather than a new
field?

After some discussion I was convinced and have added a new field called:
"glRekeyAllGLKeys indicates whether the GLO wants all of the outstanding
GL?s shared KEKs rekeyed. If it is set to TRUE then all outstanding KEKs
MUST be issued. If it is set to FALSE then all outstanding KEKs need not
be resissued."

Line 700 - Where is the new GLO certificate? - missing field from
GLOwnerInfo?

At first I thought we should just use the update certificate message,
but I have been convinced that we should add a "certificates" field to
the GLOwnerInfo field.  Unfortunately, I didn't get convinced until
after I'd submitted it, so it will have to wait until the next draft.

Line 719 - Syntax "MUST be signed a registered"

changed it to "MUST be signed by a registered"

Line 721 - How to I replace a GLO for an unmanaged list?

I was being to restrictive by not allowing multiple GLOs for unmanaged
lists.  I have removed this restriction.

Line 760 - glkRefresh still has not date component in it.

Added a date field, but this ended up changing a few other things.

Line 765 - Change the GLSuccess structure - need tag id

This is going to get removed.

Line 838 - ditto for GLFailInfo

See above

Line 876 - could you both return this and forward request to GLO?

That would certainly make it more friendly.  I added a sentence to say
it was up GL policy (in section 3.1.1) to forward a request when it?s an
closed GL.

Line 970 - is certificate optional for glAddMember?  sends out a
glProvideCert to the member to be added.

The end result was that I ended up changing GLProvideCert by replacing
glMemberName with glMember and making GLMember.certificates be optional
(and stated that it SHOULD be omitted from GLProvideCert and that it
MUST be included in GLUpdateCert).

Line 1007 - are both required or is GeneralName sufficent -- this is all
that is sent the the preceeding message.

I made the address optional in this case.

Line 1013 - bullet sub-field items

okay

Line 1037 - I think you should allow for additional items here? Maybe?

I'll make this change in the next version (i.e., I'll use
KEKIdentifier).

Line 1057 - caps must

okay

Line 1061 - make it the ktri must be supported

I may have overstepped my pay grade here but I changed it to be the ktri
choice as a result of the group's sentiment in San Diego.

Line 1061 - sentence #2 needs some re-writing

okay

Line 1066 - Is the IV encoded here or S/MIME Caps for parameter

I'll make a change in the next version.

Line 1088 - not strict enough - must generate unique messages for each
receipient each containg a glKey attribute for the single recipient.

Added the following: "For each recipient you want to generate a message
that contains that recipient?s key (i.e., one message with one
attribute)."

Line 1116 - why this and not always have X current keys.

Changed it to say: "The GLA MUST generate X number of glKey messages,
where X is the number of outstanding shared KEKs for the GL if
glRekeyAllGLKeys is set to TRUE."

Line 1178 - Add if possible - consider encrypted updateCert with bad
cert.

I actually avoided this on purpose.

Line 1186 - Confidentality between the GLA and GLO may be provided by
other methods thus the encrytion layer can be omitted in these cases.

I ended up stating that "confidentiality MUST be preserved"

Line 1190 - typo Mutlipe

okay

Line 1214 - Might as well be "one or more requests"

okay

Line 1271 - I'm not sure about this one.  I need to think about it.

Ended up removing that combination

Line 1274 - does this imply an order of items in the message - state so
either way.

Added the following: "It should be noted that there is a priority but it
does not imply an order."

Line 1292 - Incorrect - responses to GLOs may be lumped together.

Added the following: "It is valid to send one message with multiple
attributes to the same recipient."

Unknown - No status messasge is expected to be returned by a client to a
glKey attribute.

Need to add that in the -04 version.

Line 1406 - This is generated by the GLA not the GLO. -- Send suggested
text & new fail structure from CMC.

Need to make these changes in the -04 version.

Line 1431 - possible way to handle this.  THere are others.

okay.

Unknown - Put in a UTF8String statement for DN's

Added it to the PKIX section.

Line 1489 - "glAddMember request(s)"

okay

Line 1513 - Do we need to be able to pass an asymmetric key & cert to
the GLA?

I added: "Instead of immediately returning the error code, the GLA MAY
attempt to get a certificate, possibly using CMC [3]."

Line 1525 - "Must check that glAddress is not already in use"

Good catch.

Line 1586 - Why would you return a response to a response?

Jsut trying to be preceise.  Probably have to fix this in the -04
version.

Line 1586 - What is correct GLA response to this?  Not covered in CMC.

okay.

Line 1515 - Should the DN for the GLA certificate include the GL name or
that of the GLA?

I made it be the DN Of the GL. Not sure if this is right but I'll await
comments.

Line 1758 - I disagree with the MUST

Made it a "MAY".

Line 1775 - lower case the MAY.

okay

Line 1918 - Do you need to verify that the glMembers name or address is
contained in the certificate

I put in that:"The GL policy may mandate that the GL member?s address be
included in the GL member?s certificate."

Section 4.4.1 - If list is closed and rekey is missing is there a GLA
response?
        2.b.2.b.1.b and 1 different on the requirement of who must do
the re-key

Okay what I did was change the last sentence to say: ?Note that he GL
MUST also be rekeyed as described in paragraph 5.?  That way I?m not
saying who has to do the rekey (it depends on who controls the list).  I
made the same change to 2.b.2.b.2.b.  It now matches that it?s option to
rekey the GL.

Line 2196 - "a _" should be "a -"

okay

Section 4.4.2 - Item 1 - omission of the glIdentifier should be deleted

Okay.

Section 4.4.2 - Item 3 - Need to state it is not for open lists. "If a
GLO recieves a a forwarded request, ...."

I added the following to item 3 in 4.3.2 and 4.4.2 where the GLO could
receive a forwarded request: ?Note: For cases where the GL is closed and
either a) a prospective member sends directly to the GLO or b) the GLA
has mistakenly forwarded the request to the GLO, the GLO should first
determine whether to honor the request.?

Section 4.4.2 - Section 3.b.2 - Why is there text about once and only
once in the list?  Which list is being refered to the delete list or the
mail list?

I changed to say ?GL? instead of ?list.?  I deleted the part about once
and only once.

General Comment - You keep referencing things like paragraph 5 -- to me
this should be Section 5.  Paragraphs are seperated by CRs and Sections
are numbered.

Changed "sections" to be "paragraphs"

Section 4.5 - Paragraph 9 - GLA can do an automatic rekey on key
compromise for GLA rekey lists.

I changed to indicate as much.

General - I don't know where this goes.  Should state that if a
signature outside of an encryption layer is added, the "Content-Hint"
attribute must be included in the outer signature.

Agree, but it didn't make it into the -03 version, will put it in the
-04 version.

Section 4.5.2 - "1 _" not "1 -"

OKay.

Figure 8 - "8 _" to "8 -" ----- Global search for this

OKay.

Figure 10 - Should be a single member not multiple members.

Fixed.

Section 4.8 - The response message is missing from the steps.

This missed going into the -03 version will include it in the -04
version.

Section 4.9 - 2.b - "GLAQueryReuests"

Fixed.

Section 4.9 - GLAQueryRequest/Response can be betweeen GLA and member

Okay changed it to indicate as much.

Section 4.9 - 2.b.2 - Make this more general -- "With the correct
response for the qeusts".

Fixed.

Section 5 - Did we have the kari vs ktri discussion?

After San Diego, I decided to change it to ktri.

Section 5 - I really don't like the idea of using kekri for distribution
of keys.  This means that breaking key #1 means you can chain through
and get the rest of them.

Have some text, but it didn't make it in the -03 version.  Will include
it in the -04 version.

Section 9 - Text is missing

Added some, let me know what you think.

Cheers,

spt
<Prev in Thread] Current Thread [Next in Thread>
  • comments on draft-ietf-smime-symkeydist-02.txt, Sean P. Turner <=