Transcript www.oasis-open.org Practical Digital Signature Issues. Paving the way and new opportunities. Juan Carlos Cruellas – DSS-X co-chair Stefan Drees - DSS-X co-chair Marta Cruellas, CATCERT Pim van der.

www.oasis-open.org
Practical Digital Signature
Issues.
Paving the way and new
opportunities.
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
Andreas Kuehne
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
verification.
n
n
n
n
n
Avoid problems of deployment of infrastructure
required to support individual generation
All the complexity of verification implemented and
deployed once at the server.
Reduces overhead of key management: the central
server takes care of the required tasks on certs status
in both generation and verification.
All the details of the policy for the signatures
centralized.
May keep logs of the verification processes and
results.
DSS concept. Conventional
approach
n
Purchasing
System
(5)
(4)
(5)
Archiving
n
(4)
Timestamp
(3)
(2)
(1)
Cert,
CRL.
Revocation
n
Registration
PKI Certificate
Management
(2)
Cert.
Directory
CRL.
(3)
Deploy key to
each user
Handle Interface
to all PKI
functions
Security depends
on user
DSS concept. DSS approach
Internal user
Authentication &
authorisation
Directory
System
DSS Server
PKI Certificate
Management
DSS also forms the basis for the
emerging standard eID-framework
new
classical DSS-domain
DSS (X)
http://www.eid-stork.eu/
ISO/IEC 24727 /
CEN TS 15480
(„European Citizen Card“)
?
n
n
n
OASIS Digital Signature Services TC
produced a set of OASIS standards, including
the core protocols and a number of profiles.
When IPR modes changed, it was closed.
New OASIS Digital Signature Services
eXtended TC created operating under OASIS
RF IPR mode.
l
Ebxml Messaging Transport Binding for DSS.
n
n
l
Profile for managing visible signatures.
n
n
l
Specifies how DSS messages are encoded and carried using
OASIS ebXML Message Service (Ebxml MS: transport
mechanism for e-business ).
Binding for robust channel between DSS clients and servers and
ebxm features (i.e. asynchronous messaging).
Need to display (mostly in signed documents) information on the
digital signatures to human beings, parts of which may also be
signed.
Clients will instruct servers to incorporate this visual information in
the created signatures. Servers will also verify this signed visual
information.
Profile for supporting centralized encryption/decryption.
n
n
Aims at providing protocols for requesting centralized
encryption/decryption operations (CMS and XML Encryption).
Combination of encryption and signature.
n
l
Profile for detailed individual verification reports.
n
l
n
Aims at allowing to DSS clients to request that the verification
response is actually signed by the verifying server.
Responses that may be seen as signed receipts of the verification
of a certain signed document
Profile for handling signature policies.
n
n
l
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.
Profile for signed verification responses.
n
l
Features: encryption/decryption of ¡parts of a document,
encryption for different recipients, etc.
Request generation/verification of a digital signature following a
certain set of rules (signature policy).
Different documents may require different types of signatures,
generated and verified following different rules and processes.
Analysis of inter-relationships among existing profiles.
n
Paving the way (II): Interoperability events:
l
l
Standards more and more complex. Interoperability is an issue.
Interoperability tests:
n
n
l
l
Face to face: XML Sec maintenance WG in 2007.
BUT now ALSO REMOTE interoperability events.
n
n
l
Very useful for progressing towards interoperability.
Provide feedback to the Standardization Bodies from actual
implementers, helping in getting better standards (identify wrong
or ambiguous parts, identify new requirements, etc).
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
http://xades-portal.etsi.org/pub/XAdES.shtml
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
signatures.Some examples:
l
l
l
l
“Registered Electronic Mail”. ETSI is about to publish its Technical
Specification TS 102 640: “Registered Electronic Mail (REM): Architecture,
Formats and Policies”.
http://portal.etsi.org/stfs/STF_HomePages/STF318/STF318.asp
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 “.
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).
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