Re: Something Stronger than a Passphrase? (UNCLASSIFIED)
Paul,
> The "protocol spec" I found did not have much detail
> and would not support the functionality implied by the command options
> you mention. Is there a better spec than
> http://grid.ncsa.uiuc.edu/myproxy/protocol/?
No, that's the most authoritative source, and as you note, it's
unfortunately out of date.
> BTW, I notice at
> http://www.globus.org/toolkit/docs/4.0/security/myproxy/rn01re01.html#id
> 2541716 that the Globus toolkit myproxy-init supports 'myproxy-init
> --retrievable_by' but not, apparently, 'myproxy-init
> --retrievable_by_cert'.
Right, that documentation hasn't been updated since that feature was
added. <http://grid.ncsa.uiuc.edu/myproxy/man/> is always the most
up-to-date.
> So, if I have this right, it sounds like I might want users to
> "myproxy-init --retrievable_by_cert dn --no_passphrase," and for
> prospective proxies to "myproxy-logon --no_passphrase," and for MyProxy
> servers to SSL client authenticate both users and prospective proxies.
> Does this make sense?
I think so.
> I get the impression my "myproxy-init
> --retrievable_by_cert dn --no_passphrase" would force me to put a new
> credential every time I want to use a new application proxy.
True.
> Should the
> user, above, not include "--no_passphrase," not ever give the passphrase
> to prospective proxies and only use the passphrase in subsequent
> commands to modify who can retrieve proxy certs?
The ability to modify a credential's policy after it's stored on the
server as you describe would be useful, but it's not implemented.
MyProxy is open source software, and we're happy to include new
functionality developed by the community in future releases.
Cheers,
Jim