[Go-essp-tech] Question on P2P and signing of registry docs

[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

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