[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [uddi-spec-comment] Question on UDDI v3 keys
Greetings --
I have a question on UDDI v3 keys ... in a
deployment UDDI environment, what would the process be to ensure that domain
owners authorize the use of their domain names as v3 key
components?
<lc>How key partitions are created and managed is
ultimately a matter of governance for the enterprise. I expect an organization
will manage and assign its key-spaces much in the same way it manages internal
DNS domains today. Depending on the implementation used, I expect the enterprise
will select a root key-space when it installs its first v3 registry; this
key-space would then be used as the default key-space for node-generated keys.
As a means of implementing and enforcing this, I would suggest that the node
administrator is the only “role” granted the ability to generate a key-space
(i.e. is permitted to generate keyGenerator tModels).
It is likely that subordinate or other key-spaces may also be required to deal with the case of federated nodes or simply needed a different key-space for use within a node. In either case, the administrator of the node would create the subordinate or other key-spaces requested and perform an ownership transfer (via the ownership and custody transfer API or some UI) of the key-spaces’s keyGenerator tModel to the intended owner of the key-space.
This
is a controlled means of generating key spaces and a round-about way to answer
your question. In short, the administrator has control to whom it grants the
creation of key-spaces and thus has a means of enforcing enterprise
rules.</lc>
The way
that I see it, it would be possible for me (not an owner of
xyz.com) to beat
XYZ, Inc. to a public registry and create a key generator that looks like
uddi:xyz.com:services:keygenerator unless the operator validates that the owner
of the key root (the domain name) authorizes the use of the key. Do you know if
operators are prepared for this in some way? Or will this be rationale to
continue using v2-styled keys until there is some form of DNS-related
integration of some sort -- and would this even help?
<lc>As described above, control over the generation of key-spaces
by a node administrator does provide you with a means of ensuring that you don’t
have a free-for-all.
One might want to create a self-serve environment whereby anyone is granted the ability to generate key-spaces. In such an environment, it is quite likely that someone might attempt to create a key-space and squat on it (much in the same way that domain squatters do this today). This is entirely not acceptable as you suggest, and as such node policy would require that the publisher provide proof of ownership/association of the domain for which he/she is attempting to create a key-space for (through the creation of a domain keyGenerator tModel).
Policy enforcement might be implemented in a number of ways; the tModel keyGenerator might actually not be persisted and ready for use until such time validation has been performed for example. Validation might take different forms: it might be manual or it might be automated. One way to automate this is to require the domain keyGenerator tModel to be digitally signed and requiring that certain properties of the signer’s certificate be available to associate the user with the domain requested. There are clearly other ways of implementing this.
In
short, I do not anticipate an implementation would allow uncontrolled generation
of domain-based keys, as allowing uncontrolled generation is unwarranted and
simply that – uncontrolled.</lc>
I
have not seen this dealt with/mentioned by the UDDI committee ...
<lc>The spec stays clear of
making normative a behaviour; it is not its place. What the TC is in the process
of writing is a technical note that describes practical examples of using
domain-based keys. A work in progress can be found at [1].
[1] http://www.oasis-open.org/apps/org/workgroup/uddi-spec/download.php/5899/uddi-spec-tc-tn-understandingkeypartitions-20030602.doc</lc>
Am I missing
something?
Thanks,
Tom Winans
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]