Policy-Discussion

[Ian Grigg <iang AT systemics.com>]

On Friday 22 July 2005 09:52, Philipp Gühring wrote:

> > There's a sort of unwritten law in PKI that PKs can
> > only be given to 'people' (which in this context means
> > natural people and legal people or companies).  It
> > may be that what CACert is really saying is that:
> 
> >     a.  CACert provides certificate issuing for people.
> 
> Do we have a policy on robots yet?


Well, this is a deep problem that PKI assumes away
as "nonsensical" but it is no such, indeed it is better
off being characterised as a PKI bug.  Software creating
keys and using them is a valid exercise, and some of
the best security work has been done in that direction.

So what I'm trying to say here is that the assumption
is better off being stated ... because it then leads us
naturally to the statement that we need to identify
people.

(And, when I say I want a cert for my robot, what
does CACert say?  Does it say "you cannot have
a cert from us because we only do people" or does
it say "you can only do a non-identifying cert
because identity is only for people" or maybe
"the cert must identify you"  ... hours of fun there!)

> >     b.  in order to do that, CACert must satisfy itself
> >         that all "members" are people.
> 
> Since CAcert is an organisation, we shouldn´t mix the organisation members 
> with the CA subscribers.

Is there a glossary?  Sure, subscribers.

> > Or it may be something else?  But consider, if it is
> > just (b) then it would be plausible to do it in a different
> > fashion.
> 
> ?

It's easy to identify people as people without
knowing their names ;-)

> > Or maybe CACert is taking the *pragmatic* approach
> > which is to say we have to identify people in a strong
> > fashion, because otherwise we'll never get anywhere
> > in the community of CAs, and that is critical to our
> > acceptance in the future?
> 
> Yes. I guess pragmatism is necessary to get along with the over-engineering 
> that can easily happen in that branche.

Right.  Now, if that is CACert's mission - to get certs
out to the users such that it meets the needs of the
community of CAs, then that's a different objective
or mission than identifying users.  Maybe one drives
the other, but not always.

> > > But for other people to verify IDs there needs some unique key fields to
> > > enable them to do this.
> >
> > Then there are a bunch of questions:
> 
> > 1.  what is the best way to 'identify' people?
> 
> We are still searching for it. Have you found it yet?

That depends on why you are trying to do that :-)

If you mean "identify to the satisfaction of the CA
community" then that's one standard.  If it is "identify
to banks' standards" that's another standard.  And
another would be governments.  I might rather
you just stick to "identify as people" but I'll bet
nobody else much cares for that.

Let's consider the first.  CA community.  In those
cases, they do their identification according to a
metric that they themselves design.  So one CA
does it to by checking passports, and so forth,
and another does it by confirming that a payment
went through on a credit card (which might not be
in the same name....).

So it suffices - strictly and logically - to create an
ID check that exceeds all of the above.

And, as a practical compromise, it might be reasonable
to set a standard of ... say ... better than 90% of other
CAs.  Or whatever.  But the benchmark is now clear,
the other CAs.

Alternatively if you want to beat the banks, then look
at what they do.   Same with any other comparison.
But it all starts with why you are trying to do this,
which leads us to some sort of standard.


In other mail you said:
> > > A CA has to provably verify the identity of a person / organisation.
> 
> > OK.  Is that referenced anywhere?  Is there something
> > that says anything about how to do that?
> 
> I guessed that it is obvious.


Not at all :)  Certainly I don't think other CAs expect
to provably do anything.  It has been commented
many a time that they do "stuff" and not much of it
is intended to be of service to someone who's an
injured party.  As in, we know or suspect that nobody
has ever been "paid out" as a result of fraud, but the
amount of fraud attributable to spoofing is about a
billion a year (some would argue this point, others
would say it is exactly the point....).

We can also be pretty sure that the identity of a person
has rarely if ever been tested under some sort of
aggressive scenario.  Which means that "provably
verify" is just words - nobody's ever tested it.

> > So let's say I'm an attacker and I want to get the scoop on
> > someone.  
> 
> What exactly is your aim?

Unfortunately, my aim is flexible and moving, because
I represent all attackers.  Right now, I want the details
on some individual - all I can get, and I don't care really
what I get.  This tends to approximate anyone who's under
investigation by any public or private attacker.

> > How would I do that?  Become an assessor and 
> > just access the database?  Bribe an insider to reveal it to
> > me?
> 
> Good question. I guess we will have to try it to find it out.


Certainly a test to run.

iang
-- 
Advances in Financial Cryptography, Issue 2:
   https://www.financialcryptography.com/mt/archives/000498.html
Mark Stiegler, An Introduction to Petname Systems
Nick Szabo, Scarce Objects
Ian Grigg, Triple Entry Accounting