Decision 769/QD-BTTTT 2022 Guidelines for connecting digital signature applications with public certificate authorities

DECISION

On promulgating Guidelines for connecting digital signature applications with public certificate authorities regarding remote signing

___________

THE MINISTER OF INFORMATION AND COMMUNICATIONS

Pursuant to the Law on E-Transactions dated November 29, 2005;

Pursuant to Decree No. 130/2018/ND-CP dated September 27, 2018 of the Government detailing the Law on E-Transactions regarding digital signatures and digital signature certification services;

Pursuant to Decree No. 17/2017/ND-CP dated February 17, 2017 of the Government defining the functions, tasks, powers and organizational structure of the Ministry of Information and Communications;

Pursuant to Circular No. 16/2019/TT-BTTTT dated December 5, 2019 of the Minister of Information and Communications promulgating the list of mandatory standards on digital signatures and digital signature certification services after models of mobile signing and remote signing;

At the proposal of the Director of the National Electronic Authentication Centre.

HEREBY DECIDES:

Article 1. To promulgate together with this Decision the Guidelines for connecting digital signature applications with public digital signature certification service providers regarding remote signing.

Article 2. This Decision takes effect from the date of signing.

Article 3. The Chief of the Ministerial Office, the Director of the National Electronic Authentication Centre, heads of units under the Ministry, relevant organizations and individuals shall be responsible for the implementation of this Decision./.

For the Minister
Deputy Minister
Nguyen Huy Dung

GUIDELINES

FOR CONNECTING DIGITAL SIGNATURE APPLICATIONS
WITH PUBLIC CERTIFICATE AUTHORITIES
REGARDING REMOTE SIGNING
(Promulgated together with Decision No. 769/QD-BTTTT dated April 27, 2022 of the Minister of Information and Communications)

I. Introduction

These Guidelines are specifications of connection protocols for transferring a certificate signing request (CSR) from a network-connected service/application (service provider - SP) to a Certificate Authority (CA) and receiving the digital certificate of the signer as well as the result of digital signing.

These Guidelines are not applicable to services/applications that have integrated digital signing functions, or digital signing software.

In case the specialized law provisions otherwise prescribe the format of data, they shall prevail.

Those protocols can be applied to other user actions (registration, login...).

Because of the peculiarity of remote signing that requires user confirmation via another electronic device, the signing protocol described in this document is an asynchronous one. In the other words, there is no connection being maintained between the SP and the CA during the CA's authentication process with the user. After the authenticated user provides his/her signature, the digital signing result will be returned by the CA via another connection following the webhook connection method as described in this document. However, where feasible, SPs and CAs are encouraged to maintain connections with TLS session keys.

II. Detailed specifications

1. Diagram

Figure 1.  Digital signing connection flow

2. CSR processing flow

2.1. Create a CSR

The user creates a CSR.

SP encapsulates the CSR as .xml (or json), including: the SP's account credentials (sp_credentials), document ID (doc_id), transaction ID (transaction_id), SP’s system signer identifier (user_id), serial number of the digital certificate (serial_number, in case the user has more than 01 digital certificate), and time to execute the request.

The SP sends the TLS encapsulated data to the CA.

The SP calls the CA to get the certificate information.

The SP hashes the document that requests the digital signature and compresses the data.

The SP sends the hash (file_hash), the SP's account credentials (sp_credentials), and the transaction ID (transaction_id) to the CA.

2.2. Execute digital signing

The CA extracts information in the .xml (or json) data.

The CA authenticates sp_credentials.

The CA finds the subscriber from user_id, sends the digital certificate back to the SP.

The CA sends the request to and receives the signing confirmation from the user (via the CA’s app) in order to perform the digital signing process.

The CA grants a timestamp for the transaction (if any).

2.3. Return the result

The CA encapsulates the digitally signed result as .xml (or json), including the digital signature of each document ID (doc_id), digital certificate of the signer (user_cert), timestamp (if any), request execution time, transaction ID (transaction_id).

The CA sends the TLS encapsulated data to the SP.

The SP attaches the signature to the file and completes the signing process.

Method of result returning:

Via webhook mechanism: When the document signing result is available, the CA will send the result to the SP via the webhook url that the SP pre-registers with the CA.

3. Protocol definition

3.1. API gets certificate information

Description:

- The SP calls the CA.

- When the user creates a CSR, the SP calls the CA to get data about the user certificate.

- The CA will check and return the list of user certificates.

- When the certificate information is available, the SP uses such data to calculate the hash of the file to be signed.

a. API Specification

Method: GET

Path: https://x.x.x.x/get_certificate (x.x.x.x is the API URL to be decided by each CA)

Input parameters:

Example of input parameters:

Output parameters:

Example of output parameters:

3.2. API digitally signs the document

a. Description

- The SP calls the CA and provides the transaction ID (transaction_id)

- The SP uses the user certificate data to calculate the hash of the file to be signed.

- The SP sents file_hash data to the CA in order to digitally sign the document.

- The SP uses the transaction ID to get the signature information when needed.

- In case of special need, the SP and CA can exchange more to return the signing result of this request (hold and wait for the request).

b. API Specification

Method: POST

Path: https://x.x.x.x/sign (x.x.x.x is the API URL to be decided by each CA)

Input parameters:

Notes: Transmitting data_to_be_signed in base64 format increases capacity by 30%, and the hash is recommended in transferring the CSR.

Example of input parameters:

Output parameters:

Example of output parameters:

a. For asynchronous signing:

b. For synchronous signing: When following the synchronous mechanism (keeping the request and waiting for the user's confirmation), the CA will return the digital signature attached with the signing data file in the signed_files field. The user confirmation timeout depends on the policy of each CA. After the confirmation timeout expires, the session is aborted by the SP and the CSR is deemed unsuccessful.

3.3. Webhook API gets document signing information

a. Description

- The CA calls the SP via the pre-registered url.

- After the CA has the result of digitally signing the document, the CA will send such result to the SP.

- The SP attaches the signature to the file, returns it to the user, and terminates the signing flow.

b. API Specification

Method: POST

Path: https://x.x.x.x/recv_signature (x.x.x.x is the API URL to be decided by each CA)

Input parameters:

Example of input parameters:

Output parameters:

Example of output parameters:

3.4. Table of status codes

- This table of error codes represents the groups of basic status codes: successful (code 2xx, e.g. 201, 202...), invalid due to the user (code 4xx, e.g. 401, 402…) and system error (code 5xx, eg 500, 503...).

- If the CA has its own status code system, it shall prevail, but it is required to have all 5 groups of basic status codes as above and must be disclosed to the parties who want to connect.

III. Policies

1. Joint responsibilities:

Responsibilities to be jointly borne by a service provider (SP) and a certificate authority (CA) when using the protocol specified in these Guidelines:

- The SP and CA are responsible for agreeing SP_credentials with the security level in accordance with technical requirements detailed in the Appendix, safely and confidentially managing t and using such information.

- The SP and CA are responsible for agreeing on the URLs for CSRs, status codes, and messages in the event of a successful connection as well as an error.

- The SP and CA are responsible for establishing TLS transmission line for transmitting and receiving data, thus avoiding attacks leading to data leakage.

2. Responsibilities of a SP:

- Authenticating and taking responsibility for the transmitted information;

- Keeping users' information confidential when receiving digital certificates;

- Having plans to prevent the abuse of this protocol for other purposes as well as to protect the rights of users.

3. Responsibilities of a CA:

- Ensuring the availability of digital signing services to serve the needs of the SP.

- Ensuring the digital signing system that meets the standards.