Juan Carlos Cruellas

Oasis Digital Signature Services: Digital Signing without the Headaches

Implementing digital signatures on an individual basis presents many challenges, particularly with regard to key management and maintenance. The digital signature services standard eliminates the need to distribute user keys or signing devices across an organization. Instead, it facilitates the use of networked servers to create and verify signatures. The protocols flexibility makes it suitable for applications from simple time-stamping to advanced forms of signatures with full legal recognition

ETSI STF 428 – Accelerating Deployment of Interoperable Electronic Signatures in Europe

This paper provides background information on the strategy of ETSI regarding the production of an integral package of tools for accelerating the production of Interoperable Electronic Signatures across Europe, provides hints on how its different components will fit within the new rationalized framework of European Standards on Electronic Signatures, and finally outlines the main achievements of the ETSI STF-428 project (“Quick fixes to testing of electronic signatures standards“).

ETSI STF 402 – Standardizing the pan-European Infrastructure for Registered Electronic Mail and e-Delivery

This paper outlines the main achievements of the ETSI STF-402 in the area of Registered Electronic Mail (REM henceforth), related to the provision of means for achieving interoperability between solutions that make use of S/MIME for structuring messages and SMTP as transport and some identified solutions using SOAP on HTTP respectively for the same purposes.

Digital Signatures without the Headaches

Deploying support for digital signatures can be a major headache for any organisation. In many cases signatures are created on behalf of an organisation but may be applied by a constantly changing authorised group of personnel. The need to manage the allocation and certification of the multitude of user keys can be particularly burdensome and difficult to secure. This paper presents an alternative approach to the digital signing, which significantly reduces these headaches, being supported by a number of companies and standardised by OASIS. The OASIS “Digital Signature Services” (DSS) standard specifies the use of a specialised server for the creation and verification of signatures under control of remote clients. Instead of keys having to be held and managed individually, OASIS DSS enables keys and other aspects of the signing service to be managed centrally on a networked server. The OASIS DSS protocol supports a range of signature formats including XML and CMS. It is designed around a basic “Core” set of elements and procedures which can be profiled to support specific uses such as time-stamping (including XML structured timestamps), corporate entity seals, electronic post marks and code signing.

Bringing Together X.509 and EDIFACT Public Key Infrastructures: The DEDICA Project

This paper introduces the barriers of interoperability that exist between the X.509 and EDIFACT Public Key Infrastructures (PKI), and proposes a solution to remove them. The solution goes through the DEDICA (Directory based EDI Certificate Access and management) Project. The main objective of this project is to define and to provide the means to make these two infrastructures inter-operable without increasing the amount of information to be managed by them. The proposed solution is a gateway tool interconnecting both PKIs. The main goal of this gateway is to act as a TTP that “translates” certificates issued by one PKI to the other’s format, and then signs the translation to make it a new certificate. The gateway will, in fact, act as a proxy Certification Authority (CA) of the CAs of the other PKI, and will take the responsibility of the certified data authenticity, on the behalf of the original CA.

Interoperability between the X.509 and EDIFACT public key infrastructures: the DEDICA project

This paper shows a successful system to translate security objects from one encoding schema to another. The problem is similar to the translation of official documents from one language to other: we need an official translator, with recognised right to certify, that the information s/he is giving on the translation corresponds exactly with the information contained in the original document. This function can only be given by a TTP (Trusted Third Party). This TTP has to be able to check the validity and authenticity of all the data included in the original document, and translate it to the other environment, signing the translation, to certify, not only the authenticity of the data, but also the signatory of the original document. Since this particular TTP is connecting users and applications of two different environments, we have defined it as a gateway, and this paper describes with detail its architecture and functional requirements. To be more precise, the general architecture of this kind of TTP has been particularised to the case of X.509 and EDIFACT PKI, and the details of the internal modules of the gateway in this particular implementation are also given.