RE: Signed Directory Operations

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

Oh dear!


> -----Original Message-----
> From:	Bruce Greenblatt [SMTP:Bgreenblatt@RSA.com]
> Sent:	Friday, May 29, 1998 2:57 AM
> To:	'Alan Lloyd'; 'Salter, Thomas A'
> Cc:	[ldap extensions]
> Subject:	RE: Signed Directory Operations
> 
> Alan,
> 
> Thanks for taking the time to review the draft.  I think that your
> comments
> reveal a common misconception about the X.500 model and the DAP (and
> hence
> LDAP) operations.  Back in the old days when I was directly
> participating in
> the ITU (was CCITT then) standards process (88-92 study period), I
> explained
> this about the delete operation many times.  There is no requirement
> that
> the "Delete" operation actually removes anything premanently from
> storage.
	I think the misconception is in your court on this
one........................

	This has me worried. ie a Delete that does not delete. This must
be similar to some applications with bugs that dont release memory when
they should and then go bang.
	So are you saying that LDAP definition MUST specify that its
delete operation does NOT delete but does a "rename" to put the entry
into off line mode - just because the entry may or may not carry an
audit log. When I search any entries will these audit logs get searched
also -  that will do a lot for performance wont it...., when I read
entries and ask for all attributes - do I get all the audit logs back as
well... that will do a lot for performance.. . Do I now have to specify
- "no audit logs" please in every interrogation response.

	When I rename entries or move them do the audit logs stay with
the obituary entry or do they go with the renamed one.

	When I delete an entry and then add it again and then delete it
what happens - does a big obituary list form.

	Or when I actually delete anything like an attribute value -
does it still stay there.
	What happens if the entry contains attributes which are in fact
mail boxes, video, web pages, voice........do these remain  stored.

	What about subentries as per X.500 - do these have audit logs
also.

	When I replicate entries do the audit logs get transferred and
if multi master is used are these merged in any way?

	Do I have to configure the server the structure rules set for
every object to permit audit logs to be inserted in every entry.

	Do I have to configure each directory entry as to audit trace
levels?
	 

	There are servers and DSAs out there (not ours) that cashe every
thing into memory -  and I have never seen a directory server with 100
Gigs of RAM !



	As said different people have different views - I can just hear
the customers now. We licenced this LDAP server for 100,000 entries and
within a week it all filled up with obituaries! went slow and died. But
then we bought an LDAP accessed, RDB based X.500 system and we can use
it for our business.


	Audit logs for a server need to be seperate from the directory
user information provided by that server simply because one generally
wants to trace operations and users for the server with details of the
entries they accessed..These logs can be directory entries in their own
right - but administered under a management tree/area. Its wrong to have
in each entry, where there may be 10,000,000 in a big DSA, a list of
10,000,000 users that accessed entry. That becomes unmanageable and
polutes the DIB (or maybe one uses the LDAP obituary entry management
army:-) )

	In a military environment we use a term called covert channels -
it means that there is amechanism for information to be passed within
protocols or information blocks "invisibly" that may provide a recipient
additional information which they are not entitled too. Having a DIB
with obit entries all over the place and not know about them - and
possibly being able to replicate them for instance, strikes me as a
massive covert channel.. I am sure Defence will be pleased to know that
a Delete operation does not delete.

	Is anyone doing a trust model for LDAP and LDAP servers with all
this "security" stuff, and the dependency to replicate everything to
everywhere...


	 LDAP can keep adding such inconsistent, unworkable, inpractical
features and mechanisms - and all that will do is kill LDAP off -  Most
people dealing with directories are already coming to this conclusion.

	regards alan

> As my good friend Ed Reed can explain far better than I can, a better
> implementation of Delete is for the directory server to create an
> "Obituary"
> object of some sort in order that things like the audit trail object
> and
> other directory server required objects and operations can continue to
> function normally.  I will put some remarks to this effect in the next
> version of the draft.  Thanks again for the comments.
> 
> Bruce
> 
> > -----Original Message-----
> > From:	Alan Lloyd [SMTP:Alan.Lloyd@OpenDirectory.com.au]
> > Sent:	Wednesday, May 27, 1998 5:55 PM
> > To:	'Salter, Thomas A'; Bruce Greenblatt
> > Cc:	[ldap extensions]
> > Subject:	RE: Signed Directory Operations
> > 
> > 
> > I was about to say the same - there are a lot of assumptions made in
> the
> > draft re key management, selection process for signed ops - See
> X.511
> > and dap re selection of signed, encrypted  and signed and encrypted.
> > plus the massive distinction between signed entries and signed
> > operations. In addition if the audit trail is tied to THE entry and
> the
> > entry deleted what use is that.
> > 
> > As said - these approach to add "a mechanism" to a directory system
> > without considering the system, trust and information management
> issues
> > seems a bit strange.
> > 
> > 
> > The sequence number thing - how does that relate to many users and
> multi
> > master mode ?
> > 
> > regards alan
> > 
> > PS as Stephen Kille said - best use DAP and X.500 when it comes to
> > secure signed operations and trusted directories ... DAP  is
> smaller,
> > more efficient, and deals with signed operations - correctly -and
> can be
> > demonstrated.
> > 
> > 
> > > -----Original Message-----
> > > From:	Salter, Thomas A [SMTP:Thomas.Salter@unisys.com]
> > > Sent:	Thursday, May 21, 1998 5:01 AM
> > > To:	Bruce Greenblatt
> > > Cc:	[ldap extensions]
> > > Subject:	RE: Signed Directory Operations
> > > 
> > > Can you provide some clarification/rationale on these points:
> > > 1. What's the advantage of S/MIME formatted signature, rather than
> an
> > > ASN.1 bit string ?
> > > 2. How is the signature computed on the Ldap operation?  Do you
> DER
> > > encode the operation without the SignedOperation control, compute
> the
> > > signature, add the control with signature, then re-encode the
> > > operation?
> > > 3. What good is the signature if the LDAP server doesn't verify
> it?
> > > Why
> > > isn't the LDAP server required to verify the signature?
> > > 4.How about some examples of the Changes attribute?  What does the
> > > SignedOperation look like?
> > > 5. There's no discussion of how this auxiliary class,
> > > signedAuditTrail,
> > > is used.  Does every object modified by a signed operation get a
> > > Changes
> > > attribute?  Does the server maintain the sequence number ?
> > > 6. Is it expected that some LDAP servers would disallow non-signed
> > > operations?  If so, this should be specified, and there should be
> a
> > > root-dse attribute indicating it.  If not, what's the point of
> signing
> > > some operations if anyone can come along and undo the changes with
> an
> > > unsigned operation?
> > > 7. signatureSpan seems to be undefined.
> > > 8. Why do you say "The SignedResult control MUST not be marked
> > > CRITICAL."?  It seems reasonable for a client to say "If the
> server
> > > can't sign it, I don't want it"