W3C XKMS Workshop, July 19, 2001

Position Paper

Peter de Rooij, Certicom

Relevant Experience

Certicom can draw on a variety of resources with extensive experience
in standardization and interoperability testing. This includes
membership and editorship in IETF (e.g., TLS), ISO, ANSI X9F, IEEE P1363,
WAP, TIA.

As a PKI and security vendor, we also have significant practical
experience to bring to bear, in particular in the constrained and
wireless environment.

Certicom needs for XKMS

Certicom is a security and PKI company offering toolkits, products,
services and consulting, with a focus on wireless and mobile security.
Therefore, Certicom has a particular interest in the applicability of
XKMS and related technologies in a wireless or mobile environment.

A stated objective of XKMS is to simplify client implementations by
enabling delegation of client tasks to a trusted service. This is
particularly useful for mobile clients, as these often are particularly
constrained - concerning user interface, computational capabilities,
memory, storage, and network latency and bandwidth.

Expectations and Potential Contributions

Application Identification

It is to be expected that many clients will use a trust service for
obtaining key location or key validation information related to a
variety of applications. Such applications may include secure
transport or network services (SSL, TLS, IPSec, etc.), as well as
transaction services (for example, document signing, signing financial
transactions, or healthcare prescriptions.) In addition, especially
mobile clients may use the same trust service for several or all of
these applications.

It is common "best practice" to use separate keys for separate
applications. It will be hard, and in many cases even impossible, for
the client to determine whether a given key may be used in a given
application.

Practically, for the X-KISS validate service, it would be of
interest to enable a means to easily distinguish the application a
given key is to be used in. I see four possible ways to achieve this:

Use the KeyId and KeyUsage elements;
the former associates the key with a URI (and therefore with a
scheme); the latter can be used to restrict key usage to one
or more of signing, encryption, or key exchange. Scheme plus
key usage give a good general indication in simple cases (e.g.,
SSL, email signing, email encryption); I would expect more
complex cases (document signing vs. contract signing) to
require application info to be stored in the path or fragment.
In the end, this may not be very elegant.

Use a different URI to access the trust service depending on the
application to access the trust service, depending on the
application (as in Section 4.1 of XKMS).

Use a higher tier service like XTASS. While this should
definitely work, I do not see this as an obvious solution, as
this does not appear to be a higher tier service.

Indicate the application directly in the validate request; the
trust service then can take this into account as a factor in
formulating its response. I see no way to do this with the
current specs.

I hope to get (discussion and) clarification on which method (if any)
is preferred.