- From: Stephen Farrell <stephen.farrell@baltimore.ie>
- Date: Wed, 04 Dec 2002 17:47:13 +0000
- To: Blair Dillaway <blaird@exchange.microsoft.com>
- CC: merlin hughes <merlin@baltimore.ie>, www-xkms@w3.org
> I guess one might have a message router that accepts XKMS requests and > forwards them to a specific XKMS service for you. But I don't see this > being very realistic given the need for the client to trust the XKMS > service. That's the case I was thinking about (is ws-routing still live?). I guess we could include text that the responder ought to know if its publicly visible via some "other"/proxy name and be able to respond to that. Client's can also be told to be aware that the KeyName in the response might not be that in the request, which is ok, since there's no security value in that without additional measures. Stephen. > > -----Original Message----- > From: Stephen Farrell [mailto:stephen.farrell@baltimore.ie] > Sent: Wednesday, December 04, 2002 6:55 AM > To: Blair Dillaway > Cc: merlin hughes; www-xkms@w3.org > > Blair, > > I like this, but have one worry. If using SOAP will the client > always/usually know the KeyName value by which the responder knows > itself? (Or, maybe SOAP isn't as much an application layer NAT as I > think it to be:-) > > If that isn't a problem, then your idea's best. If it is, then I guess > we're back to magic values. > > But regardless, the idea of having UseKeyWith separate the potentially > different transport keys is good. Do we have constants defined for all > the required transports? > > Stephen. > > Blair Dillaway wrote: > > > > I would agree these are both variations on a magic value. Neither > > proposal seems perfect to me. It would make more sense to me that one > > > would ask for the key associated with the XKMS service URI. The > > notion of allowing a qualifier for different transport security > > technologies also makes sense. How about encoding the first as a > > KeyName and the second as the UseKeyWith > > > > So, if the XKMS service Locate URI is http://myservice/XKMS/locate, > > then to get a transport public key associated with securing that > > service, I do a LocateRequest with a > > KeyName = http://myservice/XKMS/locate and a > > UseKeyWith value representing the transport protocol I care > > about (TLS, WS-Sec, ...) > > > > Blair > > > > -----Original Message----- > > From: Stephen Farrell [mailto:stephen.farrell@baltimore.ie] > > Sent: Tuesday, December 03, 2002 4:22 AM > > To: merlin hughes > > Cc: www-xkms@w3.org > > > > Depending on the outcome of the policy-stuffing thread, I'd be fine > > with this (or any other way to encode what is, in fact, a magic value, > > > even if syntactically a URI:-) or with my original proposal. > > > > Other opinions? > > > > Stephen. > > > > merlin hughes wrote: > > > > > > Would we be better employing UseKeyWith; avoids magic values: > > > > > > <?xml version="1.0" encoding="utf-8"?> > > > <LocateRequest xmlns:ds="http://www.w3.org/2000/09/xmldsig#" > > > xmlns:xenc="http://www.w3.org/2001/04/xmlenc#" > > > Id="I9f382e970f38be00bf4e40c5c3c54a09" > > > Service="http://test.xml trustcenter.org/XKMS" > > > xmlns="http://www.w3.org/2002/03/xkms#"> > > > <RespondWith>KeyValue</RespondWith> > > > <QueryKeyBinding> > > > <UseKeyWith Application="http://www.w3.org/2002/03/xkms#" /> > > > </QueryKeyBinding> > > > </LocateRequest> > > > > > > Not sure if it would be prudent to > > > put some suffix on the Application URI > > > (Application="http://www.w3.org/2002/03/xkms#(Security|Key)") > > > and/or support Identifiers, such as Identifier="Payload" > > > for the message-signing key, Identifier="Transport" for the TLS key? > > > > > > Also, probably better to say that the responder MUST support > > > returning > > > > > a KeyValue; it MAY support returning other key info types, such as > > > KeyName or X.509 certificates. > > > > > > merlin > > > > > > r/stephen.farrell@baltimore.ie/2002.11.27/13:08:13 > > > > > > > > > > > >I've an action to say how to do this. The idea is to specify a > > > >"magic" KeyName in the locate request which is hardcoded into the > > > >responder. The locate response will contain the usual things > > > >(depending on the RespondWith > > > >etc.) and in particular can, and most likely will, contain a > > > >KeyName which is not the "magic" value. > > > >Reponders with >1 key simply give back information about all of > > > >their > > > > > >keys as they wish (i.e. its ok to only give back info about some of > > > > >your keys, perhaps only the more recent ones). > > > > > > > >"To find the key(s) with which an XKMS responder protects messages > > > >and/or connections, an XKMS client MAY send a special Locate > > > >request to the responder which specifies a fixed QueryKeyBinding > > > >containing a > > > > > >single "ds:KeyInfo", which in turn contains a single "ds:KeyName" > > > >with a fixed case-sensitive value of "XKMSResponder". Responders > > > >MUST > > > > > >return a Locate response containing the key(s) of the responder > > > >together with whatever other information was requested in the > > > >Locate request (via the normal RespondWith mechanism). A minimal > > > >example request is shown below. > > > > > > > > <?xml version="1.0" encoding="utf-8"?> > > > > <LocateRequest > xmlns:ds="http://www.w3.org/2000/09/xmldsig#" > > > > xmlns:xenc="http://www.w3.org/2001/04/xmlenc#" > > > > Id="I9f382e970f38be00bf4e40c5c3c54a09" > > > >Service="http://test.xml trustcenter.org/XKMS" > > > > xmlns="http://www.w3.org/2002/03/xkms#"> > > > > <RespondWith>KeyValue</RespondWith> > > > > <QueryKeyBinding> > > > > <KeyInfo> > > > > <ds:KeyName>XKMSResponder</ds:KeyName> > > > > </KeyInfo> > > > > </QueryKeyBinding> > > > > </LocateRequest> > > > > > > > >If the RespondWith field in the request asks for a KeyName, then > > > >the client MUST NOT assume that the value in the response will be > > > >"XKMSResponder", in fact, it will almost certainly not be that > > > >value, > > > > > >though responders MAY choose to always include such a KeyName value > > > > >in addition to "real" key names like "XKMSRespnder@example.org". > > > > > > > >The response to this "special" locate, MUST include a "ds:KeyValue" > > > >but MAY include other forms of the key, e.g. X.509 certificates. > > > > > > > >NOTE THAT THIS MECHANISM PROVIDES NO SECURITY, NOR TRUST, VALUE > > > >WHATSOEVER AND IS SIMPLY A STANDARD MECHANISM TO RETRIEVE THE KEYS > > > >USED BY AN XKMS RESPONDER. VALIDATING THAT THOSE KEYS ARE > > > >"TRUSTWORTHY", FOR ALL DEFINITIONS OF TRUSTWORTHY, IS OUT OF SCOPE > > > >OF > > > > > >THIS SPECIFICATION." > > > > > > > >An example response would be good to add, but I haven't got one > > > >handy > > > > > >right now. > > > > > > > >I'm not sure where this ought to go in the spec, but maybe as part > > > >of > > > > > >the description of Locate with a pointer to the section from the > > > >introduction to X-KISS (section 1.4). Having the pointer in section > > > >1.4 is probably the most important thing anwyay, > > > > > > > >Cheers, > > > >Stephen. > > > > > > > >-- > > > >____________________________________________________________ > > > >Stephen Farrell > > > >Baltimore Technologies, tel: (direct line) +353 1 881 6716 > > > >39 Parkgate Street, fax: +353 1 881 7000 > > > >Dublin 8. mailto:stephen.farrell@baltimore.ie > > > >Ireland http://www.baltimore.com > > > > > > > > -- > > ____________________________________________________________ > > Stephen Farrell > > Baltimore Technologies, tel: (direct line) +353 1 881 6716 > > 39 Parkgate Street, fax: +353 1 881 7000 > > Dublin 8. mailto:stephen.farrell@baltimore.ie > > Ireland http://www.baltimore.com > > -- > ____________________________________________________________ > Stephen Farrell > Baltimore Technologies, tel: (direct line) +353 1 881 6716 > 39 Parkgate Street, fax: +353 1 881 7000 > Dublin 8. mailto:stephen.farrell@baltimore.ie > Ireland http://www.baltimore.com -- ____________________________________________________________ Stephen Farrell Baltimore Technologies, tel: (direct line) +353 1 881 6716 39 Parkgate Street, fax: +353 1 881 7000 Dublin 8. mailto:stephen.farrell@baltimore.ie Ireland http://www.baltimore.com
Received on Wednesday, 4 December 2002 12:51:07 UTC