Re: Locating the responder's public key(s)

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

Received on Tuesday, 3 December 2002 07:23:03 UTC