- From: merlin hughes <merlin@baltimore.ie>
- Date: Wed, 27 Nov 2002 18:30:56 +0000
- To: stephen.farrell@baltimore.ie
- Cc: www-xkms@w3.org
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 >
Received on Wednesday, 27 November 2002 13:31:34 UTC