Subject: subschemaSubentry in PKI/PMI LDAP schema I-Ds

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Tue, 12 Nov 2002 20:15:44 -0800

Both the PKI and PMI LDAP Schema I-Ds contain a similar
worded section called "Subschema Publishing LDAPv3". Both
imply that a server has one and only one subschema subentry
and that this subentry is discoverable by reading the
subschemaSubentry attribute held in the Root DSE.

The X.500 model, as used in LDAP, clearly allows multiple
subschema subentries to be present, each controlling a subtree
of entries.  In fact, each entry held by the server could
be controlled a different subschema subentry as indicated
by the entry's subschemaSubentry attribute.

It is noted that RFC 2251 has a bug regarding the root DSE's
subschemaSubentry attribute.  To avoid this bug, PKI/PMI
specification should clearly state that the schema controlling
a particular entry is to be discovered by reading that entry's
subschemaSubentry's attribute. (Just as one would in X.500).

Kurt

---

From: David Chadwick <[email-masked]>
Date: Thu, 14 Nov 2002 20:50:59 +0000

Kurt

your point is noted. However it does not work. Since the client is
wanting to search the directory for particular PKI attributes, it does
not necessarily know the entry that they are contained in. Therefore it
cannot read the entry to find its subschema subentry before the entry
has been found. For this reason I suggest that the subschemaSubentry
attribute in the root DSE be made multivalued, so that the client can
find out if the matching rules are supported prior to it issuing the
extensible Search.

David

-- 
*****************************************************************

David W. Chadwick, BSc PhD
Professor of Information Systems Security
IS Institute, University of Salford, Salford M5 4WT
Tel: +44 161 295 5351  Fax +44 01484 532930
Mobile: +44 77 96 44 7184
Email: [email-masked]
Home Page:  http://www.salford.ac.uk/its024/chadwick.htm
Research Projects: http://sec.isi.salford.ac.uk
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
PGP Key ID is 0xBC238DE5

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

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 14 Nov 2002 13:04:08 -0800

At 12:50 PM 2002-11-14, David Chadwick wrote:
>not necessarily know the entry that they are contained in.

To issue this search, the client must have a baseObject.  It should
look at the subschemaSubentry attribute in this baseObject.

>Therefore it
>has been found.

While certainly entries subordinate to the baseObject may be
controlled by a different subschema, at least the client nows
the filter is valid at the baseObject.

>For this reason I suggest that the subschemaSubentry

Assume that a server listed two subschemaSubentry values in the
root DSE, one listing this matching rule use and one not.  How
does the client determine which subschema controls the entry
referenced by baseObject of its extensible search?

Without reading the baseObject's subschemaSubentry, it cannot
reliably determine which subschema applies.

Personally, I think the client should just issue the operation
without discovery...  worse case the assertion is Undefined.

Kurt

---

From: David Chadwick <[email-masked]>
Date: Thu, 14 Nov 2002 21:42:59 +0000

> look at the subschemaSubentry attribute in this baseObject.

Agreed. I will change the next version to say "look in the baseObject"

David

---

From: Michael Ströder <[email-masked]>
Date: Thu, 14 Nov 2002 23:11:54 +0100

David Chadwick wrote:
> attribute in the root DSE be made multivalued,

-1

It will cause nothing than grief!

Ciao, Michael.

---

From: Chris Davenport <[email-masked]>
Date: Thu, 14 Nov 2002 15:55:28 -0600

The client could easily restrict its search to only those objects whose 
subschemaSubentry value matched one of the values listed in the root DSE that 
support the matching rules.

	Chris Davenport
	Directory & Security Engineer
	ISS Hewlett-Packard Corp.

---

From: "Steven Legg" <[email-masked]>
Date: Fri, 15 Nov 2002 10:03:18 +1100

Kurt & David,

> the filter is valid at the baseObject.

The client can also discover if, and what, other subschema applies
within the scope of the subtree of the baseObject by issuing a subtree
search for subentries with objectClass=subschema.

> reliably determine which subschema applies.

Not that it really matters anyway. In the X.500 world view the absence
of a matching rule definition from a subschema subentry is not an
indication of a lack of capability on the part of the server mastering
the subschema subentry. Nor is the presence of a matching rule definition
a guarantee that a server supports the matching rule since the subschema
administrative area could span multiple DSAs, or be replicated to
other DSAs, each with their own particular set of supported features.

> without discovery...  worse case the assertion is Undefined.

I agree. I expect most clients won't bother to do schema discovery, no
matter what we say. In practice it comes down to a server deployment
issue.  One should choose a directory server to hold PKI that supports
the matching rules one expects will be used, and entries should not be
replicated to directory servers that do not also support those matching
rules.

Regards,
Steven

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 14 Nov 2002 17:36:35 -0800

At 01:55 PM 2002-11-14, Chris Davenport wrote:
>subschemaSubentry value matched one of the values listed in the root DSE that support the matching rules.

Sorry, no.  The client cannot determine, based upon the contents of
the subschemaSubentry attribute held at the root DSE, which entries
are controlled by the named subschema subentries.

The only reliable mechanism for the client to determine which
subschema controls a particular entry is reading that entry's
subschemaSubentry attribute.

Listing multiple values in the root DSE subschemaSubentry is
problematic.  Short summary of LDAPBIS discussions:  The client
would not be able to determine which subschema applied to the
root DSE itself.  The client cannot determine which values apply
elsewhere without out looking elsewhere.  Lastly, the
subschemaSubentry attribute is defined as being single valued.
(Those desiring details should check out the LDAPBIS archives).

Anyways, my primary comment here is that PKIX should be carefu
not to rely on subschema subentries for discover of server-specific
capabilities.  Subschema subentries are for discover of schema
policy.  Policy information doesn't necessarily reflect a
server's capabilities.  Values of attributes held in the
root DSE (e.g., supportedExtension, supportedControl,
supportedSASLmechanisms, supportedFeatures [coming soon])
should be used for server capability discover.

Kurt

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 14 Nov 2002 21:41:08 -0800

>are controlled by the named subschema subentries.

I should clarify this a bit.

To perform operations on a set of entries, a client may need to
discover the schema controlling these entries.  That is, the
question the client is asking "what subschemas controls these
entries?".

While the client certainly read the root DSE subschemaSubentry
attribute and then by issuing a search for each listed value
determine which entries are controlled by which listed values.
But this is only answers the question if and only if the root
DSE lists all possible subschema subentries.  And, because the
client cannot assume that all possible subschema subentries are
listed,  this approach can fail.  Also, the list may be quite
large.  So, even where this approach might work, it also may
be quite expensive.

A simpler approach is just to request the return of the
subschemaSubentry attribute with each entry in the set.

Of course, most clients don't bother with schema discovery...

Kurt