Re: [ca-tf] Certification Proposal

[Robert Kisteleki robert@localhost]

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