1. INTRODUCTION

1.1 Overview

This Certification Practice Statement (“CPS”) document outlines the certification services practices for CASTLE Platform® (“CASTLE”) Public Key Infrastructure (“CASTLE PKI”).

CASTLE PKI services include, but are not limited to, issuing, managing, validating, revoking, and renewing publicly-trusted Certificates in accordance with the requirements of the CASTLE Certificate Policy (CP) and in a manner consistent with this CPS. It is recommended that readers familiarize themselves with the CASTLE CP prior to reading this document.

These services are provided to the general public with exceptions as deemed appropriate by CASTLE management or in accordance with relevant law.

CASTLE PKI services are most commonly, but not necessarily exclusively, provided under the brand/trademark “ACME Email Server”.

The CASTLE PKI conforms to the current version of the Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates published at http://www.cabforum.org. In the event of any inconsistency between this document and those Requirements, those Requirements take precedence over this document.

Other documents related to the behavior and control of the CASTLE PKI, such as a Subscriber Agreement and Privacy Policy, can be found at https://acme.castle.cloud/legal/.

Per IETF PKIX RFC 3647, this CPS is divided into nine components that cover security controls, practices, and procedures for certification services provided by the CASTLE PKI.

The following Certification Authorities are covered under this CPS:

CA Type	Distinguished Name	Key Pair Type and Parameters	Cert SHA-256 Fingerprint	Validity Period
Root CA	C=ES O=CASTLE Platform, CN=CASTLE Root RR1 CA	RSA, n has 4096 bits, e=65537	18:45:B9:56:0B:38:A0:AC: 11:49:4F:4C:F2:B2:F3:72: A1:A3:98:E1:14:39:06:6C: A2:73:4E:CC:86:D6:7C:0E	Not Before: Mar 12 14:47:40 2021 GMT, Not After: Mar 12 14:47:40 2051 GMT

This work is licensed under the Creative Commons Attribution 4.0 International License. To view a copy of this license, visit http://creativecommons.org/licenses/by/4.0/ or send a letter to Creative Commons, PO Box 1866, Mountain View, CA 94042, USA.

1.2 Document name and identification

This is the CASTLE Certification Practice Statement. This document was approved for publication by the CASTLE Policy Management Authority, and is made available at https://acme.castle.cloud/legal/.

The following revisions have been made:

Date	Changes	Version
October 5, 2021	Original.	1.0
November 30, 2021	– Added 4.3.1.1: previous certs are revoked if new cert with the same CN is issued (#28)	1.1

1.3 PKI Participants

1.3.1 Certification Authorities

This CPS applies to the CASTLE CA.

1.3.2 Registration Authorities

CASTLE CA does not delegate any of the Section 3.2 requirements to a Delegated Third Party. CASTLE CA serves as its own RA.

1.3.3 Subscribers

See definition of “Subscriber” in Section 1.6.1 Definitions.

1.3.4 Relying Parties

See definition of “Relying Party” in Section 1.6.1 Definitions.

1.3.5 Other Participants

Other participants include CAs that cross-sign or issue subordinates to the CASTLE PKI.

CASTLE PKI vendors and service providers with access to confidential information or privileged systems are required to operate in compliance with the CASTLE CP.

1.4 Certificate Usage

1.4.1 Appropriate Certificate Uses

No stipulation.

1.4.2 Prohibited Certificate Uses

Certificates may not be used:

• For any application requiring fail-safe performance such as a) the operation of nuclear power facilities b) air traffic control systems c) aircraft navigation systems d) weapons control systems e) any other system in which failure could lead to injury, death, or environmental damage.
• For software or hardware architectures that provide facilities for interference with encrypted communications, including but not limited to a) active eavesdropping (e.g., monster-in-the-middle attacks) b) traffic management of domain names or internet protocol addresses that the organization does not own or control. Note that these restrictions shall apply regardless of whether a relying party communicating through the software or hardware architecture has knowledge of its providing facilities for interference with encrypted communications.

Note that Certificates do not guarantee anything regarding reputation, honesty, or the current state of endpoint security. A Certificate only represents that the information contained in it was verified as reasonably correct when the Certificate was issued.

1.5 Policy administration

1.5.1 Organization Administering the Document

This CPS document is maintained by the CASTLE PMA.

1.5.2 Contact Person

The CASTLE PMA can be contacted at:

Arrays & MultiSensor Processing Group
Centre Tecnològic de Telecomunicacions de Catalunya
Av. Carl Friedrich Gauss, 7
08860, Castelldefels, Barcelona
Spain

Certificate revocation requests can be made via the ACME API. Please see Section 4.9.3 for more information.

Certificate Problem Reports can be submitted via email to:

[email protected]

1.5.3 Person Determining CPS suitability for the policy

The CASTLE PMA is responsible for determining the suitability of this CPS. The CASTLE PMA is informed by results and recommendations received from an independent auditor.

1.5.4 CPS approval procedures

The CASTLE PMA approves any revisions to this CPS document after formal review.

1.6 Definitions and Acronyms

1.6.1 Definitions

• ACME Protocol
  • A protocol used for validation, issuance, and management of certificates. The protocol is an open standard managed by the IETF.
• Baseline Requirements
  • A document published by the CAB Forum which outlines minimum requirements for publicly trusted Certificate Authorities.
• CAB Forum
  • Certificate Authority / Browser Forum, a group a CAs and browsers which come together to discuss technical and policy issues related to PKI systems. (https://cabforum.org/)
• Certificate Repository
  • A repository of information about certificates.
• Policy and Legal Repository
  • A repository of policy and legal documents related to the PKI. It is located at https://acme.castle.cloud/legal/.
• Precertificate
  • A certificate containing a critical poison extension as defined by RFC 6962 Section 3.1.
• Secure PKI Facilities
  • Facilities designed to protect sensitive PKI infrastructure, including CA private keys.
• Trusted Contributor
  • A contributor who performs in a Trusted Role. Trusted Contributors may be employees, contractors, or community members. Trusted Contributors must be properly trained and qualified, and have the proper legal obligations in place before performing in a Trusted Role.
• Trusted Role
  • A role which qualifies a person to access or modify CASTLE PKI systems, infrastructure, and confidential information.

See CASTLE CP 1.6.1 for additional definitions.

1.6.2 Acronyms

• ACME
  • Automated Certificate Management Environment
• DV
  • Domain Validation
• FQDA
  • Fully-Qualified Domain Address
• HSM
  • Hardware Security Module
• IP
  • Internet Protocol
• PMA
  • Policy Management Authority
• SAN
  • Subject Alternative Name
• TLD
  • Top Level Domain

See CASTLE CP 1.6.2 for additional acronyms.

1.6.3 References

No references defined at this time.

1.6.4 Conventions

Terms not otherwise defined in this CPS shall be as defined in applicable agreements, user manuals, Certificate Policies and Certification Practice Statements, of the CA.

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in these Requirements shall be interpreted in accordance with RFC 2119.

2. PUBLICATION AND REPOSITORY RESPONSIBILITIES

2.1 Repositories

CASTLE CP, CPS, Privacy Policy, Subscriber Agreement, and WebTrust audit documents are made publicly available in the Policy and Legal Repository, which can be found at:

https://acme.castle.cloud/legal/

2.2 Publication of information

CASTLE certificates contain URLs to locations where certificate-related information is published, including revocation information via OCSP and/or CRLs.

2.3 Time or frequency of publication

New or updated CASTLE CP, CPS, Privacy Policy, Subscriber Agreement, and WebTrust audit documents are made publicly available as soon as possible. This typically means within seven days of receipt or approval. The CASTLE PMA will approve and publish updated CP and CPS documents at least annually.

New or updated CASTLE Root and Subordinate CA certificates are made publicly available as soon as possible. This typically means within seven days of creation.

2.4 Access controls on repositories

Read only access to the Policy and Legal Repository and certificate information is unrestricted. Write access is protected by logical and physical controls.

3. IDENTIFICATION AND AUTHENTICATION

3.1 Naming

3.1.1 Types of names

Certificate distinguished names and subject alternative names are compliant with the CASTLE CP.

3.1.2 Need for names to be meaningful

CASTLE certificates include a “Subject” field which identifies the subject entity (i.e. FQDA). The subject entity is identified using a distinguished name.

CASTLE certificates include an “Issuer” field which identifies the issuing entity. The issuing entity is identified using a distinguished name.

3.1.3 Anonymity or pseudonymity of subscribers

Subscribers are not identified in DV certificates, which have subject fields identifying only FQDA (not people or organizations). Relying Parties should consider DV certificate Subscribers to be anonymous.

3.1.4 Rules for interpreting various name forms

Distinguished names in certificates are to be interpreted using X.500 standards and ASN.1 syntax.

Certificates do not assert any specific relationship between Subscribers and registrants of email address(es) contained in certificates.

Regarding Internationalized Domain Names, CASTLE CA will have no objection so long as the domain is resolvable via DNS. It is the CA’s position that homoglyph spoofing should be dealt with by registrars, and Web browsers should have sensible policies for when to display the punycode versions of names.

3.1.5 Uniqueness of names

No stipulation.

3.1.6 Recognition, authentication, and role of trademarks

CASTLE CA reserves the right to make all decisions regarding Subscriber names in certificates. Entities requesting certificates will be required to demonstrate their right to use names (e.g. demonstrate control of a FQDA), but trademark rights are not verified.

While CASTLE CA will comply with Spain law and associated legal orders, it is CASTLE CA’s position that trademark enforcement responsibility for domain names should lie primarily with domain registrars and the legal system.

3.2 Initial identity validation

CASTLE CA may elect not to issue any certificate at its sole discretion.

3.2.1 Method to prove possession of private key

Applicants are required to prove possession of the Private Key corresponding to the Public Key in a Certificate request by signing the CSR provided to the Finalize method of the ACME Protocol defined in RFC 8823, Section 3.

3.2.2 Authentication of Organization and Domain Identity

CASTLE CA only issues Domain Validation (DV) certificates. All FQDA which will be listed in the Common Name and list of SANs in the certificate are fully validated prior to issuance.

CASTLE CA uses one methods for validating domain control:

1. ACME (BR and CASTLE CP Section 3.2.2.4.2)

Validation for Wildcard FQDN is not permitted.

All validations are performed in compliance with the current CAB Forum Baseline Requirements at the time of validation.

3.2.3 Authentication of individual identity

CASTLE CA does not issue certificates to individuals, and thus does not authenticate individual identities.

3.2.4 Non-verified subscriber information

Non-verified Applicant information is not included in CASTLE certificates.

3.2.5 Validation of authority

CASTLE CA does not issue Subscriber Certificates containing Subject Identity Information, and thus does not validate any natural person’s authority to request certificates on behalf of organizations.

3.2.6 Criteria for Interoperation or Certification

CASTLE CA discloses Cross Certificates in its Certificate Repository.

3.3 Identification and authentication for re-key requests

3.3.1 Identification and authentication for routine re-key

See Section 4.7.

3.3.2 Identification and authentication for re-key after revocation

See Section 4.7.

3.4 Identification and authentication for revocation request

Identification and authentication for revocation requests is performed by CASTLE CA in compliance with Section 4.9 of this document.

Identification and authentication are not required when revocation is being requested by CASTLE CA.

4. CERTIFICATE LIFE-CYCLE OPERATIONAL REQUIREMENTS

4.1 Certificate Application

4.1.1 Who can submit a certificate application

Anyone may submit an application for a certificate via the ACME protocol. Issuance will depend on proper validation and compliance with CASTLE CA policies.

4.1.2 Enrollment process and responsibilities

The enrollment process involves the following steps, in no particular order:

• Generating a key pair using secure methods
• Submitting a request for a certificate containing all necessary information, including the public key
• Agreeing to the relevant Subscriber Agreement

4.2 Certificate application processing

4.2.1 Performing identification and authentication functions

CASTLE CA performs all identification and authentication functions in accordance with the CASTLE CP. This includes validation per CPS Section 3.2.2.

Certificate information is verified using data and documents obtained no more than 90 days prior to issuance of the Certificate.

4.2.2 Approval or rejection of certificate applications

Approval requires successful completion of validation per Section 3.2.2 as well as compliance with all CA policies.

CA server will not validate or issue for DNS identifiers that do not have a Public Suffix in the ICANN domains section.

4.2.3 Time to process certificate applications

No stipulation.

4.3 Certificate issuance

4.3.1 CA actions during certificate issuance

At a high level, the following steps are taken during issuance of a Subscriber Certificate. CASTLE CA’s automated processes confirm that all names which will appear in the Common Name and/or list of SANs of the certificate have been properly validated to be controlled by the Subscriber requesting the certificate. The certificate is signed by a Subordinate CA in an HSM. After issuance is complete, the certificate is stored in a database and made available to the Subscriber.

4.3.1.1 Revocation of previous existing names

During the certificate issuance, CASTLE CA checks the existence of previous certificates with the same Common Name and/or list of SANs. CASTLE CA revokes all valid certificates that match with the request.

4.3.2 Notification to subscriber by the CA of issuance of certificate

Subscriber Certificates are made available to Subscribers via the ACME protocol as soon after issuance as reasonably possible. Typically this happens within a few seconds.

4.4 Certificate acceptance

4.4.1 Conduct constituting certificate acceptance

No stipulation.

4.4.2 Publication of the certificate by the CA

See Section 2.2 of this document for Root and Subordinate CA certificate publication information.

All Subscriber Certificates are made available to Subscribers via the ACME protocol.

4.4.3 Notification of certificate issuance by the CA to other entities

See Section 4.4.2.

4.5 Key pair and certificate usage

4.5.1 Subscriber private key and certificate usage

Subscriber usage of Private Keys and Certificates is governed by the ACME Email Server Terms of Service Agreement.

4.5.2 Relying party public key and certificate usage

Relying Parties should fully evaluate the context in which they are relying on certificates and the information contained in them, and decide to what extent the risk of reliance is acceptable. If the risk of relying on a certificate is determined to be unacceptable, then Relying Parties should not use the certificate or should obtain additional assurances before using the certificate.

CASTLE CA does not warrant that any software used by Relying Parties to evaluate or otherwise handle certificates does so properly.

4.6 Certificate renewal

Certificate renewal requests are treated as applications for new certificates.

4.6.1 Circumstance for certificate renewal

No stipulation.

4.6.2 Who may request renewal

No stipulation.

4.6.3 Processing certificate renewal requests

No stipulation.

4.6.4 Notification of new certificate issuance to subscriber

No stipulation.

4.6.5 Conduct constituting acceptance of a renewal certificate

No stipulation.

4.6.6 Publication of the renewal certificate by the CA

No stipulation.

4.6.7 Notification of certificate issuance by the CA to other entities

No stipulation.

4.7 Certificate re-key

Certificate re-key requests are treated as applications for new certificates.

4.7.1 Circumstance for certificate re-key

No stipulation.

4.7.2 Who may request certification of a new public key

No stipulation.

4.7.3 Processing certificate re-keying requests

No stipulation.

4.7.4 Notification of new certificate issuance to subscriber

No stipulation.

4.7.5 Conduct constituting acceptance of a re-keyed certificate

No stipulation.

4.7.6 Publication of the re-keyed certificate by the CA

No stipulation.

4.7.7 Notification of certificate issuance by the CA to other entities

No stipulation.

4.8 Certificate modification

Certificate modification requests are treated as applications for new certificates.

4.8.1 Circumstance for certificate modification

No stipulation.

4.8.2 Who may request certificate modification

No stipulation.

4.8.3 Processing certificate modification requests

No stipulation.

4.8.4 Notification of new certificate issuance to subscriber

No stipulation.

4.8.5 Conduct constituting acceptance of modified certificate

No stipulation.

4.8.6 Publication of the modified certificate by the CA

No stipulation.

4.8.7 Notification of certificate issuance by the CA to other entities

No stipulation.

4.9 Certificate revocation and suspension

4.9.1 Circumstances for revocation

CASTLE CA will follow the CASTLE CP and revoke a certificate in accordance with Section 4.9.1.1 and Section 4.9.1.2 of the CASTLE CP.

4.9.2 Who can request revocation

Anyone can revoke any certificate via the ACME API if they can sign the revocation request with the private key associated with the certificate. No other information is required in such cases.

Anyone can revoke any certificate via the ACME API if they can demonstrate control over all FQDA covered by the certificate. No other information is required in such cases.

Subscribers can revoke certificates belonging to their accounts via the ACME API if they can sign the revocation request with the associated account private key. No other information is required in such cases.

Certificates may be administratively revoked by CASTLE CA if it is determined that the Subscriber has failed to meet obligations under the CASTLE CP, this CPS, the relevant Terms of Service Agreement, or any other applicable agreement, regulation, or law. Certificates may also be administratively revoked at the discretion of CASTLE CA management.

4.9.3 Procedure for revocation request

Revocation requests may be made by anyone, at any time, via the Certificate Revocation interface of the ACME Protocol defined in RFC 8823 section 3. Successful revocation requests with a reason code of keyCompromisewill result in the affected key being blocked for future issuance and all currently valid certificates with that key will be revoked, regardless of whether compromise was demonstrated per the requirements in Section 4.9.12 of this document.

An investigation into whether revocation or other appropriate action is warranted will be based on at least the following criteria:

1. The nature of the alleged problem;
2. The number of Certificate Problem Reports received about a particular Certificate or Subscriber;
3. The entity making the complaint; and
4. Relevant legislation.

4.9.4 Revocation request grace period

There is no grace period for a revocation request. A revocation request must be made as soon as circumstances requiring revocation are confirmed.

4.9.5 Time within which CA must process the revocation request

Investigation into a revocation request will begin within 24 hours of receiving the request. Revocation, if necessary, will be carried out within the timeframes set by CASTLE CP Sections 4.9.1.1 and 4.9.1.2.

4.9.6 Revocation checking requirement for relying parties

Relying Parties should verify the validity of certificates via CRL or OCSP prior to relying on certificates. Relying Parties who cannot or choose not to check certificate expiration or revocation status, but decide to rely on a certificate anyway, do so at their own risk.

See Section 4.5.2.

4.9.7 CRL issuance frequency (if applicable)

CASTLE CA will issue updated CRLs for Subordinate CA certificates with a frequency greater than or equal to that required by the CASTLE CP.

CASTLE CA does not issue CRLs for Subscriber Certificates.

4.9.8 Maximum latency for CRLs (if applicable)

When a CRL is requested by a Relying Party the time to receive a response will be less than ten seconds under normal operating conditions.

4.9.9 On-line revocation/status checking availability

Revocation information will be made available for all Subscriber Certificates via OCSP. Revocation information may be made available for Subordinate CA certificates via OCSP.

4.9.10 On-line revocation checking requirements

CASTLE CA provides OCSP responses in compliance with CASTLE CP Section 4.9.10.

4.9.11 Other forms of revocation advertisements available

CASTLE CA does not allow for OCSP stapling.

4.9.12 Special requirements re key compromise

Key compromise must be demonstrated via the Certificate Revocation method of the ACME Protocol defined in RFC 8823, Section 3 by signing the request using the private key corresponding to the public key in the certificate (not the private key corresponding to the account which originally requested the certificate).

4.9.13 Circumstances for suspension

CASTLE CA does not suspend certificates.

4.9.14 Who can request suspension

Not applicable.

4.9.15 Procedure for suspension request

Not applicable.

4.9.16 Limits on suspension period

Not applicable.

4.10 Certificate status services

4.10.1 Operational characteristics

CRL entries for Subordinate CA certificates will remain in place until the certificates expire. CASTLE CA does not provide CRLs for Subscriber Certificates.

OCSP responses will be made available for all unexpired Subscriber certificates.

4.10.2 Service availability

All certificate status services are made available at all times (24×7) if possible.

4.10.3 Optional features

No stipulation.

4.11 End of subscription

A Subscriber’s subscription ends once all of Subscriber’s CASTLE CA certificates have expired or been revoked.

Prior to expiration of a Subscriber’s certificate, CASTLE CA may send Subscriber a notice regarding upcoming Certificate expiration if a contact email address was provided.

4.12 Key escrow and recovery

4.12.1 Key escrow and recovery policy and practices

Not applicable.

4.12.2 Session key encapsulation and recovery policy and practices

Not applicable.

5. MANAGEMENT, OPERATIONAL, AND PHYSICAL CONTROLS

5.1 PHYSICAL SECURITY CONTROLS

5.1.1 Site location and construction

CASTLE Secure PKI Facilities are located in Spain, as are all copies of CASTLE CA Private Keys.

CASTLE CA maintains at least two Secure PKI Facilities at all times for the sake of redundancy.

Secure PKI Facilities are constructed so as to prevent unauthorized entry or interference.

Secure PKI Facilities are monitored at all times (24×7) so as to prevent unauthorized entry or interference.

5.1.2 Physical access

Physical access to CASTLE Secure PKI Facilities is restricted to authorized CASTLE employees, vendors, and contractors, for whom access is required in order to execute their jobs. Access restrictions are strongly enforced via multi-factor authentication mechanisms.

5.1.3 Power and air conditioning

Redundant power sources are readily available at each Secure PKI Facility, and are designed to meet CASTLE CA’s operating requirements.

Air conditioning systems at each Secure PKI Facility are designed to meet CASTLE CA’s operating requirements.

5.1.4 Water exposures

CASTLE Secure PKI Facilities are designed to protect CASTLE infrastructure from water exposure/damage.

5.1.5 Fire prevention and protection

CASTLE Secure PKI Facilities are designed to prevent fire and provide suppression if necessary.

5.1.6 Media storage

CASTLE Secure PKI Facilities are designed to prevent accidental damage or unauthorized access to media.

5.1.7 Waste disposal

CASTLE CA prohibits any media that contains or has contained sensitive data from leaving organizational control in such a state that it may still be operational, or contain recoverable data. Such media may include printed documents or digital storage devices. When media that has contained sensitive information reaches its end of life, the media is physically destroyed such that recovery is reasonably believed to be impossible.

5.1.8 Off-site backup

CASTLE CA maintains multiple backups of CASTLE CA Private Keys at multiple Secure PKI Facilities.

5.2 Procedural controls

5.2.1 Trusted roles

All persons, employees or otherwise, with the ability to materially impact the operation of CASTLE PKI systems and services, or the ability to view CA confidential information, must do so while designated as serving in a Trusted Role.

Trusted Roles include, but are not limited to:

• Management
  • May view confidential information but may not directly impact CA operations. Strong decision-making authority.
• Security Officers
  • May view confidential information but may not directly impact CA operations. Strong decision-making authority.
• Systems Administrators
  • May view confidential information and directly impact CA operations. Decision-making authority is limited.
• Engineering Liaisons
  • May view confidential information but may not directly impact CA operations. No decision-making authority.

Each Trusted Role requires an appropriate level of training and legal obligation.

5.2.2 Number of Individuals Required per Task

No stipulation.

5.2.3 Identification and authentication for each role

Anyone performing work in a Trusted Role must identify and authenticate themselves before accessing CASTLE PKI systems or confidential information.

5.2.4 Roles requiring separation of duties

See Section 6.6.1.

5.3 Personnel controls

5.3.1 Qualifications, experience, and clearance requirements

CASTLE CA management is responsible for making sure that Trusted Contributors are trustworthy and competent, which includes having proper qualifications and experience.

CASTLE CA management ensures this with appropriate interviewing practices, training, background checks, and regular monitoring and review of Trusted Contributor job performance.

5.3.2 Background check procedures

Trusted Contributors must undergo a background check prior to performing in a trusted role. CASTLE CA management will review the results of background checks for problematic issues prior to approving performance of a trusted role.

Background checks include, but are not limited to, criminal background and employment history.

5.3.3 Training Requirements and Procedures

Trusted Contributors must be trained on topics relevant to the role in which they will perform.

Training programs are developed for each role by CASTLE CA management and Security Officers.

5.3.4 Retraining frequency and requirements

Training is repeated for each Trusted Contributor on an annual basis and covers topics necessary to maintain skill level requirements.

Training is also offered whenever changes in the industry or operations require it in order for contributors to competently perform in their trusted roles.

5.3.5 Job rotation frequency and sequence

No stipulation.

5.3.6 Sanctions for unauthorized actions

Action will be taken to safeguard CASTLE CA and its Subscribers whenever CASTLE Trusted Contributors, whether through negligence or malicious intent, fail to comply with CASTLE CA policies including this CPS.

Actions taken in response to non-compliance may include termination, removal from trusted roles, or reporting to legal authorities.

Once management becomes aware of non-compliance the Trusted Contributor(s) in question will be removed from trusted roles until a review of their actions is complete.

5.3.7 Independent Contractor Controls

Independent contractors who are assigned to perform Trusted Roles are subject to the duties and requirements specified for such roles in this CPS and the CASTLE CP. This includes those described in Section 5.3. Potential sanctions for unauthorized activities by independent contractors are described in Section 5.3.6.

5.3.8 Documentation supplied to personnel

Trusted Contributors are provided with all documentation necessary to perform their duties. This always includes, at a minimum, a copy of the CASTLE CP, CPS, and Information Security Policy.

5.4 Audit logging procedures

5.4.1 Types of events recorded

Audit logs are generated for all events related to CA security (physical and logical) and certificate issuance. Logs are automatically generated whenever possible. When it is necessary to manually log information, logs are kept on paper with written confirmation from a witness and securely stored. All audit logs, electronic or otherwise, shall be retained and made available to compliance auditors upon request.

At a minimum, each audit record includes:

• Date and time of entry;
• Identity of the person (or machine) making the entry; and
• Description of the entry.

5.4.2 Frequency for Processing and Archiving Audit Logs

No stipulation.

5.4.3 Retention Period for Audit Logs

Audit logs are retained for at least two years and will be made available to compliance auditors upon request.

5.4.4 Protection of Audit Log

Audit logs, whether in production or archived, are protected using both physical and logical access controls.

5.4.5 Audit Log Backup Procedures

CASTLE CA makes regular backup copies of audit logs.

5.4.6 Audit Log Accumulation System (internal vs. external)

Audit data is automatically generated and reported/recorded by operating systems, CA software applications, and network devices. Systems are in place to ensure proper reporting and recording of audit data, and the failure of such systems may lead to suspension of CA services until proper audit log reporting is restored.

5.4.7 Notification to event-causing subject

No stipulation.

5.4.8 Vulnerability assessments

Audit logs are monitored by Trusted Contributors, including operations and engineering staff. Anomalies indicating attempted breaches of CA security are reported and investigated.

Internal and external vulnerability scans occur at least every three months.

Extensive vulnerability assessments for CASTLE infrastructure are conducted at least annually by qualified third parties.

CASTLE Security Officers perform a risk assessment at least annually. This risk assessment:

1. Identifies foreseeable internal and external threats that could result in unauthorized access, disclosure, misuse, alteration, or destruction of any Certificate Data or Certificate Management Processes;
2. Assesses the likelihood and potential damage of these threats, taking into consideration the sensitivity of the Certificate Data and Certificate Management Processes; and
3. Assesses the sufficiency of the policies, procedures, information systems, technology, and other arrangements that the CA has in place to counter such threats.

5.5 Records archival

5.5.1 Types of records archived

CASTLE CA archives all audit logs, the contents of which are described in Section 5.4.1. CASTLE CA may also archive any other information deemed critical to understanding the historical performance of the CA’s duties.

5.5.2 Retention period for archive

CASTLE CA retains all documentation relating to certificate requests and the verification thereof, and all Certificates and revocation thereof, for at least two years after any Certificate based on that documentation ceases to be valid.

5.5.3 Protection of archive

Archives are protected from unauthorized modification or destruction by strong security and environmental controls.

5.5.4 Archive backup procedures

Archives are backed up regularly.

5.5.5 Requirements for time-stamping of records

Records are time-stamped as they are created.

Machine-created records use system time, which is synchronized automatically with third-party time sources. Machines without network access have the time set manually.

Manual records use a manually entered date and time, complete with time zone in use.

5.5.6 Archive collection system (internal or external)

No stipulation.

5.5.7 Procedures to obtain and verify archive information

No stipulation.

5.6 Key changeover

When a CA certificate is nearing expiration, a key changeover procedure is used to transition to a new CA certificate. The following steps constitute a key changeover procedure:

1. Some time prior to CA certificate expiration, the private key associated with the expiring certificate is no longer used to sign new certificates. It is only used to sign CRLs and OCSP responses.
2. A new key pair is generated and a new CA certificate is created containing the new key pair’s public key. This new key pair is used to sign new certificates.
3. If necessary or desired, the old private key associated with the expiring certificate may be used to cross-sign the new certificate.

5.7 Compromise and disaster recovery

5.7.1 Incident and compromise handling procedures

CASTLE CA has created and maintains incident response procedures for a range of potential compromise and disaster situations. Such situations include, but are not limited to natural disasters, security incidents, and equipment failure. Incident response plans are reviewed, potentially updated, and tested on at least an annual basis.

5.7.2 Recovery Procedures if Computing resources, software, and/or data are corrupted

In the event that computing resources, software, and/or data are corrupted or otherwise damaged, CASTLE CA will assess the situation, including its impact on CA integrity and security, and take appropriate action. CA operations may be suspended until mitigation is complete. Subscribers may be notified if corruption or damage has a material impact on the service provided to them.

5.7.3 Recovery Procedures after Key Compromise

In the event that an CASTLE CA Private Key is compromised, or suspected to be compromised, CASTLE CA will immediately launch a thorough investigation. Forensic evidence will be collected and secured as quickly as possible. If it cannot be determined with a high degree of certainty that the private key in question was not compromised, then the following steps may be taken in whatever order is deemed most appropriate by CASTLE Security Officers:

• Certificates relying on the private key in question will be revoked.
• CASTLE CA will notify root programs relying on the integrity of the key in question.
• CASTLE CA will notify Subscribers relying on the integrity of the key in question.

5.7.4 Business continuity capabilities after a disaster

No stipulation.

5.8 CA or RA termination

In the event that CASTLE CA services are to be terminated:

• All affected parties, including root programs and Subscribers, will be provided with notice as far in advance as reasonably possible.
• A termination plan will be created and review by the CASTLE PMA.

If a suitable successor entity exists, the following steps will be taken:

• CASTLE CA Private Keys, records, logs, and other critical documentation will be transferred to the successor organization in a secure and compliant manner.
• Arrangements will be made for compliant continuation of CA responsibilities.

If a suitable successor entity does not exist, the following steps will be taken:

• All certificates issued will be revoked and final CRLs will be published.
• CASTLE CA Private Keys will be destroyed.
• CA records, logs, and other critical documentation will be transferred to a third party or government entity with appropriate legal controls in place to protect information while allowing its use in compliance with relevant policies and the law.

6. TECHNICAL SECURITY CONTROLS

6.1 Key pair generation and installation

6.1.1 Key pair generation

No stipulation.

6.1.2 Private key delivery to subscriber

CASTLE CA never generates or has access to Subscriber Private Keys.

6.1.3 Public key delivery to certificate issuer

Subscriber Public Keys are communicated to CASTLE CA electronically via the ACME protocol.

6.1.4 CA public key delivery to relying parties

CASTLE Public Keys are provided to Relying Parties as part of browser, operating system, or other software trusted root certificate lists.

CASTLE Public Keys are also available in the Certificate Repository.

6.1.5 Key sizes

CASTLE Root CA RSA Private Keys are at least 4096 bits in length.

CASTLE Root CA ECDSA Private Keys are at least 384 bits in length.

CASTLE Subordinate CA RSA Private Keys are at least 2048 bits in length.

CASTLE Subordinate CA ECDSA Private Keys are at least 384 bits in length.

6.1.6 Public key parameters generation and quality checking

CASTLE CA uses HSMs conforming to FIPS 186-4, capable of providing random number generation and on-board creation of at least 2048-bit RSA keys and at least 384-bit ECDSA keys.

Per NIST SP 800‐89, section 5.3.3, the CA ensures that:

• the public exponent of any RSA key used in a DV-SSL Certificate is in the range between 2¹⁶+1 and 2²⁵⁶-1, and
• the modulus of such a certificate is an odd number, not the power of a prime, and has no factors smaller than 752.

6.1.7 Key usage purposes (as per X.509 v3 key usage field)

See Section 7, Certificate Profiles.

6.2 Private Key Protection and Cryptographic Module Engineering Controls

6.2.1 Cryptographic module standards and controls

CASTLE CA uses HSMs meeting FIPS 140-2 Level 3 (or higher) requirements.

6.2.2 Private key (n out of m) multi-person control

CASTLE CA has put into place security mechanisms which require multiple people performing in Trusted Roles in order to access CASTLE CA Private Keys, both physically and logically. This is true for all copies of Private Keys, in production or backups, on-site or off-site.

6.2.3 Private key escrow

CASTLE CA does not escrow CA Private Keys and does not provide such a service for Subscribers.

6.2.4 Private key backup

Critical CASTLE CA Private Keys are backed up both on-site and off-site, in multiple geographic locations, under multi-person control.

6.2.5 Private key archival

CASTLE CA does not archive private keys.

6.2.6 Private key transfer into or from a cryptographic module

CASTLE CA Private Keys are generated inside HSMs and are only transferred between HSMs for redundancy or backup purposes. When transferred, keys are encrypted prior to leaving HSMs and unwrapped only inside destination HSMs. Keys never exist in plain text form outside of HSMs.

6.2.7 Private key storage on cryptographic module

CASTLE CA Private Keys are stored on HSMs meeting the requirements stated in Section 6.2.1.

6.2.8 Activating Private Keys

CASTLE CA Private Keys are always stored on HSMs and activated using the mechanisms provided by the HSM manufacturer.

6.2.9 Deactivating Private Keys

CASTLE CA Private Keys are always stored on HSMs and deactivated using the mechanisms provided by the HSM manufacturer.

6.2.10 Destroying Private Keys

CASTLE CA Private Keys are destroyed by Trusted Contributors using a FIPS 140-2 (or higher) validated zeroize method provided by the HSMs storing the keys. Physical destruction of the HSM is not required.

See the Terms of Service Agreement for information regarding Subscriber private key destruction.

6.2.11 Cryptographic Module Capabilities

See Section 6.2.1.

6.3 Other aspects of key pair management

6.3.1 Public key archival

See Section 5.5.

6.3.2 Certificate operational periods and key pair usage periods

The validity periods of CASTLE Root CA, Subordinate CA, and Subscriber Certificates are profiled in Section 7 of this document.

CASTLE Root and Subordinate CA key pairs have lifetimes corresponding to their certificates. Subscriber key pairs may be re-used indefinitely provided that there is no suspicion or confirmation of Private Key compromise.

6.4 Activation data

6.4.1 Activation data generation and installation

No stipulation.

6.4.2 Activation data protection

Activation data is protected from unauthorized disclosure via a combination of physical and logical means.

6.4.3 Other aspects of activation data

No stipulation.

6.5 Computer security controls

6.5.1 Specific computer security technical requirements

CASTLE CA infrastructure and systems are appropriately secured in order to protect CA software and data from unauthorized access or modification. Access to systems is secured via multi-factor authentication whenever possible. Security updates are applied in a timely fashion. Vulnerability scans are run regularly.

6.5.2 Computer security rating

No stipulation.

6.6 Life cycle technical controls

6.6.1 System development controls

CASTLE CA has developed policies and procedures to effectively manage the acquisition and development of its CA systems.

CASTLE CA hardware and software is dedicated solely to performing CA functions.

Vendor selection includes an evaluation of reputation in the market, ability to deliver a quality product, vulnerability history, and the likelihood of remaining viable in the future. Physical product deliveries are received by Trusted Contributors and inspected for evidence of tampering. HSMs are shipped in tamper-evident packaging and tamper bag serial numbers are confirmed with the vendor upon reception.

CASTLE CA maintains a testing environment separate from the production environment. The testing environment reasonably emulates the production environment but does not have access to CASTLE CA Private Keys used in trusted certificates. The purpose of this testing environment is to allow extensive but safe testing of software and systems that are or will be deployed to the CA production environment.

CASTLE CA has developed and maintains appropriate change control policies and procedures to be followed any time CA systems are modified. Changes to CASTLE CA systems require review by qualified Trusted Personnel who are different from the person requesting the change. Change requests are documented, as are any subsequent required reviews or approvals.

When CASTLE CA develops software to be used in CA operations, software development policies are put into place and methodologies are followed in order to ensure software quality and integrity. This always includes a requirement for peer review of code changes. Code commit privileges are granted only to qualified and trusted contributors. Nobody with the ability to deploy software to CASTLE PKI systems (e.g. Systems Administrators) may have the ability to unilaterally commit code to core CA software. The reverse is also true.

6.6.2 Security management controls

No stipulation.

6.6.3 Life cycle security controls

No stipulation.

6.7 Network security controls

CASTLE CA implements reasonable network security safeguards and controls to prevent unauthorized access to CA systems and infrastructure. CASTLE CA complies with the CA/Browser Forum’s Network and Certificate System Security Requirements.

CASTLE CA’s network is multi-tiered and utilizes the principle of defense in depth.

Firewalls and other critical CA systems are configured based on a necessary-traffic-only allowlisting policy whenever possible.

6.8 Time-stamping

See Section 5.5.5.

7. CERTIFICATE, CRL, AND OCSP PROFILES

7.1 Certificate profile

All fields are as specified in RFC 5280, including fields and extensions not specifically mentioned. Extensions are not marked critical unless specifically described here as critical.

Root CA Certificate

Field or extension	Value
Serial Number	Must be unique, with 64 bits of output from a CSPRNG
Issuer Distinguished Name	C=ES, O=CASTLE Platform, CN=CASTLE Root R<t><n> CA where t is the type of root authority (RSA, ECDSA) and n is an integer representing the instance of the Root CA Certificate. For example, CASTLE Root RR1, CASTLE Root RR2, etc.
Subject Distinguished Name	Same as Issuer DN
Validity Period	Up to 30 years
Basic Constraints	Critical. cA=True, pathLength constraint absent
Key Usage	Critical. keyCertSign, cRLSign

Subordinate CA Certificate

Field or extension	Value
Serial Number	Must be unique, with 64 bits of output from a CSPRNG
Issuer Distinguished Name	Derived from Issuer certificate
Subject Distinguished Name	C=ES, O=CASTLE Platform, CN=I<t><p><n> where t is the type of authority, p is the purpose and n is an integer representing the instance of the Subordinate CA Certificate.
Validity Period	Up to 10 years
Basic Constraints	Critical. cA=True, pathLength constraint 0
Key Usage	Critical. keyCertSign, cRLSign, digitalSignature
Extended Key Usage	TLS Server Authentication, TLS Client Authentication
Authority Information Access	Contains CA Issuers URL (and optionally an OCSP URL). URLs vary based on Issuer.
CRL Distribution Points	Contains a CRL URL. URL varies based on Issuer.

DV-SSL Subscriber Certificate

Field or extension	Value
Serial Number	Must be unique, with 64 bits of output from a CSPRNG
Issuer Distinguished Name	Derived from Issuer certificate
Subject Distinguished Name	CN=one of the values from the Subject Alternative Name extension
Validity Period	Up to 365 days
Basic Constraints	Critical. cA=False
Key Usage	Critical. digitalSignature, nonRepudiation, keyEncipherment, keyAgreement
Extended Key Usage	E-mail Protection
Authority Information Access	Contains CA Issuers URL and OCSP URL. URLs vary based on Issuer.
Subject Public Key	RSA with modulus between 2048 and 4096, inclusive; or namedCurve P-256; or namedCurve P-384
Subject Alternative Name	A sequence of 1 to 100 RFC822Name

Root OCSP Signing Certificate

Signed by a Root CA Certificate, these Certificates may sign OCSP responses for Subordinate CA Certificates.

Field or extension	Value
Serial Number	Must be unique, with 64 bits of output from a CSPRNG
Issuer Distinguished Name	Derived from Issuer
Subject Distinguished Name	C=US, O=CASTLE Platform, CN=IRO<n> where n is an integer depending on the Issuer
Validity Period	Up to 10 years
Basic Constraints	Critical. cA=False
Key Usage	Critical. digitalSignature
Extended Key Usage	Critical. OCSPSigning
No Check	Present

7.1.1 Version number(s)

All certificates use X.509 version 3.

7.1.2 Certificate Content and Extensions; Application of RFC 5280

See Section 7.1.

7.1.3 Algorithm object identifiers

7.1.3.1 SubjectPublicKeyInfo

No stipulation.

7.1.3.2 Signature AlgorithmIdentifier

Name	Object identifier
sha256WithRSAEncryption	1.2.840.113549.1.1.11
ecdsa-with-SHA384	1.2.840.10045.4.3.3

7.1.4 Name forms

CASTLE CA does not issue Subscriber Certificates containing the subject:organizationName, subject:givenName, subject:surname, subject:streetAddress, subject:localityName, subject:stateOrProvinceName, subject:postalCode, subject:countryName, or subject:organizationalUnitName fields. The subject:organizationName and subject:countryName fields may be present in our Root CA, Subordinate CA, and other operational certificates.

7.1.5 Name constraints

No stipulation.

7.1.6 Certificate policy object identifier

See Section 7.1.

7.1.7 Usage of Policy Constraints extension

Not applicable.

7.1.8 Policy qualifiers syntax and semantics

See Section 7.1.

7.1.9 Processing semantics for the critical Certificate Policies extension

Not applicable.

7.2 CRL profile

For the status of Subordinate CA Certificates:

Field or Extension	Value
Version	V2
Signature Algorithm	sha256WithRSAEncryption or ecdsa-with-SHA384
ThisUpdate	The date and time when the Certificate revocation list validity begins
NextUpdate	Up to ThisUpdate + 1 year
RevokedCertificates	Contains: userCertificate, revocationDate, reasonCode
CRLnumber	The serial number of this CRL in an incrementally increasing sequence of CRLs.

7.2.1 Version number(s)

See Section 7.2.

7.2.2 CRL and CRL entry extensions

No stipulation.

7.3 OCSP profile

CASTLE OCSP responders implement the RFC 5019 profile of RFC 6960.

7.3.1 Version number(s)

No stipulation.

7.3.2 OCSP extensions

No stipulation.

8. COMPLIANCE AUDIT AND OTHER ASSESSMENTS

8.1 Frequency or circumstances of assessment

See Section 8.7 for information about the frequency of self-audits.

8.2 Identity/qualifications of assessor

No stipulation.

8.3 Assessor’s relationship to assessed entity

No stipulation.

8.4 Topics covered by assessment

No stipulation.

8.5 Actions taken as a result of deficiency

No stipulation.

8.6 Communication of results

Audit results are reported to the CASTLE PMA and any other entity entitled to the results by law, regulation, or agreement. This includes a number of Web user agent (i.e. browser) root programs.

CASTLE CA is not required to publicly disclose any audit finding that does not impact the overall audit opinion.

8.7 Self-Audits

CASTLE CA performs an anual internal audit. The sample is randomly selected. Results are saved and provided to auditors upon request.

9. OTHER BUSINESS AND LEGAL MATTERS

9.1 Fees

9.1.1 Certificate issuance or renewal fees

CASTLE CA does not charge any fees for certificate issuance or renewal.

9.1.2 Certificate access fees

No stipulation.

9.1.3 Revocation or status information access fees

CASTLE CA does not charge any fees for certificate revocation or for checking the validity status of an issued certificate using a CRL or OSCP.

9.1.4 Fees for other services

No stipulation.

9.1.5 Refund policy

CASTLE CA collects no fees, and so provides no refunds.

9.2 Financial responsibility

9.2.1 Insurance coverage

No stipulation.

9.2.2 Other assets

No stipulation.

9.2.3 Insurance or warranty coverage for end-entities

No stipulation.

9.3 Confidentiality of business information

9.3.1 Scope of confidential information

No stipulation.

9.3.2 Information not within the scope of confidential information

No stipulation.

9.3.3 Responsibility to protect confidential information

CASTLE employees, agents, and contractors are responsible for protecting confidential information and are bound by CASTLE CA’s policies with respect to the treatment of confidential information or are contractually obligated to do so. Employees receive training on how to handle confidential information.

9.4 Privacy of personal information

9.4.1 Privacy plan

CASTLE CA follows the privacy policy posted on its website (https://acme.castle.cloud/legal/) when handling personal information.

9.4.2 Information treated as private

The privacy policy posted on CASTLE’s website (https://acme.castle.cloud/legal/) identifies information that CASTLE CA treats as private.

9.4.3 Information not deemed private

The privacy policy posted on CASTLE’s website (https://acme.castle.cloud/legal/) identifies information that CASTLE CA does not treat as private.

9.4.4 Responsibility to protect private information

CASTLE employees and contractors are subject to policies or contractual obligations requiring them to comply with CASTLE CA’s privacy policy (https://acme.castle.cloud/legal/) or contractual obligations at least as protective of private information as CASTLE CA’s privacy policy.

9.4.5 Notice and consent to use private information

CASTLE CA follows the privacy policy posted on its website (https://acme.castle.cloud/legal/) when using personal information.

9.4.6 Disclosure pursuant to judicial or administrative process

CASTLE CA may disclose personal information if compelled to do so by court order or other compulsory legal process, provided that CASTLE CA will oppose such disclosure with all legal and technical tools reasonably available to CASTLE CA.

9.4.7 Other information disclosure circumstances

CASTLE CA may disclose personal information under other circumstances that are described in the privacy policy posted on its website (https://acme.castle.cloud/legal/).

9.5 Intellectual property rights

CASTLE CA and/or its business partners own the intellectual property rights in CASTLE CA’s services, including the certificates, trademarks used in providing the services, and this CPS. Certificate and revocation information are the property of CASTLE. CASTLE grants permission to reproduce and distribute certificates on a non-exclusive and royalty-free basis, provided that they are reproduced and distributed in full. Private Keys and Public Keys remain the property of the Subscribers who rightfully hold them.

Notwithstanding the foregoing, third party software (including open source software) used by CASTLE CA to provide its services is licensed, not owned, by CASTLE CA.

9.6 Representations and warranties

9.6.1 CA representations and warranties

Except as expressly stated in this CPS or in a separate agreement with a Subscriber, CASTLE CA does not make any representations or warranties regarding its products or services. CASTLE CA represents and warrants, to the extent specified in this CPS, that:

1. CASTLE CA complies, in all material aspects, with the CASTLE CP and this CPS,
2. CASTLE CA publishes and updates CRLs and OCSP responses on a regular basis,
3. All certificates issued under this CPS will be verified in accordance with this CPS and meet the minimum requirements found herein and in the CAB Forum Baseline Requirements, and
4. CASTLE CA will maintain a repository of public information on its website.

9.6.2 RA representations and warranties

CASTLE CA does not use RA services from third parties.

9.6.3 Subscriber representations and warranties

1. Each Subscriber warrants to CASTLE CA and the public-at-large that Subscriber is the legitimate owner of the email address that is, or is going to be, the subject of the CASTLE certificate issued to Subscriber, or that Subscriber is the duly authorized agent of such owner.
2. Each Subscriber warrants to CASTLE CA and the public-at-large that either (a) Subscriber did not obtain control of such email address as the result of a seizure of such email address, or (b) such email address had no ongoing lawful uses at the time of such seizure.
3. Each Subscriber warrants that all information in the CASTLE certificate issued to Subscriber regarding Subscriber or its email address is accurate, current, reliable, complete, and not misleading.
4. Each Subscriber warrants that all information provided by Subscriber to CASTLE CA is accurate, current, complete, reliable, complete, and not misleading.
5. Each Subscriber warrants that Subscriber rightfully holds the Private Key corresponding to the Public Key listed in the CASTLE certificate issued to Subscriber.
6. Each Subscriber warrants that Subscriber has taken all appropriate, reasonable, and necessary steps to secure and keep Subscriber’s Private Key secret.
7. Each Subscriber acknowledges and accepts that CASTLE CA is entitled to revoke Subscriber’s CASTLE certificates immediately if the Subscriber violates the terms of the Subscriber Agreement or if CASTLE CA discovers that any of Subscriber’s CASTLE certificates are being used to enable criminal activities such as phishing attacks, fraud, or the distribution of malware.

9.6.4 Relying party representations and warranties

Each Relying Party represents and warrants that, prior to relying on an CASTLE certificate, it:

1. Obtained sufficient knowledge on the use of digital certificates and PKI,
2. Studied the applicable limitations on the usage of certificates and agrees to CASTLE CA’s limitations on its liability related to the use of certificates,
3. Has read, understands, and agrees to this CPS,
4. Verified both the CASTLE certificate and the certificates in the certificate chain using the relevant CRL or OCSP,
5. Will not use an CASTLE certificate if the certificate has expired or been revoked, and
6. Will take all reasonable steps to minimize the risk associated with relying on a digital signature, including only relying on an CASTLE certificate after considering:

• Applicable law and the legal requirements for identification of a party, protection of the confidentiality or privacy of information, and enforceability of the transaction;
• The intended use of the certificate as listed in the certificate or this CPS,
• The data listed in the certificate,
• The economic value of the transaction or communication,
• The potential loss or damage that would be caused by an erroneous identification or a loss of confidentiality or privacy of information in the application, transaction, or communication,
• The Relying Party’s previous course of dealing with the Subscriber,
• The Relying Party’s understanding of trade, including experience with computer-based methods of trade, and
• Any other indicia of reliability or unreliability pertaining to the Subscriber and/or the application, communication, or transaction.

Any unauthorized reliance on a certificate is at a party’s own risk.

9.6.5 Representations and warranties of other participants

No stipulation.

9.7 Disclaimers of warranties

CASTLE certificates and services are provided “as-is.” CASTLE CA disclaims any and all warranties of any type, whether express or implied, including and without limitation any implied warranty of title, non-infringement, merchantability, or fitness for a particular purpose, in connection with any CASTLE CA service or CASTLE certificate.

9.8 Limitations of liability

CASTLE CA does not accept any liability for any loss, harm, claim, or attorney’s fees in connection with any certificates. CASTLE CA will not be liable for any damages, attorney’s fees, or recovery, regardless of whether such damages are direct, consequential, indirect, incidental, special, exemplary, punitive, or compensatory, even if CASTLE CA has been advised of the possibility of such damages. This limitation on liability applies irrespective of the theory of liability, i.e., whether the theory of liability is based upon contract, warranty, indemnification, contribution, tort, equity, statute or regulation, common law, or any other source of law, standard of care, category of claim, notion of fault or responsibility, or theory of recovery. This disclaimer is intended to be construed to the fullest extent allowed by applicable law.

Without waiving or limiting the foregoing in any way, CASTLE CA does not make, and CASTLE CA expressly disclaims, any warranty regarding its right to use any technology, invention, technical design, process, or business method used in either issuing certificates or providing any of CASTLE’s services. Each Subscriber affirmatively and expressly waives the right to hold CASTLE CA responsible in any way, or seek indemnification against CASTLE CA, for any infringement of intellectual property rights, including patent, trademark, trade secret, or copyright.

9.9 Indemnities

9.9.1 Indemnification by CASTLE CA

The CA does not provide any indemnification except as described in Section 9.9.1 of the Certificate Policy.

9.9.2 Indemnification by Subscribers

Each Subscriber will indemnify and hold harmless CASTLE CA and its directors, officers, employees, agents, and affiliates from any and all liabilities, claims, demands, damages, losses, costs, and expenses, including attorneys’ fees, arising out of or related to: (i) any misrepresentation or omission of material fact by Subscriber to CASTLE CA, irrespective of whether such misrepresentation or omission was intentional, (ii) Subscriber’s violation of the Terms of Service Agreement, (iii) any compromise or unauthorized use of an CASTLE certificate or corresponding Private Key, or (iv) Subscriber’s misuse of an CASTLE certificate. If applicable law prohibits Subscriber from providing indemnification for another party’s negligence or acts, such restriction, or any other restriction required by law for this indemnification provision to be enforceable, shall be deemed to be part of this indemnification provision.

9.9.3 Indemnification by Relying Parties

To the extent permitted by law, each Relying Party shall indemnify CASTLE CA, its partners, and any cross-signed entities, and their respective directors, officers, employees, agents, and contractors against any loss, damage, or expense, including reasonable attorney’s fees, related to the Relying Party’s (i) breach of any service terms applicable to the services provided by CASTLE CA or its affiliates and used by the Relying Party, this CPS, or applicable law; (ii) unreasonable reliance on a certificate; or (iii) failure to check the certificate’s status prior to use.

9.10 Term and termination

9.10.1 Term

This CPS and any amendments to this CPS are effective when published to the CASTLE CA online repository and remain in effect until replaced with a newer version.

9.10.2 Termination

This CPS and any amendments remain in effect until replaced with a newer version.

9.10.3 Effect of termination and survival

CASTLE CA will communicate the conditions and effect of this CPS’s termination via the CASTLE CA Repository. The communication will specify which provisions survive termination. At a minimum, all responsibilities related to protecting confidential information will survive termination. All Subscriber Agreements remain effective until the certificate is revoked or expired, even if this CPS terminates.

9.11 Individual notices and communications with participants

CASTLE CA accepts notices related to this CPS at the locations specified in Section 1.5.2 of this CPS. Notices are deemed effective after the sender receives a valid and digitally signed acknowledgment of receipt from CASTLE CA. If an acknowledgement of receipt is not received within five days, the sender must resend the notice in paper form to the street address specified in Section 1.5.2 of this CPS using either a courier service that confirms delivery or via certified or registered mail with postage prepaid and return receipt requested. CASTLE CA may allow other forms of notice in its Subscriber Agreements.

9.12 Amendments

9.12.1 Procedure for amendment

This CPS is reviewed at least annually and may be reviewed more frequently. Amendments are made by posting an updated version of the CPS to the online repository. Controls are in place that are designed to reasonably ensure that this CPS is not amended and published without the prior authorization of the CASTLE PMA.

9.12.2 Notification mechanism and period

CASTLE CA posts CPS revisions to its Repository. CASTLE CA does not guarantee or set a notice-and-comment period and may make changes to this CPS without notice.

9.12.3 Circumstances under which OID must be changed

The CASTLE PMA is solely responsible for determining whether an amendment to the CPS requires an OID change.

9.13 Dispute resolution provisions

Any claim, suit or proceeding arising out of this CPS or any CASTLE product or service must be brought in a state court located in Barcelona, Spain. CASTLE CA may seek injunctive or other relief in any state, federal, or national court of competent jurisdiction for any actual or alleged infringement of its, its affiliates, or any third party’s intellectual property or other proprietary rights.

9.14 Governing law

The laws of the state of Spain, govern the interpretation, construction, and enforcement of this CPS and all proceedings related to CASTLE products and services, including tort claims, without regard to any conflicts of law principles. The United Nations Convention for the International Sale of Goods does not apply to this CPS.

9.15 Compliance with applicable law

This CPS is subject to all applicable laws and regulations, including Spain restrictions on the export of software and cryptography products.

9.16 Miscellaneous provisions

9.16.1 Entire agreement

CASTLE CA requires each party using its products and services to enter into an agreement that delineates the terms associated with the product or service. If an agreement has provisions that differ from this CPS, then the agreement with that party controls, but solely with respect to that party. Third parties may not rely on or bring action to enforce such agreement.

9.16.2 Assignment

Any entities operating under this CPS may not assign their rights or obligations without the prior written consent of CASTLE CA. Unless specified otherwise in a contract with a party, CASTLE CA does not provide notice of assignment.

9.16.3 Severability

If any provision of this CPS is held invalid or unenforceable by a competent court or tribunal, the remainder of the CPS will remain valid and enforceable. Each provision of this CPS that provides for a limitation of liability, disclaimer of a warranty, or an exclusion of damages is severable and independent of any other provision.

9.16.4 Enforcement (attorneys’ fees and waiver of rights)

CASTLE CA may seek indemnification and attorneys’ fees from a party for damages, losses, and expenses related to that party’s conduct. CASTLE CA’s failure to enforce a provision of this CPS does not waive CASTLE CA’s right to enforce the same provision later or right to enforce any other provision of this CPS. To be effective, waivers must be in writing and signed by CASTLE CA.

9.16.5 Force Majeure

CASTLE CA is not liable for any delay or failure to perform an obligation under this CPS to the extent that the delay or failure is caused by an occurrence beyond CASTLE CA’s reasonable control. The operation of the Internet is beyond CASTLE CA’s reasonable control.

9.17 Other provisions

No stipulation.