Certificate Policy & CPS

This combined Certificate Policy (CP) and Certification Practice Statement (CPS) governs the public key infrastructure operated by Fidelir S.R.L. under the commercial designation Fidelir Trust Services, as a non-qualified trust service provider issuing certificates in support of advanced electronic signatures (AdES) within governed client programmes under this CP/CPS and agreed programme policy.

1. Introduction

1.1 Purpose

This document defines the certificate policy and the certification practices applied by Fidelir S.R.L. when operating certification authority services for advanced electronic signature workflows. It is intended for subscribers, relying parties, auditors, and supervisory review within the scope of active engagements.

1.2 Scope

This CP/CPS applies to all certification authority certificates and subscriber signing certificates issued under the Fidelir Trust Services PKI hierarchy that assert the NCP policy identifier 0.4.0.2042.1.1. It implements the certificate-policy and operational-practice requirements of ETSI EN 319 411-1 (NCP) and ETSI EN 319 412 certificate profile guidance for natural and legal persons. Operational controls required by EN 319 411-1 are described in §§5–8 and §10. It does not apply to qualified certificate policies (QCP) or qualified electronic signature creation.

1.3 Relying party obligations (issued certificates)

This section applies to reliance on certificates issued under this CP/CPS (Fidelir Trust Services PKI). It does not govern the public signature validation service at trust.fidelir.com, which is described in the Validation Policy (VP).

Relying parties shall verify certificate validity, scope of authorization, and applicable programme policy before relying on a signature created with such a certificate. Reliance outside the programme scope defined at issuance is prohibited unless expressly agreed in writing. A validation outcome produced by the public validation service for a document signed with a Fidelir-issued certificate does not, by itself, extend programme reliance rights beyond this section.

1.4 Relationship to the public validation service

Fidelir Trust Services operates a public signature validation platform governed by the VP. That service evaluates third-party electronic signatures against configured trust material and returns cryptographic indications. Issuance of certificates under this CP/CPS and validation of arbitrary submitted documents are separate functions: the validation platform may report on signatures that use Fidelir-issued or external certificates, but contractual and programme authorization for reliance on Fidelir-issued certificates remains defined here and in programme agreements.

2. Definitions

• AdES — Advanced Electronic Signature.
• BTSP — ETSI Best practices Time-Stamp Policy (OID 0.4.0.2023.1.1).
• CA — Certification Authority.
• CPS — Certification Practice Statement (this document).
• CRL — Certificate Revocation List.
• NCP — ETSI Normalised Certificate Policy (OID 0.4.0.2042.1.1).
• OCSP — Online Certificate Status Protocol.
• RA — Registration Authority.
• TSA — Time Stamp Authority.
• TSP — Trust Service Provider.

3. Trust service provider identification

Legal entity

Fidelir S.R.L.

IDNO

1026023126883

organizationIdentifier

NTRMD-1026023126883

Registered locality

Chișinău, Republic of Moldova

Commercial name

Fidelir Trust Services

Trust service

Advanced Electronic Signatures (non-qualified)

Supervisory authority

Serviciul de Informații și Securitate (SIS)

Legal basis (MD)

Law no. 124/2022 on electronic identification and trust services for electronic transactions

4. Certificate policy

4.1 Policy identifier

All CA and end-entity certificates in this hierarchy assert the Normalised Certificate Policy (NCP) object identifier 0.4.0.2042.1.1. This policy identifies certificates suitable for advanced electronic signature use cases that are not qualified electronic signatures and not qualified certificates under eIDAS or Moldova Law 124/2022.

4.2 Policy qualifiers

CA certificates include a CPS pointer (id-qt-cps) to this document and a user notice (id-qt-unotice) with the following text:

Non-qualified trust service provider. Certificate Policy: ETSI Normalised Certificate Policy (NCP).
Certificates issued under this policy are not qualified certificates.

Certificate user notices are intentionally brief and statute-neutral so they remain valid for the certificate lifetime. The applicable legal and supervisory framework is defined in this CP/CPS (including §11) and may be updated by CPS revision without re-issuing CA certificates where the change does not affect certificate semantics.

End-entity signing certificates include a user notice stating non-qualified status and prohibiting production reliance where certificates are marked for test or programme-laboratory use.

4.3 Excluded policies

This hierarchy does not issue certificates under ETSI qualified certificate policies (QCP-n, QCP-l, QCP-n-qcd, QCP-l-qcd, or related QCP identifiers). No QCStatements are asserted.

5. PKI hierarchy and roles

5.1 Certification hierarchy

5.2 Role separation

• CA — key generation (where applicable), certificate issuance, CRL issuance.
• OCSP responder — signing of OCSP status responses only; dedicated unit keys separate from CA and Root signing keys.
• TSA — issuance of RFC 3161 time-stamp tokens; private key used only for time-stamping.
• RA — identity proofing, authorization, lifecycle requests; operates under programme policy.
• Subscriber — protection of private signing key; lawful use within programme scope.

6. Certificate profiles

6.1 CA certificates

• Version 3 (X.509)
• Subject: C, L, O, organizationIdentifier (NTRMD), CN
• basicConstraints: critical, CA:true (subordinate CA: pathLen:0)
• keyUsage: critical, keyCertSign, cRLSign only
• subjectKeyIdentifier, authorityKeyIdentifier (subordinate CA)
• certificatePolicies: NCP + CPS URI + user notice
• privateKeyUsagePeriod: key lifetime shorter than certificate validity

6.2 Natural person signing (ETSI EN 319 412-2)

• keyUsage: critical, nonRepudiation only (type A)
• basicConstraints: critical, CA:false
• Subject: serialNumber = IDNP (13 digits, plain value — Moldova / STISC / eGOV interoperability), surname, givenName, CN (surname + space + givenName), L, ST, C
• IDNP semantics per EN 319 412-1 are documented in this CPS; structured PNO-{C}- encoding in serialNumber is not used (breaks national integrators)
• subjectAltName: subscriber email (rfc822Name)
• certificatePolicies: NCP OID + CPS URI; userNotice states non-qualified NCP status (no QCStatements)

6.3 Legal person signing (ETSI EN 319 412-3)

• Same key usage and basic constraints as natural person profile
• Organization attributes including organizationIdentifier where applicable

6.4 Time-stamp authority (ETSI EN 319 422 / EN 319 421)

• Unit certificate signed by Root; basicConstraints: CA:FALSE (not critical)
• keyUsage: critical, digitalSignature, nonRepudiation
• extKeyUsage: critical, timeStamping only
• certificatePolicies: BTSP OID 0.4.0.2023.1.1 + CPS URI + user notice
• No QCStatements
• AIA/CRL: Root OCSP, Root caIssuers, Root CRL

The TSA issues RFC 3161 time-stamp tokens at https://trust.fidelir.com/tsa under BTSP 0.4.0.2023.1.1. Tokens assert:

• Accuracy: 10 milliseconds (RFC 3161 Accuracy field)
• genTime: UTC GeneralizedTime with millisecond fractional seconds
• Ordering: not asserted (false)

Clock source for genTime is the TSA host system clock synchronized to UTC by NTP with stratum 1 only (no stratum > 1). If synchronized time is unavailable, the TSA refuses to stamp (timeNotAvailable). The TSA is a non-qualified time-stamping service under this CP/CPS; it is not a QTST.

6.5 OCSP responder (RFC 6960)

• Unit certificate; basicConstraints: critical, CA:FALSE
• keyUsage: critical, digitalSignature only
• extKeyUsage: critical, OCSPSigning only
• id-pkix-ocsp-nocheck (1.3.6.1.5.5.7.48.1.5) asserted
• Root-programme responder: signed by Root; AIA/CRL via Root OCSP, Root caIssuers, Root CRL
• Issuing CA-programme responder: signed by the Issuing CA (RFC 6960 §4.2.2); AIA/CRL via CA OCSP, CA caIssuers, CA CRL
• certificatePolicies: NCP OID + CPS URI + OCSP responder user notice
• privateKeyUsagePeriod: key lifetime shorter than certificate validity

7. Cryptographic requirements

• Certificate signature algorithm: SHA-256 with RSA
• Root CA and subordinate CA keys: RSA 4096 bit minimum
• TSA unit key: RSA 4096 bit minimum
• OCSP responder unit keys: RSA 4096 bit minimum
• Subscriber keys: RSA ≥ 3072 bit (or elliptic curve equivalent approved at programme level)
• Random number generation: OS CSPRNG or hardware-approved source
• Root CA certificate validity: up to 20 years
• Root CA private key usage period: up to 10 years
• Subordinate CA certificate validity: up to 10 years
• Subordinate CA private key usage period: up to 5 years
• TSA unit certificate validity: up to 10 years
• TSA private key usage period: up to 5 years
• OCSP responder unit certificate validity: up to 10 years
• OCSP responder private key usage period: up to 5 years
• Subscriber certificate validity: as defined per programme (typically ≤ 3 years)

8. Certificate lifecycle

8.1 Issuance

Certificates are issued only after RA verification of subscriber identity and authorization under an active client programme governed by this CP/CPS. Enrollment follows programme policy; no public self-service registration is offered.

8.2 Renewal and re-key

Renewal requires re-validation proportional to programme policy. Re-key requires generation of a new key pair; private keys shall not be transferred or exported from approved environments where hardware protection is mandated.

8.3 Suspension and revocation

Certificates are revoked upon key compromise, cessation of authorization, subscriber request, or determination of improper issuance under §8.3.1. Revocation is published via CRL and OCSP (RFC 6960). Reason codes follow RFC 5280 conventions. Revocation requests are processed within programme SLA and in any event before the next scheduled CRL publication or within 24 hours for key-compromise events, whichever is sooner.

8.3.1 Improper issuance — criteria and authorization

Improper issuance means a certificate was issued contrary to this CP/CPS, programme policy, or the verified authorization on file. Examples include: erroneous or unauthorized subject attributes; issuance without completed RA identity proofing; certificate issued outside approved programme scope; or technical profile non-conformance detected before or after publication.

Revocation for improper issuance requires:

1. A documented finding (audit, RA review, subscriber dispute, or CA operational check) referencing certificate serial number and basis;
2. Authorization by the CA operations role and, except for time-critical key compromise, confirmation by the programme authority or RA responsible for the subscriber;
3. Selection of an RFC 5280 reason code appropriate to the finding (typically affiliationChanged, cessationOfOperation, or superseded; keyCompromise where applicable);
4. Publication on the CA CRL and OCSP responder and retention of the revocation record with approver identity, timestamp, and reason for audit.

Routine subscriber-initiated revocation does not require programme-authority confirmation. Disputed improper-issuance revocations are escalated to Fidelir Trust Services management before publication when RA and CA roles disagree.

9. Publication and repository services

9.1 Repository URIs

Trust repository

https://trust.fidelir.com/repository/

CP/CPS

https://trust.fidelir.com/cps

Root CA (caIssuers)

https://trust.fidelir.com/cer/root.cer

Root CRL

https://trust.fidelir.com/crl/root.crl

Root OCSP

https://trust.fidelir.com/ocsp/root

Root OCSP responder (caIssuers)

https://trust.fidelir.com/cer/ocsp-root.cer

CA (caIssuers)

https://trust.fidelir.com/cer/ca.cer

Chain (Root + CA)

https://trust.fidelir.com/cer/chain.pem

CA CRL

https://trust.fidelir.com/crl/ca.crl

CA OCSP

https://trust.fidelir.com/ocsp/ca

CA OCSP responder (caIssuers)

https://trust.fidelir.com/cer/ocsp-ca.cer

TSA (caIssuers)

https://trust.fidelir.com/cer/tsa.cer

9.2 Operational status (v1.0)

OCSP and TSA endpoints are not browsable web pages. Non-conforming HTTP methods (for example GET or HEAD from a browser) receive HTTP 418 with an informational page; this is not an OCSP response and does not indicate responder failure. Clients shall use POST with the content types defined in RFC 6960 (OCSP) or RFC 3161 (TSA).

10. Operational and physical controls (ETSI EN 319 411-1 NCP)

The following practices implement the operational requirements associated with the NCP policy identifier asserted in issued certificates. Programme-specific requirements may add stricter controls but shall not reduce those stated here.

10.1 Governance and documented practices

• Certificate and revocation operations follow documented procedures maintained with this CP/CPS and programme addenda.
• Material CPS changes are versioned, dated, and published at the repository URI before reliance (§12).
• Roles (CA, OCSP responder, RA, TSA, programme authority) are assigned to named responsible persons with segregation of duties between RA approval and CA issuance where practicable.

10.2 Registration and identification (RA)

• Identity proofing and authorization are performed by RA staff or approved programme processes before issuance request acceptance.
• Evidence of identity and programme authorization is retained for the certificate lifetime plus the organisation’s records-retention period.
• Issuance requests that fail identity, authorization, or profile checks are rejected and logged; no certificate is issued pending resolution.

10.3 Certificate issuance controls

• Only the online CA issues subscriber certificates; profiles conform to §6 and programme policy.
• Issuance is initiated only from an authenticated RA request with verified subscriber attributes.
• Issued certificates are logged with serial number, subject DN, policy OID, validity, and approver reference.

10.4 Private key protection

• Root CA private key: stored offline; used only for subordinate CA, TSA unit, and Root-programme OCSP responder certificate signing and Root CRL issuance.
• CA private key: protected in hardened or hardware-backed environment before operational issuance; not used to sign OCSP responses.
• OCSP responder private keys: protected in hardened or hardware-backed environment; used only to sign OCSP status responses at the corresponding endpoint.
• TSA private key: protected in hardened or hardware-backed environment; used only to sign time-stamp tokens.
• Subscriber keys: generated in approved environments; export prohibited where hardware protection is mandated by programme policy.

10.5 Time-stamp authority clock and accuracy

• Each host running a TSA replica shall maintain NTP synchronization to UTC at stratum 1 exclusively.
• Claimed token Accuracy is 10 milliseconds, matching the Accuracy field in issued tokens (§6.4).
• Operators monitor NTP offset and jitter on TSA hosts; material loss of stratum-1 sync or clock unavailability requires the TSA to stop issuing tokens until restored.

10.6 Revocation and status publication

• CRL and OCSP publication follows §§8.3 and 9.2; CRL re-issued at least every 30 days or before nextUpdate.
• Revocation events are recorded with reason code, authorizer, and publication timestamp.
• Repository URIs in §9.1 are kept available with monitoring on CRL freshness and OCSP POST availability.

10.7 Audit, records and incident handling

• Audit logging: issuance, revocation, and CA administrative actions recorded and retained per programme and legal requirements.
• Logs are protected against unauthorized modification and reviewed on incident or audit request.
• Key compromise or suspected improper issuance triggers immediate escalation, revocation per §8.3, and stakeholder notification per programme SLA.

10.8 Personnel and access

• CA operations: access-controlled; dual control for Root CA activation where practicable.
• Privileged access is limited to personnel with defined role assignment; access is revoked on role change or termination.
• Personnel with CA, RA, or TSA duties receive training on this CP/CPS and applicable programme policy before performing operational tasks.

11. Legal and supervisory framework

Fidelir S.R.L. provides advanced electronic signatures as a non-qualified trust service provider. Notification has been submitted to SIS under Law no. 124/2022. Planned operational commencement: 1 September 2026.

This service does not constitute provision of qualified trust services under eIDAS and does not place Fidelir S.R.L. on the EU Trust List as a qualified trust service provider. Legal effect of signatures is determined by applicable law, programme contract, and the non-qualified status of certificates issued hereunder.

Personal data processed in connection with this programme, including subscriber identity evidence held by the registration authority, is processed by Fidelir S.R.L. as controller. Disclosure to a public authority occurs only where a legal obligation applies under the legislation of the Republic of Moldova, typically Law no. 195/2024 on personal data protection. See the Privacy Policy. Notification to SIS under Law no. 124/2022 does not replace those requirements.

12. Amendments

Material changes to this CP/CPS are published at the CP/CPS repository URI (§9.1) with an incremented version identifier and effective date. CA certificates reference this CPS URI in the certificatePolicies extension; subscribers and relying parties are responsible for monitoring CPS revisions material to their programme.