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.
"The client now needs to determine whether the binding between the name and the public key is both trustworthy and valid."
Request:
[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.
[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.
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.
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
xmlns:prtcl="http://www.w3.org/2001/xmks/proto#"
xmlns:sql="http://www.w3.org/2001/xmks/sql#"
xmlns:trust="http://www.w3.org/2001/xmks/trust#"
xmlns:ds="http://www.w3.org/2001/09/xmldsig#">
[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.
[01] <prtcl:Response prtcl:Result="http://www.w3.org/2001/xmks/proto#Success"
xmlns:prtcl="http://www.w3.org/2001/xmks/proto"
xmlns:sql="http://www.w3.org/2001/xmks/sql#"
xmlns:trust="http://www.w3.org/2001/xmks/trust"
xmlns:ds="http://www.w3.org/2001/09/xmldsig#">
[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.
KRSS (Key Registration) would be equivelant to an insert.