[Go-essp-tech] [esg-node-dev] Re: Question on P2P and signing of registry docs

Cinquini, Luca (3880) Luca.Cinquini at jpl.nasa.gov
Wed Jun 1 17:28:34 MDT 2011


Hi Gavin,
I think you meant "Estani"...
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 ?
thanks, Luca

On Jun 1, 2011, at 3:57 PM, Gavin M. Bell wrote:

Hi Luca,

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.
All CSRs go to the *single* CA for the ESGF network, which is a subordinate CA for a "well-known-CA".  And Done. :-).

This has the benefit of limiting the litany of CA Certs we have now, that is over-running the poorly designed Safari browser.
If *everybody's* is special -> nobody is special.  Right now the certificate scenario we currently have is not tenable. IMHO

This is, in a nutshell, the best long term solution... which will bear other fruit as well...
I think the underlying issues that people are really concerned with namely sovereignty and partitioning can be addressed elsewhere.

more later. :-)

On 6/1/11 10:38 AM, Estanislao Gonzalez wrote:
Hi Gavin,

to go back a little. How is SSL going to work in the p2p configuration?
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?)

In any case Phil wasn't at the telco, so not sure this got into the mails...

Thanks,
Estani

Am 01.06.2011 19:34, schrieb Gavin M. Bell:
Hey Phil,

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...

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?

We can really get gnarly and lock the whole mesh network down and put it on a VPN.... but how much is too much?

What are your thoughts?

On 6/1/11 5:07 AM, philip.kershaw at stfc.ac.uk<mailto:philip.kershaw at stfc.ac.uk> wrote:

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)" <Luca.Cinquini at jpl.nasa.gov><mailto:Luca.Cinquini at jpl.nasa.gov>
wrote:



Hi all,
        here's the agenda for today's conf call:
http://www.esgf.org/wiki/EsgfCmip5Meetings

And some background documentation on the p2p Node system:

http://www.esgf.org/wiki/ESGF_Index

thanks, Luca
_______________________________________________
GO-ESSP-TECH mailing list
GO-ESSP-TECH at ucar.edu<mailto:GO-ESSP-TECH at ucar.edu>
http://mailman.ucar.edu/mailman/listinfo/go-essp-tech



--
Gavin M. Bell
Lawrence Livermore National Labs
--

 "Never mistake a clear view for a short distance."
               -Paul Saffo

(GPG Key - http://rainbow.llnl.gov/dist/keys/gavin.asc)

 A796 CE39 9C31 68A4 52A7  1F6B 66B7 B250 21D5 6D3E




--
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:  gonzalez at dkrz.de<mailto:gonzalez at dkrz.de>


--
Gavin M. Bell
Lawrence Livermore National Labs
--

 "Never mistake a clear view for a short distance."
               -Paul Saffo

(GPG Key - http://rainbow.llnl.gov/dist/keys/gavin.asc)

 A796 CE39 9C31 68A4 52A7  1F6B 66B7 B250 21D5 6D3E


_______________________________________________
GO-ESSP-TECH mailing list
GO-ESSP-TECH at ucar.edu<mailto:GO-ESSP-TECH at ucar.edu>
http://mailman.ucar.edu/mailman/listinfo/go-essp-tech

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ucar.edu/pipermail/go-essp-tech/attachments/20110601/74f6562e/attachment.html 


More information about the GO-ESSP-TECH mailing list