Policy And Practice For Qualified Validation Service Of Qualified Electronic Signatures/Seals
Effective date: 6.1. 2025 (version 1.0)
Introduction
This document defines the Policy and Practice for the Verification Page of Circularo (the “Policy and Practice”), provided by Circularo (the Company) and implemented through the Circularo platform (the Product).
As a company, Circularo acts as a Qualified Trust Service Provider (QTSP) under Regulation (EU) No. 910/2014 (eIDAS), operating governance, compliance, and security functions.
As a product, the Circularo platform provides the Verification Page, which performs validation of electronic signatures and seals and generates the Qualified Validation Report for qualified signed documents.
This Policy and Practice ensures that both the organizational controls of Circularo (Company) and the technical implementation in the Circularo platform (Product) meet the requirements of eIDAS and ETSI standards for signature validation services.
Overview
Electronic signatures and seals are key to secure digital transactions, provided that their validation is reliable, transparent, and compliant.
Company perspective - Circularo, in its QTSP role, provides governance, operational oversight, compliance management, and security assurance. It cooperates with trusted Certification Authorities (CAs) for certificate issuance under its CP and CPS.
Product perspective - The Circularo platform, including its Verification Page and API integrations, provides the technical implementation of signature and seal validation. It validates electronic signatures and seals and produces the Qualified Validation Report for qualified signed documents.
The Qualified Validation Report is Circularo’s implementation of the Qualified Validation Report (QVR), as defined in ETSI TS 119 102-2. It:
Confirms whether the signature or seal meets eIDAS requirements for qualified signatures,
Provides detailed status and cryptographic validation,
In addition, Circularo may provide a Certificate of Fulfilment as a user-friendly evidence summary. While useful for end-users, the Certificate of Fulfilment is not a QVR.
Provider Identification
Provider - Circularo (the Company)
QTSP Status - Qualified Trust Service Provider under eIDAS
Roles -
As Company: QTSP, operator of the verification service and trust governance framework.
As Product: Provider of the technical Verification Page and APIs that perform validation and produce Qualified Validation Reports.
Policy OIDs –
0.4.0.194112.1.3: Standard implicit validation based solely on data contained within the signature.
0.4.0.194112.1.4: Explicit validation applying a specific external validation policy selected by the requester.
Contact - support@circularo.com |http://www.circularo.com
Supported Policies
This Policy and Practice supports and references the following governing documents:
Circularo Certification Policy (CP)
Circularo Security and Continuity Policies (ISMS, SSDLC, Access Control, Incident Management, Vulnerability Management, BC/DR)
Certification Authorities - Circularo always cooperates with trusted Certification Authorities. I.CA (První certifikační autorita, a.s.) is the primary CA partner, but Circularo may work with alternative trusted CAs when required, as permitted by its CP and CPS.
Normative References
This document is based on and complies with:
Regulation (EU) No. 910/2014 (eIDAS)
ETSI EN 319 401 – General Policy Requirements for Trust Service Providers
ETSI EN 319 411-1/-2 – Certificate Issuance Requirements
ETSI EN 319 441 – Policy and Security Requirements for Signature Validation Services
ETSI TS 119 102-2 – Signature Validation Report (QVR)
ETSI TS 119 442 – Protocol Profiles for Signature Validation Services
ETSI EN 319 102-1 – Procedures for Creation of AdES Signatures
ETSI TS 119 172-4 – Signature Policy Identifiers (OID policies)
RFC 6960 (OCSP) – Online Certificate Status Protocol
Verification Page Components
The Circularo Verification Page consists of organizational and technical components working together to ensure trustworthy, compliant, and transparent validation of electronic signatures and seals.
From the perspective of Circularo as a Company, these components are part of its trust service governance, risk management, and operational oversight as a QTSP.
From the perspective of Circularo as a Product, these components are implemented within the Circularo platform, including the Verification Page, APIs, and backend validation infrastructure.
Actors
The main actors in the Verification Page service are:
Provider (Circularo as Company)
Responsible for compliance with eIDAS and ETSI standards.
Defines policies, maintains documentation (CP, CPS, QSVSP), and ensures audit readiness.
Verification Page (Product)
Provides the user-facing interface for validating electronic signatures and seals.
Produces the Qualified Validation Report for qualified signed documents.
May also generate a Certificate of Fulfilment as an additional user-friendly evidence summary.
Implements Circularo’s security and continuity controls (ISMS, SSDLC, Access Control, Incident Management, BC/DR).
Subscribers (Users of Circularo)
Individuals or organizations who use the Circularo platform for document signing and verification.
May rely on validation reports to demonstrate compliance with business or regulatory requirements.
Relying Parties
Third parties that receive or rely upon a validation report issued by Circularo.
Examples: regulators, courts, business partners, or external auditors.
Certification Authorities (CAs)
Provide qualified certificates that are validated by the service.
Circularo always cooperates with trusted Certification Authorities.
I.CA is the primary CA partner, but Circularo may work with alternative trusted CAs when required, as permitted by its CP and CPS.
Signer
The natural or legal person that creates the electronic signature or seal.
May set or reference constraints at signing time (for example through a signature-creation policy or embedded policy identifiers), which can influence validation outcomes under ETSI EN 319 102-1.
May include additional evidence in the signature (for example qualified timestamps) that serves as proof of existence and affects validation results.
Signers’ related trust service providers (TSPs)
The TSP that issued the signer’s certificate (the CA/QTSP).
Any TSP involved in signature or seal generation, such as a qualified remote signing/sealing service provider where applicable.
Any TSP whose services the signer used at signing time, such as a trusted timestamp authority.
Other TSPs
External providers whose data the Verification Page may consult during validation, such as timestamp authorities (TSAs), certificate status providers (OCSP/CRL), trusted list operators, or other validation/preservation services.
These parties are outside Circularo’s operational control; their availability and published data can influence validation status and the contents of the report.
Validating Authority
The validating authority is Circularo, in its role as QTSP. It:
Operates the validation infrastructure and ensures that validation processes are independent, impartial, and compliant with eIDAS.
Issues the Qualified Validation Report, which is Circularo’s implementation of the Qualified Validation Report (QVR) as defined in ETSI TS 119 102-2.
The Qualified Validation Report:
Contains the result of the signature or seal validation,
Includes a timestamp,
Is available for qualified signed documents.
Service Architecture
The Circularo Verification Page integrates organizational and technical safeguards:
Company (Organizational Layer)
Trust governance and compliance framework.
Security management through ISMS, SSDLC, and vulnerability/patch management.
Continuity and recovery measures from BC/DR plan.
Product (Technical Layer)
Verification Page & APIs - user-facing services for uploading/verifying signatures or consuming validation as a service.
Validation Engine - backend process implementing cryptographic validation, certificate chain checks, and revocation status lookups.
creates the signature validation report(s)
builds the signature validation response in line with ETSI EN 119 102-1 (SVA model)
in Circularo’s implementation, the Driving Application (DA) is the server-side backend, which orchestrates the validation requests and consumes the responses
Secure Infrastructure - hosted in trusted cloud environments with HSM support, strong access control, monitoring, and logging.
The architecture is designed for:
Availability - redundant hosting, monitoring, continuity controls.
Integrity - cryptographic protection.
Confidentiality - TLS, access controls, role-based permissions.
Auditability - complete logging, evidence retention, and external conformity assessments.
Detailed description of the service architecture is available in Circularo’s SD2-Validation Architecture document.
Definitions and Abbreviations
Definitions
Circularo (Company) - Circularo acting as a Qualified Trust Service Provider (QTSP) under eIDAS, responsible for governance, compliance, and overall accountability of the validation service.
Circularo platform (Product) - The technical system operated by Circularo, including the Verification Page, APIs, and backend infrastructure, which performs signature and seal validation and issues validation reports.
Verification Page - The user-facing component of the Circularo platform where electronic signatures and seals can be uploaded and validated. It produces the Qualified Validation Report for qualified signed documents.
Qualified Validation Report - Circularo’s implementation of the Qualified Validation Report (QVR) as defined in ETSI TS 119 102-2. It is available only for qualified signed documents and contains the structured and timestamped validation result.
Certificate of Fulfilment - A user-facing audit trail and evidence report that summarizes signing and validation events. While it may include information about signatures and certificates, it is not equivalent to a QVR.
Subscriber - An individual or organization whose certificate, signature, or seal is validated through the Circularo Verification Page.
Relying Party - An individual, organization, or system that relies on a validation report issued by Circularo to make trust decisions (for example courts, regulators, or business partners).
Certification Authority (CA) - A trusted entity that issues qualified certificates. Circularo always cooperates with trusted CAs. I.CA is the primary CA partner, but alternative trusted CAs may be used when required.
Validating Authority - Circularo in its QTSP role, operating the Verification Page and issuing Qualified Validation Reports.
Abbreviations
API - Application Programming Interface
BC/DR - Business Continuity and Disaster Recovery
CA - Certification Authority
CP - Certification Policy
CPS - Certification Practice Statement
CRL - Certificate Revocation List
eIDAS - Regulation (EU) No. 910/2014 on electronic identification and trust services
ETSI - European Telecommunications Standards Institute
HSM - Hardware Security Module
ISMS - Information Security Management System
OCSP - Online Certificate Status Protocol
QSVS - Qualified Signature Validation Service
QSVSP - Qualified Signature Validation Service Policy (this document)
QVR - Qualified Validation Report
RA - Registration Authority
RFC - Request for Comments (IETF standard)
SVS - Signature Validation Service
TLS - Transport Layer Security
QTSP - Qualified Trust Service Provider
Policy, Practice Statement and General Terms Requirements
Organisation Managing the Documentation of TSP
Circularo (Company) is responsible for the management of all public trust service documentation, including this Policy and Practice.
Each new version of this document remains effective until formally superseded.
Updates are prepared by Circularo staff and published following internal approval by Circularo’s executive management.
Users shall only rely on the effective version of this Policy and Practice as published by Circularo at the time of using the service.
This document is inextricably linked to the Qualified Trust Service Practice Statement (CPS) and related governance documents.
Contact Person
The contact person for management of the document “Qualified Validation Policy and Practice Statement” of Circularo shall be the Chief Executive Officer of Circularo - Josef Neumann (josef.neumann@circularo.com).
Applicability of Circularo’s Public Documentation
Circularo’s public documentation related to the provision of the validation service is made available to all stakeholders and published on Circularo’s official website.
The set of applicable documents includes:
Policy and Practice for the Validation Service (this document) – Policy OIDs: 0.4.0.194112.1.3, 0.4.0.194112.1.4
Circularo Terms of Service available athttps://terms.circularo.com/terms/latest/
Only the currently effective versions of these documents are applicable and binding at the time of service use.
Validation Service Policy
The SVS Policy is integrated in this document and contains information on service applicability. Service recipients may be natural persons, legal entities, and relying parties. The Policy provides information about the service level, including validation of qualified electronic signatures and seals in accordance with eIDAS and applicable ETSI standards.
Validation Service Practice Statement
The signature validation service (QSVSP) is integrated in this document and has been developed, applied, and updated in accordance with ETSI EN 319 401 and ETSI EN 319 441. The SVS Practice Statement describes how Circularo implements the service and is owned and maintained by Circularo. The Practice Statement is accessible to auditors, users, and relying parties. This document describes the method of fulfilment of the requirements identified as necessary to maintain the high quality of the signature validation service and has been formally endorsed by Circularo.
Certificate Usage And Applicability Of The Validation Service
Circularo offers a service of qualified validation of electronic signatures and seals that allows relying parties to receive a Qualified Validation Report on the validation process in an automated and reliable way. The report is time‑stamped in compliance with applicable standards and provides assurance that validation has been performed in accordance with European legislation (eIDAS).
Validation Service Management And Operation
Circularo provides services related to the applicability of signature and seal validation, including:
Validation of advanced and qualified electronic signatures and seals in accordance with eIDAS and applicable ETSI specifications.
Validation of qualified electronic timestamps associated with signatures or seals.
Generation of Qualified Validation Reports via the Verification Page.
Information and consulting services related to validation processes and results.
Circularo provides these services by applying generally accepted recommendations, specifications, and standards, including ETSI EN 319 401, ETSI EN 319 441, and ETSI TS 119 442. For these services, Circularo publishes separate general terms that are inextricably linked to contractual relations. The policies and practice statements related to the services provided apply to all relevant actors engaging with the service, including clients, end users, and relying parties.
The validation services are operated in accordance with Circularo’s Information Security Management System (ISMS) and applicable legal and regulatory requirements, incorporating relevant requirements of ISO/IEC 27001 and ISO 22301, Regulation (EU) No. 910/2014 (eIDAS), Regulation (EU) No. 2016/679 (GDPR), and applicable legislation in the Czech Republic.
Internal Organisation
Circularo conducts its validation operations in line with adopted policies and practices. Contact information for the validation service and applicable public documentation is available on Circularo’s website.
In order to achieve reliability and security in its operations related to the provision of trust services, Circularo applies the requirements specified in ETSI EN 319 401, including:
Circularo guarantees a high level of security and reliability of its operations.
The validation service policies and practice statements applied by Circularo are non-discriminatory.
The services are available for all entities whose operations fall within the declared scope of activity and who agree to fulfil their obligations as specified in Circularo’s general terms.
Circularo concludes a suitable insurance policy every year, in accordance with applicable law, to cover obligations arising from its operations and in line with Article 13 of Regulation (EU) No. 910/2014.
Circularo has the necessary financial stability and resources for operation in accordance with this document.
Procedures for resolution of claims and disputes raised by users or relying parties in relation to the provision of the services or other related matters are defined in the Circularo Terms and referenced by this Policy and Practice.
Circularo maintains documented agreements and contractual relations with third parties to which it subcontracts services, outsourcing, or other activities.
These controls are implemented and maintained within the Circularo ISMS Documentation where relevant (for example access control, incident management, and business continuity).
Organisation Reliability
The obligations and responsibilities of users and Circularo are settled by contractual agreements and the Circularo Terms. Relations with relying parties are governed by applicable civil law.
Contracts for provision of trust services may be concluded in written or electronic form in compliance with Regulation (EU) No. 910/2014, Regulation (EU) No. 2016/679, and the applicable law of the Czech Republic. Conflicting obligations and scopes of responsibility are separated to minimise the possibility of unlawful or unintentional change or misuse of Circularo’s assets.
The validating authority is the Circularo verification service provided via the Verification Page. It exercises its functions in accordance with Regulation (EU) No. 910/2014 and the applicable ETSI specifications, which define the technical and organisational prerequisites for operation, the policies for validation, and the technical requirements.
Where Circularo uses external organisations to support services or components, those parties are contractually bound to follow the requirements set out herein.
Circularo guarantees that:
it applies operational procedures and security management procedures that prevent manipulation of the validation process and of the issued validation report,
it checks the validity of electronic signatures and seals in line with Regulation (EU) No. 910/2014,
its verification service performs validation in accordance with ETSI EN 319 441 and reports results in line with ETSI TS 119 102-2.
The obligations, responsibilities, and guarantees of actors in the validation service process are described in this Policy and Practice and in the Circularo Terms.
Separation Of Duties
Circularo enforces separation of duties to ensure the impartiality and integrity of the verification service. The duties and responsibilities of Circularo, users, and relying parties are defined in this Policy and Practice and the Circularo Terms.
Key controls include:
Role segregation - validation operations are separated from system administration, development, and audit/compliance.
Least privilege and approvals - privileged access is limited to authorised personnel and reviewed periodically, as defined in the Circularo ISMS Documentation.
Independent review - audit and compliance activities are performed independently from daily operations.
Controlled change management - changes to validation logic and platform components follow secure development and release processes defined in the Circularo ISMS Documentation.
Continuity of controls - segregation and approvals are maintained during continuity and recovery activities in line with the Circularo BCP/DR.
Human Resources
Circularo applies the requirements of ETSI EN 319 401 clause 7.2 to ensure that personnel involved in the verification service are competent, trustworthy, and subject to appropriate oversight.
Circularo guarantees that employees and contractors observe the requirements for operational reliability. Personnel engaged in validation operations are selected based on relevant expertise, reliability, experience, and qualifications, and complete training on information security and personal data protection rules relevant to their duties. Training is provided on a periodic basis, at least every 12 months, and includes awareness of potential threats and good security practices. Proper disciplinary measures are applied in case of policy breaches. Roles and responsibilities related to information security are documented in job descriptions.
Trusted roles on which the security of the signature and seal validation service relies are defined, assigned, and approved by management. Job descriptions for permanent and temporary staff reflect separation of duties and least privilege, and identify position sensitivity based on obligations, access levels, and required qualifications. Staff in trusted roles must be free of conflicts of interest that could affect the objectivity of operations. Administrative and operational procedures applicable to these roles form part of the Circularo ISMS Documentation, and management maintains sufficient knowledge of the provided trust services, security procedures, and risk assessment to perform oversight functions.
Trusted roles include, at minimum:
Security officers - overall responsibility for administering and enforcing security practices.
System administrators - installation, configuration, and support of reliable systems that operate the service, including system recovery.
System operators - day-to-day operation of reliable systems, including authorised execution of backups.
System auditors - independent review and auditing of archives and system logs.
Additional roles - specialised trusted roles defined by Circularo where required for specific trust service functions.
Assignment to trusted roles is made by senior management on the principle of least privilege and with appropriate access configuration. Personnel are not granted access to trusted functions before required checks are completed. Circularo requires a certificate of criminal record or equivalent background check, as permitted by applicable law.
Asset Management
General Requirements
Circularo applies the requirements of ETSI EN 319 401 clause 7.3. Circularo protects all service assets, including information assets used by the Verification Page, maintains an inventory of such assets, and classifies them based on risk assessment. Controls are implemented to prevent loss, unauthorised access, alteration, or misuse.
The service may rely on external providers (for example, trusted Certification Authorities for OCSP/CRL status or timestamp authorities). When information needed for validation is outside Circularo’s control, temporary delays can occur (for example, until the next CRL is published). In such cases, the validation result reflects the most current information available at the time of processing, and users may need to re-validate once new status information becomes available.
The Circularo Terms of Service apply to the use of the validation service. The Verification Page is available for personal, non-commercial use via the Circularo application without any service-level commitment. For automated use or defined service levels, clients should contact Circularo to establish a contractual agreement that specifies the applicable service level (SLA).
Where supported by the Verification Page or associated interfaces, the service allows users to:
submit the signed data object (SDO) for validation. For services limited to PDF documents with embedded PAdES signatures (i.e. Circularo), the SDO is always the PDF file itself; a separate signer’s document (SD) is not used,
upload a PDF document even if it does not contain all necessary certificates. In such cases, the service automatically uses its internally maintained trusted-certificate store, so users do not need to provide additional certificates manually,
view individual signatures for inspection when the PDF document contains multiple electronic signatures, with each signature shown and validated separately,
request validation that is automatically performed under the service’s internal signature validation policy aligned with eIDAS requirements. Explicit selection of alternative validation policies by the user is not supported.
Circularo supports signature and seal validation for ETSI baseline profiles and, where applicable, enhanced levels:
PAdES (ETSI TS 103 172), including PAdES-T/TL,
The service validates attached enveloped, attached enveloping, and detached signatures/seals, including documents containing multiple signatures/seals.
Validation accounts for expired or obsolete elements. Where a certified signing time exists (for example, via a trusted timestamp), checks are performed against that time; otherwise, checks are performed against the current time. If relevant elements were not valid at the certified signing time, or if an algorithm was used outside its applicable cryptoperiod, the Qualified Validation Report records the signature/seal as invalid for that reason.
Circularo uses cryptographic algorithms in accordance with ETSI TS 119 312, with validation processing aligned to ETSI EN 319 441.
Constraint handling follows ETSI TS 119 441 and ETSI TS 119 102-2:
the service applies its validation constraints where client-provided indications conflict with this Policy and Practice,
if a client-provided validation policy is incomplete, the service applies its own constraints to achieve a determinate result,
this Policy and Practice describes how client-submitted constraints are handled when they cannot be processed,
this Policy and Practice defines the conditions under which a client policy may be ignored and replaced by service validation rules consistent with ETSI EN 319 441,
the Policy states what constitutes acceptable proof of existence (PoE) for signatures/seals used in validation and recorded in the Qualified Validation Report.
Operation With Different Media
All physical and electronic media used by the verification service are handled and protected in accordance with Circularo’s information classification and handling rules defined in the Circularo ISMS Documentation. Media are stored securely, access is restricted to authorised personnel, and transfers use approved, protected channels. Backup copies receive protection equivalent to the primary media.
Archives that contain sensitive data are retained for the periods defined in Circularo’s retention schedule for evidence and are then destroyed using approved secure sanitisation methods. The procedures for archiving, retention, and secure destruction of validation records and related evidence are defined in the Circularo ISMS Documentation and align with the controls referenced in section 2.10 Collection of Evidence.
Access Control
The Verification Page is publicly accessible and may be used without creating or logging into a Circularo account. Public access is limited to submission of files for verification and retrieval of the resulting validation information. Administrative functions, configuration, APIs under contract, and any privileged operations require authentication and authorisation.
Circularo applies ETSI EN 319 401 clause 7.4 to the Circularo application as follows:
Authorised access only for privileged functions – role-based access control and least-privilege are enforced for staff and contracted users.
Segregation within the application – public verification functionality is logically separated from administrative and development functions.
Network and system protections – only protocols and endpoints required for the Verification Page and supporting services (for example OCSP/CRL lookups) are permitted; filtering and segmentation protect internal domains.
Account lifecycle management – privileged accounts are provisioned, modified, and revoked under documented procedures with timely removal of access.
Strong authentication and session control – applied to all non-public functions.
Audit and accountability – security-relevant events, including privileged actions and access to verification functions, are logged and monitored; logs are retained per policy.
Protection of user data – data in transit is protected with TLS; processing of submitted files is limited to what is necessary to perform verification, with storage and retention governed by Circularo ISMS Documentation and section 2.10 (Collection of Evidence). Controls against abuse (for example rate-limiting and input restrictions) are applied to protect service availability.
Cryptographic Controls
Circularo applies the requirements of ETSI EN 319 401 clause 7.5 to the verification service. Cryptographic controls cover the validation processing.
In addition, the following specific requirements apply:
Time evidence included in the report, where applicable, is obtained from a trusted timestamp authority operating in accordance with ETSI EN 319 421 or equivalent requirements.
Algorithms, and parameters conform to ETSI TS 119 312. Validation processing follows ETSI EN 319 102-1, and deprecation or replacement of algorithms is managed to ensure results remain trustworthy over time.
Physical And Environmental Security
Circularo applies the requirements of ETSI EN 319 401 clause 7.6 to protect the facilities and environments that host the verification service and its supporting components (including application servers, storage, network devices, and cryptographic modules). Where the service is operated in a third-party hosting environment, equivalent controls are contractually required and monitored.
In addition, consistent with ETSI TS 119 101 clause 5.2 (GSM 1.4) for signature validation authorities, Circularo uses cryptographic libraries that are tested against the relevant standards.
Physical and environmental protections include, as appropriate to the site and risk:
Controlled physical access to critical areas, with identification, authentication, visitor logging, and least-privilege entry procedures.
Environmental safeguards such as power redundancy (UPS and, where applicable, generators), fire detection and suppression, and HVAC to maintain operating conditions.
Protection against theft, tampering, and unauthorised removal of equipment; tamper-resistant deployment and custody for hardware security modules.
Secure handling, transport, storage, and destruction of media containing sensitive information.
Monitoring and alerting for physical security events; retention of relevant logs for accountability and incident investigation.
Detailed procedures for site security, media handling, environmental monitoring, and evidence retention are defined in the Circularo ISMS Documentation and align with the operational controls in section 2.7 and continuity requirements in section 2.11.
Operation Security
Circularo applies the requirements of ETSI EN 319 401 clause 7.7 to ensure secure operation of the verification service. Trustworthy systems and products are used, protected against unauthorised modification, and operated to preserve the technical security and reliability of all supported processes.
Security management procedures for the Circularo application and supporting infrastructure are defined in Circularo ISMS Documentation and are applied across design, deployment, and operations. At a minimum:
Security by design and change control – Security requirements are analysed during design of new systems and changes to existing ones. Software changes and configuration changes follow documented change control, including review, approval, testing, and traceability.
Protection against malicious code – The integrity of systems and information is protected through malware prevention, monitoring, and corrective controls.
Media handling and retention – Media are handled to protect archives from damage, theft, unauthorised access, and obsolescence. Retention and lifecycle controls ensure that media remain usable for the required retention period and are securely destroyed when no longer needed.
Role application – Operational procedures are applied consistently by all trusted and administrative roles that can impact the service.
Patch and vulnerability management – Security patches are applied within a reasonable time after release. Patches are deferred only where risk analysis shows they would introduce vulnerabilities or instability outweighing their benefits; reasons for any deferral are documented. Vulnerability remediation follows defined prioritisation and timelines.
Hardened, reviewed components – The service runs on maintained, up-to-date platforms. Implementations of standardised protocols and cryptographic libraries are positively tested and reviewed before use.
Confidentiality and integrity in public access – The verification component of the Circularo application (including publicly accessible endpoints) maintains integrity and confidentiality of all information provided by users and any data transmitted between users and the application. Transport is protected with TLS, and server configuration restricts protocols and ciphers to approved options. Internal communications are restricted to required endpoints (for example OCSP/CRL sources).
Administration and security management functions are separated; the use of system communication channels is restricted and controlled. Privileged activities and other security-relevant events are logged and monitored, with logs retained per policy to support accountability and incident investigation.
Information Security Policy
Circularo has an Information Security Policy approved by management in accordance with ETSI EN 319 401 clause 6.3. The policy defines Circularo’s approach to managing information security for the verification service and its supporting processes and systems.
The Information Security Policy is documented, implemented, and kept up to date. Where applicable, material changes are communicated to relevant third parties (for example relying parties, auditors, or supervisory bodies). All employees are familiarised with the policy and with the procedures that support it.
When Circularo subcontracts part of its operations, Circularo remains responsible for adherence to its security procedures. Subcontractors’ responsibilities are defined contractually, and subcontractors are required to apply security controls equivalent to those mandated by Circularo.
The Information Security Policy and the inventory of information security assets are reviewed at planned intervals and upon significant changes to ensure continuing suitability, adequacy, and effectiveness. Changes that may affect the level of security are approved by the designated information security management function. System configurations are periodically checked for deviations from security rules; the maximum interval between checks is defined in Circularo’s internal procedures.
The policy documents security and data privacy controls. Personal data processed in connection with the verification service are handled in accordance with Regulation (EU) 2016/679 (GDPR) and applicable law, and with Circularo’s publicly available Terms and Privacy Policy. Circularo collects only data proportionate to the stated purpose and uses personal data solely for providing and supporting the verification service.
Network Security
Circularo applies the requirements of ETSI EN 319 401 clause 7.8 to protect the networks supporting the Verification Page and related backend services. Internet-facing endpoints used by the Verification Page are hardened and monitored; administrative interfaces and internal services are segregated and not exposed publicly.
Where remote access to systems storing or processing confidential data is allowed, Circularo maintains a documented policy describing the security and confidentiality controls used to protect such access. Confidential data in this context can include user-related information and signed data temporarily retained while awaiting external status information (for example, if revocation status is not yet available).
In particular, Circularo enforces:
Network segmentation and filtering that separate public web tiers, application tiers, data stores, and management networks. Only required protocols and endpoints are permitted.
Perimeter and application protections such as firewalls and web application firewalls, plus rate limiting and protections against abuse and denial-of-service.
Strict outbound controls from application networks, allowing only necessary egress to trust sources such as OCSP/CRL responders and, where applicable, timestamp authorities.
Strong encryption in transit (for example TLS) for all external and internal communications carrying verification data.
Controlled remote access to management networks via secure methods (for example VPN or hardened bastions) with multi-factor authentication, least privilege, session recording where appropriate, and detailed logging.
Centralised logging and continuous monitoring of security-relevant network events, with alerts for anomalous activity and retention sufficient to support investigation and evidence needs.
These controls are defined and maintained within Circularo’s ISMS Documentation and are applied to both cloud and customer-operated environments in accordance with contractual responsibilities.
Incident Management
Risk Assessment
To ensure the quality and reliability of the verification service, Circularo performs regular risk assessments and evaluates the effectiveness of key security controls at least quarterly. Risk management is conducted in accordance with ETSI EN 319 401 clause 5.
Circularo:
carries out risk assessments to identify, analyse, and evaluate risks associated with the business and technical operation of the verification service;
selects and implements risk treatment measures so that the level of security is commensurate with the assessed risk;
derives security requirements and operating procedures from the risk treatment plan and documents them in the Information Security Policy, this Policy and Practice, and supporting procedures;
reviews the risk assessment periodically (at least annually) and upon significant changes or incidents;
submits the risk assessment and treatment decisions for management approval, including formal acceptance of residual risk.
Risk assessment explicitly considers dependencies on external trust sources (for example OCSP/CRL responders and timestamp authorities), hosting environments, third-party components, and changes introduced through the secure development and change-management processes. Outputs of the risk process feed into access control, vulnerability and patch management, monitoring, continuity planning, and incident response.
Incident Management
All systems supporting the Verification Page are designed for a high level of reliability and are operated in physically protected environments to minimise risks from natural or environmental events. Continuity and security procedures are aligned with Circularo’s operational controls and continuity planning.
For incident management, Circularo applies procedures that fulfil ETSI EN 319 401 clause 7.9. In particular, Circularo:
monitors activities concerning access to and use of information systems and verification service requests;
ensures monitoring takes into account the sensitivity of information collected and processed;
detects abnormal system activities that may indicate a security violation (including intrusion attempts) and raises alerts;
monitors, at a minimum:
a) start-up and shutdown of logging functions; and
b) availability and utilisation of services required within Circularo’s network and hosting environment;responds in a timely and coordinated manner to contain and remediate incidents and to limit the impact of any breach of security or loss of integrity;
assigns trusted-role personnel to follow up on alerts of potentially critical security events and ensures incidents are recorded, triaged, escalated, and reported per established procedures;
maintains procedures to notify the relevant competent authorities, in accordance with regulatory requirements, of any breach of security or loss of integrity that has a significant impact on the trust service and on personal data, within 24 hours of identification;
where a breach is likely to adversely affect a natural or legal person to whom the trust service has been provided, notifies the affected party without undue delay;
regularly processes audit logs using automated mechanisms to identify evidence of malicious activity and alerts personnel of possible critical security events;
announces any critical vulnerability not previously disclosed within 48 hours of discovery;
for each vulnerability, considering its potential impact, either implements a mitigation plan or documents, with evidence, a justified determination that remediation is not required (for example, where risk is acceptably low or mitigation would introduce greater instability);
employs incident reporting and response procedures in a way that minimises damage from security incidents and malfunctions.
Post-incident reviews are conducted to determine root cause, evaluate the effectiveness of detection and response, and define corrective and preventive actions.
Collection Of Evidence
Circularo applies the requirements of ETSI EN 319 401 clause 7.10 for collection and preservation of evidence related to operation of the verification service.
Circularo records and keeps accessible, for an appropriate period of time (including after service cessation), relevant information issued and received during validation activities for use as legal evidence and to ensure service continuity. The confidentiality and integrity of current and archived records are maintained, and records are archived completely and confidentially in accordance with good industry practice. Records are made available when required to demonstrate correct service operation for legal or audit purposes.
The precise time of significant operational events (for example, key management and clock synchronisation) is recorded. Clocks used for recording events in audit logs are synchronised with UTC at least once per day. Records are retained for periods appropriate to provide necessary legal evidence and as notified in the Circularo Terms and applicable contracts. Events are logged so they cannot be easily deleted or destroyed during the required retention period, except when reliably transferred to long-term archives with equivalent protections.
In addition, the following specific requirements apply:
The verification service implements event logs to capture information needed for later proof.
Each signature or seal validation is logged, possibly together with the identification of the subscriber when this information is known. By default, Circularo does not log subscriber identity.
Event logs are timestamped.
Archived data (paper and electronic) are stored for no less than 10 years and are securely destroyed after this period, unless a longer period is required by law or contract.
Event logs include, at minimum, the event type, success or failure, and an identifier of the person and/or component at the origin of the event.
Procedures for evidence collection, protection, retention, and secure destruction are defined in the Circularo ISMS Documentation and align with the operational controls in this Policy and Practice.
Business Continuity Management
Circularo applies the requirements of ETSI EN 319 401 clause 7.11 to ensure continuity of the verification service. Circularo maintains a documented Business Continuity and Disaster Recovery (BCP/DR) plan that defines roles, communication, recovery strategies, and recovery objectives for the Verification Page and supporting components. The plan is approved by management, exercised periodically, and updated after tests or real events.
In the event of a disaster or major incident — including hardware or software failure, loss of a hosting facility or critical cloud service, data corruption, or compromise of a signing or other cryptographic key — operations are restored within the recovery time and recovery point objectives defined in the BCP/DR plan, and root causes are addressed to prevent recurrence.
To support service continuity, Circularo implements appropriate technical and organisational measures, including (as applicable): fault-tolerant deployment of critical functions, tested backups and restoration procedures, capacity management and rate-limiting to mitigate abuse, controlled maintenance windows, and contractual management of third-party dependencies (for example trust status sources such as OCSP/CRL responders and, where applicable, timestamp authorities). Measures are designed to avoid interruption by third parties and to minimise unintentional interruptions by users.
Service availability for the publicly accessible Verification Page is provided on a best-effort basis. Where a defined service level is required (for example automated or integrated use), the applicable service level agreement is set out in contract. The detailed continuity strategies, recovery procedures, testing schedule, and responsibilities are documented in Circularo’s Business Continuity and Disaster Recovery plan and related ISMS documentation.
Termination Plans For The Activity Of Circularo
The obligations in this section are intended to minimise interruptions to users and relying parties if Circularo decides to terminate the verification service. Circularo applies procedures that fulfil the requirements of ETSI EN 319 401 clause 7.12.
Circularo will minimise potential interruptions and, in particular, ensure that information necessary to validate past use of the service continues to be supported for a reasonable period. The termination plan is reviewed periodically and, before termination, at least the following procedures apply:
Circularo informs stakeholders of the termination: all customers and relying parties with whom it has agreements or established relationships, and the relevant competent authorities (for example supervisory bodies), within timelines required by law and contract.
Authorisations granted to subcontractors to act on Circularo’s behalf in any function related to the verification service or the issuance of validation reports are revoked.
Circularo transfers to a reliable party its obligations to maintain all information necessary to provide evidence of the operation of the service for a reasonable period (for example audit logs, validation policies in effect at the time, and public documentation), unless Circularo can demonstrate that it holds no such information.
Where possible, Circularo facilitates transfer of service for existing customers to another qualified trust service provider offering a comparable validation service.
Circularo maintains arrangements to cover the costs of these minimum requirements in case of insolvency or where it is otherwise unable to fund them, to the extent permitted by applicable legislation.
Plans and detailed procedures for orderly termination, including communications, evidence preservation, and key destruction, are defined in the Circularo Business Continuity and Disaster Recovery plan and the Circularo ISMS Documentation.
Compliance
Circularo applies the requirements of ETSI EN 319 401 clause 7.13 to ensure compliance with legal and regulatory obligations.
Circularo operates in a lawful and trustworthy manner and can provide evidence of compliance with applicable legal requirements.
Trust services and end-user interfaces are made accessible to persons with disabilities where feasible, taking due account of relevant standards such as ETSI EN 301 549.
Appropriate technical and organisational measures protect personal data against unauthorised or unlawful processing and against accidental loss, destruction, or damage. Personal data are processed in accordance with Regulation (EU) 2016/679 (GDPR). Online authentication and data capture are limited to identification data that are adequate, relevant, and not excessive for the stated purpose.
Specific requirements:
Where personal data are processed by third parties, Circularo concludes data-processing agreements that require processors to implement technical, organisational, and legal measures consistent with this Policy and Practice and the Circularo Terms.
The verification service does not retain the signer’s document after processing when not necessary. If the verification service is combined with a long-term preservation service, retention may be required and is governed by contract and the Circularo Terms.
Circularo remains responsible for compliance with the above requirements when some or all service functionalities are undertaken by subcontractors.
The service is provided in accordance with the requirements for qualified validation of qualified electronic signatures (eIDAS Articles 32 and 33) and qualified electronic seals (eIDAS Article 40). In particular:
Article 32 — Validation of qualified electronic signatures
The validation process confirms, as applicable, that:
a) the supporting certificate was, at the time of signing, a qualified certificate for electronic signature (checked via certificate policies and trusted lists);
b) the qualified certificate was issued by a qualified trust service provider and was valid at the time of signing (evaluated using OCSP/CRL and time evidence);
c) the signature validation data correspond to the data provided to the relying party (verified per ETSI TS 119 102-2. and applicable AdES profiles);
d) the unique data representing the signatory in the certificate are correctly presented to the relying party (reported in the Qualified Validation Report);
e) any use of a pseudonym is clearly indicated if present in the certificate;
f) the electronic signature was created by a qualified electronic signature creation device (assessed using certificate statements and applicable evidence);
g) the integrity of the signed data has not been compromised (cryptographic verification of the signature with the signed data);
h) the requirements of Article 26 were met at the time of signing (AdES properties assessed per supported profiles).
The system used for validation provides relying parties with a determinate result and flags security-relevant issues in the Qualified Validation Report.
Article 40 — Qualified validation service for qualified electronic seals
The provisions above apply mutatis mutandis to validation of qualified electronic seals, including assessment of qualified certificates for seals, creation device conformity where applicable, integrity of signed data, and reporting of results to relying parties in an automated and reliable manner.
Signature Validation Service Design
Validation Process Requirements
The validation process complies with ETSI TS 119 102-2. The Verification Page implements the algorithm specified in ETSI TS 119 102-2 and may use alternative internal implementations provided they produce the same main status indication for the same set of input information.
Circularo complies with the following requirements:
The signature validation policy is not limited to the minimum number of constraints required under clause 5.1.4.1 of ETSI TS 119 102-2.
The validation process outputs a signature validation status indication and a signature validation report.
According to ETSI TS 119 102-2, the main signature validation status indication is one of: TOTAL-PASSED, TOTAL-FAILED, or INDETERMINATE.
Main indications and report content
TOTAL-PASSED
Semantics: The signature or seal is valid under the applied validation constraints.
Report data: The report includes the validated certificate chain, including the signer’s or seal certificate.
Considerations leading to TOTAL-PASSED include:
• cryptographic checks succeed, including hashes of indirectly signed data where applicable;
• constraints applicable to the signer’s identity certification are positively validated and the signing certificate is trustworthy;
• all validation constraints are met and the signature or seal conforms to them.TOTAL-FAILED
Semantics: One or more validation constraints fail.
Report data: The report provides additional information explaining each failed constraint.
Typical reasons include cryptographic verification failure, hash mismatch, or proof that the signature or seal was generated after revocation.INDETERMINATE
Semantics: Available information is insufficient to conclude TOTAL-PASSED or TOTAL-FAILED.
Report data: The report explains the cause and identifies what data is missing to complete validation.
Secondary indications and report content
Secondary indications follow ETSI TS 119 102-2 and are included in the validation report with explanatory data:
TOTAL-FAILED
FORMAT_FAILURE – The signature or seal is not compatible with supported standards to a level that permits cryptographic processing. Report lists facts causing unsuccessful processing.
HASH_FAILURE – At least one hash of a signed data object does not match the value in the signature or seal. Report identifies the affected element.
SIG_CRYPTO_FAILURE – The signature value cannot be verified with the public key in the signer’s or seal certificate. Report includes the certificate used.
REVOKED – The signer’s or seal certificate is revoked and there is proof of existence that the signature or seal time lies after the revocation time. Report includes the certificate chain, revocation time and reason, and the OCSP/CRL used.
INDETERMINATE
SIG_CONSTRAINTS_FAILURE – One or more signature attributes do not meet the validation constraints. Report lists the reasons.
CHAIN_CONSTRAINTS_FAILURE – The certificate chain does not meet certificate-related constraints. Report includes the chain and cause.
CERTIFICATE_CHAIN_GENERAL_FAILURE – Chain validation failed for other reasons. Report provides details.
CRYPTO_CONSTRAINTS_FAILURE – Algorithms or key sizes are below the required security level and are not protected by sufficiently strong prior time evidence.
EXPIRED – Certified signing time lies after the notAfter date of the certificate. Report includes chain data.
NOT_YET_VALID – Certified signing time lies before the notBefore date of the certificate.
POLICY_PROCESSING_ERROR – A formal policy file could not be processed.
SIGNATURE_POLICY_NOT_AVAILABLE – The document containing the policy details is not available.
TIMESTAMP_ORDER_FAILURE – Timestamps or signed data objects do not respect ordering constraints; report lists the affected timestamps.
NO_SIGNING_CERTIFICATE_FOUND – The signer’s or seal certificate cannot be identified.
NO_CERTIFICATE_CHAIN_FOUND – No certificate chain can be built for the identified signer’s or seal certificate.
REVOKED_NO_POE – A certificate is revoked during validation but it cannot be established whether the signing time is before or after the revocation time. Report includes chain and revocation details.
REVOKED_CA_NO_POE – A chain is found but an intermediate CA is revoked and timing is inconclusive. Report includes the chain and revocation details.
OUT_OF_BOUNDS_NO_POE – The certificate is expired or not yet valid at the validation date and the signing time cannot be ascertained to be within the validity interval.
CRYPTO_CONSTRAINTS_FAILURE_NO_POE – Weak algorithm or key with no proof that the signature or seal predates the deprecation threshold.
NO_POE – No acceptable proof of existence is available to establish that the signature or seal predates a known compromising event.
TRY_LATER – Not all constraints can be fulfilled with available information; validation may succeed when additional revocation or auxiliary data becomes available.
SIGNED_DATA_NOT_FOUND – Referenced signed data cannot be obtained; report identifies the missing data (for example a URI).
GENERIC – Other reasons preventing a determinate result; report provides additional information.
Policy application and SVA requirements
Exactly one signature validation policy is applied per validation: the Circularo default policy for qualified validation. The Verification Page does not accept external or client-provided validation policies.
If a signature or seal contains a policy identifier, it is verified as a signed attribute but does not override the applied policy. Indications purely related to fetching or parsing an external policy are generally not applicable.
The validation application meets ETSI TS 119 101 clause 7.4 requirements for SVA (SIA 1 through SIA 4).
The validation process ensures that the policy in use corresponds to the strategy defined in this Policy and Practice and the applicable terms and conditions.
Determinism principle: for the same inputs (including policy, trust anchors, evidence, and processing time), the same output indication is produced.
Proofs of existence may include qualified timestamps, archive timestamps, or other admissible evidence consistent with ETSI TS 119 102-2 (and, for long-term validation, ETSI TS 119 511).
Algorithms and parameters conform to ETSI TS 119 312.
Report form
Where the input is a qualified signed document, the output is the Qualified Validation Report structured per ETSI TS 119 102-2.
Validation Process
Depending on the signature/seal format used, the Verification Page supports validation of baseline formats and formats with time evidence as follows:
Validation process for basic signature/seal - Baseline
Validation process for signatures/seals with time - Baseline + T
Validation process for signatures/seals with long-term validation data - Baseline + LT
Step 1. Submission of a validation request.
The client uploads a single self-contained signed file via the Verification Page. The service does not accept separate uploads of original content for detached signatures on the public Verification Page; if a detached signature is submitted without its corresponding data, the result will indicate an error or an indeterminate status consistent with ETSI TS 119 102-2 (for example SIGNED_DATA_NOT_FOUND or FORMAT_FAILURE). Validation constraints are those defined in ETSI TS 119 102-2 and, under this Policy, Circularo restricts validation to the parameters described therein. The Verification Page does not support user-provided validation policies.
Step 2. Execution of the validation algorithm.
The Verification Page implements the ETSI TS 119 102-2 algorithm. Validation is performed by applying the Circularo default validation policy with a default profile of constraints, using available trust anchors, revocation information, and time evidence. Processing is deterministic for the same inputs.
Step 3. Preparation of the validation response and report.
The service prepares the validation response in line with ETSI TS 119 102-2. The response is incorporated into the validation report, which:
includes the OID of the service policy and, where used, the identifier of the applied Circularo validation policy;
records, for each applicable constraint, whether it was processed and its result; if a constraint could not be processed, the report indicates that it was ignored or replaced by service rules where appropriate;
for qualified signed documents, is issued as the Qualified Validation Report.
Step 4. Presentation of the validation report.
The Verification Page presents the result to the user and provides access to the validation report.
Validation Constraints For Electronically Signed Documents
The Verification Page operates under a single, Circularo-defined validation policy and a managed set of validation constraints. These constraints are defined, versioned, and maintained by Circularo as part of service management. The Verification Page does not accept client-provided validation policies.
Scope and formats. The service validates self-contained signed files in PAdES at Baseline, Baseline+T, and Baseline+LT profiles as applicable to the file type. Detached signatures that require separate original content are not supported on the public Verification Page; if submitted without the required data, the result will be an error or an indeterminate indication consistent with ETSI TS 119 102-2.
Certificate and trust constraints. Validation requires a buildable and trustworthy certificate chain for the signer/seal certificate under the configured trust anchors and rules. Qualified validations require evidence that the certificate and provider status satisfy eIDAS and applicable ETSI criteria. Revocation status (OCSP/CRL) and trust list information are obtained from trusted sources; if status is unavailable or inconclusive, the result is INDETERMINATE (for example TRY_LATER or REVOKED_NO_POE), and any later re-validation may yield a determinate result when new information is published.
Cryptographic constraints. Algorithms, key sizes, parameters, and hash functions must meet the minimum security levels defined in ETSI TS 119 312 and related profiles. Use of deprecated or weak algorithms/keys results in CRYPTO_CONSTRAINTS_FAILURE (or …_NO_POE where time evidence is missing) in accordance with ETSI TS 119 102-2..
Time and proof-of-existence (PoE) constraints. Signing time is established per ETSI TS 119 102-2 (e.g., using embedded qualified timestamps, archive timestamps, or other admissible evidence). Where certified signing time is not available, current time may be used for certain checks as allowed by the standard, which can lead to INDETERMINATE outcomes. PoE elements are evaluated for strength and ordering; violations produce the corresponding secondary indications (e.g., TIMESTAMP_ORDER_FAILURE, NO_POE).
Determinism and single-policy application. Exactly one policy is applied per validation — the Circularo default policy. Policy identifiers embedded in signatures are verified as signed attributes but do not override the applied policy. Indications that depend solely on fetching or parsing an external policy (e.g., SIGNATURE_POLICY_NOT_AVAILABLE, POLICY_PROCESSING_ERROR) are generally not applicable on the public Verification Page.
Operational constraints. File types and size limits for uploads, service availability, and rate-limiting are enforced to protect service reliability. Submissions that exceed published limits or do not conform to supported formats will not be processed and will result in a failure or indeterminate indication consistent with ETSI TS 119 102-2 (for example FORMAT_FAILURE or SIGNED_DATA_NOT_FOUND).
Report constraints. The validation report records, for each applicable constraint, whether it was processed and its outcome. Where a constraint could not be processed, the report states that it was ignored or replaced by service rules, consistent with ETSI TS 119 102-2. For qualified signed documents, the report is issued as an Qualified Validation Report; trusted time evidence may be added to the report itself and is obtained from a provider conforming to ETSI EN 319 421.
Validation Constraints For Certificates For Electronic Signature/Seal
This section defines the certificate-related constraints applied by the Verification Page when performing qualified validation of electronic signatures and seals. Constraints follow ETSI TS 119 172-1 (Annex A.4.2.1, BSP (m)) and RFC 5280. The Verification Page applies a single Circularo-defined validation policy and does not accept client-provided policies.
(m) 1. X509 CertificateValidationConstraints
Constraints applied during certificate path validation (RFC 5280). Values may differ for signer, CA, OCSP, CRL, or TSA certificates as appropriate.
(m) 1.1 SetOfTrustAnchors – Trust anchors are those derived from the EU Trusted List of Trust Service Providers (EU TSL).
(m) 1.2 CertificationPath – A valid path from a TSL-derived trust anchor to the signer/seal certificate must be buildable and verifiable. Paths provided in the signature/container are considered; otherwise, the Verification Page builds the path.
(m) 1.3 user-initial-policy-set – Not set (default RFC 5280 behaviour).
(m) 1.4 initial-policy-mapping-inhibit – Not set.
(m) 1.5 initial-explicit-policy – Not set.
(m) 1.6 initial-any-policy-inhibit – Not set.
(m) 1.7 initial-permitted-subtrees – Not set.
(m) 1.8 initial-excluded-subtrees – Not set.
(m) 1.9 path-length-constraints – Enforced as indicated by BasicConstraints; no additional service-specific limit beyond RFC 5280.
(m) 1.10 policy-constraints – No additional constraints beyond those inherently verified for qualified certificates (e.g., certificatePolicies/QCStatements as applicable to the issuing QTSP).
(m) 2. RevocationConstraints
Constraints for determining certificate status during validation.
(m) 2.1 RevocationCheckingConstraints – EitherCheck (OCSP or CRL). The service accepts OCSP or CRL status; where both are present, consistent results are required.
(m) 2.2 RevocationFreshnessConstraints – None (no fixed additional lower bound). Freshness is evaluated per ETSI TS 119 102-2; if status is unavailable or inconclusive, the result is INDETERMINATE (e.g., TRY_LATER or REVOKED_NO_POE).
(m) 2.3 RevocationInfoOnExpiredCerts – None (no additional requirement beyond standard practice). If post-expiry status is not available and timing cannot be established, the result may be INDETERMINATE.
(m) 3. LoAOnTSPPractices
Required level of agreement on the issuing QTSP’s practices for qualified validation:
EUQualifiedCertificateRequired – Yes (the signer/seal certificate must be a qualified certificate issued by a qualified trust service provider listed in the EU TSL).
EUQualifiedCertificateSigRequired – Yes when validating qualified electronic signatures.
EUQualifiedCertificateSealRequired – Yes when validating qualified electronic seals.
Note: For validations of advanced signatures/seals, the Verification Page applies the same processing where applicable, but the “qualified certificate” requirements above are not enforced; results will reflect advanced vs qualified status accordingly.
Cryptographic Suites Constraints
The Verification Page enforces cryptographic constraints on all cryptographically protected objects processed during validation — signatures/seals, certificate path elements, CRLs/OCSP responses, and timestamps. Constraints conform to ETSI TS 119 312 (Cryptographic Suites) and fulfil ETSI TS 119 172-1 (p)1. CryptographicSuitesConstraints.
General rule. Algorithms and parameters must be classified as acceptable for the relevant protection goals under ETSI TS 119 312 at the applicable time reference (signing time or trusted time evidence). Use of deprecated or weak algorithms yields an INDETERMINATE/CRYPTO_CONSTRAINTS_FAILURE (or related) indication unless protected by sufficiently strong prior proof of existence; if cryptographic verification itself fails, the result is TOTAL-FAILED/SIG_CRYPTO_FAILURE per ETSI TS 119 102-2.
a) Signed document objects (AdES).
Asymmetric signature algorithms, hash functions, and parameters embedded in the signed document must meet ETSI TS 119 312 minimums.
Where multiple timestamps or archive timestamps are present, their algorithms and ordering must remain consistent and acceptable; violations produce the corresponding secondary indications (e.g., TIMESTAMP_ORDER_FAILURE, CRYPTO_CONSTRAINTS_FAILURE).
b) Certificate path objects.
Signatures on end-entity and CA certificates must use algorithms and parameters acceptable under ETSI TS 119 312 at the relevant time.
Key sizes and algorithm identifiers are evaluated against the issuing CA’s certificate profile; non-conforming or deprecated parameters without adequate PoE lead to INDETERMINATE outcomes as defined in ETSI TS 119 102-2. Circularo’s CP defers exact algorithm OIDs and parameterization to the issuing CA profile; CSRs and HSM settings must conform.
c) Revocation/status information (CRL/OCSP).
CRLs and OCSP responses must be signed with acceptable algorithms and parameters and be verifiable to trustworthy issuers; otherwise the status is unusable and may result in INDETERMINATE/TRY_LATER or a related status. Formats and fields follow RFC 5280/OCSP profiles referenced in Circularo CPS.
d) Time evidence (timestamps/PoE).
Qualified timestamps and any archive timestamps must apply algorithms and parameters acceptable under ETSI TS 119 312 for their issuance time; inadequate strength or broken algorithms without prior PoE yields CRYPTO_CONSTRAINTS_FAILURE(_NO_POE).
Acceptance of time evidence follows ETSI TS 119 102-2; trusted timestamp providers must comply with applicable profiles (e.g., EN 319 421) and produce verifiable tokens.
e) RSA/ECDSA and hashes — service posture.
For certificates issued under Circularo’s CP (RA context), RSA is used; required key sizes and signature/hash algorithms follow the issuing CA’s technical profile. Requests not meeting the CA profile (e.g., hash below SHA-256) are rejected. These RA-side constraints inform the validator’s expectations for encountered certificate chains.
Effect of algorithm deprecation.
If an algorithm becomes deprecated after signing, validation remains acceptable when robust PoE shows the signature predates the deprecation window; otherwise the result is INDETERMINATE/CRYPTO_CONSTRAINTS_FAILURE_NO_POE (or NO_POE) as per ETSI TS 119 102-2.
Note on explicit parameter minima.
Concrete minima (e.g., specific key sizes or named curves) are governed by ETSI TS 119 312 classifications and the issuing CA’s published certificate profile adopted by Circularo’s CP/CPS; the Verification Page enforces these at validation time and will not accept objects falling below those thresholds.
Signature And Seal Elements Constraints
The Verification Page applies constraints on signature/seal elements as defined in ETSI TS 119 172-1 (group (b)). Unless stated otherwise, no additional content constraints are imposed beyond those inherent in ETSI TS 119 102-2 processing.
(b) 1. ConstraintOnDTBS – requirements on the type of Data To Be Signed (DTBS).
Constraint value: None. The Verification Page does not mandate a specific DTBS type; it validates the signed object as presented by the supported AdES format.
(b) 2. ContentRelatedConstraintsAsPartOfSignatureElements – required content-related qualifying properties.
(b) 2.1 MandatedSignedQProperties – DataObjectFormat
Constraint value: None. No mandated content format qualifier.(b) 2.2 MandatedSignedQProperties – content-hints
Constraint value: None. No mandated content hints.(b) 2.3 MandatedSignedQProperties – content-reference
Constraint value: None. No mandated linkage attributes.(b) 2.4 MandatedSignedQProperties – content-identifier
Constraint value: None. No mandated content identifier or value.
(b) 3. DOTBSAsAWholeOrInParts – whether the whole data or only parts must be signed.
Constraint value: None. The Verification Page does not prescribe “Whole” or “Parts”. It validates the actual signed scope defined by the signature/container and detects any post-signing changes accordingly (i.e., via byte ranges in PAdES).
Signature Validation Protocol Requirements
The Verification Page accepts validation requests over HTTPS and returns results synchronously in the browser. Where an integration interface is offered under contract, the exchange may follow the interaction patterns defined in ETSI TS 119 442 for signature validation services. In all cases, the validation response contains the OID of the service policy applied. For qualified signed documents, the response is delivered as an Qualified Validation Report.
The client–service communication channel transports the signed file to be validated and returns the validation result and report. Public use of the Verification Page does not require client authentication. In contracted integrations, client authentication and authorisation may be required, for example via API keys or mutual TLS, as defined in the applicable service documentation.
Transport security protects requests and responses in transit using TLS. If the service cannot reach required trust-status sources in real time or information is incomplete, the Verification Page returns a determinate or indeterminate result consistent with ETSI TS 119 102-2 (for example TRY_LATER). Re-validation by the client at a later time may then yield a determinate result.
Communication between the Verification Page and external trust service providers or sources (for example OCSP/CRL responders, trusted lists, timestamp authorities) is outside the scope of this document.
Interfaces
The Verification Page is accessed through a web interface over HTTPS. The client uploads a signed file and receives the validation result and report in the same browser session (synchronous flow).
Transport security – The client–service channel is protected with TLS 1.2 or higher. Circularo authenticates the service to the client with a publicly trusted server certificate to ensure confidentiality and integrity of the exchanged data.
Client authentication – Public use of the Verification Page does not require user authentication. Administrative and contracted integration functions, if any, require prior authentication and authorisation and are outside the scope of the public interface.
Request/response format – The browser submits the signed file via HTTPS (e.g., HTTP POST). The service returns a human-readable result and provides the validation report. For qualified signed documents, the report is issued as a Qualified Validation Report; the response includes the OID of the applied service policy.
Protocol scope – The public Verification Page does not expose OASIS DSS/SOAP endpoints. If an integration interface is provided under contract, it follows the applicable service documentation and may align with ETSI TS 119 442 interaction patterns. Communication between the Verification Page and external trust sources (e.g., OCSP/CRL responders, trusted lists, timestamp authorities) is outside the scope of this document.
Communication Channel
All client interactions with the Verification Page occur over HTTPS using TLS 1.2 or higher (TLS 1.3 where available). The service authenticates itself to clients with a publicly trusted server certificate to ensure confidentiality and integrity of data in transit. No plaintext or insecure protocol fallback is permitted.
Public use of the Verification Page does not require user authentication. Where authentication is required (for example, for administrative or contracted integration functions), the channel protects the confidentiality of credentials and personal data, and access is authorised before any privileged action is allowed.
To support these objectives, Circularo:
enforces server-authenticated TLS for every request and response;
prohibits downgrade to insecure protocol versions or cipher suites;
applies session and token protections for any authenticated flows, with least-privilege access and periodic review;
logs security-relevant events associated with connection establishment and authenticated access, consistent with section 2.9.
Verification Page – Other Trust Service Providers
The signature verification status and the validation report may depend on information provided by external trust service providers that are outside Circularo’s control. As part of validation, the Verification Page consumes data from, for example, certificate status providers (OCSP responders and CRL distribution points), trusted list operators, trusted timestamp authorities (TSA), and, where applicable, other validation or preservation services.
Availability, publication latency, or inconsistencies in these external sources can affect results. When required information is missing or inconclusive at validation time, the Verification Page returns a determinate or indeterminate indication consistent with ETSI TS 119 102-2 (for example TRY_LATER or REVOKED_NO_POE). External data is not altered or overridden by Circularo; if multiple sources are present, the service applies its configured constraints as described in section 3.1.3.
The communication channel between the Verification Page and external trust service providers is outside the scope of this document.
Signature Validation Report
As a result of automated processing, the Verification Page produces a comprehensive validation report (PDF) for the signature/seal, detailing the reasons for the provided status indications. For qualified signed documents, the report is issued as a Qualified Validation Report. The report includes the validation status at the time of processing and relevant technical evidence.
The service outputs a main status indication and a validation report that documents the technical validation of each applicable constraint defined in ETSI TS 119 102-2. Validation is controlled by a managed set of constraints (see 3.1.2–3.1.5). Constraints may originate from:
the signature content itself (signed attributes or references to external material), and
local verifier sources (the Circularo default validation policy and service configuration).
The Verification Page does not accept client-supplied validation policies. Any constraints passed via user parameters in the public interface are not supported; contracted deployments may use service-side configuration only.
Supported constraint families (reported as processed, with results):
Chain constraints (ETSI TS 119 102-2, 5.1.4.2).
Cryptographic constraints (ETSI TS 119 102-2, 5.1.4.3; ETSI TS 119 312).
Signature/seal element constraints (ETSI TS 119 102-2, 5.1.4.4).
Conformance of the validation report (TS 119 102-2):
Indicates one of TOTAL-PASSED, TOTAL-FAILED, or INDETERMINATE, and provides any sub-indications as per ETSI TS 119 102-2.
Identifies the service policy OID applied (the Circularo validation policy).
May include an identifier of the validation process/algorithm profile corresponding to ETSI TS 119 102-2 (clauses 5.3, 5.5, 5.6.3).
Records all validation constraints processed and their outcomes; where a constraint could not be processed, the report states that it was ignored or replaced by service rules, with rationale.
Presents information extracted from the signer’s or seal certificate (e.g., subject data) sufficient for relying parties to understand whose certificate was validated. Personal data are limited to what is necessary.
Lists signed attributes relevant to validation. Where a non-critical signed attribute cannot be decoded, the report indicates its presence.
Clearly indicates the origin of each proof of existence (PoE) used (from within the signature, the service, or trusted external sources).
– The public Verification Page does not accept user-provided hashes; where applicable, the report states whether hashing was performed by the service.When accessed via the Circularo website, all interactions occur over TLS.