XKMS Issues and Proposal

Joseph Reagle, W3C
XML Key Management Specification (20011121)

1.0 Introduction

I was originally going to send my comments in-line on the proposal on the design and some specific XML concerns. However, in focussing on the document I realized that XKMS is simply a database/directory query in a simple protocol. So when I recast XKMS in this context this allowed me to better specify my concerns and possible solutions. However, this proposal is for demonstration only; I'm not necessarily advocating this particular variation. But I do advocate there be as much generality and simplicity as possible. These examples are for X-KISS, but the same benefits would accrue to X-KRSS. It does require some changes in syntax, but I expect changes will have to made regardless, particularly the <Respond>. It doesn't add any functionality, just generality and extensibility.

2.0 XKMS 2.0 (20011121)

2.1 Example Request

"The client now needs to determine whether the binding between the name and the public key is both trustworthy and valid."


[01] <Validate>
[02]    <Query>
[03]     <Status>Valid</Status>
[04]      <ds:KeyInfo>
[05]        <ds:KeyName>...</ds:KeyName>
[06]        <ds:KeyValue>...</ds:KeyValue>
[07]      </ds:KeyInfo>
[08]   </Query>
[09]   <Respond>
[10]     <string>KeyName</string>
[11]     <string>KeyValue</string>
[12]   </Respond>
[13] </Validate>


[01] The meanings of (RetrievelMethod), "Locate", "Validate" and there "tier" structures are not immediately meaningful. They confuse the nature of the protocol action (request/action) with the sort of query (an actual key value, KeyInfo children elements, or KeyInfo children elements with other information.) The potential response of a Validate is: {Valid, Invalid, Indeterminate}. What about extensibility, or future versions of XKMS that might have an alternative response?

[03] What does Status=Valid mean in the query? Isn't this always the implicit question? Could one just as well ask <Status>Invalid</Status> in the query? (What would this mean?) Also, the Status token {Valid, Invalid, Indeterminate} should be a URI for forward compatibility and extensibility. (Phil has said he doesn't want to bother with other status' and that's fine, we can limit our support/scope to these exclusivity, but we can still have a proper mechanism.)

[05-06] Will this return keys with KeyName and KeyValue, or KeyName or KeyValue? I presume the query is conjunctive: all MUST match for a return. What about the Respond? If the only some of the requested data can be returned for the matched key, I assume they will be returned. I presume the respond is disjunctive: all data that can be returned will be. I believe that thinking of this as a simple protocol and a simple query/lookup will be important to the design and its security, we should probably look at the literature on securely designing database queries.

[10-11] KeyName and KeyValue aren't strings. Also, these "Identifiers" are magic tokens; they should be namespace qualified names. This would allow me to ask for any key structure, including those not in xmldsig. Additionally, the Multiple and Private aren't similar to the other identifiers even so and should be (namespace qualified) URIs.

2.2 Example Response

[01] <ValidateResult>
[02]    <Result MajorVersion="1" MinorVersion="2">Success</Result>
[03]    <Answer>
[04]       <KeyBinding>
[05]          <Status>Valid</Status>
[06]          <KeyID>mailto://user@host</KeyID>
[07]          <ds:KeyInfo>
[08]             <ds:KeyName>...</ds:KeyName>
[09]             <ds:KeyValue>...</ds:KeyValue>
[10]          </ds:KeyInfo>
[11]          <ValidityInterval>
[12]             <NotBefore>2000-09-20T12:00:00</NotBefore>
[13]             <NotAfter>2000-10-20T12:00:00</NotAfter>
[14]          </ValidityInterval>
[15]       </KeyBinding>
[16]    </Answer>
[17] </ValidateResult>


[02] Why do we need required Major and Minor versions? Please use namespace/URIs. (Is the Minor/MajorVersion somehow define the semantic of the "Success" if it changed between versions?) "The Service SHOULD return a requested data element if it is available. The Service MAY return additional data elements that were not requested. In particular, the service MAY return data elements specified in the request with the response." On what basis wouldn't the service return the data asked of it? Would this mean the client would imply the value doesn't exist, or some "binding" is invalid, or only indeterminent?

[03] What happens if there is more than one key that matches? (Multiple KeyBinding elements? Should their be a Multiple "Identifier" is the response as well?)

[04] The KeyBinding is not extensible, what if I want to query or return different trust semantics than those provided by XKMS?

[06] Why not use RetrievalMethod? I presume because the implication is not "this identifier is where you can get the key" but "this identifier says what HTTP scheme and address the key should be used with." That sounds like it might be useful, but I fear doing that right will be difficult if not a rat hole.

[07] Why did it return a KeyInfo? It wasn't in the query: either the KeyInfo should be specified as part of the query (which I recommend) or it shouldn't be returned in the results.

[11] For structural purposes, the ValidityInterval (and all KeyBinding children) could be in a seperate namespace. Addtionally, I believe the specification is clear, but many readers might be confused as to its meaning. For instance, if a Status of Invalid is returned with a ValdityInterval I would presume that means that the assertion that is known to be invalid only as long as the specified interval. After the interval, one might query again.

3.0 XKMS 2.0 Refactored

These examples show XKMS as simple protocol carrying a database query over xmldsig key structures and trust structures. The example is optimized for abstraction, explicitness, and extensibility.

3.1 Example Request

The client sends a query with a given ds:KeyName and is asking for the actual KeyValue, the status of the binding, and the Interval of the binding.

[01] <prtcl:Request 
[02]    <sql:Query>
[03]      <sql:From URI="http://example.org/SomeXKMService/v1.1"/>
[04]      <sql:Where>
[05]        <ds:KeyName>Joseph</ds:KeyName>
[06]      </sql:Where>
[07]      <sql:Select>
[08]        <trust:KeyId/>
[09]        <trust:Status/>
[10]        <trust:Interval/>
[11]        <ds:KeyInfo>
[12]          <ds:KeyName/>
[13]          <ds:KeyValue/>
[14]        </ds:KeyInfo>
[15]      </sql:Select>
[16]   </sql:Query>
[17] </prtcl:Request>

[01] The nature of the query has been dismabiguated from the action of the protocol: we don't need special types of requests for "Retrieve", "Locate", and "Validate".

[02] I'm using SQL conventions of FROM/WHERE/SELECT since that what's many folks are familiar with. I'm not advocating SQL particularly, just some mechanism with a clean and secure data and processing model that lets me select, insert, and delete from a database/directory.

[03] The From use to be implicit in the HTTP GET. Having it be optional is fine, but I also like the explicit provision such that it can easily be included as part of a signature. (The actual semantics corresponding to the URI could be important.)

[04] I'm using a template based query since there similar structure in XKMS, though one could also use XPATH, or XML Query.

[07] These are the actual structures being asked for. This can be very extensible. For instance, if someone comes up with a nice way of describing a key and its trust/application context they can query for that too. If I want the result to be signed, I can include a ds:Signature in the query with the expectation that the key corresponding to the entity identifed in the From signed the data.

[08-09] They two bits of semantic used to be implicit in the query. We could continue with this but I like identifying that they are part of the trust process, not the protocol aspect.

3.2 Example Response

[01] <prtcl:Response prtcl:Result="http://www.w3.org/2001/xmks/proto#Success"
[02]    <sql:Result ID="#Number1">
[03]       <sql:From URI="http://example.org/SomeXKMService/v1.1"/>
[04]       <trust:KeyBinding trust:Status="http://www.w3.org/2001/xmks/trust#Valid">
[05]          <trust:KeyID URI="mailto://user@host</trust:KeyID">
[06]          <trust:ValidityInterval>
[07]             <trust:NotBefore>2000-09-20T12:00:00</trust:NotBefore>
[08]             <trust:NotAfter>2000-10-20T12:00:00</trust:NotAfter>
[09]          </trust:ValidityInterval>
[10]          <ds:KeyInfo>
[11]             <ds:KeyName>Joseph</ds:KeyName>
[12]             <ds:KeyValue>ae234343b</ds:KeyValue>
[13]          </ds:KeyInfo>
[14]       </trust:KeyBinding>
[15]    </sql:Result>
[16] </prtcl:Response>

[01] Response status is now clearly qualifies the protocol aspect, not the nature of the key. This will also help us understand our relationship to our protocol bindings (e.g., SOAP).

[02] One can have a list of all the results (multiple Result elements) that match. (They could be ordered).

[03] From is optionally included if one wanted authentication...?

[04] The result is bound under the #Valid key binding.

[05-14] The results of the query.

4.0 Otherwise

KRSS (Key Registration) would be equivelant to an insert.