RE: [ca-tf] Next steps & Write-up of the CA-TF kick-off meeting

["Vasily Dolmatov" <]

 

> -----Original Message-----
> From: ca-tf-admin@localhost [
	    
	    
] On 
> Behalf Of Leo Vegoda
> Sent: Wednesday, February 28, 2007 6:13 AM
> To: Martin Papik
> Cc: 'Vasily Dolmatov'; 'Henk Uijterwaal'; 'Andrew de la 
> Haye'; ca-tf@localhost
> Subject: Re: [ca-tf] Next steps & Write-up of the CA-TF 
> kick-off meeting
> 
> On Feb 28, 2007, at 2:32 AM, Martin Papik wrote:
> 
> > I totally agree, we need clear goals or we're doomed. Some of the 
> > goals are listed below (in random order). Please add 
> anything I left 
> > out. And not all need to be a part of this project. Right 
> now we need 
> > to clarify what this project will be about, what we're 
> going to put a 
> > chunk of our lives into.
> >
> > The actual goals:
> >
> > * Better accuracy of data regarding IP address allocations
> > * Legal accountability of IP address usage
> > * Increased routing security
> 
> The system in place now reports the last known information 
> held for the 'registrant'. That doesn't really scale to an 
> Internet with tens of thousands of ASs. It is also unlikely 
> to provide the legal certainty needed by resource holders in 
> an age of scarcity. If we move to a certification system it 
> needs to certify that the certificate holder has a right to 
> use the resources that are certified. Whoever controls the 
> certificate needs to be able use it to assure other people 
> that they can authorise the use of the resources and the 
> transfer of the resources.
> 
> I think that means that accurate registration data, legal 
> accountability and better routing security should follow 
> automatically from a system with a hard certification of a 
> right to use resources.
> 
As it was already mentioned during the meeting, different goals require
different designs of certification system.
It is correct that if "maximum" system is made, then all goals will be
reached.

From the other side, "system with a hard certification" is quite complicated
for design and implementation even inside one well managed enterprise, and I
consider such system as impossible in the RIPE (and any other RIR)
situation.

"System"  - means not only CA, whish issue certificates, but a lot of
measures and procedures which are targeted to ensure trust of issued
certificates. Failure to implement even one from that lot of procedures
immediatedly waives any legal significance of issued certificate.

That was the reason why I asked about the goals of the system. If it would
be agreed that primary goal is to implement "hard certification" I
immediatedly become very pessimistic about perspectives of this project.

I consider this goal unreachable in the current situation and in the nearest
perspective, this could be stated as a "strategic goal" indicating the
movement of RIPE NCC towards global digital society, but it cannot be set as
a short-term (1-2 years) or long-term (3-5 years) goals.

I enumerate just a few implications of "hard certification system" which we
are not ready to deal with in the current state of affairs:

In "hard certification system" 
 - certificate can be issued only to person (not to enterprise as a whole),
so database of responsible staff of all LIRs should be maintained
 - certificate cannot be issued virtually (responsible person must meet
requestor "eye-to-eye" and check his/her identity against set of paper
personal IDs before issuing certificate)
 - certificate can not be transferred to other person
 -  private keys must be created and handled in manner which excludes
possibility of their duplicating or misuse (storing them in the file"with
passphrase protection" is not even considered)
 - certificates should be immediatedly revoked when given person leaves
given LIR, that means procedures of resigning LIR objects

There are a lot of other implications, and as I think it is impossible and
unwise to try to implement now "hard certification system" in the RIPE
community.
 As it was said above, not following the even the only one of known rules of
building of "hard certification systems" ruins trust in this system
completely and this system become _an_imitation_ of "hard security system".
I doubt that it is the goal of this project. ;)

Certificates are an element of  "system of trust" (crucial one, no doubt),
the "system of trust" is the means of making "something". 
Let us understand clearly _which_ "something" we want to make and what kind
of "system of trust" we need in order to achieve this "something". 

Let me repeat, I consider that setting the creation of "hard certification
system" as current goal (or even as a second-stage goal) is unrealistic,
because of:
 - srtucture of "hard certification system" will immediatedly come into
conflict with current srtucture and principles of operation of RIPE
community
 - releasing some principles of "hard certification system" in order to make
it compatible with structure and procedures of RIPE community creates an
_imitation_ of "hard certification system" which will claim that trust and
security is maintained, but there will be _no_ trust and _no_ security in
this system (being exact, the level of trust and security will remain the
same as before, but a lot of efforts will be spent and lot of implications
will be imposed on the participants of the system)

For instance, if it will be possible for LIR to get certificates, using
current web-portal and current authorisation scheme - it will never be "hard
certification system" and these certificates will never have any legal
meaning.

I want to state separately, that I consider that implementing of "hard
certification system" inside RIPE NCC for increasing trust to everything
which is sourced by RIPE NCC is quite a reasonable task and it is _real_ to
implement. It is possible to design and properly operate such a system with
hard certification for RIPE NCC staff and RIPE NCC operations.
First possible outcome of that could be the signing of route objects in RIPE
NCC database by RIPE NCC, thus eliminating possible threat of "phishing" of
whois.ripe.net in order to desorganize routing. This will be the real
increase in trust and security, which seems reasonable as a first step.

(TBC)

dol@
> 
> > Supportive goals:
> >
> > * design/build infrastructure, both technical (CA, 
> protocols, etc) and 
> > non technical (policies, procedures) to support the certification 
> > process
> > * document policies, procedures, typical examples (small ISP, large 
> > telco, multinational company, etc.)
> > * make it a viable option for everybody
> > * make it a desired choice for most
> > * educate people why they want it (even they've never heard of it,
> > especially)
> > * decide on data validity hierarchy (e.g. WHOIS supplemented by 
> > certificates or vice versa)
> > * do a case study of what segment of resource holders would 
> cooperate, 
> > which would not and why (for both answers if possible)
> > * design the transition between the current state and the 
> desired end 
> > result
> > * consider technical implications and requirements (data 
> availability, 
> > fault tolerance, data access)
> > * consider non-technical implications and requirements (legal 
> > responsibility, disputes, penalties, changes to existing 
> procedures, 
> > question of IP address ownership/sale)
> > * eat a lot of good lunches and dinners in good company, 
> have fun and 
> > be merry
> 
> These are all god goals.
> 
> Regards,
> 
> --
> Leo Vegoda
> IANA Numbers Liaison
> 
> 
> 

Attachment: smime.p7s
Description: application/pkcs7-signature