Policy-Discussion

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

Hi,

> OK.  So should "knowing them for a longer period
> of time" be entered into the CACert process?

No. It can´t be a requirement.
But it´s already documented in the handbooks that it helps to know someone 
before.

> And therefore, we do not guarantee that we've
> proven the identity of anyone, because such is
> an impossible statement?

We have not proven the identity, we have verified it.

> The reason for this tortuous introspection is that
> it then clears the way for establishing different levels
> of surety or risk.  Without that we are stuck with the
> myth of all CAs being equal, and all certs being
> equal, and every day being Christmas.

I don´t see the association here.

> > The only information kept (Except for TTP) is Name and date of birth. 
> > Assurers have types of ID used, which is basically pointless for useful
> > information. Everybody knows they types of ID another person is likely to
> > have.
>
> So nobody else is capable of auditing the process
> conducted by the Assurers?

Verifying the identity of a human is completely pointless. Humans are living 
creatures, so they change themself every nanosecond.
So let´s forget everything, and do something else ;-)

> What happens when Head Office decides to
> check randomly the assuring of some subscribers?

Yes, we are starting that.

> What happens when the spooks finger Mr lin Baden
> as a bad guy, and the office in deepest darkest
> Klapistan declines to answer as to what copies of
> the ID used it has, and how it was checked?

Then the points awarded will be revoked, the issued certificates will be 
revoked, ... (long procedure)

> > I'm not sure how much information there is to 'protect' for Web of Trust.
>
> Duane covered this - Name, Address, DOB are all
> good and useful for Identity Theft, the current top
> of the pops that's sweeping America.

Can´t America care for itself?
I mean, they are old enough now.

> Not very.  But the current climate doesn't make that
> much of an excuse, the current thinking is that if you
> don't have a need for data you shouldn't store it.

Yes, prooving the need to know is the best possible measurement here, I think.

I think we should start thinking about doing real end-to-end encryption and 
authentication. Perhaps there is a good way somewhen to do it.
(With end-to-end I mean brain-to-brain. Computer-to-Computer isn´t end-to-end)

Real end-to-end public key cryptography would be a solution for most of the 
identity fraud things we have at the moment.

> OK.  Is the assurer listed anywhere?  Ah, yes I see
> you say below he is listed on the website.

The assurers can list themself on the website, if they want. They don´t have 
to.
It is not published by CAcert, who are the assurers of a specific user.

> > 1. Become an assurer, Convince the person who you assure to let you copy
> > the entire of their ID's information down or photocopy it. 2. Bride one
> > of the CAcert Office administrators to give you information. 3. Break in
> > a steal information from the CAcert office
> >
> > 1 is likely to get you as much information, probably less than simply
> > stealing somebodies wallet. (You should look into pick-pocketing)
>
> 1 is a great start to identity theft.  In America, what a person
> has with them or is in their head can be used to acquire a
> credit relationship that would buy a new car for example.

But I don´t need a new car. I am happy with my current one.

> 1.b Another possibility is to *pretend* to be an assurer.  How do
> I know that you are really an Assurer from CACert?

By looking on the website, searching for that assurer, and verifying the 
identity of the pretending Assurer.

> > 2 & 3 is likely to get you more information if people have sent a copy of
> > their passport information in.  This is a little dangerous. Physial
> > security as always is important here.
> >
> > If you really wanted gain, you wouldn't steal info about a person, you
> > would get the root private key and start impersonating people.
>
> 4.  OK, so this is the classical weakness of CAs.  Steal the
> root key and take over all the identities.  I'm guessing this
> one is covered.

Yep, that´s covered.

Regards,
Philipp Gühring