[routing-wg] [ncc-services-wg] Implementation of Resource Certification (RPKI) for PI End User Resources

On 22 Oct 2013, at 11:06, Jac Kloots <Jac.Kloots at surfnet.nl> wrote:

> 
> Alex,
> 
> On Tue, 22 Oct 2013, Alex Band wrote:
> 
>> The issue is: A PI End user must prove to the RIPE NCC that they truly are the legitimate holder of the resources they would like to have a certificate for. What proof do they need to give to the RIPE NCC before we grant them access to the system?
> 
> Not having followed all of this discussion, but isn't there an effort going on as result of RIPE-452 (http://www.ripe.net/ripe/docs/ripe-452) for having a contractual relationship between PI end-users and the RIPE-NCC.
> 
> Isn't this contractual relationship the best proof for being the legitimate holder of the PI resource?

Allow me to illustrate this using an example scenario, where a PI End User wants a certificate without going through their sponsoring LIR:

1: The PI End User logs in with their RIPE NCC Access account on ripe.net (after creating one)
2: They go to a webpage with a form where they enter the prefix(es) they would like a resource certificate for
3: The background system checks if these prefixes:
	a) are PI End User resources
	b) have the status "End User Documents Approved", meaning that a RIPE-452 contract was submitted and verified
4: The PI End User must enter the RIPE Database MNTNER password/key(s) for the inetnum objects of the resources, to prove they have authoritative control over them
5: If this is successful, the RIPE NCC Access credentials, resources and ROA management interface are associated with each other, allowing them to use the system

It is up to the Community and membership to decide if this would be an acceptable workflow or if additional steps or checks would need to be added.

You should keep in mind that at all times, the sponsoring LIR is the only point of contact the RIPE NCC has, and according to the signed contract they are held responsible for the resources and PI End User relationship.

Cheers,

Alex
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </ripe/mail/archives/routing-wg/attachments/20131022/8f29b3f7/attachment.html>