[ca-tf] Certification-Policy Proposal - next steps?

Dear Certification Task Force members,

I am very happy that the discussion around this topic has come to life like this. 

I think we all agree that the value of Resource Certification lies in the fact that a certificate represents the truth. We should never lose sight of that, or it will undermine the credibility of the system, and with it the viability. With this in mind, I would like to make a couple of points, which I hope can lead to a proposal made by the CA-TF. 

1. Resource Certification is inextricably tied to the business relationship with the LIR
First, I would like there to be absolutely no misunderstandings about our membership process: When an organisation wants to become an LIR, we first diligently check their identity and company registration papers. This forms the foundation to all services we offer to them: Internet Resource allocations, Billing, LIR Portal access, RIPE Database entries, Reverse DNS Delegations, etc. So only for as long as we have business relationship with the LIR, we can make attestations about their identity, allocation status and everything else. 

When the registry closes because of bankruptcy, non-payment (http://www.ripe.net/info/faq/membership/billing.html#6) or any other reason, our business relationship ends. We will reclaim the Internet Resources (applying Lifecycle Management), remove the RIPE Database entries and stop the Reverse DNS Delegation. Reclaimed resources will be reissued to another LIR. When there is a dispute, we have an Arbitration Process: http://www.ripe.net/membership/arbitration.html

Resource Certification fits exactly into this model. We can only sign and renew certificates if we have a business relationship with a member. The PKI reason for this is that only then we can be sure that we are dealing with the correct people. Since Certification is just a different representation of our allocation data, it must follow the same process. If the business relationship is discontinued, having certificates that do not reflect this, will cause a deterioration of the value of the system. Not aligning with the current business process will increase complexity, understandability of what is the state of the business relationship and will deteriorate the trust in the system.

If the fear for disputes is the main driver for this issue, then we should refer to the Arbitration Process: in case of dispute we will not reclaim resources and allow the holder to create a new valid certificate until the dispute is being solved. 

2. Resource Certification is an additional, opt-in member service
Network operators are free to make route filtering choices they want. They can choose to not filter at all, manually filter based on local policy, or filter based on Whois Database and Internet Routing Registry data. Resource Certification intends to offer more robustness, improved data quality, and easier validation. It will provide an additional piece of information a network operator is free to base decisions on. We will offer a tool that checks certificates and ROAs and only indicates what the status is. In its current form, Certification will be offered in a hosted solution through the LIR Portal, where the user can manage ROA specifications. The system will take care of all the crypto operations like certificate requests and renewals, re-keys and make sure corresponding ROA objects are generated and published. The user only has access to this system for as long as they are a member, as explained in point 1.

3. Power, control and legal implications of the implementation of Certification
The possibilities for law enforcement agencies to take measures against the Resource Certification system run by the RIPE NCC are very limited, if existent at all. Under Dutch law, the process of Certification, as well as Resource Certificates themselves do not qualify as goods that are capable of being confiscated. If in the extremely unlikely case this this were to happen anyway, then it will prove utterly ineffective. This is because a revoked Certificate or ROA has the same status as a non-existent one, since this is an opt-in service network operators are free to base decisions on, as explained in point 2. Simply put, Resource Certification can drive a preference. The existence of a Certificate and ROA is a positive message, the absence is not a negative one. The revoked status is not a negative statement either, for as long as a new certificate for that resource has not been issued. These statements are supported by IETF documentation, the current draft can be found here: http://tools.ietf.org/id/draft-pmohapat-sidr-pfx-validate-04.txt

Section 3.1 'Policy Control' says: "It MUST be possible to enable or disable the validation step as defined in Section 3 through configuration. The default SHOULD be for the validation step to be enabled. An implementation MAY also support disabling validation for a subset of prefixes or for routes received from a particular EBGP peer....."

This confirms the idea that having a valid ROA for a given announcement is a plus, but there *must* be ways for operators to override or even disable this. It may interest the CA-TF that both Cisco and Juniper contribute to this draft and will most likely follow this document in the implementations that they will provide for their routers in the future.

4. Inter-RIR considerations
I met with the other RIRs at the IETF. Below in the table is my interpretation on how they look at Certification on three main topics. I hope this offers some additional perspective:
 	ARIN	APNIC	LACNIC	AFRINIC
 	 	 	 	 
Opt-in vs. Push	Opt-in	Opt-in	Opt-in	Opt-in
Community vs. member service	Member service, no policy needed other than the CPS	Member service, no policy	Member service, tend to no policy due to lack of community input	Member service, policy to be decided
Cert validity	Membership aligned	Membership aligned	Tend to membership aligned	Membership aligned
 
Closing thoughts and conclusion
A lot of the discussion around Resource Certification has revolved around technical implementation details. However, most of the proposals with a technical nature seem to have been made in order to resolve a concern that is actually policy or business related. I hope this message offers some perspective, and outlines how we can implement Resource Certification ensuring the best possible robustness and security, while keeping the system open, transparent and easy to understand and use for the Community. 

With this in mind, I believe it will be very beneficial for the proposal that the CA-TF will come up with, to contain the following:

a. The way Resource Certification will tie into our current business processes
b. The fact that Resource Certification is an additional, opt-in member service
c. That in case of a dispute, we have an Arbitration Process in place. During the procedure, we will not reclaim resources, and Certification will remain available to the member.
d. How Resource Certification is aimed at aiding the network operator in making routing decisions, and does not enforce anything, also when  Secure BGP becomes a reality
e. The possibilities for law enforcement agencies to take measures against the Resource Certification are very limited, if existent at all. 
f. The fact that we will have a Certification Practice Statement that reflects this

Naturally, the RIPE NCC is more than happy to support drafting a proposal.

Regards,
Andrew
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://www.ripe.net/ripe/mail/archives/ca-tf/attachments/20100331/0f72746d/attachment.html