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

[Leif Johansson <[e-mail]>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 03/17/2012 11:35 AM, Alexey Melnikov wrote:
> On 16/03/2012 22:04, Nico Williams wrote:
>> 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?
> 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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk9wHaMACgkQ8Jx8FtbMZndLKwCfRl2NWcP+Gkih5sIx1+8OykqI
+ZgAnip2ksJjeGNNlyXS7DyRDn2dPBzA
=Hx5m
-----END PGP SIGNATURE-----