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 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 (http://188.8.131.52/xkms/index.htm). 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.
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.
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.
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.