Re: protocol: data hiding

[Hallvard B Furuseth <h.b.furuseth@usit.uio.no>]

Jim Sermersheim wrote:

> I like the notion of bringing this to the reader's attention, but I
> dislike prescribing specific actions. How about something more like:

For diagnosticMessage, I agree.

Not sure about matchedDN.  The options I can think of are to act as if
the entry is not there, or to not return a matchedDN at all.  However,
with the latter behaviour, a user who knows the server well can
sometimes deduce that an expected but missing matchedDN indicates a
hidden entry.  So I think the text should at least mention that data
is best hidden by pretending it is not there.

As for the result code, I would like the text to at least suggest that
one may return a less informative result code.  Otherwise it may not be
clear to an implementor what he can do when some revealing result code
should normally be returned.  Since I can't think of any other option, I
don't really care is that is stated as a suggestion or a mandate.

Also,

Kurt D. Zeilenga wrote:

>         The matchedDN and diagnosticMessage fields, as well as some
>         resultCode values (e.g., attributeOrValueExists and
>         entryAlreadyExists), could disclose the presence the
>         specific data in the directory where not subjected to
>         access and other administrative controls.  Server
>         implementators should provide access control mechanisms
>         which not only restrict access to information under both
>         normal but also under error conditions.

s/both//.
s/presence the/presence of/.

-- 
Hallvard