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

[Bruce Greenblatt <bgreenblatt@directory-applications.com>]

At 11:01 AM 5/4/2000 -0400, Salz, Rich wrote:
>>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:

Boy, you're a tough customer.  Given that RFC 2649 is experimental, it's
not surprising that you thing that changes need to be made...

>	1. Why S/MIME, why not just a raw signature?

During the process of creating RFC 2649, we discussed using raw signatures,
but it was deceided that the benefits of using a standard mechanism that
was already recognized by other applications was substantial.  S/MIME is a
standard mechanism for the interchange of signed and encrypted data.  It
allows easy transfer of the signature between Internet applications.  I
don't see this changing.  So, I'd urge you to consider paying the overhead
of using the standard interchange mechanism.

>	2. Protection of search replies is too heavyweight; no intermediate
>	   step (like "just hash")

How does a hash of the search reply protect it?  This wasn't viewed as a
requirement at the time.

>	3. An adversary could intercept search replies undetected.

If you are concerned about this, you can protect the channel.

>	4. Audit entries aren't linked; an adversary could intercept or
>"trim off"
>	   the end, or tamper intermediates

An adversary would need to have sufficient access to the directory to do
this.  If someone hacks into the directory, any number of things can happen.

>	5. Replies aren't cryptographically tied to queries; what prevents a
>	   man in the middle attack?

LDAP over TLS can easily prevent this.

>	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)

If this is not a requirement, don't use it.  The sign by server request
allows the client that trusts the server to sign the operations to do the
work.  This is an optional feature that was deemed to be useful in some
environments.

>	7. Sequence numbers aren't required to be monotonically increasing
>within an
>	   object, so an adversary could intercept intermediate ones without
>detection.

Sequence number are required to be increasing.  RFC 2649 indicates"
"Subsequent sequence numbers indicate the sequence of changes that have
been made to this directory object.  Note that the sequence of the changes
can be verified due to the fact that the signed directory object will have
a timestamp as part of the signature object, and that the sequence
numbering as part of the change attribute should be considered to be an
unverified aid to the LDAP client.  Sequence numbers are meaningful only
within the context of a single directory entry..."  In any case the
sequenceNumbers in RFC 2649 are used as an aid to the client to show the
sequence of operations that were applied to that operation.

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

Sequence numbers are global, within an entry.  Each signature has a
timestamp as well.  So, you will know exactly when something bad happened
to an entry.

>	9. Allowing both "client signs" and "sign by server" probably means
>an adversary
>	   can do bad things by messing around with his local clock.

I don't follow this one.  For your purposes, you just only use client
signature mechanism. The sign by server request doesn't apply.

>Hope this helps.

Actually, it doesn't.  I still think that you can use RFC 2649 mechanisms
for your requirements.  In your draft, you state: "In many environments the
final step of certificate issuance is publishing the certificate to a
repository. Unfortunately, there is no way for a Certification Authority
(CA) to have a secure application-level acknowledgement that the proper
repository did, in fact, receive the certificate."  In my mind, this is
exactly what RFC 2649 provides.  When the CA publishes the certificate to a
repository (presumably via an LDAP modify operation), it will receive a
signed result from the LDAP server, and the LDAP server will store the
signed operation from the CA along with the modified LDAP entry.  If there
are specific things that need to happen in the CA - LDAP Server interaction
that don't happen in the machanisms defined by RFC 2649, then maybe we
should update RFC 2649.  I also think that it is important to have the
ability to store the signatures stored in the directory along with the
entry, so that other clients can retrieve the signatures... 

Bruce

>	/r$
>
>
==============================================
Bruce Greenblatt, Ph. D.
Directory Tools and Application Services, Inc.
http://www.directory-applications.com
Sign up for our LDAP Technical Overview Seminar at:
http://www.acteva.com/go/dtasi