Entrust Position Paper on XKMS

Workshop on XML Key Management Services

Redwood City, CA - July 19, 2001

Entrust welcomes the opportunity to participate in and contribute to the standardization of XML-based key management services. We hope our extensive experience in all aspects of PKI and key management and more recent participation in related XML standards development serve both as evidence of our commitment to, and ability to contribute to, XML-based interoperable security standards.

Below, we outline our goals and expectations for the XKMS workshop and indicate where we feel that we can best contribute, both to this meeting, and within the anticipated standardization effort.


Entrust has extensive experience in key managenment technologies and products, and participation in standardization activities around these technologies. Entrust/PKI is in its 6th generation with over 1000 customers to its credit.  Entrust has consistently participated in ISO/ITU, IETF, ANSI, WAP and W3C standards efforts.  These achievements are expanded upon below.

Entrust is proud of its contributions in the area of key management standards.  We have consistently been lead contributors within the IETF PKIX working group, co-editing the Certificate Management Protocol (CMP) standard in addition to several other standards including the Online Certificate Status Protocol (OCSP).  Both standards are ASN.1-based precursors to the XML-based key management services. In addition, Entrust contributes as the lead editor to the X.509 standard.

Within the field of XML security, Entrust is also an active contributor.  For messaging standards, Entrust actively contributes to the joint IETF-W3C XML Digital Signature working group through the co-authoring of the standard proposal.  In addition, Entrust is also a co-author on the proposal from the W3C XML Encryption working group. This experience and expertise is relevant to the XKMS iniative because of the dependence of XKMS messaging on these core standards.

Entrust also actively participates within the Security Assertions Markup Language (SAML) initiative within OASIS. In particular, Entrust is a member of the OASIS Security Services Technical Committee working on SAML standardization and co-chair of the Protocols and Core Assertions sub-groups contained within that Committee. Entrust also plans on active participation within the proposed OASIS Technical Committee on XML Access Control Markup Language (XACML).

In addition to involvement in the standardization process, we also have extensive experience in the product implementation of and interoperability testing for these standards. Entrust's complete line of Internet Security Solutions conform to the X.509/PKIX standards for key mangement. The Entrust/Java toolkit currently supports XML Signature and will soon include support for XML Encryption. We also have a reference implementation of an earlier version of an XACML proposal, as well as an online XKMS reference implementation (  Work on SAML is under development. Finally, Entrust/DeviceConnector is an XML-based key management protocol, designed specifically for card manufacturers, supporting an XKMS-like protocol. This product will evolve to support XKMS functionality.

Our Goals/Needs in the field of XML Key Management Services

The Web Services model for business transactions enables applications to dynamically "find and bind" to distributed components over the Internet in order to achieve some business transaction.  The possibly high dollar value and sensitive nature of these transactions requires a comprehensive security infrastructure.  We believe that XML Key Management Services are fundamental to this security infrastructure as they offer a syntax and protocol to simplify application and web service integration in support of secure business transactions.  Therefore, we desire a standardized and interoperable protocol the supports key management in a web services framework.

Ideally, this standardization process would be completed in a timely manner and elicit contributions from all relevant parties.  This includes the establishment of liaisons with related efforts such as SAML and XML Signature and Encryption.  The process for contributing to this effort should be open.

The standard output from the working group should follow the best practices of similar protocols ensuring secure operation and be open to ensure the satisfaction of requirements from all participating areas.

With respect to specific technical requirements of the XKMS standard, Appendix A identifies several features not currently addressed in the XKMS technical note that are required to satisfy the basic needs of batch certificate issuance systems, e.g. a Card Manufacturing System registration system.

Workshop Expectations

Entrust sees a strong need for the functionalilty described in the XKMS Technical Note.  Given its broad support, we would like for the standardization of an XML Key Management Service to begin as soon as possible, as well as be completed expediciously. Therefore, we have several ambitious goals for this workshop:

Entrust Contributions

As indicated above, a key contribution from Entrust will be its experience in the area of internet standards, implementation of those standards, and its conformance to best-practice security principles.  In particular, we hope that our co-authoring of the PKIX-CMP standard serves as a model for the work on the XKMS protocol. It is our belief that this will result in a secure, interoperable XKMS standard that is reflective of the requirements of our customers.

More tangible contributions include the identification of requirements of card manufacturers and how XKMS may be modified to allow for registration of their device certificates. Further detail on these requirements is given in Appendix A.  Entrust offers to author a document that specifies the use of XKMS in a card manufacturing environment, for progression in the anticipated XKMS working group.

Appendix A: Using XKMS to Satisfy the Requirements of a Card Manufacturing System (CMS)

It is likely that other areas will identify requirements that are not completed satisfied by the current XKMS technical note.  Working group consensus will determine which requirements should be met by the core XKMS standard document and which would be more appropriately met in a companion document. Below, we highlight a small number of requirements identified through collaboration with a number of card manufacturers. These requirements may be relevant within other areas as well.  Specifically, we identify the following key management requirements:
  1. Support for the suspension and resumption of assertions;
  2. Support for bulk assertion requests;
  3. Support for assertion request extensions.
Suspension and resumption support may be supported through modifications to the schema that clearly distinguish these operations from the current limited set of registration, revocation and recovery.

Bulk assertion requests require some additional functionality for both a registration request and response.  As part of a request, it is desireable for a single request to support the registration of multiple <Prototypes>.  We propose a small number of changes to the existing schema, to support more than one <Prototype> element. This may be signed within XKMS or alternatively, using a SOAP digital signature. As part of a registration response, observe that if a large number of requests are simultaneously registered, then a client may not want to maintain an open, synchronous connection in order to receive a response (e.g. in case the entire response may take hours to produce).  In this situation, it is suggested that XKMS support the return of an initial "pending" response.  This allows the client to close their initial connection, and obtain the response at a later time.

It is anticipated that additional elements may need to be included as part of a request in order to satisfy the requirements of a particular area.  With regard to card manufacturing, one example is the inclusion of ERP (Enterprise Resource Planning) data as part of the request, that is simply returned by the server in the response.  More generally, in the case of a certificate request, it may be desireable to include some X.509 extensions as part of the request.

Valid HTML 4.01!