DSS Version 1.0 Becomes an OASIS Standard

New Digital Signature Services (DSS) OASIS Standard Assures Authenticity of Data for Web Services

Boston, MA, USA. June 07, 2007.

OASIS, the international standards consortium, today announced that its members have approved Digital Signature Services (DSS) version 1.0 as an OASIS Standard, a status that signifies the highest level of ratification. DSS defines an XML interface to process digital signatures for Web services and other applications, enabling the sharing of digital signature creation, verification and other associated services, without complex client software and configuration.

"DSS makes it easy to use digital signatures because it lets companies control their signature applications on an organizational basis through a network-based server," said Juan Cruellas of Centre d'aplicacions avanades d'Internet (CANET), co-chair of the OASIS DSS Technical Committee. "Instead of being managed individually, signing keys are maintained on a secure server with controls that minimize the risk of compromise. Signatures can still be created by authorized individuals, but instead of requiring specialized signing equipment for each person, DSS allows organizations to use their existing authentication mechanisms, such as passwords, two factors, biometrics, etc."

DSS describes two XML-based request/response protocols, one for signatures and a second for verification. Using these protocols, a client can send documents to a server and receive back a signature on the documents; or send documents and a signature to a server and receive back an answer on whether the signature verifies the documents.

"A DSS signature secures an organization's documents efficiently and effectively while maintaining accountability down to the individual level," said Nick Pope of Thales eSecurity Ltd., co-chair of the OASIS DSS Technical Committee. "What's more, DSS allows sensitive signing keys to be protected by using tamper-proof signing devices and by locating the server in a room with controlled access. Costs are reduced with DSS, because security can be highly localized."

DSS supports a range of signature formats including XML and CMS. It is designed around a core set of elements and procedures which can be profiled to support specific uses such as time-stamping (including XML structured time-stamps), corporate entity seals, electronic post marks and code signing.

The OASIS DSS Technical Committee worked closely with the Universal Postal Union, an agency of the United Nations, to facilitate the use of DSS within its Electronic Post Mark system (UPU EPM).

"Deploying support for digital signatures can be extremely challenging, especially for large companies. The task of allocating and certifying user keys can be burdensome and difficult to secure," said OASIS president and CEO, Patrick Gannon. "The DSS OASIS Standard presents an approach to digital signing which significantly reduces these obstacles. The added services enabled by this standard are meeting global needs, and the Universal Postal Union is a good example."

The DSS OASIS Standard was developed by representatives of the American Bar Association, Austria Federal Chancellery, BEA Systems, CATCert-Agencia Catalana de Certificacio, IBM, Nokia, Universal Postal Union, and others. The DSS OASIS Standard and the archives of the OASIS DSS Technical Committee work are publicly accessible. OASIS hosts the dss-dev mailing list for exchanging information on implementing the standard.

Additional Information

DSS 1.0 OASIS Standard
http://www.oasis-open.org/specs/index.php#dssv1.0

OASIS DSS Technical Committee
http://www.oasis-open.org/committees/dss/

DSS FAQ
http://www.oasis-open.org/committees/dss/faq.php

DSS Overview

Extract, adapted and corrected from the non-normative document section 'DSS Overview' in Digital Signature Service Core Protocols, Elements, and Bindings Version 1.0 OASIS Standard:

This specification describes two XML-based request/response protocols: a signing protocol and a verifying protocol. Through these protocols a client can send documents (or document hashes) to a server and receive back a signature on the documents; or send documents (or document hashes) and a signature to a server, and receive back an answer on whether the signature verifies the documents.

These operations could be useful in a variety of contexts. For example, they could allow clients to access a single corporate key for signing press releases, with centralized access control, auditing, and archiving of signature requests. They could also allow clients to create and verify signatures without needing complex client software and configuration.

The signing and verifying protocols are chiefly designed to support the creation and verification of XML signatures [XML-Signature Syntax and Processing, W3C Recommendation 12-February-2002], XML timestamps (see section 5.1), binary timestamps [Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP) — IETF RFC 3161] and CMS signatures [Cryptographic Message Syntax (CMS) — IETF RFC 3852]. These protocols may also be extensible to other types of signatures and timestamps, such as PGP signatures [OpenPGP Message Format — IETF RFC 2440].

It is expected that the signing and verifying protocols will be profiled to meet many different application scenarios. In anticipation of this, these protocols have only a minimal set of required elements, which deal with transferring "input documents" and signatures back and forth between client and server. The input documents to be signed or verified can be transferred in their entirety, or the client can hash the documents themselves and only send the hash values, to save bandwidth and protect the confidentiality of the document content.

All functionality besides transferring input documents and signatures is relegated to a framework of "optional inputs" and "optional outputs". This document defines a number of optional inputs and outputs. Profiles of these protocols can pick and choose which optional inputs and outputs to support, and can introduce their own optional inputs and outputs when they need functionality not anticipated by this specification.

Examples of optional inputs to the signing protocol include: what type of signature to produce, which key to sign with, who the signature is intended for, and what signed and unsigned properties to place in the signature. Examples of optional inputs to the verifying protocol include: the time for which the client would like to know the signature's validity status, additional validation data necessary to verify the signature (such as certificates and CRLs), and requests for the server to return information such as the signer's name or the signing time.

The signing and verifying protocol messages must be transferred over some underlying protocol(s) which provide message transport and security. A binding specifies how to use the signing and verifying protocols with some underlying protocol, such as HTTP POST or TLS. Section 6 provides an initial set of bindings.

In addition to defining the signing and verifying protocols, this specification defines two XML elements that are related to these protocols. First, an XML timestamp element is defined in section 5.1. The signing and verifying protocols can be used to create and verify both XML and binary timestamps; a profile for doing so is defined in XML Timestamping Profile of the OASIS Digital Signature Services Version 1.0. Second, a RequesterIdentity element is defined in section 5.2. This element can be used as a signature property in an XML signature, to give the name of the end-user who requested the signature...

About OASIS

OASIS (Organization for the Advancement of Structured Information Standards) is a not-for-profit, international consortium that drives the development, convergence, and adoption of e-business standards. Members themselves set the OASIS technical agenda, using a lightweight, open process expressly designed to promote industry consensus and unite disparate efforts. The consortium produces open standards for Web services, security, e-business, and standardization efforts in the public sector and for application-specific markets. Founded in 1993, OASIS has more than 5,000 participants representing over 600 organizations and individual members in 100 countries.

Press Contact

Carol Geyer
Director of Communications
OASIS
Email: carol.geyer@oasis-open.org
Tel: +1.978.667.5115 x209 (office)
Tel: +1.941.284.0403 (mobile)

Prepared by Robin Cover for The XML Cover Pages archive. See also Security, Privacy, and Personalization.

SEARCH Advanced Search ABOUT Site Map CP RSS Channel Contact Us Sponsoring CP About Our Sponsors NEWS Cover Stories Articles & Papers Press Releases CORE STANDARDS XML SGML Schemas XSL/XSLT/XPath XLink XML Query CSS SVG TECHNOLOGY REPORTS XML Applications General Apps Government Apps Academic Apps EVENTS LIBRARY Introductions FAQs Bibliography Technology and Society Semantics Tech Topics Software Related Standards Historic	DSS Version 1.0 Becomes an OASIS Standard New Digital Signature Services (DSS) OASIS Standard Assures Authenticity of Data for Web Services Boston, MA, USA. June 07, 2007. OASIS, the international standards consortium, today announced that its members have approved Digital Signature Services (DSS) version 1.0 as an OASIS Standard, a status that signifies the highest level of ratification. DSS defines an XML interface to process digital signatures for Web services and other applications, enabling the sharing of digital signature creation, verification and other associated services, without complex client software and configuration. "DSS makes it easy to use digital signatures because it lets companies control their signature applications on an organizational basis through a network-based server," said Juan Cruellas of Centre d'aplicacions avanades d'Internet (CANET), co-chair of the OASIS DSS Technical Committee. "Instead of being managed individually, signing keys are maintained on a secure server with controls that minimize the risk of compromise. Signatures can still be created by authorized individuals, but instead of requiring specialized signing equipment for each person, DSS allows organizations to use their existing authentication mechanisms, such as passwords, two factors, biometrics, etc." DSS describes two XML-based request/response protocols, one for signatures and a second for verification. Using these protocols, a client can send documents to a server and receive back a signature on the documents; or send documents and a signature to a server and receive back an answer on whether the signature verifies the documents. "A DSS signature secures an organization's documents efficiently and effectively while maintaining accountability down to the individual level," said Nick Pope of Thales eSecurity Ltd., co-chair of the OASIS DSS Technical Committee. "What's more, DSS allows sensitive signing keys to be protected by using tamper-proof signing devices and by locating the server in a room with controlled access. Costs are reduced with DSS, because security can be highly localized." DSS supports a range of signature formats including XML and CMS. It is designed around a core set of elements and procedures which can be profiled to support specific uses such as time-stamping (including XML structured time-stamps), corporate entity seals, electronic post marks and code signing. The OASIS DSS Technical Committee worked closely with the Universal Postal Union, an agency of the United Nations, to facilitate the use of DSS within its Electronic Post Mark system (UPU EPM). "Deploying support for digital signatures can be extremely challenging, especially for large companies. The task of allocating and certifying user keys can be burdensome and difficult to secure," said OASIS president and CEO, Patrick Gannon. "The DSS OASIS Standard presents an approach to digital signing which significantly reduces these obstacles. The added services enabled by this standard are meeting global needs, and the Universal Postal Union is a good example." The DSS OASIS Standard was developed by representatives of the American Bar Association, Austria Federal Chancellery, BEA Systems, CATCert-Agencia Catalana de Certificacio, IBM, Nokia, Universal Postal Union, and others. The DSS OASIS Standard and the archives of the OASIS DSS Technical Committee work are publicly accessible. OASIS hosts the dss-dev mailing list for exchanging information on implementing the standard. Additional Information DSS 1.0 OASIS Standard http://www.oasis-open.org/specs/index.php#dssv1.0 OASIS DSS Technical Committee http://www.oasis-open.org/committees/dss/ DSS FAQ http://www.oasis-open.org/committees/dss/faq.php DSS Overview Extract, adapted and corrected from the non-normative document section 'DSS Overview' in Digital Signature Service Core Protocols, Elements, and Bindings Version 1.0 OASIS Standard: This specification describes two XML-based request/response protocols: a signing protocol and a verifying protocol. Through these protocols a client can send documents (or document hashes) to a server and receive back a signature on the documents; or send documents (or document hashes) and a signature to a server, and receive back an answer on whether the signature verifies the documents. These operations could be useful in a variety of contexts. For example, they could allow clients to access a single corporate key for signing press releases, with centralized access control, auditing, and archiving of signature requests. They could also allow clients to create and verify signatures without needing complex client software and configuration. The signing and verifying protocols are chiefly designed to support the creation and verification of XML signatures [XML-Signature Syntax and Processing, W3C Recommendation 12-February-2002], XML timestamps (see section 5.1), binary timestamps [Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP) — IETF RFC 3161] and CMS signatures [Cryptographic Message Syntax (CMS) — IETF RFC 3852]. These protocols may also be extensible to other types of signatures and timestamps, such as PGP signatures [OpenPGP Message Format — IETF RFC 2440]. It is expected that the signing and verifying protocols will be profiled to meet many different application scenarios. In anticipation of this, these protocols have only a minimal set of required elements, which deal with transferring "input documents" and signatures back and forth between client and server. The input documents to be signed or verified can be transferred in their entirety, or the client can hash the documents themselves and only send the hash values, to save bandwidth and protect the confidentiality of the document content. All functionality besides transferring input documents and signatures is relegated to a framework of "optional inputs" and "optional outputs". This document defines a number of optional inputs and outputs. Profiles of these protocols can pick and choose which optional inputs and outputs to support, and can introduce their own optional inputs and outputs when they need functionality not anticipated by this specification. Examples of optional inputs to the signing protocol include: what type of signature to produce, which key to sign with, who the signature is intended for, and what signed and unsigned properties to place in the signature. Examples of optional inputs to the verifying protocol include: the time for which the client would like to know the signature's validity status, additional validation data necessary to verify the signature (such as certificates and CRLs), and requests for the server to return information such as the signer's name or the signing time. The signing and verifying protocol messages must be transferred over some underlying protocol(s) which provide message transport and security. A binding specifies how to use the signing and verifying protocols with some underlying protocol, such as HTTP POST or TLS. Section 6 provides an initial set of bindings. In addition to defining the signing and verifying protocols, this specification defines two XML elements that are related to these protocols. First, an XML timestamp element is defined in section 5.1. The signing and verifying protocols can be used to create and verify both XML and binary timestamps; a profile for doing so is defined in XML Timestamping Profile of the OASIS Digital Signature Services Version 1.0. Second, a RequesterIdentity element is defined in section 5.2. This element can be used as a signature property in an XML signature, to give the name of the end-user who requested the signature... About OASIS OASIS (Organization for the Advancement of Structured Information Standards) is a not-for-profit, international consortium that drives the development, convergence, and adoption of e-business standards. Members themselves set the OASIS technical agenda, using a lightweight, open process expressly designed to promote industry consensus and unite disparate efforts. The consortium produces open standards for Web services, security, e-business, and standardization efforts in the public sector and for application-specific markets. Founded in 1993, OASIS has more than 5,000 participants representing over 600 organizations and individual members in 100 countries. Press Contact Carol Geyer Director of Communications OASIS Email: carol.geyer@oasis-open.org Tel: +1.978.667.5115 x209 (office) Tel: +1.941.284.0403 (mobile) Prepared by Robin Cover for The XML Cover Pages archive. See also Security, Privacy, and Personalization.