- 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