[ca-tf] Certification Proposal

Dear Filiz, dear all,

  > Hello,
  > 
  > As promised, attached please find a proposal in RIPE Proposal  
  > template. I tried to address all the points that were raised and  
  > commented by Nigel after RIPE 56.
thanks to Filiz for doing good work.

Sorry for raising concerns this late.

Over the last few weeks my ideas and understanding of how the certificate
information can be quickly used for improving security of the actual routing
have deepened, and I'm now very much trying to promote this very seriously.
In the course of this activety I'm taking potential arguments very serious
that could discourage network operators and users could feel from using RPKI
to protect their address space and authorize route origination.

In this light I have changed my evaluation of the "Michael Dillon type"
(and similar) of concern, and I firmly believe that we MUST create a policy
that clearly and explictly ensures that certificates will be securely
protected against any accidental revocation.

  > For your convenience, I attached it in 3 different file  
  > formats, .doc, pdf and .txt. All files have the same content.
  > 
  > You will see the major points that were agreed by the TF and  
  > presented in RIPE 56 have not changed but wording is polished. Some  
  > Rationale is added as part of the proposal template too. I will be on  
  > holidays for the next 2 weeks so if you can have a look and pass your  
  > further comments if any until 7 July, it will be great.

I think it is wrong to "tie validity of a certificate to membership status";
it would seem more correct to tie validity of certificates to
"allocation status" - which can be more stable than membership.
Yes, it is easy to refer to membership - because the status and rules
are already there. "Allocation status" on the other hand most likely
needs work - which however may be needed to take care of other types
of address space and relationship.

The question may be raised whether going forward with this policy proposal
modified to refer to "allocation status" is possible.
I think that this should be possible (may be adopting some temporary
definition);  so I'd suggest to modify the reference to "membershiph status"
to "allocation status"; publish start of activety to clarify/define
"allocation status" with special care of making it "stable and trustworthy",
and push forward with the modified policy proposal as "first limited
implementation step".

Of course work on defining rules and processes for allocation status would
need to be started quickly; this probably is not an item for CA-TF, though of
course the consequences of having RPKI as a way of voiding existing
allocations will have to be considered. (Sorry for all the cans of worms...)

I also think that introducing RPKI and expecting it's use for securing
actual routing raises the severity of impact that actions of the RIPE NCC
can have to an unprecedented level. As a consequence I that the argument
"just apply membership status as for other services" REALLY DOES NOT APPLY.

BTW I suspect that within CA-TF we have not yet explictly looked at
what the legal meaning of issuing the certificates is - or how these will
be defined.

  > Then once it is agreed, I can publish it as a formal proposal,  
  > announce it to the community for discussion and start its formal PDP  
  > cycle as agreed in RIPE 56.
  > 
  > Kind regards,
  > Filiz Yilmaz

Regards,
  Rueidger


Ruediger Volk

Deutsche Telekom AG -- Internet Backbone Engineering

E-Mail:  rv at NIC.DTAG.DE