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.