What Are the Technical Requirements for Trust Service Providers?

Owned by Petteri Kivimäki, created
Last updated: Dec 12, 2024
2 min read

A functioning X-Road ecosystem requires two types of trust services:

  1. time-stamping authority (TSA)

  2. certification authority (CA).

Trust Service Providers are organizations providing these services. Trust Service Providers may be commercial third parties, or the services can be provided and maintained by the X-Road Operator too. Regardless of who provides the services, they must meet certain technical requirements.

Time-Stamping Authority

The time-stamping authority must meet the following technical requirements:

  • The TSA service must be compliant with RFC3161 specification.

  • The TSA service must use HTTP(S) with POST for transportation.

  • The TSA service must support SHA-256 or stronger hash functions in requests

  • The certificate that is used for time-stamping signatures must have the id-kp-timeStamping value in the ExtendedKeyUsage field.

  • The TSA service must not require the usage of reqPolicy field in requests.

  • The TSA service must use at least 2048-bit RSA key and SHA-256 (or stronger) hash function for response signatures.

  • TSA service must maintain its accuracy within 1 second of UTC.

Certification Authority

The Certification Authority (CA) issues certificates to Security Servers (authentication certificates) and/or X-Road member organizations (signing certificates). Some requirements apply to both certificate types while others apply to one specific type only.

In addition to the technical requirements listed in this page, a certificate profile that’s aligned with the CA’s certificate policy is required. The requirements for the certificate profile are documented here.

Requirements for signing and authentication certificates

  • The certificates must be compliant with the RFC5280 specification.

  • The CA must accept PKCS#10 Certificate Signing Requests (CSRs).

  • The CA must support issuing certificates for public RSA keys with at least 2048-bit length.

  • The CA must use at least 2048-bit legnth RSA signature function and SHA-256 (or stronger) hash function for certificate signature.

Requirements for authentication certificates

  • The KeyUsage field must include at least one of the following values: digitalSignature, keyEncipherment or dataEncipherment.

  • The KeyUsage field must not include nonRepudiation.

  • The ExtendedKeyUsage field may contain ClientAuthentication or ServerAuthentication.

Requirements for signing certificates

  • The KeyUsage field must include nonRepudiation.

  • The KeyUsage field must not include any of the following values: digitalSignature, keyEncipherment and dataEncipherment.

  • The ExtendedKeyUsage field must not include ClientAuthentication.

  • The CA issuing must ensure that Qualified eSeal certificates are issued only if private key is stored on a Qualified Signature Creation Device.

  • The CA must ensure that Advanced eSeal certificates are issued only if private key is handle securely by certificate owner.

  • When a Qualified Signature Creation Device is used, the Device must support PKCS#11 protocol for connectivity.

Requirements for certificate status validation

  • The CA issuing certificates must provide a certificate validation service that is compliant with the RFC6960 or RFC2560 specification.

  • The certificate validation service must use at least 2048-bit length RSA signature function and SHA-256 (or stronger) hash function for response signing.

 Related articles