[ca-tf] Certification Proposal

Filiz Yilmaz wrote:
> 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.

I understand the intent and I agree with it. OTOH, this suggests that APNIC 
will not be able to get their certificate from us (as they are not an LIR). 
Talking to them, I have the impression that they'd like to get some cert 
from us :-)

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

Sure, this is why I'm trying to facilitate that. As it is very likely that 
there will be a standard way to get the certificates (again, this is the 
"up-down" or "provisioning" protocol), it's reasonable to expect that 
external entities will want to use that. Other channels, such as the LIR 
portal access and hosted RPKI, are value added services.

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

I don't think that we want (current, in-flux) technical matters to dictate 
the policy. Isn't it supposed to be the other way around? ;-) Then again, if 
the policy will say "certificates cover all PA allocations", then policy and 
functionality are aligned now.

Cheers,
Robert

> Regards,
> Filiz
> 
> 
>> Cheers,
>> Robert
>>
>