Joel M. Halpern wrote:
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.
I believe there will be only one sponsor included in a certificate*.
The clearance sponsor in the certificate vouches for the mapping of the
subject name to the person to the included clearance. The CA's
responsibility is then that the clearance sponsor has been validated,
and that the public key really corresponds to the subject that the
clearance sponsor identifies. Because the clearance sponsor is included
in the certificate, this vouching has to happen before the certificate
is issued. The CA needs to get the nod from one source. We don't want
to get in to the case were two sources say yes it's her and that's her
clearance, but voucher A did process X which isn't as thorough as
voucher B who did process Y.
Another way to think about this is terms of CA vouching for the binding
of the key and name. There's only one that can do it because they're
applying their signature to the certificate. If another CA also wants
to vouch then it issues another certificate.
spt
* I was unaware of the extra work necessary to claim that the attribute
could be included in an LDAP directory (i.e., the schema, the transfer
syntax, etc.) so we're targeting this attribute at certificates.
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
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art
