[db-wg] [ncc-services-wg] Securing MD5 Hashes in the RIPE Database

Thank You for this answer. Most qeustions/complains went away.
But one is still not clear to me.

> If there is no password at all in the MNTNER object the "auth:"
> attributes will not be filtered in Webupdates and no password will be
> asked for in order to display the object.
...
 > As we said in the article on RIPE Labs, the authentication model used by
 > the RIPE Database is complex with many levels of indirection. If there
 > was a simple solution to this problem that covered all possible issues
 > we would have done it years ago. Working within the current design we
 > want the best possible solution to this one issue that covers the
 > majority of use cases and acceptable workarounds for the corner cases
 > that can be implemented in a relatively short time period.

This is good point. But it looks like to me that this will bring 
inconvenience to users of KEY-schemes. Which are more secure and thereby 
should be encouraged, not punished. :)
There should be no case where some information can be got only with 
password if KEY auth is present too.
May be it should be added some possibility to send signed search 
reqests? Or may be output unfiltered object, encrypted with one of the keys.

> There is no requirement for the maintainer of a MNTNER object to be one
> of the people who have credentials listed in the MNTNER object and it
> can be a separate MNTNER object. So if the maintainer of a MNTNER object
> is on vacation and you want to change your password or PGP key right now
> with the present system there is nothing you can do.

You missed the point or I described badly. Let's look at example:

mntner:  test1-mnt
auth:    MD5-PW ...
mnt-by:  test2-mnt

mntner:  test2-mnt
auth:    MD5-PW ...
auth:    PGPKEY-...
mnt-by:  test2-mnt

So test2-mnt have 2 auth options. Let it be 2 different people. In that 
case only one having MD5-PW can see unfiltered test1-mnt. This is I 
called "punishing of users of KEY-schemes".