Subject: [kitten] Proposed changes to http://tools.ietf.org/html/draft-ietf-kitten-gssapi-naming-exts-13

From: Nico Williams <[email-masked]>
Date: Fri, 16 Mar 2012 17:04:16 -0500

Sorry for proposing last minute changes.

I have three changes to propose, of which only one is substantive:

 - clarify section 6 to indicate that "primary attribute component" and
   "prefix" are the same thing

 - re-write the second to last paragraph of section 6

 - reserve a subset of the "local" attribute namespace

   ("local" attributes are ones with neither colons nor spaces)

   This is the substantive change.  Sam and I believe that it will
   eventually be desirable to have simple attribute names that
   are not URNs -- developers and users/sysadmins (to the
   extent that attribute names leak into user/admin interfaces)
   will want non-URN, user-friendly, portable and generic
   attribute names.

   Sam proposes to reserve local attribute names that have an
   at-sign.

   This change requires confirmation on the list, thus this post.

The proposed changes are as follows.

1) Clarification of "prefix":

    If an attribute name contains a space (ASCII 0x20), the first space
    separates the most significant or primary component of the name from
-   the remainder.  If there is no space, the primary component is the
-   entire name, otherwise it defines the interpretation of the remainder
-   of the name.s
+   the remainder.  We may refer to the primary component of the
+   attribute name as the attribute name's "prefix".  If there is no
+   space, the primary component is the entire name, otherwise it defines
+   the interpretation of the remainder of the name.s

2) Re-write of second to last paragraph of section 6:

-   A sufficient prefix of attribute names needs to be dictated by a
-   mechanism in order to describe the context.  For example it would be
-   problematic to represent SAML attribute names as the name format URI,
-   a space, and the remainder of the name.  A carefully crafted SAML
-   assertion could appear to be a name from another mechanism or
-   context.  Typically a SAML attribute name would include a prefix
-   describing the trust model and other context of the attribute name.
+   Since attribute names are split at the first space into prefix and
+   suffix, there is a potential for ambiguity if a mechanism blindly
+   passes through a name attribute whose name it does not understand.
+   In order to prevent such ambiguities the mechanism MUST always prefix
+   raw name attributes with a prefix that reflects the context of the
+   attribute.

3) Reserving local attribute names with at-signs in them:

    If the primary component contains an ASCII : (0x3a), then the primary
    component is a URI.  Otherwise, the attribute is a local attribute
    and the primary component has meaning to the implementation of GSS-
-   API or to the specific configuration of the application.  At this
-   time, local attribute names are not standardized; there is debate
-   about whether such standardization will be useful.  Any future
-   standardizations will need to balance potential problems resulting
-   from attribute names used before standardization.
+   API or to the specific configuration of the application.  Local
+   attribute names with an at-sign ('@') in them are reserved for future
+   allocation by the IETF.

Comments?

Nico
--

---

From: Leif Johansson <[email-masked]>
Date: Sat, 17 Mar 2012 07:45:56 +0100

> Comments?

FTR I'm fine with this.

---

From: Alexey Melnikov <[email-masked]>
Date: Sat, 17 Mar 2012 10:35:44 +0000

> +   allocation by the IETF.
I like these changes.

---

From: Leif Johansson <[email-masked]>
Date: Mon, 26 Mar 2012 09:41:23 +0200

On 03/17/2012 11:35 AM, Alexey Melnikov wrote:
>> - clarify section 6 to indicate that "primary attribute
>> component" and "prefix" are the same thing
>> 
>> eventually be desirable to have simple attribute names that are
>> not URNs -- developers and users/sysadmins (to the extent that
>> attribute names leak into user/admin interfaces) will want
>> non-URN, user-friendly, portable and generic attribute names.
>> 
>> If an attribute name contains a space (ASCII 0x20), the first
>> space separates the most significant or primary component of the
>> name from -   the remainder.  If there is no space, the primary
>> component is the -   entire name, otherwise it defines the
>> interpretation of the remainder -   of the name.s +   the
>> remainder.  We may refer to the primary component of the +
>> attribute name as the attribute name's "prefix".  If there is no 
>> +   space, the primary component is the entire name, otherwise it
>> defines +   the interpretation of the remainder of the name.s
>> 
>> -   A sufficient prefix of attribute names needs to be dictated
>> by a -   mechanism in order to describe the context.  For example
>> it would be -   problematic to represent SAML attribute names as
>> the name format URI, -   a space, and the remainder of the name.
>> A carefully crafted SAML -   assertion could appear to be a name
>> from another mechanism or -   context.  Typically a SAML
>> attribute name would include a prefix -   describing the trust
>> model and other context of the attribute name. +   Since
>> attribute names are split at the first space into prefix and +
>> suffix, there is a potential for ambiguity if a mechanism
>> blindly +   passes through a name attribute whose name it does
>> not understand. +   In order to prevent such ambiguities the
>> mechanism MUST always prefix +   raw name attributes with a
>> prefix that reflects the context of the +   attribute.
>> 
>> 
>> If the primary component contains an ASCII : (0x3a), then the 
>> primary component is a URI.  Otherwise, the attribute is a local
>> attribute and the primary component has meaning to the
>> implementation of GSS- -   API or to the specific configuration
>> of the application.  At this -   time, local attribute names are
>> not standardized; there is debate -   about whether such
>> standardization will be useful.  Any future -   standardizations
>> will need to balance potential problems resulting -   from
>> attribute names used before standardization. +   API or to the
>> specific configuration of the application.  Local +   attribute
>> names with an at-sign ('@') in them are reserved for future +
>> allocation by the IETF.
>> 
>> Comments?
> I like these changes.
> 

Anyone else have an opinion. This is the only thing holding this
document up and I'd like to push a final version for IETF LC this
week.

	Cheers Leif