[db-wg] Re: Draft minutes from RIPE 56

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Nigel, your minutes contain the following note under "Follow-ups":

"* Resource Certification Project
    	The point was raised that the CA-TF work was a focus for actions by
lawful authority to remove items from the database. Would we want to
record all such actions. This is properly the domain of the DP-TF and
some progress on similar topics has already been made.
    	[AP56.1 DP-TF] To consider the action to be taken when legal
authority requests the removal of data from the database, and in
particular whether records of such actions should be recorded.
    	It was noted that 2008-04 will result in more ROA data for the DB
using data derived from the certification effort."

http://www.ripe.net/ripe/maillists/archives/db-wg/2008/msg00027.html

During the WG meeting at RIPE57 I would like to ask for an update (and
since the WG clashes with the Cooperation WG I will probably have to do
so via a sock-puppet).

My interest isn't merely in whether such forced-deletions would be
recorded, but also whether they would be announced publicly, whether the
affected assignee would be informed, and indeed whether they should be
done at all (and if not, what steps the NCC should take in advance to
protect itself from facing legally enforceable demands.

The reasons why this is an issue are more clearly minuted in the AOB
section to the minutes to RIPE55, as follows:


"* External object removal requests (Malcom H.)
	The issue here is where a legal request might arrive to remove an item
from the DB. If this is likely to happen, how should the RIPE NCC
respond? At present there is no law that might mandate this, but one
might come along. The RIPE DB covers far more than the EU, and this
could create a conflict of interest (or even a diplomatic incident).
Important that all be aware that this sort of thing is being proposed by
certain elements within the EU and we should perhaps think about this."

There is clearly a job for the RIPE NCC communications group to make it
clear to appropriate bodies what the function of the database actually
is [AP55.3 RIPE NCC]. Current RIPE NCC policy on information requests is
to first point to the public data, and then if more is required, then
require a court order from a Dutch judge.  We clearly need to discuss
this, but it probably needs discussing in a wider scope but it is very
important  to have arguments prepared beforehand."

http://www.ripe.net/ripe/maillists/archives/db-wg/2007/msg00170.html


I believe this is likely to become an important policy issue if
certification is a success (meaning, if people start to treat with
suspicion routing announcements for address blocks for which the
announcer cannot produce a RIPE-NCC-signed certificate).

It strikes me that there are four strategies available to the NCC:
i) cooperate cheerfully with legal requests to delete objects/revoke
certificates;
ii) seek to persuade legal authorities to forebear from making such
requests voluntarily;
iii) locate the database in a jurisdiction where such requests are
predicted to be unlikely/rare;
iv) reengineer the database so that it is split between competing
jurisdictions, such that legal authorities in multiple jurisdictions
would need to cooperate in order to compromise the database integrity
effectively.

The RIPE55 minutes indicate that the NCC is currently pursuing the
second strategy.

None of these are likely to be risk-free. I can imagine pursuing the
fourth strategy would be highly politically controversial. On the other
hand, I can imagine an existential political threat were the NCC ever to
succumb to a request from a Dutch/European court to revoke an address
block allocation (/ certificate) for a non-EU address block.

I think the WG should consider carefully whether the current approach is
sufficient, and how we should react if it fails.

Regards,

Malcolm.
- --
            Malcolm Hutty | tel: +44 20 7645 3523
   Head of Public Affairs | Read the LINX Public Affairs blog
 London Internet Exchange | http://publicaffairs.linx.net/

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkkFxrwACgkQJiK3ugcyKhTVJACgkkWkugFNkbWINAz2/4unFrcN
q2oAn0QvFt9X3sGHAW5kki2DZJxZF1Z5
=maMo
-----END PGP SIGNATURE-----