CAcert System Admins discussion list

[Iang <iang AT iang.org>]

Evaldo Gardenali wrote:
> Hi
>
> IanG escreveu:
> > I've gone through Daniel's email process and set up the email for the 
> > address above, and got it working [1].   He has set up some 
> > instructions over at the wiki, which we can all follow and improve:
> >
> >     http://wiki.cacert.org/wiki/CommunityEmail
> >
> >
> >
> > It's probably worthwhile to recall why he is doing this.


It turns out that there was a lot of early documentation of 
this at

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

(I've just done a little tidy up on that...)


> > At the 'top' there was a discussion about setting up better support 
> > for encrypting email, a little because of general threats to our email 
> > [2] but mostly because as a CA we should be able to show we can do it, 
> > comprehensively.  "Eat your own dogfood" the Americans say.  A way to 
> > meet our mission.
> Community Emails are not going to accomplish that. Adoption of X.509 
> will. Unless we are not X509 providers anymore, and we now are email 
> service providers.
> This goes exactly the opposite direction of X.509, which means we should 
> issue certificates for people to use on their own servers and their own 
> accounts.


What you ask above is a mission question.  You are presuming 
one view of the mission, whereas adoption of community 
emails would imply another view of the mission.   As the 
mission discussion was never concluded, neither view is 
right or wrong...

wip collections of the mission variants are here:

http://svn.cacert.org/CAcert/principles.html


> > Encrypting everything somehow conflicted with another discussion about 
> > escrowing official email, coming out of the Arbitration and Threats 
> > discussions.  Escrow was considered to be a serious benefit if we ever 
> > get hit by legal discovery, because the email is then already 
> > collected. This will save us a heap of bureaucracy [3].
> Escrow should be handled in a different way: just set your mail client 
> to BCC escrow AT cacert.org (with a valid certificate) by default, and keep 
> the private key safe, so it is escrow not leakage.


See the above discussion as to why it was decided not to do 
that.

(At the 'top' it was decided to handle it this way.  Now, we 
can object, but it was a board decision.  So we need to get 
that overturned at the board level.  Possibly with a 
proposal.  But first let's consider the proposal that is in 
place!)


> > =============
> > 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.
> > =============
> >
> > As we know, encrypted lists are a "hard problem".  The rough high 
> > level design was felt to be using CAcert servers as the IMAP/POP/SMTP 
> > servers for all official traffic.  This way, we could do both 
> > encrypted mail (over TLS) and also do the escrow part (by central 
> > capture).
> You are referring to a different problem.
>
> Encrypted list: Sympa is an awesome mailing list manager, used by many 
> universities and big companies worldwide. I have referred Duane, 
> Philipp, and others to Sympa a few times, and I mentioned that to the 
> Board as well. It also implements browseable archives and a lot of 
> features we would find interesting.


OK, I should have said encrypted email to a group of people 
is a "hard problem."  This present email to the above 
(informal) list is not encrypted over its whole path.

(x.509 doesn't solve that, maillist software won't solve 
that, and neither does the current proposal.  They all go 
some way to solve it, some more and some less successfully. 
 As far as I can see the current proposal goes the furthest.)

I'm not sure why you bring up Sympa.  Why would it address 
the encrypted list problem?  My email to it won't be 
encrypted, nor its email to me.  (Unless you are assuming 
webmail, and I don't and won't use that.)


> > The first phase of this work is now complete, there is a complete 
> > setup of encrypted servers available.
> And what good is it for? I fail to see the benefit of "encrypted 
> servers" in "encrypted emails" scenery. It just does not fit. End-to-end 
> encrypted emails are safe, even if you publish them to newspapers. 
> "encrypted servers" just gives us FALSE SENSE OF SECURITY.


Encrypted email gives a false sense of security, period!

It doesn't matter what technology is used, the other person 
can always put it in a newspaper.  Did I mention that 
encrypted lists are a hard problem?  One reason is that the 
security goes down, the more people on the list.  That's 
regardless of the technology.


> > This leaves some phases left.
> >
> > 1.  the escrowed system as mentioned in m20070920.2.
> Easy, just create an account, a certificate, and tell people to set 
> their email clients to (B)CC by default.


That is likely what will be asked, sure.  But it's not a 
complete solution, because it is only a technical solution 
to a complicated human problem.  Have a look at the proposal 
for some suggestions as to why that won't work.



On to point 3.

> The whole @community.cacert.org will create a management nightmare. 
> Again, we are CAcert, not Hotmail nor Gmail.



There appears to be a confusion which I've also fallen into. 
 The sense of the word Community might have been 
interpreted to imply the whole community.  Understandably 
enough, and I asked what that meant above.

Refer to the proposal for what was really intended.  The 
word was chosen somewhat to suggest in the direction of some 
wider purpose, but the word can be ignored or changed.


> > 3.  a related initiative to give wider access to the community access 
> > to this sort of protected email.  The current working title for this 
> > is community.cacert.org.  Who then is to be given this access?  Full 
> > Assurers?  All Members?  150 point Assurers?
> Did we change our focus to be email provider? that creates a whole lot 
> of new liability problems and DPA issues. Does auditor like that?


As to whether we should provide email to the community:

1st, Mission discussion.
2nd, can you indicate the liability problems?
3rd, DPA.  Good point.  I can imagine some solutions ... but 
I'd prefer to see the mission discussion resolve whether it 
even exists as a problem first.


> > For these items, there are a lot of details to work out.  Of course, 
> > all this can change.  But the basic work done so far is good and useful.
> Good and Useful to what purpose? I see they are good and useful if we 
> become email providers.
> > Meanwhile, all, it will help to setup your email addresses so we can 
> > move over to this method, as per the decision(s) agreed at 'top'.
> The details seem to be a bit overlooked here, and I fail to understand 
> it as a coherent design. Where are the plans for me to examine?


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


> And this remembers me... Who decided that we'd open 
> community.cacert.org? Who saw the proposal presented before it went live?


It isn't open.  Nobody decided.  The proposal to open it 
hasn't been presented, AFAIK.

iang