Fwd: [ca-tf] Certification-Policy Proposal - next steps?
Filiz Yilmaz filiz at ripe.net
Tue Apr 13 16:16:20 CEST 2010
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
[ Ca-tf Archive ]