OASIS Open

FAQ

1. What is the rationale behind this standardization effort? What is the motivation of the sponsors/authors?
2. What is the scope of this effort? What is explicitly out-of-scope, and why?
3. Are there existing comparable or overlapping standards, or comparable standardization efforts currently under way (inside or outside OASIS)? How does the work of this technical committee relate to these? What distinguishes this TC from similar work? How do the differences add value?
4. Is the product of this technical committee intended to be used in conjunction with other standards or complementary technologies? What are these? How does this work relate to these (is the usage of these complements mandatory? optional? restricted or profiled?)
5. Can you give some example of concrete applications that will benefit from standardizing the specifications from this TC?
6. Is it anticipated that TC deliverables will be broadly used, deployed, and/or implemented? Or are the deliverables intended for a narrow audience, possibly including only the TC membership?
7. Do you see external factors that should help a broad acceptance and deployment of the specifications from this TC? And factors that may potentially hinder a broad acceptance and deployment?
8. Do you know of companies or industry verticals that have already expressed interest in using the specification(s) produced by the TC in their products or services?
9. Regarding the adoption of this specification(s) by a vendor for its products: is this a decision that vendor companies can make individually, or are the interoperability aspects important enough to require industry-wide, coordinated adoption?
10. Have the authors and their companies considered further ways to promote the produced specification(s) after completion (PR, marketing, campaigns, industry consortia....)?
11. What are the security implications, if any, of this effort?

1. What is the rationale behind this standardization effort? What is the motivation of the sponsors/authors?

   For over two decades, companies have been focused on protecting the perimeter of their computer infrastructure through the use of "perimeter-deterrents" such as firewalls, intrusion prevention systems and other end-point access control mechanisms. A few very risk-averse institutions — primarily in the financial and defense sectors - went beyond perimeter-protection and encrypted data while at rest, in transit and some, even while in use (through the use of compartmentalized systems).

   This "hard exterior but soft center" of the vast majority of computer infrastructures now haunts the industry as one company after another divulges breaches to sensitive customer data in every consumer-focused sector - financial, retail, healthcare, education and government.

   Securing the core — the data — by encrypting data across the enterprise, has not been an option for most companies due to the lack of standards in symmetric key-management (amongst other reasons). While asymmetric key-management has a plethora of standards (thank you PKIX), symmetric key-management has suffered from a woeful lack of attention.

   While there have been recommendations and some standards from organizations like the NIST and ANSI, the architecture and scope of those recommendations do not address the gargantuan size of the internet — where every client device is a potential consumer of symmetric key-management services — and industries outside the financial and defense sectors.

   OASIS — the Organization for the Advancement of Structured Information Systems — has chosen to take up the gauntlet and created an Enterprise Key Management Infrastructure Technical Committee (EKMI TC) to address this gap.

2. What is the scope of this effort? What is explicitly out-of-scope, and why?

   The EKMI TC has identified four specific goals:

   • To standardize on Symmetric Key Services Markup Language (SKSML) — a secure network-based web-service protocol for client applications to request key-management services of a network-based server, much as DNS and DHCP clients request services of their respective servers;
   • To create Implementation and Operations Guidelines for the creation of enterprise-scale EKMI, typically consisting of a Public Key Infrastructure (PKI) for asymmetric key-management, and a Symmetric Key Management System (SKMS) for symmetric key-management;
   • To create Audit Guidelines for Information Security Auditors to audit EKMIs. This goal is being accomplished with the support of members from ISACA — the Information Systems Auditors and Control Association;
   • To create an interoperability test-suite for conformance testing of SKSML implementations.
3. Are there existing comparable or overlapping standards, or comparable standardization efforts currently under way (inside or outside OASIS)? How does the work of this technical committee relate to these? What distinguishes this TC from similar work? How do the differences add value?

   The International Standards Organization (ISO) has published standards such as ISO 11770-3:1999 Key management, while the American National Standards Institute (ANSI has published documents such as X9.117 and X9.24 related to key-management. However, these standards primarily focus on financial sectors without addressing the general computing infrastructure of companies within and outside the financial sector.

   The Institute of Electrical and Electronics Engineers (IEEE) has started a working group designated P1619.3, titled "Standard for Key Management Infrastructure for Cryptographic Protection of Stored Data," and whose scope is ".. an architecture for the key management infrastructure for cryptographic protection of stored data, describing interfaces, methods and algorithms."

   While the P1619.3 group has a more general focus than the ISO/ANSI standards, the group still restricts itself to key-management for storage devices such as disk-drives, tape-drives, SAN, NAS, etc.

   The OASIS EKMI TC has the broadest scope of all. It is not focused on any specific industry or device. On the contrary, the OASIS effort believes that key-management must be as generic a service as the Domain Name Service (DNS) is — applicable and accessible to anything that needs key-management services.

   A second distinction that the EKMI TC makes is in the belief that data must be encrypted and decrypted only in the application that needs to see the plaintext (unencrypted data). This is the topmost layer of the application stack. If the cryptographic operation is performed in any other layer of the stack, however efficient it might be in the short-term, residual vulnerabilities in the layers between the cryptographic layer and the application layer will remain. Given the effort that companies must expend to encrypt sensitive data and manage encryption keys, it behooves them to do it right, and to do it just once. Encrypting in any layer other than the application layer will only require the data-owners to revisit the problem again.

4. Is the product of this technical committee intended to be used in conjunction with other standards or complementary technologies? What are these? How does this work relate to these (is the usage of these complements mandatory? optional? restricted or profiled?)

   Yes.

   The Symmetric Key Services Markup Language (SKSML) — one of the primary deliverables of this TC — depends on the following standards:

   • OASIS' Web Service Security (WSS) - It is mandatory for SKSML to use WSS. The reason for this is that a Symmetric Key Management System (SKMS) provides security services whose compromise could be devastating to companies. It must, by necessity, strongly authenticate all messages between clients and servers. As such, SKSML will use only digitally signed requests and responses, which are encapsulated in the WSS protocol.
   • W3C' XML Signature — while SKSML does not use XML Signature directly, it is encapsulated within the WSS protocol for digitally signed messages. However, the open-source implementation of an SKMS (currently available from www.strongkey.org) uses XML Signature to maintain the integrity of all data objects on the Symmetric Key Services (SKS) server. It is recommended that conforming implementations use XML Signature for maintaining the data-integrity of SKMS objects.
   • W3C' XML Encryption - SKSML does not use XML Encryption directly; it is encapsulated within the WSS protocol for encrypted messages. However, the open-source implementation of an SKMS (currently available from www.strongkey.org) uses XML Encryption to encrypt objects within its sample applications. It is recommended that conforming implementations use XML Encryption for maintaining confidentiality of SKMS objects.
   • Simple Object Access Protocol (SOAP) - SKSML does not use SOAP directly; it is encapsulated within the WSS protocol for the exchange of objects between clients and servers.

   Version 1.0 of SKSML does not currently use the following protocols, but it is anticipated that a future version of the protocol will leverage the following protocols:

   • OASIS' Security Assertion Markup Language (SAML)
   • OASIS' eXtensible Access Control Markup Language (XACML)
5. Can you give some example of concrete applications that will benefit from standardizing the specifications from this TC?

   Retail

   A Point-of-Sale (POS) application that accepts credit cards for purchase transactions may choose to encrypt the Credit Card Number (CCN) — also known as the Personal Account Number (PAN) — before storing it in the database. While the application can generate its own symmetric encryption key and perform the cryptographic operation and all key-management functions, the POS vendor may recognize that cryptography is not within its core business capabilities. They may choose to delegate cryptographic and key-management operations to a service on the network, just as they delegate all Input/Output (I/O) functions to a database, or all hostname-IP address name-resolution services to DNS, today. The POS application will use SKSML to request those services from an SKS server on the network.

   The merchant that operates the POS application has a need to share the encrypted CCN data with a fraud-detection application, or a business-analytics application in other divisions of the company. Instead of having the POS application decrypt and provide the raw CCN data to the fraud-detection/business-analytics application, the Security Officer permits these applications to access the decryption key(s) used by the POS application, to decrypt the ciphertext (encrypted data). The fraud-detection/business-analytics applications will use the SKSML protocol to request those keys from the SKS server(s).

   The same merchant operates a network of 4,000 POS terminals all across the country using a Wide Area Network (WAN) that may have insufficient redundancy. However, the merchant would like to ensure that the POS application always has sufficient number of symmetric encryption keys to continue business operations for fixed durations, even in the face of network failures that render the SKS server incommunicado. Using the SKSML protocol, the merchant can define key-caching policies that allow the POS application to maintain the defined number of encryption keys based on a centrally-defined policy. These keys are maintained securely on the local device, but are accessible even during network failures, ensuring business continuity.

   Healthcare

   An Emergency Medical Responder (EMR) collects sensitive medical data from patients when they respond to emergencies. The sensitive medical data is stored on laptops which must be shared with doctors and nurses in the Emergency Room (ER) at hospitals. In the unfortunate event that an EMR vehicle itself meets with an accident enroute to the hospital, another EMR must be able to access all data securely from the first EMR vehicle's computers. The application(s) on the first EMR vehicle's computers will use SKSML to request key-management services from an SKMS, while the second EMR's applications, the doctors and nurses will use SKSML to request the encryption keys used by the first EMR vehicle to decrypt the medical data of patients picked up.

   Government

   A government agency that issues laptops and/or mobile devices to its employees may choose to encrypt sensitive data created by applications on the laptop. However, the agency needs to legitimately access the keys and ciphertext even if such laptops are lost/stolen. Using the SKSML protocol, applications on the laptop/mobile device can request key-management services from an SKMS. Once the data is encrypted, it can be backed up to central servers. All keys issued to authorized requesters are automatically escrowed before being issued, thereby ensuring that the government agency can recover the key and plaintext data when it needs to.

   As part of protecting the nations critical infrastructure, a government agency may need to know sensitive information about commercial infrastructure and its capabilities. While it is possible to share this information securely today with first-responders, through pre-shared cryptographic keys, this does not scale well to tens of thousands of requesters. While the issuance/management of asymmetric keys is easily performed using a Public Key Infrastructure (PKI), sharing of symmetric encryption keys without a formal SKMS is not scalable. The SKSML protocol makes it possible to centrally manage the issuance and access of symmetric encryption keys, and to scale to millions of clients.

6. Is it anticipated that TC deliverables will be broadly used, deployed, and/or implemented? Or are the deliverables intended for a narrow audience, possibly including only the TC membership?

   It is anticipated that deliverables from the EKMI TC will be used by every company and industry that needs to manage sensitive information through encryption. Much like DNS, Dynamic Host Configuration Protocol (DHCP) or a Relational Database Management System (RDBMS), a Symmetric Key Management System (SKMS) and the SKSML can be used by any application on any operating system.

7. Do you see external factors that should help a broad acceptance and deployment of the specifications from this TC? And factors that may potentially hinder a broad acceptance and deployment?

   Government and industry regulations, such as California's Breach Disclosure law (SB-1386), and the Payment Card Industry's Data Security Standard (PCI-DSS) are driving companies towards paying more attention towards protecting sensitive data.

   The availability of an open-source implementation of the proposed SKSML protocol (www.strongkey.org) is allowing potential implementers and deployers in reviewing the protocol and its capabilities, thus allowing them to test-drive an implementation of the protocol, rather than deal with just theory.

8. Do you know of companies or industry verticals that have already expressed interest in using the specification(s) produced by the TC in their products or services?

   All retail merchants subject to PCI-DSS compliance need to encrypt CCN (PAN) on their systems. All large merchants are in the process of implementing various key-management solutions, and are looking for standards. The creators of the open-source implementation are being contacted by at least 2-3 retail merchants per month on the use of the software for enterprise-wide symmetric key-management.

9. Regarding the adoption of this specification(s) by a vendor for its products: is this a decision that vendor companies can make individually, or are the interoperability aspects important enough to require industry-wide, coordinated adoption?

   The SKSML protocol is an extremely simple one — just two request formats and three response formats are currently defined - and relies on many existing standards which have already undergone interoperability tests. While vendors can choose to implement the client and/or server side of the protocol independently, for the kind of ubiquity that DNS, DHCP and RDBMS' provide today, interoperability tests are necessary between implementations.

10. Have the authors and their companies considered further ways to promote the produced specification(s) after completion (PR, marketing, campaigns, industry consortia....)

    Yes. Even as the standards work progresses, the TC has already begun the PR and marketing work. The TC is creating white-papers, implementation and operations guidelines, audit guidelines; it is planning web-seminars, workshops and presentations at various security-related conferences.

11. What are the security implications, if any, of this effort?

    They are significant. The SKSML is the first XML-based network protocol to take on large-scale symmetric key-management. The payload within the response provides requesters with the key(s) to extremely sensitive data. Having those keys fall into unauthorized hands can potentially cost companies millions of dollars in liabilities.

    Consequently, the TC is taking great pains to adopt state-of-the-art security techniques and standards in crafting the protocol, the implementation, operations and audit guidelines. The TC anticipates that Enterprise Key Management Infrastructures will become as essential to companies in securing data, as Domain Name Service is to IP address resolution. EKMI's must not only address today's vulnerabilities, but must anticipate tomorrow's attacks so that companies investing in this architecture and technology are not stranded.