Practical Digital Signature Practical Digital Signature Issues. Issues. Paving the way and new Paving the way and new opportunities. opportunities. www.oasis-open.org Juan Carlos Cruellas – DSS-X co-chair Juan Carlos Cruellas – DSS-X co-chair Stefan Drees - DSS-X co-chair Stefan Drees - DSS-X co-chair Marta Cruellas, CATCERT Marta Cruellas, CATCERT Pim van der Eijk, Sonnenglanz Consulting Pim van der Eijk, Sonnenglanz Consulting Detlef Huehnlein, Fed. Ministry of the Interior, Germany Detlef Huehnlein, Fed. Ministry of the Interior, Germany Ezer Farhi, ARX Ezer Farhi, ARX Andreas Kuehne Andreas Kuehne Konrad Lanz, Austria Federal Chancellry Konrad Lanz, Austria Federal Chancellry Clements Orthacker., A-SIT, Zentrum fur sichere Informationst Clements Orthacker., A-SIT, Zentrum fur sichere Informationst
10
Embed
Practical Digital Signature Issues. Paving the way and new opportunities. Juan Carlos Cruellas – DSS-X co-chair Stefan Drees - DSS-X.
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Practical Digital Signature Practical Digital Signature Issues.Issues.
Paving the way and new Paving the way and new opportunities. opportunities.
www.oasis-open.org
Juan Carlos Cruellas – DSS-X co-chairJuan Carlos Cruellas – DSS-X co-chairStefan Drees - DSS-X co-chairStefan Drees - DSS-X co-chair
Marta Cruellas, CATCERTMarta Cruellas, CATCERTPim van der Eijk, Sonnenglanz ConsultingPim van der Eijk, Sonnenglanz Consulting
Detlef Huehnlein, Fed. Ministry of the Interior, GermanyDetlef Huehnlein, Fed. Ministry of the Interior, GermanyEzer Farhi, ARXEzer Farhi, ARX
Andreas Kuehne Andreas Kuehne Konrad Lanz, Austria Federal ChancellryKonrad Lanz, Austria Federal Chancellry
Clements Orthacker., A-SIT, Zentrum fur sichere InformationstClements Orthacker., A-SIT, Zentrum fur sichere Informationst
Paving the way (I): OASIS DSS Standards. Protocols for central
services providing signature generation AND verification.
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 Deploy key to
each user Handle Interface
to all PKI functions
Security depends on user
PKI CertificateManagement
Cert.
CRL.
Timestamp
Directory
Archiving
PurchasingSystem
Registration
RevocationCert,CRL.(1)
(2)
(2)
(3)
(3)
(4)
(5) (4)
(5)
PKI CertificateManagement
DirectorySystem
Internal userAuthentication &
authorisation
DSS concept. DSS approach
DSS Server
DSS also forms the basis for the emerging standard eID-framework
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.
Ebxml Messaging Transport Binding for DSS. 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).
Profile for managing visible signatures. 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. Aims at providing protocols for requesting centralized
encryption/decryption operations (CMS and XML Encryption). Combination of encryption and signature.
Features: encryption/decryption of ¡parts of a document, encryption for different recipients, etc.
Profile for detailed individual verification reports. 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. 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.
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.
Paving the way (II): Interoperability events: Standards more and more complex. Interoperability is an issue. Interoperability tests:
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).
Face to face: XML Sec maintenance WG in 2007. BUT now ALSO REMOTE interoperability events.
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
New coming areas for digital signatures include trusted services supporting electronic business, with specific requirements on the signatures.Some examples:
“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