Practical Digital Signature
Paving the way and new
Juan Carlos Cruellas – DSS-X co-chair
Stefan Drees - DSS-X co-chair
Marta Cruellas, CATCERT
Pim van der Eijk, Sonnenglanz Consulting
Detlef Huehnlein, Fed. Ministry of the Interior, Germany
Ezer Farhi, ARX
Konrad Lanz, Austria Federal Chancellry
Clements Orthacker., A-SIT, Zentrum fur sichere Informationst
n Paving the way (I):
l OASIS DSS Standards. Protocols for central
services providing signature generation AND
n Avoid problems of deployment of infrastructure
required to support individual generation
n All the complexity of verification implemented and
deployed once at the server.
n Reduces overhead of key management: the central
server takes care of the required tasks on certs status
in both generation and verification.
n All the details of the policy for the signatures
n May keep logs of the verification processes and
DSS concept. Conventional
n Deploy key to
n Handle Interface
to all PKI
n Security depends
DSS concept. DSS approach
DSS also forms the basis for the
emerging standard eID-framework
new classical DSS-domain
ISO/IEC 24727 /
CEN TS 15480
(„European Citizen Card“)
n OASIS Digital Signature Services TC
produced a set of OASIS standards, including
the core protocols and a number of profiles.
n When IPR modes changed, it was closed.
n New OASIS Digital Signature Services
eXtended TC created operating under OASIS
RF IPR mode.
l Ebxml Messaging Transport Binding for DSS.
n Specifies how DSS messages are encoded and carried using
OASIS ebXML Message Service (Ebxml MS: transport
mechanism for e-business ).
n Binding for robust channel between DSS clients and servers and
ebxm features (i.e. asynchronous messaging).
l Profile for managing visible signatures.
n Need to display (mostly in signed documents) information on the
digital signatures to human beings, parts of which may also be
n Clients will instruct servers to incorporate this visual information in
the created signatures. Servers will also verify this signed visual
l Profile for supporting centralized encryption/decryption.
n Aims at providing protocols for requesting centralized
encryption/decryption operations (CMS and XML Encryption).
n Combination of encryption and signature.
n Features: encryption/decryption of ¡parts of a document,
encryption for different recipients, etc.
l Profile for detailed individual verification reports.
n Individually report on each signature found in a document and
incorporation in each one relevant details of the verification
process, satisfying the business requirement of logging them.
l Profile for signed verification responses.
n Aims at allowing to DSS clients to request that the verification
response is actually signed by the verifying server.
n Responses that may be seen as signed receipts of the verification
of a certain signed document
l Profile for handling signature policies.
n Request generation/verification of a digital signature following a
certain set of rules (signature policy).
n Different documents may require different types of signatures,
generated and verified following different rules and processes.
l Analysis of inter-relationships among existing profiles.
n Paving the way (II): Interoperability events:
l Standards more and more complex. Interoperability is an issue.
l Interoperability tests:
n Very useful for progressing towards interoperability.
n Provide feedback to the Standardization Bodies from actual
implementers, helping in getting better standards (identify wrong
or ambiguous parts, identify new requirements, etc).
l Face to face: XML Sec maintenance WG in 2007.
l BUT now ALSO REMOTE interoperability events.
n ETSI owns a portal supporting remote interoperability tests on
XAdES signatures. It has conducted two Remote Interoperability
events on XAdES (high figures of participation from Europe and
Asia) and organized a third one for next year on XAdES and
CAdES. See details at
l Also former DSS TC organized a restricted interoperability test
between the TC members.
n New coming areas for digital signatures include trusted services
supporting electronic business, with specific requirements on the
l “Registered Electronic Mail”. ETSI is about to publish its Technical
Specification TS 102 640: “Registered Electronic Mail (REM): Architecture,
Formats and Policies”.
l REM: an “ enhanced form of mail transmitted by electronic means (e-mail)
which provides evidence relating to the handling of an e-mail including proof
of submission and delivery “.
l TS: specifies generic architecture for the provision of this type of services,
proposals for formats of signed evidences and requirements on the
corresponding digital signatures. It also acknowledges the existence of
centralized services for generation and verification of digital signatures for
evidences (DSS set of protocols).
l Signatures in relevant documents formats: new ETSI STF-364 on PDF
signatures and Advanced Electronic Signatures (XAdES and CAdES).
Among other things, it will profile CAdES and XAdES with the objective of
using them for long term signatures within PDF documents framework