[Date Prev][Date Next] [Chronological] [Thread] [Top]

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