CAcert System Admins discussion list

[Daniel Black <daniel AT cacert.org>]

On Fri, 5 Sep 2008 08:25:51 am Sam Johnston wrote:
> Or just work the mail delivery components into the website and ban assurers
> from communicating with CAcert 'clients' directly - they already need to
> access the website for the assurance itself so why not for other
> communications?

I was assuming discovery was for officers of cacert more than assurers. I 
could be wrong.

The legal processes/communications amongst arbitrators is perhaps more of 
risk.

On Fri, 5 Sep 2008 01:28:09 am Kim Holburn wrote:
> Just some thoughts.  Sorry for the questions.
>

thoughts and questions welcome.

> I think that you're looking at this as a technical problem.  It is at
> least in part a social/policy problem here.  Most sysadmins can get
> around stuff and it's probably hard to stop them.
>
> I'm not familiar with your setup but how about the carrot approach?
> Provide an authenticated smtps server so people can send cacert mail
> from anywhere.  Perhaps you have this already?

yes: http://wiki.cacert.org/wiki/CommunityEmail

> To extend it you could 
> allow people with cacert emails to register other email addresses just
> like gmail?

If that's something that people want and its accepted by MSC and someone has 
the time to develop/maintain/support it thats fine.

I should point out that i'm happy for people to use gmail to pull cacert mail 
to gmail (other's may not but I am) if that is their prefered email client. 

Copying emails into a gateway that CAcert controls is easy. The hard bit is 
for clients like gmail that don't allow a setting to send through a specified 
gateway. Or for clients to just send through their ISP (though most email 
clients support auth smtps).

Enforcing this is either the carrot - hay you need this to save your laptop 
from being siesed (legal discovery)
Or the stick " If you send though other email servers (such as your ISP's 
servers) your email may be dropped in the future." (wiki:CommunityEmail). 

This stick is a combination of SPF/DKIM that mitigates spoofing by forcing a 
authenticated gateway to be used, and hence gaining an archive at the same 
time.

> This would allow people to use it for all their mail. 
> Too much info?  You could only archive emails with cacert addresses in
> the header.

I'm not sure that would satisify those who what all the goodness that gmail 
offers, and that me as a single admin cannot hope to deliver. While once 
solutions is to just go to Google Apps there are others that have different 
workflow/values/paranoia .

> e-discovery law is changing anyway, I don't think you can guess what a
> court or an opponent in court might ask for in the future.

Good preparation is an insurance policy against hard work.

> You could mandate that all business emails are digitally signed. 
All should be DKIM signed if they are sent through the gateway. Look at the 
headers of this one. You were probably meaning PGP/X509 however the effect is 
the same. Some supporting evidence of what has been sent and what has been 
forged.

> Has the idea of digitally signed emails been tested in court?
don't know. It should be easy enough to gain some credibility in it. There 
are 
issues with expiration of certs, key rotation etc etc that would need to be 
explained.

> Does a digital signature require an email client to communicate with a
> key-server to verify it? 
I don't think email clients support that currently. It would be nice. There 
is 
usually a key repository locally that the user manages by fetching PGP keys.'
X509 certs are included in the email and the client needs to verify the 
certificate chain. DKIM has a public key in DNS (or should be 
http://bugs.cacert.org/view.php?id=545).

Digital signatures is a little out of scope for legal discovery. Has 
ramifications of verification of discovery but not discovery itself.

> Does CACert run a keyserver?
no. Should it? What form/type/benefit?

-- 
Daniel Black 
(daniel AT cacert.org)
Email Administrator

Attachment: signature.asc
Description: This is a digitally signed message part.