Re: ldapACI syntax and matching rules and more

[Ellen Stokes <stokes@austin.ibm.com>]

Responses embedded and prefaced by (EJS)
Ellen

At 06:44 PM 3/15/00 -0800, Kurt D. Zeilenga wrote:
> Just did very quick read of the latest draft.  A few comments
> and questions.
>
> Please note that I (still) believe ldapACI should have a syntax
> which requires values to conform to the BNF described by Section 6.1
> of the draft and that the equality matching rule be "syntax
> aware".  In particular, the equality matching rule should
> treat any two ACI which have same meaning but different form
> to be equal.  That is:
>
> ldapACI:1.2.3.4#subtree#grant;r,s,c;attribute:X#group#cn="Dept, XYZ",c=US
> ldapACI:1.2.3.4#subtree#grant;r,s,c;attribute:x#group#CN="dept, xyz",c=us
> ldapACI:1.2.3.4#subtree#grant;r,s,c;attribute:x#group#cn=Dept\, XYZ,c=US
> ldapACI:1.2.3.4#subtree#grant;c,s,r;attribute:xx#group#cn="Dept, XYZ",c=US
> ldapACI:1.2.3.4#subtree#grant;r,s,c;attribute:1.1.1#group#cn="Dept, XYZ",c=US
>
> where x is defined as
>   ( 1.1.1 NAME ( 'x' $ 'xx' ) SUP 'name' )
> should all be considerred equal.  CaseIgnoreString does cut it...

(EJS)  I agree the above examples should be case insensitive.  I'll add the
matching rule caseIgnoreString.


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

(EJS)  If consensus is to retain familyOID, then, yes, it should be
specified in the BNF as <numericoid>; otherise it just goes away.

I agree that <subjectDN> in the BNF is underspecified.  It needs to
look something like:
<subjectDN>::= <distinguishedName> |  "public" | "this" |
               <kerberosID> | <ipAddress>
where we reach agreement on how 'handle' kerberosID per your
note and Bob's response, and also define the syntax for ipAddress
(another one of your comments).  I'll handle those two in a separate
note.


> A few questions:
>
> 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'?

(EJS) No, schema hierarchy will be independent of access control
inheritance for now; we should look at this again in the future after
we get this draft to RFC.

> I see that ACLs on attribute subtypes (cn;lang-US) are disallowed.
> Is this intentional?  If so, why?  If not, any syntax issues due
> to the attribute description's ';'(s) (could have more than one).

(EJS) It was not our intention to disallow (I didn't even think we stated
explicitly we disallowed it).  So, I'll add wording to make sure it's
understand that it is allowed.  I'll also change some of the separators
in the BNF so there is not misunderstanding of parsing when ';' is used.
Good catch.


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

(EJS) Another good catch.  We need to support IPv6.  I'll put out
a BNF for ipAddress to cover this.  I think we also need wildcarding, etc.
I think perhaps a good starting point here might be the BNF by Netscape
for support of ipAddress in access control.  I''m open to other suggestions
as well.

> Kurt