Practical Digital Signature Issues. Paving the way and new opportunities.

1
Practical Digital Signature Issues.Paving the
way and new opportunities.
www.oasis-open.org
Juan Carlos Cruellas DSS-X co-chairStefan
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 ChancellryClements
Orthacker., A-SIT, Zentrum fur sichere
Informationst
2

• 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.

3
DSS concept. Conventional approach

• Deploy key to each user
• Handle Interface to all PKI functions
• Security depends on user

4
DSS concept. DSS approach
Internal user Authentication authorisation
Directory System
PKI CertificateManagement
DSS Server
5
DSS also forms the basis for the emerging
standard eID-framework
?
6

• 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.

7

• 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.

8

• 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.

9

• 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 between the TC members.

10

• 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