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

Hello,

As the AP WG co-chair, it is important for Sander to follow the full  
discussion about the policy proposal.
I have been informed that the following mail did not reach him.
So I am passing Andrew's last full mail again to the list that was  
pointing to information about a possible new version of the  
certification proposal, as Sander's subscription to the list is  
confirmed.

Regards,
Filiz

Begin forwarded message:

> From: Andrew de la Haye <andrew at ripe.net>
> Date: 31 March 2010 10:37:43 GMT+02:00
> To: ca-tf at ripe.net
> Cc: Axel Pawlik <axel.pawlik at ripe.net>
> Subject: Re: [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/20100413/a4cf192e/attachment.html