Subject: Syntax Issues in <draft-ietf-ldapext-acl-model-06.txt>

From: "Steven Legg" <[email-masked]>
Date: Fri, 28 Jul 2000 17:26:58 +1000

Ellen, Rob, et al,

In perusing <draft-ietf-ldapext-acl-model-06.txt> I noticed some
problems with the ASN.1 usage.

> 4.  The Access Control Information Attribute (ldapACI)
>
> The access control information attribute, ldapACI, is
> defined as:
>
>  (<OID to be assigned>
>    NAME      'ldapACI'
>    DESC      'ldap access control information'
>    EQUALITY  caseIgnoreMatch
>    SYNTAX    directoryString
>    USAGE     directoryOperation
>  )

The ldapACI SYNTAX and the binary representation of values are not
compatible. Values of any attribute declared to be of DirectoryString
syntax would be expected to have a BER encoding of a CHOICE of string
types rather than a SEQUENCE. Also, the caseIgnoreMatch matching rule
is meaningless if applied to a SEQUENCE type.

Either define a new syntax OID and find/define a compatible matching
rule, or lose the binary representation. I'd prefer the former to the
latter.

The SYNTAX field should also be an OID rather than a type name.

> 4.1.2  ACI Binary Representation
>
>  The following ASN.1 data type is used to represent this
>  syntax when transferred in binary form:
>
>  ldapACI ::= SEQUENCE {

ASN.1 type names must start with an uppercase letter so ldapACI
should be LDAPACI or LdapACI.

>       scope      ENUMERATED {
>             entry       (0),
>             subtree     (1) },
>       rights     SEQUENCE OF CHOICE {
>             grant       [0] Permissions,
>             deny        [1] Permissions },
>       attr       CHOICE {
>             all         [0] NULL,
>             entry       [1] NULL,
>             attributes  [2] SEQUENCE OF Attribute },
>       subject    SEQUENCE {
>          authnLevel   CHOICE {
>             any      [0] NULL,
>             simple   [1] NULL,
>             sasl     [2] CHOICE {
>                any       [0] NULL,
>                mechanism [1] LDAPString -- from [LDAPv3]
>             }
>          },
>       subject    CHOICE {
>             dn          [0] DN,
>             user              [1] utf8String

The type name "utf8String" can't be right. I would guess that it should
be UTF8String but I haven't got the relevant standard handy to confirm this.

> 11.1.1  Request Control

>  getEffectiveRightsRequest ::= SEQUENCE {

Should read:

	GetEffectiveRightsRequest ::= SEQUENCE {

>    effectiveRightsRequest   SEQUENCE OF SEQUENCE {
>        whichObject   ENUMERATED {
>                      LDAP_ENTRY (1),
>                      LDAP_SUBTREE (2)

Identifiers in ENUMERATED lists must start with lowercase letters
and cannot contain underscores.

Try,

	ldap-entry (1),
	ldap-subtree (2)

or just,

	entry (1),
	subtree (2)

like in the BNF.

>                      },
>        subject       <see <subject > in BNF> | "*"

This is meaningless as an ASN.1 type definition. I assume it is
intended to be a UTF8String whose contents are the string encoding
of a subject according to the BNF, or "*". Otherwise, expose the
subject CHOICE as a named ASN.1 type and use that.

> 11.1.2  Response Control

>  getEffectiveRightsResponse ::= {

Should read:

	GetEffectiveRightsResponse ::= SEQUENCE {

>    result  ENUMERATED {
>       success                       (0),
>       operationsError               (1),
>       unavailableCriticalExtension (12),
>       noSuchAttribute              (16),
>       undefinedAttributeType       (17),
>       invalidAttributeSyntax       (21),
>       insufficientRights           (50),
>       unavailable                  (52),
>       unwillingToPerform           (53),
>       other                        (80)
>       }
>  }

>  PartialEffectiveRightsList ::= SEQUENCE OF SEQUENCE {
>     rights        <see <rights> in BNF>,
>     whichObject   ENUMERATED {
>                       LDAP_ENTRY (1),
>                       LDAP_SUBTREE (2)
>                       },
>     subject       < see <subject> in BNF >
>  }

... has the same problems as previously mentioned.

> 12.1  LDAP Get Effective Rights Operation
>
> ldapGetEffectiveRightsRequest ::= [APPLICATION 23] SEQUENCE
> {
>    requestName      [0] <OID to be assigned>,
>    requestValue     [1] OCTET STRING OPTIONAL }

I suggest describing the extended operation the way
draft-ietf-ldup-framing-00.txt does it. I've paraphrased below.

   An LDAPv3 Extended Request is defined in [LDAPv3] as follows:

      ExtendedRequest ::= [APPLICATION 23] SEQUENCE {
          requestName    [0] LDAPOID,
          requestValue   [1] OCTET STRING OPTIONAL
      }

   The requestName portion of the GetEffectiveRightsRequest must be the
   OID <OID to be assigned>.

   The requestValue of the GetEffectiveRightsRequest must be set to the
   BER-encoding of the following:

>    requestValue ::= SEQUENCE {

      GetEffectiveRightsRequestValue ::= SEQUENCE {

>       targetDN  LDAPDN,
>       updates   SEQUENCE OF SEQUENCE {
>                   whichObject   ENUMERATED {
>                                   LDAP_ENTRY (1),
>                                   LDAP_SUBTREE (2)
>                                   },
>                   attr SEQUENCE {
>                      attr   <see <attr> in BNF >
>                      },
>                   subject   < see <subject> in BNF > | "*"
>                   }
>       }

Ditto the usual problems.

> The server will respond to this with an LDAPMessage
> containing the ExtendedResponse which is a rights list.
>
> ldapGetEffectiveRightsResponse ::= [APPLICATION 24] SEQUENCE
> {
>    COMPONENTS OF LDAPResult,
>    responseName     [10] <OID to be assigned> OPTIONAL,
>    effectiveRights  [11] OCTET STRING OPTIONAL }
>

I suggest ...

   An LDAPv3 Extended Response is defined in [LDAPv3] as follows:

      ExtendedResponse ::= [APPLICATION 24] SEQUENCE {
          COMPONENTS of LDAPResult,
          responseName  [10] LDAPOID OPTIONAL,
          response      [11] OCTET STRING OPTIONAL
      }

   The responseName of the GetEffectiveRightsResponse must be the OID
   <OID to be assigned>.

   The response of the GetEffectiveRightsResponse is set to the BER-
   encoding of:

>    effectiveRights ::= SEQUENCE OF SEQUENCE {
>       rights        <see <rights> in BNF>,
>       whichObject   ENUMERATED {
>                        LDAP_ENTRY (1),
>                        LDAP_SUBTREE (2)
>                        },
>       subject       < see <subject> in BNF >
>    }

Ditto the usual problems.

Regards,
Steven