On the first resolution, that looks sufficient. You reference both the
need for ASN.1, and the need for clearence.
On the second issue, I may have been unclear.
It is not obvious to me that all uses of this attribute must inherently
be situations in which there is only one sponsor.Thus, the restriction
to one occurrence of the field seems to be a policy restriction, rather
than a technical once.
If there is a tehcnical reason why it must occur once, then it would be
good to say that. (For example, if receivers could not properly process
a message with multiple such fields.) If there is no technical problem
with multiple occurrences, then even if we can not see why we need it
now, I don't understand why the document outlaws it.
Yours,
Joel
Sean Turner wrote:
Joel,
Thanks for your timely review.
spt
Joel M. Halpern wrote:
I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
Please resolve these comments along with any other Last Call comments
you may receive.
Document: draft-turner-clearancesponsor-attribute-01.txt
Clearance Sponsor Attribute
Reviewer: Joel M. Halpern
Review Date: 3-August-2009
IETF LC End Date: 14-August-2009
IESG Telechat date: N/A
Summary: This document is almost ready for publication as an
Informational RFC.
Minor issues: In trying to balance versatility and specificity, the
introduction states that the attribute defined in this document may be
used in X, Y, or "locations that support attributes." Given that
almost all our protocols support "attributes" for some meaning of the
word, I think a somewhat better description is called for. It may
just suffice to say "locations or protocols that support ASN.1
definitions of attributes of entities which may conceptually have been
cleared by (some suitable words)." (Yes, I see that RFC 3281bis uses
the same terminology. It seems confusing to me.)
How about I change the intro as follows (with other comments I've
also received mixed in):
OLD:
This document specifies the clearance sponsor attribute. This attribute
may be included in public key certificates [RFC5280], attribute
certificates [RFC3281bis], directories [X.500]/[RFC4512], or locations
that support attributes. These attributes may be used in authorization
decisions
NEW:
This document specifies the clearance sponsor attribute. This attribute
may be included in locations or protocols that support ASN.1 attribute
definitions to indicate the entity that sponsored the clearance. This
attribute is only meaningful when the clearance attribute [RFC3281bis]
is also included.
This attribute may be used in authorization decisions. For example, a
web server deciding whether to allow a user access could check that the
clearance sponsor present in the user's certificate is on an "approved"
list. The web server could also check that the included clearance
sponsor is on an "approved" list to issue the included clearance.
NOTE: This document does not provide LDAP equivalent schema
specification as this attribute is initially targeted at public key
certificates [RFC5280] and attribute certificates [RFC3281bis]. This is
left to a future specification.
Nits/editorial comments: Is it really true that world-wide clearances
can always be sponsored by only one entity? The restriction to one
value seems to be a policy statement about a particular approach, so I
wonder if it is correct to capture that in the object definition? Or
is this a US Government only definition? (It doesn't say that, so I
am assuming it has broader applicability than that.)
We're not advocating a world-wide clearance. The model I've dealt with
numerous time wrt security policies is that the security policy is
defined for an organization and that organization has many
sub-organizations. When an access control decision is made the decision
maker sometime wants to know who sponsored the clearance holder. The
clearance attribute doesn't indicate who sponsored the clearance holder
so this attribute was defined to address this need.
It's not just US Government specific. This model actually holds for
many governments and other organizations that have implemented security
policies.
_______________________________________________
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
