Subject: [Gen-art] review: draft-turner-clearancesponsor-attribute-01.txt

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 03 Aug 2009 18:30:44 -0400

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.)

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.)

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 12 Aug 2009 14:57:44 -0400

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:
>> 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.
> 
> 
>> 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.
> 
> 
> 
>

---

From: Sean Turner <[email-masked]>
Date: Wed, 12 Aug 2009 14:40:29 -0400

Joel,

spt

OLD:

NEW:

---

From: Sean Turner <[email-masked]>
Date: Thu, 27 Aug 2009 08:58:44 -0400

> 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.

>>> introduction states that the attribute defined in this document may 
>>> be used in X, Y, or "locations that support attributes."  Given that 
>>> 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.)
>>
>>> 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.
>>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 27 Aug 2009 09:47:52 -0400

Your reasoning on multiple sponsors (or the lack thereof) makes sense.
Would it be sensible and practical to add a clause in the text where it 
says that only one is allowed, along the lines of ", as distinct sponsor 
should be represented in distinct certificates" (or other wording to 
that effect?)

Yours,
Joel

Sean Turner wrote:
> Joel M. Halpern wrote:
>> On the first resolution, that looks sufficient.  You reference both 
>> the need for ASN.1, and the need for clearence.
>>
>> 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.
> 
>>>> 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 
>>>> been cleared by (some suitable words)."  (Yes, I see that RFC 
>>>> 3281bis uses the same terminology.  It seems confusing to me.)
>>>