<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Hi Gavin,<div><span class="Apple-tab-span" style="white-space:pre"> </span>I think you meant "Estani"...</div><div>Anyway, I like the idea of a single ESGF CA. Can we make it happen ? Maybe at installation time you can be given the option of generating your own cert (so that we don't completely make ourselves depending on a single point of failure), or have it signed by another CA. What would be the best location for such a CA - PCMDI or ANL perhaps ?</div><div>thanks, Luca</div><div><br><div><div>On Jun 1, 2011, at 3:57 PM, Gavin M. Bell wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">
<div bgcolor="#ffffcc" text="#000000">
Hi Luca,<br>
<br>
Just as we do now... at installation you have to setup your certs.
In the installation you generate a CSR... as with everything public
key crypto, you send in your CSR get it signed and get back your
cert and then install the cert (esg-node --install-keypair). Done.<br>
All CSRs go to the *single* CA for the ESGF network, which is a
subordinate CA for a "well-known-CA". And Done. :-).<br>
<br>
This has the benefit of limiting the litany of CA Certs we have now,
that is over-running the poorly designed Safari browser.<br>
If *everybody's* is special -> nobody is special. Right now the
certificate scenario we currently have is not tenable. IMHO<br>
<br>
This is, in a nutshell, the best long term solution... which will
bear other fruit as well...<br>
I think the underlying issues that people are really concerned with
namely sovereignty and partitioning can be addressed elsewhere.<br>
<br>
more later. :-)<br>
<br>
On 6/1/11 10:38 AM, Estanislao Gonzalez wrote:
<blockquote cite="mid:4DE67922.2090305@dkrz.de" type="cite">
Hi Gavin,<br>
<br>
to go back a little. How is SSL going to work in the p2p
configuration?<br>
You said that PCMDI will sign certificate request right? But that
will imply users will have to be confronted with a "do you trust
this CA?" pop up when accesing th UI via SSL, won't it? Or is the
plan to get a CA Verisign certificate for PCMDI? (Is that
possible?)<br>
<br>
In any case Phil wasn't at the telco, so not sure this got into
the mails...<br>
<br>
Thanks,<br>
Estani<br>
<br>
Am 01.06.2011 19:34, schrieb Gavin M. Bell:
<blockquote cite="mid:4DE67835.3080808@llnl.gov" type="cite">
Hey Phil, <br>
<br>
Indeed this was on my mind as well... You are correct signing is
important and should be done. We can start looking into the
mechanics of setting up XMLSec as you suggested. With respect
to security, can we already use the certificate and key present
on the node (indeed, I think we should be able to), right? I
didn't look at XMLSec, I briefly was looking at installing GPG's
library, or a Java crypto library implementation to sign all
payloads... using the nodes' cert/key. But it begs the
question...<br>
<br>
Question, why isn't ssl enough? With an SSL connection don't
you get authentication for "free", which is all we need. If we
trust who it is coming from, can't we thus trust the
information?<br>
<br>
We can really get gnarly and lock the whole mesh network down
and put it on a VPN.... but how much is too much?<br>
<br>
What are your thoughts?<br>
<br>
On 6/1/11 5:07 AM, <a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:philip.kershaw@stfc.ac.uk">philip.kershaw@stfc.ac.uk</a>
wrote:
<blockquote cite="mid:CA0BE6E4.C079%25philip.kershaw@stfc.ac.uk" type="cite">
<pre wrap="">Hi Gavin,
I wanted to be on the call yesterday but unfortunately I've been away at
another meeting. Hello from Pisa :)
One thing I wanted to raise in the context of the P2P architecture was the
registry interface, and the need to digitally sign registry documents.
This is something that we talked about at the ESGF meeting in Asheville.
To restate the problem, any peer can pass to another peer a registry
document containing registry information for itself and for other peers
that it has communicated with. Have I got that right?
The recipient of such a document might accept the registry information
about the sender but how can it verify the registry information contained
in the document that comes from other peers? The only way to do this is
for each peer to digitally sign its registry information. That way, on
receipt of such information, a peer can verify that all the information
has come from the expected sources and has not been tampered with. This
is a must for a production system. It would be a straightforward change
to add XMLSec code to sign content.
Cheers,
Phil
On 31/05/2011 16:01, "Cinquini, Luca (3880)" <a moz-do-not-send="true" class="moz-txt-link-rfc2396E" href="mailto:Luca.Cinquini@jpl.nasa.gov"><Luca.Cinquini@jpl.nasa.gov></a>
wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Hi all,
here's the agenda for today's conf call:
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://www.esgf.org/wiki/EsgfCmip5Meetings">http://www.esgf.org/wiki/EsgfCmip5Meetings</a>
And some background documentation on the p2p Node system:
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://www.esgf.org/wiki/ESGF_Index">http://www.esgf.org/wiki/ESGF_Index</a>
thanks, Luca
_______________________________________________
GO-ESSP-TECH mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:GO-ESSP-TECH@ucar.edu">GO-ESSP-TECH@ucar.edu</a>
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://mailman.ucar.edu/mailman/listinfo/go-essp-tech">http://mailman.ucar.edu/mailman/listinfo/go-essp-tech</a>
</pre>
</blockquote>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Gavin M. Bell
Lawrence Livermore National Labs
--
"Never mistake a clear view for a short distance."
-Paul Saffo
(GPG Key - <a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://rainbow.llnl.gov/dist/keys/gavin.asc">http://rainbow.llnl.gov/dist/keys/gavin.asc</a>)
A796 CE39 9C31 68A4 52A7 1F6B 66B7 B250 21D5 6D3E
</pre>
</blockquote>
<br>
<br>
<pre class="moz-signature" cols="72">--
Estanislao Gonzalez
Max-Planck-Institut für Meteorologie (MPI-M)
Deutsches Klimarechenzentrum (DKRZ) - German Climate Computing Centre
Room 108 - Bundesstrasse 45a, D-20146 Hamburg, Germany
Phone: +49 (40) 46 00 94-126
E-Mail: <a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:gonzalez@dkrz.de">gonzalez@dkrz.de</a> </pre>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Gavin M. Bell
Lawrence Livermore National Labs
--
"Never mistake a clear view for a short distance."
-Paul Saffo
(GPG Key - <a class="moz-txt-link-freetext" href="http://rainbow.llnl.gov/dist/keys/gavin.asc">http://rainbow.llnl.gov/dist/keys/gavin.asc</a>)
A796 CE39 9C31 68A4 52A7 1F6B 66B7 B250 21D5 6D3E
</pre>
</div>
_______________________________________________<br>GO-ESSP-TECH mailing list<br><a href="mailto:GO-ESSP-TECH@ucar.edu">GO-ESSP-TECH@ucar.edu</a><br>http://mailman.ucar.edu/mailman/listinfo/go-essp-tech<br></blockquote></div><br></div></body></html>