Service Management
Resume:
XKMS Working Group
Interoperability Status Report
Guillermo Alvaro1, Stephen Farrell1, Tommy Lindberg2, Roland Lockhart3,
and Yunhao Zhang4
Trinity College Dublin, Ireland
abqbpp@r.postjobfree.com
Markup Security, Dublin, Ireland
Entrust Inc., Ottawa, Canada
SQLData, Virginia, USA
Abstract. The XML Key Management Speci cation (XKMS) is a World
Wide Web Consortium (W3C) Candidate Recommendation. Current
work on XKMS aims to demonstrate interoperability in order to progress
the speci cation along the W3C standards track. This paper describes
the state of that work and discusses some of the issues which have arisen
during the course of the work.
1 XKMS
The XML Key Management Speci cation, XKMS[1][2], is a World Wide Web
Consortium (W3C[3]) speci cation designed for retrieving and registering public
keys. It is suitable for use in conjunction with the standard for XML Signa-
tures[4] and its companion standard for XML Encryption[5] as well as in other
application contexts (e.g., email).
XKMS consists of two di erent parts: the XML Key Information Service
Speci cation (X-KISS) and the XML Key Registration Service Speci cation (X-
KRSS). X-KISS de nes a protocol to support the delegation by an application to
a service of the detailed processing of key information associated with an XML
signature, XML encryption, or other usage of the XML Signature
element. X-KRSS de nes a protocol for the registration of a public key by a key
pair holder, with the intent that the key subsequently be usable in conjunction
with X-KISS or a Public Key Infrastructure (PKI) such as X.509[6] PKIX[7].
XKMS provides XML-friendly public key management, location and valida-
tion services which are roughly equivalent to a combination of the X.509/PKIX
certi cate management protocol (CMP[8]) together with the current work-in-
progress simple certi cate validation protocol (SCVP[9]).
We will now brie y describe XKMS, focusing particularly on those aspects
of the speci cation necessary to understand the issues which have arisen during
testing.
1.1 X-KISS
Reducing the complexity of applications using XML Signature is one of the key
objectives of the protocol design. X-KISS clients are relieved of the complexity
of the underlying PKI used to establish trust relationships. These relationships
may be based upon a di erent speci cation, such as X.509/PKIX, SPKI[10] or
PGP[11].
In addition, sometimes the information provided by a signer can be insu -
cient for performing cryptographic veri cation or to be able to decide whether
to trust a signature. Alternatively, the information provided by the signer may
be in a format that is not supported by the client. In these cases communication
with an X-KISS service can be useful as a way to get that missing information.
Examples where the key information could be insu cient for the client in-
clude:
The key may be speci ed by a name only.
The key may be encoded in an X.509 certi cate that the client cannot parse.
In the case of an encryption operation, the client may not know the public
key of the recipient (e.g., just having a name).
X-KISS works via two di erent services: Locate and Validate.
Locate resolves a element but does not require the service
to make an assertion concerning the validity of the data in the
element. Validate does all that the Locate does, but in addition, the client obtains
an assertion (at that time, according to that responder) specifying the status of
the binding between the public key and other data, for example a name or a set
of extended attributes. Furthermore the service represents that each of the other
data elements returned are bound to the same public key.
Both Locate and Validate are implemented using request/response pairs of
messages, derived from MessageAbstractType abstract type, which includes all
types of messages. These message pairs are LocateRequest and LocateResult for
Locate and ValidateRequest and ValidateResult for Validate.
1.2 X-KRSS
X-KRSS handles the registration and subsequent management of public key
information. An X-KRSS service may bind information such as a name, an iden-
ti er or other attributes, to a public key, on reception of a client request. The
key may be generated by the client or by the service on request. The Registra-
tion protocol may also be used for subsequent management operations including
recovery of the private key and reissue or revocation of the key binding. The
protocol provides ways of authenticating the requester and the possession of a
private key. Additionally it provides a means of communicating the private key
to the client in the case that the private key is generated by the registration
service.
The operations constituting X-KRSS are:
Register: Information is bound to a public key through a key binding. Gener-
ation of the key pair may be performed by either the client or the Registration
service. The messages used are RegisterRequest and RegisterResult.
Reissue: A previously registered key binding is updated. It is similar to the
initial registration of a key and the principal reason a client would make a
Reissue request is to cause the registration service to generate new creden-
tials in the underlying PKI, e.g., X.509 Certi cates. The messages used are
ReissueRequest and ReissueResult.
Revoke: A previously registered key binding may be revoked. A revocation
request need only contain su cient information to identify the key binding
to be revoked and the authority for the revocation request. The messages
used are RevokeRequest and RevokeResult.
Recover: The private key associated with a key binding is recovered. The
private key must have been previously escrowed with the recovery service,
for example by means of the X-KRSS registration of a server generated key.
The messages used are RecoverRequest and RecoverResult.
1.3 Bindings
XKMS speci es SOAP and HTTP protocol bindings[2] together with relevant
security characteristics.
XKMS implementors are required to support SOAP 1.2 [12][13]. Bindings for
both SOAP 1.1[14] and plain HTTP protocols are optional.
1.4 Processing Modes
XKMS supports di erent processing modes: synchronous and asynchronous.
In synchronous processing the service immediately returns a message con-
taining the substantive response to the request.
In asynchronous processing the service returns a message to the e ect that
the request is not yet satis ed. A subsequent request/response (using a Pend-
ingRequest ) pair is needed to complete the protocol.
Asynchronous processing may be used to allow administrator intervention
during the processing of a request. For example an administrator might be re-
quired to verify and approve all X-KRSS Registration requests before they are
processed.
A StatusRequest (and StatusResult ) operation can be used to check the cur-
rent status of an operation in asynchronous processing.
XKMS requests may also employ a two phase request protocol which is used
to protect against denial of service attacks, as it allows the service to perform
a lightweight authentication of the source of an XKMS request. The two phases
of this protocol are as follows:
Phase 1: The service responds to an initial request presenting a nonce.
Phase 2: The requester sends the original request including the nonce.
The two-phase protocol may be combined with asynchronous processing.
Such a scenario might consist of three round trips as follows:
Initial request (phase 1)
Initial request (phase 2)
Pending request
1.5 Compound Messages
XKMS also supports compound requests and responses. A compound request
permits multiple XKMS requests to be made at the same time. It consists of
an outer request and one or more inner requests (X-KISS and/or X-KRSS).
The semantics of making a set of requests as a compound request are exactly
the same as if each individual request in the set had been made separately and
simultaneously [1].
The response to a compound request is a compound response. A compound
response consists of an outer response and zero or more inner responses. If the
operation is successful the compound response should contain an inner response
response element corresponding to each inner request element of the compound
request.
The compound request/response pair elements are CompoundRequest and
CompoundResult.
An XKMS service may support the use of the two phase protocol on the
outer request of a compound message, but not in an inner request. Asynchronous
processing may be used on the outer message as a whole or on individual inner
requests or both.
1.6 Implementations
The current objectives of the XKMS Working Group [15] is to demonstrate in-
teroperability. At the time of writing, interoperability tests had being conducted
using seven client toolkit implementations and four servers (table 1).
An XKMS Implementation In this section we brie y review one of the client
implementations that took part in interoperability testing - the one developed
at Trinity College, Dublin.
The client is basically a library - which is planned to be released shortly -
and several programs that use the library. The development of the client API
was done at two levels: A low level client written in C (with a length of about
4000 lines of code) and above that a higher level client library written in C++
(about 1000 lines of code long).
The library can deal with XKMS issues, and takes advantage of the bene ts
of the speci cation. For example, it can be used with X.509 certi cates, even
though the code doesn t know anything about X.509.
Implementation Client Server Type
Trinity College Dublin
intended open source
Markup Security
possibly open source
Entrust Inc.
commercial
Oracle Corporation
commercial
Apache Software Foundation
intended open source
DataPower Technology, Inc.
commercial
SQLData Systems
commercial
Table 1. XKMS Implementations
Low level implementation The low level API uses XMLSec [16], a C library
based on LibXML2 [17] that supports the major XML security standards (XML
Signature, XML Encryption, Canonical XML and Exclusive Canonical XML).
As XKMS is deeply related to these standards, the XMLSec library proved very
suitable for our implementation.
Functions de ned at this level include:
Ctx handling, used to deal with the creation and destruction of the processing
context,
Tree functions, used to add nodes and attributes into the tree structure of
the message,
Writing functions, used to generate request messages from the information
in the processing context,
Reading functions, used to parse response messages and get the information
into the processing context.
It is entirely possible to construct an XKMS communication using only these
functions. To achieve this the context structure must to be populated with the
information for the request message - including the processing mode (synchro-
nous, asynchronous, two phase), the SOAP binding used, etc.
Once the context is populated with the desired information, the function
xkmsProcCtxRequestWrite can be called and the XKMS request message will be
created, ready to be sent.
Once a response is received from the XKMS service, the function xkmsProc-
CtxProcess can be invoked to get all the information from the response message
into the context. This information can be retrieved later directly accessing the
context structure elds.
High level implementation The low level API doesn t by itself provide a ready
to use, easily con gurable, solution for developing clients. In order to provide a
better solution for developers of XKMS clients, a high level API in C++, that
uses the low level C code, was also created.
The main new concept with this API is the use of message objects. There
is a Message class that has some related functions and the di erent types of
XKMS protocol messages (Locate, Validate, Register, Compound, Pending, etc.)
derive from it. The design of these classes was simple - given the XKMS schema
and speci cation.
The functions o ered by these classes modify the processing context using
methods directly related to the message structures themselves. For example,
there is a function (xkmsAddKeyUsage ) to include a element that
states the use (Encryption, Signature, Exchange) of the key, and so on.
Other information required by this high level API can be stored in a con-
guration le, which can contain:
the SOAP binding used,
the Service access point,
whether request messages will be signed or not,
processing modes (asynchronous / two phase) and related information (e.g.,
where to direct pending noti cations)
whether the client expects the service to return the signature value of the
request, (to check response authenticity),
response limit (the number of bindings that the client is willing to accept).
Another le contains the relevant keys used by the client, like the one for
signing the message - if it is going to be signed - or the trusted keys/certi cates
for signature veri cation.
Building programs using this API should be very easy:
Initialize the libraries and the key manager that contains the keys and cer-
ti cates,
Initialize the desired message class,
Fill the context with the information from the con guration le,
Add the speci c information that is going to be sent in the request,
Communicate with the service,
Store the relevant information from the context into les,
Destroy message,
Finalize libraries.
A program example Below there is a short example of use of the high level API.
The following fragments of con guration le and code demonstrate registering
a server-generated key synchronously.
The con guration le might include the following:
\# FORMAT
\# Message Format
\# options: plain soap11 soap12
FORMAT = soap12
\# SERVICE
\# Service where the requests are directed
\# example: SERVICE = http://foo/xkms
SERVICE = http://www.example.com/xmks
\# SIGNATURE
\# Signature Flag
\# = YES, to sign the requests
\# = NO, not to sign the requests (set by default)
SIGNATURE = YES
\# ASYNCHRONOUS, TWO PHASE
\# Processing modes
\# = YES, if prepared to accept that mode
\# = NO, if processing mode not desired (set by default)
ASYNCHRONOUS = NO
TWO PHASE = NO
The program would include the following C++ code fragment:
xkmsInitialize ;
mngr = xkmsCreateKeysMngr ;
xkmsRegister message(mngr);
message.xkmsFillCtx("configuration-file");
message.xkmsAddRespondWith(xkmsRespondWithMaskPrivateKey);
message.keyBinding.xkmsAddKeyUsage(xkmsKeyUsageMaskSignature);
message.authentication.xkmsAddSharedSecret(NULL);
message.privateKey.xkmsAddPrivateKeySecret(NULL);
message.keyBinding.xkmsAddUseKeyWith("urn:ietf:rfc:2633",
"abqbpp@r.postjobfree.com");
message.xkmsCommunicate ;
message.privateKey.xkmsSavePrivateKey("keys/receivedkey.pem",
pwd, codification);
message.~xkmsRegister ;
xkmsFinalize ;
Testing this implementation This client implementation took part in the inter-
operability tests. A C++ test program, using the library, was created for each
of the tests (all of them, required and optional were supported).
Every test - required and optional - was successfully tested against the XKMS
service of Markup Security, which also supported all of them. Additionally, the
required tests were successfully tested against the XKMS service of SQLData
Systems. Finally, some X-KISS tests involving Validate operations were success-
fully tested against the XKMS service of Entrust Inc., which o ered a Validate
service.
2 XKMS interoperability
2.1 The problem
To prove interoperability between XKMS implementations each feature of the
speci cation has to be implemented and the W3C prefers two implementations
of each. However, the W3C doesn t specify how to accomplish this. Ideally there
would be several interoperable implementations covering all features. However,
this is not the case since most current implementations feature some parts of
the speci cation but not others, etc.
It is also important to remember that the purpose of the interoperability
phase is to test the speci cation itself, not the implementations - there have
been occasions when it has been hard to distinguish between testing the spec
and testing the implementations.
Note that many classical software-engineering test procedures could not be
used in this context, since most such approaches involve testing a single imple-
mentation against a test speci cation in order to test whether that implemen-
tation passes or fails. Here however, we are aiming to provide evidence that a
speci cation supports interoperability. This is basically a di erent problem, as
tests need to be run between independently developed clients and services.
One major issue to be tackled was how to be sure that every feature of the
speci cation was covered by some test. We will now describe how the XKMS
working group has handled this.
2.2 The approach taken
After studying what had happened in some other W3C working groups (in par-
ticular with respect to SOAP), the nal approach taken to demonstrate inter-
operability had three di erent steps:
1. Extract assertions from the speci cation. Initially, all the assertions in the
speci cation which contained keywords such as MUST or SHOULD were
taken out.
2. Try to cover each assertion at least once using a set of test scenarios. Each
test scenario is e ectively an executable transaction and therefore may
cover multiple assertions, though we try to minimise the number of assertions
covered by each test scenario.
3. Test clients against servers, reporting the results in an online form. Each
of the test scenarios has a di erent table allowing each implementation to
report success or failure.
The assertions and the test scenarios are contained in the Test Suite docu-
ment[18]. A password protected online form[19] enables developers to report
on their implementations, and synopses of the form are posted to the XKMS
working group mailing list periodically ([20]). The report form re-uses a script
based tool which was previously used by the W3C as a questionnaire processor.
2.3 Di culties and special cases
As with any interoperability demonstration, not all was smooth-sailing. We can
divide the problems we found into test design issues, special di culties caused
by the peculiarities of the speci cation, changes in the speci cation and the way
the results have to be interpreted.
Design of the Tests An early issue was to agree on common parameters and
conditions that would simplify testing. In particular, a common key set was
de ned in the test suite document so every server would know about it and so
that tests could refer to existing keys. (This key set has had to be extended/re-
generated a number of times as testing progressed which could have, but luckily
didn t, cause di culties for implementors.)
Covering each assertion with a good test scenario was a major issue. Separate
tests were initially de ned for each separate X-KISS or X-KRSS transaction or
operation. This allowed for basic testing of features such as the types of messages,
the SOAP bindings, the processing modes, etc.
Unfortunately, not all of the assertions found in the speci cation can be easily
tested, and some of them are not testable at all. For example, some assertions
explain the expected behaviour on receiving an incorrect message. To test that
a service shouldn t for example accept an empty string as an identi er, a client
emitting such a message would be needed, and that could be di cult to arrange.
It was decided that it was impractical to test many such assertions.
There are also some inherently untestable assertions, for example: paragraph
160 of the XKMS speci cation says that A Location service SHOULD attempt
to provide only information which is trustworthy to the best of its knowledge
but does not provide any assurance that it will do so. Information obtained
from a Locate service SHOULD NOT be relied upon unless it is validated. We
clearly cannot test this, and so it would have been better given our approach to
generating assertions, had should been used there, instead of SHOULD .
Even though we did not develop speci c tests for these assertions, it was de-
cided to leave them in the Test Suite indicating that the working group explicitly
decided not to test them.
A problem related to X-KRSS is that some of its operations result in a
state change in the server s database. For example, a key registered in a service
supporting also X-KISS should be returned in response to a subsequent Locate
operation. However, as it is not a requirement to support both services it wasn t
a good idea to create a test that combined both operations since they might make
a later conformance or regression test harder for an implementation. (This is an
example of how testing the speci cation and testing the implementations may
subtly di er!) In this case, some X-KRSS tests combined registration of a key
binding with further X-KRSS operations (like a revocation of the key binding),
so the change in the server s database was implicitly tested.
Peculiarities of XKMS that made testing di cult Like many protocols,
XKMS is quite open and exible, with many optional elements and with decisions
left to the implementations. As an example of this, there are (properly) few
constraints on what an X-KISS service should return on receiving a request.
There is exibility for the implementor on how to match the information sent by
the requester to the information that the service has. For example, if a service
receives a request with elements referring to two di erent keys, the returned
response is implementation dependent - there is no speci cation as to whether
the response ought re ect the union or the intersection of the di erent keys. It is
even possible that the same instance of a service could take di erent approaches
in uenced by the identity of the requester, from where the request is being made
or about whom.
Obviously, not always knowing the expected results makes testing more di -
cult so some additional conditions have to be imposed, not for the speci cation
itself, but for the tests.
Another problem was how to test a speci c behaviour of an implementation
where the openness of the speci cation allows other behaviours as well. For ex-
ample, a registration request could take an entire day to be processed, if some
human intervention is required. In that case we are dealing with an asynchro-
nous operation in which a Status Request can be made, which can result in a
Pending result code. As the speci cation doesn t de ne when this completion
has to take place, it is a perfectly valid behaviour for a server to complete it
immediately, which would make it impossible to get the Pending result code.
A solution to this particular case was agreed by having the server implementa-
tion trigger (delayed) completion of the asynchronous request upon receipt of
the StatusRequest. Special behaviours like this related to the tests had also to
be included in the Test Suite speci cation.
Yet another particularity of the speci cation was how to deal with the exis-
tence of elements with no limit in the number of occurrences (maxOccurs= un-
bounded in the schema). For interoperability it was agreed to interpret this as
meaning that any relevant test message had to have at least two instances of the
element in question. But this doesn t completely solve the question as we are
not checking whether a service could handle messages with a huge number of
occurrences. A solution to this is planned - essentially de ning reasonable nite
values for each unbounded occurrence in the next version of the base XKMS
speci cation.
Compound messages are another peculiarity of XKMS that make interop-
erability di cult, as they may contain inner X-KISS and X-KRSS messages at
the same time. This means that we need to combine the tests for the individual
operations, which could lead to a combinatorial explosion in the number of tests.
Also, as the semantics of making a set of requests as a compound request are
(claimed to be!) exactly the same as if each of them had been made separately
and simultaneously, special cases should be considered. For example: register-
ing, retrieving and revoking the same key in the same outer compound message.
Again, as the openness of the speci cation may not specify the expected behav-
iour in some of these cases, care must be taken to de ne the conditions and reach
an agreement, at least for the interoperability demonstration purposes.
Changes in the speci cation and the schema Some of the issues that have
arisen during testing have pointed to di erences between the speci cation text
and the part of the schema they are describing. For example, it used be stated
that it is possible to include inner Pending Requests in the outer Compound
Request, whereas the XKMS schema didn t allow that. Generally implementors
have followed the schema but each time this has occured we had to discuss
whether a change should be made to the schema or to the speci cation.
There are also cases where the working group decided that schema changes
were required. For example, it was decided that the name of an element and
a type would have to be changed (RSAKeyValue and RSAKeyValueType to
RSAKeyPair and RSAKeyPairType respectively) and (more subtly) that QNames
would be replaced with URIs using an open enumeration technique.
The problem here was when and how to apply those changes. One possibility
was to change the schema when reaching Proposed Recommendation status.
However, this would prevent testing the changes on the schema until that point.
(Essentially this is due to the W3C process for promoting the speci cation to
the next level.)
Once the schema was modi ed, we then had to decide whether a new names-
pace is required or if the changes would be made into the current location (since
the namespace is also a URL!).
Finally, changing the schema when some tests have already been made, raises
another question: Should all the tests be made again using the new schema? As
the change in the schema may a ect the implementations it seems that it would
be necessary to re-test. The problem is how to re ect the tests in the report site,
should previous tests be deleted or should the new ones be added? The approach
we have taken is to ask all implementors to do one last execution of all tests at
the end of the process.
A small modi cation was done to the schema after the interoperability test-
ing period: we added new result minor codes to indicate reasons for failure such
as that certain elements were required (ProofOfPossessionRequired), not sup-
ported (OptionalElementNotSupported, TimeInstantNotSupported) or out of
range (TimeInstantOutOfRange). These changes had no impact on the testing,
but aim to avoid the need for out of band communication between parties (caused
by the openness of the speci cation).
Interpreting Results Having an agreement on the tests and assuming that the
speci cation is going to be properly covered doesn t guarantee that all pitfalls of
the speci cation are going to be discovered. Firstly, because there is not a great
level of detail about reasons for failure in response messages, errors between
implementations generally have to be diagnosed through direct contact between
implementors.
Also, reporting the success or failure of the tests against the services in the
report site was not an easily measurable action, except for completely successful
tests. Moreover, as some implementations support only parts of the speci cation,
summary results obtained from the report site mean less than rst appears.
Ultimately, for each scenario, the overall success or failure of the test has to be
determined by hand.
2.4 Current Results
This section documents the current state of testing in the middle and at the end
of the interoperability testing period.
Table 2 summarises the test results at the middle of the interoperability
phase.
Tests [18] Total # Tests Success Partial
XKISS-[T1-T5] (Messages) 5 5 0
XKISS-[T6-T8] (Protocols) 3 2 1
XKISS-[T9-T12] (Compound) 4 0 3
XKISS-[T13-T14] (Bindings) 2 2 0
XKRSS-[T1-T5] (Messages) 5 0 0
Table 2. XKMS testing status, 28 October 2004
Table 3 below summarises the latest test results.
Tests [18] Total # Tests Success Partial
XKISS-[T1-T5] (Messages) 5 5 0
XKISS-[T6-T8] (Protocols) 3 3 0
XKISS-[T9-T12] (Compound) 4 4 0
XKISS-[T13-T14] (Bindings) 2 2 0
XKISS-[T15-T18] (Additional features) 4 4 0
XKRSS-[T1-T6] (Messages) 5 5 0
XKRSS-[T7-T9] (Protocols) 3 3 0
XKISS-[T10-T13] (Compound) 4 4 0
XKISS-T14 (Additional features) 1 1 0
Compound-T1 (Compound) 1 1 0
Optional-[T1-T3] (Additional features) 3 3 0
Table 3. XKMS testing status, 25 January 2005
For compulsory tests, a status of success was assigned only for those tests for
which at least two servers successfully passed the test with at least two clients
(the XKMS working group s agreed success criterion). Partial success status was
assigned where one server has worked with at least two clients.
The XKMS working group s agreed success criterion for optional tests was
that at least one server had successfully passed the test with at least two clients.
Note that the testing protocol only required implementors to declare their
results, there was no independent oversight of the results. This was the simplest
way to proceed given that some of the implementations are commercial.
Counting success as one point and partial as a half, the above implies
that testing (of X-KISS) was about 78 per-cent complete at the middle of this
phase. However, more tests were added later.
Testing is a hundred per-cent complete now. A summary of interoperability
can be found at [21].
At the end of the testing period, one service (Markup Security) supported
all the tests (even the optional ones), and another service (SQLData) supported
all the required tests. The ASF-XKMS service supported the X-KISS tests and
Entrust s service supported the X-KISS tests involving Validate operations.
3 Conclusions
Advancing along the W3C s Recommendation track is quite a convoluted process
which requires ful lling various criteria including interoperability testing. Every
speci cation has its peculiarities which can require a new testing scheme unlike
any done by previous W3C (or other) working groups.
There are also di culties related not only to the carrying out of the tests but
also to the design of the tests themselves, as it is not practical to demonstrate
interoperability for every single optional eld in the entire speci cation. There
is also serious additional complexity in testing compound messages which may
not have been apparent when this feature was added to the speci cation.
However, the working group believes it has de ned a reasonable set of tests
which cover all the most interesting use cases for XKMS.
Good communication between working group members has been vital in mak-
ing possible the work done to date, as has the signi cant amount of e ort in-
vested by both commercial and (putative) open source implementors. Without
that level of e ort, it is de nitely the case that a signi cant number of bugs in
the XKMS speci cation would have gone unnoticed. Even though none of the
problems found has been very serious from a security or functional point of view,
a number of them would have prevented interoperability.
Finally, it would of course have been better had the authors of the XKMS
speci cation taken more account of testing at an earlier stage - in particular
had they considered whether MUST/SHOULD type assertions could be tested
or not, (though of course the working group had not decided to generate tests
that way at that early stage - so here we are really asking for clairvoyance!).
4 Acknowledgements
The authors wish to acknowledge the XKMS Working Group members for their
work, especially to Jose Kahan (W3C team member) and Shivaram Mysore (co-
chair with SF).
GA s work on XKMS was supported by Microsoft Research.
References
1. P. Hallam-Baker and S. H. Mysore. XML Key Management Spec-
i cation (XKMS 2.0), W3C Proposed Recommendation, May 2005.
http://www.w3.org/TR/2005/PR-xkms2-20050502/.
2. P. Hallam-Baker and S. H. Mysore. XML Key Management Speci ca-
tion (XKMS 2.0) Bindings, W3C Proposed Recommendation, May 2005.
http://www.w3.org/TR/2005/PR-xkms2-bindings-20050502/.
3. World Wide Web Consortium. W3C. http://www.w3.org/.
4. D. Eastlake, D. Solo, M. Bartel, J. Boyer, B. Fox, and E. Simon. XML-
Signature Syntax and Processing, W3C Recommendation, February 2002.
http://www.w3.org/TR/xmldsig-core/.
5. D. Eastlake, J. Reagle, T. Imamura, B. Dillaway, and E. Simon. XML
Encryption Syntax and Processing, W3C Recommendation, December 2002.
http://www.w3.org/TR/xmlenc-core/.
6. International Telecommunications Union-Telecommunication. ITU-T Recommen-
dation X.509 (1997 E): Information Technology - Open Systems Interconnection -
The Directory: Authentication Framework, June 1997.
7. R. Housley, W. Polk, W. Ford, and D. Solo. Internet X.509 Public Key Infrastruc-
ture Certi cate and Certi cate Revocation List (CRL) Pro le, IETF RFC 3280,
April 2002. http://www.ietf.org/rfc/rfc3280.txt.
8. C. Adams and S. Farrell. Internet X.509 Public Key Infrastruc-
ture Certi cate Management Protocols, IETF RFC 2510, March 1999.
http://www.ietf.org/rfc/rfc2510.txt.
9. T. Freeman, R. Housley, A. Malpani, D. Cooper, and T. Polk. Simple Certi -
cate Validation Protocol (SCVP), February 2005. http://www.ietf.org/internet-
drafts/draft-ietf-pkix-scvp-18.txt.
10. C. Ellison. SPKI Requirements, IETF RFC 2692, September 1999.
http://www.ietf.org/rfc/rfc2692.txt.
11. J. Callas, L. Donnerhacke, H. Finney, and R. Thayer. OpenPGP Message Format,
IETF RFC 2440, November 1998. http://www.ietf.org/rfc/rfc2440.txt.
12. M. Gudgin et al. SOAP Version 1.2 Part 1: Messaging Framework, W3C
Recommendation, June 2003. http://www.w3.org/TR/2003/REC-soap12-part1-
20030624/.
13. M. Gudgin et al. SOAP Version 1.2 Part 2: Adjuncts, W3C Recommendation,
June 2003. http://www.w3.org/TR/2003/REC-soap12-part2-20030624/.
14. D. Box, D Ehnebuske, G. Kakivaya, A. Layman, N. Mendelsohn, H. Frystyk
Nielsen, S Thatte, and D. Winer. Simple Object Access Protocol (SOAP) 1.1,
W3C Note, May 2000. http://www.w3.org/TR/2000/NOTE-SOAP-20000508/.
15. XKMS Working Group. Xml key management working group.
http://www.w3.org/2001/XKMS/.
16. A. Sanin. XML Security Library. http://www.aleksey.com/xmlsec/.
17. D. Veillard. Libxml2 - The XML C parser and toolkit of Gnome.
http://xmlsoft.org/.
18. G. Alvaro. Xkms assertions and test collection.
http://www.w3.org/2001/XKMS/Drafts/test-suite/CR-XKMS-test-suite.html.
19. XKMS Working Group. Xkms cr test-suite report.
http://www.w3.org/2002/09/wbs/1/XKMS-WG-CR-TEST-SUITE/.
20. XKMS Working Group. Final results of questionnaire xkms cr test-suite report.
http://www.w3.org/2001/XKMS/Drafts/test-suite/results-snapshot.html.
21. XKMS Working Group. Xkms candidate recommendation implementation report.
http://www.w3.org/2001/XKMS/Drafts/test-suite/CR-XKMS-Summary.html.
er.dvi
Contact this candidate