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/