RE: I-D ACTION:draft-salzr-ldap-repsig-00.txt

["Salz, Rich" <SalzR@CertCo.com>]

>Why can't you use the mechanisms defined in RFC 2649 as a basis for this?
>Your proposal seems remarkably similar to the definitions in RFC 2649.

I have a couple of issues with 2649:
	1. Why S/MIME, why not just a raw signature?
	2. Protection of search replies is too heavyweight; no intermediate
	   step (like "just hash")
	3. An adversary could intercept search replies undetected.
	4. Audit entries aren't linked; an adversary could intercept or
"trim off"
	   the end, or tamper intermediates
	5. Replies aren't cryptographically tied to queries; what prevents a
	   man in the middle attack?
	6. For a repository that is mainly holding signed data (certs and
crls),
	   I don't see what security "sign by server" gets you, and it
weakens
	   the overall system (making some of the above attacks possible)
	7. Sequence numbers aren't required to be monotonically increasing
within an
	   object, so an adversary could intercept intermediate ones without
detection.
	8. On the other hand, audit trail sequence numbers aren't global, so
it
	   doesn't seem possible to step through and determine exactly when
something
	   bad happened.
	9. Allowing both "client signs" and "sign by server" probably means
an adversary
	   can do bad things by messing around with his local clock.
Hope this helps.
	/r$