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

Fri Jun 3 04:29:25 MDT 2011

Hi,

Why do we have to have only one cert? Why do we have to sign the 
registry with tomcat's SSL certificate?
Wouldn't it be much simpler if we leave the SSL alone (everyone does as 
it pleases), we add a second p2p network  centralized certificate and we 
link them both somehow (a service perhaps?) so when doing a p2p 
connection via SSL the SSL gets certified by the underlying p2p 
certificate (perhaps sent via XMLSec)?

Does this make sense / seems viable?

Thanks,
Estani
Am 02.06.2011 18:53, schrieb Gavin M. Bell:
> Hi Stephen,
>
> Yes, we should have this conversation.  The basic idea is the fewer 
> certs the better.  The more security savvy folks than myself should 
> feel free to elucidate the finer points.  Perhaps the single 
> subordinate CA can have its cert in a chain downstream from verisign 
> thus providing the clients (browsers et. al) to be able to verify it 
> against something like Verisign's cert and the ESGF's 'superior' CA's 
> cert as well?  This makes sense to me but I certainly defer to the 
> wisdom of those who know more.
>
> We should not break anyone's system... that is for sure :-).
>
> On 6/2/11 1:19 AM, stephen.pascoe at stfc.ac.uk wrote:
>>
>> Hi,
>>
>> So Gavin, to summarise what I think you've said: the installer will 
>> allow you to use a cert signed by any CA but you are proposing the 
>> ESGF system should use a single ESGF CA.
>>
>> How is this going to work for users accessing over HTTPS?  Are we 
>> going to require them to install the ESGF CA in their browser or will 
>> the node use a separate cert for intra-federation communication to 
>> that used for user-facing HTTPS?  Can tomcat do that?
>>
>> Also this idea already excludes the CEDA MyProxy server which is used 
>> for more than just ESGF.    I see the attraction of a single CA but 
>> I'm not sure it's going to work.
>>
>> Stephen.
>>
>> ---
>>
>> Stephen Pascoe  +44 (0)1235 445980
>>
>> Centre of Environmental Data Archival
>>
>> STFC Rutherford Appleton Laboratory, Harwell Oxford, Didcot OX11 0QX, UK
>>
>> *From:*go-essp-tech-bounces at ucar.edu 
>> [mailto:go-essp-tech-bounces at ucar.edu] *On Behalf Of *Gavin M. Bell
>> *Sent:* 02 June 2011 01:47
>> *To:* Cinquini, Luca (3880)
>> *Cc:* go-essp-tech at ucar.edu; esg-node-dev at lists.llnl.gov
>> *Subject:* Re: [Go-essp-tech] [esg-node-dev] Re: Question on P2P and 
>> signing of registry docs
>>
>> Hi,
>>
>> Dean and Rachana are on the case.
>> I am sure when they have something they'll let us know.
>>
>> As it stands right now... the script generates the CSR that you can 
>> submit to get signed.  If you already have a keypair you can use that 
>> and call esg-node --install-keypair and it will do the right things.  
>> So who you use to sign your CSR is up to you... and as I mentioned if 
>> you already have a keypair you can directly use it. :-).  Everyone is 
>> free to do as they wish. :-)
>> [note: you have to have all the certs in the cert chain if your CA's 
>> cert is in a chain]
>>
>> There is no single point of failure in this scenario.  The only thing 
>> that matters is that you have your CA's public cert in your 
>> truststore and /etc/grid-security.  You don't need to communicate to 
>> the CA at all, you just need them to sign an provide you their cert.  
>> Done.
>>
>> Essentially we would be establishing membership (those that can be 
>> authenticated thus trusted to talk to) in a peer2peer mesh network by 
>> the CA that vouches for that network.  There should only be one per 
>> mesh.  In our case that "one" is ESGF but there is no barrier to 
>> having a peer support one or many CAs... well, except if you want 
>> your clients to use Safari ;-).
>>
>> Another note about the installer... the installer under 
>> --install-keypair will take the keypair you give it and convert and 
>> insert it into your keystore as well as /etc/grid-security... It is 
>> the same cert in two formats.  Thus the entire node is represented by 
>> one DN that is used for gridftp and tomcat.  The idea there is to 
>> minimize the amount of certs you have to manage.  Don't confuse this 
>> with the ability to recognize and validate against all the certs you 
>> encounter by putting them in the truststore and /etc/grid-security/certs.
>>
>> P.S.
>> Pardon, yes I did mean Estani and everyone on the list, etc... :-) 
>> and you.
>>
>> On 6/1/11 4:28 PM, Cinquini, Luca (3880) wrote:
>>
>> 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
>>
>>
>>
>> -- 
>> 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
>>
>> -- 
>> Scanned by iCritical.
>>
>>
>
> -- 
> 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/20110603/1bd0a677/attachment-0001.html 