The latest version was saved by David Blanco Giró on 2016-08-19 12:08:00.
This document is the English translation of the original one in Spanish ( https://www.tractis.com/contracts/480550042 ). This English translation is provided for user convenience, but it is not binding. The Spanish original is the only legally binding document between you and Tractis.
Tractis Time Stamping Policy Statement
This document describes the Time Stamp Authority Service (Hereinafter, TSA) provided by Tractis.
This service creates time stamps in the XML/XAdES format defined in DSS core 1.0 and, also, PKCS#7 as defined in RFC 3161. These stamps may be used as part of more complex services or may be offered as an independent service.
To create the service, the specifications in the relevant standards published by the competent international regulatory bodies were rigorously followed.
The main specifications followed in creating the service are as follows:
- RCF 3161 –Internet X. 509 Public Key Infrastructure in all relating to the nature of the services offered.
- DSS Core 1.0 y DSS Timestamp profile in all relating to the stamps format and the request/response protocol.
- XAdES 1.3.2 for the signature formats contained in the timestamps.
- ETSI TS 102 023 in all relating to the lay-out of this document.
- TSA: Time Stamp Authority.
- TSU: Time Stamp Unit.
- DSS: Digital Signature Services.
- OASIS: Organization for the Advancement of Structured Information Standard.
- XMLdSIG: XML Digital Signature.
- XAdES: XML Advanced Electronic Signatures.
- ASN.1.- Abstract Syntax Notation 1.
- SSCD.- Secure Signature Creation Device.
- HSM.- Hardware Security Module.
- CEN-CWA.- Committee Européen de Normalisation- CEN Workshop Agreement.
- EAL4+.- Evaluation Assurance Level.
- PED.- Pin Entry Device.
- DPC.- Data Processing Center.
3. Service Description
The time stamping service provides other applications and users with mechanisms that that enables them to prove the existence of some content at a given point in time. To achieve this, the service generates a special type of electronic signatures, called time stamps, on the content to be secured. This signatures contains, in addition to the protected content, the time instant when it was created obtained from a reliable time source. This time instant lets one know reliably the moment when the time stamp was created and thereby to establish the content existence at that time instant.
A service like this is of special utility for services that work with electronic signatures, where pinpointing the instant they were created is critical in the validation processes.
By adding time stamps to the signatures we can set an upper bound that will help us know in a reliable manner the instant the signature was created and this enables the verification of the signature beyond the life of the signer certificate.
We can distinguish further, within a TSA, different TSU (Time Stamp Unit). These are charged with generating the signatures that protect the time stamps. In the Tractis TSA cardinality is kept 1:1 and there is only one TSU.
3.1. Service Component
The TSA figure requires two main components to provide the service:
- A reliable time source determines the instant the time stamp was created.
- A TSU that generates the signatures that protect the time stamps.
4. Reliable Time Sources
The TSA must have access to a time source guaranteeing the reliability of the process for obtaining the time instant used in the creating of time stamps. To this end the Tractis TSA is connected to a stratum 1 time source through a NTP protocol. This time source gives accuracy at the microsecond level using synchronization with the Navstar satellite system.
Additionally, as a back-up measure in case the connection or synchronism with the primary time source, the TSA has a second time synchronization service by GPS.
4.1. Accuracy in the issuing of time stamp
The Tractis TSA issues time stamps with an accuracy such that the allowed time difference will in no case exceed one second. This accuracy is constantly monitored to avoid deviations deriving from abnormal latencies in synchronizing with the sources or deviations in the equipment internal clocks.
Detection of erroneous time
Should a lack of synchronism in any clock of any of the instances forming the TSA cluster be detected, such instance (or instances) will be deactivated to prevent the wrong provision of time stamp services until a new synchronization has been made.
4.2. Tractis Time Stamp Unit (TSU)
Time stamps are a special kind of documents that, besides the content to protect, contain the time instant when they were generated, both protected by the body of the signature.
This type of signatures can be presented in different coding formats and syntax, for example, the format PKCS#7 coded in ASN.1 is for time stamps generated by TSA implementing the protocols defined in RFC 3161.
In our case, the Tractis TSA generates time stamps in the XMLdSIG/XAdES format, as per specification DSS core 1.0 under the Timestamping profile therein, and also PKS#7 time stamps in the format defined by RFC 3161.
In both cases, the messages generated are signed with the TSU private key and contain the certificates identifying it.
In order to assure that the signatures on the time stamps are sufficiently secure, a couple of considerations to take into account:
- The pair of keys used to generate the stamps has been generated inside a SSCD and has the length and the algorithm needed to guarantee that it cannot be broken with current computing capacities.
- The signatures on the time stamps are generated inside a SSCD meeting the technical requirements set by current legislation. In our case, these should comply at a minimum with the requirements defined in standard CEN-CWA 14169.
In order to guarantee these requirement Tractis uses as TSU a HSM Luna SA from Safenet. This device meets the CEN-CWA 14169 requirements and is catalogued as an EAL4+ SSCD.
4.3. Management of keys
The Tractis TSU employs signature mechanisms based on asymmetric key algorithms to generate its time stamps.
For the generation process a pair of keys is used: a private one, that never leaves the TSU device, and a public one, that travels inside the TSU certificate and that has to be used by third parties to verify the authenticity of the time stamp.
The time stamping algorithms use the RSA algorithm for the asymmetric encryption of the protected information, and the SHA-1 for the cryptographic summary.
Life cycle of the TSU keys
The Tractis TSU private key is generated inside the HSM that uses it to sign. By this procedure we make sure that the key has not abandoned at any time the inside of the device, minimizing the risk of the keys being compromised.
Description of the TSU keys
- Algorithm: RSA.
- Size: 2048 bits.
Observations: Once the lifetime of the keys expires, we will evaluate the advisability of using other technologies and lengths for the new keys. This review should take into account the state of the art of then current information processing architectures and computer systems capabilities, as well as the weaknesses to that date detected in the encryption algorithms.
Protection of the TUS private key
As of this time the Tractis TSU consists of a single instance and there is no back-up copy of its private key, as recommended in the ETSI TS 102 023 document, to minimize the risk of the keys being compromised.
Observations: Should the TSU increase in the future the cardinality of its instances or apply key security copies policies, the process will be carried out as recommended in ETSI TS 102 023 and documented in a new version of this herein document.
Revocation of keys
If during the lifetime of the keys the algorithms used to issue them became no longer robust, the keys would be revoked and be not valid from that very moment.
End of the keys lifetime period
Once the keys lifetime has ended, these will be destroyed along with all the back-up materials where these might be contained, such as back-up tokens and the like, should we in the future take the option of making security copies of the keys.
Tractis TSU certificate
The certificate containing the Tractis TSU public key is issued by a CA from the certification authority Firma Profesional whose distinct name is:
- /C=ES/emailAddress=ca1firmaprofesional.com/L=C/ Muntaner 244 Barcelona/OU=Consulte http://www.firmaprofesional.com/OU=Jerarquia de Certificacion Firmaprofesional/O=Firmaprofesional S.A. NIF A-62634068/CN=AC Firmaprofesional - CA1
The distinct name assigned to the Tractis TSU by Firma Profesional is:
- /C=ES/O=negonation platform S.L/serialNumber=B84282029/CN=tractis.com Timestamp Unit
The lifetime of the certificate goes from March, 9th, 2015 to July, 21th, 2020.
5. Access to the TSA
The Tractis TSA offers services to both to internal services from Tractis own infrastructure, and is used as a complement to its electronic signature creation and validation services and to the long term archiving service, and to Tractis customers via the Tractis Time Stamping Authority (Tractis TSA) service.
For this reason, the Tractis TSA is available to local Tractis traffic and to external services from other parties.
The Tractis TSA runs inside an application servers cluster that interrogates by NTP the reliable time source and generates the signatures on the time stamps by means of requests over secure channel connections to the TSU.
The TSU is physically isolated from all external traffic and can only be accesed by machines that have been accepted to do this. In order to guarantee this secure pathway, the only communication that the TSU accepts is based on TLS channels with mutual authentication. This technique makes possible that only accepted client certificates be accepted, and these can only be loaded through the TSU administrative procedures.
Observations: The TSU administrative procedures are described further down and require physical presence and two factor authentication to be carried out.
5.1. Service delivery communication protocol
The Tractis TSA generates time stamps in two types of format: XAdES and RFC 3161.
In the case of time stamps in the XAdES format, these are codified as defined in DSS core 1.0 and its profile Timestamping, and can be requested by invoking a Document/Literal web service that behaves as defined in DSS.
The format of the request/response messages and the specific behavior of the service follow faithfully the provisions in DSS 1.0 and its Timestamp profile.
As to the time stamps in the RFC 3161 format, these are codified in the ASN 1 format and can be invoked the service performance rules for TSP set forth in RFC 3161.
The details of the protocol needed to invoke the service as well as the messages intervening in this process are defined in the corresponding RFC.
Observations: As these are amply documented standards, the format of the request/response messages and the use of the service fall beyond the aim of this document. These can be consulted in the corresponding documents made available by the OASIS consortium and RFC 3161 Time Stamp Protocol for the XAdES and RFC 3161 services respectively.
The TSA administration is divided into the administration of the TSA logic and time sources and the administration of the TSU.
To carry out administration tasks, the TSA administration requires authentication by means digital of certificates in a secure device. These tasks allow turning on/off the system, as well as the communication with the time sources.
The administration of the TSU requires physical presence (applying all the physical presence controls inherited from DPC where the solution is hosted).
Additionally, it is required to have one of the device control keys that are under custody by qualified Tractis personnel and present a pin code that has to be introduced by means of a PED in the HSM.
The administration, monitoring and maintenance of the Tractis TSA systems will be carried out exclusively by personnel belonging to the Tractis Core Development Team.
The maintenance of the TSU will be carried out only by Security Officers of the digital signature area of the Tractis Core Development Team, who will be the only ones with access to the access keys to the HSM and the access codes.
Physical access to the equipment
The TSA (as well as its TSU) are located inside the Claranet DPC in Barcelona. This DPC applies strict access control measures, giving access to the premises only to dully authorized persons and only after a physical authentication process. Furthermore, each and every access event (both at entry and exit) is registered by Claranet for later auditing.
Protection against external menaces
The TSA service is in a demilitarized zone (DMZ) whose access is protected by firewalls and other measures against attacks from the net. These mechanisms protect the system against unauthorized access using protocols different from those required for the provision/administration of the service.
Application audit registries
The Tractis TSA generates two types of materials from its service provision processes: logs and service evidences.
The logs are text messages that describe certain service parameters and are stored in text files duly kept under custody with pertinent access controls.
The evidences are elements that intervene in the provision of the service, such as certificates, CRLs, or OCSP used in the stamping process. These elements are kept under separate custody in devices guaranteeing their protection and safe keeping during the time period set for them by the Tractis evidence management policy.
These registries are kept in custody under the strictest protection measures and for the time period that current legislation dictates for information of this kind.
5.3. Policy identifier
The URI identifying this document as well as the time stamping policy currently applied by the Tractis TSA is http://www.tractis.com/policies/tsp/standard. The corresponding OID is 220.127.116.11.4.1.33818.104.22.168.1.
6. Cessation of service
Should Tractis cease activity all clients subscribed to its services, in this case subscribed to the TSA, will be notified of the cessation.
Tractis will proceed to hand over all the log and evidence registries to an entity deemed appropriate by Tractis to give proof for a reasonable period of time that the service was provided correctly.
The same key destruction procedures described in the section End of the Keys Lifetime Period herein above will be applied.
Tractis will proceed likewise to the revocation of the TSU certificate current at that time, ending the validity of the same from that moment on.
7. Disaster contingencies
The Tractis TSA/TSU as of the time of writing this document has one single instance hosted at the Claranet DPC in Barcelona. This DPC is provided with security measures against natural disasters and power interruptions.
In case of major contingencies the service will be interrupted while these prevail, notifying the users of the system as soon as possible.
The contingencies considered that may result in some risk to the quality of service are:
- Delays in the processing of requests that would imply a clear violation of the service quality policy.
- Loss of synchronism with the primary and secondary sources.
The contingencies that may result in some risk to the provision of service are:
- Keys being compromised.
- Errors found in the TSA software.
Observations: For more details on the TSA contingencies and the measures to overcome them consult the document on Tractis contingency plans.
8. Dispute resolution
Should a TSA client require it, Tractis, after a process of authentication, will be able to provide the service evidences needed as supporting evidence in an expert process. To do this the client should address himself to Tractis through the contact channels defined on the Tractis.com website or get in touch with the Tractis sales team.
10. Referenced documents
- RFC 3161. - http://www.ietf.org/rfc/rfc3161.txt
- DSS core 1.0. - http://docs.oasis-open.org/dss/v1.0/oasis-dss-core-spec-v1.0-os.html
- DSS Timestamp profile. - http://docs.oasis-open.org/dss/v1.0/oasis-dss-profiles-timestamping-spec-v1.0-os.html
- ETSI TS 102 023. - Available on the ETSI website.