![](media/image1.jpeg){width="5.629861111111111in" height="0.9979166666666667in"} Certification Practices and Policies for website authentication certificates +----------------------------------+-----------------------------------+ | **Date:** 03/06/2025 | **Version**4.0.17 | +----------------------------------+-----------------------------------+ | **Status:** APPROVED | **No. of pages**112 | +----------------------------------+-----------------------------------+ | **OID:** 1.3.6.1.1.4.1.8149.2.4 | **Classification: PUBLIC** | | .0 | | +----------------------------------+-----------------------------------+ | **Archivo:AC | | | CV-CPS-CP-V4.0.17-EN-2025.docx** | | +----------------------------------+-----------------------------------+ | **Prepared by: Technology and | | | Electronic Certification | | | Agency** | | +----------------------------------+-----------------------------------+ **Changes** +-------------+-------------+------------+-----------------------------+ | **Version** | **Author** | **Date** | **Remarks** | +-------------+-------------+------------+-----------------------------+ | 4.0.1 | ACCV | 20/05/2017 | No change | +-------------+-------------+------------+-----------------------------+ | 4.0.2 | ACCV | 03/09/2018 | CAB/Forum Modification | +-------------+-------------+------------+-----------------------------+ | 4.0.3 | ACCV | 03/02/2019 | OCSP Extension | +-------------+-------------+------------+-----------------------------+ | 4.0.4 | ACCV | 19/07/2019 | RFC364 Corrections. | | | | | Modifications in the | | | | | treatment of mail | +-------------+-------------+------------+-----------------------------+ | 4.0.5 | ACCV | 29/07/2019 | Modification of the serial | | | | | number | +-------------+-------------+------------+-----------------------------+ | 4.0.6 | ACCV | 15/01/2020 | RFC3647 minor corrections . | +-------------+-------------+------------+-----------------------------+ | 4.0.7 | ACCV | 24/02/2020 | Minor changes in the Law. | | | | | RFC3647 Corrections | +-------------+-------------+------------+-----------------------------+ | 4.0.8 | ACCV | 20/03/2021 | Change in the address of | | | | | the headquarters. Proof of | | | | | key compromise | +-------------+-------------+------------+-----------------------------+ | 4.0.9 | ACCV | 20/04/2022 | Revision and correction | +-------------+-------------+------------+-----------------------------+ | 4.0.10 | ACCV | 02/12/2022 | Video identification is | | | | | included | +-------------+-------------+------------+-----------------------------+ | 4.0.11 | ACCV | 16/03/2023 | Revision and minor changes | +-------------+-------------+------------+-----------------------------+ | 4.0.12 | ACCV | 10/09/2023 | Adaptation to CAB/Forum | | | | | Policy 2.0.0.0 | +-------------+-------------+------------+-----------------------------+ | 4.0.13 | ACCV | 02/04/2024 | Review | +-------------+-------------+------------+-----------------------------+ | 4.0.14 | ACCV | 10/06/2024 | New TLS hierarchy and | | | | | revision | +-------------+-------------+------------+-----------------------------+ | 4.0.15 | ACCV | 13/01/2025 | Elimination of new | | | | | hierarchy | +-------------+-------------+------------+-----------------------------+ | 4.0.16 | ACCV | 12/02/2025 | New TLS hierarchy and | | | | | revision | +-------------+-------------+------------+-----------------------------+ | 4.0.17 | ACCV | 03/06/2025 | Consolidation of CPS and CP | +-------------+-------------+------------+-----------------------------+ Table of Contents [1. INTRODUCTION 13](#introduction) [1.1. Overview 13](#overview) [1.2. Document Name and Identification 13](#document-name-and-identification) [1.3. PKI Participants 14](#pki-participants) [1.3.1. Certification Authorities 14](#certification-authorities) [1.3.1.1. Root Certification Authorities 14](#root-certification-authorities) [1.3.1.1.1. ACCVRAIZ1 14](#accvraiz1) [1.3.1.1.2. ACCV ROOT ECC TLS 2024 15](#accv-root-ecc-tls-2024) [1.3.1.1.3. ACCV ROOT RSA TLS 2024 15](#accv-root-rsa-tls-2024) [1.3.1.2. Subordinate Certification Authorities 15](#subordinate-certification-authorities) [1.3.2. Registration Authorities 17](#registration-authorities) [1.3.3. Subscribers 18](#subscribers) [1.3.4. Relying parties 18](#relying-parties) [1.3.5. Other participants 18](#other-participants) [1.3.5.1. Applicants 18](#applicants) [1.4. Certificate Usage 18](#certificate-usage) [1.4.1. Appropriate Certificate Uses 18](#appropriate-certificate-uses) [1.4.2. Prohibited Certificates Uses 19](#prohibited-certificates-uses) [1.5. ACCV Policy Administration 19](#accv-policy-administration) [1.5.1. Organization Administering the Document 19](#organization-administering-the-document) [1.5.2. Contact Person 19](#contact-person) [1.5.2.1. Problem Reporting Address 19](#problem-reporting-address) [1.5.3. Person determining CPS suitability for the policy 19](#person-determining-cps-suitability-for-the-policy) [1.5.4. CPS approval procedures 19](#cps-approval-procedures) [1.6. Definitions and Acronyms 20](#definitions-and-acronyms) [1.6.1. Definitions 20](#definitions) [1.6.2. Acronyms 23](#acronyms) [2. Publication and Repository Responsibilities 24](#publication-and-repository-responsibilities) [2.1. Certificate repository 24](#certificate-repository) [2.2. Publication 25](#publication) [2.3. Time or Frequency of Publication 26](#time-or-frequency-of-publication) [2.4. Access Controls on Repositories 26](#access-controls-on-repositories) [3. Identification and Authentication 27](#identification-and-authentication) [3.1. Naming 27](#naming) [3.1.1. Types of names 27](#types-of-names) [3.1.2. Need for Names to be Meaningful 27](#need-for-names-to-be-meaningful) [3.1.3. Anonymity or Pseudonymity of Subscribers 27](#anonymity-or-pseudonymity-of-subscribers) [3.1.4. Rules for Interpreting Various Name Forms 27](#rules-for-interpreting-various-name-forms) [3.1.5. Uniqueness of names 27](#uniqueness-of-names) [3.1.6. Recognition, Authentication, and Role of Trademarks 27](#recognition-authentication-and-role-of-trademarks) [3.2. Initial Identity Validation 28](#initial-identity-validation) [3.2.1. Method to Prove Possession of Private Key 28](#method-to-prove-possession-of-private-key) [3.2.2. Authentication of Organization Identity 28](#authentication-of-organization-identity) [3.2.3. Authentication of Individual Identity 30](#authentication-of-individual-identity) [3.2.4. Non-Verified Subscriber Information 31](#non-verified-subscriber-information) [3.2.5. Validation of Authority 31](#validation-of-authority) [3.2.6. Criteria for interoperation 31](#criteria-for-interoperation) [3.3. Identification and Authentication for Re-Key Requests 31](#identification-and-authentication-for-re-key-requests) [3.3.1. Identification and Authentication for Routine Re-Key 31](#identification-and-authentication-for-routine-re-key) [3.3.2. Identification and Authentication for Re-Key after Revocation - Uncompromised key 32](#identification-and-authentication-for-re-key-after-revocation---uncompromised-key) [3.4. Identification and Authentication for Revocation Request 32](#identification-and-authentication-for-revocation-request) [4. Certificate Life-Cycle Operational Requirements 33](#certificate-life-cycle-operational-requirements) [4.1. Certificate Application 33](#certificate-application) [4.1.1. Who can submit a certificate request 33](#who-can-submit-a-certificate-request) [4.1.2. Enrollment Process and Responsibilities 33](#enrollment-process-and-responsibilities) [4.2. Certificate Application Processing 33](#certificate-application-processing) [4.2.1. Performing identification and authentication functions 33](#performing-identification-and-authentication-functions) [4.2.2. Approval or Rejection of Certificate Applications 34](#approval-or-rejection-of-certificate-applications) [4.2.3. Time to Process Certificate Applications 34](#time-to-process-certificate-applications) [4.3. Certificate Issuance 34](#certificate-issuance) [4.3.1. CA Actions during Certificate Issuance 34](#ca-actions-during-certificate-issuance) [4.3.2. Notification to Subscriber by the CA of Issuance of Certificate 35](#notification-to-subscriber-by-the-ca-of-issuance-of-certificate) [4.3.3. Refusal to Issue a Certificate 35](#refusal-to-issue-a-certificate) [4.4. Certificate Acceptance 35](#certificate-acceptance) [4.4.1. Conduct Constituting Certificate Acceptance 35](#conduct-constituting-certificate-acceptance) [4.4.2. Publication of the Certificate by the CA 35](#publication-of-the-certificate-by-the-ca) [4.4.3. Notification of Certificate Issuance by the CA to Other Entities 35](#notification-of-certificate-issuance-by-the-ca-to-other-entities) [4.5. Key Pair and Certificate Usage 36](#key-pair-and-certificate-usage) [4.5.1. Subscriber Private Key and Certificate Usage 36](#subscriber-private-key-and-certificate-usage) [4.5.2. Relying Party Public Key and Certificate Usage 36](#relying-party-public-key-and-certificate-usage) [4.6. Certificate Renewal 36](#certificate-renewal) [4.6.1. Circumstances for certificate renewal 36](#circumstances-for-certificate-renewal) [4.6.2. Who May Request Renewal 36](#who-may-request-renewal) [4.6.3. Processing Certificate Renewal Requests 36](#processing-certificate-renewal-requests) [4.6.4. Notification of New Certificate Issuance to Subscriber 36](#notification-of-new-certificate-issuance-to-subscriber) [4.6.5. Conduct Constituting Acceptance of a Renewal Certificate 37](#conduct-constituting-acceptance-of-a-renewal-certificate) [4.6.6. Publication of the renewal certificate by the Certification Authority 37](#publication-of-the-renewal-certificate-by-the-certification-authority) [4.6.7. Notification of Certificate Issuance by the CA to Other Entities 37](#notification-of-certificate-issuance-by-the-ca-to-other-entities-1) [4.7. Certificate Re-key 37](#certificate-re-key) [4.7.1. Circumstances for Certificate Re-Key 37](#circumstances-for-certificate-re-key) [4.7.2. Who May Request certification of a new public key 37](#who-may-request-certification-of-a-new-public-key) [4.7.3. Processing Certificate Rekeying Requests 37](#processing-certificate-rekeying-requests) [4.7.4. Notification of new certificate issuance to Subscriber 37](#notification-of-new-certificate-issuance-to-subscriber-1) [4.7.5. Conduct Constituting Acceptance of a Re-Keyed Certificate 37](#conduct-constituting-acceptance-of-a-re-keyed-certificate) [4.7.6. Publication of the Re-Keyed Certificate by the CA 37](#publication-of-the-re-keyed-certificate-by-the-ca) [4.7.7. Notification of Certificate Issuance by the CA to Other Entities 37](#notification-of-certificate-issuance-by-the-ca-to-other-entities-2) [4.8. Certificate Modification 37](#certificate-modification) [4.8.1. Circumstance for Certificate Modification 37](#circumstance-for-certificate-modification) [4.8.2. Who May Request Certificate Modification 37](#who-may-request-certificate-modification) [4.8.3. Processing Certificate Modification Requests 38](#processing-certificate-modification-requests) [4.8.4. Notification of New Certificate Issuance to Subscriber 38](#notification-of-new-certificate-issuance-to-subscriber-2) [4.8.5. Conduct Constituting Acceptance of Modified Certificate 38](#conduct-constituting-acceptance-of-modified-certificate) [4.8.6. Publication of the Modified Certificate by the CA 38](#publication-of-the-modified-certificate-by-the-ca) [4.8.7. Notification of Certificate Issuance by the CA to Other Entities 38](#notification-of-certificate-issuance-by-the-ca-to-other-entities-3) [4.9. Certificate Revocation and Suspension 38](#certificate-revocation-and-suspension) [4.9.1. Circumstances for revocation 38](#circumstances-for-revocation) [4.9.1.1. Reasons to revoke a user certificate 38](#reasons-to-revoke-a-user-certificate) [4.9.1.2. Reasons to revoke a subordinate (intermediate) CA certificate 39](#reasons-to-revoke-a-subordinate-intermediate-ca-certificate) [4.9.2. Who Can Request Revocation 39](#who-can-request-revocation) [4.9.3. Procedure for Revocation Request 40](#procedure-for-revocation-request) [4.9.3.1. Interactive telematics 40](#interactive-telematics) [4.9.3.2. Telematic ACME 40](#telematic-acme) [4.9.3.3. Telephone 40](#telephone) [4.9.4. Revocation Request Grace Period 40](#revocation-request-grace-period) [4.9.5. Time Within which CA Must Process the Revocation Request 40](#time-within-which-ca-must-process-the-revocation-request) [4.9.6. Revocation Checking Requirement for Relying Parties 40](#revocation-checking-requirement-for-relying-parties) [4.9.7. CRL Issuance Frequency 40](#crl-issuance-frequency) [4.9.8. Maximum Latency for CRLs 41](#maximum-latency-for-crls) [4.9.9. On-Line Revocation/Status Checking Availability 41](#on-line-revocationstatus-checking-availability) [4.9.10. On-Line Revocation Checking Requirements 41](#on-line-revocation-checking-requirements) [4.9.11. Other Forms of Revocation Advertisements Available 41](#other-forms-of-revocation-advertisements-available) [4.9.12. Special Requirements for Key Compromise 41](#special-requirements-for-key-compromise) [4.9.13. Circumstances for suspension 42](#circumstances-for-suspension) [4.9.14. Who can Request Suspension 42](#who-can-request-suspension) [4.9.15. Procedure for Suspension Request 42](#procedure-for-suspension-request) [4.9.16. Limits on Suspension Period 42](#limits-on-suspension-period) [4.10. Certificate Status Services 42](#certificate-status-services) [4.10.1. Operational characteristics 42](#operational-characteristics) [4.10.2. Service availability 43](#service-availability) [4.10.3. Optional features 43](#optional-features) [4.11. End of subscription. 43](#end-of-subscription.) [4.12. Key Escrow and Recovery 43](#key-escrow-and-recovery) [4.12.1. Key Escrow and Recovery Policy and Practices 43](#key-escrow-and-recovery-policy-and-practices) [4.12.2. Session Key Encapsulation and Recovery Policy and Practices 43](#session-key-encapsulation-and-recovery-policy-and-practices) [4.13. Expiration of CA certificate keys. 43](#expiration-of-ca-certificate-keys.) [5. Facility, Management, and Operational Controls 44](#facility-management-and-operational-controls) [5.1. Physical Security Controls 44](#physical-security-controls) [5.1.1. Site Location and Construction 44](#site-location-and-construction) [5.1.2. Physical access 44](#physical-access) [5.1.3. Power and air conditioning 44](#power-and-air-conditioning) [5.1.4. Water Exposure 44](#water-exposure) [5.1.5. Fire Protection and Prevention 44](#fire-protection-and-prevention) [5.1.6. Media Storage 44](#media-storage) [5.1.7. Waste Disposal 44](#waste-disposal) [5.1.8. Off-Site Backup 44](#off-site-backup) [5.2. Procedural controls 45](#procedural-controls) [5.2.1. Reliable papers 45](#reliable-papers) [5.2.1.1. Management 45](#management) [5.2.1.2. Systems Administrator 45](#systems-administrator) [5.2.1.3. PRU Administrator. 46](#pru-administrator.) [5.2.1.4. Security Administrator. 46](#security-administrator.) [5.2.1.5. Certification Authority Operator 46](#certification-authority-operator) [5.2.1.6. User Registration Point Operator 47](#user-registration-point-operator) [5.2.1.7. Training, Support and Communications Manager 47](#training-support-and-communications-manager) [5.2.1.8. Security Manager 47](#security-manager) [5.2.1.9. Auditor 48](#auditor) [5.2.1.10. Legal Expert 48](#legal-expert) [5.2.1.11. Documentation Manager 48](#documentation-manager) [5.2.1.12. Deployment Support Manager 48](#deployment-support-manager) [5.2.1.13. Certification Authority Coordinator 49](#certification-authority-coordinator) [5.2.2. Number of persons required per task 49](#number-of-persons-required-per-task) [5.2.3. Identification and authentication for each role 49](#identification-and-authentication-for-each-role) [5.2.4. Roles requiring segregation of duties 49](#roles-requiring-segregation-of-duties) [5.3. Personnel security controls 49](#personnel-security-controls) [5.3.1. Qualifications, Experience, and Clearance Requirements 50](#qualifications-experience-and-clearance-requirements) [5.3.2. Background check procedures 50](#background-check-procedures) [5.3.3. Training requirements 50](#training-requirements) [5.3.4. Retraining Frequency and Requirements 50](#retraining-frequency-and-requirements) [5.3.5. Job Rotation Frequency and Sequence 50](#job-rotation-frequency-and-sequence) [5.3.6. Sanctions for Unauthorized Actions 50](#sanctions-for-unauthorized-actions) [5.3.7. Independent Contractor Requirements 51](#independent-contractor-requirements) [5.3.8. Documentation Supplied to Personnel 51](#documentation-supplied-to-personnel) [5.3.9. Periodic compliance checks 51](#periodic-compliance-checks) [5.3.10. Termination of contracts 51](#termination-of-contracts) [5.3.10.1. Access to organizational locations 51](#access-to-organizational-locations) [5.3.10.2. Access to Information Systems 52](#access-to-information-systems) [5.3.10.3. Access to documentation 52](#access-to-documentation) [5.3.10.4. Information to the rest of the organization 52](#information-to-the-rest-of-the-organization) [5.3.10.5. Information to suppliers and collaborating entities 52](#information-to-suppliers-and-collaborating-entities) [5.3.10.6. Return of material 52](#return-of-material) [5.3.10.7. Suspension as PRU Operator 52](#suspension-as-pru-operator) [5.4. Audit Logging Procedures 53](#audit-logging-procedures) [5.4.1. Types of events recorded 53](#types-of-events-recorded) [5.4.2. Frequency of Processing Log 53](#frequency-of-processing-log) [5.4.3. Retention Period for Audit Log 53](#retention-period-for-audit-log) [5.4.4. Protection of Audit Log 54](#protection-of-audit-log) [5.4.5. Audit log backup procedures 54](#audit-log-backup-procedures) [5.4.6. Audit information collection system (internal vs. external) 54](#audit-information-collection-system-internal-vs.-external) [5.4.7. Notification to the subject causing the event 54](#notification-to-the-subject-causing-the-event) [5.4.8. Vulnerability Assessments 54](#vulnerability-assessments) [5.5. Records Archival 54](#records-archival) [5.5.1. Types of Records Archived 54](#types-of-records-archived) [5.5.2. Retention Period for Archive 55](#retention-period-for-archive) [5.5.3. Protection of Archive 55](#protection-of-archive) [5.5.4. Archive Backup Procedures. 55](#archive-backup-procedures.) [5.5.5. Requirements for Time-Stamping of Records 55](#requirements-for-time-stamping-of-records) [5.5.6. Archive Collection System (Internal or External) 55](#archive-collection-system-internal-or-external) [5.5.7. Procedures to Obtain and Verify Archive Information 55](#procedures-to-obtain-and-verify-archive-information) [5.6. Key Changeover 55](#key-changeover) [5.7. Compromise and Disaster Recovery 55](#compromise-and-disaster-recovery) [5.7.1. Incident and Compromise Handling Procedures 55](#incident-and-compromise-handling-procedures) [5.7.2. Computing Resources, Software, and/or Data are corrupted 56](#computing-resources-software-andor-data-are-corrupted) [5.7.3. Entity Private Key Compromise Procedures 56](#entity-private-key-compromise-procedures) [5.7.4. Business Continuity Capabilities after a Disaster 56](#business-continuity-capabilities-after-a-disaster) [5.8. CA or RA Termination 56](#ca-or-ra-termination) [6. Technical Security Controls 58](#technical-security-controls) [6.1. Key Pair Generation and Installation 58](#key-pair-generation-and-installation) [6.1.1. Key pair generation 58](#key-pair-generation) [6.1.1.1. CA Key Pair Generation 58](#ca-key-pair-generation) [6.1.1.2. RA Key Pair Generation 58](#ra-key-pair-generation) [6.1.1.3. Subscriber Key Pair Generation 58](#subscriber-key-pair-generation) [6.1.1.3.1. Qualified Website Authentication Certificates 58](#qualified-website-authentication-certificates) [6.1.1.3.2. Electronic Administrative Headquarters Certificates in Hardware Secure Module 58](#electronic-administrative-headquarters-certificates-in-hardware-secure-module) [6.1.1.3.3. Electronic Administrative Headquarters Certificates based on software 59](#electronic-administrative-headquarters-certificates-based-on-software) [6.1.1.3.4. Server Authentication Certificates 59](#server-authentication-certificates) [6.1.2. Private Key Delivery to Subscriber 59](#private-key-delivery-to-subscriber) [6.1.3. Public Key Delivery to Certificate Issuer 59](#public-key-delivery-to-certificate-issuer) [6.1.4. CA Public Key Delivery to Relying Parties 59](#ca-public-key-delivery-to-relying-parties) [6.1.5. Key Sizes 59](#key-sizes) [6.1.6. Public Key Parameters Generation and Quality Checking 59](#public-key-parameters-generation-and-quality-checking) [6.1.7. Key Usage Purposes (as per X.509 v3 key usage field) 60](#key-usage-purposes-as-per-x.509-v3-key-usage-field) [6.1.8. Key generation hardware/software 60](#key-generation-hardwaresoftware) [6.1.8.1. CA Keys 60](#ca-keys) [6.1.8.2. Qualified Website Authentication Certificates 60](#qualified-website-authentication-certificates-1) [6.1.8.3. Electronic Administrative Headquarters Certificates in Hardware Secure Module 61](#electronic-administrative-headquarters-certificates-in-hardware-secure-module-1) [6.1.8.4. Electronic Administrative Headquarters Certificates based on software 61](#electronic-administrative-headquarters-certificates-based-on-software-1) [6.1.8.5. Server Authentication Certificates 61](#server-authentication-certificates-1) [6.2. Private Key Protection and Cryptographic Module Engineering Controls 61](#private-key-protection-and-cryptographic-module-engineering-controls) [6.2.1. Cryptographic Module Standards and Controls 61](#cryptographic-module-standards-and-controls) [6.2.1.1. CA Keys 61](#ca-keys-1) [6.2.1.2. Qualified Website Authentication Certificates 61](#qualified-website-authentication-certificates-2) [6.2.1.3. Electronic Administrative Headquarters Certificates in Hardware Secure Module 61](#electronic-administrative-headquarters-certificates-in-hardware-secure-module-2) [6.2.1.4. Electronic Administrative Headquarters Certificates based on software 62](#electronic-administrative-headquarters-certificates-based-on-software-2) [6.2.1.5. Server Authentication Certificates 62](#server-authentication-certificates-2) [6.2.2. Private Key (n out of m) Multi-Person Control 62](#private-key-n-out-of-m-multi-person-control) [6.2.3. Private Key Escrow 62](#private-key-escrow) [6.2.4. Private Key Backup 62](#private-key-backup) [6.2.5. Private Key Archival. 62](#private-key-archival.) [6.2.6. Private Key Transfer into or from a Cryptographic Module 62](#private-key-transfer-into-or-from-a-cryptographic-module) [6.2.6.1. CA Keys 62](#ca-keys-2) [6.2.6.2. Qualified Website Authentication Certificates 62](#qualified-website-authentication-certificates-3) [6.2.6.3. Electronic Administrative Headquarters Certificates in Hardware Secure Module 63](#electronic-administrative-headquarters-certificates-in-hardware-secure-module-3) [6.2.6.4. Electronic Administrative Headquarters Certificates based on software 63](#electronic-administrative-headquarters-certificates-based-on-software-3) [6.2.6.5. Server Authentication Certificates 63](#server-authentication-certificates-3) [6.2.7. Storage of the private key in the cryptographic module 63](#storage-of-the-private-key-in-the-cryptographic-module) [6.2.7.1. CA Keys 63](#ca-keys-3) [6.2.7.2. Qualified Website Authentication Certificates 63](#qualified-website-authentication-certificates-4) [6.2.7.3. Electronic Administrative Headquarters Certificates in Hardware Secure Module 63](#electronic-administrative-headquarters-certificates-in-hardware-secure-module-4) [6.2.7.4. Electronic Administrative Headquarters Certificates based on software 63](#electronic-administrative-headquarters-certificates-based-on-software-4) [6.2.7.5. Server Authentication Certificates 63](#server-authentication-certificates-4) [6.2.8. Method of Activating Private Key 63](#method-of-activating-private-key) [6.2.8.1. CA Keys 63](#ca-keys-4) [6.2.8.2. Qualified Website Authentication Certificates 63](#qualified-website-authentication-certificates-5) [6.2.8.3. Electronic Administrative Headquarters Certificates in Hardware Secure Module 64](#electronic-administrative-headquarters-certificates-in-hardware-secure-module-5) [6.2.8.4. Electronic Administrative Headquarters Certificates based on software 64](#electronic-administrative-headquarters-certificates-based-on-software-5) [6.2.8.5. Server Authentication Certificates 64](#server-authentication-certificates-5) [6.2.9. Method of Deactivating Private Key 64](#method-of-deactivating-private-key) [6.2.9.1. CA Keys 64](#ca-keys-5) [6.2.9.2. Qualified Website Authentication Certificates 64](#qualified-website-authentication-certificates-6) [6.2.9.3. Electronic Administrative Headquarters Certificates in Hardware Secure Module 64](#electronic-administrative-headquarters-certificates-in-hardware-secure-module-6) [6.2.9.4. Electronic Administrative Headquarters Certificates based on software 64](#electronic-administrative-headquarters-certificates-based-on-software-6) [6.2.9.5. Server Authentication Certificates 64](#server-authentication-certificates-6) [6.2.10. Method of Destroying Private Key 64](#method-of-destroying-private-key) [6.2.10.1. Cryptographic hardware 64](#cryptographic-hardware) [6.2.10.2. Cryptographic cards 65](#cryptographic-cards) [6.2.10.3. Qualified Website Authentication Certificates 65](#qualified-website-authentication-certificates-7) [6.2.10.4. Electronic Administrative Headquarters Certificates in Hardware Secure Module 65](#electronic-administrative-headquarters-certificates-in-hardware-secure-module-7) [6.2.10.5. Electronic Administrative Headquarters Certificates based on software 65](#electronic-administrative-headquarters-certificates-based-on-software-7) [6.2.10.6. Server Authentication Certificates 65](#server-authentication-certificates-7) [6.2.11. Cryptographic Module Rating 65](#cryptographic-module-rating) [6.3. Other Aspects of Key Pair Management. 65](#other-aspects-of-key-pair-management.) [6.3.1. Public Key Archival 65](#public-key-archival) [6.3.2. Certificate Operational Periods and Key Pair Usage Periods 65](#certificate-operational-periods-and-key-pair-usage-periods) [6.4. Activation Data 66](#activation-data) [6.4.1. Activation Data Generation and Installation 66](#activation-data-generation-and-installation) [6.4.1.1. Certification Authorities 66](#certification-authorities-1) [6.4.1.2. Qualified Website Authentication Certificates 66](#qualified-website-authentication-certificates-8) [6.4.1.3. Electronic Administrative Headquarters Certificates in Hardware Secure Module 66](#electronic-administrative-headquarters-certificates-in-hardware-secure-module-8) [6.4.1.4. Electronic Administrative Headquarters Certificates based on software 66](#electronic-administrative-headquarters-certificates-based-on-software-8) [6.4.1.5. Server Authentication Certificates 66](#server-authentication-certificates-8) [6.4.2. Activation Data Protection 66](#activation-data-protection) [6.4.2.1. Certification Authorities 66](#certification-authorities-2) [6.4.2.2. Qualified Website Authentication Certificates 66](#qualified-website-authentication-certificates-9) [6.4.2.3. Electronic Administrative Headquarters Certificates in Hardware Secure Module 66](#electronic-administrative-headquarters-certificates-in-hardware-secure-module-9) [6.4.2.4. Electronic Administrative Headquarters Certificates based on software 66](#electronic-administrative-headquarters-certificates-based-on-software-9) [6.4.2.5. Server Authentication Certificates 66](#server-authentication-certificates-9) [6.4.3. Other Aspects of Activation Data 66](#other-aspects-of-activation-data) [6.5. Computer Security Controls 67](#computer-security-controls) [6.5.1. Specific Computer Security Technical Requirements 67](#specific-computer-security-technical-requirements) [6.5.2. Computer Security Rating 67](#computer-security-rating) [6.6. Lifecycle Technical Controls 67](#lifecycle-technical-controls) [6.6.1. System Development Controls 67](#system-development-controls) [6.6.2. Security Management Controls 68](#security-management-controls) [6.6.3. Lifecycle Security Controls 68](#lifecycle-security-controls) [6.7. Network Security Controls 68](#network-security-controls) [6.8. Time-Stamping 69](#time-stamping) [7. Certificate, CRL and OCSP Profiles 70](#certificate-crl-and-ocsp-profiles) [7.1. Certificate Profile 70](#certificate-profile) [7.1.1. Version number 70](#version-number) [7.1.2. Certificate Extensions; implementation of RFC 5280 70](#certificate-extensions-implementation-of-rfc-5280) [7.1.2.1. Root CAs 70](#root-cas) [7.1.2.2. Subordinate Cas 71](#subordinate-cas) [7.1.2.3. Subscriber Certificates 72](#subscriber-certificates) [7.1.2.3.1. Qualified Website Authentication Certificates 72](#qualified-website-authentication-certificates-10) [7.1.2.3.2. Electronic Administrative Headquarters Certificates in Hardware Secure Module 74](#electronic-administrative-headquarters-certificates-in-hardware-secure-module-10) [7.1.2.3.3. Electronic Administrative Headquarters Certificates based on software 76](#electronic-administrative-headquarters-certificates-based-on-software-10) [7.1.2.3.4. Server Authentication Certificates 78](#electronic-administrative-headquarters-certificates-based-on-software-11) [7.1.3. Object Identifiers (OID) of the algorithms 80](#object-identifiers-oid-of-the-algorithms) [7.1.3.1. SubjectPublicKeyInfo 80](#subjectpublickeyinfo) [7.1.3.1.1. RSA 80](#rsa) [7.1.3.1.2. ECDSA 81](#ecdsa) [7.1.3.2. Signature algorithm identifier 81](#signature-algorithm-identifier) [7.1.3.2.1. RSA 81](#rsa-1) [7.1.3.2.2. ECDSA 82](#ecdsa-1) [7.1.4. Name Forms 82](#name-forms) [7.1.4.1. Name Encoding 84](#name-encoding) [7.1.5. Name Constraints 84](#name-constraints) [7.1.6. Certification Policy Object Identifier (OID) 84](#certification-policy-object-identifier-oid) [7.1.6.1. Qualified Website Authentication Certificates 84](#server-authentication-certificates-11) [7.1.6.2. Electronic Administrative Headquarters Certificates in Hardware Secure Module 85](#qualified-website-authentication-certificates-12) [7.1.6.3. Electronic Administrative Headquarters Certificates based on software 85](#electronic-administrative-headquarters-certificates-based-on-software-11) [7.1.6.4. Server Authentication Certificates 86](#server-authentication-certificates-11) [7.1.7. Usage of Policy Constraints Extension 86](#usage-of-policy-constraints-extension) [7.1.8. Policy Qualifiers Syntax and Semantics 86](#policy-qualifiers-syntax-and-semantics) [7.1.9. Processing Semantics for the Critical Certificate Policies Extension 86](#processing-semantics-for-the-critical-certificate-policies-extension) [7.1.10. Signed Certificate Timestamp (SCT) List 86](#signed-certificate-timestamp-sct-list) [7.2. CRL Profile 87](#crl-profile) [7.2.1. Version number 87](#version-number-1) [7.2.2. CRL and extensions 87](#crl-and-extensions) [7.3. OCSP Profile 88](#ocsp-profile) [7.3.1. Version number 88](#version-number-2) [7.3.2. OCSP extensions 88](#ocsp-extensions) [8. COMPLIANCE AUDIT AND OTHER ASSESSMENTS 89](#compliance-audit-and-other-assessments) [8.1. Frequency or Circumstances of Assessment 89](#frequency-or-circumstances-of-assessment) [8.2. Identity/Qualifications of Assessor 89](#identityqualifications-of-assessor) [8.3. Assessor\'s Relationship to Assessed Entity 89](#assessors-relationship-to-assessed-entity) [8.4. Topics Covered by Assessment 90](#topics-covered-by-assessment) [8.5. Actions Taken as a Result of Deficiency 90](#actions-taken-as-a-result-of-deficiency) [8.6. Communication of Results 90](#communication-of-results) [8.7. Self-Audits 91](#self-audits) [9. OTHER BUSINESS AND LEGAL MATTERS 92](#other-business-and-legal-matters) [9.1. Fees 92](#fees) [9.1.1. Certificate Issuance or Renewal Fees 92](#certificate-issuance-or-renewal-fees) [9.1.2. Certificate Access Fees 92](#certificate-access-fees) [9.1.3. Revocation or Status Information Access Fees 92](#revocation-or-status-information-access-fees) [9.1.4. Fees for Other Services 92](#fees-for-other-services) [9.1.5. Refund Policy 92](#refund-policy) [9.2. Financial Responsibility 92](#financial-responsibility) [9.2.1. Insurance Coverage 92](#insurance-coverage) [9.2.2. Other assets 92](#other-assets) [9.2.3. Insurance or Warranty Coverage for end-entities 92](#insurance-or-warranty-coverage-for-end-entities) [9.3. Confidentiality of Business Information 92](#confidentiality-of-business-information) [9.3.1. Scope of Confidential Information. 92](#scope-of-confidential-information.) [9.3.2. Information Not Within the Scope of Confidential Information 93](#information-not-within-the-scope-of-confidential-information) [9.3.3. Responsibility to Protect Confidential Information 93](#responsibility-to-protect-confidential-information) [9.4. Privacy of Personal Information 93](#privacy-of-personal-information) [9.4.1. Privacy Plan 93](#privacy-plan) [9.4.2. Information Treated as Private 94](#information-treated-as-private) [9.4.3. Information not Deemed Private 95](#information-not-deemed-private) [9.4.4. Responsibility to Protect Private Information 95](#responsibility-to-protect-private-information) [9.4.5. Notice and Consent to Use Private Information 95](#notice-and-consent-to-use-private-information) [9.4.6. Disclosure Pursuant to Judicial or Administrative Process 95](#disclosure-pursuant-to-judicial-or-administrative-process) [9.4.7. Other Information Disclosure Circumstances 96](#other-information-disclosure-circumstances) [9.5. Intellectual Property Rights 96](#intellectual-property-rights) [9.6. Representations and Warranties 96](#representations-and-warranties) [9.6.1. CA Representations and Warranties 96](#ca-representations-and-warranties) [9.6.2. RA Representations and Warranties 98](#ra-representations-and-warranties) [9.6.3. Subscriber Representations and Warranties 99](#subscriber-representations-and-warranties) [9.6.4. Relying Party Representations and Warranties 99](#relying-party-representations-and-warranties) [9.6.5. Representations and Warranties of other Participants 100](#representations-and-warranties-of-other-participants) [9.7. Disclaimer of Warranties 100](#disclaimer-of-warranties) [9.8. Limitations of Liability 100](#limitations-of-liability) [9.9. Indemnities 101](#indemnities) [9.10. Term and Termination 101](#term-and-termination) [9.10.1. Term. 101](#term.) [9.10.2. Termination. 101](#termination.) [9.10.3. Effect of Termination and Survival. 101](#effect-of-termination-and-survival.) [9.11. Individual Notices and Communications with Participants 102](#individual-notices-and-communications-with-participants) [9.12. Amendments 102](#amendments) [9.12.1. Procedure for Amendment 102](#procedure-for-amendment) [9.12.2. Notification Mechanism and Period 102](#notification-mechanism-and-period) [9.12.3. Circumstances Under Which OID Must be Changed 102](#circumstances-under-which-oid-must-be-changed) [9.13. Dispute Resolution Provisions 102](#dispute-resolution-provisions) [9.14. Governing Law 103](#governing-law) [9.15. Compliance with Applicable Law 103](#compliance-with-applicable-law) [9.16. Miscellaneous Provisions 103](#miscellaneous-provisions) [9.16.1. Entire Agreement 103](#entire-agreement) [9.16.2. Assignment 104](#assignment) [9.16.3. Severability 104](#severability) [9.16.4. Enforcement (Attorneys\' Fees and Waiver of Rights) 104](#enforcement-attorneys-fees-and-waiver-of-rights) [9.16.5. Force Majeure 104](#force-majeure) [9.17. Other Provisions 104](#other-provisions) [10. Annex I 105](#annex-i) [10.1. Qualified Website Authentication Certificates 105](#qualified-website-authentication-certificates-12) [10.2. Electronic Administrative Headquarters Certificates in Hardware Secure Module 107](#electronic-administrative-headquarters-certificates-in-hardware-secure-module-12) [10.3. Electronic Administrative Headquarters Certificates based on software 109](#electronic-administrative-headquarters-certificates-based-on-software-12) [10.4. Server Authentication Certificates 111](#server-authentication-certificates-12) # INTRODUCTION ## Overview This document contains the *Declaration of Certification Practices and Policies (CPS)* of the Agencia de Tecnología y Certificación Electrónica in the issuance of website authentication certificates. The Agency of Technology and Electronic Certification (ACCV) is part of Infraestructures i Serveis de Telecomunicacions i Certificació, SAU (ISTEC), public law entity with its own legal personality and full capacity to fulfill its purposes, which is governed by its Statutes. In accordance with the above, in compliance with current legislation and aligned with Regulation (EU) No. 910/2014 of the European Parliament and of the Council of 23 July 2014 on electronic identification and trust services for electronic transactions in the internal market and repealing Directive 1999/93/EC and its amendment in Regulation (EU) 2024/1183 of the European Parliament and of the Council of 11 April 2024 amending Regulation (EU) n.° 910/2014 regarding the establishment of the European digital identity framework, this Declaration of Certification Practices and Policies (CPS) details the rules and general conditions of the certification services provided by the Agencia de Tecnología y Certificación Electrónica, in relation to the management of signature creation and verification data and electronic certificates, the conditions applicable to the request, issuance, use, suspension and termination of the validity of the certificates, the technical and organizational security measures, profiles and information mechanisms on the validity of the certificates and, where appropriate, the existence of coordination procedures with the corresponding public registries that allow the immediate exchange of information on the validity of the powers of attorney indicated in the certificates and that must be registered in these registries, always in the scope of website authentication certificates. Thus, this Certification Practices Statement is the compendium of standards applicable to the certification activity of the Agencia de Tecnología y Certificación Electrónica (ACCV) as a Qualified Trust Service Provider in the issuance of website authentication certificates. It should also be noted that this Certification Policy and Practices Statement is drafted following the specifications of RFC 3647 *\"Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework*\" proposed by the *Network Working Group* for this type of documents. Finally, it should be noted that the Agencia de Tecnología y Certificación Electrónica (ACCV) follows the current version of the document \"*Baseline Requirements for* *the Issuance and Management of Publicly-Trusted Certificates*\" published in https://wwww.cabforum.org/. In the case of any incompatibility between this document and the CAB Forum requirements, these requirements will prevail. ACCV will NOT issue official certificates signed by Certification Authorities that have not passed the necessary audits and certifications in each case. ## Document Name and Identification +------------------+---------------------------------------------------+ | Name of document | Certification Practices and Policies for website | | | authentication certificates | +------------------+---------------------------------------------------+ | Document version | 4.0.17 | +------------------+---------------------------------------------------+ | Document status | APPROVED | +------------------+---------------------------------------------------+ | CPS/ OID (Object | 1.3.6.1.4.1.1.8149.2.4.0 | | Identifier) | | | Reference | | +------------------+---------------------------------------------------+ | Date of issue | 03/06/2025 | +------------------+---------------------------------------------------+ | Expiration date | Not applicable. | +------------------+---------------------------------------------------+ | Location | This CPS can be found at | | | http://www.accv.es/pdf-politicas | +------------------+---------------------------------------------------+ ## Website Authentication Certificate is a type of certificate used to confirm the identity of the website to which users connect, using public key cryptography techniques and by using well-established protocols that provide data encryption and authentication between applications and servers (TLS/SSL). The following types of certificates are issued under this CPS: +---------------------------------------------------+------------------+ | **Name** | **OID owner** | +---------------------------------------------------+------------------+ | Qualified Website Authentication Certificates | 1.3.6.1. | | | 4.1.8149.3.3.5.0 | +---------------------------------------------------+------------------+ | Qualified Certificates of electronic | 1.3.6.1.4 | | administrative headquarter in hardware secure | .1.8149.3.14.6.0 | | module -HSM-. | | +---------------------------------------------------+------------------+ | Qualified Certificates of electronic | 1.3.6.1.4 | | administrative headquarters based on software | .1.8149.3.15.6.0 | +---------------------------------------------------+------------------+ | Server Authentication Certificates | 1.3.6.1.4 | | | .1.8149.3.36.2.0 | +---------------------------------------------------+------------------+ All certificates issued under this CPS are OV (Organization Validated), which means that they follow at least the OVCP issuance and management requirements as described in ## PKI Participants ### Certification Authorities In this Certification Practice Statement, the acronym \"ACCV\" will be used to designate the Certification Authorities that make up the Agencia de Tecnología y Certificación Electrónica. The Certification Authorities that make up ACCV are structured in several certification hierarchies, composed of several root and subordinate Certification Authorities. The hierarchies under the scope of application of this CPS are made up of the following certification authorities #### Root Certification Authorities > First level Certification Authority. Its function is to establish the > root of the new trust model of the Public Key Infrastructure or PKI. > This CA does not issue certificates for end entities. This first level > Certification Authority is self-signed, issuing a certificate whose > signer is the Certification Authority itself, and which contains the > public key (or signature verification data) signed with the signature > creation data (private key). ##### ACCVRAIZ1 - C=EN,O=ACCV,OU=PKIACCV,CN=ACCVRAIZ1 - Fingerprint (HASH) SHA1: - **93057A8815C64FCE882FFA9116522878BC536417** - Fingerprint (HASH) SHA256: - **9A6EC012E1A7DA9DBE34194D478AD7C0DB1822FB071DF12981496ED104384113** > Valid from May 5, 2011 to December 31, 2030. > > Key type: RSA 4096 bits - SHA1 ##### ACCV ROOT ECC TLS 2024 - CN=ACCV ROOT ECC TLS 2024,2.5.4.97=VATES-A40573396,O=ISTEC,L=BURJASSOT,ST=VALENCIA,C=ES - Fingerprint (HASH) SHA1: - **2E529E361D817B33E1FE095E91A4EB969458B3F4** - Fingerprint (HASH) SHA256: - **79CD55455296ADFB55CDF0DBE9176985A0B503C544276C5A9305F2EC9B66693A** > Valid from February 27, 2024 to January 26, 2049. > > Key type: ECDSA P384 SHA384 ##### ACCV ROOT RSA TLS 2024 - CN=ACCV ROOT RSA TLS 2024,2.5.4.97=VATES-A40573396,O=ISTEC,L=BURJASSOT,ST=VALENCIA,C=ES - Fingerprint (HASH) SHA1: - **970ABA25EC3D78649B305BA75F8C914C275D8654** - Fingerprint (HASH) SHA256: - **B40BFA8880A02F93025643C6DBBD39DF194A2854D076E167A2BD8467CF9E2C34** > Valid from February 27, 2024 to January 26, 2049. > > Key type: RSA 4096 SHA512 #### Subordinate Certification Authorities > **- ACCVRAIZ1** root - \"ACCVCA-110\" Valid from May 7, 2015 until January 1, 2027. > SHA256 Fingerprint: > > **E9327A347CBE1CB94CDC9AA54CB31B6E43D68968D17D09CE326A091BFC2F0B11** > > SHA1 Fingerprint: > > **677CDF63B95E9EAEAE696F44506718FE0D2F6E41** > > Key type: RSA 4096 bits - SHA256 - \"ACCVCA-120. Valid from January 27, 2015 to January 01, 2027. > SHA256 Fingerprint: > > **2DE620F2D1200AA90B16C3CCF670FD7ED14379AB06FA8B031CFEF8DA051EA5A2** > > SHA1 Fingerprint: > > **4872A4C3DF174CEF34D77FE6A3B4E7BE7DF2D25D** > > Key type: RSA 4096 bits - SHA256 - \"ACCVCA-130\" Valid from January 15, 2015 to January 1, 2027. > SHA256 Fingerprint: > > **572BF899FD774362DC19219625ECC157BB55434EA5166D5758DC4B4F890D6653** > > SHA1 Fingerprint: > > **0055B77F432B54245406068CC8F77805C325DCF5** > > Key type: RSA 4096 bits - SHA256 > > **- ACCV ROOT** root **ECC TLS 2024** - \"ACCV ECC1 TLS\" Valid from February 27, 2024 to February 23, 2039. SHA256 Fingerprint: **93C087AB9331B74C0FCCCE11BC61FB9FA6D432077D8F1018194FA4CCA664D781** SHA1 Fingerprint: **4F35E0547A8E74D9D3EC1B260F0F9AD4809246E3** Key type: ECDSA P384 SHA384 > **- ACCV ROOT RSA TLS 2024 ACCV ROOT RSA TLS 2024** Root - \"ACCV RSA1 TLS\" Valid from February 27, 2024 to February 23, 2039. SHA256 Fingerprint: **346440CF7674A529305545563322FCFB38F5A4B3F1E7E852DFF8A4B7A5EF72D1** SHA1 Fingerprint: **D9698B1190136DAE3C3B0164329D050AB84D416D** Key type: RSA 4096 SHA512 > ![](media/image2.png){width="5.557638888888889in" > height="5.701388888888889in"} ### Registration Authorities The only Registration Authority for website authentication certificates is ACCV, and performs the identification and verification of the applicant and verification of all data included in the certificate, with special emphasis on the verifications necessary to verify the possession of the domain or domains by the certificate applicant. To this end, the Registration Authority will ensure that the certificate application contains truthful and complete information, and that it complies with the requirements of the corresponding Policy. The basic functions of the Registration Authority extend to: - Verify the identity and any personal circumstances of certificate applicants relevant to the purpose of the certificate. - Prior to the issuance of the certificate, inform the person requesting it of the precise conditions for the use of the certificate and its limitations of use. - Verify that the information contained in the certificate is accurate and that it includes all the information prescribed for a certificate of the type in question. - Ensure that the signatory is in possession of the signature creation data corresponding to the verification data contained in the certificate. - Verify by the established and accepted methods for this type of certificates the possession of the domain or domains by the applicant. ### Subscribers The group of users that can request certificates defined by this policy is made up of those responsible for public or private entities, in a position to represent the requesting entity. In the case of public entities, requests can be made by Heads of Service or equivalent organizational positions in any type of Public Administration (European, state, regional and local), who are ultimately responsible for their use within the different projects or information systems. These (or to whom they explicitly delegate) are the only subscribers authorized to request e-Office certificates. In the case of private entities, the certificates may be requested by those persons with the capacity to represent the entity or who have been authorized to manage this type of certificates. The right to request certificates defined in this Certification Policy is limited to individuals. Certification requests made by legal persons, entities or organizations will not be accepted without a natural person identified as the applicant. ### Relying parties The right to rely on certificates issued in accordance with these practices and policies is limited to: 1. Users of application clients in the area of identity verification of the websites they connect to and encryption of the channel of data transmitted between them. 2. Applications and services with SSL and/or TLS support capabilities, in the field of verification of the identity of the websites to which they connect, and of the encryption of the channel of the data transmitted between them. ### Other participants #### **Applicants** An Applicant is the natural person who, in his own name or as representative of a third party, and after identification, requests the issuance of a Certificate.\ In the case of Certificate Applicants whose Subscriber is a legal entity, such natural person may only be a legal or voluntary representative or an administrator with sufficient powers for this purpose of the legal entity that will be the subscriber of the certificate. ## Certificate Usage The Certification Policies corresponding to each type of certificate issued by ACCV are the documents that determine the uses and limitations of each certificate. This CPS establishes the uses and limitations for certificates issued for website authentication.. ### Appropriate Certificate Uses Certificates issued by ACCV under this CPS can be used to provide websites with SSL/TLS capabilities. Also, and as long as the uses allow it, they can be used as a mechanism to identify these sites unequivocally to services and software applications. The Certificates of Electronic Administrative Headquarters are a subset of Website Authentication Certificates, which are issued as identification systems of an Electronic Administrative Headquarters that guarantees secure communication with it, in the terms defined in Law 40/2015, of October 1, on the Legal Regime of the Public Sector and in Law 18/2011, of July 5, regulating the use of information and communication technologies in the Administration of Justice. ### Prohibited Certificates Uses Certificates issued by ACCV for website authentication will be used only in accordance with the function and purpose established in this Certification Practices and Policies Statement, and in accordance with current regulations. ## ACCV Policy Administration ### Organization Administering the Document +----------------+----------------------------------------------------:+ | Name | *Agencia de Tecnología y Certificación Electrónica* | +----------------+-----------------------------------------------------+ | E-mail address | *accv@accv.es* | +----------------+-----------------------------------------------------+ | Address | *Pol. Ademuz, s/n.- 46100 Burjassot (Spain)* | +----------------+-----------------------------------------------------+ | Telephone | *+34 963 866 014* | | number | | +----------------+-----------------------------------------------------+ ### Contact Person +-----------------+---------------------------------------------------:+ | Name | *Agencia de Tecnología y Certificación | | | Electrónica* | +-----------------+----------------------------------------------------+ | E-mail address | *accv@accv.es* | +-----------------+----------------------------------------------------+ | Address | *Pol. Ademuz, s/n. - 46100 Burjassot (Spain)* | +-----------------+----------------------------------------------------+ | Telephone | *+34 963 866 014* | | number | | +-----------------+----------------------------------------------------+ #### Problem Reporting Address The user can provide information regarding compromised keys or incorrect certificates by using the form [https://www.accv.es/contacta/.](https://www.accv.es/contacta/) In the form the user can paste the certificate or keys in PEM format, including the BEGIN and END lines. You can also use directly the address for sending detected problems (the form sends a copy to that address). In the case of ACME certificates, the account owner can use the mechanism enabled following the protocol for revocation: ### Person determining CPS suitability for the policy The competent entity to determine the adequacy of this CPS is Infraestructures i Serveis de Telecomunicacions i Certificació, SA (ISTEC) in accordance with its bylaws. ### CPS approval procedures ISTEC approves the CPS and its possible modifications. Modifications are made by updating the entire CPS or by publishing an addendum. ISTEC determines whether a modification to this CPS requires a notification or an OID change. ISTEC will review its certification policies and practices and update this Certification Policy and Practice Statement annually to keep it in line with the latest version of the requirements defined in \"Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates\", published at https://www.cabforum.org/, increasing the version number and adding a dated changelog entry, even if no other changes were made to the document. ## Definitions and Acronyms ### Definitions For the purpose of determining the scope of the concepts that are used in this Certification Practices Statement, it shall be understood as follows: - Certification Authority: is the natural or legal person that, in accordance with the legislation on electronic signatures, issues electronic certificates, and may also provide other services related to electronic signatures. For the purposes of this Certification Practices Statement, Certification Authorities are all those defined as such. - Registration Authority: natural or legal person that ACCV designates to verify the identity of applicants and subscribers of certificates, and if applicable, the validity of the powers of representatives and subsistence of legal personality or voluntary representation. In ACCV they are also called User Registration Points or PRU. - Bastioning: is the process by which a specific security policy is implemented on an operating system installation. The bastioning of a computer is intended to reduce the level of exposure of a computer and, therefore, the risks and vulnerabilities associated with it. - Certification chain: list of certificates containing at least one certificate and ACCV root certificate. - Certificate: electronic document electronically signed by a Certification Service Provider that binds the subscriber to signature verification data and confirms the identity of the subscriber. In this Certification Practices Statement, when reference is made to a certificate, it means a Certificate issued by ACCV. - Root certificate: Certificate whose subscriber is ACCV and belongs to the hierarchy of ACCV as Certification Service Provider, and contains the signature verification data of the Certification Service Provider, signed with the signature creation data of ACCV as Certification Service Provider. - Qualified certificate: certificate issued by a Trusted Service Provider that meets the requirements established in Regulation (EU) No. 910/2014 of the European Parliament and of the Council of 23 July 2014 regarding the verification of the identity and other circumstances of the applicants and the reliability and guarantees of the certification services they provide. To be considered as a qualified certificate it must appear on the trusted list (TSL) referred to in Article 22(1) of that Regulation. - Websites Authentication Certificate: A Certificate that authenticates a website and links the website to the natural or legal person to whom the Certificate has been issued. - OV Certificate: Web site authentication certificate issued according to the Organization Validation Policy (OVCP), guaranteeing the user that the owner of the web site he/she is accessing is the same as the Organization identified by the OV Certificate. - Electronic Headquarters Certificate: Certificate of authentication of websites that identifies an Electronic Headquarters, guaranteeing secure communication with the same in the terms defined in Law 40/2015, of October 1, 2015, of the Public Sector Legal Regime. - Key: sequence of symbols. - Signature creation data (Private Key): unique data, such as codes or private cryptographic keys, used by the subscriber to create the electronic signature. - Signature verification data (Public Key): data, such as codes or public cryptographic keys, used to verify the electronic signature. - Certification Practices Statement: ACCV\'s statement made available to the public electronically and free of charge by the Certification Service Provider in compliance with the provisions of the Law. - Secure Signature Creation Device: instrument used to apply signature creation data complying with the requirements set forth in Regulation (EU) No 910/2014 (Annex II Requirements for Qualified Electronic Signature Creation Devices). - Certificate Directory: repository of information that follows the ITU-T X.500 standard. - Electronic document: information of any nature in electronic form, stored in an electronic support according to a specific format, and susceptible of identification and differentiated treatment. - Register of Activities: document required by Regulation (EU) 2016/679 whose purpose is to establish the security measures implemented, for the purposes of this document, by ACCV as Certification Service Provider, for the protection of personal data contained in the files of the certification activity that contain personal data (hereinafter the Files). - Data Processor: the natural or legal person, public authority, service or any other body that processes personal data on behalf of the controller of the files. - Qualified electronic signature: an advanced electronic signature based on a qualified certificate and generated by means of a qualified signature creation device. - Advanced electronic signature: is an electronic signature that allows to establish the personal identity of the subscriber with respect to the signed data and to verify the integrity of the same, since it is exclusively linked to the subscriber and to the data to which it refers, and because it has been created by means that are under the subscriber\'s exclusive control. - Electronic signature: is the set of data in electronic form, consigned together or associated with others, which can be used as a means of personal identification. - Hash function: is an operation performed on a set of data of any size, so that the result obtained is another set of data of fixed size, regardless of the original size, and which has the property of being uniquely associated to the initial data, i.e., it is impossible to find two different messages that generate the same result when applying the hash function. - Hash or Fingerprint: a fixed-size result obtained after applying a hash function to a message and which has the property of being uniquely associated with the initial data. - Public Key Infrastructure (PKI): infrastructure that supports the issuance and management of keys and certificates for authentication, encryption, integrity, or non-repudiation services. - Certificate Revocation Lists or Revoked Certificates Lists: list containing only the lists of revoked or suspended certificates (not expired ones). - Cryptographic Security Hardware Module: hardware module used to perform cryptographic functions and store keys in secure mode. - Certificate Serial Number: a unique integer value that is unequivocally associated with a certificate issued by CA. - Multi-Perspective Issuance Corroboration: A process by which the determinations made during domain validation and CAA checking by the Primary Network Perspective are corroborated by other Network Perspectives before Certificate issuance. - OCSP (Online Certificate Status Protocol): computer protocol that allows the status of a certificate to be checked at the time it is used. - OCSP Responder: computer server that responds, following the OCSP protocol, to OCSP requests with the status of the certificate being queried. - OID (Object Identifier): value of hierarchical nature and comprising a sequence of variable components, but always consisting of non-negative integers separated by a dot, which can be assigned to registered objects and which have the property of being unique among the rest of the OIDs. - OCSP Request: request for a certificate status query to OCSP Responder following the OCSP protocol. - PIN: (Personal Identification Number) specific number only known by the person who has to access a resource that is protected by this mechanism. - Certification Service Provider: is a natural or legal person who, in accordance with the legislation on electronic signatures, issues electronic certificates, and may also provide other services related to electronic signatures. In this Certification Practices Statement will correspond to the Certification Authorities belonging to ACCV hierarchy. - Certification Policy: document that completes the Certification Practices Statement, establishing the conditions of use and procedures followed by ACCV to issue Certificates. - PKCS#10 (Certification Request Syntax Standard): standard developed by RSA Labs, and accepted internationally as a standard, which defines the syntax of a certificate request. - Pre-certificate: Signed data structure that can be sent to a Certificate Tramsparency log, as defined in RFC 6962. - PUK: (Personal Unblocking Key) a specific number or key known only to the person who has to access a resource that is used to unlock access to that resource. - CAA records: DNS (Domain Name System) Certification Authority Authorization (CAA) resource record. It allows a DNS domain name holder to specify the Certification Authorities (CAs) authorized to issue certificates for that domain. The publication of CAA resource records allows a domain name registrant to implement additional controls to reduce the risk of unauthorized issuance. - File Manager (or File Processor): the person who decides on the purpose, content and use of the processing of the Files. - Security Manager: in charge of coordinating and controlling the measures imposed by the security document regarding the files. - Electronic headquarters: Electronic address, available to citizens through telecommunications networks, whose ownership corresponds to a Public Administration, or to one or more public bodies or Public Law entities in the exercise of their competences. - SHA Secure Hash Algorithm. A family of encryption hash functions published by the National Institute of Standards and Technology (NIST). The first version of the algorithm was created in 1993 under the name SHA, although it is now known as SHA-0 to avoid confusion with later versions. The second version of the system, published under the name SHA-1, was released two years later. Subsequently, SHA-2 has been published in 2001 (consisting of several functions: SHA-224, SHA-256, SHA-384, and SHA-512) and the most recent, SHA-3, which was selected in a hash function competition held by NIST in 2012). The algorithm consists of taking messages of less than 264 bits and generating a fixed-length digest. The probability of finding two different messages that produce the same digest is practically zero. For this reason it is used to ensure the integrity of documents during the electronic signature process. - Time-Stamping: The date and time stamping of an electronic document by means of indelible cryptographic procedures, based on the specifications Request For Comments: 3161 - \"Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP)\", which enables the document to be objectively dated. - Applicant: natural person who requests the issuance of a certificate. - Subscriber (or Subject): the certificate holder or signer. The person whose personal identity is linked to the electronically signed data, through a public key certified by the Certification Service Provider. The concept of subscriber will be referred to in the certificates and in the software applications related to their issuance as Subject, for strict reasons of international standardization. - Cryptographic card: card used by the subscriber to store private signature and decryption keys, to generate electronic signatures and decrypt data messages. It is considered a secure signature creation device in accordance with the Electronic Signature Law and allows the generation of recognized electronic signatures. - Relying third parties or trusting parties: those persons who place their trust in an ACCV certificate, verifying the validity and validity of the certificate as described in this Certification Practices Statement and in the Certification Policies associated with each type of certificate. - X.500: standard developed by the ITU that defines the directory recommendations. It corresponds to the ISO/IEC 9594-1: 1993 standard. It gives rise to the following series of recommendations: X.501, X.509, X.511, X.518, X.519, X.520, X.521 and X.525. - X.509: standard developed by the ITU, which defines the basic electronic format for electronic certificates. ### Acronyms +------------+---------------------------------------------------------+ | ACCV | Agencia de Tecnología y Certificación Electrónica | +------------+---------------------------------------------------------+ | CA | Certification Authority | +------------+---------------------------------------------------------+ | CN | Common Name | +------------+---------------------------------------------------------+ | CP | Certificate Policy | +------------+---------------------------------------------------------+ | CPS | Certification Practice Statement | +------------+---------------------------------------------------------+ | CRL | Certificate Revocation List | +------------+---------------------------------------------------------+ | DGTIC GVA | Directorate General of Information and Communication | | | Technologies Generalitat Valenciana | +------------+---------------------------------------------------------+ | FIPS | Federal Information Processing Standard | +------------+---------------------------------------------------------+ | IETF | Internet Engineering Task Force | +------------+---------------------------------------------------------+ | IVF | Valencian Institute of Finance | +------------+---------------------------------------------------------+ | ISTEC | Telecommunication Infrastructures and Services and | | | Certification | +------------+---------------------------------------------------------+ | OID | Object identifier | +------------+---------------------------------------------------------+ | OCSP | On-line Certificate Status Protocol | +------------+---------------------------------------------------------+ | OPRU | Registration Point Operator | +------------+---------------------------------------------------------+ | OV | Organization Validated | +------------+---------------------------------------------------------+ | PKI | Public Key Infrastructure | +------------+---------------------------------------------------------+ | PKIGVA | ACCV PKI | +------------+---------------------------------------------------------+ | PRU | User Registration Point | +------------+---------------------------------------------------------+ | RA | Registration Authority | +------------+---------------------------------------------------------+ | RFC | Request For Comment | +------------+---------------------------------------------------------+ | SSL | Secure Sockets Layer | +------------+---------------------------------------------------------+ | Sub CA | Subordinate Certification Authority | +------------+---------------------------------------------------------+ | TLS | Transport Security Layer | +------------+---------------------------------------------------------+ # Publication and Repository Responsibilities ## Certificate repository The certificate repository service will be available 24 hours a day, 7 days a week, and in case of interruption due to force majeure, the service will be restored as soon as possible. ACCV repository is composed of: OCSP server according to RFC-6960 accessible at: [http://ocsp.accv.es](http://ocsp.accv.es/) URL for access to certificates with high availability ACCVRAIZ1: ACCVCA-110: ACCVCA-120: ACCVCA-130: ACCV ROOT RSA TLS 2024: ACCV RSA1 TLS: ACCV ROOT ECC TLS 2024: ACCV ECC1 TLS: URL of access to CRLs with high availability ACCVRAIZ1: ACCVCA-110: ACCVCA-120: ACCVCA-130: ACCV ROOT RSA TLS 2024: ACCV RSA1 TLS: ACCV ROOT ECC TLS 2024: ACCV ECC1 TLS: ACCV repository does not contain any information of a confidential nature and no other repository operated by any other organization is used. ACCV conforms to the current version of the \"Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates\", published at https://www.cabforum.org/. In the event of any inconsistency between this certification policy and the CAB Forum requirements, the latter shall take precedence over this document. Among the conditions established is the obligation to revoke the certificates if it is detected that the issuance or operation does not comply with that defined in the regulations. **This revocation must be made within a maximum period of between one (1) and five (5) calendar days (depending on the type of non-compliance) and no postponement of any kind is possible. If it is not possible to comply with this condition, certificates issued under this regulation should never be used.** ## Publication It is the obligation of the CAs belonging to ACCV trust hierarchy to publish information regarding their practices, their certificates and the updated status of such certificates. This CPD is public and is available on ACCV website http://www.accv.es/fileadmin/Archivos/Practicas_de_certificacion/ACCV-CPS-CP-V4.0.17-EN-2025.pdf, in PDF format. ACCV Certification Policies are public and are available on ACCV website http://www.accv.es/pdf-politicas, in PDF format. ACCV CA certificate is public and is available in ACCV repository, in X.509 v3 format. It is also available at http://www.accv.es. The certificates issued by ACCV are public and are available in ACCV repository, in X.509 v3 format. The list of certificates revoked by ACCV is public and is available, in CRL v2 format, in ACCV repository. ACCV provides test web pages that allow application software vendors to test their software with subscriber certificates that are chained to each publicly trusted root certificate. \- ACCVCA-120 VALID https://activo.accv.es/test/hola.html REVOKED https://revocado.accv.es:442/test/hola.html EXPIRED https://caducado.accv.es:444/test/hola.html \- ACCV RSA1 TLS VALID https://activonjrsa.accv.es/test/hola.html REVOKED https://revocadonjrsa.accv.es:442/test/hola.html EXPIRED https://caducadonjrsa.accv.es:444/test/hola.html \- ACCV ECC1 TLS VALID https://activonjecc.accv.es/test/hola.html REVOKED https://revocadonjecc.accv.es:442/test/hola.html EXPIRED https://caducadonjecc.accv.es:444/test/hola.html Within the scope of the Certificate Transparency project, in the case of TLS certificates (such as those issued under this CPS), pre-certificates will be published in the CT Log service of qualified log server providers to meet project requirements. ## Time or Frequency of Publication This CPS shall be published each time it is modified, carrying out an annual review to verify compliance and adaptation to new directives and technical standards. This revision shall be indicated by changing the minor version number. Certificates issued by the CA will be published immediately after issuance. The CA shall add the revoked certificates to the relevant CRL within the time period stipulated in section 4.4.9 *Frequency of issuance of CRLs*. ## Access Controls on Repositories Access to read the information in ACCV repository and on its website is free of charge. Only ACCV is authorized to modify, replace or delete information from its repository and website. In this regard, ACCV uses appropriate means of control in order to restrict the ability to write or modify these elements. ## # Identification and Authentication ## Naming ### Types of names All certificate subscribers require a non-null distinguished name compliant with the X.500 standard. TLS Certificates in general include entries in the subjectAlternativeName (SAN) extension which are intended to be relied upon by relying parties. ### Need for Names to be Meaningful In all cases the distinguished name must make sense. This CPS describes the attributes used for the distinguished name in the points in 7.1.2 and 7.1.4. The names in the certificates identify the subject and the issuer respectively. The subject name in CA Certificates MUST match the issuer name in Certificates issued by the CA, as required by the RFC5280. ### Anonymity or Pseudonymity of Subscribers ACCV does not issue pseudonym certificates for server authentication. ### Rules for Interpreting Various Name Forms The rules used by ACCV to interpret the distinguished names of the certificates it issues are those contained in ISO/IEC 9594 (X.500) Distinguished Name (DN) and RFC-2253. ### Uniqueness of names Distinctive names must identify the subscriber and shall be unambiguous. ACCV does not enforce uniqueness of distinguished names. As a difference, the assigned serial numbers included in the certificates are unique. ACCV generates serial numbers of at least 64 bits. These numbers are the result of a CSPRNG. It is verified that the serial numbers are never reused. In the case of TLS certificates the CN may be missing or optionally one of the names included in the Subject Alternative Name extension may be used. The second option is not recommended. ### Recognition, Authentication, and Role of Trademarks The inclusion of a name in a certificate does not imply the existence of any right over it and is without prejudice to the best rights that third parties may have. ACCV does not act as arbitrator or mediator, nor does it resolve any disputes concerning ownership of names of persons or organizations, domain names, trademarks or trade names, etc. ACCV reserves the right to refuse an application for a certificate because of a name conflict. The Spanish Patent and Trademark Office of the Ministry of Industry, Commerce and Tourism has granted the following trademarks owned by ISTEC. \- "Autoritat de Certificació de la Comunitat Valenciana\", mixed trademark nº 2.591.232, granted on September 15, 2004, published in the Official Bulletin of Industrial Property of October 16, 2004. ![](media/image3.wmf){width="2.1659722222222224in" height="0.3597222222222222in"} \- "ACCV\", trademark nº 2.591.037, granted on May 19, 2005, published in the Spanish Official Industrial Property Gazette on June 16, 2005.\ - \"Agencia de Tecnología y Certificación Electrónica\", trademark nº 2.943.180, applied for at the Spanish Official Industrial Property Office on August 13, 2010. ![](media/image4.png){width="3.0131944444444443in" height="0.4951388888888889in"} ACCV deliberately prohibits the use of a name whose right of use is not owned by the subscriber. However, it is not required to seek proof of trademark ownership before issuing certificates. ## Initial Identity Validation ### Method to Prove Possession of Private Key In the event that the key pair is generated by the final entity (subscriber) externally to the tools and applications provided by ACCV, the subscriber must prove possession of the private key corresponding to the public key requested to be certified by sending the certification request signed by the private key associated with the public key provided. ### Authentication of Organization Identity ACCV makes no commitments in the issuance of certificates regarding the use of a trademark or trade name, deliberately not allowing the use of a name whose right of use is not owned by the Subscriber. In case of dispute, ACCV may refuse the application or revoke any certificate without liability. ACCV will use the tools indicated in this point to perform the corresponding searches and confirm the rights of use. ACCV uses the mechanisms established by the technical regulations in force, specifically Commission Implementing Regulation (EU) 2015/1502 of 8 September 2015 on the establishment of minimum technical specifications and procedures for the security levels of electronic identification methods, as provided for in Article 8(3) of Regulation (EU) No. 910/2014 of the European Parliament and of the Council on electronic identification and trust services for electronic transactions in the internal market. The right to request certificates as defined in this CPS is limited to subscribers identified as natural persons. Certification requests made by subscribers identified as legal persons, entities or organizations will not be accepted. The applicant\'s identity is authenticated by using his or her qualified personal certificate, signing with it the request for the website authentication certificate when identifying himself or herself in the application that ACCV makes available to users for this function (NPSC ). The applicant must submit the necessary documentation as determined by Data relating to the entity such as inclusion in the corresponding commercial register, domicile, locality, state or province, country, operating codes, etc. The necessary representation capabilities of the entity that owns the referred domain. Possession of the domain This presentation must be made using the sources and applications that ACCV makes available to users for this purpose. ACCV will check the data provided (including the applicant\'s country) using the information available at: Official gazettes Data Protection Agencies Public Administration Registries Commercial registries Patent and Trademark Offices Identity Verification and Consultation Services requesting from the applicant any corrections or additional documents it may consider necessary. All agencies and records used are official and highly reliable, providing traceable evidence of all searches. ACCV retains this information for audit purposes, allowing it to be reused for a period of no more than 13 months from its last verification. ***Domain verification*** ACCV will verify that the domain of the certificates and their associated addresses belong to the applicant\'s data using the information available from the personal and domain registries, requiring from the applicant any additional explanations or documents it may consider necessary and including in the process technically reliable verification mechanisms approved by the industry. ACCV retains domain check information for audit purposes but does not reuse it, verifying the domain for each request independently. ACCV will not issue certificates for IP addresses or private domain names, and entries in the dNSName must be in the \"preferred name syntax\" as specified in RFC 5280, and therefore must not contain underscore characters (\"\_\"). For gTLDs, certificates will only be issued with approved gTLD names, and will only be issued to subscribers who have control of the gTLD, as listed in ICANN/IANA. Specifically: - Verification that the applicant, whose identity has been verified beyond doubt, is one of the owners of the domain. For this verification, ACCV must use one or more of the following methods: Contact by mail, sending a unique random number in the mail to one or more addresses created using \'admin\', \'administrator\', \'webmaster\', \'hostmaster\', or \'postmaster\' as the local part, followed by the at sign (\"@\"), followed by a domain name to authorize, including a random value in the email, and receiving a confirmation reply using the same random value as the initial email. ACCV must wait no longer than 30 days for the response and must confirm that the response includes the same random number. **(CAB/Forum BR 3.2.2.4.4 Constructed Email to Domain Contact)** Confirm the presence of a random value included in the contents of a file under the \"/.well-known/pki-validation\" directory in the domain name to be authorized. This URL must be accessible by the CA via HTTP/HTTPS over an Authorized Port. Once the value has been communicated to the applicant, it will only be valid for 30 days. In the URL, the content of the file does not appear in any case and only 200 is considered as the correct HTTP response value (re-addresses are not allowed). Multiple network perspectives (at least two) will be used to verify the random value in the HTTP/HTTPS connection. This method is NOT allowed to validate wildcard domain names. **(CAB/Forum BR 3.2.2.4.18 Agreed‑Upon Change to Website v2)** Confirmation of the requester\'s control over an FQDN by validating control of the FQDN domain using the ACME HTTP Challenge method defined in section 8.3 of RFC 8555. ACCV MUST receive a successful HTTP response from the request (which means that an HTTP 2xx status code should be received).\ a 2xx HTTP status code must be received). The token (as defined in RFC 8555, Section 8.3) once the value is communicated to the requester, will only be valid for 30 days. In the URL, the content of the file does not appear in any case and only 200 is considered as the correct HTTP response value (re-addresses are not allowed). Multiple network perspectives (at least two) will be used to verify the random value in the HTTP/HTTPS connection. This method is NOT allowed to validate wildcard domain names. The data necessary to establish communication using ACME with ACCV can be obtained from the account associated with the agency in the NPSC application provided by ACCV. In order to carry out the automatic generation and renewal of certificates, it is essential that all subscriber and organization documents are validated and valid. For this purpose, reminders are sent to registered users with ACME certificates indicating that the documents or credentials are about to expire. These reminders begin 30 days before expiration and are repeated daily. **(CAB/Forum BR 3.2.2.4.19 Agreed‑Upon Change to Website ‑ ACME)** Confirm the presence of a random value in a DNS CNAME, TXT or CAA record for 1) an Authoritative Domain Name; or 2) an Authoritative Domain Name that is prefixed with a tag beginning with an underscore character. Once the value is communicated to the applicant, it will only be valid for 30 days. Multiple network perspectives (at least two) will be used to perform the verification. **(CAB/Forum BR 3.2.2.4.7 DNS Change)** ACCV will check for the existence of CAA records just before issuing the certificate, acting as defined in RFC 8659 and in the CAB/Forum documents if the record is present. Multiple network perspectives (at least two) shall be used to perform the CAA record verification. The identifier associated with ACCV as CAA *issue* and *issuewild* records is \"accv.es\". Connection tests to the given domain and DNS response tests using secure protocol (e.g. HTTPS) will be performed. If it is a certificate with a wildcard character (\*), the requesting application (NPSC) only allows the character to be placed in a valid position (never allowed in a first position to the left of a \"registry-controlled\" label or public suffix). The wildcard character (\*) is not allowed in the electronic headquarters certificates. In the event of any irregularity, the applicant for the certificate will be notified by ACCV and its issuance will be suspended until it is corrected. If such correction is not made within one month, the application will be denied. ### Authentication of Individual Identity ACCV uses the mechanisms established by the technical regulations in force, specifically Commission Implementing Regulation (EU) 2015/1502 of 8 September 2015 on the establishment of minimum technical specifications and procedures for the security levels of electronic identification methods, as provided for in Article 8(3) of Regulation (EU) No. 910/2014 of the European Parliament and of the Council on electronic identification and trust services for electronic transactions in the internal market. See the relevant Policy. Authentication of the identity of a certificate applicant shall be performed by using his or her personal qualified certificate supported for signing the application for the qualified website certificate. The applicant must also submit the necessary documentation that determines the capacity to represent the entity that owns the domain to which it refers and the possession of the domain itself. This presentation will be made telematically using the means and applications that ACCV makes available to the users ( ).3.2.2 ACCV will check the data provided (including the applicant\'s country) using the information available at: Official gazettes Data Protection Agencies Public Administration Registries Commercial registries Patent and Trademark Offices Identity Verification and Consultation Services requesting from the applicant any corrections or additional documents it may consider necessary. All agencies and records used are official and highly reliable, providing traceable evidence of all searches. ACCV retains this information for audit purposes, allowing it to be reused for a period of no more than 13 months from its last verification. ### Non-Verified Subscriber Information All information provided is verified. ### Validation of Authority The authority of certificate applicants to request certificates on behalf of someone else is verified during the validation of the applicant\'s identity. As established by law, a specific power of attorney is required for this operation. ### Criteria for interoperation ACCV neither interoperates nor has cross-certificates with other Certification Authorities. ## Identification and Authentication for Re-Key Requests ### Identification and Authentication for Routine Re-Key Identification and authentication for certificate renewal can be performed using the techniques for initial authentication and identification (described in sections 3.2.2 *Authentication of the identity of an organization* and 3.2.3 *Authentication of the identity of an individual,* of this CPS). ACCV can reuse information stored in previous verifications if no more than 13 months have passed since the last verification of the data, except for domain verification information, which is not reused, and the associated keys, which must be supplied again. There are, therefore, mechanisms for renewal: - Web forms in the Non-Personal Certificate Management Area, available at https://npsc.accv.es:8450/npsc. - Automation via ACME (with the corresponding documentation in force) For further information see section 4.6 of this document. ### Identification and Authentication for Re-Key after Revocation - Uncompromised key The identification and authentication policy for the renewal of a certificate after an uncommitted revocation of the key will be the same as for the initial registration, being able to reuse the information in possession of ACCV if no more than 13 months have passed since the last verification of the data, except for the domain verification information, which is not reused, and the associated keys, which must be supplied again. ACCV, for technical reasons and detailing all the steps, may use some electronic method that reliably and unequivocally guarantees the identity of the applicant and the authenticity of the application. ## Identification and Authentication for Revocation Request The identification policy for revocation requests may be the same as for initial registration. The authentication policy shall accept revocation requests digitally signed by the certificate subscriber. The identification policy for revocation requests accepts the following methods of identification: - By means of a revocation form (located in the Non-Personal Certificate Management Area https://npsc.accv.es:8450/npsc) accessed by the certificate applicant or the person responsible for the certificate on the date of the revocation request by means of a qualified personal certificate. - Using ACME\'s revocation mechanism ACCV or any of its member entities may request ex officio the revocation of a certificate if they have knowledge or suspicion of the compromise of the subscriber\'s private key, or any other fact that would recommend such action. For further information see section 4.9 of this document. # Certificate Life-Cycle Operational Requirements ## Certificate Application ### Who can submit a certificate request This type of certificate request is the responsibility of private or public entities. A certificate request can be submitted by the subject of the certificate or by an authorized representative of the same, and that have proven to have control over the domain name to be included in the Certificate. In the case of electronic headquarters certificates, only public entities can apply for them. ### Enrollment Process and Responsibilities The process begins by accessing the Non-Personal Certificate Management Area (NPSC) located at https://npsc.accv.es:8450/npsc. The connection to the system is always encrypted and only client identification with qualified personal certificates is accepted. If the website authentication certificate associated with an entity is requested for the first time, the user must attach the document that accredits him/her as qualified to make the request (document of taking office in the position or official journal where the corresponding appointment is recorded, powers of attorney and registration in the corresponding registries), in electronically signed pdf format. If the access has been made with a certificate that accredits the necessary capacity to manage the website authentication certificates, the Organization, Organizational Unit and Position data of that certificate will be used. ACCV will check the application data and accredit the applicant for the application of website authentication certificates, for 13 months from the approval without the need to provide additional documentation, except for the domain verification information that is not reused. In the case of identification with a public employee certificate, there is no time limitation as long as the certificate is in force. In addition to checking the credentials associated with the entity, ACCV will check in the authorized registries the possession of the domain or domains that appear in the certificate request, so that there is no doubt of such possession. ACCV will keep a record of these searches and verifications so that they can be reproduced in all the steps. For this verification ACCV will use the data provided in the registration process, being necessary a direct link between this data and the domains included in the application. For domain verification and if the type of certificate allows it, the ACME services provided by ACCV can be used, automating the registration and generation process if the validation documentation of the organization is valid and in force. To register an ACME account it is necessary to register the user and the organization. From the registration you can obtain the necessary data for the application. ## Certificate Application Processing The identifier associated with ACCV as CAA issue and issuewild records is \"accv.es\". ### Performing identification and authentication functions The applicant identifies himself with a qualified personal certificate in the Non-Personal Certificate Management Area (NPSC) located at https://npsc.accv.es:8450/npsc, using the certificate data to perform the identification and authentication functions. In case of using ACME the request is completed in an automated way through the communication mechanisms described in the protocol since the identification is performed with the data provided when activating the ACME account. Once the certificate application is received in electronic format through the platform by the authorized persons and once the economic proposal is accepted (if applicable), ACCV proceeds to review the application. In the case of using automation by ACME, the application will only be accepted if the required documentation is current and valid. ACCV verifies the application data and accredits the applicant of the Web site authentication certificate application, for 13 months from the approval without the need to submit any additional documentation. In the case of identification with a public employee or representative certificate, there is no time limit as long as the certificate is valid. In addition to checking the credentials associated with the entity, ACCV verifies in the authorized registries the possession of the domain or domains that appear in the certificate request, so that there is no doubt about the existence of this possession, as detailed in sections 3.2.2 and 3.2.3 of this policy. ACCV provides records of these searches and checks so that they can be reproduced at each step. For this check ACCV uses the data that was submitted in the registration process, being necessary a direct connection between this data and the domains that are included in the application. In this process, ACCV checks that certificate requests do not include domains that can be used for phishing or other fraudulent uses, using the available mechanisms and lists. ### Approval or Rejection of Certificate Applications In case of acceptance, the Registration Authority will notify the applicant via a digitally signed email to the email address provided in the application. In the case of using ACME services the application is automatically approved if the domain requirements are met and the credentials of the agency and subscriber are current and valid. In case of rejection, the Registration Authority will notify the applicant by means of a digitally signed e-mail to the e-mail address given in the application. The application is cancelled and cannot be reused, although it is possible to reuse the documentation provided marked as correct for a period not exceeding 13 months. This process is carried out by a member of ACCV different from the one responsible for performing the data verification. The differentiation of functions is performed using the capabilities established in the management application. In the case of ACME services all processes at this point are carried out in an automated manner. ACCV will use this information to decide on new applications. ### Time to Process Certificate Applications The maximum time for processing certificate requests is five (5) business days. This time includes the processing time by ACCV and does not include the time used by the user to provide the necessary information and documentation. ## Certificate Issuance ACCV is not responsible for monitoring, investigating or confirming the accuracy of the information contained in the certificate subsequent to its issuance. In the event of receiving information about the inaccuracy or current non-applicability of the information contained in the certificate, the certificate may be revoked. ### CA Actions during Certificate Issuance The issuance of the certificate takes place once the Registration Authority has performed the necessary checks to validate the application. The mechanism that determines the nature and manner of these checks is this CPS. When the applicant receives the approval email, they must log back into NPSC, identifying themselves with a qualified personal certificate to generate and download the certificate. This does not apply if ACME is used, where the application, verification of documentation and domain possession, and generation is done in a single step. The organization responsible for the authentication certificate of the websites may request ACCV to add other users with the ability to perform the transactions that are associated with the lifecycle of the certificates. The Registration Authority will check the credential request and notify the applicant of the authorization or denial of permission, via a signed email. ACCV may perform this authorization ex officio in the event that the person in charge of the organization loses its management capacity and there is no other authorized person. When ACCV CA issues a certificate in accordance with a valid certification request, it will send one copy of the certificate to the Registration Authority that issued the request and another to ACCV repository. ACCV checks that the certificates conform to the accepted profiles using different validators that are run before the CA signs the applications (they are signed by a generic non-recognized key). Specifically, the following are used: \- zlint \- pkilint If any of these validators return an error, the issuance is stopped and the applicant and the CA operators are notified. ACCV will perform frequent reviews of samples of website authentication certificates to ensure the accuracy of the data and the format of the certificates by the validators used in the issuance. If in the course of these samplings a change of data is confirmed that may imply the loss of domain ownership, ACCV will revoke the certificates involved. In case of inaccuracy of the data contained in the certificate or its inapplicability, the same process will be followed. ACCV will leave a documentary record of all these reviews and actions. In the case of certificates issued by a root CA, a person authorized by ACCV is required to intervene manually in order for the root CA to perform a certificate signing operation. ### Notification to Subscriber by the CA of Issuance of Certificate ACCV notifies the subscriber of the issuance of the certificate, through an e-mail to the e-mail address provided in the application process. ### Refusal to Issue a Certificate ACCV reserves its right to refuse to issue a Certificate to any party as it sees fit, without incurring any liability or responsibility for any loss or expenses arising out of such refusal. ACCV reserves the right not to disclose reasons for such a refusal. ## Certificate Acceptance ### Conduct Constituting Certificate Acceptance The acceptance of the certificates by the signatories occurs at the time of signing the certification contract associated with each Certification Policy. The acceptance of the contract implies knowledge and acceptance by the subscriber of the associated Certification Policy. The user must accept the contract before the certificate is issued. ### Publication of the Certificate by the CA Once the certificate has been accepted by the subscriber and generated, the certificate will be published in ACCV repository and made available to authorized users. ### Notification of Certificate Issuance by the CA to Other Entities Prior to the issuance of Website Authentication Certificates, a pre-certificate is sent to the Certificate Transparency Service Logs (CT LOG) following the requirements established in the application policies. The number of operators to which the pre-certificate is sent and the format of the extensions is indicated at .7.1.10 There are no further notifications. ## Key Pair and Certificate Usage ### Subscriber Private Key and Certificate Usage ACCV does not generate or store the Private Keys associated with website authentication Certificates (although it provides tools to facilitate this). The custody and control of the private keys corresponds to the subscriber or its Representatives who have accredited to have control over the domain name to be included in the Certificate. The intended scope of use for a private key shall be specified through certificate extensions, including key usage and extended key usage extensions, in the associated certificate. Certificates can be used to identify the server to whose domain the certificate is issued in a secure manner, and to establish secure communication channels (including encryption) using the mechanisms available in each case. In the case of electronic headquarters certificates, they are used to identify an electronic headquarter of a public body. ### Relying Party Public Key and Certificate Usage The relying parties undertake to: \- The uses of the certificates correspond to the scope of application. \- The provisions of the CPS are complied with \- Check the status of the certificate and verify the status of the hierarchical chain before establishing trust. \- Not to compromise or use the services offered in a malicious manner. \- Report any anomalies or problems detected using the appropriate channels. ## Certificate Renewal The renewal of certificates must be carried out using the same procedures and identification methods as those established for the initial application. ACCV does not renew Certificates maintaining the public Key of the same, but, in any case, the renewal of Certificates is always done by providing Keys. ### Circumstances for certificate renewal The certificate renewal period begins 30 days before the expiration date of the certificate, when the subscriber receives an email notifying him/her of the steps to follow to proceed with the certificate renewal. In the case of using ACME the renewal process can be initiated automatically if this option has been configured and the documents required for the validation of the organization are current and valid. ### Who May Request Renewal Any subscriber may request the renewal of its certificate. To do so, the same requirements must be met as for the initial application. ACCV does not automatically renew Certificates. ### Processing Certificate Renewal Requests The same process will be followed as described for the initial issuance. ### Notification of New Certificate Issuance to Subscriber It is the responsibility of the Registration Authority to notify the subscriber of the issuance of the certificate and to deliver a copy to the subscriber or, failing that, to inform the subscriber how to obtain a copy. The same process will be followed as described for the initial issuance. ### Conduct Constituting Acceptance of a Renewal Certificate The same process will be followed as described for the initial issuance. ### Publication of the renewal certificate by the Certification Authority The same process will be followed as described for the initial issuance. ### Notification of Certificate Issuance by the CA to Other Entities The same process will be followed as described for the initial issuance. ## Certificate Re-key Key renewal necessarily implies certificate renewal and cannot be carried out as separate processes. ### Circumstances for Certificate Re-Key Key renewal necessarily implies certificate renewal and cannot be carried out as separate processes. ### Who May Request certification of a new public key Key renewal necessarily implies certificate renewal and cannot be carried out as separate processes. ACCV can regenerate the keys of the certificates of the CAs, according to the document of the corresponding generation ceremony. ACCV can regenerate the keys of OCSP and TSA services certificates in accordance with the corresponding internal procedure. ### Processing Certificate Rekeying Requests Key renewal necessarily implies certificate renewal and cannot be carried out as separate processes. ### Notification of new certificate issuance to Subscriber Key renewal necessarily implies certificate renewal and cannot be carried out as separate processes. ### Conduct Constituting Acceptance of a Re-Keyed Certificate Key renewal necessarily implies certificate renewal and cannot be carried out as separate processes. ### Publication of the Re-Keyed Certificate by the CA Key renewal necessarily implies certificate renewal and cannot be carried out as separate processes. ### Notification of Certificate Issuance by the CA to Other Entities Key renewal necessarily implies certificate renewal and cannot be carried out as separate processes. ## Certificate Modification Modification of certificate fields is not allowed. When it is necessary to modify any information in the certificate, ACCV will revoke the certificate and issue a new one following the established processes. ### Circumstance for Certificate Modification Modification of certificate fields is not allowed. When it is necessary to modify any information in the certificate, ACCV will revoke the certificate and issue a new one following the established processes. ### Who May Request Certificate Modification Modification of certificate fields is not allowed. When it is necessary to modify any information in the certificate, ACCV will revoke the certificate and issue a new one following the established processes. ### Processing Certificate Modification Requests Modification of certificate fields is not allowed. When it is necessary to modify any information in the certificate, ACCV will revoke the certificate and issue a new one following the established processes. ### Notification of New Certificate Issuance to Subscriber Modification of certificate fields is not allowed. When it is necessary to modify any information in the certificate, ACCV will revoke the certificate and issue a new one following the established processes. ### Conduct Constituting Acceptance of Modified Certificate Modification of certificate fields is not allowed. When it is necessary to modify any information in the certificate, ACCV will revoke the certificate and issue a new one following the established processes. ### Publication of the Modified Certificate by the CA Modification of certificate fields is not allowed. When it is necessary to modify any information in the certificate, ACCV will revoke the certificate and issue a new one following the established processes. ### Notification of Certificate Issuance by the CA to Other Entities Modification of certificate fields is not allowed. When it is necessary to modify any information in the certificate, ACCV will revoke the certificate and issue a new one following the established processes. ## Certificate Revocation and Suspension ACCV specifies the revocation reasons for the certificates that have been revoked. For subscriber's certificates only if the subscriber has provided the revocation reason, otherwise this will be unspecified. ### Circumstances for revocation #### **Reasons to revoke a user certificate** A certificate is revoked in a period not exceeding 24 hours when: - A valid revocation request is received from the subscriber. - A valid request for revocation is received from an authorized third party, for example by means of a court order. - The certificate subscriber or its keys or the keys of its certificates have been compromised by: - The theft, loss, disclosure, modification, or other compromise or suspected compromise of the user\'s private key. - Deliberate misuse of keys and certificates, or failure to observe the operational requirements of the Subscriber Agreement, or this CPS. - The key pair generated by the subscriber is revealed as \"weak\". - The certificate of a higher RA or CA in the certificate trust hierarchy is revoked. - ACCV is aware of a demonstrated or proven method that exposes the Subscriber\'s Private Key to compromise or if there is clear evidence that the specific method used to generate the Private Key was flawed. A certificate must be revoked in a period not exceeding five days, being advisable to revoke in a period not exceeding 24 hours when: - A prerequisite necessary for the issuance of the certificate has not been met. - A fundamental factor of the certificate is known to be false or reasonably believed to be false. - An error occurred while entering or processing the data. - The information contained in a certificate becomes inaccurate, for example, when the owner of a certificate changes its name. - ACCV is aware of any circumstances indicating that the use of a domain name in the certificate is no longer legally permitted (for example, if a court or similar body has revoked the domain name owner\'s right to use the domain name, if a relevant license or service agreement between the domain name owner and the certificate applicant has been terminated, or if the domain name owner has not renewed the certificate). - ACCV is aware that a Wildcard Certificate has been used to fraudulently authenticate a subordinate domain name. - The Certificate has not been issued in accordance with the policies set out in this document #### **Reasons to revoke a subordinate (intermediate) CA certificate** An intermediate (subordinate) CA certificate is revoked when: - ACCV obtains evidence that the private key of the subordinate CA corresponding to the certificate\'s public key has been compromised. - ACCV obtains evidence of misuse. - ACCV has knowledge that the certificate has not been issued in accordance with this CPS, the Certification Policy or the applicable Certification Practices Statement, or that the subordinate CA has not complied with them. - ACCV determines that any information appearing on the Certificate is inaccurate or misleading. - ACCV ceases to operate for any reason and has not arranged for another CA to provide revocation support for the Certificate. - ACCV\'s right to issue certificates under these requirements expires, is revoked or lapses, unless the issuing CA has taken steps to continue to maintain the CRL/OCSP repository. - Revocation is required by ACCV Certificate Policy and/or the Certification Practices Statement. - The technical content or format of the certificate presents an unacceptable risk to application software vendors or relying parties. The revocation must be made within a period not exceeding 7 days from the time ACCV becomes aware of the fulfillment of these conditions. ### Who Can Request Revocation The revocation of a certificate can be requested both by the subscriber of the certificate and by ACCV, as well as by any person who has reliable knowledge that the data associated with the certificate has become inaccurate or incorrect or that any of the circumstances established for revocation have been incurred. Certificate subscribers may request revocation for any reason and must request revocation under the conditions specified in the following section. ### Procedure for Revocation Request ACCV accepts requests for revocation of Web site authentication certificates by the following procedures #### Interactive telematics By accessing the Non-Personal Certificate Management Area (NPSC) located at the user can revoke the certificates he/she has requested or for which he/she has permission to do so. It can also be revoked through the contact form at https://www.accv.es/# where the user must paste the private key in PEM format, including the BEGIN and END lines. #### Telematic ACME Using the automation service through ACME, from the account for which the certificate was issued. #### Telephone Using the 24x7 contact telephone number 963 866 014. Subscribers, relying parties, application software vendors and other third parties may report suspected private key compromise, certificate misuse or other types of fraud, compromise, misuse, misconduct or any other certificate-related issues at the URL https://www.accv.es/contacto/. The support email and contact telephone numbers are located at this URL. ### Revocation Request Grace Period In the event that a Grace Period is not defined in the Subscriber Agreement, Subscribers are required to request revocation within 24 hours of detecting any problem that invalidates the use of the certificate (loss or compromise of the Private Key, etc.). ### Time Within which CA Must Process the Revocation Request ACCV will handle revocation requests in accordance with sections 4.9.1.1 and 4.9.5 of the BR/TLS, always ensuring that within 24 hours of receipt of a CPR a preliminary study and initial report has been carried out. ACCV will inform the subscriber and the entity has reported the problem. ### Revocation Checking Requirement for Relying Parties Third parties that trust and accept the use of Certificates issued by ACCV are obliged to verify the status of the certificates (revocation and expiration) throughout the certification chain and at each use of the same against the relevant CRL published or using the OCSP server.\ ACCV makes available to its users several revocation checking services for the certificates it issues (CRL, OCSP, others\...). Relying parties must use at least OCSP (preferably) or CRL. ### CRL Issuance Frequency ACCV will publish a new end-entity CRL in its repository at maximum intervals of 5 hours, even if no CRL modifications (certificate status changes) have occurred during the mentioned period. The nextUpdate field has a maximum value of 4 days. ACCV shall publish a new root CRL in its repository with a maximum periodicity of 6 months, even if there have been no changes in the CRL. In case of revocation of an intermediate certification authority, the CRL shall be published within no more than 12 hours. The OCSP is updated prior to the CRL. The most recent information will be the one provided by the OCSP. The CRL does not contain expired certificates. To inquire about the status of an expired certificate the valid information will be the one provided by the OCSP. ### Maximum Latency for CRLs The maximum time between the generation of the CRLs and their publication in the repository is 30 minutes. ### On-Line Revocation/Status Checking Availability ACCV provides an OCSP server for online certificate status verification at: ocsp.accv.es:80 according to RFC 6960 and RFC 5019. OCSP responses are signed by an OCSP server whose certificate is signed by the CA that issued the certificate we are checking, and which has the specific key usages for it. ACCV maintains the certificate status information indefinitely, guaranteeing this information for at least 15 years. ### On-Line Revocation Checking Requirements The OCSP server is freely accessible and there are no requirements for its use, except for those derived from the use of the OCSP protocol according to the provisions of RFC 6960. OCSP supports calls to the service using the GET method (in addition to the POST method). For the status of subscriber certificates: \- ACCV updates the information provided through OCSP within 3 hours. \- OCSP responses for this service have a maximum expiration time of 3 days. \- An authorized OCSP response (i.e., the OCSP service MUST NOT respond with \"unknown\" status) must be available within 15 minutes of the certificate first being published or made available. For the status of subordinate CA certificates: \- ACCV updates the information provided via OCSP within 6 months and within 12 hours of revocation of an intermediate CA certificate. ACCV OCSP service provides definitive responses on \"reserved\" certificate serial numbers, as if there is a corresponding certificate that matches the pre-certificate, as indicated in RFC 6962. A certificate serial number within an OCSP request is in one of the following three options: - 1 . \"assigned\" if the issuing CA has issued a certificate with that serial number. - 2 \"reserved\" if a Precertificate \[RFC6962\] with that serial number has been issued by the issuing CA. - 3 \"not used\" if none of the above conditions are met. If the OCSP server receives a status request for a certificate that has not been issued (\"not used\"), then it responds with a \"revoked\" status, with reason certificateHold(6) and revocationTime January 1, 1970. ACCV monitors the response to such requests as part of its security response procedures. ACCV also provides web services to consult the validity status of issued certificates. ### Other Forms of Revocation Advertisements Available Not defined ### Special Requirements for Key Compromise There will be no variation in the above clauses in the event that the revocation is due to the compromise of the private key. The user can provide the compromised private key using the support form at the following URL: [https://www.accv.es/ayuda/certificates-revocation/how-revoke-certificate/.](https://www.accv.es/ayuda/certificates-revocation/how-revoke-certificate/) In the form you must paste this key in PEM format, including the BEGIN and END lines. ### Circumstances for suspension Suspension renders the certificate invalid for the entire time it is suspended. ACCV does not allow the suspension of certificates. ### Who can Request Suspension ACCV does not allow the suspension of certificates. ### Procedure for Suspension Request ACCV does not allow the suspension of certificates. ### Limits on Suspension Period ACCV does not allow the suspension of certificates. ## Certificate Status Services The information related to the verification of the revocation status of the electronic Certificates issued by ACCV can be consulted through CRLs and/or the Certificate Status Information and Consultation Service through the OCSP protocol, and are accessible through the following means indicated in our web page: CRL: CRL ACCVRAIZ1 CRL ACCVCA110 CRL ACCVCA120 CRL ACCVCA130 CRL ACCV ROOT RSA TLS 2024 CRL ACCV RSA1 TLS CRL ACCV ROOT ECC TLS 2024 CRL ACCV ECC1 TLS OCSP (all hierarchy): [http://ocsp.accv.es](http://ocsp.accv.es/) ### Operational characteristics Revoked certificates remain in the CRL until they reach their expiration date. Once this is reached, they are removed from the list of revoked certificates. OCSP sets a limit of 180 months, which allows checking the status of the certificate beyond the expiration date. The Certificate Status Information and Query Service via OCSP protocol supports the GET method to retrieve the validation information of issued certificates, in accordance with the requirements of RFC6960 and those established by the CA/Browser Forum entity (which can be consulted [at](https://cabforum.org/baseline-requirements-documents/) https://cabforum.org/baseline-requirements-documents/). OCSP responses have a validity interval of 3 days and the information is constantly updated by directly accessing the database. The OCSP server will not respond \"good\" to a query about the status of a certificate that has not been issued. ### Service availability CRL systems and Online Certificate Status Query Systems (OCSP) will be available 24 hours a day, 7 days a week. The OCSP response time should be kept below 1s and the CRL download time should be kept below 10s. ### Optional features There are no access or query restrictions for OCSP and CRL. ## End of subscription. The subscription ends with: ACCV cease of operation the expiration or revocation of the certificate without a renewal. ACCV will inform the person responsible for the website authentication certificate, by e-mail, at a time prior to the publication of the certificate in the List of Revoked Certificates, about the suspension or revocation of the certificates in which he/she appears as subscriber or responsible, specifying the reasons, date and time when his/her certificate will become invalid, and informing him/her that he/she should not continue to use it. ## Key Escrow and Recovery ### Key Escrow and Recovery Policy and Practices ACCV does not deposit keys of any kind associated with this type of certificate. ### Session Key Encapsulation and Recovery Policy and Practices Session key recovery is not supported. ## Expiration of CA certificate keys. ACCV will avoid generating website authentication certificates that expire later than the CA certificates. For this purpose, website authentication certificates whose validity period exceeds that of the CA certificate in question will not be issued and will be generated with the new CA certificate, in order to avoid notifying subscribers to renew their certificate, in the event that the CA certificate expires earlier. # Facility, Management, and Operational Controls ## Physical Security Controls ### Site Location and Construction The information systems of ACCV are located in Data Processing Centers (DPC) with appropriate levels of protection, external walls of the sites are of solid construction, and surveillance 24 hours a day, 7 days a week. Physical barriers are used to segregate secure areas within DPCs and are constructed so as to extend from real floor to real ceiling to prevent unauthorized entry. ### Physical access ACCV Data Processing Centers have different security perimeters, with different security requirements and authorizations. The equipment that protects the security perimeters includes combination-based physical access control systems, video surveillance and recording, and intrusion detection systems, among other equipment. In order to access the most protected areas, duality of access and an extensive period of time working for the company is required. ### Power and air conditioning The installations are equipped with uninterruptible power supply systems with sufficient power to autonomously power the electrical network during controlled system power cuts and to protect equipment from electrical fluctuations that could damage it. The equipment shall only be switched off in the event of failure of the autonomous power generation systems. The air conditioning system consists of various independent pieces of equipment with the capacity to maintain temperature and humidity levels within the systems' optimum margins of operation. ### Water Exposure ACCV Data Processing Centers are equipped with flood detectors and alarm systems appropriate to the environment. ### Fire Protection and Prevention ACCV\' Data Processing Centers have automated systems for fire detection and extinguishing. ### Media Storage Sensitive data media is stored securely in fireproof cabinets and safes in accordance with the type of medium and the classification of the information contained in them. These cabinets are located in different buildings to remove risks associated with a single location. Access to these media is restricted to authorized personnel. ### Waste Disposal The disposal of magnetic and optical media and information on paper is carried out securely following procedures stipulated for this purpose, using processes of demagnetization, sterilization, destruction or shredding, depending on the type of medium to be processed. ### Off-Site Backup Encrypted remote backup copies are made on a daily basis and are stored in premises located close to the back-up Data Processing Center, where ACCV operations would continue in the event of a serious incident or collapse of the main Data Processing Center. ## Procedural controls ACCV information systems and services are operated securely, following pre-established procedures. For security reasons, information regarding procedural controls is considered confidential and is only explained in summary form. ### Reliable papers The roles identified for the control and management of the services are: a. Management b. Systems Administrator c. Point of User Registration (PRU) Manager d. Security Administrator e. Certification Authority Operator f. PRU Operator g. Responsible for training, support and communication h. Security Manager i. Auditor j. Jurist k. Documentation Manager l. Application Development Assistance and Deployment Support m. Certification Authority Coordinator #### Management At the head of ACCV\'s staff and under the control of ISTEC\'s Board of Directors, he is the person responsible for the economic and financial management and the technical and administrative control of ACCV\'s activities. Corresponds to the position of Manager of Infraestructures i Serveis de Telecomunicacions i Certificació, SAU (ISTEC). #### Systems Administrator He/she is responsible for operating systems and software products installation and configuration, and maintaining and updating the installed products and programs. He/she is entrusted with the establishment and documentation of systems and provided services monitoring procedures, as well as tasks carried out by the Certification Authority Operators monitoring. He/she must ensure that services are provided with the appropriate level of quality and reliability, in accordance with the critical level of these services. He/she is responsible for the correct implementation of the Backup Policy, and in particular, for maintaining sufficient information which permits the effective restoration of any system. Along with the Certification Authority Operator and, in exceptional cases, the PRU Administrator, is responsible for making the local backup copies. He/she must maintain the inventory of servers and equipment comprising ACCV certification platform group. He/she must not have access to aspects relating to system or network security (registrations/removals of users, management of firewall rules, management and maintenance of intrusion detection systems, etc.). He/she must collaborate with the Auditors in relation to everything that is required of him/her. #### PRU Administrator. This profile is similar to Systems Administrator but dedicated to the tasks related to installation, maintenance and control of the systems that comprising the User Registration Points. He/she is responsible for administrative tasks relating to PRU Operators' authorizations, confidentiality agreements, etc. He/she must maintain the inventory of PRUs and equipment used for PRU operations. In exceptional cases, he/she may work with the Systems Administrator and Certification Authority Operator to carry out local backups of the PKI systems. In the same way as for Systems Administrators, he/she must not have access to aspects relating to the security of systems, or of the network, etc. (registrations/removals of users, management of firewall rules, management and maintenance of intrusion detection systems, etc.). He/she must collaborate with the Auditors in relation to everything that is required of him/her. #### Security Administrator. He/she must comply with and ensure compliance with ACCV's security policies, and must be responsible for any matter relating to the security of ACCV: physical security, security of applications, of the network, etc. He/she is the individual responsible for managing the perimeter protection systems and specifically managing firewall rules, according to the security rules and in compliance with the Security Responsible. He/she is responsible for installation, configuration and management of the intrusion detection systems (IDS) and the tools associated with these. He/she is responsible for resolving or ensuring the resolution of security incidents that have occurred, eliminating vulnerabilities detected, etc. recording always all the incidences that have occurred and all his/her actions. He/she is responsible for maintaining updated the documents concerned with security devices and, generally, all its tasks. He/she will notify the Security Responsible of the incoherence between the Security Policy, the Certification Practices Statement, etc. and the real practices. He/she will control that companies which provide collocation services operate and maintain correctly the physical security systems of DPCs. In a coordinated manner with the Security Responsible, he/she must take charge of explaining all security mechanisms to the personnel that should know it, raising awareness among ACCV staff and enforcing standards and security policies. He/she must collaborate with the Auditors in relation to everything that is required of him/her. #### Certification Authority Operator He/she assists the Systems Administrators and PRU Administrators in technical or administrative matters that do not require access to the DPC. He/she must assist the Training, Support and Communications Manager in any tasks instructed. He/she must collaborate in accordance with the requests of PRU Administrators, with regard to inventory roles, assistance in the installation of systems comprising the PRUs, documentation preparation, collaboration in the training and support of PRU Operators, etc. He/she works with the Documentation Manager to monitor existing documents, to monitor the documentation file (hard copy) and to revise certificates and contracts. He/she works with the Security Manager on administrative tasks, inventory tasks and, in general, technical or administrative tasks. Along with the Systems Administrator and, in exceptional cases, the PRU Administrator, he/she is responsible for making the local backup copies. This is the only task that the Certification Authority Operator carries out within the DPC. He/she must collaborate with the Auditors in relation to everything that is required of him/her. #### User Registration Point Operator He/she is responsible for functions relating to the identification of certificate applicants, the processing of digital certificates, the revocation of digital certificates and the unblocking of cryptography cards, all while exclusively using the tools and applications provided by the PRU Administrators, and strictly following the approved procedures. He/she must collaborate with the Auditors in relation to everything that is required of him/her. #### Training, Support and Communications Manager He/she is responsible for the maintenance of content of the website of the Agencia de Tecnología y Certificación Electrónica (www.accv.es). He/she is entrusted with communication and updating duties in relation to ACCV's website. He/she is responsible for defining the training plan for end users, Call Center agents and personnel involved directly in the operation and administration of ACCV's certification platform. In addition, he/she works with the PRU Administrator in preparing training for PRU Operators. The Training, Support and Communications Manager is responsible for preparation of the contents of the courses taught on the e-learning corporate platform. He/she must revise the Call Centre incident and response files on a monthly basis, and revise the Call Center agents' scripts. He/she must coordinate the actions of microcomputing personnel and provide the tools and necessary material for them to carry out their duties correctly. The Training, Support and Communications Manager may receive the collaboration of the Certification Authority Operators for those tasks that he/she deems appropriate. #### Security Manager He/she must comply with and ensure compliance with ACCV's security policies, and must be responsible for any matter relating to the security of ACCV: physical security, security of applications, of the network, etc. He/she is the individual responsible for managing the perimeter protection systems and specifically managing firewall rules. He/she is responsible for installation, configuration and management of the intrusion detection systems (IDS) and the tools associated with these. He/she is responsible for resolving or ensuring the resolution of security incidents that have occurred, eliminating vulnerabilities detected, etc. He/she is responsible for management and control of the DPC physical security systems, the access control systems, the air conditioning and power supply systems. He/she is responsible for explaining the security systems to personnel that must know about them, ensuring the awareness of all ACCV personnel and ensuring compliance with security regulations and policies. He/she must establish schedules for carrying out the analysis of vulnerabilities, trials and tests of service continuity plans and information systems audits. He/she must collaborate with the Auditors in relation to everything that is required of him/her. #### Auditor The auditor profile corresponds to an internal position, without prejudice to the personnel responsible for external audits. The Auditor is responsible for: • Verifying the existence of all the required and listed documentation • Verifying the consistency of the documentation with procedures, inventoried assets, etc. • Verifying the monitoring of incidents and events • Verifying the protection of systems (exploitation of vulnerabilities, access logs, users, etc.). • Verifying alarms and physical security elements • Verifying compliance with regulations and legislation • Verifying knowledge of procedures among the personnel involved In short, the auditor must verify all aspects mentioned in the security policy, copies policies, certification practices, Certification Policies, etc. in the group of ACCV systems and within ACCV personnel, as well as in the PRUs. #### Legal Expert He/she is responsible for the legal aspects of the provision of certification services and the formalization of the provision of these services to other entities, with which a certification agreement has to be set up. He/she is entrusted with processing the approval and publication of Certification Policies, modifications to the Certification Practice Statement document and, in general, to any government regulations which affect the Certification Authority's certification platform and services. He/she ensures compliance with the electronic signature legislation currently in force, analyzing the existing Certification Policies and Certification Practice Statement and those which are subject to approval, and notifying the inconsistencies or problems that he/she detects. He/she must collaborate with the Auditors in relation to everything that is required of him/her. #### Documentation Manager He/she is responsible for maintaining ACCV's electronic documentation repository and hard-copy documentation files. He/she checks that documents are updated when required and by the persons that the Documentation Manager appoints, and may even exceed specified requirements for documents to be updated or maintained. He/she is responsible for keeping the document index file up to date and is the only individual authorized to store, delete or modify documents in ACCV's documentation repository. He/she may receive the collaboration of the Certification Authority Operators in carrying out documentary control or inventory tasks. He/she must guarantee that any certificate issued is associated with a certification contract drawn up in hard copy. He/she must collaborate with the Auditors in relation to everything that is required of him/her. #### Deployment Support Manager He/she is responsible for maintaining contact with development teams of IT applications of user organizations and entities of ACCV's services, in order to provide the necessary support and assistance for the development and deployment of data transmission applications and services which use digital certification and electronic signatures. He/she is responsible for redirecting technical IT or legal queries that he/she cannot resolve to the appropriate personnel. He/she must gather sufficient information (projects information template) in order to be able to provide an optimum level of assistance and advice. He/she must provide guidance on development possibilities, techniques and tools, taking into account the corporate information systems, security policy, applicable legislation, etc. The Deployment Support Manager must provide guidance on existing technical and administrative regulations, the role of creation of PRUs by organizations and entities that offer electronic transmission services, the operating method of these, etc. Must collaborate with ministries or entities with which a certification agreement has been set up, in order to analyze methods of distribution of certificates, creation of PRUs, etc. He/she must collaborate with the Auditors in relation to everything that is required of him/her. #### Certification Authority Coordinator He/she is responsible for monitoring and controlling the performance of the roles attributed to each job profile described above, and for the distribution of new tasks among the profiles. He/she is responsible for constituting a means of communication between the personnel appointed to each of the profiles and the Certification Authority management body. In the same way, he/she is responsible for serving as a link with other departments of the Autonomous Government of Valencia. He/she is responsible for presenting strategic decisions to the Certification Authority management body and for approving tactical decisions. He/she advises ACCV personnel on training to be taken, retraining courses, etc. and facilitates the implementation of these courses and training plans. He/she must collaborate with the Auditors in relation to everything that is required of him/her. ### Number of persons required per task Two persons are required for key activation of cryptographic hardware key generation and storage devices. Modification of cryptographic hardware configuration parameters requires authentication by at least two authorized persons with sufficient privileges. ### Identification and authentication for each role All authorized ACCV users are identified by digital certificates issued by ACCV itself and are authenticated by cryptographic smart-cards and/or biometric devices. Authentication is complemented with the corresponding authorizations to access certain information assets or ACCV systems. ### Roles requiring segregation of duties No identity is authorized to assume both a System Administrator and a Security Manager role; No identity is authorized to assume both a System Administrator and an Auditor role; No identity is authorized to assume both a Security Manager and an Auditor role; ## Personnel security controls This section reflects the contents of ACCV *Personnel Security Controls* document. ### Qualifications, Experience, and Clearance Requirements ACCV requires all personnel who carry out duties in its installations to have sufficient qualifications and experience in environments relating to the provision of certification services. All personnel must comply with the organization\'s security requirements and must possess: > • Knowledge and training in digital certification environments. > > • Basic training in information systems security. > > • Specific training for their post. > > • Academic qualification or experience in the equivalent industry Before new personnel begin performing any task or work for ACCV, their identity and trust issues will be verified with official records. ### Background check procedures By checking the Curriculum Vitae of the personnel. ### Training requirements The personnel of ACCV are subject to a specific training plan for carrying out their role within the organization: This training plan includes the following aspects: 1. Training in the basic legal aspects relating to the provision of certification services. 2. Training in information systems security. 3. Services provided by ACCV. 4. Basic concepts of PKI. 5. Certification Practice Statement and the relevant Certification Policies. 6. Incident management ACCV maintains records of such training and ensure that personnel entrusted with Validation Specialist duties maintain a skill level that enables them to perform such duties satisfactorily. ACCV documents that each Validation Specialist possesses the skills required by a task before allowing the Validation Specialist to perform that task. ACCV requires all Validation Specialists to pass an examination provided by the CA on the information verification requirements outlined in the "Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates". ### Retraining Frequency and Requirements Prior to technological changes in the environment, the introduction of new tools or the modification of operating procedures, the appropriate training will be carried out for the personnel affected. Training sessions will be carried out prior to changes in the Certification Practice Statement, Certification Policies or other relevant documents. ### Job Rotation Frequency and Sequence No rotation plan has been defined for the personnel Agencia de Tecnología y Certificación Electrónica in the assignment of its tasks. ### Sanctions for Unauthorized Actions In the event that an unauthorized action is carried out regarding to the operations of the Certification Authority, disciplinary measures shall be taken. Actions which contravene the Certification Practice Statement or the relevant Certification Policies in a negligent or malicious way shall be considered to be unauthorized actions. If any infringement occurs, the Certification Authority shall suspend the access of the persons involved to all the Certification Authority information systems, as soon as it becomes aware of the infringement. In addition, and according to the seriousness of the infringements, the sanctions provided for in the Civil Service Act, the company collective agreement, or the Workers' Statute shall be applied in accordance with the employment situation of the infringing party. ### Independent Contractor Requirements The external personnel that is involved in the issuance of certificates receives the necessary technical and legal training to carry out their tasks with due diligence (at least the detailed training on section 5.3.3). All personnel are subject to a secrecy obligation by virtue of signing the confidentiality agreement begin working for ACCV. In this agreement, they also undertake to carry out their duties in accordance with this Certification Practice Statement, ACCV Information Security Policy and the approved procedures of ACCV. ### Documentation Supplied to Personnel Personnel joining the Certification Authority are provided with access to the following documentation: •Certification Practice Statement •Certification Policies •Privacy policy •Information Security Policy •Organization chart and roles of personnel Access is provided to documentation relating to regulations and security plans, emergency procedures and all technical documentation necessary for personnel to carry out their roles. ### Periodic compliance checks The check that personnel possess the necessary knowledge is carried out at the end of the training sessions and on a discretionary basis, by the training staff responsible for teaching these courses and, as a last resort, by the Training, Support and Communications Manager. The verification of the existence of the documentation that employees must be familiar with and sign is carried out annually by the Documentation Manager. The Security Manager carries out an annual review of the compliance of the authorizations granted with the actual privileges given to employees. ### Termination of contracts In the event of termination of the employment relationship of personnel performing their duties at ACCV, the Security Manager shall proceed to carry out the actions or checks detailed in the following points, either directly or by instructing the appropriate personnel to do so. #### Access to organizational locations The individual\'s access privileges to the organization\'s facilities to which access is restricted shall be removed. This involves, at a minimum, the removal of access authorization to the following locations - Suppression of privilege access to the main CPS - Suppression of privilege access to the secondary CPS - Suppression of privileged access to computer rooms and facilities and dependencies of Polígono Ademuz S/N in Burjassot (Valencia). #### Access to Information Systems The individual\'s access privileges to the organization\'s Information Systems should be removed, with special attention to administration privileges and remote access privileges. - User deletion on servers - User deletion in ACCV Document Repository (RD-ACCV) - User deletion in Incident Control System - Change known passwords - Root / Server Administrator - FW - Network electronics (switches, balancers, routers,\...) - IDS #### Access to documentation Suppression of access to all information, with the exception of information considered PUBLIC. Removal of access to the Secure Developer Zone on ACCV website. #### Information to the rest of the organization The rest of the organization should be clearly informed of the individual\'s departure and loss of privileges. This is to minimize the possibility of \"social engineering\" attacks by the individual. #### Information to suppliers and collaborating entities Suppliers and entities collaborating with ACCV must also be informed of the departure of the individual and that he/she no longer represents ACCV. #### Return of material The return of material provided by ACCV should be verified. For example: - PC and monitor / laptop - Office furniture keys - Cell phone - etc #### Suspension as PRU Operator The need for the employee to maintain their ability to operate as a PRU Operator after leaving the organization should be reviewed. If this need does not exist, the employee\'s permission to access the ARCA .system should be revoked ## Audit Logging Procedures ### Types of events recorded ACCV records all events relating to: •Successful or failed attempts to change the security parameters of the operating system. •Start-up and stoppage of applications. •Successful or failed attempts to start or end a session. •Successful or failed attempts to create, modify or delete system accounts. •Successful or failed attempts to create, modify or delete authorized system users. •Successful or failed attempts to request, generate, sign, issue or revoke keys and certificates. •Successful or failed attempts to generate, sign or issue a CRL. •Successful or failed attempts to create, modify or delete certificate holder information. •Successful or failed attempts to access installations by authorized or unauthorized personnel. • Successful and unsuccessful login attempts to routers and firewalls • Logging of all administrative actions performed on routers and firewalls, including configuration changes, firmware updates, and access control modification • Logging of all changes made to firewall rules, including additions, modifications, and deletions • Logging of all system events and errors, including hardware failures, software crashes, and system restarts •Backup, file and restoration. •Changes to system configuration. •Software and hardware updates. •System maintenance. •Changes of personnel All these records are centralized at several points: - The incident management system (change management, tracking of non-personal certificates, etc\...). - The centralized log system (centralizes via syslog the events of the core systems) - The Active Directory log for the organization\'s LAN. ### Frequency of Processing Log Two levels of audits are established for the control of event records with a weekly and monthly frequency, respectively. ### Retention Period for Audit Log ACCV shall retain all the relevant audit records generated by the system for a minimum period from the date of their creation of two (2) years for those relating to daily audits, five (5) years for those relating to monthly audits and fifteen (15) years for those relating to annual audits. ### Protection of Audit Log Each audit log contained in these records is encrypted using the public key of a certificate that is issued for ACCV audit function. The backup copies of these records are stored in a fireproof file locked within the secure ACCV installations. The destruction of an audit file can only be carried out with the authorization of the System Administrator, the Security Manager and ACCV Auditor. This destruction can be begun on the written recommendation of any of these three parties or of the Administrator of the audited service. ### Audit log backup procedures Incremental local and remote copies are generated on a daily basis, in accordance with ACCV's Backup Copies Policy. ### Audit information collection system (internal vs. external) The audit gathering system on ACCV information systems is a combination of automatic and manual processes carried out by the operating systems, ACCV applications, and the personnel that operates them. ### Notification to the subject causing the event There is no provision for notification regarding the subject giving rise to the log. ### Vulnerability Assessments At least one yearly analysis is carried out of vulnerabilities and perimeter security. It is the responsibility of the analysis team coordinators to inform ACCV, via the Security Manager, of any problem preventing the performance of the audits, or the delivery of the resulting documentation. It is the responsibility of ACCV to inform the audit teams of the suspension of analyses. The security analyses involve the initiation of the specific tasks to correct the vulnerabilities detected and the issue of a counter-report by ACCV. ## Records Archival ### Types of Records Archived The information and events recorded are as follows: \- The audit records specified in point 5.4 of this Certification Practice Statement. \- The backup supports of the servers that comprising ACCV infrastructure. \- Documentation relating to the certificates' life cycles, including: • Certification contract • Copy of the identification documentation provided by the certificate requester • Location of the User Registration Point -PRU- where the certificate was issued • Identity of the Operator of the PRU where the certificate was issued • Date of the last in-person identification of the subscriber \- Confidentiality agreements \- Agreements signed by ACCV \- Authorizations for Access to Information Systems (including User Registration Point Operator authorization). ### Retention Period for Archive All information and documentation related to the life cycle of the certificates issued by ACCV is retained for a period of 15 years. ### Protection of Archive Access to the archive is restricted to authorized personnel. Likewise, the events related to the certificates issued by ACCV are cryptographically protected to guarantee the detection of manipulations in their content. ### Archive Backup Procedures. Two daily copies are made of the files that comprising the archives to be retained. One copy is made locally and is stored in a fireproof safe in ACCV main Data Processing Center. The second copy of the data is made in encrypted and remote manner and is stored in the continuity/backup Data Processing Center located in a building other than ACCV main DPC building. ### Requirements for Time-Stamping of Records ACCV systems record the time that the archives are made. The systems time is provided by a reliable time source. All ACCV systems synchronize their time with this source. ### Archive Collection System (Internal or External) The information collection system is an internal ACCV system. ### Procedures to Obtain and Verify Archive Information Only authorized personnel have access to physical backup and IT files in order to carry out integrity verification or other kinds of checks. Integrity validation of electronic archives (backups) are carried out automatically at time of their generation and an incident is created in the event of errors or unexpected events. ## Key Changeover ACCV CA\'s private signing key is changed periodically. ACCV will stop issuing certificates associated and will proceed to sign or issue new certificates from the corresponding Certification Authority before the end of the validity period is reached, in accordance with the provisions of section 6.3.2. The prior key will continue to sign and publish CRLs until the end of its useful life. The key change or the issuance of a new certificate for the signing of the subscriber certificates will be carried out in such a way that the impact on the subscribers and trusted parties is minimal. All affected entities will be notified prior to a planned key change. ## Compromise and Disaster Recovery ### Incident and Compromise Handling Procedures The Incident Response Plan and the Disaster Recovery Plan describe all the actions carried out and the material and human resources to solve a specific incident. These documents detail the actions to: Notify users, evaluate the incident, activate safeguards At this point, if necessary, the different actors of the WebPKI ecosystem will be notified using the available and commonly used tools (Bugzilla, distribution lists, etc.) as stipulated in the different recognition policies. Recover affected services to provide adequate levels Restore regular operations and processes to normal levels In the event of the unavailability of the installations of the Certification Authority for a period greater than six hours, ACCV's Incident Response Plan and a Disaster Recovery Plan shall be activated. The Disaster Recovery Plan guarantees that services identified as critical due to their availability requirement will be available in the Continuity DPC in less than 12 hours following activation of the Plan. ACCV annually test, review, and update these procedures. ### Computing Resources, Software, and/or Data are corrupted If hardware, software and/or data resources are altered or are suspected of having been altered, the operation of ACCV's services shall be suspended until a secure environment is re-established with the incorporation of new components of creditable effectiveness. In parallel, an audit shall be carried out to identify the cause of the alteration and ensure the non-reoccurrence of the alteration. In the event of issued certificates being affected, the certificate subscribers shall be notified of this and re-certification shall take place. All these actions are included in the incident response plan. ### Entity Private Key Compromise Procedures In the event of the compromise of an entity's key, it shall immediately be revoked and this shall be notified to the rest of the entities that are part of ACCV whether they are dependent or not on the affected entity. The corresponding CRL shall be generated and published, the entity operations shall be suspended and the process of generation, certification and start-up of a new entity with the same name as the withdrawn one and with a new key pair will begin. In the event that the affected entity is a CA, the entity's revoked certificate shall remain accessible in ACCV repository for the purpose of continuing to permit the verification of the certificates issued during the entity's period of operation. The entities comprising ACCV that are dependent on the renewed entity shall be informed about the fact and ordered to request their re-certification due to the entity having been renewed. Certificates signed by entities dependent on the compromised entity during the period between compromise of the key and revocation of the corresponding certificate, shall in turn be revoked, and their subscribers informed and re-certified. ### Business Continuity Capabilities after a Disaster In the event of a natural disaster affecting the installations of ACCV\'s main Data Processing Center and, therefore, the services provided from this location, the Service Continuity Plan shall be activated, guaranteeing that the services identified as critical due to their availability requirement, shall be available in the Continuity DPC in less than 12 hours following the Plan activation, and the remaining essential services shall be available within reasonable and appropriate periods to their level of necessity and critical nature. ## CA or RA Termination The causes that can lead to the termination of the Certification Authority operations are as follows: •Compromise of the CA private key • Political decision by the Autonomous Government of Valencia In the event of termination of its activity as Certification Services Provider, ACCV shall carry out the following actions with a minimum notice period of two months: •To duly inform about their intentions to terminate their activity to all the subscribers of their certificates, as well as to third parties with whom it has signed a contract / agreement or who may be affected. •To finalize any contract / agreement that allows acting on your behalf in the procedure of issuing certificates. •With the consent of the subscribers, transfer to another Qualified Trust Service Provider those certificates that remain valid on the effective date of cessation of activity. If this transfer is not accepted or not possible, the certificates will be revoked. •To communicate to the Ministry that at that moment it has the competences in the matter, the cessation of its activity and the destination that it will give to the certificates, as well as any other relevant circumstance related to the cessation of activity. •To send to the Ministry competent in the matter all the information related to the revoked certificates so that the latter takes care of their custody to the pertinent effects. # Technical Security Controls ## Key Pair Generation and Installation ### Key pair generation #### CA Key Pair Generation Following this procedure, ACCV will prepare and follow a Key Generation Script, have a Qualified Auditor witness the CA Key Pair generation process, and have a Qualified Auditor issue a report opining that the CA followed its key ceremony during its Key and Certificate generation process and the controls used to ensure the integrity and confidentiality of the Key Pair. This procedure describes the following: - roles participating in the ceremony; - functions to be performed by every role and in which phases; - responsibilities during and after the ceremony; and - requirements of evidence to be collected of the ceremony. The procedure of issuing, signing and distributing of new CA Certificate, specifying that before the expiration of the Certificate a new one is generated, thus avoiding possible interruptions in the operations from any entity that can trust the Certificate. For reasons of security and quality, the Keys that ACCV needs to carry out its activities as a Trust Service Provider will be generated by the Entity itself inside its own infrastructures, in a physically secure environment and by at least two authorised persons. Key pairs for all ACCV internal components are generated on cryptography hardware modules with FIPS 140-1 Level 4 certification. In the case of components of CA type, there is audited documentation of the creation ceremony, which includes the steps followed, the personnel involved and the distribution of the activation mechanisms. All these steps are carried out and recorded in the presence of a qualified auditor and in a secured environment. Key algorithms and lengths employed are based on standards that are broadly recognised for the purpose for which they are generated. The technical components necessary to create Keys are designed so that a Key is only generated once and so that a Private Key cannot be calculated using its Public Key. #### RA Key Pair Generation Not stipulated #### Subscriber Key Pair Generation ##### Qualified Website Authentication Certificates The key pair for certificates issued under this policy is generated in software by the certificate subscriber. ##### Electronic Administrative Headquarters Certificates in Hardware Secure Module The key pair for certificates issued under this policy is generated in the user\'s HSM and never leaves it. ##### Electronic Administrative Headquarters Certificates based on software The key pair for certificates issued under this policy is generated in software by the certificate subscriber. ##### Server Authentication Certificates The key pair for certificates issued under this policy is generated in software by the certificate subscriber. ### Private Key Delivery to Subscriber The private key is generated by the subscriber, therefore, it is not necessary to deliver it to the subscriber. ### Public Key Delivery to Certificate Issuer The public key to be certified is generated by the subscriber in the device corresponding to the type of certificate and is delivered to the Certification Authority by the Registration Authority by sending a certification request in PKCS#10 format, digitally signed by the subscriber. If it is detected that the public key of the request does not meet the requirements (weak key, compromise etc\...) it will be rejected. ### CA Public Key Delivery to Relying Parties The public keys of all CAs belonging to ACCV trust hierarchy can be downloaded from the website http://www.accv.es. ### Key Sizes The keys of ACCVRAIZ1 root and the certificate authorities that are in the same hierarchy are RSA keys of 4096 bits in length. The keys of ACCV ROOT RSA TLS 2024 root ACCV ROOT and certificate authorities that are in the same hierarchy are RSA keys of 4096 bits in length. The keys of ACCV ROOT ECC TLS 2024 root ACCV ROOT and certification authorities that are in the same hierarchy are 384-bit long ECC keys. The key size for end-entity certificates issued under the scope of this Certification Policy is: - For RSA keys of at least 2048 bits. - For ECDSA keys of at least NIST ECC P-256. ### Public Key Parameters Generation and Quality Checking Keys for ACCVRAIZ1 and CAs of the same hierarchy are created with the RSA algorithm. Keys for ACCV ROOT RSA TLS 2024 and CAs of the same hierarchy are created with the RSA algorithm. Keys for ACCV ROOT ECC TLS 2024 and CAs of the same hierarchy are created with the ECC algorithm. For end-entity certificates, the parameters defined in ETSI TS 119 312 \"Electronic Signatures and Infrastructures (ESI); Cryptographic Suites\" are used. The parameters used are as follows: +----------------+----------------+----------------+-----------------+ | **Signature | **Hash | **Padding | **Signature | | Suite** | Function** | Method** | algorithm** | +:===============+:===============+:===============+:================+ | s | sha256 | e | rsa | | ha256-with-rsa | | msa-pkcs1-v1.5 | | +----------------+----------------+----------------+-----------------+ | s | SHA-256, | | ecdsa | | ha2-with-ecdsa | SHA-384 or | | | | | SHA-512 | | | +----------------+----------------+----------------+-----------------+ ACCV performs the validation of RSA and ECC keys following the procedures defined in NIST SP 800-89 and NIST SP 800-56A: Revision 3 ### Key Usage Purposes (as per X.509 v3 key usage field) All subscriber certificates issued by ACCV contain the KEY USAGE and EXTENDED KEY extensions. USAGE defined by the X.509 v3 standard for the definition and limitation of these purposes. The private keys corresponding to the root certificates are not used to sign certificates, except in the following cases Self-signed certificates to represent the Root CA itself. Certificates for SubCAs, and, if applicable, Cross Certificates. Certificates for infrastructure purposes (administrative function certificates, internal CA operating device certificates) Certificates for OCSP response verification The keys defined by this policy will be used for the purposes described in 1.3 User Community and Scope of Application. > The detailed definition of the certificate profile and the uses of the > keys can be found in section 7 of this document *\"Certificate, CRL > and OCSP Profiles\"*. ### Key generation hardware/software #### CA Keys Keys for PKI entities are generated on cryptographic HSM devices with FIPS 140-1 Level 4 certification. The devices used are: - Thales Nshield 500e F2, with [EAL-4+](http://www.commoncriteriaportal.org/files/epfiles/ncipher-nshield-v23360-cert-eng.pdf) certification and [FIPS 140-2 Level3](http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/1401val2007.htm#740) - AEP Keyper Enterprise Model 9720, with [FIPS-140-2 Level4](http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140crt/140crt956.pdf) certification. - Thales Luna PCIe HSM A700 with [FIPS 140-2 Level3](http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/1401val2007.htm#740) Certification - Thales Luna Network HSM A790 with certification [FIPS 140-2 Level3](http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/1401val2007.htm#740) #### Qualified Website Authentication Certificates Key generation is performed in software by the certificate subscriber. #### Electronic Administrative Headquarters Certificates in Hardware Secure Module Key generation is performed in HSM. The minimum requirements for these devices are those specified by the corresponding competent Ministry, and in accordance with European technical standards. #### Electronic Administrative Headquarters Certificates based on software Key generation is performed in software by the certificate subscriber. #### Server Authentication Certificates Key generation is performed in software by the certificate subscriber. ## Private Key Protection and Cryptographic Module Engineering Controls ACCV will protect its Private Key(s) in accordance with the provisions of this CPS and in compliance with the CA/Browser Forum Baseline Requirements. ### Cryptographic Module Standards and Controls #### CA Keys It is mandatory that the modules used for the creation of keys used by all CAs integrated in the trust hierarchies comply with a security certification appropriate to their functionality and the security required. A hardware security module (HSM) is a security device that generates and protects cryptographic keys. Therefore, these products must meet, at a minimum, FIPS 140-2 level 3, or Common Criteria EAL 4+ criteria for the corresponding protection profile. ACCV has procedures and policies in place to verify that an HSM has not been tampered with during transport and storage. Cryptographic devices with qualified electronic signature certificates, suitable as qualified signature creation devices (DSCF), meet the requirements of the CC EAL4+ security level, although certifications that meet a minimum of ITSEC E3, FIPS 140-2 Level 2 or equivalent security criteria are also acceptable. The European reference standard for the devices used is Commission Implementing Decision (EU) 2016/650 of 25 April 2016. #### Qualified Website Authentication Certificates The cryptographic modules are located in software on the subscriber\'s device. #### Electronic Administrative Headquarters Certificates in Hardware Secure Module HSM devices used in the issuance of these certificates must be ITSEC E5 high, FIPS 140-2 level 3 or equivalent certified and support PKCS#11 and CSP standards. HSMs certified by the nationally accredited agency (OC-CCN https://oc.ccn.cni.es/index.php/es/) are also accepted. Key generation is performed in the HSMs. The minimum requirements for these devices are those specified by the relevant competent authority and in accordance with European technical standards. These HSMs must be accredited as Secure Signature Creation Device/Secure Seal Creation Device according to eIDAS (QsigCD/QsealCD) regulations. #### Electronic Administrative Headquarters Certificates based on software The cryptographic modules are located in software on the subscriber\'s device. #### Server Authentication Certificates The cryptographic modules are located in software on the subscriber\'s device. ### Private Key (n out of m) Multi-Person Control The private keys used by the certification authorities that make up both hierarchies are under multi-person control. All of them are divided into several fragments and a minimum of two of these fragments is necessary to access the key. Not applicable in the case of end-entity/subscriber private keys. ### Private Key Escrow Subscriber private signature keys are not stored. Private keys of the Certification Authorities and Registration Authorities that are part of ACCV are stored in cryptography hardware devices with FIPS 140-2 level 3 certification. The rest of the private keys of entities comprising ACCV are contained on cryptography smartcards in the possession of the Administrators of each entity. ### Private Key Backup The CA private signature keys SHALL be backed up under the same multi-person control as the original signature key. There is a procedure for activating the keys of the cryptographic backup module of the CA (root or subordinate) that can be applied in the event of a contingency. All private keys of ACCV entities are under the exclusive control of ACCV. The private keys of the subscribers of the certificates defined by this policy are not stored or backed up. ### Private Key Archival. Backups of expired private keys of ACCV entities are stored in encrypted form in a fireproof safe, which can only be accessed by authorized personnel with at least dual access. All private keys of ACCV entities are under the exclusive control of ACCV. The private keys of the subscribers of the certificates defined by this policy are not archived. ### Private Key Transfer into or from a Cryptographic Module #### CA Keys Private keys are created on the cryptography module at the time of the creation of each ACCV entity that use these modules, fulfilling the requirements defined in section 6.2.1. #### Qualified Website Authentication Certificates Not applicable within the scope of this CPS. #### Electronic Administrative Headquarters Certificates in Hardware Secure Module The generation of the keys that are associated to the certificate is carried out inside the HSM and never leaves it. #### Electronic Administrative Headquarters Certificates based on software Not applicable within the scope of this CPS. #### Server Authentication Certificates Not applicable within the scope of this CPS. ### Storage of the private key in the cryptographic module #### CA Keys Private keys are created in the cryptographic module at the time of the creation of each of ACCV entities that make use of these modules, complying with the requirements defined in the section \"Private keys\". 6.2.1 #### Qualified Website Authentication Certificates Not applicable within the scope of this CPS. #### Electronic Administrative Headquarters Certificates in Hardware Secure Module The private key is generated by the applicant and is never in possession of the Agency of Technology and Electronic Certification. The storage of the private key will depend on the mechanisms of the HSM chosen to generate and store the keys. #### Electronic Administrative Headquarters Certificates based on software Not applicable within the scope of this CPS. #### Server Authentication Certificates Not applicable within the scope of this CPS. ### Method of Activating Private Key #### CA Keys The private keys of each of the CAs that conform trust hierarchies are activated by means of the initialization of the CA software and the activation of the cryptography hardware that contains the keys. Once the CA system has been activated, a threshold number of shareholders SHALL be required to supply their activation data in order to activate a CA's Private Key, as defined in 6.2.2. Once the Private Key is activated, the Private Key MAY be active for an indefinite period until it is deactivated when the CA goes offline. #### Qualified Website Authentication Certificates The private key is generated by the applicant and is never in the possession of ACCV. #### Electronic Administrative Headquarters Certificates in Hardware Secure Module The private key is generated by the applicant and is never in possession of ACCV. The activation will depend on the mechanisms of the HSM chosen to generate and store the keys. #### Electronic Administrative Headquarters Certificates based on software The private key is generated by the applicant and is never in the possession of ACCV. #### Server Authentication Certificates The private key is generated by the applicant and is never in the possession of ACCV. ### Method of Deactivating Private Key #### CA Keys An Administrator can proceed to deactivate ACCV Certification Authorities key by stopping the CA software. #### Qualified Website Authentication Certificates The private key is generated by the applicant and is never in the possession of ACCV. #### Electronic Administrative Headquarters Certificates in Hardware Secure Module The private key is generated by the applicant and is never in possession of the Agency of Technology and Electronic Certification. The deactivation will depend on the mechanisms of the HSM chosen to generate and store the keys. #### Electronic Administrative Headquarters Certificates based on software The private key is generated by the applicant and is never in the possession of ACCV. #### Server Authentication Certificates The private key is generated by the applicant and is never in the possession of ACCV. ### Method of Destroying Private Key The destruction of a token can be done for the following reasons: - Cessation of the use of the keys contained - Deterioration such that it does not allow efficient use of the token, but does not totally prevent its use. - Recovery of a lost token or stolen. Destruction must always be preceded by a revocation of the certificate associated with the token, if it is still valid. Private Keys are destroyed in accordance with NIST SP 800-88. #### Cryptographic hardware HSM destruction is not contemplated, due to its high cost. Instead, initialization tasks will be carried out. During the transition from the \"operational\" to the \"initialization\" state, the keys contained therein are securely deleted. #### Cryptographic cards The destruction of the token can be done when the information printed on the token becomes invalid and a new card must be issued. The task to be performed consists of a **Secure Destruction** of the Token at the physical level. #### Qualified Website Authentication Certificates The private key is generated by the applicant and is never in the possession of ACCV. It can be destroyed by deleting it following the instructions of the application that hosts it. #### Electronic Administrative Headquarters Certificates in Hardware Secure Module The private key is generated by the applicant and is never in possession of the Agency of Technology and Electronic Certification. Destruction will depend on the mechanisms of the HSM chosen to generate and store the keys. #### Electronic Administrative Headquarters Certificates based on software The private key is generated by the applicant and is never in the possession of ACCV. It can be destroyed by deleting it following the instructions of the application that hosts it. #### Server Authentication Certificates The private key is generated by the applicant and is never in the possession of ACCV. It can be destroyed by deleting it following the instructions of the application that hosts it. ### Cryptographic Module Rating See6.2.1 section of this document. ## Other Aspects of Key Pair Management. ### Public Key Archival ACCV maintains an archive of all certificates issued for a period of fifteen (15) years. ### Certificate Operational Periods and Key Pair Usage Periods ACCVRAIZ1 root CA certificate is valid until 12/31/2030 and the CAs belonging to its hierarchy are valid for 4 years less than the root CA. ACCV ROOT RSA TLS 2024 Root CA certificate is valid until Saturday, January 26, 2049 and the CAs belonging to its hierarchy are valid until February 23, 2039. ACCV ROOT ECC TLS 2024 Root CA certificate is valid until Saturday, January 26, 2049 and the CAs belonging to its hierarchy are valid until February 23, 2039. Registration Authorities and other ACCV entities have a maximum term of three (3) years. Certificates issued under this policy are valid for a maximum of 12 months. The key used for the issuance of certificates is provided for each issuance, and therefore they are also valid for a maximum of 12 months. This is the maximum validity date allowed in the application for certificates issued under this policy. ACCVCA-120 certificate is valid from January 27, 2015 through January 1, 2027. ACCV RSA1 TLS certificate is valid from February 27, 2024 to February 23, 2039. ACCV ECC1 TLS certificate is valid from February 27, 2024 to February 23, 2039. ## Activation Data ### Activation Data Generation and Installation #### Certification Authorities The activation data of ACCV Certification Authorities are generated and stored in secure devices in possession of authorized personnel. #### Qualified Website Authentication Certificates The private key is generated by the applicant and is never in the possession of ACCV. #### Electronic Administrative Headquarters Certificates in Hardware Secure Module The private key is generated by the applicant and is never in possession of ACCV. The activation data will depend on the mechanisms of the HSM chosen to generate and store the keys. #### Electronic Administrative Headquarters Certificates based on software The private key is generated by the applicant and is never in the possession of ACCV. #### Server Authentication Certificates The private key is generated by the applicant and is never in the possession of ACCV. ### Activation Data Protection Only authorized personnel know the PINs and passwords to access the activation data. #### Certification Authorities Only authorized personnel know the PINs and passwords to access the activation data. #### Qualified Website Authentication Certificates The subscriber is responsible for the protection of his private key activation data. #### Electronic Administrative Headquarters Certificates in Hardware Secure Module The subscriber is responsible for the protection of his private key activation data. #### Electronic Administrative Headquarters Certificates based on software The subscriber is responsible for the protection of his private key activation data. #### Server Authentication Certificates The subscriber is responsible for the protection of his private key activation data. ### Other Aspects of Activation Data There are no other aspects to consider. ## Computer Security Controls ### Specific Computer Security Technical Requirements ACCV implements an Information Security Management System (ISMS) based on the **ISO-27001** standard and establishes controls and procedures for its correct compliance. - \- Operational controls - \- User procedures documented - \- Safe delete procedures for storage and removable media, so obsolete equipment. - \- Contingency and Continuity plans - \- Antivirus and Antimalware - \- Strict policy on which types of software users may install - \- Security data exchanges - \- Transmission with CA and RA - \- Transmission with CA and RA Databases - \- User data - \- Access control - \- Dual factor based authentication for CA and RA operators - \- Use the principle of least privilege - \- Unique and nominal user IDs - \- Periodic audits of the privileges applied - \- Strict provisioning procedures - \- Enforcement guides for passwords and security tokens. ACCV has a security policy and procedures to guarantee security. ### Computer Security Rating ACCV implements an Information Security Management System (ISMS) based on the **ISO-27001** standard and establishes controls and procedures for its correct compliance. During the continuous evaluation of the ISMS, impact and risk analyses are performed to assess IT security. ## Lifecycle Technical Controls ### System Development Controls ACCV implements an Information Security Management System (ISMS) based in standard **ISO-27001** and establishes controls and procedures for its correct compliance. There are several procedures and guidelines from ACCV associated with development control: > \- Development and Testing Policy > > \- ACCV Development Best Practices Guidelines > > \- Change Control Procedure > > \- Capacity Management > > \- Business Continuity Plan All these procedures have the corresponding documentary support in the ACCV document manager. The characteristics of the ACCV development system: > Continuous integration process > > Tools to analyze and detect anomalies in the code > > Strict separation between the development and test platform and the > working platform > > The test and real data are independent > > Test and development never work with real data The production process is carried out after an exhaustive approval process, following the change control procedure, always warranting the roll-back. ### Security Management Controls ACCV implements an Information Security Management System (ISMS) based in standard **ISO-27001** and establishes controls and procedures for its correct compliance. There are several procedures and guidelines from ACCV associated with security control: \- Staff Security Functions and Controls \- Asset Inventory \- Procedure for the safe use of devices and media \- Business Continuity Plan \- Change Control Procedure \- Incident Management Procedure \- Vulnerability Management Procedure All these procedures have the corresponding documentary support in the ACCV document manager. Certificate subscribers can contact the ACCV to report any incident using the channels specified in: and as indicated in 1.5.2 ACCV keeps a detailed record of all incidents, as well as the solutions implemented in its resolution, as specified in the ISMS. ### Lifecycle Security Controls ACCV periodically performs security and vulnerability tests in the different phases of the software life cycle (SDL). \- Threat modeling to avoid errors in the design phase \- Automatic code review tools for detecting bugs, vulnerabilities and code defects (Sonarqube) \- Vulnerability scanning and penetration testing. ## Network Security Controls ACCV protects physical access to network management devices and has an architecture that distributes traffic according to its security characteristics, creating clearly defined network sections. These sections are divided by multi-level zoning, using multiple redundant firewalls. Sensitive information transferred over insecure networks is encrypted using SSL protocols. ACCV conforms with the latest version of the CAB Forum Network and Certificate System Security Requirements. ## Time-Stamping ACCV has a qualified Time Stamping Authority (TSA). The rules and procedures governing the TSA can be found in its respective policy at https://www.accv.es/quienes-somos/practicas-y-politicas-de-certificacion/politicas-de-certificacion/. The anonymous access URL is at: # Certificate, CRL and OCSP Profiles ## Certificate Profile ACCV generates serial numbers with 127 bits of entropy. The main application forces this behavior. It implements a singleton serial number generator using SecureRandom. This generator generates random serial numbers of 16 octets (128 bits). ### Version number ACCV supports and uses X.509 version 3 (X.509 v3) certificates. X.509 is a standard developed by the International Telecommunication Union (international organization of the United Nations for the coordination of telecommunications network services between governments and companies) for Public Key Infrastructures and digital certificates. ### Certificate Extensions; implementation of RFC 5280 Certificate extensions, their criticality and cryptographic algorithm object identifiers are provisioned according to IETF RFC 5280 standards and comply with CAB Forum Baseline Requirements. #### Root CAs The extensions used generically in the certificates are: - Key Usage. Marked as critical in all cases - KeyCertSign CRLSign - Basic Constraint - Present and marked as critical - Field CA TRUE - Certification policies - ACCVRAIZ1: Present and marked non-critical - ACCV ROOT RSA TLS 2024: Not Present - ACCV ROOT ECC TLS 2024: Not present - SubjectAlternativeName. - ACCVRAIZ1: Present and marked non-critical - ACCV ROOT RSA TLS 2024: Not Present - ACCV ROOT ECC TLS 2024: Not present - CRL Distribution Point. - ACCVRAIZ1: Present and marked non-critical - ACCV ROOT RSA TLS 2024: Not Present - ACCV ROOT ECC TLS 2024: Not present - extKeyUsage - Not present - authorityInformationAccess - ACCVRAIZ1: Present and marked non-critical - ACCV ROOT RSA TLS 2024: Not Present - ACCV ROOT ECC TLS 2024: Not present - nameConstraints: Not present #### Subordinate Cas The extensions used generically in the certificates are: - Key Usage. Marked as critical in all cases - KeyCertSign CRLSign - Basic Constraint - Present and marked as critical - Field CA TRUE - Certification policies - Present and marked as non-critical - SubjectAlternativeName. - ACCVCA-110: Present and marked non-critical - ACCVCA-120: Present and marked non-critical - ACCVCA-130: Present and marked non-critical - ACCV RSA1 TLS: Not Present - ACCV ECC1 TLS: Not present - CRL Distribution Point. - ACCVCA-110: Present and marked non-critical - ACCVCA-120: Present and marked non-critical - ACCVCA-130: Present and marked non-critical - ACCV RSA1 TLS: Present and marked as non-critical - ACCV ECC1 TLS: Present and marked as non-critical - extKeyUsage - ACCVCA-110: Not present - ACCVCA-120: Not present - ACCVCA-130: Not present - ACCV RSA1 TLS: Client authentication, Server authentication - ACCV ECC1 TLS: Client authentication, Server authentication - authorityInformationAccess - Present and marked as non-critical - nameConstraints: Not present #### Subscriber Certificates ##### Qualified Website Authentication Certificates +-------------------+--------------------------------------------------+ | > **Field** | > **Value** | +-------------------+--------------------------------------------------+ | > ***Subject*** | | +-------------------+--------------------------------------------------+ | > SerialNumber | NIF of the Administration, organization or | | | entity of public or private law subscriber of | | | the certificate, to which the website is linked. | +-------------------+--------------------------------------------------+ | > CommonName | Domain Name (DNS) where the certificate will | | | reside. If it appears it must match a DNSName of | | | the SAN. (OPTIONAL not recommended) | +-------------------+--------------------------------------------------+ | > Organ | Tax ID number of the entity, as it appears in | | izationIdentifier | the official records. Encoded According to | | > | European Standard ETSI EN 319 412-1 | | > (2.5.4.97) | | +-------------------+--------------------------------------------------+ | > Organization | > Denomination (\"official\" name) of the | | | > Administration, organization or public law | | | > entity subscribing the certificate and owner | | | > of the domain. | +-------------------+--------------------------------------------------+ | > Locality | > City | +-------------------+--------------------------------------------------+ | > State | > Province | +-------------------+--------------------------------------------------+ | > Country | > ES (code ISO 3166-1) | +-------------------+--------------------------------------------------+ | > ***Version*** | > V3 | +-------------------+--------------------------------------------------+ | > * | > Unique identifier of the certificate. Less | | **SerialNumber*** | > than 32 hexadecimal characters. | +-------------------+--------------------------------------------------+ | > ***Signature | > ACCVCA-120 sha256withRSAEncryption | | > algorithm*** | > | | | > ACCV RSA1 TLS sha256withRSAEncryption | | | > | | | > ACCV ECC1 TLS ecdsa-with-SHA384 | +-------------------+--------------------------------------------------+ | > ***Issuer*** | > DN of the CA issuing the certificate (see | | | > 7.1.4) | +-------------------+--------------------------------------------------+ | > ***Valid | > Issuance Date | | > from*** | | +-------------------+--------------------------------------------------+ | > ***Valid | > Expiration Date | | > until*** | | +-------------------+--------------------------------------------------+ | > ***Public | > Octet String containing the certificate public | | > Key*** | > key | +-------------------+--------------------------------------------------+ | > ***Extended Key | > Server Authentication | | > Usage*** | > | | | > Client Authentication (optional) | +-------------------+--------------------------------------------------+ | > ***CRL | > ACCVCA-120: | | > Distribution | > Point*** | leadmin/Archivos/certificados/accvca120_der.crl> | | | > | | | > ACCV RSA1 TLS: | | | > | | | | | | > | | | > ACCV ECC1 TLS: | | | > | | | | +-------------------+--------------------------------------------------+ | > ***SubjectA | | | lternativeName*** | | +-------------------+--------------------------------------------------+ | | > dnsName: DNS Domain Name 1 (if commonName is | | | > included it must have the same value) | +-------------------+--------------------------------------------------+ | > Optional | > dnsName: DNS Domain Name 2 | +-------------------+--------------------------------------------------+ | > Optional | > dnsName: DNS Domain Name 3 | +-------------------+--------------------------------------------------+ | > Optional | > dnsName: DNS Domain Name 4 | +-------------------+--------------------------------------------------+ | > Optional | > dnsName: DNS Domain Name 5 | +-------------------+--------------------------------------------------+ | > Optional | > dnsName: DNS Domain Name 6 | +-------------------+--------------------------------------------------+ | > ***Certificate | | | > Policy | | | > Extensions*** | | +-------------------+--------------------------------------------------+ | > Policy OID | > {itu-t(0) identified-organization(4) etsi(0) | | | > other-certificate-policies(2042) | | | > policy-identifiers(1) ovcp(7)} | | | > | | | > 0.4.0.2042.1.7 | +-------------------+--------------------------------------------------+ | | | +-------------------+--------------------------------------------------+ | > Policy OID | > {joint-iso-itu-t(2) | | | > international-organizations(23) | | | > ca-browser-forum(140) certificate-policies(1) | | | > baseline-requirements(2) | | | > organization-validated(2)} | | | > | | | > 2.23.140.1.2.2 | +-------------------+--------------------------------------------------+ | | | +-------------------+--------------------------------------------------+ | > Policy OID | > QCP-w Qualified website certificate in | | | > accordance with EU Regulation 910/2014. | | | > | | | > itu-t(0) identified-organization(4) etsi(0) | | | > qualified-certificate-policies(194112) | | | > | | | > policy-identifiers(1) qncp-web (5) | +-------------------+--------------------------------------------------+ | | | +-------------------+--------------------------------------------------+ | > Policy OID | > 1.3.6.1.4.1.8149.3.3.5.0 | +-------------------+--------------------------------------------------+ | > Policy CPS | > http://www.accv.es/CER | | > Location | T-CUALIFICADO-WEB_ACCV-ISTEC_CIF-A40573396_SPAIN | +-------------------+--------------------------------------------------+ | > ***Authority | | | > Information | | | > Access*** | | +-------------------+--------------------------------------------------+ | *Access Method* | Id-ad-ocsp | +-------------------+--------------------------------------------------+ | *Access Location* | http://ocsp.accv.es | +-------------------+--------------------------------------------------+ | *Access Method* | Id-ad-caIssuers | +-------------------+--------------------------------------------------+ | *Access Location* | ACCVCA-120: | | | | | | | | | ACCV RSA1 TLS: | | | | | | | | | > ACCV ECC1 TLS: | | | > | | | | +-------------------+--------------------------------------------------+ | > ***Fingerprint | > Fingerprint of the certificate of the CA | | > issuer*** | > issuing the certificate | +-------------------+--------------------------------------------------+ | > ***Hashing | > RSA: SHA-256 | | > algorithm*** | > | | | > ECC: SHA-384 | +-------------------+--------------------------------------------------+ | > ***KeyUsage | > RSA: Digital Signature, Key Encipherment | | > (critical)*** | > | | | > ECC: Digital Signature | +-------------------+--------------------------------------------------+ | **SCT List | > Signed Certificate Timestamp List | | 1.3.6.1. | > | | 4.1.11129.2.4.2** | > SCT Responses from Qualified Logs. At least | | | > three different responses. | +-------------------+--------------------------------------------------+ | | | +-------------------+--------------------------------------------------+ | **QcStatement** | **QC (Qualified Certificate) Fields** | +-------------------+--------------------------------------------------+ | QcCompliance | *The certificate is qualified* | +-------------------+--------------------------------------------------+ | QcType | web *Particular type of qualified certificate* | +-------------------+--------------------------------------------------+ | QcRetentionPeriod | 15y *Retention period of material information* | +-------------------+--------------------------------------------------+ | QcPDS | > | | | > | | | > Location of PKI Disclosure Statement | +-------------------+--------------------------------------------------+ | | | +-------------------+--------------------------------------------------+ | **CA/Browser | > cabfOrganizationIdentifier (OID: 2.23.140.3.1) | | Forum | > | | Organization | > {joint-iso-itu-t(2) | | Identifier | > international-organizations(23) | | Field** | > ca-browser-forum(140) | | | > certificate-extensions(3) | | | > cabf-organization-identifier(1) } | +-------------------+--------------------------------------------------+ | | registrationSchemeIdentifier *3 character | | | Registration scheme identifier (VAT)* | +-------------------+--------------------------------------------------+ | | registrationCountry *2 character ISO 3166 | | | country code (ES)* | +-------------------+--------------------------------------------------+ | | registrationStateOrProvince *Province | | | (optional)* | +-------------------+--------------------------------------------------+ | | > registrationReference Registration reference | | | > assigned according to the identified | | | > registration scheme (CIF) | +-------------------+--------------------------------------------------+ ##### Electronic Administrative Headquarters Certificates in Hardware Secure Module +-------------------+--------------------------------------------------+ | > **Field** | > **Value** | +-------------------+--------------------------------------------------+ | > ***Subject*** | | +-------------------+--------------------------------------------------+ | > SerialNumber | NIF of the Administration, organism or public | | | law entity subscribing the certificate, to which | | | the head office is linked. | +-------------------+--------------------------------------------------+ | > CommonName | Domain Name (DNS) where the certificate will | | | reside. If it appears it must match a DNSName of | | | the SAN. (OPTIONAL not recommended) | +-------------------+--------------------------------------------------+ | > Organ | Tax ID number of the entity, as it appears in | | izationIdentifier | the official records. Encoded According to | | > | European Standard ETSI EN 319 412-1 | | > (2.5.4.97) | | +-------------------+--------------------------------------------------+ | > Organization | > Denomination (\"official\" name) of the | | | > Administration, agency or public law entity | | | > subscribing the certificate, to which the site | | | > is linked. | +-------------------+--------------------------------------------------+ | > Locality | > City | +-------------------+--------------------------------------------------+ | > State | > Province | +-------------------+--------------------------------------------------+ | > Country | > ES | | | > | | | > State whose law governs the name, which will | | | > be \"Spain\" because they are public entities. | +-------------------+--------------------------------------------------+ | > ***Version*** | > V3 | +-------------------+--------------------------------------------------+ | > * | > Unique identifier of the certificate. Less | | **SerialNumber*** | > than 32 hexadecimal characters. | +-------------------+--------------------------------------------------+ | > ***Signature | > ACCVCA-120 sha256withRSAEncryption | | > algorithm*** | > | | | > ACCV RSA1 TLS sha256withRSAEncryption | | | > | | | > ACCV ECC1 TLS ecdsa-with-SHA384 | +-------------------+--------------------------------------------------+ | > ***Issuer*** | > DN of the CA issuing the certificate (see | | | > 7.1.4) | +-------------------+--------------------------------------------------+ | > ***Valid | > Issuance Date | | > from*** | | +-------------------+--------------------------------------------------+ | > ***Valid | > Expiration Date | | > until*** | | +-------------------+--------------------------------------------------+ | > ***Public | > Octet String containing the public key of the | | > Key*** | > host certificate | +-------------------+--------------------------------------------------+ | > ***Extended Key | > Server Authentication | | > Usage*** | > | | | > Client Authentication (optional) | +-------------------+--------------------------------------------------+ | > ***CRL | > ACCVCA-120: | | > Distribution | > Point*** | leadmin/Archivos/certificados/accvca120_der.crl> | | | > | | | > ACCV RSA1 TLS: | | | > | | | | | | > | | | > ACCV ECC1 TLS: | | | > | | | | +-------------------+--------------------------------------------------+ | > ***SubjectA | | | lternativeName*** | | +-------------------+--------------------------------------------------+ | | > DnsName: DNS Domain Name of the Headquarters | | | > (if commonName is included it must have the | | | > same value) | +-------------------+--------------------------------------------------+ | > Optional | > DnsName: DNS Domain Name of the Head Office | +-------------------+--------------------------------------------------+ | > Optional | > DnsName: DNS Domain Name of the Head Office | +-------------------+--------------------------------------------------+ | > Optional | > DnsName: DNS Domain Name of the Head Office | +-------------------+--------------------------------------------------+ | > Optional | > DnsName: DNS Domain Name of the Head Office | +-------------------+--------------------------------------------------+ | > ***Certificate | | | > Policy | | | > Extensions*** | | +-------------------+--------------------------------------------------+ | Policy OID | {itu-t(0) identified-organization(4) etsi(0) | | | other-certificate-policies(2042) | | | policy-identifiers(1) ovcp(7)} | | | | | | 0.4.0.2042.1.7 | +-------------------+--------------------------------------------------+ | | | +-------------------+--------------------------------------------------+ | Policy OID | {joint-iso-itu-t(2) | | | international-organizations(23) | | | ca-browser-forum(140)certificate-policies(1) | | | baseline-requirements(2) | | | organization-validated(2)} | | | | | | 2.23.140.1.2.2 | +-------------------+--------------------------------------------------+ | | | +-------------------+--------------------------------------------------+ | Policy OID | 2.16.724.1.3.5.5.1 | +-------------------+--------------------------------------------------+ | | | +-------------------+--------------------------------------------------+ | > Policy OID | > QCP-w Qualified website certificate in | | | > accordance with EU Regulation 910/2014. | | | > | | | > itu-t(0) identified-organization(4) etsi(0) | | | > qualified-certificate-policies(194112) | | | > | | | > policy-identifiers(1) qncp-web (5) | +-------------------+--------------------------------------------------+ | | | +-------------------+--------------------------------------------------+ | > Policy OID | > 1.3.6.1.4.1.8149.3.14.6.0 | +-------------------+--------------------------------------------------+ | > Policy CPS | Location | -CUALIFICADO-WEB_ACCV-ISTEC_CIF-A40573396_SPAIN> | +-------------------+--------------------------------------------------+ | > ***Authority | | | > Information | | | > Access*** | | +-------------------+--------------------------------------------------+ | *Access Method* | Id-ad-ocsp | +-------------------+--------------------------------------------------+ | *Access Location* | http://ocsp.accv.es | +-------------------+--------------------------------------------------+ | *Access Method* | Id-ad-caIssuers | +-------------------+--------------------------------------------------+ | *Access Location* | ACCVCA-120: | | | | | | | | | ACCV RSA1 TLS: | | | http://www.accv.es/gestcert/accv_rsa1_tls.crt | | | | | | ACCV ECC1 TLS: | | | http://www.accv.es/gestcert/accv_ecc1_tls.crt | +-------------------+--------------------------------------------------+ | > ***Fingerprint | > Fingerprint of the certificate of the CA | | > issuer*** | > issuing the certificate (see CPS) | +-------------------+--------------------------------------------------+ | > ***Hashing | > RSA: SHA-256 | | > algorithm*** | > | | | > ECC: SHA-384 | +-------------------+--------------------------------------------------+ | > ***KeyUsage | > RSA: Digital Signature, Key Encipherment | | > (critical)*** | > | | | > ECC: Digital Signature | +-------------------+--------------------------------------------------+ | | | +-------------------+--------------------------------------------------+ | > ***SCT List | > Signed Certificate Timestamp List | | > 1.3.6.1.4.4 | | | .1.11129.2.4.2*** | | +-------------------+--------------------------------------------------+ | | | +-------------------+--------------------------------------------------+ | **QcStatement** | **QC (Qualified Certificate) Fields** | +-------------------+--------------------------------------------------+ | QcCompliance | *The certificate is qualified* | +-------------------+--------------------------------------------------+ | QcType | web *Particular type of qualified certificate* | +-------------------+--------------------------------------------------+ | QcRetentionPeriod | 15y *Retention period of material information* | +-------------------+--------------------------------------------------+ | QcPDS | https://www.accv.es/fileadmin/Archivos | | | /Practicas_de_certificacion/ACCV-PDS-V1.1-EN.pdf | | | | | | *Location of PKI Disclosure Statement* | +-------------------+--------------------------------------------------+ | QcSCD | Secure Signature Creation Device (SSCD) | +-------------------+--------------------------------------------------+ | | | +-------------------+--------------------------------------------------+ | **CA/Browser | cabfOrganizationIdentifier (OID: 2.23.140.3.1) | | Forum | | | Organization | {joint-iso-itu-t(2) | | Identifier | international-organizations(23) | | Field** | ca-browser-forum(140) certificate-extensions(3) | | | cabf-organization-identifier(1) } | +-------------------+--------------------------------------------------+ | | registrationSchemeIdentifier *3 character | | | Registration Scheme identifier (VAT)* | +-------------------+--------------------------------------------------+ | | registrationCountry *2 character ISO 3166 | | | country code (ES)* | +-------------------+--------------------------------------------------+ | | registrationStateOrProvince *State or Province | | | (optional)* | +-------------------+--------------------------------------------------+ | | registrationReference *Registration Reference | | | allocated in accordance with the identified | | | Registration Scheme (CIF)* | +-------------------+--------------------------------------------------+ ##### Electronic Administrative Headquarters Certificates based on software +-------------------+--------------------------------------------------+ | > **Field** | > **Value** | +-------------------+--------------------------------------------------+ | > ***Subject*** | | +-------------------+--------------------------------------------------+ | > SerialNumber | NIF of the Administration, organism or public | | | law entity subscribing the certificate, to which | | | the head office is linked. | +-------------------+--------------------------------------------------+ | > CommonName | Domain Name (DNS) where the certificate will | | | reside. If it appears it must match a DNSName of | | | the SAN. (OPTIONAL not recommended) | +-------------------+--------------------------------------------------+ | > Organ | Tax ID number of the entity, as it appears in | | izationIdentifier | the official records. Encoded According to | | > | European Standard ETSI EN 319 412-1 | | > (2.5.4.97) | | +-------------------+--------------------------------------------------+ | > Organization | > Denomination (\"official\" name) of the | | | > Administration, agency or public law entity | | | > subscribing the certificate, to which the site | | | > is linked. | +-------------------+--------------------------------------------------+ | > Locality | > City | +-------------------+--------------------------------------------------+ | > State | > Province | +-------------------+--------------------------------------------------+ | > Country | > ES | | | > | | | > State whose law governs the name, which will | | | > be \"Spain\" because they are public entities. | +-------------------+--------------------------------------------------+ | > ***Version*** | > V3 | +-------------------+--------------------------------------------------+ | > * | > Unique identifier of the certificate. Less | | **SerialNumber*** | > than 32 hexadecimal characters. | +-------------------+--------------------------------------------------+ | > ***Signature | > ACCVCA-120 sha256withRSAEncryption | | > algorithm*** | > | | | > ACCV RSA1 TLS sha256withRSAEncryption | | | > | | | > ACCV ECC1 TLS ecdsa-with-SHA384 | +-------------------+--------------------------------------------------+ | > ***Issuer*** | > DN of the CA issuing the certificate (see | | | > 7.1.4) | +-------------------+--------------------------------------------------+ | > ***Valid | > Issuance Date | | > from*** | | +-------------------+--------------------------------------------------+ | > ***Valid | > Expiration Date | | > until*** | | +-------------------+--------------------------------------------------+ | > ***Public | > Octet String containing the public key of the | | > Key*** | > host certificate | +-------------------+--------------------------------------------------+ | > ***Extended Key | | | > Usage*** | | +-------------------+--------------------------------------------------+ | | > Server Authentication | | | > | | | > Client Authentication (optional) | +-------------------+--------------------------------------------------+ | > ***CRL | | | > Distribution | | | > Point*** | | +-------------------+--------------------------------------------------+ | | > ACCVCA-120: | | | > | | | > | | | > ACCV RSA1 TLS: | | | > | | | | | | > | | | > ACCV ECC1 TLS: | | | > | | | | +-------------------+--------------------------------------------------+ | > ***SubjectA | | | lternativeName*** | | +-------------------+--------------------------------------------------+ | | > DnsName: DNS Domain Name of the Headquarters | | | > (if commonName is included it must have the | | | > same value) | +-------------------+--------------------------------------------------+ | > Optional | > DnsName: DNS Domain Name of the Head Office | +-------------------+--------------------------------------------------+ | > Optional | > DnsName: DNS Domain Name of the Head Office | +-------------------+--------------------------------------------------+ | > Optional | > DnsName: DNS Domain Name of the Head Office | +-------------------+--------------------------------------------------+ | > Optional | > DnsName: DNS Domain Name of the Head Office | +-------------------+--------------------------------------------------+ | > ***Certificate | | | > Policy | | | > Extensions*** | | +-------------------+--------------------------------------------------+ | > Policy OID | > {itu-t(0) identified-organization(4) etsi(0) | | | > other-certificate-policies(2042) | | | > policy-identifiers(1) ovcp(7)} | | | > | | | > 0.4.0.2042.1.7 | +-------------------+--------------------------------------------------+ | | | +-------------------+--------------------------------------------------+ | > Policy OID | > {joint-iso-itu-t(2) | | | > international-organizations(23) | | | > ca-browser-forum(140) certificate-policies(1) | | | > baseline-requirements(2) | | | > organization-validated(2)} | | | > | | | > 2.23.140.1.2.2 | +-------------------+--------------------------------------------------+ | | | +-------------------+--------------------------------------------------+ | Policy OID | 2.16.724.1.3.5.5.2 | +-------------------+--------------------------------------------------+ | | | +-------------------+--------------------------------------------------+ | > Policy OID | > QCP-w Qualified website certificate in | | | > accordance with EU Regulation 910/2014. | | | > | | | > itu-t(0) identified-organization(4) etsi(0) | | | > qualified-certificate-policies(194112) | | | > | | | > policy-identifiers(1) qncp-web (5) | | | > | | | > 0.4.0.194112.1.5 | +-------------------+--------------------------------------------------+ | | | +-------------------+--------------------------------------------------+ | > Policy OID | > 1.3.6.1.4.1.8149.3.15.6.0 | +-------------------+--------------------------------------------------+ | > Policy CPS | > Location | -CUALIFICADO-WEB_ACCV-ISTEC_CIF-A40573396_SPAIN> | +-------------------+--------------------------------------------------+ | > ***Authority | | | > Information | | | > Access*** | | +-------------------+--------------------------------------------------+ | *Access Method* | Id-ad-ocsp | +-------------------+--------------------------------------------------+ | *Access Location* | http://ocsp.accv.es | +-------------------+--------------------------------------------------+ | *Access Method* | Id-ad-caIssuers | +-------------------+--------------------------------------------------+ | *Access Location* | ACCVCA-120: | | | | | | | | | | | | ACCV RSA1 TLS: | | | http://www.accv.es/gestcert/accv_rsa1_tls.crt | | | | | | ACCV ECC1 TLS: | | | http://www.accv.es/gestcert/accv_ecc1_tls.crt | +-------------------+--------------------------------------------------+ | > ***Fingerprint | > Fingerprint of the certificate of the CA | | > issuer*** | > issuing the certificate (see CPS) | +-------------------+--------------------------------------------------+ | > ***Hashing | > RSA: SHA-256 | | > algorithm*** | > | | | > ECC: SHA-384 | +-------------------+--------------------------------------------------+ | > ***KeyUsage | | | > (critical)*** | | +-------------------+--------------------------------------------------+ | | > RSA: Digital Signature, Key Encipherment | | | > | | | > ECC: Digital Signature | +-------------------+--------------------------------------------------+ | | | +-------------------+--------------------------------------------------+ | > ***SCT List | > Signed Certificate Timestamp List | | > 1.3.6.1.4.4 | | | .1.11129.2.4.2*** | | +-------------------+--------------------------------------------------+ | | | +-------------------+--------------------------------------------------+ | **QcStatement** | **QC (Qualified Certificate) Fields** | +-------------------+--------------------------------------------------+ | QcCompliance | *The certificate is qualified* | +-------------------+--------------------------------------------------+ | QcType | web *Particular type of qualified certificate* | +-------------------+--------------------------------------------------+ | QcRetentionPeriod | 15y *Retention period of material information* | +-------------------+--------------------------------------------------+ | QcPDS | https://www.accv.es/fileadmin/Archivos | | | /Practicas_de_certificacion/ACCV-PDS-V1.1-EN.pdf | | | | | | *Location of PKI Disclosure Statement* | +-------------------+--------------------------------------------------+ | | | +-------------------+--------------------------------------------------+ | **CA/Browser | cabfOrganizationIdentifier (OID: 2.23.140.3.1) | | Forum | | | Organization | {joint-iso-itu-t(2) | | Identifier | international-organizations(23) | | Field** | ca-browser-forum(140) certificate-extensions(3) | | | cabf-organization-identifier(1) } | +-------------------+--------------------------------------------------+ | | registrationSchemeIdentifier *3 character | | | Registration Scheme identifier (VAT)* | +-------------------+--------------------------------------------------+ | | registrationCountry *2 character ISO 3166 | | | country code (ES)* | +-------------------+--------------------------------------------------+ | | registrationStateOrProvince *State or Province | | | (optional)* | +-------------------+--------------------------------------------------+ | | registrationReference Registration *Reference | | | allocated in accordance with the identified | | | Registration Scheme (CIF)* | +-------------------+--------------------------------------------------+ ##### Server Authentication Certificates +-------------------+--------------------------------------------------+ | > **Field** | > **Value** | +-------------------+--------------------------------------------------+ | > ***Subject*** | | +-------------------+--------------------------------------------------+ | > SerialNumber | NIF of the Administration, organization or | | | entity of public or private law subscriber of | | | the certificate, to which the website is linked. | +-------------------+--------------------------------------------------+ | > CommonName | Domain Name (DNS) where the certificate will | | | reside. If it appears it must match a DNSName of | | | the SAN. (OPTIONAL not recommended) | +-------------------+--------------------------------------------------+ | > Organ | Tax ID number of the entity, as it appears in | | izationIdentifier | the official records. Encoded According to | | > | European Standard ETSI EN 319 412-1 | | > (2.5.4.97) | | +-------------------+--------------------------------------------------+ | > Organization | > Denomination (\"official\" name) of the | | | > Administration, organization or public law | | | > entity subscribing the certificate and owner | | | > of the domain. | +-------------------+--------------------------------------------------+ | > Locality | > City | +-------------------+--------------------------------------------------+ | > State | > Province | +-------------------+--------------------------------------------------+ | > Country | > ES (code ISO 3166-1) | +-------------------+--------------------------------------------------+ | > ***Version*** | > V3 | +-------------------+--------------------------------------------------+ | > * | > Unique identifier of the certificate. Less | | **SerialNumber*** | > than 32 hexadecimal characters. | +-------------------+--------------------------------------------------+ | > ***Signature | > ACCVCA-120 sha256withRSAEncryption | | > algorithm*** | > | | | > ACCV RSA1 TLS sha256withRSAEncryption | | | > | | | > ACCV ECC1 TLS ecdsa-with-SHA384 | +-------------------+--------------------------------------------------+ | > ***Issuer*** | > DN of the CA issuing the certificate (see | | | > 7.1.4) | +-------------------+--------------------------------------------------+ | > ***Valid | > Issuance Date | | > from*** | | +-------------------+--------------------------------------------------+ | > ***Valid | > Expiration Date | | > until*** | | +-------------------+--------------------------------------------------+ | > ***Public | > Octet String containing the certificate public | | > Key*** | > key | +-------------------+--------------------------------------------------+ | > ***Extended Key | | | > Usage*** | | +-------------------+--------------------------------------------------+ | | > Server Authentication | | | > | | | > Client Authentication (optional) | +-------------------+--------------------------------------------------+ | > ***CRL | > ACCVCA-120: | | > Distribution | > Point*** | leadmin/Archivos/certificados/accvca120_der.crl> | | | > | | | > ACCV RSA1 TLS: | | | > | | | | | | > | | | > ACCV ECC1 TLS: | | | > | | | | +-------------------+--------------------------------------------------+ | | | +-------------------+--------------------------------------------------+ | > ***SubjectA | | | lternativeName*** | | +-------------------+--------------------------------------------------+ | | > dnsName: DNS Domain Name (if commonName is | | | > included it must have the same value) | +-------------------+--------------------------------------------------+ | > Optional | > dnsName: DNS Domain Name 2 | +-------------------+--------------------------------------------------+ | > Optional | > dnsName: DNS Domain Name 3 | +-------------------+--------------------------------------------------+ | > Optional | > dnsName: DNS Domain Name 4 | +-------------------+--------------------------------------------------+ | > Optional | > dnsName: DNS Domain Name 5 | +-------------------+--------------------------------------------------+ | > ***Certificate | | | > Policy | | | > Extensions*** | | +-------------------+--------------------------------------------------+ | | | +-------------------+--------------------------------------------------+ | > Policy OID | > {joint-iso-itu-t(2) | | | > international-organizations(23) | | | > ca-browser-forum(140) certificate-policies(1) | | | > baseline-requirements(2) | | | > organization-validated(2)} | | | > | | | > 2.23.140.1.2.2 | +-------------------+--------------------------------------------------+ | | | +-------------------+--------------------------------------------------+ | > Policy OID | > 1.3.6.1.4.1.8149.3.36.2.0 | +-------------------+--------------------------------------------------+ | > Policy CPS | > Location | -CUALIFICADO-WEB_ACCV-ISTEC_CIF-A40573396_SPAIN> | +-------------------+--------------------------------------------------+ | > ***Authority | | | > Information | | | > Access*** | | +-------------------+--------------------------------------------------+ | *Access Method* | Id-ad-ocsp | +-------------------+--------------------------------------------------+ | *Access Location* | http://ocsp.accv.es | +-------------------+--------------------------------------------------+ | *Access Method* | Id-ad-caIssuers | +-------------------+--------------------------------------------------+ | *Access Location* | ACCVCA-120: | | | | | | | | | ACCV RSA1 TLS: | | | | | | | | | > ACCV ECC1 TLS: | | | > | | | | +-------------------+--------------------------------------------------+ | > ***Fingerprint | > Fingerprint of the certificate of the CA | | > issuer*** | > issuing the certificate (see CPS) | +-------------------+--------------------------------------------------+ | > ***Hashing | > RSA: SHA-256 | | > algorithm*** | > | | | > ECC: SHA-384 | +-------------------+--------------------------------------------------+ | > ***KeyUsage | | | > (critical)*** | | +-------------------+--------------------------------------------------+ | | > RSA: Digital Signature, Key Encipherment | | | > | | | > ECC: Digital Signature | +-------------------+--------------------------------------------------+ | | | +-------------------+--------------------------------------------------+ | **SCT | Signed Certificate Timestamp List | | List1.3.6.1. | | | 4.1.11129.2.4.2** | *SCT Responses from Qualified Logs. At least | | | three different responses.* | +-------------------+--------------------------------------------------+ | | | +-------------------+--------------------------------------------------+ | **CA/Browser | cabfOrganizationIdentifier (OID: 2.23.140.3.1) | | Forum | | | Organization | {joint-iso-itu-t(2) | | Identifier | international-organizations(23) | | Field** | ca-browser-forum(140) certificate-extensions(3) | | | cabf-organization-identifier(1) } | +-------------------+--------------------------------------------------+ | | registrationSchemeIdentifier *3 character | | | Registration scheme identifier (VAT)* | +-------------------+--------------------------------------------------+ | | registrationCountry *2 character ISO 3166 | | | country code (ES)* | +-------------------+--------------------------------------------------+ | | registrationStateOrProvince *Province | | | (optional)* | +-------------------+--------------------------------------------------+ | | registrationReference *Registration reference | | | assigned according to the identified | | | registration scheme (CIF)* | +-------------------+--------------------------------------------------+ In all cases, the specifications and limits established in RFC-5280 shall be complied with. In the case of pre-certificates (only applicable to certificates published in the Certificate Transparency logs) the profile is structurally identical to the final certificate, with the exception of a special extension marked as critical with the OID 1.3.6.1.4.1.11129.2.4.3 This extension ensures that the Precertificate will not be accepted as a Certificate by clients conforming to RFC 5280. The existence of a signed Precertificate can be treated as evidence of a corresponding Certificate also existing, as the signature represents a binding commitment by the CA that it may issue such a Certificate. ### Object Identifiers (OID) of the algorithms Object Identifier (OID) of Cryptographic algorithms: - sha1withRSAEncryption (1.2.840.113549.1.1.5) - sha256withRSAEncryption (1.2.840.113549.1.1.11) - sha384WithRSAEncryption(1.2.840.113549.1.1.12) - sha512withRSAEncryption (1.2.840.113549.1.1.13) - rsaEncryption (1.2.840.113549.1.1.1) - ECC P-256 secp256r1 (OID: 1.2.840.10045.3.1.7). - ECC P-384 secp384r1 (OID: 1.3.132.0.34). - ECC P-521 secp521r1 (OID: 1.3.132.0.35). - ecdsa-with-SHA256 (1.2.840.10045.4.3.2) - ecdsa-with-SHA384 (1.2.840.10045.4.3.3) As of January 16, 2015, ACCV does not issue subscriber certificates using the SHA-1 algorithm with an expiration date greater than January 1, 2017. #### SubjectPublicKeyInfo The following requirements apply to the subjectPublicKeyInfo field of a certificate or Pre-Certificate.\ Pre-certificate. Other encodings are not allowed. ##### RSA ACCV indicates an RSA key using the rsaEncryption algorithm identifier (OID: 1.2.840.113549.1.1.1.1). The parameters are present, and are an explicit NULL.\ \ The AlgorithmIdentifier for RSA keys is identical byte by by byte with the following hexadecimal encoded bytes: **300d06092a864886f70d0101010500** ##### ECDSA ACCV indicates the ECDSA key using the algorithm identifier id-ecPublicKey (OID: 1.2.840.10045.2.1). The namedCurve encoding is used for the parameters.\ \ For P-256 keys, the namedCurve MUST be secp256r1 (OID: 1.2.840.10045.3.1.7).\ For P-384 keys, the namedCurve MUST be secp384r1 (OID: 1.3.132.0.34).\ For P-521 keys, the namedCurve MUST be secp521r1 (OID: 1.3.132.0.35).\ \ When encrypted, the AlgorithmIdentifier for ECDSA keys is identical byte-for-byte with the following bytes hexadecimally encoded:\ \ For P-256 keys, **301306072a8648ce3d020106082a8648ce3d030107**.\ For P-384 keys, **301006072a8648ce3d02010606052b81040022**.\ For P-521 keys, **301006072a8648ce3d02010606052b81040023**. #### Signature algorithm identifier All objects signed by ACCV meet these requirements on the use of the AlgorithmIdentifier or AlgorithmIdentifier-derived type in the context of signatures.\ \ In particular, it applies to all of the following objects and fields: - The signatureAlgorithm field of a certificate or pre-certificate. - The signatureAlgorithm field of a TBSCertificate (e.g., the one used by a certificate or pre-certificate). - The signatureAlgorithm field of a CertificateList. - The signature field of a TBSCertList - The signatureAlgorithm field of a BasicOCSPResponse. No other coding is allowed for these fields. ##### RSA ACCV uses one of the following algorithms and signature encodings. When encoded, the AlgorithmIdentifier MUST be identical byte-for-byte with the specified hexadecimal encoded bytes.\ \ RSASSA-PKCS1-v1_5 with SHA-256:\ \ Codificación: **300d06092a864886f70d01010b0500**.\ \ RSASSA-PKCS1-v1_5 with SHA-384:\ \ Codificación: **300d06092a864886f70d01010c0500**.\ \ RSASSA-PKCS1-v1_5 with SHA-512:\ \ Codificación: **300d06092a864886f70d01010d0500**.\ \ RSASSA-PSS with SHA-256, MGF-1 with SHA-256 and a salt length of 32 bytes:\ \ Encoding:\ \ **304106092a864886f70d01010a3034a00f300d0609608648016503040201\ 0500a11c301a06092a864886f70d010108300d0609608648016503040201\ 0500a203020120**\ \ RSASSA-PSS with SHA-384, MGF-1 with SHA-384 and a salt length of 48 bytes:\ \ Encoding:\ \ **304106092a864886f70d01010a3034a00f300d0609608648016503040202\ 0500a11c301a06092a864886f70d010108300d0609608648016503040202\ 0500a203020130**\ \ RSASSA-PSS with SHA-512, MGF-1 with SHA-512 and a salt length of 64 bytes:\ \ Encoding:\ \ **304106092a864886f70d01010a3034a00f300d0609608648016503040203\ 0500a11c301a06092a864886f70d010108300d0609608648016503040203\ 0500a203020140** ##### ECDSA ACCV uses the appropriate signature algorithm and encryption depending on the signing key used.\ \ If the signing key is P-256, the signature MUST use ECDSA with SHA-256. When encrypted, the AlgorithmIdentifier MUST be identical byte-for-byte with the following hexadecimal encoded bytes: **300a06082a8648ce3d040302**.\ \ If the signing key is P-384, the signature MUST use ECDSA with SHA-384. When encrypted, the AlgorithmIdentifier MUST be identical byte-for-byte with the following bytes hexadecimally encoded: **300a06082a8648ce3d040303**.\ \ If the signing key is P-521, the signature MUST use ECDSA with SHA-512. When encrypted, the AlgorithmIdentifier MUST be identical byte-for-byte with the following hexadecimal encoded bytes: **300a06082a8648ce3d040304**. ### Name Forms The subject and sender names for all possible certification chains are identical byte by byte. Certificates issued by ACCV contain the distinguished name X.500 of the issuer and the subscriber of the certificate in the issuer name and subject name fields respectively. In the case of ACCVRAIZ1 RootCA or SubCAs Issuer\'s name: cn=ACCVRAIZ1, ou=PKIACCV o=ACCV, c=ES - Subject: - commonName (required). Must match the name of ACCV entity. - OrganizationalUnit (required) fixed string \"PKIACCV\". - Organization (required) fixed string \"ACCV\". - Country (required) Country code ISO 3166-1 In the case of ACCV ROOT RSA TLS 2024 RootCA and its SubCAs Issuer Name: CN=ACCV ROOT RSA TLS 2024, organizationIdentifier=VATES-A40573396, O=ISTEC, L=BURJASSOT, ST=VALENCIA, C=EN - Subject: - commonName (required). Must match the name of ACCV entity. - organizationIdentifier (required) fixed string **VATES-A40573396** - Organization (mandatory) **ISTEC** fixed chain - Locality (required): fixed chain **BURJASSOT** - State (required): fixed chain **VALENCIA** - Country (required) country code ISO 3166-1 **EN** For ACCV ROOT ECC TLS 2024 RootCA and its SubCAs Issuer Name: CN=ACCV ROOT ECC TLS 2024, organizationIdentifier=VATES-A40573396, O=ISTEC, L=BURJASSOT, ST=VALENCIA, C=ES - Subject: - commonName (required). Must match the name of ACCV entity. - organizationIdentifier (required) fixed string **VATES-A40573396** - Organization (mandatory) **ISTEC** fixed chain - Locality (required): fixed chain **BURJASSOT** - State (required): fixed chain **VALENCIA** - Country (required) country code ISO 3166-1 **EN** The Issuer names supported for end-entity certificates issued under this CPD are: cn=ACCVCA-120,ou=PKIACCV,o=ACCV, c=ES cn=ACCV RSA1 TLS,2.5.4.97=VATES-A40573396,o=ISTEC,l=BURJASSOT,s=VALENCIA,c=ES cn=ACCV ECC1 TLS,2.5.4.97=VATES-A40573396,o=ISTEC,l=BURJASSOT,s=VALENCIA,c=ES All the fields of the final entity certificate of the Subject and Subject Alternative Name, except those referring to DNS name or mailing addresses, must be completed in capital letters, without accents. The subjectAlternativeName (SAN) field contains at least one entry. Each entry in the SAN field must be of type dNSName containing the full qualified name of a system. Subject: commonName (optional). If included, it must match one of the DNSName fields in the SAN. serialNumber (required). NIF of the entity, defined in [Royal Decree 1065/2007, of July 27](https://www.boe.es/buscar/act.php?id=BOE-A-2007-15984). OrganizationIdentifier (required) Entity identifier, following the format defined in the European standard ETSI EN 319 412-1. Organization (required) Designation (official name) of the Administration, agency or entity on behalf of which the certificate subscriber and domain owner is acting. locality (required) City state (required) State or province country (required) ISO 3166-1 country code #### Name Encoding Rules applied when coding a Name: - Each Name contains one RDNSequence. - Each RelativeDistinguishedName contains exactly one AttributeTypeAndValue. - Each RelativeDistinguishedName, if present, is encoded within RDNSequence in the order in which it appears in Section 7.1.2. of the Certification Policy. - Each Name contains no more than one instance of a given AttributeTypeAndValue in all RelativeDistinguishedNames. ### Name Constraints The names contained in the certificates are restricted to X.500 distinguished names (DN), distinguishable by subscriber and unambiguous. There are no name restrictions defined in the SubCA certificates. There are no restrictions defined by extension for certificates issued under this policy. ### Certification Policy Object Identifier (OID) ACCV has defined a policy for assigning OID\'s within its private numbering arc. The OID of all ACCV Certification Policies start with the prefix 1.3.6.1.1.4.1.8149.3. For the root CA and intermediate Cas the policy is *anyPolicy* (2.5.29.32.0). #### Qualified Website Authentication Certificates The object identifier defined by ACCV to identify this policy is as follows: **1.3.6.1.4.1.8149.3.3.5.0** In this case an OID is added to identify the type of entity being represented according to ETSI EN 319 411-2. **0.4.0.194112.1.5 Certification policy for EU-qualified certificates issued to websites** In this case an OID is added to identify the type of entity being represented following the CAB/Forum guidelines. **2.23.140.1.2.2 Certificates issued in accordance with the CA/Browser Forum\'s Baseline Requirements - Organization identity asserted** In this case an OID is added to identify the type of entity being represented according to ETSI EN 319 411-1. **0.4.0.2042.1.7 Organizational Validation Certificate Policy (OVCP)** #### Electronic Administrative Headquarters Certificates in Hardware Secure Module The object identifier defined by ACCV to identify this policy is as follows: **1.3.6.1.4.1.8149.3.14.6.0** In this case an OID is added to identify the type of entity that is represented according to the definition of the profiles by the General State Administration. **2.16.724.1.3.5.5.1 High level Electronic Administrative Headquarters Certificates** In this case an OID is added to identify the type of entity being represented according to ETSI EN 319 411-2. **0.4.0.194112.1.5 Certification policy for EU-qualified certificates issued to websites** In this case, an OID is added to identify the type of entity being represented according to the CAB/Forum guidelines. **2.23.140.1.2.2 Certificates issued in accordance with the CA/Browser Forum\'s Baseline Requirements - Organization identity asserted** In this case an OID is added to identify the type of entity being represented according to the ETSI EN 319 411-1 standard. **0.4.0.2042.1.7 Organizational Validation Certificate Policy (OVCP)** #### Electronic Administrative Headquarters Certificates based on software The object identifier defined by ACCV to identify this policy is as follows: **1.3.6.1.4.1.8149.3.15.6.0** In this case an OID is added to identify the type of entity that is represented according to the definition of the profiles by the General State Administration. **2.16.724.1.3.5.5.2 Medium/substantial Electronic Administrative Headquarters Certificates** In this case an OID is added to identify the type of entity being represented according to ETSI EN 319 411-2. **0.4.0.194112.1.5 Certification policy for EU-qualified certificates issued to websites** In this case, an OID is added to identify the type of entity being represented according to the CAB/Forum guidelines. **2.23.140.1.2.2 Certificates issued in accordance with the CA/Browser Forum\'s Baseline Requirements - Organization identity asserted** In this case an OID is added to identify the type of entity being represented according to the ETSI EN 319 411-1 standard. **0.4.0.2042.1.7 Organizational Validation Certificate Policy (OVCP)** #### Server Authentication Certificates The object identifier defined by ACCV to identify this policy is as follows: **1.3.6.1.4.1.8149.3.36.2.0** In this case an OID is added to identify the type of entity being represented following the CAB/Forum guidelines. **2.23.140.1.2.2 Certificates issued in accordance with the CA/Browser Forum\'s Baseline Requirements - Organization identity asserted** ### Usage of Policy Constraints Extension The \"Policy Constraints\" extension is not used in certificates issued under this Certification Policy. ### Policy Qualifiers Syntax and Semantics The \"Certificate Policy\" extension can include a Policy Qualifier (optional): \- CPS Pointer: contains the URL where the Certification Policies are published. ### Processing Semantics for the Critical Certificate Policies Extension The \"*Certificate Policy*\" extension identifies the policy that defines the practices that ACCV explicitly associates with the certificate. Additionally the extension may contain a policy qualifier. ### Signed Certificate Timestamp (SCT) List Responses from well-known qualified registries, currently compliant with Chrome\'s certificate transparency policy. OID extension: 1.3.6.1.4.1.11129.2.4.2 RFC 6962 (Certificate Transparency): For certificates with a notBefore value greater than or equal to April 21, 2021 (2021-04-21T00:00:00Z), the number of embedded SCTs is based on the lifetime of the certificate: +----------------------+-----------------------+-----------------------+ | **Certificate | **\# of SCTs from | **Maximum \# of SCTs | | lifetime** | separate logs** | per log operator | | | | which count towards | | | | the SCT requirement** | +----------------------+-----------------------+-----------------------+ | 180 days or less | 2 | 1 | +----------------------+-----------------------+-----------------------+ | 181 to 398 days | 3 | 2 | +----------------------+-----------------------+-----------------------+ For certificates with a notBefore value less than April 21, 2021 (2021-04-21T00:00:00Z), the number of embedded SCTs is based on the lifetime of the certificate: +--------------------------+-------------------------------------------+ | Lifetime of Certificate | Number of SCTs from distinct logs | +:========================:+:=========================================:+ | \< 15 months | 2 | +--------------------------+-------------------------------------------+ | \>= 15, \<= 27 months | 3 | +--------------------------+-------------------------------------------+ | \> 27, \<= 39 months | 4 | +--------------------------+-------------------------------------------+ | \> 39 months | 5 | +--------------------------+-------------------------------------------+ ## ## CRL Profile ### Version number The format of the CRLs used in this policy is as specified in version 2 (X509 v2). The serial number of revoked certificates remains in the CRL until they expire. ### CRL and extensions This Certification Practice Statement supports and uses CRLs that comply with the X.509 standard and support the following fields: Version: Set as v2 Signature Algorithm: Identifier of the algorithm used to sign the CRL. Hash Algorithm: Identifier of the algorithm used to hash the CRL. Issuer: The distinguished name of the issuing CA This update: Time of CRL issuance Next Update: Time of the next CRL update CRL Number: Sequential CRL number Issuer Key Identifier: Fingerprint of the CA issuer Revoked Certificates: List of revoked certificates. **reasonCode (OID 2.5.29.21)** > If present, this extension is not marked as critical. > > If a CRL entry is for a root CA or subordinate CA certificate, this > CRL entry extension is present. For subscriber certificates, their CRL > entry extension is omitted when the CRLReason specified is not > specified (0). > > ACCV will make every effort to have the CRLReason indicate the most > appropriate reason for revocation of the Certificate. > > Only the following CRLReason can be present in the CRL reasonCode > extension for subscriber certificates: - keyCompromise (RFC 5280 CLR Reason #1): Indicates that it is known or suspected that the subscriber\'s private key has been compromised. - affiliationChanged: (RFC 5280 CRL Reason #3): Indicates that the subject name or other subject identity information in the certificate has changed, but there is no reason to suspect that the certificate\'s private key has been compromised. - superseded (RFC 5280 CRL Reason #4): Indicates that the Certificate is being replaced because: the Subscriber has requested a new Certificate. - cessationOfOperation: (RFC 5280 CRL Reason #5): Indicates that the website with the Certificate is closed before the expiration of the Certificate, or if the Subscriber no longer owns or controls the Domain Name in the Certificate before the expiration of the Certificate. - privilegeWithdrawn: (RFC 5280 CRL Reason #9): indicates that there has been a breach by the Subscriber that has not resulted in a Key Commitment, such as that the Certificate Subscriber provided misleading information in its Certificate Application or has failed to comply with its material obligations under the Subscriber Agreement. o Terms of Use. > ACCV will inform Subscribers of the revocation reason options listed > above and provides an explanation of when to choose each option. The > tools ACCV makes available to the Subscriber allow these options to be > easily specified when the Subscriber requests revocation of their > Certificate, with the default being that the reason for revocation is > not indicated. > > privilegeWithdrawn reason code is not available to the subscriber as a > revocation reason option, because the use of this reason code is > determined by the CA and not the subscriber. ## OCSP Profile ACCV also publishes certificate status information via the Online Certificate Status Protocol (OCSP). This OCSP service operates according to the standard defined in RFC 6960 and RFC 5019. Specifically, it is guaranteed that if the OCSP responder receives a status request for a certificate that has not been issued, it will not respond with a \"good\" status. The response must be \"revoked\", with specification of the revocation reason certificateHold (6), and must specify the revocationTime January 1, 1970. If the OCSP response is based on an OCSP input the code of the response revocation reason will be the same as the one obtained from the CRL. ACCV provides its OCSP service at http://ocsp.accv.es, on a 24x7 basis. ### Version number The OCSP service operates according to the standard defined in RFC-6960 and RFC-5019. The certificates used in the service conform to the X509 version 3 standard. ### OCSP extensions The OCSP service provided by ACCV supports at least the following extensions: > \- NONCE (optional) > > \- Archive Cutoff > > \- Extended Revoked Definition The individual ACCV OCSP Response Extensions do not contain the ReasonCode extension (OID 2.5.29.21) of the CRL entries. # COMPLIANCE AUDIT AND OTHER ASSESSMENTS ACCV carries out the necessary checks to ensure that \- Issues certificates and operates the services in accordance with all the legislation applicable to its activity \- Meets the established technical requirements \- Complies with the audit requirements set forth in this section. ## Frequency or Circumstances of Assessment A fully audit shall be carried out on ACCV at least once a year to guarantee the compliance of its running and operating procedures with the provisions included in this CPS. Certificates capable of issuing new certificates and all their operations fall within the scope of the audit, these operations are divided into an unbroken sequence of audit periods. An audit period must not exceed one year in duration. Other technical and security audits shall be carried out in accordance with the stipulations of ACCV's Audit Policy, which include an audit on compliance with personal data protection legislation If ACCV does not have a valid Audit Report indicating compliance with one of the audit schemes listed in Section 8.4, then, before issuing Publicly-Trusted Certificates, we will successfully complete a point-in-time readiness assessment performed in accordance with applicable standards under one of the audit schemes listed in Section 8.4. The point-in-time readiness assessment will be completed no earlier than twelve (12) months prior to issuing Publicly-Trusted Certificates and will be followed by a complete audit under such scheme within ninety (90) days of issuing the first Publicly-Trusted Certificate. ## Identity/Qualifications of Assessor The auditor will be selected at the time of each audit. The audit of the CA shall be performed by a Qualified Auditor. A Qualified Auditor means a natural person, Legal Entity, or group of natural persons or Legal Entities that collectively possess the following qualifications and skills: - Independence of the object of the audit; - The ability to conduct an audit that addresses the criteria specified in an Eligible Audit Scheme (see Section 8.4); - Employ individuals who are proficient in the examination of public key infrastructure technology, information security tools and techniques, information technology and security auditing, and the third party attestation function; - For audits performed in accordance with the WebTrust standard: licensed by WebTrust; - Required by law, government regulation or professional code of ethics; and - Except in the case of an Internal Government Auditing Agency, maintains Professional Liability/Errors & Omissions insurance with policy limits of at least one million US dollars in coverage ## Assessor\'s Relationship to Assessed Entity Apart from the audit function, the auditor and the audited party (ACCV) shall not have any current or planned financial, legal or any other type of relationship that could lead to a conflict of interest. In compliance with the provisions of the regulations in force in our legislation on the protection of personal data, and given that for the fulfillment, by the auditor, of the services regulated in the contract it will be necessary to access the personal data of the files owned by ACCV, the auditor will be considered a Data Processor, pursuant to the provisions of Article 4.8 of Regulation (EU) 2016/679 of 27 April 2016. ## Topics Covered by Assessment The audit shall determine the compliance of ACCV services with this CPS and the applicable CPs. It shall also determine the risks of non-fulfillment of compliance with the operating procedures defined by these documents. The aspects covered by an audit shall include, but shall not be limited to: \- Security policy \- Physical security \- Technological evaluation \- Administration of the CA's services \- Selection of personnel \- CPS and CPs in force \- Contracts \- Privacy policy ACCV carries out at least one annual audit under these schemes: - "WebTrust for CAs v2.1 or newer" and "WebTrust for CAs SSL Baseline with Network Security v2.3 or newer". - Regulation (EU) No. 910/2014 of the European Parliament and of the Council of July 23, 2014 (eIDAS) and Regulation (EU) 2024/1183 of the European Parliament and of the Council of 11 April 2024 In addition to the necessary audits established by the legislation in force and by the technical norms of application for the fulfillment of its functions. ACCV incorporate periodic monitoring and/or accountability procedures to ensure that its audits continue to be conducted in accordance with the requirements of the scheme. Audits will be conducted by a Qualified Auditor, as specified in 8.2. ## Actions Taken as a Result of Deficiency The identification of deficiencies in the audit will result in corrective actions being taken. ACCV, in collaboration with the Auditor, will be responsible for determining these corrective actions. In case of serious deficiencies, ISTEC may decide to temporarily suspend operations until the deficiencies are remedied, revoke the entity\'s certificate, change personnel, etc. ## Communication of Results The auditor shall notify the results of the audit to ACCV Security Manager, and the managers of the various areas in which non-conformance is detected. The Audit Report shall state explicitly that it covers the relevant systems and processes used in the issuance of all Certificates that assert one or more of the policy identifiers listed in Section 7.1.6.1. The Audit Report must contain at least the following clearly-labelled information: - name of the organization being audited; - name and address of the organization performing the audit; - the SHA-256 fingerprint of all Roots and Subordinate CA Certificates, including Cross Certificates, that were in-scope of the audit; - audit criteria, with version number(s), that were used to audit each of the certificates (and associated keys); - a list of the CA policy documents, with version numbers, referenced during the audit; - whether the audit assessed a period of time or a point in time; - the start date and end date of the Audit Period, for those that cover a period of time; - the point in time date, for those that are for a point in time; - the date the report was issued, which will necessarily be after the end date or point in time date. An authoritative English language version of the publicly available audit information must be provided by the Qualified Auditor and ACCV will keep public and accessible audit reports, ensuring that no more than three months will pass from the end of the previous audit period. The Audit Report must be available as a PDF, and shall be text searchable for all information required. Each SHA-256 fingerprint within the Audit Report must be uppercase letters and must not contain colons, spaces, or line feeds. ## Self-Audits ACCV constantly monitors compliance with procedures and policies, establishing periodic controls of relevant indicators and performing self-audits. In the case of non-personal website and electronic headquarters certificates, at least quarterly on a randomly selected sample of three percent of the Certificates issued during the period immediately following the previous self-audit sample. In this quarterly analysis, ACCV uses linting tools to verify the technical accuracy of the certificates issued regardless of the reviews carried out in the issuance process. # OTHER BUSINESS AND LEGAL MATTERS ## Fees ### Certificate Issuance or Renewal Fees The prices for the initial issuance and renewal of the certificates referred to in this CPS are included in the Price List of ACCV. This list is published on ACCV website www.accv.es ### Certificate Access Fees Access to the certificates issued, given their public nature, is free and free of charge and therefore there is no fee applied to them. ### Revocation or Status Information Access Fees Access to certificate status or revocation information is free of charge and therefore no fees will be charged. ### Fees for Other Services No fee shall be applied for the service of providing information on this CPS. ### Refund Policy No refunds will be made for amounts paid for this type of certificate. ## Financial Responsibility ### Insurance Coverage ACCV offers a guarantee of sufficient coverage of civil liability as a public body and responsible as such for damages, as established in article 9, paragraph 3, subsection b) of Law 6/2020, of November 11, which regulates certain aspects of electronic trust services, which covers the risk of liability for damages that may be caused by the use of certificates issued by this Certification Authority. ### Other assets There are no other assets to consider. ### Insurance or Warranty Coverage for end-entities There are no additional insurances or coverages beyond those covered by the liability insurance defined in section .9.2.1 ## Confidentiality of Business Information ### Scope of Confidential Information. It is expressly declared as confidential information, which may not be disclosed to third parties, except in those cases provided by law: - The private keys of the entities that make up ACCV. - All information related to the operations carried out by ACCV. - All information related to security parameters, control and audit procedures. - All personal information provided to ACCV during the registration process of certificate subscribers, except as specified by the applicable Certification Policy and the certification contract. - Business information provided by its suppliers and other persons with whom ACCV has a legal or contractual duty of confidentiality. - Business continuity and emergency plans. - Transaction records, including complete records and audit trails of transactions. - All information classified as \"CONFIDENTIAL\" or \"STRICTLY CONFIDENTIAL\". ### Information Not Within the Scope of Confidential Information ACCV shall consider the following information to be for public access: 1. Information contained in the Certification Practice Statement approved by ACCV. 2. Information contained in the different Certification Policies approved by ACCV. 3. Issued certificates as well as the information contained in these. 4. Certificate Revocation List (CRL) 5. Any information qualified as \"PUBLIC\". ACCV's CPS and CPs shall not include information qualified as confidential in point 9.3.1 of this document. Information that is not considered as confidential access is permitted, without prejudice to the right of ACCV to establish the relevant security controls for the purpose of protecting the authenticity and integrity of documents that store information for public access, and thereby preventing unauthorized persons from being able to add to, modify or delete contents. ### Responsibility to Protect Confidential Information ACCV is responsible for the protection of confidential information generated or communicated during all operations. In the case of end entities, certificate subscribers are responsible for protecting their own private key and all activation information required to access or use the private key. ACCV shall have the right to disclose confidential information to the extent required by law. In particular, records certifying the reliability of the information included in the certificate will be disclosed if required as evidence in legal proceedings. In such cases, the consent of the certificate subscriber is not required. Certificate revocation information is provided by the CRL on the web server that acts as ACCV repository. This information is also available on ACCV OCSP validation server at ocsp.accv.es:80. ## Privacy of Personal Information ACCV has a Privacy Policy, published on the website of the entity, through which it complies with the provisions established in the legislation on protection of personal data in force and which informs about the policy of protection of personal data of ACCV. ### Privacy Plan In compliance with the requirements stipulated in each of the Certification Policies and according with Article 5 of Regulation (EU) 910/2014 (eIDAS), any information of a personal nature provided to ACCV by the subscribers of its certificates shall be handled in accordance with the terms of "Regulation (EU) 2016/679 of the European Parliament and of the Council of 27 April 2016 on the protection of natural persons with regard to the processing of personal data" and "Organic Law 3/2018 of 5 December on the Protection of Personal Data and the Guarantee of Digital Rights". In this sense, ACCV appears before the Spanish Data Protection Agency as responsible for the mixed file \"*Electronic Signature Users*\" and its processing. This file was created and its attributes modified by means of the following regulations: - Order of March 8, 2002, of the Regional Ministry of Innovation and Competitiveness, by which computerized files with personal data are created ( vid. DOGV nº 4.221 of April 4, 2002 and correction of errors in the DOGV nº 4.304, of July 31, 2002). - Order of May 26, 2004, of the Regional Ministry of Infrastructures and Transport, by which personal data files are created, modified and cancelled (DOGV 4.772, of June 10, 2004). - Decree 149/2007, of September 7, 2007, of the Consell, which approves the Statute of Ente Prestador de Servicios de Certificación Electrónica de la Comunitat Valenciana (DOGV 5.596, of September 11, 2007). - Law 5/2013, of December 23, 2013, on Fiscal Measures, Administrative and Financial Management, and Organization of the Generalitat (DOCV 7.181 of December 27, 2013). - Decree 15/2014, of January 24, of the Consell, approving the Regulations of Organization and Operation of the Institut Valencià de Finances (IVF) (DOCV 7.202 of January 29, 2014). - Law 21/2017, of December 28, on Fiscal Measures, Administrative and Financial Management, and Organization of the Generalitat (DOCV 8.202 of December 30, 2017). - Law 27/2018, of December 27, on Fiscal Measures, Administrative and Financial Management, and Organization of the Generalitat (DOCV 8.453 of December 28, 2018). In this file are recorded mainly those identification data (name, surname, ID card or equivalent) and contact (postal address, email,) necessary for the provision of digital certification services that ACCV offers to individuals and legal entities. Data legally considered as BASIC LEVEL due to its characteristics. Additionally, in accordance with the obligations established by Regulation (EU) 2016/679 on the protection of individuals with regard to the processing of personal data and on the free movement of such data and repealing Directive 95/46/EC (General Data Protection Regulation), ACCV has a public Register of Activities describing the technical and organizational measures carried out by the entity itself with the intention of protecting the personal data transferred in the performance of its functions. ### Information Treated as Private In accordance with the stipulations of Article 4.1 of Regulation (EU) 2016/679 of the European Parliament and of the Council of 27 April 2016, any information relating to identified or identifiable individuals is considered to be personal data. Personal information that must not be included either on certificates or on the certificate status verification system is considered to be personal information of a private nature. In any case, the following data is considered to be private information: 1. Certificate requests, whether approved or refused, and any other personal information obtained for the issue and maintenance of certificates if the information is not included in the Certificate and if the information is not public information. 2. Private keys generated and/or stored by ACCV. 3. Any other information identified as "Private information" In addition, data received by the Certification Services Provider has the legal consideration of basic level data. Pursuant to Regulation (EU) 2016/679 of 27 April 2016, confidential information is protected from loss, destruction, damage, falsification and illegal or unauthorized processing (article 5.1.f) In no case ACCV includes data referred in article 9 of Regulation (EU) 2016/679 of 27 April 2016, in the digital certificates issued. ### Information not Deemed Private This information refers to the personal information included in the certificates and in the referred mechanism for checking the status of the certificates, in accordance with section 3.1 of this document. The information is not private by law (\"public data\"), but is only published in the repository with the consent of the subscriber. In any case, the following information is considered non-confidential: a\. Certificates issued or in the process of issuance. b\. The subscriber\'s attachment to a certificate issued by ACCV. c\. The name and surname of the subscriber of the certificate, as well as any other circumstances or personal data of the holder, in the event that they are significant according to the purpose of the certificate, in accordance with this document. d\. The e-mail address of the certificate subscriber. e\. The uses and economic limits outlined in the certificate. f\. The period of validity of the certificate, as well as the date of issuance of the certificate and the expiration date. g\. The serial number of the certificate. h\. The different statuses or situations of the certificate and the date of the beginning of each of them, specifically: pending generation and/or delivery, valid, revoked, suspended or expired and the reason that caused the change of status. i\. The certificate revocation lists (CRLs), as well as all other revocation status information. j\. The information contained in ACCV Repository. ### Responsibility to Protect Private Information ACCV guarantees compliance with its legal obligations as a certification service provider, in accordance with Regulation (EU) 910/2014 (eIDAS) and its amendment in Regulation (EU) 2024/1183, and by virtue of this, and in accordance with Article 24 of the aforementioned Regulation, it shall be liable for any damages caused in the development of its own activity, for failure to comply with the requirements contained in Article 8 of Law 6/2020, of November 11, regarding the protection of personal data. ### Notice and Consent to Use Private Information For the provision of the service, ACCV will have to obtain the consent of the holders of the data necessary to provide certification services. Consent will be understood to have been obtained with the signing of the certification contract and the collection of the certificates by the user. ACCV will only use private information after obtaining consent or as required by applicable laws or regulations. ### Disclosure Pursuant to Judicial or Administrative Process ACCV may only communicate information classified as confidential or containing personal data in those cases in which it is required to do so by the competent public authority and in the cases provided for by law. Specifically, ACCV is obliged to disclose the identity of the signatories when requested to do so by the judicial authorities in the exercise of the functions attributed to them, and in all other cases provided for in Article 52 of Organic Law 3/2018, of December 5, on the Protection of Personal Data and Guarantee of Digital Rights, in which this communication is required. ### Other Information Disclosure Circumstances ACCV includes, in the privacy policy provided at the beginning of section 9.4, prescriptions to allow the disclosure of key holder information directly to key holders or authorized third parties. ## Intellectual Property Rights All intellectual property rights, including those concerning certificates and CRLs issued by ACCV, OIDs and any other document not explicitly mentioned, whether electronic or otherwise, owned by ACCV, belong to ACCV. The CPS and Certification Policies are issued by ACCV, and are licensed under a Creative Commons Attribution-NoDerivatives 4.0 (CC BY-ND 4.0) license. Private keys and public keys are the property of the subscriber, regardless of the physical medium used to store them. The subscriber shall retain any rights it may have in the product trademark or trade name registered on the certificate. ## Representations and Warranties ### CA Representations and Warranties ACCV is obliged to: - Conduct its operations in accordance with this CPS. - Protect your private keys. - Issue certificates in accordance with the applicable Certification Policies. - Upon receipt of a valid certificate request, issue certificates compliant with the X.509 standard and the requirements of the request. - Issue certificates that are in accordance with the information known at the time of issuance, and free of data entry errors. - Ensure confidentiality in the signature creation data generation process and its delivery by a secure procedure to the signatory. - Use reliable systems and products that are protected against tampering and that guarantee the technical and cryptographic security of the certification processes they support. - Use reliable systems for storing qualified certificates that make it possible to verify their authenticity and prevent unauthorized persons from altering the data, restrict their accessibility in the cases or to the persons indicated by the signatory, and make it possible to detect any change that affects these security conditions. - Ensure that the date and time at which a certificate was issued, terminated or suspended can be accurately determined. - Employ personnel with the necessary qualifications, knowledge and experience to provide the certification services offered and the appropriate security and management procedures in the field of electronic signatures. - Revoke the certificates under the terms of the *Certificate Suspension and Revocation* section of this document and publish the revoked certificates in the CRL of ACCV repository (www.accv.es), with the frequency stipulated in the *Frequency of issuance of CRLs* section of this document. - Publish this CPS and applicable CPs on the website www.accv.es, ensuring access to current as well as previous versions. - Promptly notify, by e-mail, certificate subscribers in the event that the CA revokes the certificate and the reason for such revocation. - Collaborate with the audits conducted by ACCV to validate the renewal of their own keys. - Operate in accordance with applicable legislation. Specifically with: 1. Decree 220/2014, of December 12, of the Valencian Government, regulating the use of the advanced electronic signature in the Generalitat Valenciana. 2. Law 6/2020, of November 11, regulating certain aspects of electronic trust services. 3. Regulation (EU) number 910/2014 of the European Parliament and of the Council on electronic identification and trust services for electronic transactions in the internal market and its amendment in Regulation (EU) 2024/1183. 4. Law 39/2015, of October 1, on the Common Administrative Procedure of Public Administrations. 5. Decree 15/2014, of January 24, of the Consell, approving the Regulations on the Organization and Operation of the Institut Valencià de Finances (IVF). 6. Law 21/2017, of December 28, 2017 Generalitat Valenciana, approving the integration into the Generalitat Valenciana of the functions and competences in the field of certification and electronic signature developed by the Institut Valencià de Finances (IVF). 7. Law 27/2018 of December 27, 2018 of the Generalitat Valenciana, approving the creation of the new organization, ISTEC. 8. Order ETD/465/2021, of May 6, regulating remote video identification methods for issuing qualified electronic certificates. 9. Order ETD/743/2022, of July 26, amending Order ETD/465/2021, of May 6, regulating remote video identification methods for the issuance of qualified electronic certificates. 10. Royal Decree 203/2021, of March 30, which approves the Regulations for the performance and operation of the public sector by electronic means. - Protect, if any, the keys in your custody. - Ensure the availability of CRLs in accordance with the provisions of section 4.9.9 *Frequency of issuance of CRLs*, of this CPS. - In the event of ceasing its activity, it must notify the holders of the certificates issued by ACCV, as well as the competent Ministry (at the date of writing this document it is the Ministry of Industry, Tourism and Trade), at least two months prior to the effective cessation, communicating the destination to be given to the certificates. - Comply with the specifications contained in the regulations on Personal Data Protection. - Keep on record all information and documentation relating to a qualified certificate and certification practice statements in effect at any given time for fifteen years from the time of issuance, so that signatures made with the certificate can be verified. Root CAs shall be responsible for the performance and warranties of the Subordinate CAs, for the Subordinate CAs\' compliance with these Requirements and for all liabilities and indemnification obligations of the Subordinate CAs under these Requirements, as if the Root CAs were the Subordinate CAs issuing the Certificates. ### RA Representations and Warranties Persons operating in the RAs integrated in ACCV hierarchy - User Registration Point operators - are obliged to: - Conduct its operations in accordance with this CPS. - Perform its operations in accordance with the Certification Policy applicable to the type of certificate requested on each occasion. - Exhaustively verify the identity of the persons to whom the digital certificate processed by them is granted, for which they will require the presence of the applicant and the exhibition of the original and valid DNI, Spanish passport, or document admitted in law. In case of foreign users, they must show the document that identifies them and must be in possession of a Foreigner Identification Number (NIE) . - Not to store or copy the signature creation data of the person to whom they have provided their services. - Inform, prior to the issuance of a certificate, the person requesting its services, of the obligations it assumes, the way in which it must safeguard the signature creation data, the procedure to be followed to report the loss or misuse of the signature creation and verification data or devices, its price, the precise conditions for the use of the certificate, its limitations of use and the way in which it guarantees its possible financial liability, and the web page where it can consult any ACCV, CPS and CP information in force and previous, the applicable legislation, the applicable legislation, the possible financial liability, and the web page where it can consult any ACCV information, of its limitations of use and of the way in which it guarantees its possible patrimonial responsibility, and of the web page where you can consult any information of ACCV, the CPS and the current and previous CPs, the applicable legislation, the obtained certifications and the applicable procedures for the extrajudicial resolution of the conflicts that could arise by the exercise of the activity. - Validate and securely send to the CA to which the RA is subordinated a certification request duly completed with the information provided by the subscriber and digitally signed, and receive the certificates issued in accordance with that request. - Securely store both the documentation provided by the subscriber and that generated by the RA itself during the registration or revocation process, until the time of its submission to ACCV. - Formalize the Certification Agreement with the subscriber as established by the applicable Certification Policy. - Request the revocation of a certificate when it has knowledge or suspicion of the compromise of a private key. - Authenticate end-user requests for renewal or revocation of their certificates, generate digitally signed renewal or revocation requests and send them to their superior CA. - In the case of approval of a certification request notify the subscriber the issuance of their certificates and how to obtain it. - In the case of rejection of an application for certification, notify the applicant of such rejection and the reason for it. - Maintain under its strict control the digital certificate processing tools and notify ACCV of any malfunction or other eventuality that may deviate from the expected normal behavior. - Send a signed copy of the certification contract and revocation requests to ACCV. - Process revocation requests that it receives immediately, after having carried out a reliable identification. - Collaborate in all aspects of the operation, audit or control of the User Registration Point as requested by ACCV. - To the most general and broad obligation of confidentiality, during and after the provision of the service as Registration Authority, with respect to the information received by ACCV and with respect to the information and documentation in which the service has been provided. In the same sense, not to transmit such information to third parties, under any circumstances, without the express, written and prior authorization of ACCV, in which case the same obligation of confidentiality shall be transferred to such third parties. ### Subscriber Representations and Warranties It is the obligation of the subscribers of the certificates issued under this policy: - Limit and adapt the use of the certificate to lawful purposes and in accordance with the uses permitted by the relevant Certification Policy and this CPS. - Take the necessary care and means to ensure the safekeeping of your private key. - Immediately request the revocation of a certificate in case of knowledge or suspicion of compromise of the private key corresponding to the public key contained in the certificate. The ways in which this request can be made are specified in this document in section 4.9.3 *Revocation request procedures*. - Not to use a digital certificate that has lost its effectiveness, because it has been suspended, revoked or because the validity period of the certificate has expired. - Provide the Registration Authorities with information that they consider accurate and complete in relation to the data requested by them in order to carry out the registration process, as well as inform ACCV managers of any modification to this information. - Pay, if applicable, the fees accrued for the certification services requested. - Certificates with the use of serverAuthentication key are subject to the CA/Browser Forum definition at https://cabforum.org/working-groups/server/baseline-requirements/documents/. Among the conditions established is the obligation to revoke the certificates if it is detected that the issuance or operation does not comply with the defined regulations. This revocation must be done within a maximum period of five (5) calendar days and no postponement of any kind is possible; if it is not possible to comply with this condition, certificates issued under this regulation must never be used. ACCV requires, as part of the Subscriber Agreement or Terms of Use, that the Applicant accepts the commitments and warranties in this section for the benefit of the CA and the Certificate Beneficiaries. Prior to the issuance of a Certificate, ACCV shall obtain, for the express benefit of the CA and the Beneficiaries of the Certificate, either: - The Applicant\'s acceptance of the Subscriber Agreement with the CA, and - The Applicant\'s acknowledgement of the Terms of Use. ACCV shall implement a process to ensure that each Subscriber Agreement or Terms of Use is legally enforceable against the Applicant. In any case, the Agreement must apply to the Certificate to be issued pursuant to the certificate application. ACCV may use an electronic or \"click-through\" Agreement provided that the CA has determined that such agreements are legally enforceable. A separate Agreement shall be used for each certificate application. ### Relying Party Representations and Warranties It is the obligation of the parties to rely on the certificates issued by ACCV: - Limit the reliability of certificates to the permitted uses of the same, in accordance with what is expressed in the certificate extensions and the relevant Certification Policy. - Verify the validity of the certificates at the time of performing or verifying any operation based on them. - Assume responsibility for the correct verification of digital signatures. - To assume its responsibility in verifying the validity, revocation or suspension of the certificates it trusts. - Be fully aware of the warranties and liabilities applicable to the acceptance and use of the certificates relied upon, and agree to be bound by them. - In the case of qualified certificates, verify that the service identifier is included in the most recent version of the ***Trusted Service List*** published by the responsible body of the European Commission. ### Representations and Warranties of other Participants No warranties or representations to other participants are considered. ## Disclaimer of Warranties ACCV may refuse all service guarantees that are not linked to the obligations stipulated by Law 6/2020 of November 11, regulating certain aspects of electronic trust services, and Regulation (EU) No 910/2014 of the European Parliament and of the Council of 23 July 2014 on electronic identification and trust services for electronic transactions in the internal market, especially guarantees of fitness for a particular purpose or guarantees of the use of certificates for commercial purposes. ## Limitations of Liability ACCV shall be liable for any damages it causes to any person in the exercise of its activity, when it fails to comply with the obligations imposed by Law 6/2020, of November 11, regulating certain aspects of electronic trust services, Decree 220/2014, of December 12, of the Valencian Government, and Regulation (EU) number 910/2014 of the European Parliament and of the Council, concerning electronic identification and trust services for electronic transactions in the internal market, or acts negligently. ACCV shall be liable for any damages caused to the Signatory or bona fide third parties due to the lack or delay in the inclusion in the certificate validity query service of the expiration or suspension of the validity of the certificate issued by ACCV, once it becomes aware of it. ACCV assumes all liability to third parties for the performance of persons performing the functions necessary for the provision of the certification service. ACCV is the Agencia de Tecnología y Certificación Electrónica, which is a Subdirectorate of lnfraestructures I Serveis De Telecomunicacions I Certificacio SA, Public Law Entity. The liability of the Administration is based on objective grounds and covers any injury suffered by individuals as long as it is a consequence of the normal or abnormal operation of public services. ACCV will only be liable for damages caused by the improper use of the website authentication certificate, when it has not consigned in it, in a manner clearly recognizable by third parties, the limit as to its possible use or the amount of the value of valid transactions that can be made using it, ACCV shall not be liable when the signatory exceeds the limits contained in the certificate as to its possible uses and the individualized amount of the transactions that can be carried out with it or does not use it in accordance with the conditions established and communicated to the signatory by ACCV. ACCV shall not be liable either if the recipient of the electronically signed documents does not check and take into account the restrictions contained in the certificate as to its possible uses and the individualized amount of the transactions that can be carried out with it. ACCV Registration Entities do not assume any liability in case of loss or damage: - Of the services they provide, in case of war, natural disasters or any other case of force majeure. - Caused by the use of certificates that exceeds the limits established by them, the relevant Certification Policy and this CPS. - Caused by the improper or fraudulent use of certificates or CRLs issued by ACCV. - Caused to the signatory or bona fide third parties if the recipient of the electronically signed documents does not verify and take into account the restrictions in the certificate as to its possible uses, or when not taking into account the suspension or loss of validity of the certificate published in the CRL, or when not verifying the electronic signature. Except as set forth in the provisions of this CPS, ACCV makes no other commitments or warranties and assumes no other liability to subscribers or relying parties. ## Indemnities ACCV is a governmental entity, so it is not applicable. There are no additional insurances or coverages beyond those covered by the liability insurance defined in section .9.2.1 ## Term and Termination ### Term. ACCV establishes, in its legal instruments with subscribers and verifiers, a clause that determines the period of validity of the legal relationship by virtue of which they provide certificates to subscribers. The CPS, the PDS and the various CPs become effective upon publication. ### Termination. ACCV establishes, in its legal instruments with subscribers and verifiers, a clause that determines the consequences of the termination of the legal relationship by virtue of which they supply certificates to subscribers. This CPS, the PDS and the various CPS will be repealed when a new version of the document is published. The new version will replace the previous document in its entirety. ### Effect of Termination and Survival. ACCV establishes, in its legal instruments with subscribers and verifiers, survival clauses, by virtue of which certain rules remain in force after the termination of the legal relationship regulating the service between the parties. For current certificates issued under a previous Certification Policy and Practices Statement, the new version shall prevail over the previous one in all that does not oppose it. ## Individual Notices and Communications with Participants Any notice, demand, request or any other communication required under the practices described in this CPS shall be made by means of a document or electronic message in accordance with this CPS or in writing by certified mail addressed to any of the addresses contained in point *1.5* of this document. Electronic communications shall become effective upon receipt by the addressee to whom they are addressed. ## Amendments ACCV may unilaterally modify this document, subject to the following procedure: - The modification must be justified from a technical and legal point of view. - The modification proposed by ACCV cannot violate the provisions contained in the certification policies established by ACCV. - A change control is established, based on ACCV\'s Change Management Policy. - The implications that the change of specifications has on the user are established, and the need to notify the user of such modifications is foreseen. ### Procedure for Amendment The entity with the authority to make and approve changes to the CPS and CPs is ISTEC (specifically Deputy Directorate for Digital Identity/ACCV), whose contact details can be found in section 1.5.1. of this CPS. In those cases in which it is considered that the modification of the CPS does not materially reduce the confidence that a Certification Policy or its implementation provides, nor alters the acceptability of the certificates supported by the policy for the purposes for which they have been used, the minor version number of the document and the last Object Identifier (OID) number that represents it will be increased, maintaining the major version number of the document, as well as the rest of its associated OID. It is not considered necessary to communicate this type of modification to the subscribers of the certificates corresponding to the modified CP or CPS. In the event that the changes to the current specification affect the acceptability of certificates for specific purposes, the highest version number of the document will be increased and the lowest version number will be reset to zero. The last two numbers of the Object Identifier (OID) that represents it will also be modified. ### Notification Mechanism and Period Any modification to this Certification Practices Statement or the Certification Policy Documents will be published on ACCV website [www.accv.es](http://www.accv.es/) serving as notification to subscribers, users or third parties. ### Circumstances Under Which OID Must be Changed ISTEC is the competent entity to approve this Certification Practices Statement, as well as the Certification Policies associated with each type of certificate. Likewise, it is the responsibility of ISTEC to approve and authorize the modifications of such documents. ## Dispute Resolution Provisions ACCV may establish, through the legal instruments through which its relationship with subscribers and verifiers is articulated, the mediation, arbitration and conflict resolution procedures deemed appropriate, all without prejudice to administrative procedure legislation. Disputes arising from the provision of certification services by ACCV shall be submitted to the contentious-administrative jurisdiction, in accordance with the provisions of Law 29/1998, of July 13, 1998, Regulating Contentious-Administrative Jurisdiction. ## Governing Law The functioning and operations of ACCV, as well as this CPS, are governed by the Community, State and Valencian legislation in force at any given time. The following standards are explicitly assumed to apply: 1. Decree 220/2014 of December 12, 2014, of the Valencian Government, regulating the use of advanced electronic signatures in the Generalitat Valenciana. 2. Law 6/2020, of November 11, regulating certain aspects of electronic trust services. 3. Law 39/2015, of October 1, 2015, on the Common Administrative Procedure of Public Administrations. 4. Law 40/2015, of October 1, 2015, on the Legal Regime of the Public Sector. 5. Law 5/2013, of December 23, 2013, on Fiscal Measures, Administrative and Financial Management, and Organization of the Generalitat. 6. Law 21/2017, of December 28, 2017 Generalitat Valenciana, approving the integration into the Generalitat Valenciana of the functions and competences in the field of certification and electronic signature developed by the Institut Valencià de Finances (IVF). 7. Law 27/2018 of December 27, 2018 of the Generalitat Valenciana, approving the creation of the new body, ISTEC. 8. Regulation (EU) No 910/2014 of the European Parliament and of the Council of 23 July 2014 on electronic identification and trust services for electronic transactions in the internal market and repealing Directive 1999/93/EC. 9. Regulation (EU) 2024/1183 of the European Parliament and of the Council of 11 April 2024 amending Regulation (EU) No 910/2014 as regards the establishment of the European digital identity framework. 10. Order ETD/465/2021, of May 6, regulating remote video identification methods for issuing qualified electronic certificates. 11. Order ETD/743/2022, of July 26, amending Order ETD/465/2021, of May 6, regulating remote video identification methods for the issuance of qualified electronic certificates. 12. Royal Decree 203/2021, of March 30, which approves the Regulations for the performance and operation of the public sector by electronic means. ## Compliance with Applicable Law ACCV declares that this CPS complies with the legislation indicated in section 9.14 ## Miscellaneous Provisions ### Entire Agreement This CPS and all documents referred to herein constitute the entire agreement between the parties, superseding all other agreements that may exist with respect to the same subject matter. All third parties relying on the certificates fully assume the contents of the latest version of this document, the PDS and the corresponding Policies. ### Assignment This CPS shall be binding on the successors, executors, heirs, representatives, administrators and assigns, express, tacit or apparent, of the parties. The invalidity of one of the clauses contained in this CPS shall not affect the rest of the clauses. In such a case, said clause shall be deemed inapplicable. ### Severability In case of conflict of any part of this document with the current legislation of any jurisdiction in which a Certification Authority operates or issues certificates, after the corresponding legal review, ACCV may modify the conflicting points to the minimum extent necessary to comply with such legislation. In such a case, (prior to issuing a certificate under the modified requirements) ACCV shall include in the subsections of this Section information on the Act requiring the modification and the specific change implemented by ACCV. ACCV will also inform interested parties, such as the CAB Forum, of the newly added relevant information prior to issuing a certificate under the changes made. ### Enforcement (Attorneys\' Fees and Waiver of Rights) ACCV may claim indemnification and attorneys\' fees from a party for damages, losses and expenses related to such party\'s conduct. ACCV\'s failure to enforce a provision of this TOU does not waive ACCV\'s right to enforce the same provision later or the right to enforce any other provision of this TOU. To be effective, waivers must be in writing and signed by ACCV. ### Force Majeure ACCV will not accept any liability for failure or delay in the performance of any of the obligations contained in the CPS, if such failure or delay is the result of a force majeure event, unforeseeable circumstances or any circumstances over which no direct control can be exercised. The operation of the Internet is beyond ACCV\'s reasonable control. ## Other Provisions In case of loss of QSCD certification of any of the qualified devices used by ACCV for end-entity certificates, ACCV will take the necessary measures to minimize the possible impact, informing the supervisory body and stopping the issuance of certificates on the affected devices. # Annex I ## Qualified Website Authentication Certificates +:---------------------------------------------------------------------:+ | CERTIFICATION CONTRACT - CODE 1.3.6.1.1.4.1.1.8149.3.3 | +-----------------------------------------------------------------------+ | ***Section 1 - Applicant Data*** | | | | *Last name*: | | | | *Name*: | | | | Tax ID: Tel: | | | | Position or position: | | | | Administration-Organization: | | | | CIF of the Organization: | | | | *E-mail address*: | | | | Mailing address: | +-----------------------------------------------------------------------+ | ***Section 2 - Domain data*** | | | | Qualified name: | | | | Aliases: | | | | Contact e-mail address: | +-----------------------------------------------------------------------+ | **Section 3 - *Date and Signature*** | | | | *I sign this certification contract associated with the Certification | | Policy for Qualified Certificates for Website Authentication with | | code 1.3.6.1.1.4.1.8149.3.3, issued by Agencia de Tecnología y | | Certificación Electrónica. I declare to know and accept the rules of | | use of this type of certificates that are exposed in | | http://www.accv.es. I also declare that the information provided is | | true.* | | | | *Applicant\'s signature* | | | | *Firmat/Signed*: | +-----------------------------------------------------------------------+ +:---------------------------------------------------------------------:+ | CERTIFICATION CONTRACT - CODE 1.3.6.1.4.1.8149.3.3 | | | | Conditions of use of certificates | +-----------------------------------------------------------------------+ | 1. The certificates associated with the Certification Policy of | | certificates for servers with SSL support, issued by the Agency | | of Technology and Electronic Certification are of type X.509v3 | | and are governed by the Certification Practices Statement of the | | Agency of Technology and Electronic Certification, as a | | Certification Service Provider, as well as by the Certification | | Policy referred to. Both documents must be interpreted according | | to the legislation of the European Community, the Spanish legal | | system and the legislation of the Generalitat Valenciana. | | | | 2. The applicant for the certificates must be a natural person, in | | possession of a qualified ACCV certificate or DNIe. The applicant | | must provide the data relating to their relationship with the | | Agency or Company on behalf of which they are requesting the | | certificate using the tools made available by ACCV. | | | | 3. The applicant of the certificates, specially authorized for the | | management of these by a given Organization or Company, is | | responsible for the veracity of the data provided at all times | | throughout the application and registration process. It will be | | responsible for communicating any variation of the data provided | | to obtain the certificate. | | | | 4. The certificate subscriber is responsible for the custody of his | | private key and for communicating as soon as possible any loss or | | theft of this key. | | | | 5. The certificate subscriber is responsible for limiting the use of | | the certificate to the provisions of the associated Certification | | Policy, which is a public document and is available at | | http://www.accv.es. | | | | 6. The Agency of Technology and Electronic Certification is not | | responsible for the operation of the computer servers that make | | use of the issued certificates. | | | | 7. The Agencia de Tecnología y Certificación Electrónica is | | responsible for compliance with the European, Spanish and | | Valencian legislation, as far as Electronic Signature is | | concerned. It is also responsible for compliance with the | | provisions of the Certification Practices Statement of the | | Agencia de Tecnología y Certificación Electrónica and the | | Certification Policy associated with this type of certificates. | | | | 8. The validity period of these certificates is a maximum of 12 | | months. For renewal, the same procedure must be followed as for | | the first application or the procedures set out in the associated | | Certification Policy. | | | | 9. The issued certificates will lose their effectiveness, in | | addition to the expiration of the validity period, when a | | revocation occurs, when the certificate support becomes unusable, | | when a judicial or administrative resolution ordering the loss of | | effectiveness is issued, for serious inaccuracies in the data | | provided by the applicant and by death of the subscriber of the | | certificate. Other conditions for the loss of effectiveness are | | included in the Certification Practices Statement and in the | | Certification Policy associated with this type of certificate. | | | | 10. The identification of the applicants will be based on their | | personal digital certificate issued by the Technology and | | Electronic Certification Agency or their DNIe. | | | | 11. In compliance with the Organic Law 3/2018 of December 5, 2018, on | | the Protection of Personal Data, the applicant is informed of the | | existence of an automated file of personal data, created under | | the responsibility of the Agency of Technology and Electronic | | Certification. The purpose of this file is to serve the uses | | related to the certification services provided by the Agency of | | Technology and Electronic Certification. The subscriber expressly | | authorizes the use of his personal data contained in the file, to | | the extent necessary to carry out the actions set out in the | | Certification Policy. | | | | 12. The Agency of Technology and Electronic Certification undertakes | | to put the means at its disposal to prevent alteration, loss or | | unauthorized access to personal data contained in the file. | | | | 13. The applicant may exercise their rights of access, rectification | | or cancellation of their personal data by writing to the Agency | | of Technology and Electronic Certification, through any of the | | Entry Registries of the Generalitat Valenciana and clearly | | indicating this desire. | | | | **[Revocation Reason]{.underline}** | | | | These are the reasons you can use to revoke your certificate: | | | | **No reason or unspecified** | | | | The subscriber is not required to provide a reason for revocation | | unless his private key has been compromised. | | | | **affiliationChanged** | | | | This revocation reason SHOULD be chosen when your organization name | | or other organization information on the certificate has changed. | | | | **superseded** | | | | This revocation reason SHOULD be chosen when requesting a new | | certificate to replace an existing certificate. | | | | **cessationOfOperation** | | | | You SHOULD choose this revocation reason when you no longer own all | | the domain names in the certificate or when you will no longer use | | the certificate because the web site will no longer be operational. | | | | **keyCompromise** | | | | This revocation reason MUST be chosen when the subscriber knows or | | has reason to believe that the private key of his certificate has | | been compromised. For example if an unauthorized person has gained | | access to the private key of his certificate. If this reason is | | selected, ALL CERTIFICATES ISSUED WITH THE SAME KEYS BY THE | | ORGANIZATION WILL BE REVOKED and ACCV may contact the applicant to | | gather more information and require additional evidence. | | | | **privilegeWithdrawn** | | | | The CA detects that there has been a breach on the subscriber side | | that has not resulted in key compromise, such as that the certificate | | subscriber provided misleading information in its certificate | | application or has not complied with its material obligations under | | the subscriber agreement or terms of use. | | | | Certificates with serverAuthentication keyuse are subject to the | | CA/Browser Forum definition at | | https:/ | | /cabforum.org/working-groups/server/baseline-requirements/documents/. | | Among the conditions established is the obligation to revoke the | | certificates if it is detected that the issuance or operation does | | not comply with the defined regulations. This revocation must be made | | within a maximum period of between one (1) and five (5) calendar days | | depending on the type of incident and no postponement of any kind is | | possible. If it is not possible to comply with this condition, | | certificates issued under this regulation should never be used. | | | | By signing this document, the citizen authorizes ACCV to consult the | | identity data contained in the Ministry of Interior, avoiding the | | citizen to provide a photocopy of his identity document. | +-----------------------------------------------------------------------+ ## Electronic Administrative Headquarters Certificates in Hardware Secure Module +:---------------------------------------------------------------------:+ | CERTIFICATION CONTRACT - CODE 1.3.6.1.1.4.1.8149.3.14 | +-----------------------------------------------------------------------+ | ***Section 1 - Applicant Data*** | | | | *Last name*: | | | | *Name*: | | | | Tax ID: Tel: | | | | Position or position: | | | | Administration-Organization: | | | | CIF of the Organization: | | | | *E-mail address*: | | | | Mailing address: | +-----------------------------------------------------------------------+ | ***Section 2 - E-Office data*** | | | | Qualified name: | | | | Alias (if the certificate is not issued to the qualified name): | | | | Descriptive name of the electronic site: | | | | Contact e-mail address: | +-----------------------------------------------------------------------+ | **Section 3 - *Date and Signature*** | | | | *I sign this certification contract associated with the Certification | | Policy for Electronic Administrative Headquarters Certificates in | | Hardware Secure Module with code 1.3.6.1.1.4.1.8149.3.14, issued by | | Agencia de Tecnología y Certificación Electrónica. I declare to know | | and accept the rules for the use of this type of certificates that | | are exposed in http://www.accv.es. I also declare that the | | information provided is true.* | | | | *Applicant\'s signature* | | | | *Firmat/Signed*: | +-----------------------------------------------------------------------+ +:---------------------------------------------------------------------:+ | CERTIFICATION CONTRACT - CODE 1.3.6.1.1.4.1.8149.3.14 | | | | Conditions of use of certificates | +-----------------------------------------------------------------------+ | 1. The certificates associated with the Certification Policy for | | Qualified Certificates of Administrative Electronic Headquarters | | in secure device, issued by ACCV are of type X.509v3 and are | | governed by the Certification Practices Statement of ACCV, as | | Certification Service Provider, as well as by the Certification | | Policy referred to. Both documents must be interpreted according | | to the legislation of the European Community, the Spanish legal | | system and the legislation of the Generalitat de Catalunya. | | | | 2. The applicant of the certificates must be a natural person, in | | possession of a recognized certificate of the Agency of | | Technology and Electronic Certification, and must be employed in | | a Public Administration, Instrumental Entity of the | | Administration or Corporate Entity. | | | | 3. The applicant of the certificates, specially authorized for the | | management of these by a specific Administration or Public | | Entity, is responsible for the veracity of the data provided at | | all times throughout the application and registration process. | | He/she will be responsible for communicating any variation of the | | data provided to obtain the certificate. | | | | 4. The certificate subscriber is responsible for the custody of his | | private key and for communicating as soon as possible any loss or | | theft of this key. | | | | 5. The certificate subscriber is responsible for limiting the use of | | the certificate to the provisions of the associated Certification | | Policy, which is a public document and is available at | | http://www.accv.es. | | | | 6. The Agency of Technology and Electronic Certification is not | | responsible for the content of the documents signed using the | | certificates issued by it. | | | | 7. The Agency of Technology and Electronic Certification is | | responsible for compliance with European, Spanish and Valencian | | legislation, as far as Electronic Signature is concerned. It is | | also responsible for compliance with the provisions of the | | Certification Practices Statement of ACCV and the Certification | | Policy associated with this type of certificates. | | | | 8. The validity period of these certificates is a maximum of 12 | | months. For renewal, the same procedure must be followed as for | | the first application or the procedures set out in the associated | | Certification Policy. | | | | 9. The issued certificates will lose their effectiveness, in | | addition to the expiration of the validity period, when a | | revocation occurs, when the certificate support becomes unusable, | | when a judicial or administrative resolution ordering the loss of | | effectiveness is issued, for serious inaccuracies in the data | | provided by the applicant and by death of the subscriber of the | | certificate. Other conditions for the loss of effectiveness are | | included in the Certification Practices Statement and in the | | Certification Policy associated with this type of certificate. | | | | 10. The documentation to be provided for the identification of the | | natural person requesting the certificate will be the National | | Identity Document, NIE or Passport valid and in force. The | | applicant must provide the data related to its relationship with | | the Public Administration, Instrumental Entity of the | | Administration or Corporate Entity of Public Law. | | | | 11. In compliance with the Organic Law 3/2018 of December 5, 2018, on | | the Protection of Personal Data, the applicant is informed of the | | existence of an automated personal data file, created under the | | responsibility of the Agency of Technology and Electronic | | Certification. The purpose of this file is to serve the uses | | related to the certification services provided by the Agency of | | Technology and Electronic Certification. The subscriber expressly | | authorizes the use of his personal data contained in the file, to | | the extent necessary to carry out the actions set out in the | | Certification Policy. | | | | 12. The Agency of Technology and Electronic Certification undertakes | | to put the means at its disposal to prevent alteration, loss or | | unauthorized access to personal data contained in the file. | | | | 13. The applicant may exercise their rights of access, rectification | | or cancellation of their personal data by writing to the Agency | | of Technology and Electronic Certification, through any of the | | Entry Registries of the Generalitat de Catalunya, clearly | | indicating this desire. | | | | **[Revocation Reason]{.underline}** | | | | These are the reasons you can use to revoke your certificate: | | | | **No reason or unspecified** | | | | The subscriber is not required to provide a reason for revocation | | unless his private key has been compromised. | | | | **affiliationChanged** | | | | This revocation reason SHOULD be chosen when your organization name | | or other organization information on the certificate has changed. | | | | **superseded** | | | | This revocation reason SHOULD be chosen when requesting a new | | certificate to replace an existing certificate. | | | | **cessationOfOperation** | | | | You SHOULD choose this revocation reason when you no longer own all | | the domain names in the certificate or when you will no longer use | | the certificate because the web site will no longer be operational. | | | | **keyCompromise** | | | | This revocation reason MUST be chosen when the subscriber knows or | | has reason to believe that the private key of his certificate has | | been compromised. For example if an unauthorized person has gained | | access to the private key of his certificate. If this reason is | | selected, ALL CERTIFICATES ISSUED WITH THE SAME KEYS BY THE | | ORGANIZATION WILL BE REVOKED and ACCV may contact the applicant to | | gather more information and require additional evidence. | | | | **privilegeWithdrawn** | | | | The CA detects that there has been a breach on the subscriber side | | that has not resulted in key compromise, such as that the certificate | | subscriber provided misleading information in its certificate | | application or has not complied with its material obligations under | | the subscriber agreement or terms of use. | | | | Certificates with serverAuthentication keyuse are subject to the | | CA/Browser Forum definition at | | https:/ | | /cabforum.org/working-groups/server/baseline-requirements/documents/. | | Among the conditions established is the obligation to revoke the | | certificates if it is detected that the issuance or operation does | | not comply with the defined regulations. This revocation must be made | | within a maximum period of between one (1) and five (5) calendar days | | depending on the type of incident and no postponement of any kind is | | possible. If it is not possible to comply with this condition, | | certificates issued under this regulation should never be used. | | | | By signing this document, the citizen authorizes ACCV to consult the | | identity data contained in the Ministry of Interior, avoiding the | | citizen to provide a photocopy of his identity document. | +-----------------------------------------------------------------------+ ## Electronic Administrative Headquarters Certificates based on software +:---------------------------------------------------------------------:+ | CERTIFICATION CONTRACT - CODE 1.3.6.1.1.4.1.8149.3.15 | +-----------------------------------------------------------------------+ | ***Section 1 - Applicant Data*** | | | | *Last name*: | | | | *Name*: | | | | Tax ID: Tel: | | | | Position or position: | | | | Administration-Organization: | | | | CIF of the Organization: | | | | *E-mail address*: | | | | Mailing address: | +-----------------------------------------------------------------------+ | ***Section 2 - E-Office data*** | | | | Qualified name: | | | | Alias (if the certificate is not issued to the qualified name): | | | | Descriptive name of the electronic site: | | | | Contact e-mail address: | +-----------------------------------------------------------------------+ | **Section 3 - *Date and Signature*** | | | | *I sign this certification contract associated with the Certification | | Policy for Electronic Administrative Headquarters Certificates based | | on software with code 1.3.6.1.1.4.1.8149.3.15, issued by Agencia de | | Tecnología y Certificación Electrónica. I declare to know and accept | | the rules of use of this type of certificates that are exposed in | | http://www.accv.es. I also declare that the information provided is | | true.* | | | | *Applicant\'s signature* | | | | *Firmat/Signed*: | +-----------------------------------------------------------------------+ +:---------------------------------------------------------------------:+ | CERTIFICATION CONTRACT - CODE 1.3.6.1.1.4.1.8149.3.15 | | | | Conditions of use of certificates | +-----------------------------------------------------------------------+ | 1. The certificates associated with the Certification Policy for | | Qualified Certificates of Administrative Electronic Headquarters | | in software support, issued by ACCV are of type X.509v3 and are | | governed by the Certification Practices Statement of ACCV, as | | Certification Service Provider, as well as by the Certification | | Policy referred to. Both documents must be interpreted according | | to the legislation of the European Community, the Spanish legal | | system and the legislation of the Generalitat de Catalunya. | | | | 2. The applicant of the certificates must be a natural person, in | | possession of a qualified certificate, and must be employed in a | | Public Administration, Instrumental Entity of the Administration | | or Corporate Entity. | | | | 3. The applicant of the certificates, specially authorized for the | | management of these by a specific Administration or Entity, is | | responsible for the veracity of the data provided at all times | | throughout the application and registration process. He/she will | | be responsible for communicating any variation of the data | | provided to obtain the certificate. | | | | 4. The certificate subscriber is responsible for the custody of his | | private key and for communicating as soon as possible any loss or | | theft of this key. | | | | 5. The certificate subscriber is responsible for limiting the use of | | the certificate to the provisions of the associated Certification | | Policy, which is a public document and is available at | | http://www.accv.es. | | | | 6. The Agency of Technology and Electronic Certification is not | | responsible for the content of the documents signed using the | | certificates issued by it. | | | | 7. The Agency of Technology and Electronic Certification is | | responsible for compliance with European, Spanish and Valencian | | legislation, as far as Electronic Signature is concerned. It is | | also responsible for compliance with the provisions of the | | Certification Practices Statement of ACCV and the Certification | | Policy associated with this type of certificates. | | | | 8. The validity period of these certificates is a maximum of 12 | | months. For renewal, the same procedure must be followed as for | | the first application or the procedures set out in the associated | | Certification Policy. | | | | 9. The issued certificates will lose their effectiveness, in | | addition to the expiration of the validity period, when a | | revocation occurs, when the certificate support becomes unusable, | | when a judicial or administrative resolution ordering the loss of | | effectiveness is issued, for serious inaccuracies in the data | | provided by the applicant and by death of the subscriber of the | | certificate. Other conditions for the loss of effectiveness are | | included in the Certification Practices Statement and in the | | Certification Policy associated with this type of certificate. | | | | 10. The documentation to be provided for the identification of the | | natural person requesting the certificate will be his or her | | personal qualified certificate before the registration authority. | | The applicant must provide the data related to its relationship | | with the Public Administration, Instrumental Entity of the | | Administration or Public Law Corporate Entity. | | | | 11. In compliance with the Organic Law 3/2018 of December 5, 2018, on | | the Protection of Personal Data, the applicant is informed of the | | existence of an automated file of personal data, created under | | the responsibility of the Agency of Technology and Electronic | | Certification. The purpose of this file is to serve the uses | | related to the certification services provided by the Agency of | | Technology and Electronic Certification. The subscriber expressly | | authorizes the use of his personal data contained in the file, to | | the extent necessary to carry out the actions set out in the | | Certification Policy. | | | | 12. The Agency of Technology and Electronic Certification undertakes | | to put the means at its disposal to prevent alteration, loss or | | unauthorized access to personal data contained in the file. | | | | 13. The applicant may exercise their rights of access, rectification, | | cancellation, portability, restriction of processing and | | objection to their personal data by writing to the Agency of | | Technology and Electronic Certification, through any of the Entry | | Registries of the Generalitat, clearly indicating this desire. | | | | **[Revocation Reason]{.underline}** | | | | These are the reasons you can use to revoke your certificate: | | | | **No reason or unspecified** | | | | The subscriber is not required to provide a reason for revocation | | unless his private key has been compromised. | | | | **affiliationChanged** | | | | This revocation reason SHOULD be chosen when your organization name | | or other organization information on the certificate has changed. | | | | **superseded** | | | | This revocation reason SHOULD be chosen when requesting a new | | certificate to replace an existing certificate. | | | | **cessationOfOperation** | | | | You SHOULD choose this revocation reason when you no longer own all | | the domain names in the certificate or when you will no longer use | | the certificate because the web site will no longer be operational. | | | | **keyCompromise** | | | | This revocation reason MUST be chosen when the subscriber knows or | | has reason to believe that the private key of his certificate has | | been compromised. For example if an unauthorized person has gained | | access to the private key of his certificate. If this reason is | | selected, ALL CERTIFICATES ISSUED WITH THE SAME KEYS BY THE | | ORGANIZATION WILL BE REVOKED and ACCV may contact the applicant to | | gather more information and require additional evidence. | | | | **privilegeWithdrawn** | | | | The CA detects that there has been a breach on the subscriber side | | that has not resulted in key compromise, such as that the certificate | | subscriber provided misleading information in its certificate | | application or has not complied with its material obligations under | | the subscriber agreement or terms of use. | | | | Certificates with serverAuthentication keyuse are subject to the | | CA/Browser Forum definition at | | https:/ | | /cabforum.org/working-groups/server/baseline-requirements/documents/. | | Among the conditions established is the obligation to revoke the | | certificates if it is detected that the issuance or operation does | | not comply with the defined regulations. This revocation must be made | | within a maximum period of between one (1) and five (5) calendar days | | depending on the type of incident and no postponement of any kind is | | possible. If it is not possible to comply with this condition, | | certificates issued under this regulation should never be used. | | | | By signing this document, the citizen authorizes ACCV to consult the | | identity data contained in the Ministry of Interior, avoiding the | | citizen to provide a photocopy of his identity document. | +-----------------------------------------------------------------------+ ## Server Authentication Certificates +:---------------------------------------------------------------------:+ | CERTIFICATION CONTRACT - CODE 1.3.6.1.1.4.1.8149.3.36 | +-----------------------------------------------------------------------+ | ***Section 1 - Applicant Data*** | | | | *Last name*: | | | | *Name*: | | | | Tax ID: Tel: | | | | Position or position: | | | | Administration-Organization: | | | | CIF of the Organization: | | | | *E-mail address*: | | | | Mailing address: | +-----------------------------------------------------------------------+ | ***Section 2 - Domain data*** | | | | Qualified name: | | | | Aliases: | | | | Contact e-mail address: | +-----------------------------------------------------------------------+ | **Section 3 - *Date and Signature*** | | | | *I sign this certification contract associated with the Certification | | Policy for Website Authentication Certificates with code | | 1.3.6.1.4.1.1.8149.3.36, issued by Agencia de Tecnología y | | Certificación Electrónica. I declare to know and accept the rules of | | use of this type of certificates that are exposed in | | http://www.accv.es. I also declare that the information provided is | | true.* | | | | *Applicant\'s signature* | | | | *Firmat/Signed*: | +-----------------------------------------------------------------------+ +:---------------------------------------------------------------------:+ | CERTIFICATION CONTRACT - CODE 1.3.6.1.1.4.1.8149.3.36 | | | | Conditions of use of certificates | +-----------------------------------------------------------------------+ | 1. The certificates associated with the Certification Policy of | | certificates for servers with SSL support, issued by the Agency | | of Technology and Electronic Certification are of type X.509v3 | | and are governed by the Certification Practices Statement of the | | Agency of Technology and Electronic Certification, as a | | Certification Service Provider, as well as by the Certification | | Policy referred to. Both documents must be interpreted according | | to the legislation of the European Community, the Spanish legal | | system and the legislation of the Generalitat Valenciana. | | | | 2. The applicant for the certificates must be a natural person, in | | possession of a qualified ACCV certificate or DNIe. The applicant | | must provide the data relating to their relationship with the | | Agency or Company on behalf of which they are requesting the | | certificate using the tools made available by ACCV. | | | | 3. The applicant of the certificates, specially authorized for the | | management of these by a specific Organization or Company, is | | responsible for the veracity of the data provided at all times | | throughout the application and registration process. He/she will | | be responsible for communicating any variation of the data | | provided to obtain the certificate. | | | | 4. The certificate subscriber is responsible for the custody of his | | private key and for communicating as soon as possible any loss or | | theft of this key. | | | | 5. The certificate subscriber is responsible for limiting the use of | | the certificate to the provisions of the associated Certification | | Policy, which is a public document and is available at | | http://www.accv.es. | | | | 6. The Agency of Technology and Electronic Certification is not | | responsible for the operation of the computer servers that make | | use of the issued certificates. | | | | 7. The Agencia de Tecnología y Certificación Electrónica is | | responsible for compliance with the European, Spanish and | | Valencian legislation, as far as Electronic Signature is | | concerned. It is also responsible for compliance with the | | provisions of the Certification Practices Statement of the | | Agencia de Tecnología y Certificación Electrónica and the | | Certification Policy associated with this type of certificates. | | | | 8. The validity period of these certificates is a maximum of 12 | | months. For renewal, the same procedure must be followed as for | | the first application or the procedures set out in the associated | | Certification Policy. | | | | 9. The issued certificates will lose their effectiveness, in | | addition to the expiration of the validity period, when a | | revocation occurs, when the certificate support becomes unusable, | | when a judicial or administrative resolution ordering the loss of | | effectiveness is issued, for serious inaccuracies in the data | | provided by the applicant and by death of the subscriber of the | | certificate. Other conditions for the loss of effectiveness are | | included in the Certification Practices Statement and in the | | Certification Policy associated with this type of certificate. | | | | 10. The identification of the applicants will be based on their | | personal digital certificate issued by the Technology and | | Electronic Certification Agency or their DNIe. | | | | 11. In compliance with the Organic Law 3/2018 of December 5, 2018, on | | the Protection of Personal Data, the applicant is informed of the | | existence of an automated personal data file, created under the | | responsibility of the Agency of Technology and Electronic | | Certification. The purpose of this file is to serve the uses | | related to the certification services provided by the Agency of | | Technology and Electronic Certification. The subscriber expressly | | authorizes the use of his personal data contained in the file, to | | the extent necessary to carry out the actions set out in the | | Certification Policy. | | | | 12. The Agency of Technology and Electronic Certification undertakes | | to put the means at its disposal to prevent alteration, loss or | | unauthorized access to personal data contained in the file. | | | | 13. The applicant may exercise their rights of access, rectification | | or cancellation of their personal data by writing to the Agency | | of Technology and Electronic Certification, through any of the | | Entry Registries of the Generalitat Valenciana and clearly | | indicating this desire. | | | | **[Revocation Reason]{.underline}** | | | | These are the reasons you can use to revoke your certificate: | | | | **No reason or unspecified** | | | | The subscriber is not required to provide a reason for revocation | | unless his private key has been compromised. | | | | **affiliationChanged** | | | | This revocation reason SHOULD be chosen when your organization name | | or other organization information on the certificate has changed. | | | | **superseded** | | | | This revocation reason SHOULD be chosen when requesting a new | | certificate to replace an existing certificate. | | | | **cessationOfOperation** | | | | You SHOULD choose this revocation reason when you no longer own all | | the domain names in the certificate or when you will no longer use | | the certificate because the web site will no longer be operational. | | | | **keyCompromise** | | | | This revocation reason MUST be chosen when the subscriber knows or | | has reason to believe that the private key of his certificate has | | been compromised. For example if an unauthorized person has gained | | access to the private key of his certificate. If this reason is | | selected, ALL CERTIFICATES ISSUED WITH THE SAME KEYS BY THE | | ORGANIZATION WILL BE REVOKED and ACCV may contact the applicant to | | gather more information and require additional evidence. | | | | **privilegeWithdrawn** | | | | The CA detects that there has been a breach on the subscriber side | | that has not resulted in key compromise, such as that the certificate | | subscriber provided misleading information in its certificate | | application or has not complied with its material obligations under | | the subscriber agreement or terms of use. | | | | Certificates with serverAuthentication keyuse are subject to the | | CA/Browser Forum definition at | | https:/ | | /cabforum.org/working-groups/server/baseline-requirements/documents/. | | Among the conditions established is the obligation to revoke the | | certificates if it is detected that the issuance or operation does | | not comply with the defined regulations. This revocation must be made | | within a maximum period of between one (1) and five (5) calendar days | | depending on the type of incident and no postponement of any kind is | | possible. If it is not possible to comply with this condition, | | certificates issued under this regulation should never be used. | | | | By signing this document, the citizen authorizes ACCV to consult the | | identity data contained in the Ministry of Interior, avoiding the | | citizen to provide a photocopy of his identity document. | +-----------------------------------------------------------------------+