[ca-tf] Certification Proposal

Dear all,

I've asked what others thought of Ruediger's latest comments and no  
one said a word, so I decided I will send my comments hoping we can  
get the discussion going. This is very important, as I stated before,  
because I am not sure if there is now enough consensus among TF  
members for me to publish the proposal formally, which will carry  
Nigel's name (but on behalf of TF) on it as agreed.

So, here are my comments:

Regarding "allocation status" (vs "membership status"), I believe  
this will not practically work very well on our side. We do not have  
a clear definition of "allocation status". Strictly speaking, it is  
not defined within RIPE policies. Trying to set a definition from  
scratch within the scope of a service proposal such as certification  
has a big potential to complicate matters and it may be out of a  
certification service scope, (assuming the idea is to keep this  
proposal as a service proposal, which should fit within the current  
addressing policy framework).

It is best to have clear criteria to issue a certificate or not from  
the beginning. Please note that unclear criteria will put RIPE NCC  
staff in a difficult situation. It would be best to have a clear  
policy so that the RIPE NCC can also produce clear and well-defined  
procedures based on that policy. It is also very important that the  
users of the service (initially just LIRs) also understand clearly  
what this service entails and under which conditions the policy is  
allowing them to use it.

In general, the policy should cover best practices for those who are  
good users and who are the majority.

Having said that, we all understand how very strict certification  
criteria can cause operational problems for the few people who fail  
to abide with the criteria, perhaps without any bad intentions. After  
conducting some internal discussion here in the NCC,  I have made  
some further changes to the proposal. The proposal now mentions  
"grace period" mechanisms explicitly. This should ensure that the aim  
is to set a policy which will not break anything for those people who  
intend to keep their allocations and continue receiving a service as  
a RIPE NCC member. So the policy should be working for those who  
follow the general good path. The aim is to be able to stop the  
service to those people who choose to cease their service level with  
the RIPE NCC. So the consequences of not abiding with the set path  
will only apply to those who seem to be abusing the system in an  
ongoing manner. I think this what any sensible and useful policy is  
trying to achieve in general.

Please let me know if this helps or not?

I've made some other changes on the text. One of these changes is  
basically the  removal of the sentence about the "single  
certificate". This has been causing problems and confusion since day  
one. It came out that there are already some wording issues about  
what exactly a single certificate means on an engineering level, and  
what people literally understand from it. Also there may be cases  
where more than one certificate may be useful. So I removed this from  
the policy proposal. It seems the RIPE NCC can deal with different  
situations, according to different needs, case by case.

Please find all the changes mentioned above in the new draft I am  
attaching this mail. I would really appreciate it if everyone can  
state their opinion on this text and then we can publish it formally  
and open up it to community for discussion, as announced at RIPE 56.

Please also note that this proposal will still follow the RIPE PDP,  
which means there may be further and further edits on it, based on  
community feedback that may be received when it is open for  
discussion. So there is still room for discussion about it. Of course  
it is best to publish an almost complete proposal that will receive  
consensus easily, but some of the points may, by their nature,  
require a broader discussion.

I hope to hear from you soon. I will assume there is consensus to go  
public with this version of the proposal if I do not hear from anyone  
with objections by 18 August (this is almost 4 weeks from today,  
which fits with RIPE PDP phases in general :)).  I would appreciate  
if those who have objections can also come up with suggestions for  
alternative wording.

Kind regards,
Filiz

ps: Following attachments are for the same content, but in different  
formats (.doc, .pdf, .txt) for your convenience)


-------------- next part --------------
A non-text attachment was scrubbed...
Name: proposal_in_template_draft02-3.doc
Type: application/octet-stream
Size: 26624 bytes
Desc: not available
Url : https://www.ripe.net/ripe/mail/archives/ca-tf/attachments/20080724/f2d9998e/attachment.obj 
-------------- next part --------------


-------------- next part --------------
A non-text attachment was scrubbed...
Name: proposal_in_template_draft02-3.pdf
Type: application/pdf
Size: 48015 bytes
Desc: not available
Url : https://www.ripe.net/ripe/mail/archives/ca-tf/attachments/20080724/f2d9998e/attachment.pdf 
-------------- next part --------------



-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: proposal_in_template_draft02-3.txt
Url: https://www.ripe.net/ripe/mail/archives/ca-tf/attachments/20080724/f2d9998e/attachment.txt 
-------------- next part --------------




On 7 Jul 2008, at 08:53, Ruediger Volk, Deutsche Telekom T-Com -  
TE141-P1 wrote:

> Dear Filiz, dear all,
>
>> 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.
> thanks to Filiz for doing good work.
>
> Sorry for raising concerns this late.
>
> Over the last few weeks my ideas and understanding of how the  
> certificate
> information can be quickly used for improving security of the  
> actual routing
> have deepened, and I'm now very much trying to promote this very  
> seriously.
> In the course of this activety I'm taking potential arguments very  
> serious
> that could discourage network operators and users could feel from  
> using RPKI
> to protect their address space and authorize route origination.
>
> In this light I have changed my evaluation of the "Michael Dillon  
> type"
> (and similar) of concern, and I firmly believe that we MUST create  
> a policy
> that clearly and explictly ensures that certificates will be securely
> protected against any accidental revocation.
>
>> 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.
>
> I think it is wrong to "tie validity of a certificate to membership  
> status";
> it would seem more correct to tie validity of certificates to
> "allocation status" - which can be more stable than membership.
> Yes, it is easy to refer to membership - because the status and rules
> are already there. "Allocation status" on the other hand most likely
> needs work - which however may be needed to take care of other types
> of address space and relationship.
>
> The question may be raised whether going forward with this policy  
> proposal
> modified to refer to "allocation status" is possible.
> I think that this should be possible (may be adopting some temporary
> definition);  so I'd suggest to modify the reference to  
> "membershiph status"
> to "allocation status"; publish start of activety to clarify/define
> "allocation status" with special care of making it "stable and  
> trustworthy",
> and push forward with the modified policy proposal as "first limited
> implementation step".
>
> Of course work on defining rules and processes for allocation  
> status would
> need to be started quickly; this probably is not an item for CA-TF,  
> though of
> course the consequences of having RPKI as a way of voiding existing
> allocations will have to be considered. (Sorry for all the cans of  
> worms...)
>
> I also think that introducing RPKI and expecting it's use for securing
> actual routing raises the severity of impact that actions of the  
> RIPE NCC
> can have to an unprecedented level. As a consequence I that the  
> argument
> "just apply membership status as for other services" REALLY DOES  
> NOT APPLY.
>
> BTW I suspect that within CA-TF we have not yet explictly looked at
> what the legal meaning of issuing the certificates is - or how  
> these will
> be defined.
>
>> 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
>
> Regards,
>   Rueidger
>
>
> Ruediger Volk
>
> Deutsche Telekom AG -- Internet Backbone Engineering
>
> E-Mail:  rv at NIC.DTAG.DE
>