RE: [uddi-spec-comment] Question on UDDI v3 keys

Tom,

 

Please find inline input on your question. Please let 
me know if this answers your questions.

 

Regards,

 

Luc 
Clément                        

Co-Chair OASIS UDDI 
Spec TC

Systinet Corporation
Tel: 
+1.617.395.6798

 

From: Thomas B Winans 
[mailto:] 
Sent: Thursday, August 12, 2004 
14:15
To: 
Subject: 
[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