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

  • Summary
  • Content
  • Status
  • Vietnamese
  • Download
Save

Please log in to use this function

Send link to email

Please log in to use this function

Error message
Font size:

ATTRIBUTE

Decision No. 769/QD-BTTTT dated April 27, 2022 of the Ministry of Information and Communications on promulgating Guidelines for connecting digital signature applications with public certificate authorities regarding remote signing
Issuing body: Ministry of Information and CommunicationsEffective date:
Known

Please log in to a subscriber account to use this function.

Don’t have an account? Register here

Official number:769/QD-BTTTTSigner:Nguyen Huy Dung
Type:DecisionExpiry date:Updating
Issuing date:27/04/2022Effect status:
Known

Please log in to a subscriber account to use this function.

Don’t have an account? Register here

Fields:Information - Communications

SUMMARY

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

On April 27, 2022, the Ministry of Information and Communications issues the Decision No. 769/QD-BTTTT on promulgating Guidelines for connecting digital signature applications with public certificate authorities regarding remote signing.

Accordingly, 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.

Those protocols can be applied to other user actions (registration, login...). But these Guidelines are not applicable to services/applications that have integrated digital signing functions, or digital signing software. 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.

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

This Decision takes effect from the date of signing.

For more details, click here.
Download files here.
LuatVietnam.vn is the SOLE distributor of English translations of Official Gazette published by the Vietnam News Agency
Effect status: Known

THE MINISTRY OF INFORMATION AND
COMMUNICATIONS

-------

THE SOCIALIST REPUBLIC OF VIETNAM
Independence - Freedom - Happiness

---------------

No. 769/QD-BTTTT

Hanoi, April 27, 2022

 


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:

No.

Parameters

Datatypes

Obligatory

Notes

1

sp_id

String

The SP's account name provided by the CA

2

sp_password

String

Password provided by the CA to the SP

3

user_id

String

Citizen’s identity card number/ people’s identity card number/Passport/tax identification number of the individual/organization that wants to log in

4

serial_number

String

 

Serial number of digital certificate

5

transaction_id

String

Transaction ID created by the SP

 

Example of input parameters:

Output parameters:

No.

Parameters

Datatypes

Notes

1

status_code

Int

Successful request code or corresponding error code. E.g.: 200, 401, 403, 500...

2

message

String

Success message or error message corresponding to the status code in status_code.

3

cert_id

String

Digital certificate identifier (also known as cert alias)

4

cert_data

String

Raw data of the certificate (base64 format)

5

chain_data

List <String>

List of certificates, including 3 elements. The first element is the digital signer certificate, the second is the CA's digital certificate, and the last is the root certificate issued by the NEAC.

6

serial_number

String

Serial number of digital certificate

7

transaction_id

String

Transaction ID created by the SP

 

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:

No.

Parameters

Datatypes

Obligatory

Notes

1

sp_id

String

The SP's account name provided by The CA

2

sp_password

String

Password provided by the CA to the SP

3

user_id

String

Citizen’s identity card number/ people’s identity card number/Passport/tax identification number of the individual/organization that wants to log in

4

data_to_be_signed

String

String representing of the document that requires to be signed (base64 string with file, hex with hash)

5

doc_id

String

ID of the document that requires digital signature

(This ID needs to be displayed on both the SP's interface and the CA's application interface at the same time when the user certifies the CSR)

6

file_type

String

File type: xml/json/word/pdf/excel/...

7

sign_type

String

Digital signature type: hash/file

8

serial_number

String

 

Serial number of the digital certificate (in case of one subject with multiple digital certificates)

9

time_stamp

String

 

The time the user sends the CSR. Format: YYYYMMddHHmmSS

10

transaction_id

String

Transaction ID created by the SP

 

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:

No.

Parameters

Datatypes

Notes

1

status_code

Int

Successful request code or corresponding error code. Example: 200, 401, 403, 500...

2

message

String

Success message or error message corresponding to the status code in status_code

3

transaction_id

String

Transaction ID created by the SP

4

doc_id

String

ID of the document that requires digital signature (This ID needs to be displayed on both the SP's interface and the CA's application interface at the same time when the user certifies the CSR)

5

signature_value

String

Signature data associated with the document (base64 format)

6

timestamp_signature

String

The CA's signature on the timestamp of the digital signing transaction

 

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:

No.

Parameters

Datatypes

Obligatory

Notes

1

sp_id

String

Th SP's account name provided by CA (Can be used by the SP to distinguish which request sent by which CA)

2

status_code

int

Successful request code or corresponding error code. Example: 200, 401, 403, 500...

3

message

String

Success message or error message corresponding to the status code in status_code

4

transaction_id

String

Transaction ID created by the SP

5

doc_id

String

 

ID of the document that requires digital signature

6

signature_value

String

 

Signature data associated with the document (base64 format)

7

timestamp_signature

String

 

The CA's signature on the timestamp of the digital signing transaction

 

Example of input parameters:

Output parameters:

No.

Parameters

Datatypes

Notes

1

status_code

Int

Successful request code or corresponding error code. Example: 200, 401, 403, 500...

2

message

String

Success message or error message corresponding to the status code in status_code

 

Example of output parameters:

3.4. Table of status codes

No.

Status_code

Notes

1

200

Successful

2

400

Invalid document

3

401

Invalid credentials

4

403

The certificate is revoked, or the format is unknown

5

500

System error

 

...

Other errors (If any)

 

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

 

TECHNICAL REQUIREMENTS

 

No.

Contents

Technical requirements

1

sp_credentials

Preparing, executing, and comparing the username and password strings (according to RFC 8265)

2

Hash

The hash must be at least as secure as SHA (according to RFC 6234) or higher.

3

Digital signature

Pursuant to Circular No. 22/2020 of the Ministry of Information and Communications prescribing technical requirements for digital signature software and digital signature verification software

4

TLS

Connections must meet the Transport Layer Security standard TLS 1.3 (according to RFC 8446)

5

Hex

Meeting base16, base32 and base64 encoding standards (according to RFC 4648)

6

User's digital certificate

Digital certificates must meet x509 standard (according to RFC 5280)

 
Please log in to a subscriber account to see the full text. Don’t have an account? Register here
Please log in to a subscriber account to see the full text. Don’t have an account? Register here
Processing, please wait...
LuatVietnam.vn is the SOLE distributor of English translations of Official Gazette published by the Vietnam News Agency

ENGLISH DOCUMENTS

LuatVietnam's translation
Decision 769/QĐ-BTTTT DOC (Word)

This utility is available to subscribers only. Please log in to a subscriber account to download. Don’t have an account? Register here

Decision 769/QĐ-BTTTT PDF

This utility is available to subscribers only. Please log in to a subscriber account to download. Don’t have an account? Register here

* Note: To view documents downloaded from LuatVietnam.vn, please install DOC, DOCX and PDF file readers
For further support, please call 19006192

related news

SAME CATEGORY

loading