Re: ldapACI syntax and matching rules and more

[George_Robert_Blakley_III@tivoli.com]

Kurt et. al.:

Here are a few of my reactions:

>Also, I think KerberosId should be generalized.  I suggest
>referring to it as a UserId which allows any UTF-8 printable
>string.  This maps better onto authmeth's authzid "u:".
>If left as a KerberosId, it should not be a SHOULD.

This is "OK", but it needs to be possible to avoid name capture
in cases where different authentication mechanisms are supported to the
same directory.  I don't want someone to be able to use a
"foo-name" which is lexically the same as someone else's kerberosid
to get access to resources illicitly.

>The BNFs appear underspecified.  < printable string > allows
>too many characters which hinder (or disallow) parsing.  A
>< subject DN > should be an RFC 2253 DN string.  < oid >
>should be a RFC 2252 numericoid.

I'll defer to those more knowledgeable on these.

>How does a ACL granting access to an attribute types superior affect
>access the attribute type?  Ie: does granting access to 'name'
>allow access to 'cn'?

In the current draft the answer is no, and I'd prefer to keep it
this way in order to keep the ACL resolution algorithm simple.  If we
implement semantics like these, then we need to do bunch of type
resolution at access check time -- could be a performance problem.

>Why is ipAddress restricted to the "dotted-decimal string
>representation"?  This restricts ipAddress to IPv4 addresses.
>A reference to exact ipAddress form should be provided.
>[I'd like wildcard support... ie: 10.*.*.* or 10.0.0.0/8
>or 10.0.0.0:255.0.0.0]

Again, I don't want to do wildcarding because it requires a complicated
evaluation
code-path at access check time.  However I agree it would be good to have some
proposal
which supports IPv6.

--bob

Bob Blakley
Chief Scientist
Tivoli SecureWay Business Unit