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

Tue Jun 7 04:00:21 MDT 2011

Hi,

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:

_channel [SSL secured]
  _payload - [non secured xml or whatever the manager uses to connect 
nodes in the p2p]
   _nodeA_services [xmlsec signed by nodeA]
   _nodeB_services [xmlsec signed by nodeB]
   _nodeC_services [xmlsec signed by nodeC]

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 :-)

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

Thanks,
Estani

Am 07.06.2011 00:39, schrieb Gavin M. Bell:
> Hi,
>
> 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).
>
> Yes, Philip we should try to use something separate just for this bit 
> of functionality... I agree... cleaner.
>
>
>
> On 6/6/11 1:38 AM, philip.kershaw at stfc.ac.uk wrote:
>> 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"<gavin at llnl.gov<mailto:gavin at llnl.gov>>
>> Date: Thu, 2 Jun 2011 09:58:42 -0700
>> To: Philip Kershaw<philip.kershaw at stfc.ac.uk<mailto:philip.kershaw at stfc.ac.uk>>
>> Cc: "go-essp-tech at ucar.edu<mailto:go-essp-tech at ucar.edu>"<go-essp-tech at ucar.edu<mailto:go-essp-tech at ucar.edu>>, "esg-node-dev at lists.llnl.gov<mailto:esg-node-dev at lists.llnl.gov>"<esg-node-dev at lists.llnl.gov<mailto:esg-node-dev at lists.llnl.gov>>
>> 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,philip.kershaw at stfc.ac.uk<mailto:philip.kershaw at stfc.ac.uk>  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 -http://rainbow.llnl.gov/dist/keys/gavin.asc)
>>
>>   A796 CE39 9C31 68A4 52A7  1F6B 66B7 B250 21D5 6D3E
>>
>
> -- 
> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ucar.edu/pipermail/go-essp-tech/attachments/20110607/08d9b0f4/attachment.html 