Electronic TimeStamp Process

 

The electronic timestamping process is distributed in the following phases:

• e.Sing Device:

Request process, in which the preparation of the object to be timestamped is carried out (RFC3161 Timestamp Request).

• ANF AC Time stamping authority:

O Access control that aims to determine if the user is authorized.

O Review of the correction of the request and time.

This component is designed to review:

A) That the request is complete and correct. If the result is positive, the data is sent as input to the Time Stamp Generation.

B) Consistency of the current time with respect to the last TimeStamping issued.

O Generation of the time parameter.

This component uses a Stratum Time Secure Source I for the distribution of time parameters. These parameters will be used as input in the Time Stamping Generation process. The necessary security measures are taken to prevent two applications from concurring at the same instant in time, and result in a duplicate transaction number.

Or Time Stamp Generation.

This function is responsible for creating a time stamp that associates the current time instant, a unique serial number, the data provided for the time stamp and ensure the policy requirements to which it adheres.

The Time Stamp Token (TST).

This component calculates the time stamp flag to be returned to the client. It is the one that actually does the cryptographic signature of the data that provides the function of generating the time stamp indicator.

• e.Sing Device:

 

Timestamp reception: the timestamp verification process, which evaluates the integrity and authenticity of the time stamp received

 

Request Process (TimeStamp Request)

 

The process, begins with the request, by a third party, for a timestamp to be applied to a document. For carrying out this process, the ANF AC's e-Sign device prepares a TimeStampRequest per RFC3161. The parameters to send are:

 

• Authentication of use license.

• Hash of the document to be timestamp.

• Name of the algorithm used to obtain the hash of the document.

Important Note: ANF AC's TSU Service respects the Haber and Stornetta principles, anonymity of the timestamp applicant as a guarantee of service independence. The field "certReq" serves for the TSA to send the certificate of the timestamp, but not for that of the applicant. The Time Stamping Units serve without distinction for electronic signature and any other type of transaction.

TimeStampReq:: = SEQUENCE {

Version INTEGER {v1 (1)},

MessageImprint: Contains the hash of the data to be timestamped.

  - hash algorithm OID and the hash value of the data to be

--time-stamped

ReqPolicy TSAPolicyId OPTIONAL,

Nonce INTEGER OPTIONAL,

CertReq BOOLEAN DEFAULT TRUE,

Extensions [0] IMPLICIT Extensions OPTIONAL}

 

The meaning of the main fields is as follows:

• Version: Version number of the syntax used. The current version is 1.

• MessageImprint: Contains the hash of the data to be sealed. The hash length must match the hash length of the algorithm used. The algorithm used may be SHA256, SHA1.

 

MessageImprint :: = SEQUENCE {

HashAlgorithm AlgorithmIdentifier,

HashedMessage OCTET STRING}

 

• reqPolicy: Policy outlined by the TSU.

 

TSAPolicyId :: = OBJECT IDENTIFIER

 

 

Timestamp Process

In the timestamping process, the system performs different actions; first, it performs a review of the request, verifying the correct structuring of the TimeStampRequest object and the origin of the same. During this verification, it is checked that the expected parameters have been entered and that they are correct. We have previously mentioned the possible values of the hash algorithms supported by the service: SHA256, SHA-1.

It is subsequently obtained from the secure source of time, and the time token is generated, which is electronically signed with the private TSU timestamping keys.

Finally, the TimeStamp Response is generated, following the specifications of RFC3161, with the following representation.

TimeStampResp :: = SEQUENCE {

PKIStatusInfo status,

TimeStampToken TimeStampToken OPTIONAL}

 

The status field is based on the definition of the PKIStatusInfo structure of RFC2510:

PKIStatusInfo :: = SEQUENCE {

PKIStatus status,

StatusString PKIFreeText OPTIONAL,

FailInfo PKIFailureInfo OPTIONAL}

 

• Status: If this field is zero or one, it indicates that the timestamp comes in the reply message. For any other value, it indicates that it does not come in the reply message.

PKIStatus:: = INTEGER {

Granted (0),

- when the PKIStatus contains the value zero to TimeStampToken, as requested, is present.

GrantedWithMods (1),

- when the PKIStatus contains the value one to TimeStampToken, with modifications, is present.

Rejection (2),

Waiting (3),

RevocationWarning (4),

- this message contains a warning that a revocation is

Imminent

RevocationNotification (5)

- the request cannot be handled due to system failure}

• StatusString: Used to indicate error events.

• FailInfo: Indicates the causes for which the time stamp has not been generated. The possible errors are:

PKIFailureInfo :: = BIT STRING {

BadAlg (0),

- Unrecognized or unsupported Algorithm Identifier

BadRequest (2),

- Transaction not permitted or supported

BadDataFormat (5),

- The data submitted has the wrong format

TimeNotAvailable (14),

- The TSA's time source is not available

UnacceptedPolicy (15),

- The requested TSA policy is not supported by the TSA

UnacceptedExtension (16),

- The requested extension is not supported by the TSA

AddInfoNotAvailable (17)

- The additional information requested could not be understood

- or is not available

SystemFailure (25)

 

- the request can not be handled due to system failure}

• The timestampTokenInfo field contains the generated time stamp. It is defined as:

TimeStampToken :: = ContentInfo

- contentType is id-signedData ([CMS])

- Content is SignedData ([CMS])

 

ContentInfo is a structure that encapsulates the information signed in a TSTInfo structure. It is defined in RFC2630 and has the following fields:

TSTInfo:: = SEQUENCE {

Version INTEGER {v1 (1)},

Policy TSAPolicyId,

MessageImprint MessageImprint, -

- MUST have the same value as the similar field in

- TimeStampReq

SerialNumber INTEGER,

- Time-Stamping users MUST be ready to accommodate integers

- up to 160 bits.

GenTime GeneralizedTime,

Accuracy Accuracy OPTIONAL,

Ordering BOOLEAN DEFAULT FALSE,

Nonce INTEGER OPTIONAL,

- MUST be present if the same field was present

- in TimeStampReq. In that case it MUST have the same value.

Tsa [0] GeneralName OPTIONAL,

Extensions [1] IMPLICIT Extensions OPTIONAL}

• version: indicates the seal version

• policy: determined by the TSU

• messageImprint: will be the same as the request message

• serialNumber: it is an integer assigned by the TSA and must be unique for each label it generates. Therefore, a timestamp will be identified by the name of the TSA that generated it and the assigned serial number

• genTime: It is the instant of time in which the timestamp was created. Both ISO and the IETF express the time instant referred to the UTC scale, to avoid confusion with the local hours. The format should be as follows:

CC YY MM DD hh mm ss Z

CC represents the century (19-99)

YY represents the year (00-99)

MM represents the month (01-12)

DD represents the day (01-31)

Hh represents the time (00-23)

Mm represents the minutes (00-59)

Ss represents the seconds (00-59)

Z comes from Zulu, which is as it is known to UTC

• accuracy: in cases where necessary, it provides accuracy even in microseconds:

Accuracy :: = SEQUENCE {

Seconds [1] Integer OPTIONAL,

Millis [2] Integer (1..999) OPTIONAL,

Micros [3] Integer (1..999) OPTIONAL,

}

• nonce: appears if it is in the request message, and will have the same value

• tsa: serves to identify the TSA.

• extensions: defined in RFC 2459

The method of communication between the entities and the time-stamping service of ANF AC TSA will be performed using HTTP / HTTPS protocol with client authentication, in order to be able to validate the requests made.

In addition to the information reviewed, the following unsigned attributes are included. These attributes serve as the basis for carrying out advanced verification processes in the hash-chaining list of each TSU, and are a fundamental guarantee in the provision of the service:

• The last hash chronologically issued by the TSU

• The current hash

• The next hash. In which the two previous hashes are associated.

 

• The unique transaction number of the TimeStamping issued.