Subject: Re: comments on draft-ietf-pkix-ldap-schema-01.txt

From: [email-masked]
Date: Mon, 23 Oct 2000 06:10:39 -0400

David,

Thanks for the comments - I've added further comments below prefaced with
TJH>

Regards,
Tim Hahn

Internet: [email-masked]
Internal: Timothy Hahn/Endicott/IBM@IBMUS or IBMUSM00(HAHNT)
phone: 607.752.6388     tie-line: 8/852.6388
fax: 607.752.3681

"David Chadwick" <[email-masked]> on 10/21/2000 11:08:25 AM

Please respond to [email-masked]

To:   Timothy Hahn/Endicott/IBM@IBMUS, <[email-masked]>
cc:   [email-masked]
Subject:  Re: comments on draft-ietf-pkix-ldap-schema-01.txt

From:               [email-masked]
To:                 [email-masked]
Subject:            comments on draft-ietf-pkix-ldap-schema-01.txt
Date sent:          Thu, 21 Sep 2000 14:18:15 -0400

> Greetings,
Tim
Apologies for the delay

>
> Section 2:
> ----------
> I would prefer that the phrase "use the subschemasubentry attribute in
> the root DSE" be changed to "use the subschemasubentry attribute from
> the namingContext entry which is found in the root DSE".

I disagree with your proposed change for the following reasons:

firstly the namingContext entry is not found in the root DSE, but
rather a pointer to the namingContext entry is found in the root
DSE. But this does not help, as the subschema subentry itself is
only mandatorily pointed to from the rootDSE, and not from the
namingContext entry. This is assuming I have read 2251 correctly,
viz:

If the server masters directory entries under one
   or more schema rules, there may be any number of values
of the
   subschemaSubentry attribute in the root DSE.

TJH> I should have used the phrase "namingContext attribute in the
TJH> root DSE".  The trouble I see with multiple values in the
TJH> subschemasubentry attribute in the root DSE is that because
TJH> attributes contain un-ordered sets of values, how does one
TJH> correlate a specific subschemasubentry value with the
TJH> particular namingContext value (DN) under which the client
TJH> intends to add, modify, or delete an entry?  Thus, I still
TJH> feel it is better to obtain the subschemasubentry value (DN)
TJH> by first getting the namingContext value (DN) from the
TJH> root DSE, then performing a base search against that DN
TJH> to get the subschemasubentry attribute value.  It's not
TJH> guaranteed that entries below that "namingContext entry"
TJH> aren't in yet another namingContext (in some other server)
TJH> but getting the subschemasubentry value in this fashion
TJH> would give you a much better chance of getting the schema
TJH> that governs the particular sub-tree (namingContext)
TJH> that the application is interested in interacting with.
TJH> Multiple subschemasubentry values in the root DSE is just
TJH> confusing because they aren't "correlated" to the
TJH> namingContext attribute values.

>
> Section 3.2:
> ------------
> In the BNF for "GeneralName", a single whitespace character appears
> (e.g. "rfc822 +").  Was this intentional?  It seems out of

I dont really mind either way here. I will let Steven be the
authoritative voice on this

> place/misleading.
>
> Editor's note on AuthorityKeyIdentifier:
> ----------------------------------------
> Seems to me that authority issuer name and authority certificate
> serial number could be useful.

What we really need is some LDAP server vendor (IBM??) to
implement these matching rules and to give some feedback about
which fields are really useful for users to use. At the moment we
can only guess at what people will want to use in practice.

>
> Section 4.1:
> ------------
> In the BNF for "CertificateListExactAssertion", the "$" after "Time"
> is OPTIONAL, correct?  It should only be needed if
> "DistributionPointName" is specified, I think.

Yes we could change the ABNF to put the  $ inside the DP
construct.

>
> Section 5 - ISSUE:
> ------------------
> I am not qualified to provide an opinion on this one.
>
> Section 5.3.2 - first Editor's note:
> ------------------------------------
> I would like to see attribute type names (not just OIDs) be allowed.

The AC profile specifies that the attribute MUST be identified by its
OID in the AC. Therefore if the user interface allows attribute
names to be presented by the user, something has to map this into
the correct OID, otherwise a wrong AC will be found by the LDAP
server. If we specify an OID in the matching rule, then it must be
the user interface that does the mapping. If we allow string names
in the matching rule, it must be the server that does the mapping.

What do you think?

TJH> I think that pushing OID <-> friendlyName mappings onto
TJH> clients is a bad think to rely on.  Anything we can do
TJH> to lessen complex schema interaction by client programs
TJH> is a good thing IMHO.

>
> Section 5.3.2 - second Editor's note:
> -------------------------------------
> I would find 5.3.9 Time Specification Match to be useful.  I don't
> have experience with the others.
>

Thanks for that.

David
>
> Regards,
> Tim Hahn
>
> Internet: [email-masked]
> Internal: Timothy Hahn/Endicott/IBM@IBMUS or IBMUSM00(HAHNT)
> phone: 607.752.6388     tie-line: 8/852.6388
> fax: 607.752.3681

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

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

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