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

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"