|
Difference between
current version
and
version 7:
| Line 55 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 storage approaches. One potential solution to this is to use a centralized key management service such as [MyProxy|http://grid.ncsa.uiuc.edu/myproxy/]. |
| At line 56 added 3 lines. |
| + 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. However, the certificate is still used to generate proxy certificates so that services can invoke new requests on behalf of the user, so some of the advantages of the GSI proxy certificate are maintained. For example, this will be especially relevant when running analyses through an environment like Kepler and a user invokes a computation through a grid service which in turn can invoke other grid services on behalf of the user by generating and sending another proxy certificate. |
| + |
| + |
Back to Certificate Authority Design,
or to the Page History.
|
