XML Key Management Services

XML Key Management Services Position Paper

Submitted for the W3C Workshop on XML Key Management Services, July 19, 2001

Software Architect

Microsoft Corporation

Microsoft hereby grants to the W3C a perpetual, nonexclusive, non-sublicensable, non assignable, royalty-free, world-wide right and license under any Microsoft copyrights in this contribution to copy, publish and distribute the contribution.

This contribution and the information contained herein is provided on an "AS IS" basis and to the maximum extent permitted by applicable law, Microsoft provides the contribution AS IS AND WITH ALL FAULTS, and hereby disclaims all other warranties and conditions, either express, implied or statutory, including, but not limited to, any (if any) implied warranties, duties or conditions of merchantability, of fitness for a particular purpose, of accuracy or completeness of responses, of results, of workmanlike effort, of lack of viruses, and of lack of negligence, all with regard to the contribution. ALSO, THERE IS NO WARRANTY OR CONDITION OF TITLE, QUIET ENJOYMENT, QUIET POSSESSION, CORRESPONDENCE TO DESCRIPTION OR NON-INFRINGEMENT WITH REGARD TO THE CONTRIBUTION.

IN NO EVENT WILL MICROSOFT BE LIABLE TO ANY OTHER PARTY INCLUDING THE W3C AND ITS MEMBERS FOR THE COST OF PROCURING SUBSTITUTE GOODS OR SERVICES, LOST PROFITS, LOSS OF USE, LOSS OF DATA, OR ANY INCIDENTAL, CONSEQUENTIAL, DIRECT, INDIRECT, OR SPECIAL DAMAGES WHETHER UNDER CONTRACT, TORT, WARRANTY, OR OTHERWISE, ARISING IN ANY WAY OUT OF THIS OR ANY OTHER AGREEMENT RELATING TO THIS DOCUMENT, WHETHER OR NOT SUCH PARTY HAD ADVANCE NOTICE OF THE POSSIBILITY OF SUCH DAMAGES.

With the emergence of rich XML Web services as envisioned by Microsoft’s .NET initiative, the ability to secure those services will be essential. This will include requirements to authenticate participating entities, encrypt communications for confidentiality, and ensure message integrity. A variety of technologies may contribute in this area, including existing technology such as TLS/SSL[6] and IPSEC[1]. But we also anticipate new security functionality based on the W3C/IETF XML Signature[11] and W3C XML Encryption[12] standard efforts along with the natural extension of these technologies to integrated security features in SOAP[7] (or future W3C XML Protocol Activity products) and WSDL[9].

It seems clear that public key cryptography will play an important role in securing XML Web services and applications. To facilitate use of this technology, we will need infrastructure for establishing trust in public keys as well as distributing and managing keying information. It is highly desirable that this infrastructure be based on the same paradigms used for other services and applications. The existing XKMS Note[10] meets this requirement, defining interfaces to key management and trust services based on SOAP and WSDL.

The services defined in the XKMS Note offer several advantages when compared with existing public key trust infrastructures such as the X509 Certificate based PKIX[4] or PGP[3] standards. While a full treatment of this issue is beyond the scope of this paper, some of the more significant aspects of XKMS are touched on in the subsequent paragraphs.

First, the XKMS Note defines an XML Web service. Hence, the same tools, programming model, data representation, and connectivity assumptions are shared between XKMS and XML Web service applications using it. This offers clear advantages to the software developer in terms of application development, deployment, and maintenance. It may also prove critically important for small form-factor devices hosting XML-based applications where support for security-only components (i.e., ASN.1[5] parsers, PKCS#7[6] formatters) may be impractical. In addition, a single implementation can target different XKMS services providers by simply pointing to the appropriate URL. This inherent support for multiple trust services provides flexibility and resilience important for many applications.

Furthermore, use of an XML-based service approach creates a very useful synergism between XKMS and other XML security technologies. The XKMS Note already leverages XML Signature. But, it is also positioned to take advantage of SOAP/XML Protocol and WSDL integrated security solutions as they are developed. An XKMS service will be able to leverage these for authenticated and secured communication with its users. This would eliminate reliance on TLS/SSL or IPSEC to ensure authenticity and integrity of communications.

Second, XKMS envisions a connected world where real-time interaction between network applications, using cryptographic security technology, are the norm. In particular, XKMS can support actions such as trust-delegation and real-time key validation. This is quite different from the assumptions in most deployed PKI systems. These existing systems arose in a poorly connected world where real-time reliance on a trusted party was problematic. Consistent with this, they assume:

- Binding of keys to relevant attributes occurs ahead of actual key use, i.e., the applications are known ahead of time and don’t change.

- Trust assertions are immutable. They can be revoked, but not updated.

- Relying parties are responsible for trust assessment and hold all the required information (certificates, CRLs, CA root keys) to make that assessment.

These have some important consequences for the using applications. Most importantly, one often needs to communicate significant trust information (e.g., certificate chains) between parties and all parties need to cache a significant amount of information (CA roots, intermediate certificates, CRLs, CRL distribution points, and so forth). While this may remain an appropriate approach for many applications, XKMS offers a better alternative for many applications.

An XKMS-based application can rely on an XKMS service to resolve the trust in a given key. This makes it feasible to communicate key information using a lightweight reference or actual key value, eliminating much of the information typically cached by today’s applications. The XKMS service can then use a variety of means to determine the trustworthiness of the key. For example look-up in a private database or X.509 certificate chain evaluation using a back-end PKIX-style PKI. This ability to abstract the trust determination mechanism from the exposed service interfaces is a strength of the XKMS Note services.

For applications that want to do their own trust evaluation, XKMS still has value. For instance, it provides a standard means of publishing application public keys so other parties can locate them. It also provide a means of retrieving key values and obtaining real-time status information for a given key, similar in concept to what OCSP[2] provides for a PKIX-style PKI.

XKMS also has the potential to support context dependent trust assessment. This is quite different from existing infrastructures where the usage is defined up front and is immutable. An XKMS service can be an equal participant with other Web-based applications and services. Hence, they can work cooperatively in a peer-to-peer relationship, with the relying party defining a usage context and the XKMS service determining trust appropriate for that context. For example, an application could inquire if an authentication key was valid in the context of a $5 transaction or a $10K transaction. The answers might be different. This capability raises the possibility of trust services that are adaptive to new applications and usages over time. This would require extensions to the XKMS Note to accommodate registering keys for specific usages, updating those allowed usages over time, communicating context information between XKMS services and applications, and so forth.

In summary, the existing XKMS Note is a great starting point for incorporating key management and trust services into world envisioned by the .NET initiative, but, it’s only a starting point. It is hoped the XKMS Workshop will generate broad based interest in establishing a W3C standards effort in this area. This would bring the requisite industry experience to bear in evaluating the richness, robustness and flexibility required of such services and specifying these in a standard XML-based service definition. It is also hoped such a effort will look at possible extensions to the services defined in the XKMS Note, such as context dependent trust assessment and adaptive behaviors mentioned earlier. It would be most beneficial to the industry if these were defined as part of an integrated set of trust management services. This effort should, of course, be coordinated with other on-going and emerging web service related W3C activities.

REFERENCES

[1] IETF Working Group, IP Security Protocol (IPSEC). Multiple specifications including RFCs 1828, 1829, 2104, 2085, 2401, 2410, 2411, 2402, 2412, 2451, 2403, 2404, 2405, 2406, 2407, 2408, 2409, and 2857.

[2] X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP (RFC 2560)

[3] IETF Working Group, An Open Specification for Pretty Good Privacy (openPGP). Multiple specifications including RFC 2440.

[4] IETF Working Group, Public Key Infrastructure (X.509) (pkix). Multiple specifications including RFCs 2459, 2510, 2511, 2527, 2528, 2559, 2585, 2587, 2560, 2797, 2875, 3039, and 3029.

[5] ITU X.680, Abstract Syntax Notation One (ASN.1): Specification of Base Notation, Dec 97.

[6] PKCS #7 - Cryptographic Message Syntax Standard,v1.5, RSA Security, 10 Nov 93.

[7] Simple Object Access Protocol (SOAP) 1.1, W3C Note 08 May 2000

[8] The TLS Protocol Version 1.0. T. Dierks, C. Allen. January 1999. (RFC 2246 )

[9] Web Services Description Language (WSDL) 1.1, W3C Note 15 March 2001

[10] XML Key Management Specification (XKMS) W3C Note 30 March 2001

[11] XML-Signature Syntax and Processing. D. Eastlake, J. Reagle, D. Solo. March 2001. (RFC 3075)

[12] W3C XML Encryption Working Group