[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: [ldapext] Summary of group discussion

Keutel, Jochen wrote:

Hello Andrew,
    I'm definitely late in commenting this ... I just missed the
discussion in September, sorry.

One thing I'd like to add: X.501 defines the X.500 access control
schema. Esp. it defines:

ACIItem ::= SEQUENCE {
    identificationTag DirectoryString { ub-tag },
    precedence Precedence,
    authenticationLevel AuthenticationLevel,
    itemOrUserFirst CHOICE {
      itemFirst [0] SEQUENCE {
        protectedItems ProtectedItems,
        itemPermissions SET OF ItemPermission },
      userFirst [1] SEQUENCE {
        userClasses UserClasses,
        userPermissions SET OF UserPermission } } }

UserClasses ::= SEQUENCE {
    allUsers [0] NULL OPTIONAL,
    thisEntry [1] NULL OPTIONAL,
    name [2] SET SIZE (1..MAX) OF NameAndOptionalUID OPTIONAL,
    userGroup [3] SET SIZE (1..MAX) OF NameAndOptionalUID OPTIONAL,
      -- dn component shall be the name of an
      -- entry of GroupOfUniqueNames
    subtree [4] SET SIZE (1..MAX) OF SubtreeSpecification OPTIONAL }

The referenced NameAndOptionalUID is defined in X.520:

NameAndOptionalUID ::= SEQUENCE {
    dn DistinguishedName,
    uid UniqueIdentifier OPTIONAL }

So here we have a unique identifier twice: Inside the groupOfUniqueNames
and in the NameAndOptionalUID structure. Both are not used in the real
world ... (at least I've never seen it).

The problem I see: Products using this ACI schema (esp. X.500 based
products as e.g. Siemens DirX or CriticalPath) do only work if the
userGroup component of UserClasses is really a groupOfuniqueNames. Of
course you can put the DN of a groupOfNames or groupOfEntries or ...
into this field - but ACI checking won't work.

So I see 2 points:

1. Shall X.501 be changed as well?
In X.501(1993), which is the spec that LDAP conforms to, section 16.4.2.5 "Determining group membership" clause (b) says
The entry named by the userGroup specification must be an instance of the object class groupOfNames or groupOfUniqueNames. 

So from that perspective, we're not completely cutting things off.


2. Shall this ACI issue be mentioned in your draft?
The other alternative is to fix the LDAP definition of the NameAndOptionalUID syntax, so that it's actually usable in LDAP.
Given the bass-ackward RDN ordering that was chosen for the string representation of DNs in LDAP, the only unambiguous thing to do with these is to put the x500uniqueIdentifier *first* in the string. So revise RFC4517's definition 3.3.21 

	NameAndOptionalUID = [BitString] distinguishedName
The SHARP character in the current definition is extraneous since the BitString definition is already fully delimited. 

If we fix this syntax then I would drop all objections relating to its use.
--
  -- Howard Chu
  CTO, Symas Corp.           http://www.symas.com
  Director, Highland Sun     http://highlandsun.com/hyc/
  Chief Architect, OpenLDAP  http://www.openldap.org/project/
_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www.ietf.org/mailman/listinfo/ldapext