Subject: Naming Re: Summary of IETF63 Kitten meeting

From: Nicolas Williams <[email-masked]>
Date: Tue, 27 Sep 2005 18:06:51 -0500

On Wed, Aug 03, 2005 at 07:02:46PM +0200, Jeffrey Altman wrote:
> * the need for including critical bit on attributes.  This is expected
>   to be easy for PKIX but it is not authenticated.

Specifically, we don't know whether a CA added a given extension blindly
or whether it asserts that the extension is "authenticated."

> * corrections to the use of kerberos cross realm transit paths.
>   cross realm transit path lists are not ordered.  they only provide
>   a list of the realms that were crossed.

Right.  We may need to distinguish between ordered and unordered
attribute/value sets.

> * There is concern that naming is an extremely broad and highly complex
>   problem.  Can it be done in a simple generic manner?

Can it?  I think so, but at a price; see below -- or is the question: is
this price worth paying?

> * The inquire function scares many people.

Sam in particular.

> * name attributes are being treated as tagged blobs.  This results in
>   problems both with how to represent dependencies between blobs and
>   how to handle in a generic manner how to extract sub-parts of a blob.

I had not considered dependencies between attributes.  This is not an
issue when name objects are treated as read-only objects, but it is when
the application sets attributes on a name object; we may need a
validation function.

> * there is a concern with how we can successfully compare names when
>   there are arbitrary sets of name attributes.   What is the canonical
>   name?   Part of the justification for this work is because there is
>   not always a canonical name that is static for all time.

The whole point of this is that there is no canonical name.  Name
comparison can continue to be done as usual under RFC2743.  Applications
that can take advantage of these extensions may make authorization
decisions based on individual (or sets) of attributes' values.

> * there needs to be a means of limiting the credentials provided to
>   an application based upon the needs of the application and the
>   qualities the credentials support.

Yes.

> * Denis Pikas wrote for CAT a draft to describe how to represent
>   group membership.  It can be found via google.  The wg should
>   review:
> 	draft-ietf-cat-xgssapi-acc-cntrl-03.txt

I have not yet reviewed it.

> * Review closely the saml attribute work

Yes.  I'll ask the SAML community within Sun to take a look.

> * There is a desire to support negative attributes.   In order to
>   do so there must be some means of indicating that for a given set
>   of positive and negative ACLs that all of the negative ACLs have
>   been included and none have been removed.
> 
> The wg ran out of time.  Clearly more discussion is required on the
> list.  Please read the draft.

And the negative attribute debate was not settled.  The antis seemed to
have the better arguments, as I recall, and IMO.

Nico
-- 

_______________________________________________
Kitten mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/kitten