[address-policy-wg] Legal counsel on 2008-08 (Initial Certification Policy in the RIPE NCC Service Region)

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

On 31/05/2011 09:54, Sander Steffann wrote:
> It's not about agreeing at this point in time, it's about moving forward: at the last RIPE meeting you said that RPKI has risks what we shouldn't take without thinking about them and without looking for alternatives. In the hallway after the discussion you promised me to do research. As far as I can remember you would:
> 1) study the discussions in the IETF and other places to see why RPKI design decisions were made the way they are
> 2) see if there is a better way to secure routing that provides (90%-100%) the same benefits without the major risks as you see them
> 3) of course taking 1 into account while doing 2
> 
> Can you give us a status update on this?

You make it sound like I agreed to single-handedly solve the problem in
all its various aspects.

Not so.

The only pointer anyone has given me to explain why 2008-08 incorporates
the RPKI architecture that it does is "Go read the SIDR mailing list
archive". So I had a look at that, but as far as I can understand they
took the RPKI architecture as an input from previous work. So the
reasons why this was picked seem to lie elsewhere, although I'm not sure
where that is. Any better pointers to the actual discussion and
decision-making would be welcome.

What worries me about the questions you set me above is that it reads as
though you expect me to single-handedly design an alternative solution
that meets 2008-08's goals while also satisfying the criticisms. As I
said in the hallway, the technical work on producing an alternative
approach would have to be led by someone expert in that area, which I am
not. If such work is done, I believe I can contribute usefully by
helping to identify whether an alternative does indeed reduce the risk
of the foreseeable consequences I've identified with 2008-08.

For example, in the hallway we discussed a couple of ideas for
variations on 2008-08 (distributed certification and decentralised CAs).
These did seem to tackle the problems of centralisation with 2008-08,
and so seem to me to be worthy of investigation, but developing the idea
into an approvable policy proposal should be done by someone else. To
reiterate: I am happy to contribute.

However, if the design of this is in the hands of the IETF not RIPE,
then I have to ask whether there any point in us designing an
alternative? Or is the only decision for this WG a simple YES/NO on
whether the community wants RIPE NCC to implement the IETF work?

If the latter, what I have already said is probably sufficient.

I must confess my ignorance on the scope available to us, and ask for
your guidance.

In any case, my own core relevant expertise lies in correcting some of
the misinformation propagated here about "black helicopters" and so
forth, by providing concrete information on public policy developments
in progress, and filling in the information gap left by the RIPE NCC's
legal advice, which disclaims advising upon the likelihood and likely
consequences of future changes in the law (I'm not criticising the
lawyer for leaving this gap: that area is essentially Public Affairs
advice not legal advice).

I suggest that this is important input to this WG's decision as to
whether it believes 2008-08 (or any successor proposal) is in fact
useful, i.e. whether it is likely to do more good than harm.

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/

                 London Internet Exchange Ltd
  Maya House, 134-138 Borough High Street, London SE1 1LB

         Company Registered in England No. 3137929
       Trinity Court, Trinity Street, Peterborough PE1 1DA
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.14 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk3kxDQACgkQJiK3ugcyKhS9uwCgrl/fYP62Y/tMwCGfOy9h1Xh5
CVoAoMmztYz0XGVIyW6XXRK5RDa6dciR
=Thdg
-----END PGP SIGNATURE-----