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.