Policy-Discussion

[Philipp Gühring <pg AT futureware.at>]

Hi,

> OK.  Well, I'm surprised that wasn't part of the audit
> process.  Huh.  Maybe I'm not surprised :)

The audit process isn´t finished yet. So there is no reason to be surprised 
yet.

> > Data points to uniquely identify people as govt issued ID and other
> > things aren't a good way to uniquely identify people, nor something
> > desirable to keep on file either, so it's a case of damned if you do and
> > damned if you don't...

That´s why we try to handle it as secure as possible.

> 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?

>     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.

> 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.

?

> 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.

> Either way, whatever the reason, without understanding
> it, it won't be possible to create policy in a cohesive
> fashion.

:)

> > 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?

> 2.  who can get access to this information?

everyone who is authorized and can proof the need-to-know.

> 3.  what can we do to protect it?

hide it, encrypt it, do not digitize it, store it, ...

> 4.  in what forms does the info exist and what are
>     the regimes for each piece of info?

We even have a formal specification for that! It´s the sourcecode.

> 5.  do we key everything on some external
>     datum or on our own internal number?

?

> So let's say I'm an attacker and I want to get the scoop on
> someone.  

What exactly is your aim?

> 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.

Regards,
Philipp Gühring