comments on:draft-ietf-ldapext-sigops-01.txt

[Alan Lloyd <Alan.Lloyd@OpenDirectory.com.au>]

<draft-ietf-ldapext-sigops-01.txt>


Overall - this document prescribes many mechanisms which in the scheme
of secure and auditable directory systems have very little value.
The document prescribes signatures on updates which includes deletes (-
and should include renames) but resolves the fact that as these objects
dissappear by these operations, it prescribes creating arbitarilly named
"zombie objects" to represent their history.

The thrust of the proposal is to put update logs on every entry and with
these log records to be a signed (and possibly non authenticated by
anyone)the LDAP operation that did the update. This means that entries
will grow! This means that in searches that some implementations (not
ours) could end up scanning the log records in normal search operations
- ie they have to test all attribute types to find equivalence/non
equivalence to see if they are the ones they want. Just emagine a few
million entries with 10 times the attribute count because they got
updated over time - the server would go slower and slower ( But not ours
because we use smart indexing of course..)


It seems a little pointless that with the commercial and cost related
R&D effort effort which is put in to secure distributed auditing
directory mechanisms - that we try to do that with " growing directory
entries" and randomly named entries which get generated on the fly and
no doubt written back into the directory itself . 

If one deletes or modifies these zombies what happens them, do we
zombified zombies and so on. And are these directories using this
approach filling up with generations of zomby objects with their own
audit trails?

In addition the spec says that the signature process is not vetted re
authenticating  the User - this area is convenently passed over to TLS
which (in all the TLS documents I have read) seems to pass off User
authentication to something else which will probably be SASL, that will
have to use X.509 - and at the end of the day these X.509 structures
will have to be carried and searched for and loaded the directory in
this Audited environment, with secure signed directory operations such
as DAP. Which by the way can sign and authenticate any of its protocols
and operations....

I dont like lots of definition with little utility that leaves the very
requirement which should be addressed ie. - authenticated signed
operations and the key management issues, unresolved. And in addition
has a good chance of taking out every LDAP servers performance (except
ours).

I think that LDAP has reached its final frontier with this area and that
those involved with the implementation of LDAP servers and X.500 DSAs
need to look at the server, distribution, authentication, key management
and information management issues of the system BEFORE one puts forward
a set of signing mechanisms and a set of logs and auditable objects
(such as zombies) that on the face of it do very little and leave many
problems unresolved.

Does any server or DSA supplier out there want to sell systems that fill
up with zombie objects which are arbitaraly named and get slower and
slower because the DIT is polluted - Some suppliers licence their
systems based on entry count. What happens if the 100k entry server
reaches 500k entries over a week because of updates? What happens to
cached systems that fill up with log records?

What is the access controls on these new objects and their generations,
does this get written to them, what are the schema rules and name
bindings of them - are they universal within one server or across the
directory enterprise. 

It is easy to stick a field in a protocol... But what does an
implementation have to do to support it re key and information
management  and dirctory schema rules, search performance and doctrine
and managment AND how valuable is that in terms of trust and commercial
security...

With this draft - not a lot.


regards alan