Karl, You raise an interesting point - the point "What are the ramifications for security and system stability? What happens if someone uses a poor implementation or malicously puts GUIDs into EPRs such that they alias other services? Do we have signature validation for EPRs? " This was discussed in the design team over a year ago and the consensus was that being able to strongly tie identity to the name, e.g., cryptographically, was not a requirement - but rather an option. (I agreed it should not be required - but felt strongly that we must be able to accommodate such linkage). As you may know the Legion implementation of abstract names (called LOID's) include a public key so that clients can ensure that only the holder of the corresponding private key can read the message. Similarly in the "Secure Grid Naming Protocol" (SGNP) that Avaki took to GGF there were keys in the names. That may have persisted into LSID's - which were derived off of SGNP - I am not sure. As the WS-naming DRAFT currently stands there is nothing to prevent a name generator (minter?) from placing keys, signed certs, or anything else in the AbstractName component. For example I might include the GUID and a signed hash along with the cert that signed it. Or ... there are lots of options that all fit in the purview of WS-Naming. As to malicious name generation of spoofing - without some additional mechanism it can happen - that's life. It is not the way I would prefer it, but getting agreement on "how" would be difficult. My guess is that if we are successful, that AbstractName "types" will be developed that allow clients to verify the AbstractName. Andrew -----Original Message----- From: owner-ogsa-wg@ggf.org [mailto:owner-ogsa-wg@ggf.org] On Behalf Of Karl Czajkowski Sent: Thursday, September 01, 2005 12:11 AM To: Mark Morgan Cc: ogsa-wg@ggf.org Subject: Re: [ogsa-wg] BES query On Aug 31, Mark Morgan modulated:
I have to admit that I am confused as to what makes adding an abstract name to an EPR so much of a burden. I know that Andrew and I are talking about something very lightweight (perhaps just generating a GUID when the EPR is generated). So, in the technical sense, it's extra work that needs to be done, but in my mind it's far less honerous then writing good comments for your code and I think everyone would agree that the benefits of doing so far outweight the burden. In this case, AbstractNames give a potentially huge benefit for a line or two of code. Why is this such a big deal?
-Mark
Mark: In reflecting on this a bit, I personally would like to hear comments from the security crowd. It sounds like the main difference in having this GUID is, as I tried to summarize earlier, that someone can compare EPRs or otherwise reason about service identities without consulting the referenced service. What are the ramifications for security and system stability? What happens if someone uses a poor implementation or malicously puts GUIDs into EPRs such that they alias other services? Do we have signature validation for EPRs? I guess this depends on the "culture" that would emerge around consumption and use of these GUIDs... I wonder if there are unspoken architectural assumptions here that are at the heart of the debate? karl -- Karl Czajkowski karlcz@univa.com