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

["Vasily Dolmatov" <]

 

> -----Original Message-----
> From: Leo Vegoda [
	    
	    
] 
> Sent: Wednesday, February 28, 2007 1:23 PM
> To: Vasily Dolmatov
> Cc: 'Martin Papik'; 'Henk Uijterwaal'; 'Andrew de la Haye'; 
> ca-tf@localhost
> Subject: Re: [ca-tf] Next steps & Write-up of the CA-TF 
> kick-off meeting
> 
> Hi Vasily,
> 
> On Feb 28, 2007, at 5:58 PM, Vasily Dolmatov wrote:
> 
> [...]
> 
> > 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.
> 
> Can you please expand on this. I suspect that using the LIR 
> Portal - or something based on it - would be an excellent way 
> of getting widespread take-up.
> 
"widespread take-up" - yes. 
"legal meaning" - no.

It was explained in the skipped text. ;)

In brief: There is no way to _ensure_ that certificate was taken by proper
person.
There is crucial difference between "Leo Vegoda with valid passport in hand"
and "someone who connected to the Portal using two text strings, which some
time ago were sent by e-mail to someone who wrote he was Leo Vegoda".
So, certificate generated in the first case can legally represent Leo Vegoda
(provided another lot of conditions were met), certificate generated in the
second case can represent _nothing_ and _noone_. It will be issued and
transferred to _unknown_person_ who happened to posess knowlegde of pair of
text strings in given moment of time. No claims concerning following actions
using this certificate can be considered either legally or logically.

The trick is that "security is a chain" and security is so hard as hard is
the weakest link in this chain.
Web authentication via login/password pair is _weak_. Period. 
It can be (and is) enough for tasks performed with LIR portal now, but this
procedure has no trust in it, so no secure procedure can inherit this trust
from it.  Because of absence of this trust. Nothing to inherit.

That is the reason why I continue to ask about GOALS.

If we have a goal to implement legally meaningful system - we cannot use LIR
Portal for start of it.
If we have no such goal - we can use LIR Portal, but then the question arise
again: "What are we implementing certificates for?"
Starting from LIR Portal they cannot give us more trust (see above), as for
security - it is necessary to deduce which procedures will become more
secure with certificates (which were issued with _same_level_ of trust as in
the current system) as compared with current situation when information is
circulating without using of certificates.

There is basic item in information security: "threats model"
One need to start securing information system from understanding which
threats it is opposed to, which threats are significant and should be
defended from and which threats are unlikely or not so dangerous so can be
ignored.
After that it becomes possible to design security system and implement
various security technologies.
Any security system design is a tradeoff between security and usability and
one should clearly see and understand what threats were ignored and why. ;)

As I can see now, when struggling with threats
 -  that someone can claim that some operations with resources which were
assigned to him were performed without his knowledge and against his will
and he consider RIPE NCC legally responsible for the consequencies and
possible losses
 - that someone can decline responsibility for some evil operations which
were performed from IP-space assigned to him
 - that there will be resources which assigned to someone with whom there is
no possibility to communicate by RIPE NCC
 - (which are other?)

One have no or little help from implementation of "hard certificate system"

First threat is eliminated with proper authentication procedure when making
operations (there are a bunch of authentication methods and certificates are
only one of them and "hard certificates" are the very special branch of
certificates) and inserting proper clauses in the agreement between RIPE NCC
and LIR in order to avoid possible suing.
Second threat has really no connection with certificate problem at all...
Assigning some IP space to a LIR in order to be further used by clients of
this LIR gives no legal possibilities to force LIR to make something, using
certificates or not. ;) This threat should be struggled with by other means,
maybe by cooperating LIRs around some kind of CERT or something.
Third threat is again not connected directly with certificate usage,
implementation of certificates maybe a good occasion to clean up "dead
bodies" from the database, but that could be done without certificates as
well, another good occasion is prolongation of contract with LIR, which
takes place on yearly basis. Either it is said that "there will be no
certificate to those whose contact data is invalid", or "there will be no
contract prolongation to those..." Certificates are just the cause for
action which has no direct connection with certificates.

If there are other threats which could be addressed with implementation of
"hard certificate system" please, lay them on the table for considering. ;)

dol@




> Thanks,
> 
> --
> Leo Vegoda
> IANA Numbers Liaison
> 
> 
> 

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