<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Hi,<br>
<br>
Maybe I got everything wrong, so please correct as required. I don't
think the problem is about the "payload" itself, but more about
securing what each node asserts about themselves. So very abstractly
seen we *want* to have this:<br>
<br>
_channel [SSL secured]<br>
_payload - [non secured xml or whatever the manager uses to connect
nodes in the p2p]<br>
_nodeA_services [xmlsec signed by nodeA]<br>
_nodeB_services [xmlsec signed by nodeB]<br>
_nodeC_services [xmlsec signed by nodeC]<br>
<br>
So that you can't play with the assertions performed at nodeA unless
you crack it's private key. The weak link is probably the SSL
connection, but as Phil mentioned you will just falsify one Node at
most... to falsify all of them it means you can break RSA (or
whatever we use) so probably you should better be targeting banks
than us :-)<br>
<br>
XMLsec is, AFAIK, just a way of signing an xml file (or in our case
part of a file) and embedding the signature in it. The certificates
I'd assume are centrally signed so only the CA should be trusted (as
I said, this certificates does not require to be the ones used in
the ssl connection). So you might trust any node it gets a CA signed
cert not found in the CA's CRL (I hate acronyms, sorry for that).<br>
<br>
Thanks,<br>
Estani<br>
<br>
Am 07.06.2011 00:39, schrieb Gavin M. Bell:
<blockquote cite="mid:4DED571F.50107@llnl.gov" type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
Hi, <br>
<br>
By the way, to date I am still ignorant about xmlsec, however, I
think it may be worth knowing that the xml that is sent around
from client to server is not just xml but the payload of an
encapsulating transfer object. Indeed we can/should secure this
payload, but I thought that this would be good information to have
to better contextually set the parameters w.r.t. what we are
trying to achieve. So, at the moment the salient question perhaps
would be, how do we secure the xml content, a separate mechanism
from the xml transport? I hope xmlsec is orthogonal w.r.t.
transport. (pardon my momentary lack of knowledge of xmlsec).<br>
<br>
Yes, Philip we should try to use something separate just for this
bit of functionality... I agree... cleaner.<br>
<br>
<br>
<br>
On 6/6/11 1:38 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:CA124F56.C1A4%25philip.kershaw@stfc.ac.uk"
type="cite">
<pre wrap="">ESGF is already using XMLSec but you have probably not realised ;) Luca has used it to sign the SAML assertion set in the node session cookie. This code is part of the Java OpenSAML library. For the registry it would be cleaner to use the separate underlying XMLSec implementation. I will ask Neill (unless he's reading this) as he will probably know.
Phil
From: "Gavin M. Bell" <<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:gavin@llnl.gov">gavin@llnl.gov</a><a moz-do-not-send="true" class="moz-txt-link-rfc2396E" href="mailto:gavin@llnl.gov"><mailto:gavin@llnl.gov></a>>
Date: Thu, 2 Jun 2011 09:58:42 -0700
To: Philip Kershaw <<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:philip.kershaw@stfc.ac.uk">philip.kershaw@stfc.ac.uk</a><a moz-do-not-send="true" class="moz-txt-link-rfc2396E" href="mailto:philip.kershaw@stfc.ac.uk"><mailto:philip.kershaw@stfc.ac.uk></a>>
Cc: "<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-rfc2396E" href="mailto:go-essp-tech@ucar.edu"><mailto:go-essp-tech@ucar.edu></a>" <<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-rfc2396E" href="mailto:go-essp-tech@ucar.edu"><mailto:go-essp-tech@ucar.edu></a>>, "<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:esg-node-dev@lists.llnl.gov">esg-node-dev@lists.llnl.gov</a><a moz-do-not-send="true" class="moz-txt-link-rfc2396E" href="mailto:esg-node-dev@lists.llnl.gov"><mailto:esg-node-dev@lists.llnl.gov></a>" <<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:esg-node-dev@lists.llnl.gov">esg-node-dev@lists.llnl.gov</a><a moz-do-not-send="true" class="moz-txt-link-rfc2396
E" href="mailto:esg-node-dev@lists.llnl.gov"><mailto:esg-node-dev@lists.llnl.gov></a>>
Subject: Re: Question on P2P and signing of registry docs
Indeed,
Okay... so interested parties should 'sit down' and hash this out (pun intended) :-).
If you think XMLSec is the way to go, and you have documentation that you feel would be particularly helpful to getting up to speed on it, please send it out.
And ofcourse we want to *keep it simple*, whatever we do.
P.S.
Now that we are going to be in crypto land, we need to simultaneously get the ball rolling on any export issues so by the time we are done implementing the legal eagles have sorted that stuff out as well so we don't get stymied later.
On 6/2/11 2:18 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><a moz-do-not-send="true" class="moz-txt-link-rfc2396E" href="mailto:philip.kershaw@stfc.ac.uk"><mailto:philip.kershaw@stfc.ac.uk></a> wrote:
However, this p2p scenario inevitably brings in to play the need for
digital signature. The key issue is that when I pass a registry document,
to another peer I assert information about myself but also information
about other peers too.
So, we all trust each other so what's the problem? Imagine a node is
compromised and then look at the consequences.
1) Without signature. I with the compromised cert can modify my own
registry doc but I can also assert any rubbish I like about anyone else's
2) With signature. I can modify my own registry entry but much as I might
want to, I can't modify anything about anyone else's because they're all
signed.
--
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>
<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 class="moz-txt-link-abbreviated" href="mailto:gonzalez@dkrz.de">gonzalez@dkrz.de</a> </pre>
</body>
</html>