Digital signatures play an important role in the security of electronic commerce and other web applications by assuring the authenticity of web data both when exchanged and retrieved from storage.
What is the need for Web-based Digital Signature Services?
Web-based digital signature services enable the sharing of digital signature creation, verification and other associated services, avoiding the need to implement the technical, as well as physical and procedural, complexities within user applications.
What services does DSS include?
The DSS specifications include services for:
A combination of the above.
What specifications are being produced by the OASIS DSS TC?
The OASIS DSS TC is producing a Digital Signature Service Core Protocol and Elements specification that defines the core protocol and XML data elements for a broad range of uses. This core can be profiled for a particular use case.
What profiles are being specified by the OASIS DSS TC?
Profiles are currently being considered for:
German Signature Law Signature
European Advanced Electronic Signature (XAdES)
Electronic Post Mark
S/MIME and Code-Signing
Who should be involved in this development?
Providers of digital signature services, as well as those concerned with applications where the use of digital signatures is an important factor, would benefit from the involvement in this activity.
What benefits are to be gained from involvement?
By involvement in the OASIS DSS TC, users can ensure that their requirements can be met by the open market, and that solution providers can fit in the open market.
How does this work compare with related efforts at other standards organizations?
The work of the OASIS DSS TC incorporates the use of existing digital signature standards including:
IETF / W3C XML Signature
IETF Cryptographic Message Syntax (RFC 2630)
ETSI XML Advanced Electronic Signatures (XAdES - TS 101 733)
IETF Time-stamp protocol (RFC 3161)
When will the DSS specifications be completed?
Committee drafts of the DSS Core and profiles have been released. These are in the process of being updated to take into account implementation experience and external comments. The specifications are shortly due to go out for public review with the aim of completion in the second half of 2006.
Are DSS requests secured?
The DSS Core specification is specified in a way that the exchanges may be
carried over a range of transport and security bindings. The core includes
some optional bindings using HTTP Post or SOAP over TLS. If required, an
alternative binding using signature services can be defined as part of the
transport binding for a profile, for example, using Web Security Services in
conjunction with SOAP.
Are the DSS XML Time stamps and RFC 3161 the same?
DSS has defined an XML timestamp which is essentially the same and the binary timestamp token defined in RFC 3161. Some elements of the RFC 3161 fields were not included as the functionality is covered elsewhere in the DSS protocol. In particular:
a) The nonce is optional in RFC 3161. Its use allows the client to
prevent replay attacks. DSS is designed to be used over a security binding
which prevents replay. The serial number already provides for unqiueness.
b) Message imprint is not included as it is in the XML DSig <ds:reference>,
and this allows greater flexibility in the object being timestamped.
c) The version is identified through the XML Namespace.
d) The <dss:Timestamp> element is extensible by adding additional elements
within the <ds:object> element within the <ds:signature> forming the <dss:timestamp>.