<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffcc" text="#000000">
Hi, <br>
<br>
On 6/14/11 7:55 AM, <a class="moz-txt-link-abbreviated" href="mailto:philip.kershaw@stfc.ac.uk">philip.kershaw@stfc.ac.uk</a> wrote:
<blockquote cite="mid:CA1BE92C.C839%25philip.kershaw@stfc.ac.uk"
type="cite">
<pre wrap="">Hi Gavin,
Continuing the thread on certificates from elsewhere as promised.
</pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">
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 ;)
</pre>
</blockquote>
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?".<br>
So for this reason we should limit the number of CA certs we
"trust".<br>
<br>
<blockquote cite="mid:CA1BE92C.C839%25philip.kershaw@stfc.ac.uk"
type="cite">
<pre wrap=""></pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">
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?
</pre>
</blockquote>
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. <br>
<br>
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.<br>
<blockquote cite="mid:CA1BE92C.C839%25philip.kershaw@stfc.ac.uk"
type="cite">
<pre wrap=""></pre>
<blockquote type="cite">
<pre wrap="">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*?
</pre>
</blockquote>
<pre wrap="">
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? ;) :)
</pre>
</blockquote>
For the browsers we do this... we all have certs provided by the
browser cartel.<br>
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.<br>
<blockquote cite="mid:CA1BE92C.C839%25philip.kershaw@stfc.ac.uk"
type="cite">
<pre wrap="">
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.
</pre>
</blockquote>
This simply means accepting certs signed by CAs that EGI uses. I.E.
CAs analogous to DOEGrids. I see no problem with that.<br>
<br>
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.<br>
<blockquote cite="mid:CA1BE92C.C839%25philip.kershaw@stfc.ac.uk"
type="cite">
<pre wrap="">
We can talk more on the call ...
</pre>
</blockquote>
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. <br>
<blockquote cite="mid:CA1BE92C.C839%25philip.kershaw@stfc.ac.uk"
type="cite">
<pre wrap="">
Cheers,
Phil
On 06/06/2011 12:37, <a class="moz-txt-link-rfc2396E" href="mailto:philip.kershaw@stfc.ac.uk">"philip.kershaw@stfc.ac.uk"</a>
<a class="moz-txt-link-rfc2396E" href="mailto:philip.kershaw@stfc.ac.uk"><philip.kershaw@stfc.ac.uk></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">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 <a class="moz-txt-link-rfc2396E" href="mailto:gonzalez@dkrz.de"><gonzalez@dkrz.de></a>
Organization: DKRZ
Date: Fri, 3 Jun 2011 12:29:25 +0200
To: "Gavin M. Bell" <a class="moz-txt-link-rfc2396E" href="mailto:gavin@llnl.gov"><gavin@llnl.gov></a>
Cc: <a class="moz-txt-link-rfc2396E" href="mailto:Luca.Cinquini@jpl.nasa.gov">"Luca.Cinquini@jpl.nasa.gov"</a> <a class="moz-txt-link-rfc2396E" href="mailto:Luca.Cinquini@jpl.nasa.gov"><Luca.Cinquini@jpl.nasa.gov></a>,
<a class="moz-txt-link-rfc2396E" href="mailto:go-essp-tech@ucar.edu">"go-essp-tech@ucar.edu"</a> <a class="moz-txt-link-rfc2396E" href="mailto:go-essp-tech@ucar.edu"><go-essp-tech@ucar.edu></a>,
<a class="moz-txt-link-rfc2396E" href="mailto:esg-node-dev@lists.llnl.gov">"esg-node-dev@lists.llnl.gov"</a> <a class="moz-txt-link-rfc2396E" href="mailto:esg-node-dev@lists.llnl.gov"><esg-node-dev@lists.llnl.gov></a>
Subject: Re: [Go-essp-tech] [esg-node-dev] Re: Question on P2P and
signing of registry docs
</pre>
<blockquote type="cite">
<pre wrap="">
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, <a class="moz-txt-link-abbreviated" href="mailto:stephen.pascoe@stfc.ac.uk">stephen.pascoe@stfc.ac.uk</a>
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: <a class="moz-txt-link-abbreviated" href="mailto:go-essp-tech-bounces@ucar.edu">go-essp-tech-bounces@ucar.edu</a>
[<a class="moz-txt-link-freetext" href="mailto:go-essp-tech-bounces@ucar.edu">mailto:go-essp-tech-bounces@ucar.edu</a>]
On Behalf Of Gavin M. Bell
Sent: 02 June 2011 01:47
To: Cinquini, Luca (3880)
Cc: <a class="moz-txt-link-abbreviated" href="mailto:go-essp-tech@ucar.edu">go-essp-tech@ucar.edu</a>;
<a class="moz-txt-link-abbreviated" href="mailto:esg-node-dev@lists.llnl.gov">esg-node-dev@lists.llnl.gov</a>
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 - <a class="moz-txt-link-freetext" href="http://rainbow.llnl.gov/dist/keys/gavin.asc">http://rainbow.llnl.gov/dist/keys/gavin.asc</a>)
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 - <a class="moz-txt-link-freetext" href="http://rainbow.llnl.gov/dist/keys/gavin.asc">http://rainbow.llnl.gov/dist/keys/gavin.asc</a>)
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: <a class="moz-txt-link-abbreviated" href="mailto:gonzalez@dkrz.de">gonzalez@dkrz.de</a>
_______________________________________________
GO-ESSP-TECH mailing list
<a class="moz-txt-link-abbreviated" href="mailto:GO-ESSP-TECH@ucar.eduhttp://mailman.ucar.edu/mailman/listinfo/go-essp-tec">GO-ESSP-TECH@ucar.eduhttp://mailman.ucar.edu/mailman/listinfo/go-essp-tec</a>
h
</pre>
</blockquote>
<pre wrap="">
--
Scanned by iCritical.
</pre>
</blockquote>
<pre wrap="">
--
Scanned by iCritical.
</pre>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Gavin M. Bell
--
"Never mistake a clear view for a short distance."
-Paul Saffo
</pre>
</body>
</html>