#language en ## 20260125 AK ---- [[Roots/NewRootsTaskForce/NewCPSConditions/CZ|Czech]] |'''English''' | [[Roots/NewRootsTaskForce/NewCPSConditions/DE|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. ||Hash algorithm||Fingerprint field length|| ||SHA1||20 Bytes||40 hex. digits|| ||SHA256||32 B||64 h-d|| ||SHA384||48 B||96 h-d|| ||SHA512||64 B||128 h-d|| === 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. ||Certificate / cert. pattern||Field||Algorithm|| ||RSA tree|| || || ||Root CA cert||Serial # (16 B *)||RNG ***) + uniquity|| || ||Signature Algorithm (whole cert)||sha256WithRSAEncryption|| || ||Signature Algorithm Hash||sha256|| || ||RSA Public-Key (4096 bits)||RSAEncryption|| || ||Fingerprint (20 B **)||SHA1 hash|| ||Subordinate CA cert & pattern||Serial # (16 B *)||RNG ***) + uniquity|| || ||Signature Algorithm (whole cert)||sha256WithRSAEncryption|| || ||Signature Algorithm Hash||sha256|| || ||RSA Public-Key (3072 bits)||RSAEncryption|| || ||Fingerprint (20 B **)||SHA1 hash|| ||ECC tree|| || || ||Root CA cert||Serial # (16 B *)||RNG ***) + uniquity|| || ||Signature Algorithm (whole cert)||ecdsa-with-SHA256|| || ||Signature Algorithm Hash||sha256|| || ||Public-Key (521 bits) ++)||id-ecPublicKey|| || ||Fingerprint (32 B **)||sha256 Hash|| ||Subordinate CA cert & pattern||Serial # (16 B *)||RNG ***) + uniquity|| || ||Signature Algorithm (whole cert)||ecdsa-with-SHA256|| || ||Signature Algorithm Hash||sha256|| || ||Public-Key (384 bits) +++)||id-ecPublicKey|| || ||Fingerprint (32 B **)||sha256 Hash|| || *) ||[[https://cabforum.org/|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: 1. The message is first hashed using SHA-256. 1. The output (hash) is then signed using '''ECDSA''' with a private key. 1. 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: '''' 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) ||Certification type||Expiration time proposed in present||Expiration time in the future||Comment|| ||Root CA||20 years||max. 20 years ||may be reduced down to 5 years || ||Subordinate CAs: Person, Client, Server||5 years||max. 5 years ||may be reduced down to 2 years || ||User's (0-49 APs): Person, Client, Server||6 months||200 days (after 20260315), 100 days (after 20270315), 47 days (after 20290315)||Measure against the Quantum-computer breaking|| ||User's (50+ APs): Person, Client, Server||398 days||200 days (after 20260315), 100 days (after 20270315), 47 days (after 20290315)||Measure against the Quantum-computer breaking|| == 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 . More Email addresses may be entered as Subject Alternate Names (SANs). * The user's name following . All strings contained in a CSR and a certificate should be coded as UTF-8.<
>Note: [[https://datatracker.ietf.org/doc/html/rfc5280|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. || TLD suffix || Registrar || Policy || Comment || || .ac || http://www.nic.ac/ || http://www.nic.ac/pdf/AC-IDN-Policy.pdf || || || .ar || http://www.nic.ar/ || http://www.nic.ar/616.html |||| || .at || http://www.nic.at/ || http://www.nic.at/en/service/legal_information/registration_guidelines/ || [character list]http://www.nic.at/en/service/technical_information/idn/charset_converter/) || || .biz || http://www.neustarregistry.biz/ || http://www.neustarregistry.biz/products/idns || || || .br || http://registro.br/ || http://registro.br/faq/faq6.html || || || .cat || http://www.domini.cat/ || http://www.domini.cat/normativa/en_normativa_registre.html || || || .ch || http://www.switch.ch/id/ || http://www.switch.ch/id/terms/agb.html#anhang1 || || || .cl || http://www.nic.cl/ || http://www.nic.cl/CL-IDN-policy.html || || || .cn || http://www.cnnic.net.cn/ || http://www.faqs.org/rfcs/rfc3743.html || JET Guidelines || || .cz || https://www.nic.cz/ || https://www.nic.cz/page/314/pravidla-a-postupy/ || || || .de || http://www.denic.de/ || http://www.denic.de/en/richtlinien.html || || || .dk || http://www.dk-hostmaster.dk/ || http://www.dk-hostmaster.dk/index.html?id=151 || || || .es || https://www.nic.es/ || https://www.nic.es/media/2008-12/1228818323935.pdf || || || .fi || http://www.ficora.fi/ || http://www.ficora.fi/en/index/palvelut/fiverkkotunnukset/aakkostenkaytto.html || || || .gr || https://grweb.ics.forth.gr/english/index.html || https://grweb.ics.forth.gr/english/ENCharacterTable1.jsp || || || .hu || http://www.domain.hu/domain/ || http://www.domain.hu/domain/English/szabalyzat.html || section 2.1.2 || || .info || http://www.afilias.info/ || http://www.afilias.info/register/idn/ || || || .io || http://www.nic.io/ || http://www.nic.io/IO-IDN-Policy.pdf || || || .ir || https://www.nic.ir/ || https://www.nic.ir/IDN || || || .is || http://www.isnic.is/ || http://www.isnic.is/english/domain/rules.html || || || .jp || http://jprs.co.jp/ || http://www.iana.org/assignments/idn/jp-japanese.html || || || .kr || http://domain.nic.or.kr/ || http://www.faqs.org/rfcs/rfc3743.html || JET Guidelines || || .li || http://www.switch.ch/id/ || http://www.switch.ch/id/terms/agb.html#anhang1 || managed by .ch registry || || .lt || http://www.domreg.lt/public?pg=&sp=&loc=en || http://www.domreg.lt/public?pg=8A7FB6&sp=idn&loc=en || [character list]http://www.domreg.lt/static/doc/public/idn_symbols-en.pdf || || .museum || http://about.museum/ || http://about.museum/idn/idnpolicy.html || || || .no || http://www.norid.no/ || http://www.norid.no/domeneregistrering/veiviser.en.html || section 4 || || .org || http://www.pir.org/ || http://pir.org/PDFs/ORG-Extended-Characters-22-Jan-07.pdf || || || .pl || http://www.nask.pl/ || http://www.dns.pl/IDN/idn-registration-policy.txt || || || .pr || https://www.nic.pr/ || https://www.nic.pr/idn_rules.asp || || || .se || http://www.nic-se.se/ || http://www.iis.se/en/domaner/internationaliserad-doman-idn/ || [character list]http://www.iis.se/docs/teckentabell-03.pdf || || .sh || http://www.nic.sh/ || http://www.nic.sh/SH-IDN-Policy.pdf || || || .sk || https://sk-nic.sk/ || https://sk-nic.sk/en/documents/rules/ || || || .th || http://www.thnic.or.th/ || http://www.iana.org/assignments/idn/th-thai.html || || || .tm || http://www.nic.tm/ || http://www.nic.tm/TM-IDN-Policy.pdf || || || .tw || http://www.twnic.net.tw/ || http://www.faqs.org/rfcs/rfc3743.html || JET Guidelines || || .vn || http://www.vnnic.net.vn/ || http://www.vnnic.vn/english/5-6-300-2-[2-04-20071115.htm || [character list]http://vietunicode.sourceforge.net/tcvn6909.pdf || == 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: || '''Level''' || '''Description''' || '''Legal Force''' || || Electronic Signature || Basic Format (e. g. click on "Agree") || Low || || Assured Electronic Signature (AES) || Bound to Signer, detection of changes || Middle || || Qualified Electronic Signature (QES) || Created with a Qualified Certificate and QSCD || Equal to a Handwritten Signature across the EU || 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 === || '''Area''' || '''US – ESIGN''' || '''EU – eIDAS''' || || Legal force of e-signature || Equivalent to paper || Depends on type (SES, AES, QES) || || Technological neutrality || Very high || Partial || || Identity of the signatory || Undefined || Highly regulated (QES) || || Consumer protection || Mandatory consent and accessibility || Standard GDPR + eIDAS || 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. 1. They are '''reliable''' for the purpose in question, or their reliability can be proven by other means. 1. 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''. 1. 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 == || '''Criterion''' || '''Australia (federal ETA)''' || '''USA ESIGN''' || '''Singapore ETA 2010''' || '''EU eIDAS''' || || ''Equivalence of e-signature to handwritten signature'' || Yes, if 3 conditions are met || Yes || Yes, if 2 conditions are met || Yes, but only QES has automatic equivalence || || ''Types of signatures'' || Does not define formal levels || Wide spectrum of types || Electronic / Secure electronic signature || SES / AES / QES || || ''Certification authorities'' || No central list of trusted CAs || No list of trusted CAs || Regulated CAs under ETA + CA Regulations 2010 || Qualified providers are listed in the EU Trusted List || || ''Technical requirements'' || "Reliability appropriate to the purpose" || None || "Reasonable reliability" + special rules for secure signatures || Precisely defined requirements for AES and QES || || ''Exceptions'' || Wills, powers of attorney, certain deeds || None || Certain documents require secure signatures || Certain acts require QES (e.g., public services) || || ''International standards'' || Inspired by UNCITRAL || None/U.S. domestic || Implementation of UNCITRAL + ETR || Own European framework || Table 9.15.1.a - a brief comparison || '''State''' || '''Name of the Act''' || '''Year of adoption''' || '''Key requirements''' || '''Specifics / Notes''' || || ''Australia'' || '''Electronic Transactions Act 1999''' (ETA) + state/territory versions || 1999 || The signature must identify the signatory and express their intent; It must be "reasonably reliable" for the purpose; The other party must agree to the electronic form || There is no central list of "trusted providers"; technologies such as DocuSign are commonly accepted || || ''EU'' || '''eIDAS Regulation''' (Regulation (EU) No 910/2014), amended in 2024 || 2014 (effective from 2016), amendment in 2024 || Distinguishes between simple, advanced, and qualified e-signatures; Qualified signatures have the same legal weight as handwritten signatures; Requires certificates from qualified providers || Direct application in all member states; harmonization for cross-border transactions || || ''Singapore'' || '''Electronic Transactions Act (Cap. 88)''', originally 1998, amended in 2010 and 2021 || 1998 (ETA), major amendment in 2010 || An electronic signature must identify the person and express their intent; Distinguishes between "electronic" and "secure electronic" signatures (digital signatures with certificates); Certification authorities regulated by IMDA || Allows electronic signing of commercial documents; integration with Singpass for greater security || || ''USA'' || '''ESIGN Act''' (Electronic Signatures in Global and National Commerce Act) + *UETA* (Uniform Electronic Transactions Act) || ESIGN: 2000, UETA: 1999 || Electronic signatures have the same legal weight as handwritten signatures; ESIGN applies at the federal level (international and interstate commerce); UETA adopted by most states || ESIGN is the "default" federal law; UETA harmonizes state regulations || 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