[Go-essp-tech] Certificate authorities and ESGF
philip.kershaw at stfc.ac.uk
philip.kershaw at stfc.ac.uk
Mon Jun 6 05:37:37 MDT 2011
A new title but continuing an existing thread...
There are a couple of points I'd raise about this issue. I can see the
desire to simplify management of PKI within ESGF, it's just that we need
to think carefully about how we do it. A number of issues have made the
trust root management difficult to date:
1. poor out-of-the-box tooling available for handling keystores
2. multiple root CAs (one per organisation),
3. the need to keep intermediate CA certificates in the trust roots.
1) Is for another conversation. 2) We have a problem in that we want
certificates for our web servers that will be accepted by the major
browsers but we also need to run CAs for our MyProxy Online CA services.
So any one organisation has at least two trust roots, one for their web
server's SSL certificates and one for short lived credentials issued from
MyProxy. I would be surprised if the likes of Verisign would issue us
with an intermediate CA for use with MyProxy. Given this fact I think we
are likely to have to live with two sets of trust roots for the
foreseeable future.
That said, there are ways that we can simplify our trust root management
with our MyProxy services. We've got to move away from the use of
SimpleCA and each organisation running it's own CA. It undesirable on a
number of counts. The UK and I'm sure other countries have national grid
infrastructures that can support us and that we can plug into. The BADC's
MyProxy CA certificate is issued from the UK e-Science root CA. This
means that when I discuss interoperation between ourselves and other
national grid infrastructures I have a head start in that I am using a
trust root that is known and recognised. This is helping right now as we
look at integration with grid infrastructure in Europe with EGI.
The equivalent for ESGF in the US would seem to be the DoE Grids CA and I
know Rachana has had discussions with them about the possibility of our
MyProxy CA certificates being issued through them. This would simplify CA
certificate management as we would have a common trust root for many of
our organisations' CA certificates. There is an issue of governance. As
a point of principle, I don't think that we as individual federation
partners should be in the business of managing root CAs. They should
instead be handled by independent organisations that have expertise in
this area like DoE or respective national grid infrastructures.
On the last point 3), there shouldn't be any need to store intermediate CA
certificates certainly in the case of web server certificates. The
respective servers should be configured to pass back any intermediate
certificates in the SSL handshake. For MyProxy, I requested a patch to
enable it to return intermediate CA certificates in MyProxy logon
responses and this has been incorporated into the latest release. That
said, there's still a case for keeping intermediate certificates in trust
roots as it provides more fine grained control over trust by means of
signing policy files and CRLs (Certificate Revocation Lists).
Cheers,
Phil
From: Estanislao Gonzalez <gonzalez at dkrz.de>
Organization: DKRZ
Date: Fri, 3 Jun 2011 12:29:25 +0200
To: "Gavin M. Bell" <gavin at llnl.gov>
Cc: "Luca.Cinquini at jpl.nasa.gov" <Luca.Cinquini at jpl.nasa.gov>,
"go-essp-tech at ucar.edu" <go-essp-tech at ucar.edu>,
"esg-node-dev at lists.llnl.gov" <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,
>
> 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
>
>
>_______________________________________________
>GO-ESSP-TECH mailing list
>GO-ESSP-TECH at ucar.eduhttp://mailman.ucar.edu/mailman/listinfo/go-essp-tech
--
Scanned by iCritical.
More information about the GO-ESSP-TECH
mailing list