Last Call Review of draft-herzog-setkey-
review-herzog-setkey-secdir-lc-wallace-2011-02-07-00

I have reviewed this document as part of the security directorate's ongoing
effort to review all IETF documents being processed by the IESG.  These
comments were written primarily for the benefit of the security area
directors.  Document editors and WG chairs should treat these comments just
like any other last call comments.



The draft-herzog-setkey-03 I-D defines an attribute for use with the symmetric
key package structure defined in RFC 6031.



I have a number of questions and concerns about this draft.  The primary issue
is a lack of discussion of who processes the attribute, how the processing is
performed and the effects of the processing.  Some of my questions would
probably be cleared up if the processing rules for the attribute were clear. 
For example, without understanding the processing of the participant-sets, it
is not clear why something simple like a key usage value cannot be used to
simply denote that the holder of the key may only use the key in an active or
passive way.  Below are a list of questions, comments and nits more or less in
the order they appear in the document.



In the last paragraph of section 1.1, it would be helpful to define
“participant-set” before noting that one may be partitioned.



On page 3, s/Becuase/Because/



On page 5, s/Futher/Further/



On page 5, s/Heirarchy/Hierarchy/



What grammar is being referenced in the last paragraph of section 1.2?  As
noted below, including the attribute syntax may be helpful.



In section 2, why are the union, intersection and setdiff represented in the
attribute value instead of being calculated by the key source with the results
of the calculation included in the attribute value?



In section 2, must each of union, intersection and setdiff have a terminal
SetKeyParticipantSet value that contains community, groupID or explicit?  If
so, it may be easier to move community and groupID into SetMember and define
the union, intersection and setdiff fields to be SEQUENCEs of SetMembers.



In section 2, why SHOULD NOT appear in sKeyAttrs instead of MUST NOT?  When is
it OK to use for a specific key?  Would this attribute be appropriate as an
unprotected attribute in an RFC 6032 structure?



The last sentence of the second paragraph below the ASN.1 in section 2 states
that a member SHOULD be considered active if it appears in both lists.  What
does this mean?  If the participant is acting as a passive participant, must it
be considered as active because it appears in both lists or is passive a subset
of active by definition?



In section 2, the bullet that describes the union field refers to empty and
non-empty sets.  The syntax does not permit an empty SetKeyParticipantSet
value.  If the expectation is that each SetKeyParticipantSet member in the
union be evaluated first, that should be clearly stated.  Same comment applies
to the intersection and setdiff fields.  This sort of evaluation seems like it
could get fairly complicated.



The bullets describing the community and groupID fields indicate that the
values SHOULD represent unchanging sets of participants.  Earlier the draft
defines sets as immutable.  Should these SHOULDs be MUSTs?  Are there any
security considerations specific to using groups with variable membership?



Section 2 implies that a participant is evaluated relative to the contents of a
setkey attribute.  Where does the participant value come from?  Does it
identify a specific entity, a group or both?



Is the freeform field intended to carry text?  If so why not use UTF8String
instead of OCTET STRING?  There’s probably a language tag issue to be had in
here somewhere too:-)



In the last paragraph on page 8, does locations mean fields within an attribute
instance?  If so, providing examples of these locations might be helpful.  This
might also benefit the first paragraph after the bullets on page 9.



The last sentence of section 2 should be preceded by a restatement of the
definition of an attribute (or a reference to the structure) to provide some
context for the single value requirement.



The IANA considerations are inconsistent with the liberal use of extensibility
markers and text calling out possible future modifications, i.e., it seems
probable that there will be future actions for IANA.



The security considerations section will probably need some augmentation to
address effects of processing rules.  The current security considerations
should state what types of protections are required for this attribute, if any.



On page 9, /Housely/Housley/