Re: Summary of group discussion

Howard Chu wrote:
> 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.

OK, it's not the *only* unambiguous thing. We could also just use another RDN 
delimiter (COMMA) instead of the SHARP in the current definition.

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