• Roots
• NewRootsTaskForce
• NewCPSConditions

---

Czech |English | Deutsch | ...

---

CPS Rules and Conditions for issued certificates - 202601

Algorithms

SHA1 (= SHA) usage is deprecated and will only be use only where required by standards as RFCs. Since 2025-08, hash algorithms can be chosen in SHA2 hash function group (SHA-224, SHA-256 /preferred/, SHA-384, SHA-512).

• CAcert currently (2025-10) supports the RSA and the ECC algorithms for X.509 keys.
• X.509 signing uses the SHA256 message digest algorithm. This should be upgraded at least to SHA2.
• OpenPGP Signing uses RSA signing over RSA and DSA keys.

Hash

The SHA1 algorithm will be probably replaced by a more sofisticated successor in the future. In the year 2025, it can be SHA2 hash function group (SHA-224, SHA-256 /preferred/, SHA-384, SHA-512).

• SHA1 - 256, deprecated since 2025-08
• SHA2 - 256, 384, 512
• SHA3 - 256, 384, 512

• (source: https://www.keylength.com/en/8/)

Fingerprints

• Fingerprint depends on the used hash algorithm; a certificate's TBSCertificate structure can be hashed/fingerprinted using any hash algorithm.
• Fingerprint field can be longer or shorter for other algorithms and is not directly included in the certificate.

Algorithms and their impact to fields in CAcert certificates

The following table states the fields of all types of CAcert certificates which are, or may be, influenced by the selection of alhorithms used. The recently used algorithms and fields are also listed.

• *)	CA/Browser Forum recommendation on cert serial numbers
  **)	length may vary according the algorithm used, see above
  ***)	RNG = Random Number Generator
  ++)	ASN1 OID: secp521r1, NIST CURVE: P-521. Public Key Parameters: ECDSA_P521
  +++)	ASN1 OID: secp384r1, NIST CURVE: P-384, Public Key Parameters: ECDSA_P384

Elliptic Curve Cryptohraphy (ECC)

• Importance:

• Efficiency: ECC provides the same security as RSA with much shorter keys (e.g., 256-bit ECC ≈ 3072-bit RSA).

• Wide support: Used in TLS, SSH, Bitcoin, Ethereum, digital signatures, etc.

ECDSA (Elliptic Curve Digital Signature Algorithm)

An algorithm for creating and verifying digital signatures based on elliptic curves. It uses SHA-256 – a hash function from the SHA-2 group that creates a 256-bit fingerprint of the message.

• Procedure - a combined signature mechanism:
• The message is first hashed using SHA-256.

• The output (hash) is then signed using ECDSA with a private key.

• The recipient verifies the signature using a public key and the same hashing algorithm (SHA-256).
• Commonly used in:
• TLS/SSL certificates (e.g., in HTTPS).
• Blockchain technologies (e.g., Bitcoin, Ethereum).
• Digital certificates and signatures (e.g., X.509).

In X.509 certificates, this algorithm is often referred to as Signature Algorithm: ecdsa-with-SHA256

• Advantages:
• Higher security with shorter key lengths compared to RSA.
• More efficient computational requirements.
• Widely supported by modern systems.

ECDSA used in the CPS, Appendix B

"ECDSA_P521" is a generic designation for the use of the ECDSA algorithm with elliptic curve P-521 (or secp521r1).

• ECDSA = digital signature algorithm

• P-521 = elliptic curve with 521-bit security (defined by NIST, OID: 1.3.132.0.35)

• Together, they form a signature mechanism with extremely high security.

Formal name in standards: In X.509 certificates or TLS, this is often referred to as:

• Signature Algorithm: ecdsa-with-SHA512
• Public Key Algorithm: id-ecPublicKey
  • Named Curve: secp521r1 (or P-521)
• what means: ECDSA with SHA-512 (preferred in view of P-521 key length; or SHA-256|384) + P-521 curve

Using:

• Digital signatures in certificates with extreme security.
• Military, government institutions, long-term archiving.
• In TLS: e.g., TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 with the P-521 curve.

The standardized identifier

The id-ecPublicKey is a standardized identifier for public keys based on elliptic curves (Elliptic Curve Cryptography, ECC). It indicates that the public key is ECC type – i.e., it is neither RSA nor DSA, but is based on elliptic curve mathematics. This identifier is used in X.509 certificates, PKCS#8 key files, and other cryptographic standards.

OID (Object Identifier) corresponding to id-ecPublicKey is: 1.2.840.10045.2.1

• The public key contains:

• Curve (e.g., secp256r1, secp256k1, secp384r1, etc.)

• Point coordinates on the curve (x, y) that represent the public key.

An example of use in the certificate

• Public Key Algorithm: id-ecPublicKey
  • Public-Key: (256 bit) value: 04:3a:... (point coordinates)
  • ASN1 OID: prime256v1 (what is secp256r1)
  • NIST Curve: P-521

NIST Curve: <Name> is the official name of the elliptical curve defined by NIST (National Institute of Standards and Technology) in the document FIPS 186-4. Details:

• Name: P-521

• OID (Object Identifier): 1.3.132.0.35 (same as secp521r1)

• Bit length: 521 bits (prime field)

• Type: Curve over a prime field

• Definition:

  • Equation: y² = x³ − 3x + b (general form for NIST P-curves)
  • Parameter b is specific to P-521 (very long number, defined in FIPS 186-4)

The name P-521 (in NIST) corresponds secp521r1 (in SECG standard); both identifiers indicate the same curve. An example of practical use:

• TLS/SSL (e.g., in configurations with ecdh-x25519 or ecdh-secp521r1)
• X.509 certificates (if maximum security is required)
• Cryptographic libraries (OpenSSL, Bouncy Castle, etc.)
• Bit length: 521 bits → extremely high security
• For the highest security requirements

Expiration times

On April 14, 2025, the CA/Browser Forum passed a ballot to reduce SSL/TLS certificates to 47 day maximum term by March 15, 2029. (https://en.wikipedia.org/wiki/Certificate_authority#cite_note-44)

The certificate renewal is deprecated

Users are strongly encouraged NOT to renew expired certificates, thus to prefer issuing a new CSR with a new key pair for every certificate they need renew.

• This is extremely important for server certificates.

Revoking certificates

Expiration or renewal are not sufficient reasons to revoke a certificate. You shall not revoke a certificate if not required by a good reason as a key compromission.

If you revoke a certificate used for signature, even if it is expired, this means that the key pair was compromised at some time before the revocation. So, if you keep a document for a long time (and resign the document including the previous signatures), having one of the certificates revoked could lead to have doubts about the integrity of the document or the signatory.

CSR Minimum requirements

General

These rules are valid for Certificate Signing Requests (CSRs), which are generated by an utility, as OpenSSL, Kleopatra, or XCA. If an user uses the CAcert Web application, the CSR is generated properly.

• Key pair: a newly generated pair consisting of a private key and public key. Users must keep their private keys safely.

• Only the public key is a part of CSR.

• If the member selects SSO (Single Sign On ID) during submission of CSR: a version of SSO hash type: SHA1 is deprecated now (2025-08), so the SHA2 or SHA3 is now in use, until also obsoletes.

Person

The user can select the following items on the certificate generation page.

• The Email address of the user <RFC5322 in 3.4.1>. More Email addresses may be entered as Subject Alternate Names (SANs).

• The user's name following <RFC5322 in 3.4>. All strings contained in a CSR and a certificate should be coded as UTF-8.
  Note: RFC5280 verification is only mandated for subjectAltName, not for the subject field.
  Note for organizations: Even if RFC5280 does not require CN, it is a wip for OAP to state how this is done.

• The ability to sign documents or software with the certificate issued.
• The Single Sign-On (SSO) code: a hash of the random number, created with SHA2 hash function group (SHA-224, SHA-256 /preferred/, SHA-384, SHA-512)(2025-09) or following SHA versions.
• The ability to login to the user's account at CAcert.
• The hash algorithm used at certificate signing (issuing). Nowadays SHA-256, SHA-384, or SHA-512 are available.

Client

• The Internet FQDN address of the client: host name of the client computer

Server

• The Internet FQDN address of the server: host name of the server computer

The list of accepted TLD Registrars

This list is expected to be enlarged or modified as necessary. At 2025-8, the TLD list has as many as 1592 items. The most new top-level domains come from the total releasing of making TLD names; now a TLD can be practically anything, created using worldwide letter systems, e.g. .aaa, .bauhaus, .москва, .טעסט, or .電訊盈科.
The following list is then rather historical one. It contains domains of some countries, their registrars and policies.

Criteria for establishing and operating certification authorities (CA)

These criteria are primarily determined by:

1. Standards X.509 and PKI (Public Key Infrastructure)

• Technical specifications for certificate format and management.

2. National and international standards - E.g.:

• ETSI EN 319 411-1 and -2 (European standard for certification authorities and certificates)

• RFC 5280 (Internet Engineering Task Force - specification X.509 for certificates and CRLs)

• ISO/IEC 27001 (for security management systems)

3. Legal frameworks - E.g.:

• eIDAS regulation (EU) No 910/2014 - For European certification authorities that issue certificates for electronic identification and signatures.

• Electronic Signature Act (see "Electronic Signature Law")

4. Audit and certification schemes - For example:

• WebTrust / ETSI TS 102 042 - For auditing the CA

• CA/Browser Forum Baseline Requirements - For CAs whose certificates are to be accepted by browsers (e.g., Chrome, Firefox)

Where can I find details?

• ETSI (European Telecommunications Standards Institute): https://www.etsi.org

• CA/Browser Forum: https://cabforum.org

• eIDAS: https://ec.europa.eu/digital-building-blocks/wikis/display/EIDAS

Key criteria for TLS (Transport Layer Security) certificates

CA/Browser Forum Baseline Requirements - a set of rules that must be met by all certification authorities (CAs) whose certificates are to be accepted by browsers (Chrome, Firefox, Safari, Edge, etc.).

Basic criteria for TLS CAs (according to CA/Browser Forum Baseline Requirements v1.9.7, current as of 2026):

1. Identification and verification of the entity

• The identity of the applicant (domain, organization, individual) must be verified.
• For domains: verification via DNS, email, or HTTP file.
• For organizations: verification through official registers (e.g., commercial register).

2. Certificate issuance

• Maximum validity: 398 days (in effect from September 1, 2020).

• Must contain valid Subject Alternative Name (SAN).

• It must not contain any invalid or unverified domains.

3. Safety requirements

• Keys must be generated on the applicant's (or CA's) device with sufficient entropy.

• Minimum key length: 2048 bit RSA or equivalent (e.g. ECDSA P-256).

• The SHA-256 or higher hash algorithm must be used.

4. Revocation and CRL/OCSP

• CA must provide CRL (Certificate Revocation List) or OCSP (Online Certificate Status Protocol).

• Revocation must be performed within 24 hours after the compromise is detected.

5. Audit a compliance

• The CA must be regularly audited according to WebTrust or ETSI TS 102 042.

• The audit must be published and valid.

6. Legal and regional requirements

• In the EU: compliance with the eIDAS Regulation (if certificates are used for eIDAS-compatible services).

Where can I find official documents?

• CA/Browser Forum Baseline Requirements:

  • https://cabforum.org/baseline-requirements/

• WebTrust for CA:

  • https://www.webtrust.org

• eIDAS regulation (EU):

  • https://ec.europa.eu/digital-building-blocks/wikis/display/EIDAS

Electronic Signature Law

Europe

The e-IDAS (electronic identification and trust services, EU 910/2014) is an European regulation that harmonizes rules for:

• electronic identification
• electronic signatures
• electronic seals
• time stamps
• delivery services
• website verification

The aim is to ensure that electronic transactions have the same legal validity throughout the EU as paper documents and physical signatures.

Three levels of electronic signature

eIDAS defines three types of signatures:

The signatures created by certificates issued by CAcert are not qualified and so they cannot legally replace human signatures. They can work at 2nd level (AES).

These signatures do not fulfil the "Requirements for advanced electronic signatures" of the EU act e-IDAS, article 26.

U.S.A.

ESIGN Act (Electronic Signatures in Global and National Commerce Act)

An US federal law from 2000 that guarantees the legal validity of electronic signatures and electronic documents in commercial transactions, particularly in interstate and international trade. It is the basic legal framework that enabled the mass adoption of e-signatures in the US.

Main principles of the law

• An electronic signature has the same legal weight as a handwritten signature on paper.

• An electronic document has the same legal validity as a paper document.

Definition of electronic signature as:

"an electronic sound, symbol, or process... performed by a person with the intent to sign a document."

This includes clicking the "Sign" button, biometric signatures, stylus, PIN, etc.

Preservation of consumer rights

• The consumer must agree to the electronic form of the documents.

• They must have the option of obtaining the documents in paper form.
• They must be informed of the technical requirements (e.g., how to open the documents).

Integrity and preservation of documents

Electronic documents must be stored in such a way that they are accurate, accessible, and reproducible.

What ESIGN does not address

• Does not specify a particular e-signature technology.
• Does not require qualified certificates (unlike EU's e-IDAS).
• Does not address the identity of the signatory—this is left to service providers and practice.

Practical implications

• It has enabled the digitization of banking, insurance, real estate transactions, HR processes, and e-commerce.
• It is technologically neutral, so it easily adapts to new verification methods.

Comparison with the EU approach

The CAcert-made certificates could be used in theory, because the principle of qualified certificate doesn't exist here. Therefore, if CAcert disclaims responsibility for signatures based on its certificates, it is necessary to declare this fact clearly.

Australia (New South Wales & Other)

Electronic Transactions Act 1999 (ETA) is the federal framework, supplemented by individual states and territories with their own versions of the ETA.

Main principles

Electronic signatures are equivalent to handwritten signatures if they meet three conditions:

1. They identify the signatory and express their intention to sign the document.

2. They are reliable for the purpose in question, or their reliability can be proven by other means.

3. The other party agrees to the signature method used.

Exceptions

Some documents cannot be signed electronically (e.g., **wills, powers of attorney, certain real estate documents**).

New South Wales (NSW)

• New South Wales has its own Electronic Transactions Act 2000 (NSW), which is practically harmonized with the federal ETA.

• The principles are the same: identification, intent, reliability, consent.

Note: CAcert origins from NSW, so it followed the laws of that Australian state. After CAcert relocation to EU, the law addiction should be changed.

Singapore

Electronic Transactions Act 2010 (ETA) Singapore has a highly sophisticated and modern framework that also implements international standards (UNCITRAL).

Main principles

Electronic signatures are recognized as legally binding if:

1. The method used identifies the signatory and expresses their intention.

2. It is reasonably reliable for the purpose.

Resolution of signature types

• Electronic signature – any electronic expression of will.

• Secure electronic signature – a signature based on a certificate from a trusted certification authority; it has a stronger legal presumption of validity.

Other elements

ETA 2010 also implements:

• UNCITRAL Model Law on Electronic Transferable Records (e.g., electronic bills of exchange)

• Framework for certification authorities (Electronic Transactions (Certification Authority) Regulations 2010).

The legal systems of Australia and Singapore are compatible in that they are based on UNCITRAL models and recognize electronic signatures as equivalent to traditional signatures, provided they meet certain conditions.

The Commonwealth and States of Australia have passed various Electronic Transactions Acts that speak to digital signatures. In summary, these acts follow the "technology neutral" model and permit but do not regulate the use of digital signatures.

This especially means that the signatures created by certificates issued by CAcert are not in and of themselves legally binding human signatures, at least according to the laws of Australia. See CPS[1.4.3](#1.4.3.%20Unreliable%20Applications). However, certificates may play a part in larger signing applications. See CPSS[1.4.1](#1.4.1.%20Appropriate%20certificate%20uses) for "digital signing" certificates. These applications may impose significant obligations, risks and liabilities on the parties.

Comparison tables

Table 9.15.1.a - a brief comparison

Table 9.15.1.b - Legal Acts concerning e-signing - comparison for countries AU, EU, SGP, and USA

Post-quantum cryptography (PQC)

• (Cryptographic algorithms resistant against Quantum-computer break)
• (Research: AI)

Post-quantum cryptography (PQC) is concerned with the design of cryptographic algorithms that can withstand cryptanalytically relevant quantum computers. The goal is to replace the asymptotic methods commonly used today based on factorization or discrete logarithm, which are vulnerable due to Shore's algorithm.

Main classes of post-quantum algorithms

• Lattice-based
• Code-based
• Multivariate-based
• Hash-based
• Isogeny-based

These categories are based on various mathematical problems for which there are no efficient quantum solutions known by the time of standard cryptanalytic attacks.

NIST Standardization and the Main Candidates

NIST (National Institute of Standards and Technology) conducted a competition to standardize the first PQC algorithms. The winners include:

• CRYSTALS-Kyber (KEM)
• CRYSTALS-Dilithium (Digital Signature)
• FALCON (digital signature)
• SPHINCS+ (hash-based digital signature)

These algorithms were selected for their security level and performance in different application scenarios.

Quantum Key Distribution (QKD)

In addition to the purely mathematical approaches of PQC, there is Quantum Key Distribution (QKD) technology that uses the physical principles of quantum mechanics to provide secure transmission of encryption keys. Ideally, QKD is combined with PQC for maximum data protection against both present and future quantum attacks.

Next steps and related topics

• Research on quantum-resistant "hybrid" protocols combining classical and post-quantum elements.
• Monitoring developments in quantum computing and cryptanalytic research.
• Involvement in standardisation initiatives (IETF, ETSI) for the introduction of PQC in Internet protocols.

The article https://freemindtronic.com/quantum-computing-threats-rsa-aes/ states:

• Key takeaways:

  • RSA-2048 & AES-256 remain safe against quantum attacks through at least 2035.

  • Grover’s algorithm reduces AES-256 strength to 2¹²⁸ operations—still infeasible.
  • Shor’s algorithm would require ~20 million stable qubits to break RSA-2048.
  • HQC draft selected in March 2025, final standard expected by 2027.
  • Segmented key encryption by Jacques Gascuel offers immediate post-quantum defense.

• CategoryNewRootsTaskForce