CAcert System Admins discussion list

[Iang <iang AT iang.org>]

(Sam seems not to be on this list and his post didn't get 
approved.  But here's a response.)


> I would prefer to see us cut back on the sysadmin load as much as 
> possible


Concur.  We need a lot of simplification.  We are moving
towards a bigger team of sysadms, where each different
person manages a smaller task.  That's hopefully what we
have with Daniel, who is (AFAIK) just handling the email.
This means he takes that small load of Philipp;  the
intention is to find many more sysadms to also take the
loads off.

Email is the one area where this process is working, so
don't mistake the current activity for problems !!


> as however you look at it it's a risk, and a lot of the work 
> done by the team currently is just keeping the lights on (Gartner's 
> famous $8 in $10 of wasted IT spend). This would allow our very limited 
> resources to 'move up the value chain' and focus more on things that 
> differentiate CAcert rather than bogging them down with unnecessary tasks.
>
> On the other hand we absolutely need to get serious about our records 
> management as the current situation is far from where we need to be - we 
> have between 1,000 and 10,000 assurers maintaining their own 
> repositories containing information that we're not even necessarily 
> allowed to have (copies of IDs, etc.), plus email exchanges invariably 
> containing personal information, and if we ever needed to find something 
> to defend ourselves we could land in hot water.


(There are two aspects:  Assurers maintaining own documents
on paper.  Assurers maintaining digital copies or making
digital communications (email).)


> For this assurers need to be given a address (ideally @cacert.org 
> <http://cacert.org>) and they need to use it for 'official' work like 
> assurances.


Well, ok, I understand what you are saying.  However, "need"
is a strong word.  Some points.

-1. The Assurance Policy (wip) states that Assurers can
allocate full / 35 points if they check the email address.
This is controversial, some people don't like this idea, so
it is a bit of a leap to say it is needed.

-2. Secondly, the point of this was to bolster the email
checking of the primary email address, as this is required
for establishing the statement in the AP.  Now, a threat is
that an automated system is easy to defeat if you really
want to.  A way to overcome that is to use a completely
uncorrelated approach.

Basically if we can use an unknown email address to send a
non-form letter, then we can potentially create that
uncorrelated approach.  This expands the whole search
envelope of an attacker, which makes it a lot easier to spot
attacks.  E.g., if I send a private email from 
iang@iang
 to
you saying "Beware the Jabberwock" and you reply saying
"Beware the Jubjub bird" using your email address, then that
becomes very hard to address in an automated attack.

However, if 
iang@cacert
 is used, there is a potential handle
to scan for attacks.

Neither of these are killer arguments.  We may still
conclude that even with these difficulties, having every
assurer have a cacert.org address is a good idea.  So:

+1.  There is a requirement emerging for the CAcert Assurer
to prove (as in, provide evidence) that he or she is indeed
a CAcert Assurer.  I had imagined this by way of a web
query.  But, the presence of an email address may do the
same thing;  email from 
iang AT assurers.cacert.org
 could be
reasonable.

+2.  There is an idea floating around to give people in the
community email addresses at community.cacert.org.  So this
idea may mesh nicely into that.  Caveat:  it is again
controversial :)




> This then need to be archived by a 'real' archiving solution 
> like Postini (who, incidentally do have SAS 70 Type II, ISO and WebTrust 
> audits under their belt according to a talk at the Google Enterprise 
> partner conference in Rome this week). It needs to work and work well, 
> or it will be circumvented or deter people from acting at all. We need 
> this both to justify the work of our assurers as well as to protect them 
> from outsiders.


An alternate view:   No check is perfect.  This is why
CAcert gains its strength from several assurances, not from
single processes.  This is the web-of-trust argument;  if we
can have people checked by 2 independent assurances, that
has some strength that can never be emulated by one careful
check (and vice versa).  So while improving the basic checks
to be more careful and more "defended in depth" is a good
idea, our intention has been to go for defence in breadth
before defence in depth (so to speak).

Or, in simpler words, if we think 2 assurances isn't strong
enough, we could (a) use more assurances and/or (b) improve
the uncorrelation of the existing assurances.



> CAcert may not be Hotmail or Gmail but it could use the latter with 
> Google Apps (SAS 70 Type II apparently in the pipeline), were it not for 
> internal opposition. It's a publicly available free solution and I've 
> already offered to see about getting the education edition 
> (~=$50/user/year) for us as a non-profit, allowing us to wire 
> provisioning and authentication up to the cacert.org <http://cacert.org> 
> interface. We're not going to get to see the source code, except perhaps 
> via an auditor we could never afford, so unless we adjust our 
> expectations accordingly we will miss out on this incredibly powerful 
> tool and will be essentially stuck in the dark ages.


Prose aside, other people always have more powerful tools.
I'm too old to listen to "grass is greener" arguments ...
what specifically does this system do that we can't do?


> In terms of 
> privacy, Google subscribes to Safe Harbour which satisfies the EU 
> Directives and in terms of liability it is hard to imagine that we would 
> be found liable for choosing Google, while we well could if we for 
> example fail to patch an open source product.


I'm confused when you talk about Google and privacy.  They
are well known as the vacuum of the world, and they are
likely breached by all sorts of agencies in their own
country.  Legal approaches bypass the Safe Harbour process,
in general.


> Thus I propose that we:
>  - give our users a known good solution rather than a patchwork of DIY 
> concoctions (most probably gmail anyway)


Hmmm... bear in mind that there is a plan in progress on
this issue.  It was requested by the board and is in the
minutes:

http://wiki.cacert.org/wiki/TopMinutes-20070917
=============
m20070920.2: Agreed to ask that the new email system can be
set up to automatically archive everything on "official"
lists. Privacy officer to be consulted before actually
implementing it.
=============

This was backed up by some logic and planning here:
http://wiki.cacert.org/wiki/PolicyDrafts/EmailHandling
and current documentation for users here:
http://wiki.cacert.org/wiki/CommunityEmail

I think one main concern is that if official or
semi-official mail is not under the control of CAcert, this
makes for a headache in privacy, audit and credibility
terms.  Sure, we can do something about that, but right now
we have chosen an internal path.

One other thing being that ... all suggestions welcome, but
suggestions *after* a lot of hard work has been done are
generally less hopeful ;)


>  - archive the important data for 5 or 10 years (eg assurances and 
> organisation assurances)


Is that more an Assurance Policy issue?  Possibly best
addressed on the Policy list, and with reference to the AP here:

http://wiki.cacert.org/wiki/PolicyDrafts/AssurancePolicy


> Sympa is a great mail server (I use it for The System Administrators 
> Guild of Ireland) which can be wired up to the database but so is Google 
> Groups and it's one less thing for us to lose sleep over. In any case we 
> should use the latter for archives as whatever happens to our systems we 
> won't lose our 'corporate memory'.
>
> As for encrypted mails, encrypting the transports is likely better than 
> what we have and won't interfere with our workflows. Encrypting mails 
> sent to escrow addresses could be sensible except it is at the cost of 
> legal discovery by search, and if it's not enforced then it won't happen.


Good to see some brainstorming :)



iang