- XKMS WG Chair(s):
- Shivaram Mysore < email@example.com
- Stephen Farrell < firstname.lastname@example.org
- XKMS Editor:
- Phillip Hallam-Baker < email@example.com >
- Issues List Maintainer(s):
- Phillip Hallam-Baker < firstname.lastname@example.org
This page enumerates outstanding issues on the XML Key Management Specification. The
source of an issue need not be its first instance; it also might reference a
cogent description or WG poll. Also, this document may not capture editorial
tweaks and errors that were easily and quickly remedied.
This page will contain two tables. Outstanding issues are recorded
in the first table. They are typed as either Editorial (including
typos and small clarifications), Clarification (where significant
explanatory text is required) or Major. In some cases, a
volunteer has been identified, but in case not, then implementation of the
proposed resolution is left to the specification editor(s). Once an
issue has been resolved (meaning that a resolution satisfactory to the group
is agreed and has been included in the latest version of the specification),
the issue is moved to the `Resolved Issues' table. The issue index
number is maintained to allow for consistent referencing.
New issues, and the resolution of issues should be reported to the XKMS mailing list. Before doing so,
ensure that the issue is not already covered by an issue either in the
"Outstanding Issues" table (in which case, a new issue need not be entered)
or in the "Resolved Issues" table (in which case a new outstanding issue
should be created, as opposed to moved from resolved to outstanding).
In addition, for newly discovered issues, the discoverer should
identify an related issues that may already be cited in either table
Outstanding Issues Last
|Editorial Fix for SOAP 1.2 Usage; Editorial fixes
required for Part 2 of the spec.
|Support for Delegated Signature in KeyUsage
Pinkas - IETF/PKIX
|Need to clarify what is an issue and what is not - see
- 1. Section 2.6: Two Phase Request Protocol. As far as I can
tell from the text, the purpose of the two phase protocol and the
nonce is for the service to protect itself against Denial of
Service attacks and against replay attacks. So why is it sensible
to make the client trigger this by including "Represent" in the
first request message? How does the client know that the service
will want to do this?
On p.15 it says that if the service requires use of the two phase
protocol and the requester did not put "Represent" in the
request, then the service is to return a MajorResult of
"Receiver" and a MinorResult of "MustRepresent". This logic seems
odd -- almost as if the service is returning an error for a
badly-formed request (even though the requester can't have known
beforehand that this was needed). It would be preferable, I
think, to simply send the regular response with a MajorResult of
"Represent"; if the requester can't deal with this, then *it*
should send the error message.
- Section 3.3.1: Element . Related to the previous comment, I'll
just note that if you want to keep the interchange the way it is
currently specified then you need to add a MinorResult of
"MustRepresent" to the second table in 18.104.22.168.
- Section 3.3.2: Element . The last line of the first paragraph
says, "This provides a cryptographic linkage between the request
and the response." Note that it's only a "cryptographic linkage"
if the response is signed or cryptographically protected in some
other way. The conditions in the remainder of the section do not
- Section 6.1.1: Example: Registration of Client-Generated Key
Pair. In the element, there is no key identifier. How is the
service supposed to know which key to use to verify this binding?
Is it supposed to be implied from the elements in ? If so (or if
there's some other way that the service is supposed to figure
this out), shouldn't this be specified somewhere so that
implementers know what to build?
- Section 6.1.2: Example: Registration of Service-Generated Key
Pair. The third paragraph talks about encrypting the returned
private key using a symmetric key derived from the authentication
code and includes the following text: "as described in Appendix
C.1.3". But Appendix C.1.3 does not describe this process in any
way. What should be said is "as described in Section 8.1; see
also Appendix C.1.3". [As an aside, was the key derivation
algorithm in Section 8.1 created for the purposes of this
specification? Are there not standard ones out there (e.g., in
FIPS, ANSI, etc.) that could have been used instead?]
|Document doesn't flow as smoothly as it might:
- Section 1 says there are two "service specifications" but
doesn't say where they are more fully described or specified.
- The sections in section 1.7 do not correspond to the sections
of the table of contents.
- Section 1.5 has the same title as Section 4 (except that it has
"specification"). How to make this flow better, or at least use
the term (r not) "specification" consistently.
- Generally, I don't distinguish between a "message format" and a
"message syntax." What do these section do differently?
|I think there are 2 errors in the XKMS last call
schema at http://www.w3.org/TR/2003/WD-xkms2-20030418/Schemas/xkms.xsd
- The choice of inner results in CompoundResult should have a
minOccurs attribute of 0, rather than defaulting to 1. The text
at paragraph 77 of the XKMS spec part I indicates that there can
be zero or more inner responses. This makes sense because a
service which does not support compound requests will want to
return an empty CompoundResult.
- The comment field just above the CompoundResult definition
mistakenly refers to it as "CompoundResponse".
- As far as can see, there is no way to specify the desired key
type (RSA/DSA/...) in <xkms:LocateRequest/> or
<xkms:ValidateRequest/>. This is not a major problem
because XKISS server may return a list of keys but I think that
in most case the desired key type is known to the client and
could be used to narrow key search on the server side (and reduce
network traffic :) ). For example, I can easily imagine that RSA
and DSA keys would be stored in different database tables. Key
type may limit key search to one table instead of two.
- It does not seem that there is a way to use symmetric keys.
While public key cryptography is became more and more afordable,
there are still situations when symmetric key cryptography is
usefull either because of performance, legacy or some other
reasons. An use case example might be a couple of high traffic
servers when one stores some sensitive data on the client in an
encrypted format (say, in cookies) and another one decrypt this
data. These two servers may use XKISS server as a central keys
storage (for example, to provide keys rotation). Using symmetric
keys might be desirable because of performance reasons as well as
small encrypted data size.
- In the schema for <xkms:ValidityInreval/> element
"NotBefore" and "NotAfter" attributes do not have
"use=\"optional\"" specified. 3) The "maxOccurs=\"3\"" for
<xkms:KeyUsage/> element may prevent schema extension in
the future, I would suggest to change this to
- Interop Test suite available ??
|Section 4.2.1 Example: Document Signature
The XKMS ValidateResponse is not correct according to the
The ValidateRequest requires KeyName element to be present in
ValidateResult, the ValidateResult has the ResultMajor = Success but
only contains X509Certificate in KeyInfo, according to this example
KeyName should be present in KeyInfo for ResultMajor = Success . This
shows that ValidateResult is not composed successfully.
- In section 2.5.2 it is described:
Service generation of the Pending Response Message
RequestID is set to the value of Id in the Pending
request message Nonce is not present
set to a randomly generated unique value
- Corresponding example the values are not given correctly: In
22.214.171.124 Response the value of RequestId should be
"#I4294d3993de300c1ef54d49bd0903b2d" according to the
- Clarify use of "#" before the Id values in XKMS Response
Protocol Binding Spec (Part 2):
- Just before line 386, Appendix DReferences -- TYPO; Need Space
in between D & References
- [CSP] TBD -- FILL-IN HERE !!
- Just before line 75, [PKIX] TDB -- FILL-IN HERE !!
- [SPKI] TDB -- FILL-IN HERE !!
- also make items in  bold to be consistent.
- line 80 will need a hard reference soon.
- just before line 84 another item [XML-ns] that needs to be in
Last $Revision: 1.1 $ by $Author: sfarrell $ on $Date: 2003/08/08 13:05:10 $