Symmetric Key Services Markup Language (SKSML) Version 1.0

Public Review Draft 03

5 August 2010

Specification URIs:

This Version:

http://docs.oasis-open.org/ekmi/sksml/v1.0/pr03/SKSML-1.0-Specification.html

http://docs.oasis-open.org/ekmi/sksml/v1.0/pr03/SKSML-1.0-Specification.odt(Authoritative)

http://docs.oasis-open.org/ekmi/sksml/v1.0/pr03/SKSML-1.0-Specification.pdf

Previous Version:

http://docs.oasis-open.org/ekmi/sksml/v1.0/cs01/SKSML-1.0-Specification.html

http://docs.oasis-open.org/ekmi/sksml/v1.0/cs01/SKSML-1.0-Specification.odt (Authoritative)

http://docs.oasis-open.org/ekmi/sksml/v1.0/cs01/SKSML-1.0-Specification.pdf

Latest Version:

http://docs.oasis-open.org/ekmi/sksml/v1.0/SKSML-1.0-Specification.html

http://docs.oasis-open.org/ekmi/sksml/v1.0/SKSML-1.0-Specification.odt

http://docs.oasis-open.org/ekmi/sksml/v1.0/SKSML-1.0-Specification.pdf

Technical Committee:

OASIS Enterprise Key Management Infrastructure (EKMI) TC

Chair(s):

Anil Saldhana, Red Hat Inc (anil.saldhana@redhat.com)

Timothy Bruce, CA Inc (Timothy.Bruce@ca.com)

Editor(s):

Allen Schaaf (netsecurity@sound-by-design.com)

Anil Saldhana, Red Hat, Inc. (anil.saldhana@redhat.com)

Tomas Gustavsson, PrimeKey Solutions AB (tomas@primekey.se)

Related Work:

This specification replaces or supercedes:

• None

This specification is related to:

• Advanced Encryption Standard (AES) - NIST FIPS 197 - http://csrc.nist.gov/publications/fips/fips197/fips-197.pdf

• Simple Object Access Protocol (SOAP) - W3C Recommendation 08 May 2000. http://www.w3.org/TR/soap/

• XML Encryption - W3C Recommendation 10 Dec 2002. http://www.w3.org/TR/xmlenc-core/

• XML Signature - W3C Recommendation 10 Jun 2008. http://www.w3.org/TR/xmldsig-core/

• Web Services Security - SOAP Message Security 1.0 - OASIS Standard 200401, March 2004 - http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0.pdf

Declared XML Namespace(s):

http://docs.oasis-open.org/ekmi/2008/01

Abstract:

This normative specification defines the first (1.0) version of the Symmetric Key Services Markup Language (SKSML), an XML-based messaging protocol, by which applications executing on computing devices may request and receive symmetric key-management services from centralized key-management servers, securely, over networks. Applications using SKSML are expected to either implement the SKSML protocol, or use a software library – called the Symmetric Key Client Library (SKCL) – that implements this protocol. SKSML messages are transported securely over standard HTTP using XML Security (XML Signature and XML Encryption).

Status:

This document was last revised by the EKMI TC as of the above date. The level of approval is also listed above. Check the "Latest Version" or "Latest Approved Version" location noted above for possible later revisions of this document.

Technical Committee members should send comments on this specification to the Technical Committee’s email list. Others should send comments to the Technical Committee by using the “Send A Comment” button on the Technical Committee’s web page at http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=ekmi

For information on whether any patents have been disclosed that may be essential to implementing this specification, and any offers of patent licensing terms, please refer to the Intellectual Property Rights section of the Technical Committee web page (http://www.oasis-open.org/committees/ekmi/ipr.php).



Notices

Copyright © OASIS® 2010. All Rights Reserved.

All capitalized terms in the following text have the meanings assigned to them in the OASIS Intellectual Property Rights Policy (the "OASIS IPR Policy"). The full Policy may be found at the OASIS website.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published, and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this section are included on all such copies and derivative works. However, this document itself may not be modified in any way, including by removing the copyright notice or references to OASIS, except as needed for the purpose of developing any document or deliverable produced by an OASIS Technical Committee (in which case the rules applicable to copyrights, as set forth in the OASIS IPR Policy, must be followed) or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by OASIS or its successors or assigns.

This document and the information contained herein is provided on an "AS IS" basis and OASIS DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY OWNERSHIP RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

OASIS requests that any OASIS Party or any other party that believes it has patent claims that would necessarily be infringed by implementations of this OASIS Committee Specification or OASIS Standard, to notify OASIS TC Administrator and provide an indication of its willingness to grant patent licenses to such patent claims in a manner consistent with the IPR Mode of the OASIS Technical Committee that produced this specification.

OASIS invites any party to contact the OASIS TC Administrator if it is aware of a claim of ownership of any patent claims that would necessarily be infringed by implementations of this specification by a patent holder that is not willing to provide a license to such patent claims in a manner consistent with the IPR Mode of the OASIS Technical Committee that produced this specification. OASIS may include such claims on its website, but disclaims any obligation to do so.

OASIS takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on OASIS' procedures with respect to rights in any document or deliverable produced by an OASIS Technical Committee can be found on the OASIS website. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this OASIS Committee Specification or OASIS Standard, can be obtained from the OASIS TC Administrator. OASIS makes no representation that any information or list of intellectual property rights will at any time be complete, or that any claims in such list are, in fact, Essential Claims.

The names "OASIS" and “SKSML” are trademarks of OASIS, the owner and developer of this specification, and should be used only to refer to the organization and its official outputs. OASIS welcomes reference to, and implementation and use of, specifications, while reserving the right to enforce its marks against misleading uses. Please see http://www.oasis-open.org/who/trademark.php for above guidance.

Table of Contents

1 Introduction

This document presents the specification for the Symmetric Key Services Markup Language (SKSML), a protocol by which applications may request and receive symmetric key-management services, securely, over networks or other mechanisms as may be selected by implementers. All text is normative unless otherwise indicated.

1.1 Terminology

The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this specification are to be interpreted as described in IETF RFC 2119.

1.2 Glossary

3DES – Triple Data Encryption Standard

AES – Advanced Encryption Standard

Base64 – An encoding scheme for representing data

Ciphertext – Encrypted data

Cryptographic module – A software library or hardware module dedicated to performing cryptographic operations

DES – Data Encryption Standard

DID or Domain ID – Domain Identifier; the unique PEN assigned to an implementation of an SKMS (Symmetric Key Management System) within an enterprise

GKID or Global Key ID – Global Key Identifier; the unique identifier assigned to every symmetric encryption key within an SKMS. It is the concatenation of the DID-SID-KID

Initialization Vector or IV – A block of bits required to encrypt/decrypt the first block of data when used with a particular mode of cryptographic operations

KeyCachePolicy – The collection of rules that defines how a symmetric encryption key may be cached by a client implementation

KID or Key ID – Key Identifier; the unique integer assigned to every symmetric encryption key generated within a specific SKS (Symmetric Key Services) server within an SKMS (Symmetric Key Management System)

KeyUsePolicy – The collection of rules that defines how a symmetric encryption key may be used by an application

PEN – Private Enterprise Number; the unique integer assigned by IANA to any organization that requests such a number

PII – Personally Identifiable Information, such as credit card numbers, social security numbers, bank account numbers, drivers license numbers, etc.

Plaintext – Unencrypted data

SHA – Secure Hashing Algorithm

SHA-1 – Secure Hashing Algorithm with a resultant size of 160-bits

SHA-256 – Secure Hashing Algorithm with a resultant size of 256-bits

SHA-384 – Secure Hashing Algorithm with a resultant size of 384-bits

SHA-512 – Secure Hashing Algorithm with a resultant size of 512-bits

SID or Server ID – Server Identifier; the unique integer assigned to every SKS server within an enterprise's SKMS

SKCL – Symmetric Key Client Library; a software library that supports the SKSML protocol

SKMS – Symmetric Key Management System; a collection of hardware and software providing symmetric encryption key-management services

SKS – Symmetric Key Services; a server that provides symmetric key management services over a network or other mechanism selected by implementers

SKSML – Symmetric Key Services Markup Language; an XML-based protocol to request and receive symmetric encryption key-management services

SOAP – Simple Object Access Protocol

SOAP Body – The content part of a SOAP message

SOAP Envelope – The SOAP message consisting of a SOAP Header and a SOAP Body, conforming to the SOAP protocol standard.

SOAP Error – A SOAP error message response to a SOAP request

SOAP Header – The header part of a SOAP message containing meta-information about the message, including security-related objects

Symkey - A symmetric encryption key

unbounded – A parameter used with the “maxOccurs” attribute to indicate an unlimited number

X509 Digital Certificate – a digital certificate that conforms to the Internet Engineering Task Force's PKI X509 standard

XMLEncryption – Encrypted content represented in eXtensible Markup Language that conforms to the World Wide Web Consortium's XML Encryption standard

XMLSignature – A digital signature represented in eXtensible Markup Language that conforms to the World Wide Web Consortium's XML Signature standard

1.3 Normative References

[AES] Advanced Encryption Standard.NIST FIPS 197. http://csrc.nist.gov/publications/fips/fips197/fips-197.pdf

[RFC 2119] S. Bradner. Key words for use in RFCs to Indicate Requirement Levels. IETF RFC 2119, March 1997.

[SOAP] SOAP v1.2 Specification. W3C Recommendation. 27 April 2007. http://www.w3.org/TR/soap12

[XMLEncryption] XML Encryption Syntax and Processing. W3C Recommendation. 10 Dec 2002.

http://www.w3.org/TR/xmlenc-core/

[XMLSignature] XML Signature Syntax and Processing. W3C Recommendation. 10 June 2008.

http://www.w3.org/TR/xmldsig-core/

[WSS] OASIS Standard, “Web Services Security – SOAP Message Security 1.0”, March 2004. http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0.pdf

[RFC 2578] K. McCloghrie, et al. Structure of Management Information Version 2 (SMIv2).IETF RFC 2578, April 1999. http://www.rfc-editor.org/rfc/rfc2578.txt

2 Background (non-normative)

A confluence of events is causing many companies to consider encrypting sensitive data across many applications and platforms within their IT infrastructure. Some of these events include:

• “Breach Disclosure” laws in nearly 40 states of the USA, requiring companies that have suffered breaches on computers containing Personally Identifiable Information (PII) of their employees or customers, to disclose those breaches to the affected individuals

• Industry-specific regulations such as the credit card industry's Payment Card Industry Data Security Standard, requiring the encryption of credit card numbers accompanied with strong key-management controls

• National laws such as the US' Health Insurance Portability and Accountability Act (HIPAA) and the European Union Directive, requiring the securing of health-related data and PII, respectively

• A significant increase in the number of business applications and e-commerce services on the internet requiring credit card numbers for payment, which in turn becomes a target for attackers

• A significant increase in the number of users connected to the internet with inadequate protection, leading to many attack vectors becoming propagated on these unprotected PC's

In a rush to provide solutions to the market, vendors have created many device-specific, platform-specific, database-specific and application-specific encryption and key-management tools. While these tools may be capable of performing their stated tasks adequately, a typical enterprise would have to deal with many encryption and key-management solutions to adequately protect sensitive data. The following illustration shows how the same key-management tasks need to repeated across every single device, platform, database and/or application where encryption is performed:

Not only does this raise the cost of ownership for implementing companies, but it raises the possibility that with many dissimilar key-management systems, because of the typical complexity of key-management schemes, there is a greater likelihood of human error leading to a vulnerability.

To ensure that encryption policies and designs are specified and used uniformly across applications, a common key-management service capable of supporting enterprise platforms, applications and devices is needed. To enable such applications to communicate with this service, a uniform protocol is needed. The Symmetric Key Services Markup Language (SKSML) is that protocol.

Once an enterprise has implemented an SKMS, and applications have been modified to take advantage of SKSML, they can expect to see their key-management infrastructure to resemble the following diagram:

Architected much like the Domain Name Service (DNS), an SKMS becomes the focal point for all symmetric encryption key-management services.

The Symmetric Key Client Library (SKCL) on client devices is responsible for communicating with the Symmetric Key Services (SKS) server using SKSML. The SKCL handles security, caching, cryptographic operations and ensuring that the use of the key is in conformance to policies specified for the key.

The SKS server is responsible for storing all policies, keys and information about authorized clients and servers within the SKMS, and responds to client requests.

2.1 Requirements (non-normative)

The requirements of the SKSML protocol are that:

• It must be platform independent;

• It must support the request of new and previously escrowed symmetric encryption keys;

• It must support the unique identification of every symmetric encryption key on the internet;

• It must provide message authenticity, confidentiality and integrity even when used over insecure networks;

• It must support the use of encryption/decryption services by a client even when disconnected from the network;

• It must provide flexibility in defining key-usage policies;

SKSML meets the above requirements in the following manner:

• SKSML uses XML for encapsulating its requests and responses and can thus, be used on any platform that supports XML;

• Using a scheme that concatenates unique Domain identifiers (Private Enterprise Numbers issued by the IANA), unique SKS Server identifiers within a domain and unique Key identifiers within an SKS server, SKSML creates Global Key Identifiers (GKID) that can uniquely identify symmetric keys across the internet;

• SKSML relies on XML Signature and XML Encryption. Relying on RSA cryptographic key-pairs and digital certificates, SKSML uses the digital signatures for authenticity and message-integrity, while using RSA-encryption for confidentiality;

• Using secure key-caching enabled through centrally-defined policies, SKSML supports the request and receipt of KeyCachePolicy elements by clients for the use of symmetric encryption keys even when the client is disconnected from the network and an SKS server;

• SKSML provides significant flexibility for defining policies on how symmetric encryption keys may be used by client applications. The KeyUsePolicy element allows Security Officers to define which applications may use a specific key, days and times of use, location of use, purpose of use, key-sizes, encryption algorithms, etc.

SKSML is the first key-management protocol that will do for encryption key-management services what DNS did for name-service protocols: provide a single, standard means of requesting and receiving key-management services from centrally defined servers.

3 Examples of use of SKSML (non-normative)

The following high-level diagram will be used to describe the use of SKSML.

3.1 Request for a new symmetric key

When a client application (that has been linked to the SKCL) needs to encrypt sensitive data, it will call an API method within the SKCL for a new symmetric key. After the SKCL has ensured that the application is authorized to make such a request (by verifying that the configured/passed-in credentials can access the cryptographic key-store module on the client containing the PrivateKey used for signing SKSML requests), the SKCL assembles the following SKSML request:

[a01] is the start of the SymkeyRequest element.

[a02] identifies the namespace to which this XML conforms, and the location of its XML Schema Definition (XSD).

[a03] identifies the GlobalKeyID (GKID) being requested by the client application. The GKID is a concatenation of three distinct identifiers in the following order: the unique Domain Identifier, the unique Server Identifier within the domain and the unique Key Identifier generated on a server. Using a “zero” value for the Server ID and the Key ID indicates a request for a new symmetric key.

[a04] is the closing tag of the SymkeyRequest element.

3.2 Response with a new symmetric key

After an SKS server has performed its operations of authenticating the request, identifying the requester, determining policies that apply to the requester, generating the symmetric encryption key in conformance to the defined policy and finally escrowing a symmetric key securely, it assembles the following response and returns it to the client.

[b01] <ekmi:SymkeyResponse
[b02] xmlns:ekmi='http://docs.oasis-open.org/ekmi/2008/01'
[b03] xmlns:xenc='http://www.w3.org/2001/04/xmlenc#'>
[b04] <ekmi:Symkey>
[b05] <ekmi:SymkeyRequestID>10514-1-7476</ekmi:SymkeyRequestID>
[b06] <ekmi:GlobalKeyID>10514-1-235</ekmi:GlobalKeyID>
[b07] <ekmi:KeyUsePolicy>
[b08] <ekmi:KeyUsePolicyID>10514-4</ekmi:KeyUsePolicyID>
[b09] <ekmi:PolicyName>DES-EDE KeyUsePolicy</ekmi:PolicyName>
[b10] <ekmi:KeyClass>HR-Class</ekmi:KeyClass>
[b11] <ekmi:KeyAlgorithm>
[b12] http://www.w3.org/2001/04/xmlenc#tripledes-cbc
[b13] </ekmi:KeyAlgorithm>
[b14] <ekmi:KeySize>192</ekmi:KeySize>
[b15] <ekmi:Status>Active</ekmi:Status>
[b16] <ekmi:Permissions>
[b17] <ekmi:PermittedApplications ekmi:any=”false”>
[b18] <ekmi:PermittedApplication>
[b19] <ekmi:ApplicationID>10514-23</ekmi:ApplicationID>
[b20] <ekmi:ApplicationName>
[b21] Payroll Application
[b22] </ekmi:ApplicationName>
[b23] <ekmi:ApplicationVersion>1.0</ekmi:ApplicationVersion>
[b24] <ekmi:ApplicationDigestAlgorithm>
[b25] http://www.w3.org/2000/09/xmldsig#sha1
[b26] </ekmi:ApplicationDigestAlgorithm>
[b27] <ekmi:ApplicationDigestValue>
[b28] NIG4bKkt4cziEqFFuOoBTM81efU=
[b29] </ekmi:ApplicationDigestValue>
[b30] </ekmi:PermittedApplication>
[b31] </ekmi:PermittedApplications>
[b32] <ekmi:PermittedDates ekmi:any=”false”>
[b33] <ekmi:PermittedDate>
[b34] <ekmi:StartDate>2008-01-01</ekmi:StartDate>
[b35] <ekmi:EndDate>2008-12-31</ekmi:EndDate>
[b36] </ekmi:PermittedDate>
[b37] </ekmi:PermittedDates>
[b38] <ekmi:PermittedDays ekmi:any=”true” xsi:nil=”true”/>
[b39] <ekmi:PermittedDuration ekmi:any=”true” xsi:nil=”true”/>
[b40] <ekmi:PermittedLevels ekmi:any=”true” xsi:nil=”true”/>
[b41] <ekmi:PermittedLocations ekmi:any=”true” xsi:nil=”true”/>
[b42] <ekmi:PermittedNumberOfTransactions ekmi:any=”true” xsi:nil=”true”/>
[b43] <ekmi:PermittedTimes ekmi:any=”false”>
[b44] <ekmi:PermittedTime>
[b45] <ekmi:StartTime>07:00:00</ekmi:StartTime>
[b46] <ekmi:EndTime>19:00:00</ekmi:EndTime>
[b47] </ekmi:PermittedTime>
[b48] </ekmi:PermittedTimes>
[b49] <ekmi:PermittedUses ekmi:any=”true” xsi:nil=”true”/>
[b50] </ekmi:Permissions>
[b51] </ekmi:KeyUsePolicy>
[b52] <ekmi:EncryptionMethod
[b53] Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-1_5"/>
[b54] <xenc:CipherData>
[b55] <xenc:CipherValue>
[b56] E9zWB/y93hVSzeTLiDcQoDxmlNxTuxSffMNwCJmt1dIqzQHBnpdQ81g6DKdkCFjJM
[b57] hQhywCx9sfYjv9h5FDqUiQXGOca8EU871zBoXBjDxjfg1pU8tGFbpWZcd/ATpJD/2fw
[b58] UJow/qimxi8+huUYJMtaGHtXuLlWtx27STRcRpIsY=
[b59] </xenc:CipherValue>
[b60] </xenc:CipherData>
[b61] </ekmi:Symkey>
[b62] </ekmi:SymkeyResponse>

[b01] is the start of the SymkeyResponse element.

[b02] and [b03] identify the namespaces to which this XML conforms, and the location of their XML Schema Definitions (XSD).

[b04] is the start tag of the Symkey element which contains the symmetric encryption key and related elements.

[b05] identifies the SymkeyRequestID assigned by the SKS server for this request. In this example, the concatenated values of the Domain ID, Server ID and Request ID indicate that the key belongs to the organization represented by the PEN, 10514; it was generated on an SKS server with a Server ID of 1 and is the 7,476^th unique request received on that SKS server. The client and the server use this value to associate asynchronous requests and responses for symmetric keys between themselves; however, the value is also returned for synchronous request/responses too.

[b06] identifies the GlobalKeyID (GKID) assigned by the SKS server for the new symmetric key being returned. In this example, the concatenated values of the Domain ID, Server ID and Key ID indicate that the key belongs to the organization represented by the PEN, 10514; it was generated on an SKS server with a Server ID of 1 and is the 235^th unique key generated on that SKS server.

[b07] is the start of the KeyUsePolicy element. This element contains details of the policy to which SKCL implementations must conform when using the symmetric key.

[b08] identifies the unique KeyUsePolicyID (KUPID) which identifies this policy within the SKMS.

[b09] provides a descriptive name for this key-use policy, which is helpful to human readers when identifying this policy.

[b10] identifies the KeyClass to which this symmetric key belongs. Key-classes are useful to applications that wish to encrypt plaintext with a key that has specific characteristics. The requesting application is expected to know what KeyClass it needs before it asks for a key corresponding to that class.

[b11] is the start tag of the KeyAlgorithm element.

[b12] identifies the cryptographic algorithm that this symmetric key must be used with to for cryptographic operations.

[b13] is the closing tag of the KeyAlgorithm element.

[b14] specifies the size of the symmetric encryption key in bits. While it is possible for application developers to determine this programmatically from the key-object, this element provides this information as a convenience.

[b15] indicates the Status of this KeyUsePolicy and whether it is an active policy or not. This is useful in situations where an application may wish to re-use a symmetric key to encrypt related data to the data originally encrypted with the symmetric key. While it is possible for the symmetric key object to be active in the database, it is conceivable that the KeyUsePolicy used by the key has changed and the application technically needs to use a new symmetric key to encrypt new data.

[b16] is the start of the Permissions element. This element provides a sophisticated mechanism for controlling how, where, when and by which applications symmetric keys be used. While there are many sub-elements within a Permissions element, not all KeyUsePolicy objects might use all Permissions sub-elements. The example shown in this section only uses three of the possible Permissions sub-elements.

[b17] is the start of the PermittedApplications element. This element allows SKMS policies to be defined that allow only specific applications to use symmetric encryption keys associated with this policy. The ekmi:any=”true” attribute of the PermittedApplications element indicates that not just any application on the client machine is permitted to use this symmetric key; only the specified applications within the sub-elements of this element are permitted to use the symmetric key in question..

[b18] is the start of the first PermittedApplication element. This element identifies a specific application within a list of PermittedApplications that is allowed to use the symmetric key. There can be any number of PermittedApplication elements with PermittedApplications.

[b19] identifies the unique ApplicationID (as identified within the SKMS) of the PermittedApplication.

[b20] is the start of the ApplicationName element.

[b21] identifies the ApplicationName of the PermittedApplication (as identified within the SKMS).

[b22] is the closing tag of the ApplicationName element.

[b23] identifies the specific ApplicationVersion of the PermittedApplication. This is helpful when there are multiple versions of a specific application, and the policy-makers need to distinguish between the symmetric keys in use by a specific version of the application.

[b24] is the start of the ApplicationDigestAlgorithm element. This element permits enterprises to ensure that only a cryptographically-verified application is authorized to use the symmetric encryption key. This assumes that the implementation has an infrastructure where the SKCL is capable of determining a cryptographic value to uniquely identify an application within the run-time environment.

[b25] identifies the W3C-specified URL of the cryptographic algorithm used to calculate the message digest of the application's image.

[b26] is the closing tag of the ApplicationDigestAlgorithm element.

[b27] is the start of the ApplicationDigestValue element. This element permits enterprises to ensure that only a cryptographically-verified application is authorized to use the symmetric encryption key. This assumes that the implementation has an infrastructure where the SKCL is capable of determining a cryptographic value to uniquely identify an application within the run-time environment.

[b28] identifies the Base64-encoded message digest of the PermittedApplication's image, based on the algorithm specified in the ApplicationDigestAlgorithm element.

[b29] is the closing tag of the ApplicationDigestValue element.

[b30] is the closing tag of the PermittedApplication element.

[b31] is the closing tag of the PermittedApplications element.

[b32] is the start of the PermittedDates element. This element permits enterprises to ensure that the symmetric encryption key can be used only during a specified date period. This assumes that the implementation has an infrastructure where the SKCL is capable of accurately determining the current date within the run-time environment.

[b33] is the start of the first PermittedDate element. There can be any number of PermittedDate elements within a PermittedDates element.

[b34] identifies the StartDate of the duration period during which the symmetric encryption key can be used by authorized applications.

[b35] identifies the EndDate of the duration period during which the symmetric encryption key can be used by authorized applications.

[b36] is the closing tag of the PermittedDate element.

[b37] is the closing tag of the PermittedDates element.

[b38] is an empty (null) PermittedDays element. This element permits enterprises to ensure that the symmetric encryption key can be used only on specific days of the week. This assumes that the implementation has an infrastructure where the SKCL is capable of accurately determining the current day-of-week within the run-time environment. In this specific instance, the null element indicates that this permission does not apply to this symmetric key, and therefore, there are no constraints on its use. However, the key is still subject to all non-null permission clauses.

[b39] is an empty (null) PermittedDuration element. This element permits enterprises to ensure that the symmetric encryption key can be used only for a specific duration of time once the symmetric key has been used for the first time on the client. This assumes that the implementation has an infrastructure where the SKCL is capable of accurately determining the current time within the run-time environment. In this specific instance, the null element indicates that this permission does not apply to this symmetric key, and therefore, there are no constraints on its use. However, the key is still subject to all non-null permission clauses.

[b40] is an empty (null) PermittedLevels element. This element permits enterprises to ensure that the symmetric encryption key can be used only by applications that are classified at a given level within the Multi-Level Security (MLS) system as defined in the Bell-LaPadula model. In this specific instance, the null element indicates that this permission does not apply to this symmetric key, and therefore, there are no constraints on its use. However, the key is still subject to all non-null permission clauses.

[b41] is an empty (null) PermittedLocations element. This element permits enterprises to ensure that the symmetric encryption key can be used only by applications at specified geographic locations on the planet. This assumes that the implementation has an infrastructure where the SKCL is capable of accurately determining the current GPS location of the client within the run-time environment. In this specific instance, the null element indicates that this permission does not apply to this symmetric key, and therefore, there are no constraints on its use. However, the key is still subject to all non-null permission clauses.

[b42] is an empty (null) PermittedNumberOfTransactions element. This element permits enterprises to ensure that the symmetric encryption key can be used by applications only for a specified number of encryption transactions. In this specific instance, the null element indicates that this permission does not apply to this symmetric key, and therefore, there are no constraints on its use. However, the key is still subject to all non-null permission clauses.

[b43] is the start of the PermittedTimes element. This element permits enterprises to ensure that the symmetric encryption key can be used only during a specified time period within any date. This assumes that the implementation has an infrastructure where the SKCL is capable of accurately determining the current time within the run-time environment.

[b44] is the start of the first PermittedTime element. There can be any number of PermittedTime elements within a PermittedTimes element.

[b45] identifies the StartTime of the duration period during which the symmetric encryption key can be used by authorized applications.

[b46] identifies the EndTime of the duration period during which the symmetric encryption key can be used by authorized applications.

[b47] is the closing tag of the PermittedTime element.

[b48] is the closing tag of the PermittedTimes element.

[b49] is an empty (null) PermittedUses element. This element permits enterprises to ensure that the symmetric encryption key can be used by applications for specific uses. In this specific instance, the null element indicates that this permission does not apply to this symmetric key, and therefore, there are no constraints on its use. However, the key is still subject to all non-null permission clauses.

[b50] is the closing tag of the Permissions element.

[b51] is the closing tag of the KeyUsePolicy element.

[b52]-[b53] identifies the encryption algorithm used in the EncryptionMethod element to encrypt the symmetric encryption key itself, to transport to the requesting client. The symmetric key is encrypted using the PublicKey or the requesting client. The Algorithm attribute uses the W3C-specified URLs for identifying the encryption and padding algorithms.

[b54] is the start of the CipherData element. This element is from the W3C XML Encryption namespace (as identified by the “xenc” qualifier in the element name).

[b55] is the start of the CipherValue element. This element contains the Base64-encoded ciphertext of the symmetric encryption key.

[b56] – [b58] is the Base64-encoded ciphertext of the symmetric encryption key.

[b59] is the closing tag of the CipherValue element.

[b60] is the closing tag of the CipherData element.

[b61] is the closing tag of the Symkey element.

[b62] is the closing tag of the SymkeyResponse element.

3.3 Request for an existing symmetric key

Typically, when a client application encrypts data, it must make accommodations to store the GlobalKeyID of the symmetric encryption key it uses to encrypt the plaintext, along with the ciphertext. Without the GlobalKeyID, neither the client application nor the SKS server can determine which key was used to encrypt specific ciphertext. When the client application needs to decrypt such ciphertext, it must request the symmetric key with the appropriate GlobalKeyID from the SKS server if it does not already have the key cached within its key-cache.

The client application (that has been linked to the SKCL) will call an API method within the SKCL for the appropriate symmetric key. After the SKCL has ensured that the application is authorized to make such a request, and assuming that the client application needs the key with the GlobalKeyID value of 10514-1-235, the SKCL assembles the following SKSML request.

[c01] <ekmi:SymkeyRequest
[c02] xmlns:ekmi=”http://docs.oasis-open.org/ekmi/2008/01">
[c03] <ekmi:GlobalKeyID>10514-1-235</ekmi:GlobalKeyID>
[c04] </ekmi:SymkeyRequest>

[c01] is the start of the SymkeyRequest element.

[c02] identifies the namespace to which this XML conforms, and the location of its XML Schema Definition (XSD).

[c03] identifies the GlobalKeyID (GKID) of the specific symmetric encryption key being requested by the client application.

[c04] is the closing tag of the SymkeyRequest element.

Note that the request for an existing symmetric key is no different from a request for a new symmetric key other than that the GlobalKeyID being requested has non-zero values for the Server ID and Key ID parts of the GlobalKeyID.

3.4 Response with an existing symmetric key

After an SKS server has performed its operations of authenticating the request, identifying the requester and determining whether the requester is authorized to receive the symmetric key, the SKS server sends back the symmetric key using a SymkeyResponse message secured using XML Security. This SymkeyResponse is identical to the message described in Section 3.2 (since the SymkeyRequest was for the same symmetric key identified there) and is therefore, not repeated here for brevity.

3.5 Request for a new symmetric key of a specific KeyClass

There are business situations where an application might need a symmetric key that conforms to a KeyUsePolicy that has a specific KeyClass attribute within the policy. This is useful in situations where there may be many encryption policies within a company that apply to different type of data, geographical zones, applications, level of access to sensitive data, etc., and the requesting application needs a symmetric key which satisfies its business rules.

In those situations, a client application (that has been linked to the SKCL) will call an API method within the SKCL for a new symmetric key of a specific KeyClass. After the SKCL has ensured that the application is authorized to make such a request the SKCL assembles the following SKSML request:

[e01] <ekmi:SymkeyRequest
[e02] xmlns:ekmi=”http://docs.oasis-open.org/ekmi/2008/01">
[e03] <ekmi:GlobalKeyID>10514-0-0</ekmi:GlobalKeyID>
[e04] <ekmi:KeyClasses>
[e05] <ekmi:KeyClass>HR-Class</ekmi:KeyClass>
[e06] </ekmi:KeyClasses>
[e07] </ekmi:SymkeyRequest>

[e01] is the start of the SymkeyRequest element.

[e02] identifies the namespace to which this XML conforms, and the location of its XML Schema Definition (XSD).

[e03] identifies the GlobalKeyID (GKID) being requested by the client application. The “zero” value for the Server ID and the Key ID indicates a request for a new symmetric key.

[e04] is the start of the KeyClasses element.

[e05] identifies the specific KeyClass being requested by the client application.

[e06] is the closing tag of the KeyClasses element.

[e07] is the closing tag of the SymkeyRequest element.

3.6 Response with a new symmetric key of a specific KeyClass

After an SKS server has performed its operations of authenticating the request, identifying the requester and determining whether the requester is authorized to receive a symmetric key of the requested KeyClass, the SKS server generates, escrows, encrypts and sends back the symmetric key using a SymkeyResponse message secured using XML Security. This SymkeyResponse is identical to the message described in Section 3.2 (since the symmetric key identified there is of the KeyClass requested here) and is therefore, not repeated here for brevity.

3.7 Request for multiple new symmetric keys

There are business situations where an application needs many symmetric keys to encrypt different parts of a single record. This is useful in applications where many entities might have access to the same “master” record, but only some entities have access to sensitive data within “detail” records. In these situations, the use of multiple symmetric keys addresses this business requirement, while allowing the entire record to freely move to any system without fear of loss of confidentiality.

For example, within an Electronic Health Record (EHR) application, the application might store a Patient's medical data as a single logical EHR within a database (even though they may be physically represented by many hundreds of detail records). This has the benefit of presenting a single view of a Patient's EHR to all actors within the use-case. However, the information necessary to a Physician treating the patient is quite different from the information necessary to an insurance company processing a claim, a government agency tracks diseases, a pharmacy filling out a prescription or a nurse administering treatment to the patient.

While there is a clear business advantage to maintaining all patient data as a single logical EHR, security and privacy requirements dictate that appropriate sensitive data must be made visible only to authorized entities.

In these situations, a client application (that has been linked to the SKCL) will call an API method within the SKCL for multiple new symmetric keys. In order to request multiple symmetric keys, the SKSML request must contain a KeyClass element within the KeyClasses element for every key the client application needs. Thus, if the EHR application were to request nine symmetric keys to encrypt different parts of the EHR, the client application would make the following SKSML SymkeyRequest:

[g01] <ekmi:SymkeyRequest
[g02] xmlns:ekmi=”http://docs.oasis-open.org/ekmi/2008/01">
[g03] <ekmi:GlobalKeyID>10514-0-0</ekmi:GlobalKeyID>
[g04] <ekmi:KeyClasses>
[g05] <ekmi:KeyClass>EHR-CDC</ekmi:KeyClass>
[g06] <ekmi:KeyClass>EHR-CRO</ekmi:KeyClass>
[g07] <ekmi:KeyClass>EHR-DEF</ekmi:KeyClass>
[g08] <ekmi:KeyClass>EHR-EMT</ekmi:KeyClass>
[g09] <ekmi:KeyClass>EHR-HOS</ekmi:KeyClass>
[g10] <ekmi:KeyClass>EHR-INS</ekmi:KeyClass>
[g11] <ekmi:KeyClass>EHR-NUR</ekmi:KeyClass>
[g12] <ekmi:KeyClass>EHR-PAT</ekmi:KeyClass>
[g13] <ekmi:KeyClass>EHR-PHY</ekmi:KeyClass>
[g14] </ekmi:KeyClasses>
[g15] </ekmi:SymkeyRequest>

[g01] is the start of the SymkeyRequest element.

[g02] identifies the namespace to which this XML conforms, and the location of its XML Schema Definition (XSD).

[g03] identifies the GlobalKeyID (GKID) being requested by the client application. The “zero” value for the Server ID and the Key ID indicates a request for a new symmetric key.

[g04] is the start of the KeyClasses element.

[g05] identifies a KeyClass for a symmetric encryption key being requested by the client application, ostensibly for encrypting data that can later be decrypted by an authorized application at the Center for Disease Control (CDC) and any other application that has been granted access to keys of the EHR-CDC KeyClass.

[g06] identifies a KeyClass for a symmetric encryption key being requested by the client application, for encrypting data that can later be decrypted only by an authorized application at Clinical Research Organizations (CRO) and any other application that has been granted access to keys of the EHR-CRO KeyClass.

[g07] identifies a default KeyClass (EHR-DEF) for a symmetric encryption key for encrypting data that can later be decrypted by any authorized application within the EHR system.

[g08] identifies a KeyClass for a symmetric encryption key for encrypting data that was collected by an Emergency Medical Technician (EMT), and which can later be decrypted only by authorized applications at the hospital that have access to keys of the EHR-EMT KeyClass.

[g09] identifies a KeyClass for a symmetric encryption key for encrypting data collected by a hospital where the patient might have used for treatment. Data encrypted by keys of this EHR-HOS KeyClass can later be decrypted only by authorized application that has access to keys of this KeyClass.

[g10] identifies a KeyClass (EHR-INS) for a symmetric encryption key that might be used for encrypting data which will be submitted to an insurance company for claims processing.

[g11] identifies a KeyClass for a symmetric encryption key for encrypting data that can later be decrypted by any authorized application used by nurses and/or other authorized entities in providing treatment to a patient at the hospital (EHR-NUR).

[g12] identifies a KeyClass for a symmetric encryption key for encrypting patient related data (EHR-PAT) that may not be medical in nature, but nevertheless sensitive.

[g13] identifies a KeyClass for a symmetric encryption key for encrypting data that can later be decrypted by authorized physicians and other entities that have access to keys of the EHR-PHY KeyClass.

[g14] is the closing tag of the KeyClasses element.

[g15] is the closing tag of the SymkeyRequest element.

3.8 Response with multiple new symmetric keys

After an SKS server has performed its operations of authenticating the request, identifying the requester, determining policies that apply to the requester, generating the symmetric encryption keys in conformance to the defined policies and KeyClasses and finally escrowing the symmetric keys securely, it assembles the following response and returns it to the client.

To reduce the verbosity of the response that includes nine symmetric encryption keys, the SKSML shows only the details of two symmetric keys and the encapsulating element tags for the remaining seven keys. Regardless of what the KeyUsePolicy and/or Permissions elements state in those seven keys, the schema for each response conforms to the specification described in this document.

[h01] <ekmi:SymkeyResponse
[h02] xmlns:ekmi='http://docs.oasis-open.org/ekmi/2008/01'
[h03] xmlns:xenc='http://www.w3.org/2001/04/xmlenc#'>
[h04] <ekmi:Symkey>
[h05] <ekmi:SymkeyRequestID>10514-4-78122</ekmi:SymkeyRequestID>
[h06] <ekmi:GlobalKeyID>10514-4-3792</ekmi:GlobalKeyID>
[h07] <ekmi:KeyUsePolicy>
[h08] <ekmi:KeyUsePolicyID>10514-9</ekmi:KeyUsePolicyID>
[h09] <ekmi:PolicyName>DES-EDE KeyUsePolicy for EHR-CDC</ekmi:PolicyName>
[h10] <ekmi:KeyClass>EHR-CDC</ekmi:KeyClass>
[h11] <ekmi:KeyAlgorithm>
[h12] http://www.w3.org/2001/04/xmlenc#tripledes-cbc
[h13] </ekmi:KeyAlgorithm>
[h14] <ekmi:KeySize>192</ekmi:KeySize>
[h15] <ekmi:Status>Active</ekmi:Status>
[h16] <ekmi:Permissions>
[h17] <ekmi:PermittedApplications ekmi:any="true" xsi:nil="true"/>
[h18] <ekmi:PermittedDates ekmi:any="true" xsi:nil="true"/>
[h19] <ekmi:PermittedDays ekmi:any="true" xsi:nil="true"/>
[h20] <ekmi:PermittedDuration ekmi:any="true" xsi:nil="true"/>
[h21] <ekmi:PermittedLevels ekmi:any="true" xsi:nil="true"/>
[h22] <ekmi:PermittedLocations ekmi:any="true" xsi:nil="true"/>
[h23] <ekmi:PermittedNumberOfTransactions
[h24] ekmi:any="true" xsi:nil="true"/>
[h25] <ekmi:PermittedTimes ekmi:any="true" xsi:nil="true"/>
[h26] <ekmi:PermittedUses ekmi:any="true" xsi:nil="true"/>
[h27] </ekmi:Permissions>
[h28] </ekmi:KeyUsePolicy>
[h29] <ekmi:EncryptionMethod
[h30] Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-1_5"/>
[h31] <xenc:CipherData>
[h32] <xenc:CipherValue>
[h33] E9zWB/y93hVSzeTLiDcQoDxmlNxTuxSffMNwCJmt1dIqzQHBnpdQ81g6DKdkCFjJMa1w
[h34] hQhywCx9sfYjv9h5FDqUiQXGOca8EU871zBoXBjDxjfg1pU8tlWtx27STRcR/2fw2ava
[h35] UlWtx27STRcRJMtaGHtXuLlWtx27STRcRpIsY=
[h36] </xenc:CipherValue>
[h37] </xenc:CipherData>
[h38] </ekmi:Symkey>
[h39] <ekmi:Symkey>
[h40] <ekmi:SymkeyRequestID>10514-4-78122</ekmi:SymkeyRequestID>
[h41] <ekmi:GlobalKeyID>10514-4-3793</ekmi:GlobalKeyID>
[h42] <ekmi:KeyUsePolicy>
[h43] <ekmi:KeyUsePolicyID>10514-12</ekmi:KeyUsePolicyID>
[h44] <ekmi:PolicyName>DES-EDE KeyUsePolicy for EHR-CRO</ekmi:PolicyName>
[h45] <ekmi:KeyClass>EHR-CRO</ekmi:KeyClass>
[h46] <ekmi:KeyAlgorithm>
[h47] http://www.w3.org/2001/04/xmlenc#tripledes-cbc
[h48] </ekmi:KeyAlgorithm>
[h49] <ekmi:KeySize>192</ekmi:KeySize>
[h50] <ekmi:Status>Active</ekmi:Status>
[h51] <ekmi:Permissions>
[h52] <ekmi:PermittedApplications ekmi:any="true" xsi:nil="true"/>
[h53] <ekmi:PermittedDates ekmi:any="true" xsi:nil="true"/>
[h54] <ekmi:PermittedDate>
[h55] <ekmi:StartDate>2008-01-01</ekmi:StartDate>
[h56] <ekmi:EndDate>2009-12-31</ekmi:EndDate>
[h57] </ekmi:PermittedDate>
[h58] </ekmi:PermittedDates>
[h59] <ekmi:PermittedDays ekmi:any="true" xsi:nil="true"/>
[h60] <ekmi:PermittedDuration ekmi:any="true" xsi:nil="true"/>
[h61] <ekmi:PermittedLevels ekmi:any="true" xsi:nil="true"/>
[h62] <ekmi:PermittedLocations ekmi:any="true" xsi:nil="true"/>
[h63] <ekmi:PermittedNumberOfTransactions
[h64] ekmi:any="true" xsi:nil="true"/>
[h65] <ekmi:PermittedTimes ekmi:any="true" xsi:nil="true"/>
[h66] <ekmi:PermittedUses ekmi:any="true" xsi:nil="true"/>
[h67] </ekmi:Permissions>
[h68] </ekmi:KeyUsePolicy>
[h69] <ekmi:EncryptionMethod
[h70] Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-1_5"/>
[h71] <xenc:CipherData>
[h72] <xenc:CipherValue>
[h73] qUiQXGOca8EU871zBoXBjDoDxmlNxTuxSffMNwCJmt1dIqzQHBnpdQ81g6DKdkCFjJM1
[h74] hQhywCx9sfYjv9h5FDqUiQXGOca8EU871zBoXBjDxjfg1pU8tGFbpWZcd/ATpJD/2fw1
[h75] UJow/qimxi8+ huUYJMtaGHtXuLlWtx27STRcRpIsY=
[h76] </xenc:CipherValue>
[h77] </xenc:CipherData>
[h78] </ekmi:Symkey>
[h79] <ekmi:Symkey>
[h80] <ekmi:SymkeyRequestID>10514-4-78122</ekmi:SymkeyRequestID>
[h81] <ekmi:GlobalKeyID>10514-4-3795</ekmi:GlobalKeyID>
...
[h82] <ekmi:KeyClass>EHR-DEF</ekmi:KeyClass>
...
[h83] </ekmi:Symkey>
[h84] <ekmi:Symkey>
[h85] <ekmi:SymkeyRequestID>10514-4-78122</ekmi:SymkeyRequestID>
[h86] <ekmi:GlobalKeyID>10514-4-3797</ekmi:GlobalKeyID>
...
[h87] <ekmi:KeyClass>EHR-EMT</ekmi:KeyClass>
...
[h88] </ekmi:Symkey>
[h89] <ekmi:Symkey>
[h90] <ekmi:SymkeyRequestID>10514-4-78122</ekmi:SymkeyRequestID>
[h91] <ekmi:GlobalKeyID>10514-4-3798</ekmi:GlobalKeyID>
...
[h92] <ekmi:KeyClass>EHR-HOS</ekmi:KeyClass>
...
[h93] </ekmi:Symkey>
[h94] <ekmi:Symkey>
[h95] <ekmi:GlobalKeyID>10514-4-3799</ekmi:GlobalKeyID>
...
[h96] <ekmi:KeyClass>EHR-INS</ekmi:KeyClass>
...
[h97] </ekmi:Symkey>
[h98] <ekmi:Symkey>
[h99] <ekmi:SymkeyRequestID>10514-4-78122</ekmi:SymkeyRequestID>
[h100] <ekmi:GlobalKeyID>10514-4-3801</ekmi:GlobalKeyID>
...
[h101] <ekmi:KeyClass>EHR-NUR</ekmi:KeyClass>
...
[h102] </ekmi:Symkey>
[h103] <ekmi:Symkey>
[h104] <ekmi:SymkeyRequestID>10514-4-78122</ekmi:SymkeyRequestID>
[h105] <ekmi:GlobalKeyID>10514-4-3803</ekmi:GlobalKeyID>
...
[h106] <ekmi:KeyClass>EHR-PAT</ekmi:KeyClass>
...
[h107] </ekmi:Symkey>
[h108] <ekmi:Symkey>
[h109] <ekmi:SymkeyRequestID>10514-4-78122</ekmi:SymkeyRequestID>
[h110] <ekmi:GlobalKeyID>10514-4-3805</ekmi:GlobalKeyID>
...
[h111] <ekmi:KeyClass>EHR-PHY</ekmi:KeyClass>
...
[h112] </ekmi:Symkey>
[h113] </ekmi:SymkeyResponse>

[h01] is the start of the SymkeyResponse element.

[h02] and [h03] identify the namespaces to which this XML conforms, and the location of their XML Schema Definitions (XSD).

[h04] is the start tag of the first Symkey element which contains the symmetric encryption key and related elements.

[h05] identifies the SymkeyRequestID assigned by the SKS server for this request. In this example, the concatenated values of the Domain ID, Server ID and Request ID indicate that the key belongs to the organization represented by the PEN, 10514; it was generated on an SKS server with a Server ID of 4 and is the 78,122^nd unique request received on that SKS server. The client and the server use this value to associate asynchronous requests and responses for symmetric keys between themselves; however, the value is also returned for synchronous request/responses too.

[h06] identifies the GlobalKeyID (GKID) assigned by the SKS server of this first symmetric key. In this example, the concatenated values of the Domain ID, Server ID and Key ID indicate that the key belongs to the organization represented by the PEN, 10514; it was generated on an SKS server with a Server ID of 4 and is the 3792^nd unique key generated on that SKS server.

[h07] is the start of the KeyUsePolicy element that applies just to this symmetric key. This element contains details of the policy to which SKCL implementations must conform when using the symmetric key.

[h08] identifies the unique KeyUsePolicyID (KUPID) which identifies this policy within the SKMS.

[h09] provides a descriptive name for this key-use policy, which is helpful to human readers when identifying this policy.

[h10] identifies the KeyClass to which this symmetric key belongs. In the case of this example, the first symmetric key in the response conforms to the EHR-CDC class which, presumably, might be a key that covers data encrypted for/by the Center for Disease Control (CDC) within an Electronic Health Record (EHR) system. Key-classes are useful to applications that wish to encrypt plaintext with a key that has specific characteristics. The requesting application is expected to know what KeyClass it needs before it asks for a key corresponding to that class.

[h11] is the start tag of the KeyAlgorithm element.

[h12] identifies the cryptographic algorithm that this symmetric key must be used with. For this symmetric key example, the algorithm is the Triple Data Encryption Standard (3DES) with Cipher Block Chaining (CBC) padding. The URL is a standard notation for this algorithm and padding as defined within [XMLEncryption]..

[h13] is the closing tag of the KeyAlgorithm element.

[h14] specifies the size of the symmetric encryption key in bits. For this Triple-DES key, it is 192-bits.

[h15] indicates the Status of this KeyUsePolicy and whether it is an active policy or not. This is useful in situations where an application may wish to re-use a symmetric key to encrypt related data to the data originally encrypted with the symmetric key. While it is possible for the symmetric key object to be active in the database, it is conceivable that the KeyUsePolicy used by the key has changed and the application technically needs to use a new symmetric key to encrypt new data.

[h16] is the start of the Permissions element. This element provides a sophisticated mechanism for controlling how, where, when and by which applications symmetric keys be used. While there are many sub-elements within a Permissions element, not all KeyUsePolicy objects might use all Permissions sub-elements<ekmi:RequestedKeyClass>Payroll-Tax-Class</ekmi:RequestedKeyClass>. The example shown for this symmetric key indicates that there are no other specific restrictions on the use of this symmetric key by authorized client applications; i.e. any authorized client application may use it at any time, on any date, in any location for any purpose.

[h17] is the start and end of the null PermittedApplications element. This implies that there are no restrictions on which application can use this symmetric key.

[h18] is the start and end of the null PermittedDates element. This implies that there are no date restrictions on when this symmetric key can be used.

[h19] is the start and end of the null PermittedDays element. This implies that there are no day-of-week restrictions on when this symmetric key can be used.

[h20] is the start and end of the null PermittedDuration element. This implies that there are no restrictions to how long this symmetric key may be used.

[h21] is the start and end of the null PermittedLevels element. This implies that there are no restrictions on the MLS security level in which this symmetric key can be used.

[h22] is the start and end of the null PermittedLocations element. This implies that there are no geophysical restrictions where this symmetric key can be used.

[h23] - [h24] is the start and end of the null PermittedNumberOfTransactions element. This implies that there are no restrictions on how many encryption transactions that can be performed by this symmetric key.

[h25] is the start and end of the null PermittedTimes element. This implies that there are no time-of-day restrictions when this symmetric key can be used.

[h26] is the start and end of the null PermittedUses element. This implies that there are no restrictions how this symmetric key can be used by applications.

[h27] is the closing tag of the Permissions element.

[h28] is the closing tag of the KeyUsePolicy element.

[h29] and [h30] identify the encryption algorithm used in the EncryptionMethod element to encrypt the symmetric encryption key itself, to transport to the requesting client. The symmetric key is encrypted using the PublicKey or the requesting client. The Algorithm attribute uses the W3C-specified URLs for identifying the encryption and padding algorithms.

[h31] is the start of the CipherData element. This element is from the W3C XML Encryption namespace (as identified by the “xenc” qualifier in the element name).

[h32] is the start of the CipherValue element. This element contains the Base64-encoded ciphertext of the symmetric encryption key.

[h33] – [h35] is the Base64-encoded ciphertext of the symmetric encryption key.

[h36] is the closing tag of the CipherValue element.

[h37] is the closing tag of the CipherData element.

[h38] is the closing tag of the first Symkey element within this SymkeyResponse.

[h39] - [h78] represents the second Symkey element in this SymkeyResponse. The differences in this symmetric key element from the first, can be summarized as follows:

• [h41] identifies a different GlobalKeyID (10514-4-3793) for this symmetric key;

• [h43] identifies a different KeyUsePolicy (10514-12) for this symmetric key;

• [h45] identifies a different KeyClass (EHR-CRO) for this symmetric key;

• [h51] - [h67] defines a different Permissions element for this symmetric key;

• [h73] - [h75] contains a different CipherValue for this symmetric key;

[h79] – [h83] is the container for the third Symkey element in this response. For the sake of brevity, all the usual Symkey elements have been dispensed with, but the unique GlobalKeyID and KeyClass are shown to indicate the SKS server's response to the request. In this example, they are 10514-4-3795 and EHR-DEF respectively.

[h84] – [h113] contain the remaining Symkey elements of this SymkeyResponse. Once again, for brevity, all the details of the Symkey elements are dispensed with, except for the unique GKIDs and KeyClasses.

[h105] is the closing tag of the SymkeyResponse element.

Note that it is possible for a request to contain the same KeyClass multiple times; there is no requirement that they need to be unique within a request if an application has a legitimate business need for multiple symmetric keys of the same KeyClass. The SKS server will respond with unique symmetric keys, all belonging to the KeyClass requested by the client application.

An additional note is that the SymkeyRequestID is unchanged for every symmetric-key response element in this example. This is because a single request was responsible for the generation of all these keys, and as a result, every Symkey element contains the same SymkeyRequestID.

3.9 Request for a symmetric key with an Encryption Certificate

Within an SKMS, all requests and responses are digitally signed to ensure message-authenticity and integrity. In addition, the symmetric-key payload in the response is also encrypted with the Public Key of the requesting client's X509 digital certificate for message-confidentiality.

While it is always possible to build an SKMS that can find the encryption certificates of requesting clients, either within its database or from a Lightweight Directory Access Protocol (LDAP) directory on the network, it is sometimes efficient, or even necessary, to send the encryption certificate of the client with the symmetric key request.. The following example shows such a request.

[i01] <ekmi:SymkeyRequest
[i02] xmlns:ekmi=”http://docs.oasis-open.org/ekmi/2008/01">
[i03] <ekmi:GlobalKeyID>10514-0-0</ekmi:GlobalKeyID>
[i04] <ekmi:X509EncryptionCertificate>
MIIDfDCCAmSgAwIBAgIIAe/AvliGc3AwDQYJKoZIhvcNAQELBQAwZzEmMCQGA1UEAxMdU3Ryb25nab
S2V5IERFTU8gU3Vib3JkaW5hdGUgQ0ExJDAiBgNVBAsTG0ZvciBTdHJvbmdLZXkgREVNTyBVc2Ug1d
T25seTEXMBUGA1UEChMOU3Ryb25nQXV0aCBJbmMwHhcNMDYwNzI1MTcxMDMwWhcNMDcwNzIa64dd3k
A1UECxMbRm9yIFN0cm9uZ0tleSBERU1PIFVzZSBPbmx5MRcwFQYDVQQKEw5TdHJvbmdBdXRoIEl2da
S2V5IERFTU8gU3Vib3JkaW5hdGUgQ0ExJDAiBgNVBAsTG0ZvciBTdHJvbmdLZXkgREVNTyBVc2Ugia
T25seTEXMBUGA1UEChMOU3Ryb25nQXV0aCBJbmMwHhcNMDYwNzI1MTY0NjEwWhcNMDcwNzI1s34wdd
NjEwWjBpMREwDwYKCZImiZPyLGQBARMBOTEVMBMGA1UEAxMMU0tTIFNlcnZlci0xMSQwIgYDVQsdw2
ExtGb3IgU3Ryb25nS2V5IERFTU8gVXNlIE9ubHkxFzAVBgNVBAoTDlN0cm9uZ0F1dGggSW5jMIIBd2
NBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAztppqRoU5A8plxx1Rz1QEUnlAAM1D5g9+isIr3wxa
hbwjtFSMYilnY4iV77xU/nsMOnMZ7RxsLYKdCzQ1ODVYqQwqmAvaJ5Z6SVy34gZ51YG+rSWE3NjFsd
bOXW8RJYA/Tn6Lmht/qngrcaqqmtP0cAAiMRZOWtCTmC2K/LEqDabXSyU6Hh8ySNE3njybvmWpresf
zsYokTdvnWQqT6tKo1OwJsdJ1+hxM7DrnMLvMNq5reINfsKhDdX17wzhrBUx+hiYA/qo8tMXkL6wsd
4PN5dYugtzpSzIdUO5tIg58Avhzwo7hy5oofBlKFY22CeljQ36u0bMjuyGj6UYHs3rdfdfsds32rda
YzCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAyAmxMZhYA8wHJ4UE4b61s51JVWe4Fygj4MCf3a
hvcNAQELBQADggEBACK05PtvZD4WPglOe=
[i05] </ekmi:X509EncryptionCertificate>
[i06] </ekmi:SymkeyRequest>

[i01] is the start of the SymkeyRequest element.

[i02] identifies the namespace to which this XML conforms, and the location of its XML Schema Definition (XSD).

[i03] identifies the GlobalKeyID (GKID) being requested by the client application. The “zero” value for the Server ID and the Key ID indicates a request for a new symmetric key.

[i04] is the start of the X509EncryptionCertificate element. All the lines between [i04] and [i05] represent the Base64-encoded X509-compliant digital certificate of the requesting client, with the encryption-usage enabled in the certificate.

[i05] is the closing tag of the X509EncryptionCertificate element.

[i06] is the closing tag of the SymkeyRequest element.

3.10 Response with an SKS error

While one hopes that all authorized requesters will get favorable responses from the SKS server, there are situations in which the client application can receive an error to a request for a symmetric key. The following XML shows one example of such an error response. Depending on the type of error, the actual message content might be different.

[j01] <ekmi:SymkeyResponse
[j02] xmlns:ekmi='http://docs.oasis-open.org/ekmi/2008/01'
[j03] xmlns:xenc='http://www.w3.org/2001/04/xmlenc#'>
[j04] <ekmi:SymkeyError>
[j05] <ekmi:SymkeyRequestID>10514-2-1044</ekmi:SymkeyRequestID>
[j06] <ekmi:RequestedGlobalKeyID>10514-2-22</ekmi:RequestedGlobalKeyID>
[j07] <ekmi:RequestedKeyClass>Payroll</ekmi:RequestedKeyClass>
[j08] <ekmi:ErrorCode>SKS-100004</ekmi:ErrorCode>
[j09] <ekmi:ErrorMessage>Unauthorized request for key</ekmi:ErrorMessage>
[j10] </ekmi:SymkeyError>
[j11] </ekmi:SymkeyResponse>

[j01] is the start of the SymkeyResponse element.

[j02] and [j03] identify the namespaces to which this XML conforms, and the location of their XML Schema Definitions (XSD).

[j04] is the start of the SymkeyError element, which tells the Symmetric Key Client Library (SKCL) that the request for a symmetric key resulted in an error.

[j05] identifies the SymkeyRequestID assigned by the SKS server for this request. In this example, the concatenated values of the Domain ID, Server ID and Request ID indicate that the key belongs to the organization represented by the PEN, 10514; it was generated on an SKS server with a Server ID of 1 and is the 1,044^th unique request received on that SKS server.

[j06] indicates the RequestedGlobalKeyID the client requested. Returning the GKID in the error response allows the SKCL to associate the error message with the requesting application on the client machine.

[j07] indicates the RequestedKeyClass the client requested. Returning the key-class in the error response allows the SKCL to associate the error message with the requesting application on the client machine.

[j08] is an ErrorCode returned by the SKS server. The code may be one of the standard error codes defined in this specification, or may be a vendor-specific error code.

[j09] is the text of the ErrorMessage, localized to the region and language of the requesting client application.

[j10] is the closing tag of the SymkeyError tag.

[j11] is the closing tag of the SymkeyResponse tag.

3.11 Response with symmetric keys and errors

When a client application requests multiple symmetric keys, the SKS server may respond in one of three ways. The SKS server may:

1. Return all symmetric keys as requested;

2. Return no symmetric keys – i.e. it returns all errors;

3. Return some symmetric keys and some errors.

The following SKSML shows the third case, where the server returns some symmetric keys and errors in response to a request for multiple keys (such as the one shown in Section 3.7 Request for multiple new symmetric keys).

In a response that contains a mix of symmetric keys and errors, all symmetric keys precede all errors – i.e. the SymkeyResponse element will not consist of Symkeys interspersed with SymkeyErrors in between; all Symkeys (if any) will start from the top of the response till the first SymkeyError element.

[k01] <ekmi:SymkeyResponse
[k02] xmlns:ekmi='http://docs.oasis-open.org/ekmi/2008/01'
[k03] xmlns:xenc='http://www.w3.org/2001/04/xmlenc#'>
[k04] <ekmi:Symkey>
[k05] <ekmi:SymkeyRequestID>10514-4-1125927</ekmi:SymkeyRequestID>
[k06] <ekmi:GlobalKeyID>10514-4-3792</ekmi:GlobalKeyID>
[k07] <ekmi:KeyUsePolicy>
[k08] <ekmi:KeyUsePolicyID>10514-9</ekmi:KeyUsePolicyID>
[k09] <ekmi:PolicyName>DES-EDE Policy for EHR-CDC</ekmi:PolicyName>
[k10] <ekmi:KeyClass>EHR-CDC</ekmi:KeyClass>
[k11] <ekmi:KeyAlgorithm>
[k12] http://www.w3.org/2001/04/xmlenc#tripledes-cbc
[k13] </ekmi:KeyAlgorithm>
[k14] <ekmi:KeySize>192</ekmi:KeySize>
[k15] <ekmi:Status>Active</ekmi:Status>
[k16] <ekmi:Permissions>
[k17] <ekmi:PermittedApplications ekmi:any="true" xsi:nil="true"/>
[k18] <ekmi:PermittedDates ekmi:any="true" xsi:nil="true"/>
[k19] <ekmi:PermittedDays ekmi:any="true" xsi:nil="true"/>
[k20] <ekmi:PermittedDuration ekmi:any="true" xsi:nil="true"/>
[k21] <ekmi:PermittedLevels ekmi:any="true" xsi:nil="true"/>
[k22] <ekmi:PermittedLocations ekmi:any="true" xsi:nil="true"/>
[k23] <ekmi:PermittedNumberOfTransactions
[k24] ekmi:any="true" xsi:nil="true"/>
[k25] <ekmi:PermittedTimes ekmi:any="true" xsi:nil="true"/>
[k26] <ekmi:PermittedUses ekmi:any="true" xsi:nil="true"/>
[k27] </ekmi:Permissions>
[k28] </ekmi:KeyUsePolicy>
[k29] <ekmi:EncryptionMethod
[k30] Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-1_5"/>
[k31] <xenc:CipherData>
[k32] <xenc:CipherValue>
[k33] E9zWB/y93hVSzeTLiDcQoDxmlNxTuxSffMNwCJmt1dIqzQHBnpdQ81g6DKdkCFjJ
[k34] hQhywCx9sfYjv9h5FDqUiQXGOca8EU871zBoXBjDxjfg1pU8tlWtx27STRcR/2fw
[k35] UlWtx27STRcRJMtaGHtXuLlWtx27STRcRpIsY=
[k36] </xenc:CipherValue>
[k37] </xenc:CipherData>
[k38] </ekmi:Symkey>
[k39] <ekmi:Symkey>
[k40] <ekmi:SymkeyRequestID>10514-4-1125927</ekmi:SymkeyRequestID>
[k41] <ekmi:GlobalKeyID>10514-4-3793</ekmi:GlobalKeyID>
[k42] <ekmi:KeyUsePolicy>
[k43] <ekmi:KeyUsePolicyID>10514-12</ekmi:KeyUsePolicyID>
[k44] <ekmi:PolicyName>DES-EDE Policy for EHR-CRO</ekmi:PolicyName>
[k45] <ekmi:KeyClass>EHR-CRO</ekmi:KeyClass>
[k46] <ekmi:KeyAlgorithm>
[k47] http://www.w3.org/2001/04/xmlenc#tripledes-cbc
[k48] </ekmi:KeyAlgorithm>
[k49] <ekmi:KeySize>192</ekmi:KeySize>
[k50] <ekmi:Status>Active</ekmi:Status>
[k51] <ekmi:Permissions>
[k52] <ekmi:PermittedApplications ekmi:any="true" xsi:nil="true"/>
[k53] <ekmi:PermittedDates ekmi:any="true" xsi:nil="true"/>
[k54] <ekmi:PermittedDate>
[k55] <ekmi:StartDate>2008-01-01</ekmi:StartDate>
[k56] <ekmi:EndDate>2009-12-31</ekmi:EndDate>
[k57] </ekmi:PermittedDate>
[k58] </ekmi:PermittedDates>
[k59] <ekmi:PermittedDays ekmi:any="true" xsi:nil="true"/>
[k60] <ekmi:PermittedDuration ekmi:any="true" xsi:nil="true"/>
[k61] <ekmi:PermittedLevels ekmi:any="true" xsi:nil="true"/>
[k62] <ekmi:PermittedLocations ekmi:any="true" xsi:nil="true"/>
[k63] <ekmi:PermittedNumberOfTransactions
[k64] ekmi:any="true" xsi:nil="true"/>
[k65] <ekmi:PermittedTimes ekmi:any="true" xsi:nil="true"/>
[k66] <ekmi:PermittedUses ekmi:any="true" xsi:nil="true"/>
[k67] </ekmi:Permissions>
[k68] </ekmi:KeyUsePolicy>
[k69] <ekmi:EncryptionMethod
[k70] Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-1_5"/>
[k71] <xenc:CipherData>
[k72] <xenc:CipherValue>
[k73] qUiQXGOca8EU871zBoXBjDoDxmlNxTuxSffMNwCJmt1dIqzQHBnpdQ81g6DKdkCF
[k74] hQhywCx9sfYjv9h5FDqUiQXGOca8EU871zBoXBjDxjfg1pU8tGFbpWZcd/ATpJD/
[k75] UJow/qimxi8+ huUYJMtaGHtXuLlWtx27STRcRpIsY=
[k76] </xenc:CipherValue>
[k77] </xenc:CipherData>
[k78] </ekmi:Symkey>
[k79] <ekmi:Symkey>
[k80] <ekmi:SymkeyRequestID>10514-4-1125927</ekmi:SymkeyRequestID>
[k81] <ekmi:GlobalKeyID>10514-4-3795</ekmi:GlobalKeyID>
...
[k82] <ekmi:KeyClass>EHR-DEF</ekmi:KeyClass>
...
[k83] </ekmi:Symkey>
[k84] <ekmi:Symkey>
[k85] <ekmi:SymkeyRequestID>10514-4-1125927</ekmi:SymkeyRequestID>
[k86] <ekmi:GlobalKeyID>10514-4-3797</ekmi:GlobalKeyID>
...
[k87] <ekmi:KeyClass>EHR-EMT</ekmi:KeyClass>
...
[k88] </ekmi:Symkey>
[k89] <ekmi:Symkey>
[k90] <ekmi:SymkeyRequestID>10514-4-1125927</ekmi:SymkeyRequestID>
[k91] <ekmi:GlobalKeyID>10514-4-3798</ekmi:GlobalKeyID>
...
[k92] <ekmi:KeyClass>EHR-HOS</ekmi:KeyClass>
...
[k93] </ekmi:Symkey>
[k94] <ekmi:Symkey>
[k95] <ekmi:SymkeyRequestID>10514-4-1125927</ekmi:SymkeyRequestID>
[k96] <ekmi:GlobalKeyID>10514-4-3799</ekmi:GlobalKeyID>
...
[k97] <ekmi:KeyClass>EHR-INS</ekmi:KeyClass>
...
[k98] </ekmi:Symkey>
[k99] <ekmi:Symkey>
[k100] <ekmi:SymkeyRequestID>10514-4-1125927</ekmi:SymkeyRequestID>
[k101] <ekmi:GlobalKeyID>10514-4-3801</ekmi:GlobalKeyID>
...
[k102] <ekmi:KeyClass>EHR-NUR</ekmi:KeyClass>
...
[k103] </ekmi:Symkey>
[k104] <ekmi:SymkeyError>
[k105] <ekmi:SymkeyRequestID>10514-4-1125927</ekmi:SymkeyRequestID>
[k106] <ekmi:RequestedGlobalKeyID>10514-0-0</ekmi:RequestedGlobalKeyID>
[k107] <ekmi:RequestedKeyClass>EHR-PAT</ekmi:RequestedKeyClass>
[k108] <ekmi:ErrorCode>SKS-100004</ekmi:ErrorCode>
[k109] <ekmi:ErrorMessage>Unauthorized request for key</ekmi:ErrorMessage>
[k110] </ekmi:SymkeyError>
[k111] <ekmi:SymkeyError>
[k112] <ekmi:SymkeyRequestID>10514-4-1125927</ekmi:SymkeyRequestID>
[k113] <ekmi:RequestedGlobalKeyID>10514-0-0</ekmi:RequestedGlobalKeyID>
[k114] <ekmi:RequestedKeyClass>EHR-PHY</ekmi:RequestedKeyClass>
[k115] <ekmi:ErrorCode>SKS-100004</ekmi:ErrorCode>
[k116] <ekmi:ErrorMessage>Unauthorized request for key</ekmi:ErrorMessage>
[k117] </ekmi:SymkeyError>
[k118] </ekmi:SymkeyResponse>

[k01] – [k103] is no different from the response shown in Section 3.8 Response with multiple new symmetric keys.

[k104] - [k110] identifies the first SymkeyError returned by the SKS server. It is not unlike the error described in Section 3.9 Response with an SKS error.

[k111] - [k117] identifies the second SymkeyError returned by the SKS server.

[k118] is the closing tag of the SymkeyResponse tag.

3.12 Response with a pending Request ID

Some use-cases call for sending a request to the SKS server and getting a response, asynchronously. In these situations, SKSML allows for returning a response with a SymkeyRequestID in it. This indicates that the request is being processed and its status is currently pending. The client application may use this request identifier to poll the SKS server for an update on the request status.

The format of the SymkeyResponse is as follows.

[l01] <ekmi:SymkeyResponse
[l02] xmlns:ekmi='http://docs.oasis-open.org/ekmi/2008/01'
[l03] xmlns:xenc='http://www.w3.org/2001/04/xmlenc#'>
[l04] <ekmi:SymkeyWorkInProgress>
[l05] <ekmi:RequestedGlobalKeyID>10514-0-0</ekmi:RequestedGlobalKeyID>
[l06] <ekmi:SymkeyRequestID>10514-4-7235</ekmi:SymkeyRequestID>
[l07] </ekmi:SymkeyWorkInProgress>
[l08] </ekmi:SymkeyResponse>

[l01] – [l03] is the standard preamble to a SymkeyResponse element.

[l04] identifies the start of the second SymkeyWorkInProgress element. This indicates that the server was unable to return a response at this time and as a result, has provided a request identifier that the client may use to query the server at a later time for a response.

[l05] contains the RequestedGlobalKeyID element. This element contains either a request for a new symmetric key, or a request for an existing symmetric key. In this example, the request is for a new symmetric key.

[l06] contains the SymkeyRequestID element. This element contains the unique request identifier provided by the SKS server for the request it received. The SymkeyRequestID appears identical to the GlobalKeyID; however, their meanings are very distinct.

[l07] contains the closing tag of the SymkeyWorkInProgress element.

[l08] is the closing tag of the SymkeyResponse element.

3.13 Request for an update of a pending Request ID

Some use-cases call for sending a request and getting a response, to and from the SKS server, asynchronously. In these situations, SKSML allows for returning a response with a SymkeyRequestID in it that indicates that the status of the request is currently pending. The client application may use this request identifier to poll the SKS server for an update on the request status.

When a client makes a SymkeyRequest with a SymkeyRequestID in it, the SKS server may send back one of three responses: I) a SymkeyWorkInProgress with the same SymkeyRequestID in it, indicating that the request is still pending; ii) a SymkeyError, indicating that the request was processed, but the processing resulted in an error; and iii) a Symkey with a symmetric key in it, indicating a successful response.

The format of the SymkeyResponse is as follows.

[m01] <ekmi:SymkeyRequest
[m02] xmlns:ekmi='http://docs.oasis-open.org/ekmi/2008/01'>
[m03] <ekmi:SymkeyRequestID>10514-4-7235</ekmi:SymkeyRequestID>
[m04] </ekmi:SymkeyResponse>

[m01] – [m02] is the standard preamble to a SymkeyRequest element.

[m03] contains the SymkeyRequestID element. This element contains the unique request identifier provided by the SKS server when the client made the request for a symmetric key earlier. The SymkeyRequestID appears identical to the GlobalKeyID; however, their meanings are very distinct when they are wrapped in the appropriate element tags.

[m04] contains the closing tag of the SymkeyRequest element.

3.14 Request for a symmetric key-caching policy

When a client application (that has been linked to the SKCL) needs to encrypt sensitive data, it will call an API method within the SKCL for a new symmetric key. After the SKCL has ensured that the application is authorized to make such a request (by verifying that the configured/passed-in credentials can access the cryptographic key-store module on the client containing the PrivateKey used for signing SKSML requests), the SKCL assembles the following SKSML request:

[n01] <ekmi:KeyCachePolicyRequest
[n02] xmlns:ekmi=”http://docs.oasis-open.org/ekmi/2008/01">

[n03] <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">

[n04] ...

[n05] </ds:Signature>

[n06] </ekmi:KeyCachePolicyRequest>

[n01] is the start of the KeyCachePolicyRequest element.

[n02] identifies the namespace to which this XML conforms, and the location of its XML Schema Definition (XSD).

[n03] to [n05] will identify the XML Digital Signature of the sender.

[n06] is the end of the KeyCachePolicyRequest element.

The server uses the digital signature in XML format to establish the identity of the requester, as well as to to ensure message integrity in the request.

<ekmi:KeyCachePolicyRequest xmlns:ekmi="http://docs.oasis-open.org/ekmi/2008/01"/>

3.15 Response with a symmetric key-caching policy (1)

After an SKS server has performed its operations of authenticating a KeyCachePolicyRequest, identifying the requester, determining policies that apply to the requester, it assembles the following response and returns it to the client.

[o01] <ekmi:KeyCachePolicyResponse
[o02] xmlns:ekmi='http://docs.oasis-open.org/ekmi/2008/01'
[o03] xmlns:xenc='http://www.w3.org/2001/04/xmlenc#'>
[o04] <ekmi:KeyCachePolicy>
[o05] <ekmi:KeyCachePolicyID>10514-1</ekmi:KeyCachePolicyID>
[o06] <ekmi:PolicyName>No Caching Policy</ekmi:PolicyName>
[o07] <ekmi:Description>
[o08] This policy is for high-risk, always-connected machines on the
[o09] network, which will never cache symmetric keys locally. This
[o10] policy never expires (but checks monthly for any updates).
[o11] </ekmi:Description>
[o12] <ekmi:KeyClass>NoCachingClass</ekmi:KeyClass>
[o13] <ekmi:StartDate>2008-01-01T00:00:01.0</ekmi:StartDate>
[o14] <ekmi:EndDate>1969-01-01T00:00:00.0</ekmi:EndDate>
[o15] <ekmi:PolicyCheckInterval>2592000</ekmi:PolicyCheckInterval>
[o16] <ekmi:Status>Active</ekmi:Status>
[o17] </ekmi:KeyCachePolicy>
[o18] </ekmi:KeyCachePolicyResponse>

[o01] is the start of the KeyCachePolicyResponse element.

[o02] and [o03] identify the namespaces to which this XML conforms, and the location of their XML Schema Definitions (XSD).

[o04] is the start of the first – and only - KeyCachePolicy element.

[o05] identifies the KeyCachePolicyID (KCPID) assigned to this policy by the SKS server. In this example, the concatenated values of the Domain ID and Policy ID indicate that the key belongs to the organization represented by the PEN, 10514; and is the first key-caching policy within the SKMS.

[o06] provides a descriptive name for this key-cache policy through the PolicyName element, which is helpful to human readers when identifying this policy.

[o07] is the start tag of the Description element.

[o08] - [o10] provides a human-readable description about this key-cache policy.

[o11] is the closing tag of the Description element.

[o12] specifies the KeyClass to which this policy applies. Only keys that belong to this key-class are subject to this caching policy.

[o13] specifies the date and time that this KeyCachePolicy is effective. This is accomplished through a StartDate element. In this example, the policy is effective as of January 01, 2008.

[o14] specifies the date and time that this KeyCachePolicy becomes invalid. This is accomplished through a EndDate element. In this example, the use of the UNIX “epoch” date (January 01, 1969) indicates that this policy never expires.

[o15] specifies the frequency at which this client must check with the SKS server for updates to the key-caching policy. This is specified in seconds in the PolicyCheckInterval element; in this example it is a monthly interval.

[o16] indicates the Status of this KeyCachePolicy and whether it is an active policy or not.

[o17] is the closing tag of the KeyCachePolicy element.

[o18] is the closing tag of the KeyCachePolicyResponse element.

3.16 Response with a symmetric key-caching policy (2)

This is a second example of a key-caching policy response that has additional elements in the policy permitting caching and specify the number of unused and used (for encryption) symmetric keys that may be cached by the client machine.

[p01] <ekmi:KeyCachePolicyResponse
[p02] xmlns:ekmi='http://docs.oasis-open.org/ekmi/2008/01'
[p03] xmlns:xenc='http://www.w3.org/2001/04/xmlenc#'>
[p04] <ekmi:KeyCachePolicy>
[p05] <ekmi:KeyCachePolicyID>10514-17</ekmi:KeyCachePolicyID>
[p06] <ekmi:PolicyName>Corporate Laptop Key Caching Policy</ekmi:PolicyName>
[p07] <ekmi:Description>
[p08] This policy defines how company-issued laptops will manage symmetric
[p09] keys used for file/disk encryption in their local cache. This
[p10] policy must be used by all laptops that use the company EKMI.
[p11] </ekmi:Description>
[p12] <ekmi:KeyClass>LaptopKeysCachingClass</ekmi:KeyClass>
[p13] <ekmi:StartDate>2008-01-01T00:00:01.0</ekmi:StartDate>
[p14] <ekmi:EndDate>2008-12-31T00:00:01.0</ekmi:EndDate>
[p15] <ekmi:PolicyCheckInterval>2592000</ekmi:PolicyCheckInterval>
[p16] <ekmi:Status>Active</ekmi:Status>
[p17] <ekmi:NewKeysCacheDetail>
[p18] <ekmi:MaximumKeys>3</ekmi:MaximumKeys>
[p19] <ekmi:MaximumDuration>7776000</ekmi:MaximumDuration>
[p20] </ekmi:NewKeysCacheDetail>
[p21] <ekmi:UsedKeysCacheDetail>
[p22] <ekmi:MaximumKeys>3</ekmi:MaximumKeys>
[p23] <ekmi:MaximumDuration>7776000</ekmi:MaximumDuration>
[p24] </ekmi:UsedKeysCacheDetail>
[p25] </ekmi:KeyCachePolicy>
[p26] </ekmi:KeyCachePolicyResponse>

[p01] is the start of the KeyCachePolicyResponse element.

[p02] and [p03] identify the namespaces to which this XML conforms, and the location of their XML Schema Definitions (XSD).

[p04] is the start of the first – and only - KeyCachePolicy element.

[p05] identifies the KeyCachePolicyID (KCPID) assigned by the SKS server for the key-caching policy being returned.

[p06] provides a descriptive name for this key-cache policy through the PolicyName element, which is helpful to human readers when identifying this policy.

[p07] is the start tag of the Description element.

[p08] - [p10] provides a human-readable description about this key-cache policy.

[p11] is the closing tag of the Description element.

[p12] specifies the KeyClass to which this policy applies. Only keys that belong to this key-class are subject to this caching policy.

[p13] specifies the date and time that this KeyCachePolicy is effective. This is accomplished through a StartDate element. In this example, the policy is effective as of January 01, 2008.

[p14] specifies the date and time that this KeyCachePolicy becomes invalid. This is accomplished through a EndDate element. In this example, the policy expires on December 31, 2008.

[p15] specifies the frequency at which this client must check with the SKS server for updates to the key-caching policy. This is specified in seconds in the PolicyCheckInterval element; in this example it is a monthly interval.

[p16] indicates the Status of this KeyCachePolicy and whether it is an active policy or not.

[p17] is the start of the NewKeysCacheDetail element, which provides details about how many new symmetric keys – that haven't been used for any encryption transactions – may be cached by the client and for how long.

[p18] indicates the maximum number of new (unused) symmetric keys that may be cached by the client. This is specified through the MaximumKeys element. When the client uses a symmetric key, this reduces the number of new symmetric keys. In this case, the SKCL connects to the SKS server (if it is on the network) and requests a new symmetric key to add to its new-key cache.

[p19] indicates the maximum duration that new (unused) symmetric keys may be cached by the client. This is specified through the MaximumDuration element in seconds. If there are any new keys that exceed this duration limit, the SKCL deletes the specific symmetric key and replaces it with a new symmetric key from the SKS server.

[p20] is the closing tag of the NewKeysCacheDetail element.

[p21] is the start of the UsedKeysCacheDetail element, which provides details about how many used symmetric keys – those that HAVE been used for any encryption transactions – may be cached by the client and for how long.

[p22] indicates the maximum number of used symmetric keys that may be cached by the client through the MaximumKeys element. If the client already has the maximum number of used-keys in its cache, using the First-In-First-Out (FIFO) method, it deletes the oldest symmetric key in the cache to replace with the key that transitioned from the “new” to “used” status.

[p23] indicates the maximum duration that used symmetric keys may be cached by the clien through the MaximumDuration element in seconds. If there are any used keys that exceed this duration limit, the SKCL deletes the specific symmetric key. While this may temporarily reduce the number of used symmetric keys in the cache, the SKCL takes the most conservative position when making this decision.

[p24] is the closing tag of the UsedKeysCacheDetail element.

[p25] is the closing tag of the KeyCachePolicy element.

[p26] is the closing tag of the KeyCachePolicyResponse element.

3.17 Response with multiple symmetric key-caching policies (3)

This is a third example of a key-caching policy response that has multiple key-cache policies that apply to different classes of symmetric keys.

[q01] <ekmi:KeyCachePolicyResponse
[q02] xmlns:ekmi='http://docs.oasis-open.org/ekmi/2008/01'
[q03] xmlns:xenc='http://www.w3.org/2001/04/xmlenc#'>
[q04] <ekmi:KeyCachePolicy>
[q05] <ekmi:KeyCachePolicyID>10514-1</ekmi:KeyCachePolicyID>
[q06] <ekmi:PolicyName>No Caching Policy</ekmi:PolicyName>
[q07] <ekmi:Description>
[q08] This policy is for high-risk, always-connected machines on the
[q09] network, which will never cache symmetric keys locally. This
[q10] policy never expires (but checks monthly for any updates).
[q11] </ekmi:Description>
[q12] <ekmi:KeyClass>NoCachingClass</ekmi:KeyClass>
[q13] <ekmi:StartDate>2008-01-01T00:00:01.0</ekmi:StartDate>
[q14] <ekmi:EndDate>1969-01-01T00:00:00.0</ekmi:EndDate>
[q15] <ekmi:PolicyCheckInterval>2592000</ekmi:PolicyCheckInterval>
[q16] <ekmi:Status>Active</ekmi:Status>
[q17] </ekmi:KeyCachePolicy>
[q18] <ekmi:KeyCachePolicy>
[q19] <ekmi:KeyCachePolicyID>10514-17</ekmi:KeyCachePolicyID>
[q20] <ekmi:PolicyName>Corporate Laptop Key Caching Policy</ekmi:PolicyName>
[q21] <ekmi:Description>
[q22] This policy defines how company-issued laptops will manage symmetric
[q23] keys used for file/disk encryption in their local cache. This
[q24] policy must be used by all laptops that use the company EKMI.
[q25] </ekmi:Description>
[q26] <ekmi:KeyClass>LaptopKeysCachingClass</ekmi:KeyClass>
[q27] <ekmi:StartDate>2008-01-01T00:00:01.0</ekmi:StartDate>
[q28] <ekmi:EndDate>2008-12-31T00:00:01.0</ekmi:EndDate>
[q29] <ekmi:PolicyCheckInterval>2592000</ekmi:PolicyCheckInterval>
[q30] <ekmi:Status>Active</ekmi:Status>
[q31] <ekmi:NewKeysCacheDetail>
[q32] <ekmi:MaximumKeys>3</ekmi:MaximumKeys>
[q33] <ekmi:MaximumDuration>7776000</ekmi:MaximumDuration>
[q34] </ekmi:NewKeysCacheDetail>
[q35] <ekmi:UsedKeysCacheDetail>
[q36] <ekmi:MaximumKeys>3</ekmi:MaximumKeys>
[q37] <ekmi:MaximumDuration>7776000</ekmi:MaximumDuration>
[q38] </ekmi:UsedKeysCacheDetail>
[q39] </ekmi:KeyCachePolicy>
[q40] <ekmi:KeyCachePolicy>
[q41] <ekmi:KeyCachePolicyID>10514-17</ekmi:KeyCachePolicyID>
[q42] <ekmi:PolicyName>Corporate Laptop Key Caching Policy</ekmi:PolicyName>
[q43] <ekmi:Description>
[q44] This policy defines how company-issued laptops will manage
[q45] symmetric keys used for file/disk encryption in their local
[q46] cache. This policy must be used by all laptops.
[q47] </ekmi:Description>
[q48] <ekmi:KeyClass>LaptopKeysCachingClass</ekmi:KeyClass>
[q49] <ekmi:StartDate>2008-01-01T00:00:01.0</ekmi:StartDate>
[q50] <ekmi:EndDate>2008-12-31T00:00:01.0</ekmi:EndDate>
[q51] <ekmi:PolicyCheckInterval>2592000</ekmi:PolicyCheckInterval>
[q52] <ekmi:Status>Active</ekmi:Status>
[q53] <ekmi:NewKeysCacheDetail>
[q54] <ekmi:MaximumKeys>3</ekmi:MaximumKeys>
[q55] <ekmi:MaximumDuration>7776000</ekmi:MaximumDuration>
[q56] </ekmi:NewKeysCacheDetail>
[q57] <ekmi:UsedKeysCacheDetail>
[q58] <ekmi:MaximumKeys>3</ekmi:MaximumKeys>
[q59] <ekmi:MaximumDuration>7776000</ekmi:MaximumDuration>
[q60] </ekmi:UsedKeysCacheDetail>
[q61] <ekmi:KeyCachePolicy>
[q62] </ekmi:KeyCachePolicyResponse>

[q01] is the start of the KeyCachePolicyResponse element.

[q02] and [q03] identify the namespaces to which this XML conforms, and the location of their XML Schema Definitions (XSD).

[q04] is the start of the first of three KeyCachePolicy elements in this response.

[q05] identifies the KeyCachePolicyID (KCPID) assigned to this policy by the SKS server. In this example, the concatenated values of the Domain ID and Policy ID indicate that the key belongs to the organization represented by the PEN, 10514; and is the first key-caching policy within the SKMS.

[q06] provides a descriptive name for this key-cache policy through the PolicyName element, which is helpful to human readers when identifying this policy.

[q07] is the start tag of the Description element.

[q08] - [q10] provides a human-readable description about this key-cache policy.

[q11] is the closing tag of the Description element.

[q12] specifies the KeyClass to which this policy applies. Only keys that belong to this key-class are subject to this caching policy.

[q13] specifies the date and time that this KeyCachePolicy is effective. This is accomplished through a StartDate element. In this example, the policy is effective as of January 01, 2008.

[q14] specifies the date and time that this KeyCachePolicy becomes invalid. This is accomplished through a EndDate element. In this example, the use of the UNIX “epoch” date (January 01, 1969) indicates that this policy never expires.

[q15] specifies the frequency at which this client must check with the SKS server for updates to the key-caching policy. This is specified in seconds in the PolicyCheckInterval element; in this example it is a monthly interval.

[q16] indicates the Status of this KeyCachePolicy and whether it is an active policy or not.

[q17] is the closing tag of the first KeyCachePolicy element.

[q18] is the start of the second of three KeyCachePolicy elements in this response.

[q19] identifies the KeyCachePolicyID (KCPID) assigned by the SKS server for the key-caching policy being returned.

[q20] provides the descriptive name for this key-cache policy through the PolicyName element.

[q21] is the start tag of the Description element.

[q22] - [q24] provides a human-readable description about this key-cache policy.

[q25] is the closing tag of the Description element.

[q26] specifies the KeyClass to which this policy applies. Only keys that belong to this key-class are subject to this caching policy.

[q27] specifies the date and time that this KeyCachePolicy is effective. This is accomplished through a StartDate element. In this example, the policy is effective as of January 01, 2008.

[q28] specifies the date and time that this KeyCachePolicy becomes invalid. This is accomplished through a EndDate element. In this example, the policy expires on December 31, 2008.

[q29] specifies the frequency at which this client must check with the SKS server for updates to the key-caching policy. This is specified in seconds in the PolicyCheckInterval element; in this example it is a monthly interval.

[q30] indicates the Status of this KeyCachePolicy and whether it is an active policy or not.

[q31] is the start of the NewKeysCacheDetail element, which provides details about how many new symmetric keys – that haven't been used for any encryption transactions – may be cached by the client and for how long.

[q32] indicates the maximum number of new (unused) symmetric keys that may be cached by the client. This is specified through the MaximumKeys element. When the client uses a symmetric key, this reduces the number of new symmetric keys. In this case, the SKCL connects to the SKS server (if it is on the network) and requests a new symmetric key to add to its new-key cache.

[q33] indicates the maximum duration that new (unused) symmetric keys may be cached by the client. This is specified through the MaximumDuration element in seconds. If there are any new keys that exceed this duration limit, the SKCL deletes the specific symmetric key and replaces it with a new symmetric key from the SKS server.

[q34] is the closing tag of the NewKeysCacheDetail element.

[q35] is the start of the UsedKeysCacheDetail element, which provides details about how many used symmetric keys – those that HAVE been used for any encryption transactions – may be cached by the client and for how long.

[q36] indicates the maximum number of used symmetric keys that may be cached by the client through the MaximumKeys element. If the client already has the maximum number of used-keys in its cache, using the First-In-First-Out (FIFO) method, it deletes the oldest symmetric key in the cache to replace with the key that transitioned from the “new” to “used” status.

[q37] indicates the maximum duration that used symmetric keys may be cached by the clien through the MaximumDuration element in seconds. If there are any used keys that exceed this duration limit, the SKCL deletes the specific symmetric key. While this may temporarily reduce the number of used symmetric keys in the cache, the SKCL takes the most conservative position when making this decision.

[q38] is the closing tag of the UsedKeysCacheDetail element.

[q39] is the closing tag of the second KeyCachePolicy element.

[q40] is the start of the third KeyCachePolicy element in this response.

[q41] identifies the KeyCachePolicyID (KCPID) assigned by the SKS server for the key-caching policy being returned.

[q42] provides the descriptive name for this key-cache policy through the PolicyName element.

[q43] is the start tag of the Description element.

[q44] - [q46] provides a human-readable description about this key-cache policy.

[q47] is the closing tag of the Description element.

[q48] specifies the KeyClass to which this policy applies. Only keys that belong to this key-class are subject to this caching policy.

[q49] specifies the date and time that this KeyCachePolicy is effective.

[q50] specifies the date and time that this KeyCachePolicy becomes invalid.

[q51] specifies the frequency at which this client must check with the SKS server for updates to the key-caching policy.

[q52] indicates the Status of this KeyCachePolicy and whether it is an active policy or not.

[q53] is the start of the NewKeysCacheDetail element, which provides details about how many new symmetric keys may be cached by the client and for how long.

[q54] indicates the maximum number of new (unused) symmetric keys that may be cached by the client. This is specified through the MaximumKeys element. When the client uses a symmetric key, this reduces the number of new symmetric keys. In this case, the SKCL connects to the SKS server (if it is on the network) and requests a new symmetric key to add to its new-key cache.

[q55] indicates the maximum duration that new (unused) symmetric keys may be cached by the client. This is specified through the MaximumDuration element in seconds. If there are any new keys that exceed this duration limit, the SKCL deletes the specific symmetric key and replaces it with a new symmetric key from the SKS server.

[q56] is the closing tag of the NewKeysCacheDetail element.

[q57] is the start of the UsedKeysCacheDetail element, which provides details about how many used symmetric keys – those that HAVE been used for any encryption transactions – may be cached by the client and for how long.

[q58] indicates the maximum number of used symmetric keys that may be cached by the client through the MaximumKeys element. If the client already has the maximum number of used-keys in its cache, using the First-In-First-Out (FIFO) method, it deletes the oldest symmetric key in the cache to replace with the key that transitioned from the “new” to “used” status.

[q59] indicates the maximum duration that used symmetric keys may be cached by the clien through the MaximumDuration element in seconds. If there are any used keys that exceed this duration limit, the SKCL deletes the specific symmetric key. While this may temporarily reduce the number of used symmetric keys in the cache, the SKCL takes the most conservative position when making this decision.

[q60] is the closing tag of the UsedKeysCacheDetail element.

[q61] is the closing tag of the third and final KeyCachePolicy element in this response.

[q62] is the closing tag of the KeyCachePolicyResponse element.

4 Specification

4.1 Element <SymkeyRequest>

The <SymkeyRequest> element identifies one or more GlobalKeyID's of symmetric encryption keys needed by the client application. The request may also specify one or more KeyClass elements for the requested key when the request is for a new symmetric key.

Schema Definition:

<xsd:element name="SymkeyRequest">
<xsd:complexType>

<xsd:choice>

<xsd:sequence>

<xsd:element

name="GlobalKeyID"

type="ekmi:GlobalKeyIDType"

minOccurs="1"

maxOccurs="unbounded">

</xsd:element>

<xsd:element

name="KeyClasses"

type="ekmi:KeyClassesType"

minOccurs="0"

maxOccurs=”unbounded”>

</xsd:element>

<xsd:element

name="X509EncryptionCertificate"

type="ekmi:X509CertificateType"

minOccurs="0"

maxOccurs="1">

</xsd:element>

</xsd:sequence>

<xsd:sequence>

<xsd:element

name="SymkeyRequestID"

type="ekmi:SymkeyRequestIDType"

minOccurs="1"

maxOccurs="unbounded">

</xsd:element>

</xsd:sequence>

</xsd:choice>

</xsd:complexType>

</xsd:element>

The <SymkeyRequest> element consists of a choice of two sequences of elements; one or the other sequence MUST be present in a <SymkeyRequest>.

1. <GlobalKeyID> [Required]
   
   The first sequence choice consists of the <GlobalKeyID> element of type GlobalKeyIDType. It identifies the unique global key identifier of the requested symmetric key within the target Symmetric Key Management System (SKMS). If this sequence is chosen, there MUST be at least one <GlobalKeyID> element in a <SymkeyRequest>, but there may be an unbounded (unlimited) number of <GlobalKeyID> elements specified.
   
   The <GlobalKeyID> element and GlobalKeyIDType is specified in Section 4.2.

   <KeyClasses> [Optional]
   
   This element of type KeyClassesType, when specified, identifies at least one <KeyClass> element, but may specify an unbounded (unlimited) number of <KeyClass> elements within the <KeyClasses> set. Client applications may request one or more symmetric keys conforming to one or more key classes required by the application. If the client application is authorized to receive keys conforming to such key classes, the SKS server will generate and supply them.
   
   When more than one <GlobalKeyID> for a new symmetric key is specified in the request, there MAY be only one <KeyClass> element within the <KeyClasses> set.
   
   When the client requires more than one new symmetric key, and each key is required to be of a different key class, there MUST be only one <GlobalKeyID> element followed by as many <KeyClass> elements inside the <KeyClasses> set, as needed by the client application.
   
   When a client requires multiple symmetric keys of two or more key classes, the client MUST send multiple requests to the SKS server. See examples 4 and 5 below in this section.
   
   The <KeyClasses> and <KeyClass> elements and their respective types are specified in Section 4.3.

   <X509EncryptionCertificate> [Optional]
   
   This element of type X509EncryptionCertificateType, when specified, identifies a PKI X509-compliant digital certificate whose corresponding private-key is owned/authorized for use by the requesting client. The <X509EncryptionCertificate> MUST meet the following requirements:

   1. It MUST be a valid X509 v3 digital certificate whose expiry is not earlier than the date and time the symmetric-key request is received by the SKS server;

   2. It MUST not be revoked by the Certificate Authority (CA) who issued the encryption certificate at the date and time the symmetric-key request is received by the SKS server;

   3. It MUST have its keyEncipherment bit set in the keyUsage extension of the certificate.

Note: The SKS server will use the specified X509EncryptionCertificate if the security policy on the SKS server permits it. The security policy may have specified that only encryption certificates stored on the SKS server database or in an LDAP Directory known the to server be used; in which case the SKS server will ignore the encryption certificate in the X509EncryptionCertificate element and use what is stored on the SKS server or other location known to the server. In the event the SKS server uses an encryption certificate stored on the server-side, it is assumed that the requesting client has the corresponding private-key to decrypt the payload when extracted from the response.

The <X509EncryptionCertificate> and its respective type is specified in Section 4.4.

2. <SymkeyRequestID> [Required]
   
   The second sequence choice consists of the <SymkeyRequestID> element of type SymkeyRequestIDType. It identifies the unique symmetric-key request identifier within the target Symmetric Key Management System (SKMS). If this sequence is chosen, there MUST be at least one <SymkeyRequestID> element in a <SymkeyRequest>, but there may be an unbounded (unlimited) number of <SymkeyRequestID> elements specified.
   
   The presence of the <SymkeyRequestID> element in the <SymkeyRequest> implies that the client had previously made a <SymkeyRequest> asynchronously,and instead of receiving a <Symkey> or a <SymkeyError>, it received a <SymkeyWorkInProgress> response with a <SymkeyRequestID> in it. The client is now following-up with the SKS Server to get an update on its earlier request with the <SymkeyRequestID>.
   
   The <SymkeyRequestID> element and the SymkeyRequestIDType is specified in Section 4.5.

Some examples of the <SymkeyRequest> element are as follows:

Example 1 – A single new symmetric key request of a default key class:

<ekmi:SymkeyRequest xmlns:ekmi=”http://docs.oasis-open.org/ekmi/2008/01">
<ekmi:GlobalKeyID>10514-0-0</ekmi:GlobalKeyID>
</ekmi:SymkeyRequest>

Example 2 – A request for three new symmetric keys of a default key class for each symmetric key:

<ekmi:SymkeyRequest xmlns:ekmi=”http://docs.oasis-open.org/ekmi/2008/01">
<ekmi:GlobalKeyID>10514-0-0</ekmi:GlobalKeyID>
<ekmi:GlobalKeyID>10514-0-0</ekmi:GlobalKeyID>
<ekmi:GlobalKeyID>10514-0-0</ekmi:GlobalKeyID>
</ekmi:SymkeyRequest>

Example 3 – A request for a single new symmetric key of a specific key class:

<ekmi:SymkeyRequest xmlns:ekmi=”http://docs.oasis-open.org/ekmi/2008/01">
<ekmi:GlobalKeyID>10514-0-0</ekmi:GlobalKeyID>
<ekmi:KeyClasses>
<ekmi:KeyClass>HR-Class</ekmi:KeyClass>
</ekmi:KeyClasses>
</ekmi:SymkeyRequest>

Example 4 – A request for a two new symmetric keys with the same key class for each symmetric key:

<ekmi:SymkeyRequest xmlns:ekmi=”http://docs.oasis-open.org/ekmi/2008/01">
<ekmi:GlobalKeyID>10514-0-0</ekmi:GlobalKeyID>
<ekmi:GlobalKeyID>10514-0-0</ekmi:GlobalKeyID>
<ekmi:KeyClasses>
<ekmi:KeyClass>FIN-FX</ekmi:KeyClass>
</ekmi:KeyClasses>
</ekmi:SymkeyRequest>

Example 5 – A request for a nine new symmetric keys of different key classes:

<ekmi:SymkeyRequest xmlns:ekmi=”http://docs.oasis-open.org/ekmi/2008/01">
<ekmi:GlobalKeyID>10514-0-0</ekmi:GlobalKeyID>
<ekmi:KeyClasses>
<ekmi:KeyClass>EHR-CDC</ekmi:KeyClass>
<ekmi:KeyClass>EHR-CRO</ekmi:KeyClass>
<ekmi:KeyClass>EHR-DEF</ekmi:KeyClass>
<ekmi:KeyClass>EHR-EMT</ekmi:KeyClass>
<ekmi:KeyClass>EHR-HOS</ekmi:KeyClass>
<ekmi:KeyClass>EHR-INS</ekmi:KeyClass>
<ekmi:KeyClass>EHR-NUR</ekmi:KeyClass>
<ekmi:KeyClass>EHR-PAT</ekmi:KeyClass>
<ekmi:KeyClass>EHR-PHY</ekmi:KeyClass>
</ekmi:KeyClasses>
</ekmi:SymkeyRequest>

Example 6 – A follow-up request to a previously received symmetric-key request ID:

<ekmi:SymkeyRequest xmlns:ekmi=”http://docs.oasis-open.org/ekmi/2008/01">
<ekmi:SymkeyRequestID>10514-1-1234</ekmi:SymkeyRequestID>
</ekmi:SymkeyRequest>

Example 7 – A follow-up request to previously received multiple symmetric-key request IDs:

<ekmi:SymkeyRequest xmlns:ekmi=”http://docs.oasis-open.org/ekmi/2008/01">
<ekmi:SymkeyRequestID>10514-1-1234</ekmi:SymkeyRequestID>
<ekmi:SymkeyRequestID>10514-1-1345</ekmi:SymkeyRequestID>
<ekmi:SymkeyRequestID>10514-1-1347</ekmi:SymkeyRequestID>
</ekmi:SymkeyRequest>

Example 8 – A new symmetric key request of a default key class with the X509EncryptionCertificate sent by the client to the server:

<ekmi:SymkeyRequest xmlns:ekmi=”http://docs.oasis-open.org/ekmi/2008/01">
<ekmi:GlobalKeyID>10514-0-0</ekmi:GlobalKeyID>
<ekmi:X509EncryptionCertificate>
MIIDfDCCAmSgAwIBAgIIAe/AvliGc3AwDQYJKoZIhvcNAQELBQAwZzEmMCQGA1UEAxMdU3Ryb25n S2V5IERFTU8gU3Vib3JkaW5hdGUgQ0ExJDAiBgNVBAsTG0ZvciBTdHJvbmdLZXkgREVNTyBVc2Ug T25seTEXMBUGA1UEChMOU3Ryb25nQXV0aCBJbmMwHhcNMDYwNzI1MTcxMDMwWhcNMDcwNzI1MTcy MDMwWjBtMREwDwYKCZImiZPyLGQBARMBMjEZMBcGA1UEAxMQUE9TIFJlZ2lzdGVyIDIyMjEkMCIG A1UECxMbRm9yIFN0cm9uZ0tleSBERU1PIFVzZSBPbmx5MRcwFQYDVQQKEw5TdHJvbmdBdXRoIElu YzCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAyAmxMZhYA8wHJ4UE4b61s51JVWe4Fygj4MCf U7LA3JhpUS4TlX0XFWqrcmltLOiVG7YBFarJFluBFJW2X6q8FuvUprv4V9nJrgiwAPtkiRyIx96n qKXIxkUlQ4idlEg1AZI9dEdf4Y5cqBBCygPYnBoTudglM7R47AjR4nr4ks8CAwEAAaOBqTCBpjAO BgNVHQ8BAf8EBAMCBLAwHQYDVR0OBBYEFOIOrWrZo0LdBRLVncRAwLBqVZpCMB8GA1UdIwQYMBaA FPTYwEHoJG4iFVHRnt2EWxGluAQVMBgGA1UdIAQRMA8wDQYLKwYEAdISg30BBAEwOgYDVR0fBDMw MTAvoC2gK4YpaHR0cDovL2RlbW8uc3Ryb25na2V5Lm9yZy9kZW1vLXN1Yi1jYS5jcmwwDQYJKoZI hvcNAQELBQADggEBACK05PtvZD4WPglOe+EHUiApzFyCdRzf0pFZtxRwG9lR1PZUWUjmwTNfGFsL S6kyoHgUfVa5fpT1EU1mXUB/Lmo3hFGyprZjfmD7DwuBcYgmZHv7yHrmGOMIOXjFTACvHpM0vOce hVx2e4VE0yhBLu/ldH9awGGDp6Bk2XzxqQcs8y6ZzOXZAnPgKQZdjbFKERSsy/d1D8pk5baBk4bd Zh568OcaUrbm9ZReRVTVaY5qiQpkOU+tDrBSj/HIL6GAqegYllkz6KYCy6RVOy6iVVSjHocDqdJr EVOR+ds6xn8mmojdlERrILmuxiLpibPp609SfnDIxNlzLwe5g7ep3lc=
</ekmi:X509EncryptionCertificate>
</ekmi:SymkeyRequest>

Example 9 – A new symmetric key request with a specific key class and the X509EncryptionCertificate:

<ekmi:SymkeyRequest xmlns:ekmi=”http://docs.oasis-open.org/ekmi/2008/01">
<ekmi:GlobalKeyID>10514-0-0</ekmi:GlobalKeyID>
<ekmi:KeyClasses>
<ekmi:KeyClass>HR-Class</ekmi:KeyClass>
</ekmi:KeyClasses>
<ekmi:X509EncryptionCertificate>
MIIDfDCCAmSgAwIBAgIIAe/AvliGc3AwDQYJKoZIhvcNAQELBQAwZzEmMCQGA1UEAxMdU3Ryb25n S2V5IERFTU8gU3Vib3JkaW5hdGUgQ0ExJDAiBgNVBAsTG0ZvciBTdHJvbmdLZXkgREVNTyBVc2Ug T25seTEXMBUGA1UEChMOU3Ryb25nQXV0aCBJbmMwHhcNMDYwNzI1MTcxMDMwWhcNMDcwNzI1MTcy MDMwWjBtMREwDwYKCZImiZPyLGQBARMBMjEZMBcGA1UEAxMQUE9TIFJlZ2lzdGVyIDIyMjEkMCIG A1UECxMbRm9yIFN0cm9uZ0tleSBERU1PIFVzZSBPbmx5MRcwFQYDVQQKEw5TdHJvbmdBdXRoIElu YzCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAyAmxMZhYA8wHJ4UE4b61s51JVWe4Fygj4MCf U7LA3JhpUS4TlX0XFWqrcmltLOiVG7YBFarJFluBFJW2X6q8FuvUprv4V9nJrgiwAPtkiRyIx96n qKXIxkUlQ4idlEg1AZI9dEdf4Y5cqBBCygPYnBoTudglM7R47AjR4nr4ks8CAwEAAaOBqTCBpjAO BgNVHQ8BAf8EBAMCBLAwHQYDVR0OBBYEFOIOrWrZo0LdBRLVncRAwLBqVZpCMB8GA1UdIwQYMBaA FPTYwEHoJG4iFVHRnt2EWxGluAQVMBgGA1UdIAQRMA8wDQYLKwYEAdISg30BBAEwOgYDVR0fBDMw MTAvoC2gK4YpaHR0cDovL2RlbW8uc3Ryb25na2V5Lm9yZy9kZW1vLXN1Yi1jYS5jcmwwDQYJKoZI hvcNAQELBQADggEBACK05PtvZD4WPglOe+EHUiApzFyCdRzf0pFZtxRwG9lR1PZUWUjmwTNfGFsL S6kyoHgUfVa5fpT1EU1mXUB/Lmo3hFGyprZjfmD7DwuBcYgmZHv7yHrmGOMIOXjFTACvHpM0vOce hVx2e4VE0yhBLu/ldH9awGGDp6Bk2XzxqQcs8y6ZzOXZAnPgKQZdjbFKERSsy/d1D8pk5baBk4bd Zh568OcaUrbm9ZReRVTVaY5qiQpkOU+tDrBSj/HIL6GAqegYllkz6KYCy6RVOy6iVVSjHocDqdJr EVOR+ds6xn8mmojdlERrILmuxiLpibPp609SfnDIxNlzLwe5g7ep3lc=
</ekmi:X509EncryptionCertificate>
</ekmi:SymkeyRequest>

4.2 Element <GlobalKeyID>

The <GlobalKeyID> element is the unique identifier of a symmetric encryption key within an SKMS. Every symmetric key generated by the SKS server MUST be assigned a unique <GlobalKeyID> as specified in this section.

Schema Definition:

<xsd:simpleType name="GlobalKeyIDType">
<xsd:restriction base="xsd:string">
<xsd:minLength value="5"/>
<xsd:maxLength value="62"/>
<xsd:pattern value="[0-9]{1,20}-[0-9]{1,20}-[0-9]{1,20}"/>
<xsd:whiteSpace value="collapse"/>
</xsd:restriction>
</xsd:simpleType>

The <GlobalKeyID> element is of the GlobalKeyIDType, and is a string identifier of a symmetric key consisting of five parts concatenated together:

1. A positive integer identifying the Domain ID. The DomainID identifies the IANA-issued Private Enterprise Number (PEN) as published at http://www.iana.org/assignments/enterprise-numbers and is used by the SKS server to constrain the ownership of objects within the SKMS:

2. A literal hyphen ("-") without surrounding spaces;

3. A positive integer identifying the Server ID of the server;

4. Another literal hyphen ("-") without surrounding spaces;

5. A positive integer identifying the unique Key ID;

Combined, the five components of this element make up a unique identifier for a symmetric key within the SKMS. Since all enterprise are expected to use only the PENs assigned to them, and assuming they do, the <GlobalKeyID> is unique across the internet.

The DomainID part of the <GlobalKeyID> element MUST be a positive integer in the range of 0 (zero) to 18446744073709551615 (20-byte ASCII decimal).

When an SKMS manages the symmetric keys for a single enterprise, the DomainID part of the <GlobalKeyID> element in a <SymkeyRequest> MAY be zero (“0”). When an SKMS manages symmetric keys for multiple enterprises, the DomainID in the <GlobalKeyID> of a <SymkeyRequest> MUST be positive and non-zero. In such a situation, the client application will request a symmetric key for the domain in which it is authorized to request and receive keys.

The DomainID in the <GlobalKeyID> element of a <SymkeyResponse> MUST always be positive and non-zero. It will typically contain the PEN of the domain to which the symmetric key belongs.

The ServerID part of the <GlobalKeyID> element MUST be a positive integer in the range of 0 (zero) to 18446744073709551615 (20-byte ASCII decimal).

The ServerID part of the <GlobalKeyID> element of a <SymkeyRequest> MUST always be zero (“0”).

The ServerID part of the <GlobalKeyID> element of a <SymkeyResponse> MUST always be positive and non-zero. It will typically contain the unique server identifier of the SKS server where the symmetric key was generated.

The KeyID part of the <GlobalKeyID> element MUST be a positive integer in the range of 0 (zero) to 18446744073709551615 (20-byte ASCII decimal).

The KeyID part of the <GlobalKeyID> element of a <SymkeyRequest> MUST always be zero (“0”).

The KeyID part of the <GlobalKeyID> element of a <SymkeyResponse> MUST always be positive and non-zero. It will typically contain the unique key identifier of the symmetric key within the SKS server where the key was generated.

Example 1 – A <GlobalKeyID> value for a new symmetric key from an SKMS that serves a single domain:

<ekmi:GlobalKeyID>0-0-0</ekmi:GlobalKeyID>

Example 2 – A <GlobalKeyID> value for a new symmetric key for the domain with the PEN 10514, from an SKMS that serves multiple domains:

<ekmi:GlobalKeyID>10514-0-0</ekmi:GlobalKeyID>

Example 3 – A <GlobalKeyID> value for the 16,777,215th symmetric key generated on 2^nd SKS server for an enterprise with the PEN 10514, in either a <SymkeyRequest> or a <SymkeyResponse>:

<ekmi:GlobalKeyID>10514-2-16777215</ekmi:GlobalKeyID>

Example 4 – The maximum <GlobalKeyID> value possible (a 62-byte ASCII decimal), in a <SymkeyRequest> or <SymkeyResponse>:

<ekmi:GlobalKeyID>

18446744073709551615-18446744073709551615-18446744073709551615

</ekmi:GlobalKeyID>

4.3 Element <KeyClasses> and <KeyClass>

The <KeyClasses> element of type KeyClassesType, when specified, identifies at least one <KeyClass> element, but may specify an unbounded (unlimited) number of <KeyClass> elements within the <KeyClasses> set.

Schema Definition:

<xsd:complexType name="KeyClassesType">
<xsd:sequence>

<xsd:element

name="KeyClass"

type="ekmi:KeyClassType"

minOccurs="1"

maxOccurs="unbounded"/>

</xsd:sequence>

</xsd:complexType>

<xsd:simpleType name="KeyClassType">

<xsd:restriction base="xsd:string">

<xsd:maxLength value="255"/>

</xsd:restriction>

</xsd:simpleType>

Client applications may request one or more symmetric keys conforming to one or more key classes required by the application. If the client application is authorized to receive keys conforming to such key classes, the SKS server will generate and supply them.

The <KeyClasses> element is useful only when requesting new symmetric keys, i.e. symmetric encryption keys that have previously NOT been used for encrypting data. There is little reason for a client application to specify the <KeyClasses> element when requesting an existing (escrowed) symmetric key. This is because the SKS server will return the requested key to authorized clients with whatever key class is associated with the key, regardless of what key class is specified in the request. The key class will have been associated with the symmetric key at the time of its generation and cannot be changed once associated with a key.

When more than one <GlobalKeyID> is specified in the request, there MAY be only one <KeyClass> element within the <KeyClasses> set. When a key class is not specified in a request, it implies a request for symmetric key(s) of a default key class configured at the SKS server. The default key class for a site is site-specific.

When the client requires more than one symmetric key, and each key needs to be of a different key class, there MUST be only one <GlobalKeyID> element followed by as many <KeyClass> elements insides the <KeyClasses> set as needed by the client application. (Example 5 in this section).

When a client requires many symmetric keys – say five keys – and two or more keys belong to the same key class, the client MUST send multiple requests to the SKS server. One request will contain multiple <GlobalKeyID> elements with one <KeyClass> element in the <KeyClasses> set, and the other request will contain one <GlobalKeyID> element and multiple <KeyClass> elements within the <KeyClasses> set. (Examples 4 and 5 in this section).

Example 1 – A symmetric key request of a default key class (when no KeyClass is specified):

<ekmi:SymkeyRequest xmlns:ekmi=”http://docs.oasis-open.org/ekmi/2008/01">
<ekmi:GlobalKeyID>10514-0-0</ekmi:GlobalKeyID>
</ekmi:SymkeyRequest>

Example 2 – A request for multiple new symmetric keys, each of a default key class:

<ekmi:SymkeyRequest xmlns:ekmi=”http://docs.oasis-open.org/ekmi/2008/01">
<ekmi:GlobalKeyID>10514-0-0</ekmi:GlobalKeyID>
<ekmi:GlobalKeyID>10514-0-0</ekmi:GlobalKeyID>
</ekmi:SymkeyRequest>

Example 3 – A request for a new symmetric key of a specific key class:

<ekmi:SymkeyRequest xmlns:ekmi=”http://docs.oasis-open.org/ekmi/2008/01">
<ekmi:GlobalKeyID>10514-0-0</ekmi:GlobalKeyID>
<ekmi:KeyClasses>
<ekmi:KeyClass>256-Bit-Class</ekmi:KeyClass>
</ekmi:KeyClasses>
</ekmi:SymkeyRequest>

Example 4 – A request for two new symmetric keys of the same key class for each symmetric key. Note that if the FIN-FX key class was the default key class, a request as shown in Example 2 of this section would result in the same response:

<ekmi:SymkeyRequest xmlns:ekmi=”http://docs.oasis-open.org/ekmi/2008/01">
<ekmi:GlobalKeyID>10514-0-0</ekmi:GlobalKeyID>
<ekmi:GlobalKeyID>10514-0-0</ekmi:GlobalKeyID>
<ekmi:KeyClasses>
<ekmi:KeyClass>FIN-FX</ekmi:KeyClass>
</ekmi:KeyClasses>
</ekmi:SymkeyRequest>

Example 5 – A request for a four new symmetric keys of different key classes:

<ekmi:SymkeyRequest xmlns:ekmi=”http://docs.oasis-open.org/ekmi/2008/01">
<ekmi:GlobalKeyID>10514-0-0</ekmi:GlobalKeyID>
<ekmi:KeyClasses>
<ekmi:KeyClass>EHR-DEF</ekmi:KeyClass>
<ekmi:KeyClass>EHR-HOS</ekmi:KeyClass>
<ekmi:KeyClass>EHR-INS</ekmi:KeyClass>
<ekmi:KeyClass>EHR-PAT</ekmi:KeyClass>
</ekmi:KeyClasses>
</ekmi:SymkeyRequest>

4.4 Element <X509EncryptionCertificate>

The <X509EncryptionCertificate> element of type X509EncryptionCertificateType, when specified, contains a PKI X509-compliant digital certificate.

Schema Definition:

<xsd:simpleType name="X509EncryptionCertificateType">

<xsd:restriction base="xsd:base64Binary"/>
</xsd:simpleType>

The <X509EncryptionCertificate> element appears only within a <SymkeyRequest> element. There SHALL be only one <X509EncryptionCertificate> element in a <SymkeyRequest>. The content of the <X509EncryptionCertificate> element is restricted to being base64Binary from the XML Schema Definition types.

Example 1 – A symmetric key request with the X509EncryptionCertificate sent by the client to the server:

<ekmi:SymkeyRequest xmlns:ekmi=”http://docs.oasis-open.org/ekmi/2008/01">
<ekmi:GlobalKeyID>10514-0-0</ekmi:GlobalKeyID>
<ekmi:X509EncryptionCertificate>
MIIDfDCCAmSgAwIBAgIIAe/AvliGc3AwDQYJKoZIhvcNAQELBQAwZzEmMCQGA1UEAxMdU3Ryb25n S2V5IERFTU8gU3Vib3JkaW5hdGUgQ0ExJDAiBgNVBAsTG0ZvciBTdHJvbmdLZXkgREVNTyBVc2Ug T25seTEXMBUGA1UEChMOU3Ryb25nQXV0aCBJbmMwHhcNMDYwNzI1MTcxMDMwWhcNMDcwNzI1MTcy MDMwWjBtMREwDwYKCZImiZPyLGQBARMBMjEZMBcGA1UEAxMQUE9TIFJlZ2lzdGVyIDIyMjEkMCIG A1UECxMbRm9yIFN0cm9uZ0tleSBERU1PIFVzZSBPbmx5MRcwFQYDVQQKEw5TdHJvbmdBdXRoIElu YzCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAyAmxMZhYA8wHJ4UE4b61s51JVWe4Fygj4MCf U7LA3JhpUS4TlX0XFWqrcmltLOiVG7YBFarJFluBFJW2X6q8FuvUprv4V9nJrgiwAPtkiRyIx96n qKXIxkUlQ4idlEg1AZI9dEdf4Y5cqBBCygPYnBoTudglM7R47AjR4nr4ks8CAwEAAaOBqTCBpjAO BgNVHQ8BAf8EBAMCBLAwHQYDVR0OBBYEFOIOrWrZo0LdBRLVncRAwLBqVZpCMB8GA1UdIwQYMBaA FPTYwEHoJG4iFVHRnt2EWxGluAQVMBgGA1UdIAQRMA8wDQYLKwYEAdISg30BBAEwOgYDVR0fBDMw MTAvoC2gK4YpaHR0cDovL2RlbW8uc3Ryb25na2V5Lm9yZy9kZW1vLXN1Yi1jYS5jcmwwDQYJKoZI hvcNAQELBQADggEBACK05PtvZD4WPglOe+EHUiApzFyCdRzf0pFZtxRwG9lR1PZUWUjmwTNfGFsL S6kyoHgUfVa5fpT1EU1mXUB/Lmo3hFGyprZjfmD7DwuBcYgmZHv7yHrmGOMIOXjFTACvHpM0vOce hVx2e4VE0yhBLu/ldH9awGGDp6Bk2XzxqQcs8y6ZzOXZAnPgKQZdjbFKERSsy/d1D8pk5baBk4bd Zh568OcaUrbm9ZReRVTVaY5qiQpkOU+tDrBSj/HIL6GAqegYllkz6KYCy6RVOy6iVVSjHocDqdJr EVOR+ds6xn8mmojdlERrILmuxiLpibPp609SfnDIxNlzLwe5g7ep3lc=
</ekmi:X509EncryptionCertificate>
</ekmi:SymkeyRequest>

4.5 Element <SymkeyRequestID>

The <SymkeyRequestID> element is the unique identifier of a request for a symmetric encryption key within an SKMS. Every request for a symmetric key received by the SKS server MUST be assigned a unique <SymkeyRequestID> as specified in this section.

Schema Definition:

<xsd:simpleType name="SymkeyRequestIDType">

<xsd:restriction base="xsd:string">

<xsd:minLength value="5"/>

<xsd:maxLength value="62"/>

<xsd:pattern value="[0-9]{1,20}-[0-9]{1,20}-[0-9]{1,20}"/>

<xsd:whiteSpace value="collapse"/>

</xsd:restriction>

</xsd:simpleType>

The <SymkeyRequestID> element is of the SymkeyRequestIDType, and is a string identifier consisting of five parts concatenated together:

1. A positive integer identifying the Domain ID. The DomainID identifies the IANA-issued Private Enterprise Number (PEN) as published at http://www.iana.org/assignments/enterprise-numbers and is used by the SKS server to constrain the ownership of objects within the SKMS:

2. A literal hyphen ("-") without surrounding spaces;

3. A positive integer identifying the unique Server ID of the server within the SKMS of the above-mentioned domain, that originally received the request;

4. Another literal hyphen ("-") without surrounding spaces;

5. A positive integer identifying the unique Request ID on the server that received the request;

Combined, the five components of this element make up a unique identifier for a request of a symmetric key within the SKMS. Since all enterprise are expected to use only the PENs assigned to them, and assuming they do, the <SymkeyRequestID> is unique across the internet.

The DomainID in the <SymkeyRequestID> element of a <SymkeyRequest> or <SymkeyResponse> MUST always be a non-zero, positive integer in the range of 0 (zero) to 18446744073709551615 (20-byte ASCII decimal). It will typically contain the PEN of the domain to which the SKMS belongs.

The ServerID part of the <SymkeyRequestID> element of a <SymkeyRequest> or <SymkeyResponse> MUST always be a non-zero, positive integer and be in the range of one (“1”) to 18446744073709551615 (20-byte ASCII decimal). It will typically contain the unique server identifier of the SKS server where the symmetric key request was received.

The RequestID part of the <SymkeyRequestID> element of a <SymkeyRequest> or <SymkeyResponse> MUST always be a non-zero, positive integer and be in the range of one (“1”) to 18446744073709551615 (20-byte ASCII decimal). It will typically contain the unique request identifier on the SKS server where the symmetric key request was received.

While the <SymkeyRequestID> and the <GlobalKeyID> appear identical in structure, they are completely different elements and must be managed by the SKS server separately.

Example 1 – A <SymkeyRequestID> value for the 16,777,215^th symmetric-key request received on the 2^nd SKS server for an enterprise with the PEN 10514, in either a <SymkeyRequest> or a <SymkeyResponse>:

<ekmi:SymkeyRequestID>10514-2-16777215</ekmi:SymkeyRequestID>

Example 2 – The maximum <SymkeyRequestID> value possible (a 62-byte ASCII decimal), in a

<SymkeyRequest> or <SymkeyResponse>:

<ekmi:SymkeyRequestID>
18446744073709551615-18446744073709551615-18446744073709551615
</ekmi:SymkeyRequestID>

4.6 Element <SymkeyResponse>

The <SymkeyResponse> element is the response returned by an SKS server upon being sent a valid <SymkeyRequest> by a client application.

Schema Definition:

<xsd:element name="SymkeyResponse">
<xsd:complexType>

<xsd:choice>

<xsd:sequence>

<xsd:element

name="Symkey"

type="ekmi:SymkeyType"

minOccurs="1"

maxOccurs="unbounded"/>

<xsd:element

name="SymkeyWorkInProgress"

type="ekmi:SymkeyWorkInProgressType"

minOccurs="0"

maxOccurs="unbounded"/>

<xsd:element

name="SymkeyError"

type="ekmi:SymkeyErrorType"

minOccurs="0"

maxOccurs="unbounded"/>

</xsd:sequence>

<xsd:sequence>

<xsd:element

name="SymkeyWorkInProgress"

type="ekmi:SymkeyWorkInProgressType"

minOccurs="1"

maxOccurs="unbounded"/>

<xsd:element

name="SymkeyError"

type="ekmi:SymkeyErrorType"

minOccurs="0"

maxOccurs="unbounded"/>

</xsd:sequence>

<xsd:sequence>

<xsd:element

name="SymkeyError"

type="ekmi:SymkeyErrorType"

minOccurs="1"
maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:choice>
</xsd:complexType>

</xsd:element>

The <SymkeyResponse> element consists of a choice of one of three sequences of children elements:

• A sequence of a required <Symkey> element followed with an optional <SymkeyWorkInProgress> and/or an optional <SymkeyError> element;
• A sequence of a required <SymkeyWorkInProgress> element followed by an optional <SymkeyError> element; or

• A required <SymkeyError> element .

In any <SymkeyResponse> element that consists of the first two choices, all <Symkey> elements MUST precede the first <SymkeyWorkInProgress> element and all <SymkeyWorkInProgress> elements MUST precede the first <SymkeyError> element..

1. <Symkey> [Required]
   
   This element of type SymkeyType, is returned by the SKS server in response to a successful processing of a <SymkeyRequest>. There MAY be more than one <Symkey> element in the <SymkeyResponse> if the client application made a request for multiple symmetric keys.
   
   The <Symkey> element and the SymkeyType are specified in Section 4.7.

2. <SymkeyWorkInProgress> [Required and/or Optional]
   
   This element of type SymkeyWorkInProgressType, contains a response to a pending process of a request for one or more symmetric keys. There MAY be more than one <SymkeyWorkInProgress> element in the <SymkeyResponse> if the client application made a request for multiple symmetric keys and the request resulted in multiple pending responses.
   
   When the <SymkeyResponse> element contains at least one <Symkey> element, the <SymkeyWorkInProgress> is an optional element. When the <SymkeyResponse> element contains only <SymkeyWorkInProgress> and <SymkeyError> elements, the <SymkeyWorkInProgress> is required.
   
   The <SymkeyWorkInProgress> element and the SymkeyWorkInProgressType are specified in Section 4.8.

3. <SymkeyError> [Required and/or Optional]
   
   This element of type SymkeyErrorType, contains a response to a failed attempt in processing a request for one or more symmetric keys. There MAY be more than one <SymkeyError> element in the <SymkeyResponse> if the client application made a request for multiple symmetric keys and the request resulted in multiple errors.
   
   When the <SymkeyResponse> element contains at least one <Symkey> or <SymkeyWorkInProgress> element, the <SymkeyError> is an optional element; otherwise the <SymkeyError> is required.
   
   The <SymkeyError> element and SymkeyErrorType are specified in Section 4.9.

Some high-level examples of the <SymkeyResponse> element are as follows:

Example 1 – A response with a single symmetric key:

<ekmi:SymkeyResponse
xmlns:ekmi=”http://docs.oasis-open.org/ekmi/2008/01">
<ekmi:Symkey>.....</ekmi:Symkey>
</ekmi:SymkeyResponse>

Example 2 – A response with three symmetric keys:

<ekmi:SymkeyResponse
xmlns:ekmi=”http://docs.oasis-open.org/ekmi/2008/01">
<ekmi:Symkey>.....</ekmi:Symkey>
<ekmi:Symkey>.....</ekmi:Symkey>
<ekmi:Symkey>.....</ekmi:Symkey>
</ekmi:SymkeyResponse>

Example 3 – A response with a single work-in-progress element:

<ekmi:SymkeyResponse
xmlns:ekmi=”http://docs.oasis-open.org/ekmi/2008/01">
<ekmi:SymkeyWorkInProgress>.....</ekmi:SymkeyWorkInProgress>
</ekmi:SymkeyResponse>

Example 4 – A response with multiple work-in-progress elements:

<ekmi:SymkeyResponse
xmlns:ekmi=”http://docs.oasis-open.org/ekmi/2008/01">
<ekmi:SymkeyWorkInProgress>.....</ekmi:SymkeyWorkInProgress>
<ekmi:SymkeyWorkInProgress>.....</ekmi:SymkeyWorkInProgress>
<ekmi:SymkeyWorkInProgress>.....</ekmi:SymkeyWorkInProgress>
</ekmi:SymkeyResponse>

Example 5 – A response with multiple symmetric-key and work-in-progress elements:

<ekmi:SymkeyResponse
xmlns:ekmi=”http://docs.oasis-open.org/ekmi/2008/01">
<ekmi:Symkey>.....</ekmi:Symkey>
<ekmi:Symkey>.....</ekmi:Symkey>
<ekmi:Symkey>.....</ekmi:Symkey>
<ekmi:SymkeyWorkInProgress>.....</ekmi:SymkeyWorkInProgress>
<ekmi:SymkeyWorkInProgress>.....</ekmi:SymkeyWorkInProgress>
<ekmi:SymkeyWorkInProgress>.....</ekmi:SymkeyWorkInProgress>
</ekmi:SymkeyResponse>

Example 6 – A response with an error:

<ekmi:SymkeyResponse
xmlns:ekmi=”http://docs.oasis-open.org/ekmi/2008/01">
<ekmi:SymkeyError>.....</ekmi:SymkeyError>
</ekmi:SymkeyResponse>

Example 7 – A response with multiple errors:

<ekmi:SymkeyResponse
xmlns:ekmi=”http://docs.oasis-open.org/ekmi/2008/01">
<ekmi:SymkeyError>.....</ekmi:SymkeyError>
<ekmi:SymkeyError>.....</ekmi:SymkeyError>
</ekmi:SymkeyResponse>

Example 8 – A response with one symmetric key and one error:

<ekmi:SymkeyResponse
xmlns:ekmi=”http://docs.oasis-open.org/ekmi/2008/01">
<ekmi:Symkey>.....</ekmi:Symkey>
<ekmi:SymkeyError>.....</ekmi:SymkeyError>
</ekmi:SymkeyResponse>

Example 9 – A response with multiple symmetric keys and multiple errors:

<ekmi:SymkeyResponse
xmlns:ekmi=”http://docs.oasis-open.org/ekmi/2008/01">
<ekmi:Symkey>.....</ekmi:Symkey>
<ekmi:Symkey>.....</ekmi:Symkey>
<ekmi:Symkey>.....</ekmi:Symkey>
<ekmi:SymkeyError>.....</ekmi:SymkeyError>
<ekmi:SymkeyError>.....</ekmi:SymkeyError>
</ekmi:SymkeyResponse>

Example 10 – A response with multiple symmetric keys, multiple work-in-progress and multiple error elements:

<ekmi:SymkeyResponse
xmlns:ekmi=”http://docs.oasis-open.org/ekmi/2008/01">
<ekmi:Symkey>.....</ekmi:Symkey>
<ekmi:Symkey>.....</ekmi:Symkey>
<ekmi:Symkey>.....</ekmi:Symkey>
<ekmi:SymkeyWorkInProgress>.....</ekmi:SymkeyWorkInProgress>
<ekmi:SymkeyWorkInProgress>.....</ekmi:SymkeyWorkInProgress>
<ekmi:SymkeyWorkInProgress>.....</ekmi:SymkeyWorkInProgress>
<ekmi:SymkeyError>.....</ekmi:SymkeyError>
<ekmi:SymkeyError>.....</ekmi:SymkeyError>
</ekmi:SymkeyResponse>

4.7 Element <Symkey>

The <Symkey> element is the raison d'etre of the SKSML protocol. The element of type SymkeyType, contains the symmetric key returned by the SKS server, in response to a successful processing of a <SymkeyRequest> from a client application.

Schema Definition:

<xsd:complexType name="SymkeyType">
<xsd:sequence>
<xsd:element name="SymkeyRequestID" type="ekmi:SymkeyRequestID"/>
<xsd:element name="GlobalKeyID" type="ekmi:GlobalKeyIDType"/>
<xsd:element name="KeyUsePolicy" type="ekmi:KeyUsePolicyType"/>
<xsd:element name="EncryptionMethod" type="xenc:EncryptionMethodType"/>
<xsd:element ref="xenc:CipherData"/>
</xsd:sequence>
</xsd:complexType>

When a request for a symmetric key is successful, there MUST be at least one <Symkey> element in a <SymkeyResponse> element. There MAY be more than one <Symkey> element in the response if the client application made a request for multiple symmetric keys and the SKS server processed the request successfully.

In the event an SKS server receives the request asynchronously, the response SHALL contain a <SymkeyWorkInProgress> element implying that the request is being processed and is pending completion. The <SymkeyError> element is specified in Section 4.7.

In the event of an error in processing the request, there SHALL be no <Symkey> element in the response; there SHALL be a <SymkeyError> element, instead. The <SymkeyError> element is specified in Section 4.9.

The <Symkey> element consists of a sequence of the following child elements:

1. <SymkeyRequestID> [Required]
   
   This element of type SymkeyRequestIDType identifies the unique identifier of the request made by the client within an SKMS. There SHALL be only one <SymkeyRequestID> within a <Symkey> element.
   
   The <SymkeyRequestID> element and the SymkeyRequestIDType are specified in Section 4.5.

2. <GlobalKeyID> [Required]
   
   This element of type GlobalKeyIDType identifies the unique identifier of the symmetric key within an SKMS. There SHALL be only one <GlobalKeyID> within a <Symkey> element.
   
   The <GlobalKeyID> element and the GlobalKeyIDType are specified in Section 4.2.

3. <KeyUsePolicy> [Required]
   
   This element of type KeyUsePolicyType, defines how the symmetric key in this <Symkey> element may be used by applications. There SHALL be only one <KeyUsePolicy> element within a <Symkey> element.
   
   The <KeyUsePolicy> element and KeyUsePolicyType are specified in Section 4.10.

4. <EncryptionMethod> [Required]
   
   This element of type EncryptionMethodType from [XMLEncryption] describes how the symmetric key in this <Symkey> element is encrypted for transport between the SKS Server and the client application.
   
   The <EncryptionMethod> MUST specify one of the following two transport algorithms in the Algorithm attribute of the element:
   
   - http://www.w3.org/2001/04/xmlenc#rsa-1_5
   - http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p

5. <CipherData> [Required]
   
   This element of CipherDataType from [XMLEncryption] contains the encrypted symmetric-key. As specified in [XMLEncryption], the content of this element is Base-64 encoded and is of the XML Schema base64Binary type.

Some high-level examples of the <Symkey> element are as follows. Details about the <KeyUsePolicy> element have been elided for brevity:

Example 1 – A response with a symmetric key:

<ekmi:SymkeyResponse
xmlns:ekmi=”http://docs.oasis-open.org/ekmi/2008/01">
<ekmi:Symkey>
<ekmi:SymkeyRequestID>10514-1-7455</ekmi:SymkeyRequestID>
<ekmi:GlobalKeyID>10514-1-235</ekmi:GlobalKeyID>
<ekmi:KeyUsePolicy>.....</ekmi:KeyUsePolicy>
<ekmi:EncryptionMethod
Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-1_5"/>
<xenc:CipherData>
<xenc:CipherValue>
E9zWB/y93hVSzeTLiDcQoDxmlNxTux+SffMNwCJmt1dIqzQHBnpdQ8
1g6DKdkCFjJMhQhywCx9sfYjv9h5FDqUiQXGOca8EU871zBoXBjDxj
fg1pU8tGFbpWZcd/ATpJD/UJow/qimxi8+huUYJMtaGH= </xenc:CipherValue>
</xenc:CipherData>
</ekmi:Symkey>
</ekmi:SymkeyResponse>

Example 2 – A response with multiple symmetric keys:

<ekmi:SymkeyResponse
xmlns:ekmi=”http://docs.oasis-open.org/ekmi/2008/01">
<ekmi:Symkey>
<ekmi:SymkeyRequestID>10514-1-12455</ekmi:SymkeyRequestID>
<ekmi:GlobalKeyID>10514-1-235</ekmi:GlobalKeyID>
<ekmi:KeyUsePolicy>.....</ekmi:KeyUsePolicy>
<ekmi:EncryptionMethod
Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p"/>
<xenc:CipherData>
<xenc:CipherValue>
E9zWB/y93hVSzeTLiDcQoDxmlNxTux+SffMNwCJmt1dIqzQHBnpdQ8
1g6DKdkCFjJMhQhywCx9sfYjv9h5FDqUiQXGOca8EU871zBoXBjDxj
fg1pU8tGFbpWZcd/ATpJD/UJow/qimxi8+huUYJMtaGH= </xenc:CipherValue>
</xenc:CipherData>
</ekmi:Symkey>
<ekmi:Symkey>
<ekmi:SymkeyRequestID>10514-1-12467</ekmi:SymkeyRequestID>
<ekmi:GlobalKeyID>10514-1-236</ekmi:GlobalKeyID>
<ekmi:KeyUsePolicy>.....</ekmi:KeyUsePolicy>
<ekmi:EncryptionMethod
Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p"/>
<xenc:CipherData>
<xenc:CipherValue>
Qbg65cy93hVSzeTLiDcQoDxmlNxTux+SffMNwCJmt1dIqzQHBnpdQ8
7k6DKdkCFjJMhQhywCx9sfYjv9h5FDqUiQXGOca8EU871zBoXBjDxj
uyecU8tGFbpWZcd/ATpJD/UJow/qimxi8+huUYJMtaGH=
</xenc:CipherValue>
</xenc:CipherData>
</ekmi:Symkey>
</ekmi:SymkeyResponse>

4.8 Element <SymkeyWorkInProgress>

The <SymkeyWorkInProgress> element is returned in a <SymkeyResponse> when a client either makes an asynchronous request for a symmetric-key from an SKS server.

The <SymkeyWorkInProgress> element of type SymkeyWorkInProgressType, contains a unique request ID returned by the SKS server, in response to receiving a <SymkeyRequest> from a client application.

Schema Definition:

<xsd:complexType name="SymkeyWorkInProgressType">
<xsd:sequence>

<xsd:element

name="RequestedGlobalKeyID"

type="ekmi:GlobalKeyIDType"

minOccurs=”1”

maxOccurs=”1”>

</xsd:element>

<xsd:element

name="RequestedKeyClass"

type="ekmi:KeyClassType"

minOccurs="0"

maxOccurs=”1”>

</xsd:element>

<xsd:element

name="SymkeyRequestID"

type="ekmi:SymkeyRequestIDType"

minOccurs=”1”

maxOccurs=”1”>

</xsd:element>

<xsd:element

name="RequestCheckInterval"

type="ekmi:RequestCheckIntervalType"

minOccurs="1"

maxOccurs="1">

</xsd:element>

</xsd:sequence>

</xsd:complexType>

Schema Definition:

<xsd:simpleType name="RequestCheckIntervalType">

<xsd:restriction base="xsd:positiveInteger">

<xsd:minInclusive value="60"/>

<xsd:maxInclusive value="86400"/>

</xsd:restriction>

</xsd:simpleType>

The <SymkeyWorkInProgress> element consists of a sequence of the following child elements:

1. <RequestedGlobalKeyID> [Required]
   
   This element of type GlobalKeyIDType identifies the identifier of the requested symmetric key within an SKMS. There SHALL be only one <RequestedGlobalKeyID> within a <SymkeyWorkInProgress> element.
   
   The GlobalKeyIDType is specified in Section 4.2.

2. <RequestedKeyClass> [Optional]
   
   This element of type KeyClassType, identifies the class of the symmetric-key that was requested, if any. If present, there SHALL be only one <RequestedKeyClass> element within a <SymkeyWorkInProgress> element.
   
   The KeyClassType is specified in Section 4.3.

3. <SymkeyRequestID> [Required]
   
   This element of type SymkeyRequestIDType identifies the unique request identifier returned by the SKS server. This request identifier may be used by the client to query the SKS server for an update on the request at a future time.
   
   The <SymkeyRequestID> element and SymkeyRequestIDType are specified in Section 4.5.

4. <RequestCheckInterval> [Required]
   
   This element of RequestCheckIntervalType defines the number of seconds a client MUST wait after it has received a < SymkeyWorkInProgress> response before it may query the SKS server for an update on the request. The value also indicates that the requesting client MUST wait the same interval between update queries in the event it continues to get a <SymkeyWorkInProgress> response from the server.

   The RequestCheckIntervalType is a positiveInteger type from the XML Schema Definition and restricts the minimum value to be 60 seconds, and the maximum value to be 604,800 seconds (1-week).

Some high-level examples of the <SymkeyWorkInProgress> element are as follows.:

Example 1 – A response with a work-in-progress element and a check-request frequency interval of 5-minutes:

<ekmi:SymkeyResponse xmlns:ekmi=”http://docs.oasis-open.org/ekmi/2008/01">
<ekmi:SymkeyWorkInProgress>
<ekmi:RequestedGlobalKeyID>10514-1-235</ekmi:RequestedGlobalKeyID>
<ekmi:SymkeyRequestID>10514-1-17964</ekmi:SymkeyRequestID>
<ekmi:RequestCheckInterval>300</ekmi:RequestCheckInterval>
</ekmi:SymkeyWorkInProgress>
</ekmi:SymkeyResponse>

Example 2 – A response with a work-in-progress element and a check-request frequency interval of 30-minutes:

<ekmi:SymkeyResponse xmlns:ekmi=”http://docs.oasis-open.org/ekmi/2008/01">
<ekmi:SymkeyWorkInProgress>
<ekmi:RequestedGlobalKeyID>10514-0-0</ekmi:RequestedGlobalKeyID>
<ekmi:RequestedKeyClass>HR-Class</ekmi:RequestedKeyClass>
<ekmi:SymkeyRequestID>10514-3-4955</ekmi:SymkeyRequestID>
<ekmi:RequestCheckInterval>1800</ekmi:RequestCheckInterval>
</ekmi:SymkeyWorkInProgress>
</ekmi:SymkeyResponse>

4.9 Element <SymkeyError>

The <SymkeyError> element of type SymkeyErrorType, contains the error returned by the SKS server, in response to a failure in processing of a <SymkeyRequest> from a client application.

Schema Definition:

<xsd:complexType name="SymkeyErrorType">
<xsd:sequence>

<xsd:element

name="SymkeyRequestID" type="ekmi:SymkeyRequestIDType">

<xsd:element

name="RequestedGlobalKeyID" type="ekmi:GlobalKeyIDType"/>

<xsd:element

name="RequestedKeyClass"

type="ekmi:KeyClassType"

minOccurs="0"/>

<xsd:element name="ErrorCode">

<xsd:simpleType>

<xsd:restriction base="xsd:string">

<xsd:maxLength value="255"/>

</xsd:restriction>

</xsd:simpleType>

</xsd:element>

<xsd:element name="ErrorMessage">

<xsd:simpleType>

<xsd:restriction base="xsd:string">

<xsd:maxLength value="1024"/>

</xsd:restriction>

</xsd:simpleType>

</xsd:element>

</xsd:sequence>

</xsd:complexType>

There MAY be more than one <SymkeyError> element in the response if the client application made a request for multiple symmetric keys and the SKS server failed in processing the request for more than one symmetric key.

The <SymkeyError> element consists of a sequence of the following child elements:

1. <SymkeyRequestID> [Required]
   
   This element of type SymkeyRequestIDType identifies the unique identifier of the request made by the client within an SKMS. There SHALL be only one <SymkeyRequestID> within a <SymkeyError> element.
   
   The <SymkeyRequestID> element and the SymkeyRequestIDType are specified in Section 4.5.

2. <RequestedGlobalKeyID> [Required]
   
   This element of type GlobalKeyIDType identifies the unique identifier of the symmetric key requested by the client application. There SHALL be only one <RequestedGlobalKeyID> within a <SymkeyError> element.
   
   The GlobalKeyIDType is specified in Section 4.2.

3. <RequestedKeyClass> [Optional]
   
   This element of type KeyClassType identifies the key-class of the symmetric key requested by the client application. If the <RequestedKeyClass> element is not embedded in the <SymkeyError> element, this implies that the requested symmetric key was for the default key-class of the SKMS.
   
   The KeyClassType is specified in Section 4.3.

4. <ErrorCode> [Required]
   
   This element of type String identifies a mnemonic code identifying the error the SKS Server experienced in processing the client's symmetric key request.
   
   The <ErrorCode> element SHALL return one of the codes identified in Appendix C of this specification.

5. <ErrorMessage> [Required]
   
   This element of type String identifies a localized message describing the error the SKS Server experienced in processing the client's symmetric key request.
   
   The <ErrorMessage> element SHALL return the appropriate localized version of the message corresponding to the <ErrorCode> element from Appendix C of this specification.

Some high-level examples of the <SymkeyError> element are as follows.

Example 1 – An error within a response:

Example 2 – Multiple errors within a response:

4.10 Element <KeyUsePolicy>

The <KeyUsePolicy> element defines rules that conforming implementations of the SKCL MUST adhere to when using the symmetric key sent by the SKS Server. It is an integral part of the <Symkey> element.

Schema Definition:

<xsd:complexType name="KeyUsePolicyType" mixed="true">

<xsd:sequence>
<xsd:element name="KeyUsePolicyID" type="ekmi:TwoPartIDType"/>

<xsd:element name="PolicyName">

<xsd:simpleType>

<xsd:restriction base="xsd:string">

<xsd:maxLength value="255"/>

</xsd:restriction>

</xsd:simpleType>

</xsd:element>

<xsd:element name="KeyClass" type="ekmi:KeyClassType"/>

<xsd:element name="KeyAlgorithm" type="ekmi:EncryptionAlgorithmType"/>

<xsd:element name="KeySize" type="ekmi:KeySizeType"/>

<xsd:element name="Status" type="ekmi:StatusType"/>

<xsd:element name="Permissions" type="ekmi:PermissionsType"/>

</xsd:sequence>

</xsd:complexType>

The <KeyUsePolicy> element is of the KeyUsePolicyType and consists of the following child elements:

1. <KeyUsePolicyID> [Required]
   
   The < KeyUsePolicyID> element, of type TwoPartIDType , identifies the unique policy object within the SKMS. There SHALL be only one <KeyUsePolicyID> element within a <KeyUsePolicy> element.
   
   The TwoPartIDType is specified in Section 4.11.

2. <PolicyName> [Required]
   
   The <PolicyName> element, of type XSD String,with a maximum length of 255 characters, identifies a unique name given to this <KeyUsePolicy>. There SHALL be only one <PolicyName> element within a <KeyUsePolicy> element.

3. <KeyClass> [Required]
   
   The <KeyClass> element ,of type KeyClassType , identifies a key-class assigned to this <KeyUsePolicy>. There SHALL be only one <KeyUsePolicyID> element within a <KeyUsePolicy> element.
   
   The KeyClassType is specified in Section 4.3.

4. <KeyAlgorithm> [Required]
   
   The <KeyAlgorithm> element , of type EncryptionAlgorithmType , identifies encryption algorithm to be used by applications when using this symmetric key. There SHALL be only one <KeyAlgorithm> element within a <KeyUsePolicy> element.
   
   The <KeyAlgorithm> element is specified in Section 4.12.

5. <KeySize> [Required]
   
   The <KeySize> element , of type KeySizeType, defines the size of the symmetric key, in bits (binary digits). There SHALL be only one <KeySize> element within a <KeyUsePolicy> element.
   
   Note: It is possible to determine the size of a symmetric key in an SKCL implementation without having to send the size in the response. So, why include it? It is our belief that while network bandwidth and compute performance of devices are increasing steadily, encryption is desired in many small and portable devices. Consequently, it will speed up applications in cryptographic processing if they do not have to determine the size of each key they use. While “protocol purity” demands that implementation issues do not show up in protocol design, we believe it is justified in this case.
   
   The KeySizeType is specified in Section 4.13.

6. <Status> [Required]
   
   The <Status> element, of type StatusType, identifies the current status of the symmetric key. There SHALL be only one <Status> element within a <KeyUsePolicy> element.
   
   The StatusType is specified in Section 4.14.

7. <Permissions> [Required]
   
   The <Permissions> element, of type PermissionsType, defines what is permissible to client applications with the symmetric key this element is associated with. It is the responsibility of the conforming SKCL implementation to enforce these rules.
   
   An important distinction of this element – unlike most access control rules – is that the absence of sub-elements in the <Permissions> element implies that all permissions are allowed. The presence of sub-elements in this element provide rules to the SKCL about what actions are permitted.
   
   There SHALL be only one <Permissions> element in a <KeyUsePolicy> element.
   
   The PermissionsType is specified in Section 4.15.

Some examples of the <KeyUsePolicy> element are as follows.

Example 1 – A <KeyUsePolicy> with some permission restrictions:

Example 2 – A <KeyUsePolicy> with no restrictions on the key:

<ekmi:KeyUsePolicy>
<ekmi:KeyUsePolicyID>10514-2</ekmi:KeyUsePolicyID>
<ekmi:PolicyName>Laptop KeyUsePolicy</ekmi:PolicyName>
<ekmi:KeyClass>HR-Class</ekmi:KeyClass>
<ekmi:KeyAlgorithm>
http://www.w3.org/2001/04/xmlenc#aes256-cbc
</ekmi:KeyAlgorithm>
<ekmi:KeySize>256</ekmi:KeySize>
<ekmi:Status>Active</ekmi:Status>
<ekmi:Permissions>
<ekmi:PermittedApplications ekmi:any="true" xsi:nil="true"/>
<ekmi:PermittedDates ekmi:any="true" xsi:nil="true"/>
<ekmi:PermittedDays ekmi:any="true" xsi:nil="true"/>
<ekmi:PermittedDuration ekmi:any="true" xsi:nil="true"/>
<ekmi:PermittedLevels ekmi:any="true" xsi:nil="true"/>
<ekmi:PermittedLocations ekmi:any="true" xsi:nil="true"/>
<ekmi:PermittedNumberOfTransactions ekmi:any="true" xsi:nil="true"/>
<ekmi:PermittedTimes ekmi:any="true" xsi:nil="true"/>
<ekmi:PermittedUses ekmi:any="true" xsi:nil="true"/>
</ekmi:Permissions>
</ekmi:KeyUsePolicy>

4.11 Type TwoPartIDType

The TwoPartIDType is used to create identifiers for many elements within the SKSML. It is a simple concatenation of two integers with a hyphen between them (“-”) to create an XML Schema String type.

The TwoPartIDType has a minimum length of three (3) characters, and a maximum length of 41 characters.