[Go-essp-tech] [esg-node-dev] Certificate authorities and ESGF
Gavin M. Bell
gavin at llnl.gov
Tue Jun 14 11:47:38 MDT 2011
Hi,
On 6/14/11 7:55 AM, philip.kershaw at stfc.ac.uk wrote:
> Hi Gavin,
>
> Continuing the thread on certificates from elsewhere as promised.
>
>> So, let me be clear... I am not proposing anything other than keeping
>> things simple. 36+ CA certs in the truststore does not sound simple.
> I've just looked in the certificate manager in Firefox. I see many more
> than 36 certificates in there. I'm sure this is not untypical of browsers
> in general and yet I don't see the whole of e-commerce around the world
> grinding to halt just because browsers bundle with a lot of CA
> certificates. They seem to manage just fine ;)
>
The *only* issue with regards to this is safari. If we want to support
safari then they are the limiting reagent... otherwise... indeed it's
just fine. Semantically, what are the implications of having "a
million" certs in your trusstore... it is the whole question of "what
does it mean when everybody is special?".
So for this reason we should limit the number of CA certs we "trust".
>> Having separate keys to manage on the node, is not simpler than having
>> one. In so far as simplicity does not harm adoption and flexibility we
>> should keep things simple.
> Yes, but given my browser example, there's no reason why we can't manage
> many certificates. If we are still saying we have problems with managing
> these doesn't that say rather more about the tooling we are using and the
> inadequacies of handling Java keystores?
>
There is nothing that we are doing that will preclude a user from
installing their own certs. The installation script provides a
convenience function for doing so, but users are totally able to not use
it. By definition the script is a convenience. So at the moment, the
script will take a keypair and install it both as a tomcat keystore and
as a globus /etc/grid-security keypair.
I see the typical scenario that node installers will use this feature to
setup the node entirely to use on keypair and if they choose replace the
keystore with their browser-blessed certs as they choose.
>> What suggestions do you have toward that end?
>> What infrastructures? I would love to learn more about it, I am sure
>> others in the group as well. I'd like to get as concrete on these
>> things
>> as possible, as soon as possible. What do you suppose we *do*?
>
> I think it's all pretty much there in my previous message below...
>
> We could radically reduce the number of CAs we have in our trust stores by
> using DOEGrids as our trustroot for short-lived credential services
> (MyProxy) and other Grid server certificates. We'd still need another CA
> for web servers but why we can't we agree some policy on that? In the UK
> and other EU countries we have a common CA provider for web servers in
> Terena. Can't you all do something similar in the US? ;) :)
For the browsers we do this... we all have certs provided by the browser
cartel.
VeriSign, et. al. And Rachana and Dean are on the case with respect to
DOEGrids, so we are on the same page. We need to purge all the simpleCA
certs that are in our system and consolidate to the DOEGrids CA or
subordinate ca.
> There are structures like the IGTF that can help us establish a PKI that
> will fit in with other systems around the world and enable us to
> interoperate more easily. This is a problem I need to tackle now as I try
> to integrate European Grid infrastructure (EGI) with ESGF.
This simply means accepting certs signed by CAs that EGI uses. I.E. CAs
analogous to DOEGrids. I see no problem with that.
The issue here is process. And with the script install it promotes the
generation of a CSR that is suitable for signing by any of these CAs. I
think this is the major part of the solution. When folks install the
ESGF P2P nodes they generate the csr and are given instructions to get
that CSR signed. This is the missing link with those that don't use the
script.
> We can talk more on the call ...
I think we are saying the same things... I think the ESGF P2P solution
along with the installation script is a cleaner solution for the
end-user and node installer that just giving the user a war and web
pages of instructions.
> Cheers,
> Phil
>
> On 06/06/2011 12:37, "philip.kershaw at stfc.ac.uk"
> <philip.kershaw at stfc.ac.uk> wrote:
>
>> 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-tec
>>> h
>> --
>> Scanned by iCritical.
> --
> Scanned by iCritical.
--
Gavin M. Bell
--
"Never mistake a clear view for a short distance."
-Paul Saffo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ucar.edu/pipermail/go-essp-tech/attachments/20110614/0a0454a2/attachment-0001.html
More information about the GO-ESSP-TECH
mailing list