<p dir="ltr">Interesting.</p>
<p dir="ltr">Den 12 sep 2013 15:09 skrev "Keith" <<a href="mailto:keith@fernie.eu">keith@fernie.eu</a>>:<br>
><br>
> After further thought:<br>
><br>
> With a CA on each freedombox we could have something like this<br>
><br>
> Create a CA using (options used could be changed)<br>
> openssl genrsa -des3 -out "Freedombox CA.key" 4096<br>
> openssl req -new -x509 -days 3650 -key "Freedombox CA.key" -out<br>
> "Freedombox CA.pem"</p>
<p dir="ltr">Isn't this just a new snake oil certificate?  I would like a simple GUI to add CAcert.org certificates, or from any other CA.</p>
<p dir="ltr">Also generate certificate keys that can be imported to web browsers and used to log in on your freedombox web interface. One for each user, and easy to remove.</p>
<p dir="ltr">I think there are work on using PGP keys useful in TLS (SSL), anyone know the name? Think that would more useful and it would be more along your idea, I think.</p>
<p dir="ltr">> Possibly replace any snakeoil keys created by Debian (Postfix uses 2048<br>
> bits, could use 4096 bits if Postfix is the MTA used).<br>
><br>
> Include in Plinth an option for a freedom box to obtain ssl keys with<br>
> the Freedombox CA. No interface to an external website, openssl can do<br>
> this.<br>
><br>
> The public key of the Freedombox CA could be published, to be imported<br>
> into someone else's browser, could be a problem with multiple Freedombox<br>
> CA's with the same name.<br>
><br>
> Possibly a paranoid option to rotate the ssl keys on the freedom box<br>
> running manually and/or as a cron job (Now doing this daily with one of<br>
> my mailservers).<br>
><br>
><br>
> On Thu, 2013-09-12 at 12:05 +0200, Jonas Smedegaard wrote:<br>
> > Quoting Keith (2013-09-12 12:43:28)<br>
> > > Anyone for setting up a Freedombox CA?<br>
> > > This could be added to the freedombox as a trusted CA and usable for<br>
> > > freedombox to freedombox TLS only.<br>
> ><br>
> > Please update subject field to reflect when, well, changing subject.<br>
> ><br>
> > It could, if it is deemed sensible to trust an external entity separate<br>
> > from other external entities with a lot more eyeballs on them.<br>
> ><br>
> > Or, if your idea is that "we" run the CA, I am curious how "we" as a<br>
> > non-hierarchical body deal with such a hierarchical structure as a CA.<br>
> ><br>
> > Personally I would prefer this sliding scale:<br>
> ><br>
> >   common CAs -> CAcert.org -> no CAs<br>
> ><br>
> > I.e. I see no need for creating a new CA.  But am open to (at least try<br>
> > to) understand the reasoning behind your idea. :-)<br>
> ><br>
> ><br>
> >  - Jonas<br>
> ><br>
> > _______________________________________________<br>
> > Freedombox-discuss mailing list<br>
> > <a href="mailto:Freedombox-discuss@lists.alioth.debian.org">Freedombox-discuss@lists.alioth.debian.org</a><br>
> > <a href="http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss">http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss</a><br>
><br>
><br>
><br>
> _______________________________________________<br>
> Freedombox-discuss mailing list<br>
> <a href="mailto:Freedombox-discuss@lists.alioth.debian.org">Freedombox-discuss@lists.alioth.debian.org</a><br>
> <a href="http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss">http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss</a><br>
</p>