| Line 1 was replaced by line 1 |
| - __DRAFT FOR COMMENTS__ |
| + __DRAFT FOR COMMENTS__ |
| Lines 3-4 were replaced by lines 3-4 |
| - The SEEK Certificate Authority needs to provide authentication credentials for a large |
| - number of users distributed across multiple institutions, and also be trusted and manageable. |
| + The SEEK Certificate Authority needs to provide authentication credentials for a large |
| + number of users distributed across multiple institutions, and also be trusted and manageable. |
| Line 6 was replaced by line 6 |
| - authentication system for a group of over 5000 scientists. The current institutions participating |
| + authentication system for a group of over 5000 scientists. The current institutions participating |
| Lines 8-13 were replaced by lines 8-13 |
| - Ecological Research Network (LTER), the Partnership for Interdisciplinary Studies of Coastal Oceans (PISCO), |
| - the University of California Natural Reserve System (UCNRS), and the Organization of Biological Field Stations (OBFS). |
| - It is a distributed system based on referrals so that each organization manages its own set of users. Referrals are set up to |
| - institution-specific LDAP servers that are run by administrators that can be trusted to maintain the security of the LDAP |
| - tree. This LDAP system is password-based, but the SEEK ~EcoGrid needs to utilize X.509 |
| - certificates for GSI authentication. Thus, some modifications would be needed to use this system. |
| + Ecological Research Network (LTER), the Partnership for Interdisciplinary Studies of Coastal Oceans (PISCO), |
| + the University of California Natural Reserve System (UCNRS), and the Organization of Biological Field Stations (OBFS). |
| + It is a distributed system based on referrals so that each organization manages its own set of users. Referrals are set up to |
| + institution-specific LDAP servers that are run by administrators that can be trusted to maintain the security of the LDAP |
| + tree. This LDAP system is password-based, but the SEEK ~EcoGrid needs to utilize X.509 |
| + certificates for GSI authentication. Thus, some modifications would be needed to use this system. |
| Lines 16-17 were replaced by lines 16-17 |
| - Distinguished Name formats and the referral system. We will store user and host certificates |
| - in the LDAP tree for easy retrieval. |
| + Distinguished Name formats and the referral system. We will store user and host certificates |
| + in the LDAP tree for easy retrieval. |
| Lines 19-29 were replaced by lines 19-42 |
| - !!Distributed CA Servers |
| - The Root LDAP server for the SEEK ~EcoGrid will have a DN: |
| - o=~EcoGrid,ou=seek.ecoinformatics.org,cn=~EcoGrid CA |
| - This CA will in turn sign certificates for a set of subordinate CAs that will actually manage the user accounts |
| - and the LDAP tree. These will include:\\ |
| - {{ |
| - NCEAS: o=~EcoGrid,ou=nceas.ucsb.edu,cn=NCEAS CA\\ |
| - LTER: o=~EcoGrid,ou=lternet.edu,cn=LTER CA\\ |
| - PISCO: o=~EcoGrid,ou=piscoweb.org,cn=PISCO CA\\ |
| - UCNRS: o=~EcoGrid,ou=ucnrs.org,cn=UCNRS CA\\ |
| - OBFS: o=~EcoGrid,ou=obfs.org,cn=OBFS CA\\ |
| + !!Distributed CA Servers |
| + The Root LDAP server for the SEEK ~EcoGrid will have a DN:\\ \\ |
| + {{ |
| + o=~EcoGrid,ou=seek.ecoinformatics.org,cn=~EcoGrid CA |
| + }} \\ |
| + |
| + This CA will in turn sign certificates for a set of subordinate CAs that will actually manage the user accounts |
| + and the LDAP tree. These will include:\\ \\ |
| + {{ |
| + NCEAS: o=~EcoGrid,ou=nceas.ucsb.edu,cn=NCEAS CA\\ |
| + LTER: o=~EcoGrid,ou=lternet.edu,cn=LTER CA\\ |
| + PISCO: o=~EcoGrid,ou=piscoweb.org,cn=PISCO CA\\ |
| + UCNRS: o=~EcoGrid,ou=ucnrs.org,cn=UCNRS CA\\ |
| + OBFS: o=~EcoGrid,ou=obfs.org,cn=OBFS CA\\ |
| + }}\\ |
| + |
| + !!DN Format |
| + Distinguished names for each of the participating organizations will follow a prescribed format, namely:\\ \\ |
| + {{ |
| + NCEAS: uid=mjones,o=NCEAS,dc=nceas,dc=ucsb,dc=edu\\ |
| + LTER: uid=mjones,o=LTER,dc=lternet,dc=edu\\ |
| + PISCO: uid=mjones,o=PISCO,dc=piscoweb,dc=org\\ |
| + UCNRS: uid=mjones,o=UCNRS,o=ucnrs.org\\ |
| + OBFS: uid=mjones,o=OBFS,dc=obfs,dc=org\\ |
| Lines 31-42 were replaced by lines 44-47 |
| - !!DN Format |
| - Distinguished names for each of the participating organizations will follow a prescribed format, namely:\\ |
| - {{ |
| - NCEAS: uid=mjones,o=NCEAS,dc=nceas,dc=ucsb,dc=edu\\ |
| - LTER: uid=mjones,o=LTER,dc=lternet,dc=edu\\ |
| - PISCO: uid=mjones,o=PISCO,dc=piscoweb,dc=org\\ |
| - UCNRS: uid=mjones,o=UCNRS,o=ucnrs.org\\ |
| - OBFS: uid=mjones,o=OBFS,dc=obfs,dc=org\\ |
| - }}\\ |
| - Other institutional formats will be added as needed. Our goal is that all of the DN formats will contain a uid attribute and |
| - an o (organization) attribute, which allows us to easily create referrals in the tree. The suffix portion of the DN can vary by |
| - organization, although we recommend using the domain component (dc) syntax as it is consistent and known to be unique. |
| + |
| + Other institutional formats will be added as needed. Our goal is that all of the DN formats will contain a uid attribute and |
| + an o (organization) attribute, which allows us to easily create referrals in the tree. The suffix portion of the DN can vary by |
| + organization, although we recommend using the domain component (dc) syntax as it is consistent and known to be unique. |
| Lines 44-45 were replaced by lines 49-50 |
| - !!Adding New CA servers |
| - New institutions that wish to participate in the ~EcoGrid will need to provide both a trustworthy CA and a trustworthy LDAP installation. The new institution can then contact the **note: who do they contact?** in order to register their CA and have it be listed in the root ~EcoGrid node. We are also considering requiring each CA node to run a grid service registry node to distribute this functionality across a wider set of servers. More details on this to follow. |
| + !!Adding New CA servers |
| + New institutions that wish to participate in the ~EcoGrid will need to provide both a trustworthy CA and a trustworthy LDAP installation. The new institution can then contact the **note: who do they contact?** in order to register their CA and have it be listed in the root ~EcoGrid node. We are also considering requiring each CA node to run a grid service registry node to distribute this functionality across a wider set of servers. More details on this to follow. |
| Lines 47-48 were replaced by lines 52-53 |
| - !!End-user tools |
| - For a certificate-based system to be effective, we need to make it simple for users to request certificates and install both the public and private keys in appropriate locations. I think we shoul dbuild a simple web-based system for a user to generate a certificate request, send it to the correct CA, and retrieve the signed certificate from the CA. This means that there needs to be a mechanism for the CA to check the validity of the request: this probably can occur through a combination of email and phone contacts to the scientist. In larger organizations such as LTER, we may want to delegate even further down the tree to individual LTER sites so that the CA managers have personal knowledge of the end users. |
| + !!End-user tools |
| + For a certificate-based system to be effective, we need to make it simple for users to request certificates and install both the public and private keys in appropriate locations. I think we shoul dbuild a simple web-based system for a user to generate a certificate request, send it to the correct CA, and retrieve the signed certificate from the CA. This means that there needs to be a mechanism for the CA to check the validity of the request: this probably can occur through a combination of email and phone contacts to the scientist. In larger organizations such as LTER, we may want to delegate even further down the tree to individual LTER sites so that the CA managers have personal knowledge of the end users. |
| Line 50 was replaced by line 55 |
| - One immediate issue surfaces: how do we manage private keys? Private keys need to be created on the client side for privacy reasons, but installed in many possible locations. For example, we expect many people to interact with the system using Kepler. Kepler needs a mechanism to generate key requests, and store and manage private keys. Even with this, users will still encounter problems trying to run Kepler on other desktops (where the key isn't present), or run other applications that use different key sotrage approaches. One potential solution to this is to use a centralized key management service such as [http://grid.ncsa.uiuc.edu/myproxy/ MyProxy]. THe problem with ~MyProxy and other centralized schemes is that there needs to be a password based mechanism for obtaining the certificate, and so the whole system is still based on a centralized authentication module, which certificates are designed to bypass. |
| + One immediate issue surfaces: how do we manage private keys? Private keys need to be created on the client side for privacy reasons, but installed in many possible locations. For example, we expect many people to interact with the system using Kepler. Kepler needs a mechanism to generate key requests, and store and manage private keys. Even with this, users will still encounter problems trying to run Kepler on other desktops (where the key isn't present), or run other applications that use different key sotrage approaches. One potential solution to this is to use a centralized key management service such as [http://grid.ncsa.uiuc.edu/myproxy/ MyProxy]. THe problem with ~MyProxy and other centralized schemes is that there needs to be a password based mechanism for obtaining the certificate, and so the whole system is still based on a centralized authentication module, which certificates are designed to bypass. |
| Lines 52-53 were replaced by lines 57-58 |
| - ------------------------------------------- |
| - [EcoGridCommunity] |
| + ------------------------------------------- |
| + [EcoGridCommunity] |
