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

From: "Jim Sermersheim" <[email-masked]>
Date: Fri, 28 Jul 2000 17:41:35 -0600

>>> "Steven Legg" <[email-masked]> 7/28/00 1:24:34 AM >>>
<snip>
>
>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.

That's my fault. I see your point, I'm also in favor of defining a new OID and matching rule (or rules). I'm told of a WG meeting some time back (Chicago maybe?) where there was an overwhelming consensus NOT to define new syntax OIDS. If this is still the case, a lesser evil might be to use Octet String syntax, and just force exact matching (eck).

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

true

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

ok.

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

Right, and if UTF8String is not defined, we could change it to UTF8String and add:

UTF8String ::= OCTET String -- one or more ISO 10646 characters.

>> 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 {
>
<snip>
>.. has the same problems as previously mentioned.

I think we hadn't scrubbed the controls and extensions yet. Thanks for these.

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

This makes more sense.

>>
>>       }
>
>Ditto the usual problems.

yes

>> The server will respond to this with an LDAPMessage
>> containing the ExtendedResponse which is a rights list.
<snip>

>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 {
<snip>

Same response.

Thanks. Jim

---

From: "David Chadwick" <[email-masked]>
Date: Sun, 30 Jul 2000 13:16:59 +0100

>  I'm also in favor of defining a new
> OID and matching rule (or rules). I'm told of a WG meeting some time
> back (Chicago maybe?) where there was an overwhelming consensus NOT to
> define new syntax OIDS. If this is still the case, a lesser evil might
> be to use Octet String syntax, and just force exact matching (eck).
> 

This is part of a larger issue that should be covered by a Shema 
BOF if there is one. I have written a PKIX id that has defined 
matching rules and syntaxes for certificates and CRLs etc. I dont 
think we can dodge this issue in general. Whilst we dont want to 
unnecessarily define extra syntaxes for the sake of it, we do want 
to allow users to have sensible and easy ways of matching on 
complex attributes (such as ACI and certificates)

David

***************************************************

David Chadwick
IS Institute, University of Salford, Salford M5 4WT
Tel +44 161 295 5351  Fax +44 161 745 8169
Mobile +44 790 167 0359
Email [email-masked]
Home Page  http://www.salford.ac.uk/its024/chadwick.htm
Understanding X.500  http://www.salford.ac.uk/its024/X500.htm
X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm
Entrust key validation string MLJ9-DU5T-HV8J

***************************************************

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Sun, 30 Jul 2000 05:35:35 -0700

My opinion is that if you want more than BLOB semantics, then
you need to define a new syntax.  However, new syntaxes should
have a string representation.

---

From: "David Chadwick" <[email-masked]>
Date: Mon, 31 Jul 2000 15:40:00 +0100

Date sent:      	Sun, 30 Jul 2000 05:35:35 -0700
To:             	[email-masked]
From:           	"Kurt D. Zeilenga" <[email-masked]>
Subject:        	Re: Syntax Issues
Copies to:      	"Jim Sermersheim" <[email-masked]>, <[email-masked]>,
       	<[email-masked]>

> have a string representation.

Agreed. This is what has been done in the past, and I have done for 
certificates and CRLs
David

David Chadwick