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 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.
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:
KeyUsageelements; 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.
I hope to get (discussion and) clarification on which method (if any) is preferred.