[ca-tf] Certification-Policy Proposal - next steps?

On Wed, 2010-03-31 at 10:37 +0200, Andrew de la Haye wrote:
> Dear Certification Task Force members,
> 
> 
> I am very happy that the discussion around this topic has come to life
> like this. 

Nice when that happens, isn't it :-)

> I think we all agree that the value of Resource Certification lies in
> the fact that a certificate represents the truth. We should never lose
> sight of that, or it will undermine the credibility of the system, and
> with it the viability. With this in mind, I would like to make a
> couple of points, which I hope can lead to a proposal made by the
> CA-TF. 

One could make a number of philosophical points about what is truth, but
I will confine myself to one. A certificate represents the truth at a
particular point in time. In this case it represents the world view that
the RIPE NCC believes to be "true" at the moment of issuing the
certificate. Thereafter its value declines gradually over time until it
is reissued again.

> 
> 1. Resource Certification is inextricably tied to the business
> relationship with the LIR
> First, I would like there to be absolutely no misunderstandings about
> our membership process: When an organisation wants to become an LIR,
> we first diligently check their identity and company registration
> papers. This forms the foundation to all services we offer to them:
> Internet Resource allocations, Billing, LIR Portal access, RIPE
> Database entries, Reverse DNS Delegations, etc. So only for as long as
> we have business relationship with the LIR, we can make attestations
> about their identity, allocation status and everything else. 

But going to my statement above, you are actually only attesting to the
business relationship at a particular point in time. If the user is
happy with the decaying relationship of the certificate over time, then
I'm not sure what the RIPE NCC has to worry about.

> When the registry closes because of bankruptcy, non-payment
> (http://www.ripe.net/info/faq/membership/billing.html#6) or any other
> reason, our business relationship ends. We will reclaim the Internet
> Resources (applying Lifecycle Management), remove the RIPE Database
> entries and stop the Reverse DNS Delegation. Reclaimed resources will
> be reissued to another LIR. When there is a dispute, we have an
> Arbitration Process: http://www.ripe.net/membership/arbitration.html

So, at this point, you revoke the certificate. With appropriate
precautions.

> 
> Resource Certification fits exactly into this model. We can only sign
> and renew certificates if we have a business relationship with a
> member. The PKI reason for this is that only then we can be sure that
> we are dealing with the correct people. Since Certification is just a
> different representation of our allocation data, it must follow the
> same process. If the business relationship is discontinued, having
> certificates that do not reflect this, will cause a deterioration of
> the value of the system. Not aligning with the current business
> process will increase complexity, understandability of what is the
> state of the business relationship and will deteriorate the trust in
> the system.

Again, as above. When you recover the resource, you revoke the
certificate. 
> 
> If the fear for disputes is the main driver for this issue, then we
> should refer to the Arbitration Process: in case of dispute we will
> not reclaim resources and allow the holder to create a new valid
> certificate until the dispute is being solved. 

This helps, but why not issue the certificate with a long expiry and
revoke when absolutely necessary? 

> 
> 2. Resource Certification is an additional, opt-in member service
> Network operators are free to make route filtering choices they want.
> They can choose to not filter at all, manually filter based on local
> policy, or filter based on Whois Database and Internet Routing

The problem with this approach is that it leads to the same sort of
problems we see with RBLs. Some RBLs are better operated than others,
but the average operator may not understand this and may end up blocking
email based on a badly operated RBL. When you query this you just end up
with the response "well you are on this RBL so you must be a spammer". I
can see similar things happening with certification.

>  Registry data. Resource Certification intends to offer more
> robustness, improved data quality, and easier validation. It will
> provide an additional piece of information a network operator is free
> to base decisions on. We will offer a tool that checks certificates

But as above, how many will actually understand what they are doing?

>  and ROAs and only indicates what the status is. In its current form,
> Certification will be offered in a hosted solution through the LIR
> Portal, where the user can manage ROA specifications. The system will
> take care of all the crypto operations like certificate requests and
> renewals, re-keys and make sure corresponding ROA objects are
> generated and published. The user only has access to this system for
> as long as they are a member, as explained in point 1.

Well, doubts have been expressed in a number of quarters about the lack
of the up/down protocol in your implementation. The feeling is that the
portal solution only addresses part of the problem.

> 3. Power, control and legal implications of the implementation of
> Certification
> The possibilities for law enforcement agencies to take measures
> against the Resource Certification system run by the RIPE NCC are very
> limited, if existent at all. Under Dutch law, the process of
> Certification, as well as Resource Certificates themselves do not
> qualify as goods that are capable of being confiscated. If in the
> extremely unlikely case this this were to happen anyway, then it will
> prove utterly ineffective. This is because a revoked Certificate or
> ROA has the same status as a non-existent one, since this is an opt-in
> service network operators are free to base decisions on, as explained

See above. Same problem.

>  in point 2. Simply put, Resource Certification can drive a
> preference. The existence of a Certificate and ROA is a positive
> message, the absence is not a negative one. The revoked status is not
> a negative statement either, for as long as a new certificate for that
> resource has not been issued. These statements are supported by IETF
> documentation, the current draft can be found here:
> http://tools.ietf.org/id/draft-pmohapat-sidr-pfx-validate-04.txt
> 
> 
> Section 3.1 'Policy Control' says: "It MUST be possible to enable or
> disable the validation step as defined in Section 3 through
> configuration. The default SHOULD be for the validation step to be
> enabled. An implementation MAY also support disabling validation for a
> subset of prefixes or for routes received from a particular EBGP
> peer....."
> 
> 
> This confirms the idea that having a valid ROA for a given
> announcement is a plus, but there *must* be ways for operators to
> override or even disable this. It may interest the CA-TF that both
> Cisco and Juniper contribute to this draft and will most likely follow
> this document in the implementations that they will provide for their
> routers in the future.

This indeed does help with giving me a warm, damp feeling. But we need
to make it crystal clear to the community that they are free to ignore
certificates... and then where does that give us improved routing
security? 

> 
> 4. Inter-RIR considerations
> I met with the other RIRs at the IETF. Below in the table is my
> interpretation on how they look at Certification on three main topics.
> I hope this offers some additional perspective:
>  
> ARIN
> APNIC
> LACNIC
> AFRINIC
>  
>  
>  
>  
>  
> Opt-in vs.
> Push
> Opt-in
> Opt-in
> Opt-in
> Opt-in
> Community vs.
> member service
> Member
> service, no
> policy needed
> other than the
> CPS
> Member
> service, no
> policy
> Member
> service, tend
> to no policy
> due to lack of
> community
> input
> Member
> service,
> policy to be
> decided
> Cert validity
> Membership
> aligned
> Membership
> aligned
> Tend to
> membership
> aligned
> Membership
> aligned

Well, I know for a fact that in the APNIC region the members have had
similar misgivings about certification. If this is all sorted out and
everyone is happy, then good. I had the impression that it wasn't
however.

> Closing thoughts and conclusion
> A lot of the discussion around Resource Certification has revolved
> around technical implementation details. However, most of the
> proposals with a technical nature seem to have been made in order to
> resolve a concern that is actually policy or business related. I hope
> this message offers some perspective, and outlines how we can
> implement Resource Certification ensuring the best possible robustness
> and security, while keeping the system open, transparent and easy to
> understand and use for the Community. 
> 
> 
> With this in mind, I believe it will be very beneficial for the
> proposal that the CA-TF will come up with, to contain the following:
> 
> 
> a. The way Resource Certification will tie into our current business
> processes
> b. The fact that Resource Certification is an additional, opt-in
> member service
> c. That in case of a dispute, we have an Arbitration Process in place.
> During the procedure, we will not reclaim resources, and Certification
> will remain available to the member.
> d. How Resource Certification is aimed at aiding the network operator
> in making routing decisions, and does not enforce anything, also when
>  Secure BGP becomes a reality
> e. The possibilities for law enforcement agencies to take measures
> against the Resource Certification are very limited, if existent at
> all. 
> f. The fact that we will have a Certification Practice Statement that
> reflects this

I really don't think this goes far enough. I think we will have greater
chance of selling the product if we *slightly* decouple the certificates
from the membership status. And the simplest way of doing this is to
lengthen the certificate expiry time.

> 
> Naturally, the RIPE NCC is more than happy to support drafting a
> proposal.

Taken as read...

I suggest we get together early on at Prague, but preferably come up
with a straw man on this list.

Nigel