[ca-tf] Certification Proposal

Hello,

On 7 Jul 2008, at 11:22, Robert Kisteleki wrote:

> Hi,
>
> Please allow me to propose a few enhancements:
>
>> 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.
>
> This excludes other RIRs. It seems likely that they can ask for  
> certificates too - for resources that have been transferred to them  
> from RIPE NCC.
>

Any RIPE NCC member who is also an LIR can ask for certificates. Note  
the wording referring to both "member" AND an "LIR" ( a logical AND).  
In today's definition a member becomes an LIR once they start holding  
some allocation.
I thought this is (at least initially) the intention, thus the wording.


>> 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).
>
> I suggest we say "including, but not limited to, the LIR Portal."  
> The reason is that the draft IETF standards include another method  
> (see SIDR "provisioning protocol"), which will be the "official"  
> protocol for retrieving certificates form an IR. Actually, that is  
> going to be the only standard method - everything else is region- 
> specific.
>

During the TF meeting in March, I got the opinion that the TF was  
keen on mentioning a specific secure channel. In today's setup it is  
LIR portal and this was also agreed in that meeting. If there needs  
to be a change in this, I will appreciate a consensus among TF members.


>> 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.
>
> "revoked and/or not renewed" is a bit more general. Most of the  
> time it's enough not to issue new certificates - the old ones will  
> expire anyway.
>

Rudiger also commented on this bit. I will appreciate other TF  
members' input on these issues too if we are going to change what has  
been agreed previously and discussed in the RIPE 56. Obviously we  
need consensus on this before we can publish a different proposal  
than the one presented in the meeting :).


>> 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.
>
> Note that on the longer run, LIRs will get the chance to ask for  
> certificates with only partial coverage. There can be a number of  
> reasons for this: preparation for key-rollover, splits and  
> transfers too.


Technical crew seems to be keen on having one single certificate for  
all resources by default. I think key-rollovers and maybe even splits  
can be covered within a procedural how-to documentation. I agree  
transfers is a policy matter. However, this initial proposal is not  
to detail down these cases (yet).

>
> This leads me to the question: is the policy going to be updated  
> later on, as new services / enhancements are made, or is it better  
> to add wording for things we foresee already?
>


I answered this partially above. The idea is to start with a policy  
for the simplest case and then build up on it for the rest of the  
more complicated cases. This also follows the path of technical  
implementation phases. The proposal text reads the following in the  
Rationale:

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


Regards,
Filiz


> Cheers,
> Robert
>