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/