Re: [ca-tf] Certification Proposal

[Filiz Yilmaz filiz@localhost]

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.
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.
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

Attachment: proposal_in_template.doc
Description: Binary data

Attachment: proposal_in_template.pdf
Description: Adobe PDF document

1. Number (will be assigned by the RIPE NCC):
2. Policy Proposal Name: Initial Certification Policy for Provider Aggregatable Address Space Holders 
3. Author: 
a. name: Nigel Titley on behalf of Certification TF
b. e-mail:
c. organisation:
4. Proposal Version: 1.0
5. Submission Date: TBA
6. Suggested RIPE WG for discussion and publication: Address Policy 
7. Proposal type: new
8. Policy term: renewable
9. Summary of proposal

The RIPE NCC plans to deploy a certification service that can be used to secure uniqueness of resources. This proposal lays out guidelines for how LIRs can receive certificates over their Provider Aggregatable (PA) address space holdings and how these certificates should be maintained.

10. Policy text
New

The RIPE NCC issues certificates upon request. 

The requester must be a RIPE NCC member LIR holding Provider Aggregatable (PA) address space allocations.
 
When the RIPE NCC receives a certification request, they may ask for further details to ensure that the requester is the legitimate holder of the resource. 

The certificate will be issued via a secure channel that the RIPE NCC maintains for its members (at the time of this proposal this is LIR Portal). 

Maintenance and renewal of certificates will be tied to membership status of the LIR. In cases of continuing non-payment, cessation of membership and/or closing of the LIR, existing certificates will be revoked by the RIPE NCC.

The RIPE NCC will issue a resource certificate covering all PA allocations held by the LIR at the time of the request. When there is a change in the PA allocations held by the LIR, the RIPE NCC will ensure that there is a single, up-to-date certificate reflecting the LIR's total PA address holdings.  

11. Rationale:
a. Arguments supporting the proposal

The RIPE Certification Task Force (CA-TF) was formed at RIPE 53 to advise, review and to provide feedback about a certification system. More details about the CA-TF can be found at: 
http://www.ripe.net/ripe/tf/certification/index.html

Since RIPE 53, the CA-TF has been looking at the system from several angles such as benefits and usefulness of it as well as operational, business and policy implications that it may bring. As these issues were narrowed down for discussion, CA-TF has reported to the community in time. 

This proposal is a product of of the work done by the CA-TF. The task force has studied possible policy implications and decided that a short initial policy will be useful that will be a guideline for a certification system for the RIPE community to discuss. 

At this stage, only a policy for LIRs holding PA address space is proposed. The CA-TF believes that the system should cover PA resources initially, as this is the simplest case for the system. Once a policy for PA resources for LIRs has been discussed and the community has agreed on guidelines, then the CA-TF will consider more complicated scenarios, such as PI address space and ERX and legacy address space. This phased development is also inline with the technical implementation of the system, as certificates for PA allocations will be the first real cases for the certification system when it launches. Certification of other resources will be implemented later on. 

It is proposed that the validity of certificates is tied to membership status of an LIR. This is inline with the other services that the RIPE NCC provides to its members. 

The reason for aggregating all resources on the same certificate is to simplify matters for the LIR and other downstream parties. Once resources are split over multiple certificates it will be impossible to merge them further down the chain. There are various scenarios in which this could be problematic, for example: it will be impossible to sign a Route Origination Authorisation (ROA) object, a key routing application of certification, with resources covered by two different certificates. Additionally, certificates should be tied to their own key pair; fragmentation of resources over multiple certificates will result in more complex key management requirements.

b. Arguments opposing the proposal


On 30 May 2008, at 17:59, Nigel Titley wrote:

> > So my question now is: how do we proceed?
> I certainly think that the way to proceed is to offer certification  
> to PA holders first. This is far less fraught with legal problems  
> than anything else. I'm happy for us to widen the policy to cover  
> other objects too.
> As to Michael Dillon's problem, I can understand his fears, I've  
> worked for BT too, and the prospect of all your routes dropping out  
> of the routing tables because accounts payable can't get their act  
> together is enough to strike fear into the heart. However, I  
> maintain that a combination of the RIPE NCCs traditional tolerant  
> approach to lateness of payment, together with <insert large  
> company here> appreciating how important this is should do the  
> trick. If you want to build appropriate wording into the proposal,  
> then by all means go ahead, but I think it isn;t necessary. After  
> all, similar things happen with domain names (and with far worse  
> consequences).
> Nigel