Digital Certificates and Signature Trust Chains

Ang tuktok ng trust chain. Ang root CA certificates ay self-signed at pre-installed sa mga sistema ng operasyon at mga browser. Ito ang pinakasalitang pinagmulan ng trust — kung ka sumasampalataya sa root, ka sumasampalataya sa lahat ng inilabas nito.

Ang root CAs ay bihira ang direktang inilabas ng end-user certificates. Sa halip, sila ay inilabas ng intermediate CA certificates, na sa kabilang banda ay inilabas ang end-user certificates. Ito ay nagdagdag ng isang layer ng seguridad — kung ang intermediate ay napinsala, lamang ito ang kailangang buwisganan, hindi ang root.

Ang certificate na inilabas sa isang tao o organisasyon para sa pag-sign o pag-verify. Kapag pinag-verify ang signature, ang verifier ay sinusundan ang chain: end-user → intermediate → root. Kung lahat ng links ay validong at ang root ay sumasampalataya, ang signature ay sumasampalataya.

RSA 2048-bit is the minimum accepted by NIST SP 800-131A for signatures beyond 2030. ECC P-256 provides equivalent security with smaller key sizes (256-bit) and faster signing — 3x faster than RSA 2048. eSign.AI uses ECC P-256 by default and RSA 3072 for regulatory environments that require RSA.

CA/Browser Forum baseline: 398 days max for TLS certificates. For eSignature certificates: EU QTSP certificates are typically valid 2-5 years. China CA certificates: 3 years. Singapore Netrust: 2-3 years. After expiry, the signature remains valid but LTV data must be embedded for independent verification.

Root CA → Intermediate CA → Signing certificate is the standard 3-level chain. Some QTSPs use 4 levels (Root → Country → CA → Signing). Verification requires all intermediate certificates to be available — if a chain certificate is missing, the signature shows as "not verified" in Adobe Reader.

OCSP (Online Certificate Status Protocol) checks revocation in real-time, typically 50-200 ms latency. CRL (Certificate Revocation List) downloads the full list (50 KB - 5 MB) and caches it. PAdES B-LT embeds both OCSP responses and CRLs at signing time, ensuring verification works even if the CA goes offline.

Certificate issuance follows a standard flow: the subscriber submits an application with identity documents, the CA verifies identity (in person, via eKYC, or through a trusted agent), the CA issues the certificate with a defined validity period, and the subscriber receives a private key stored on a secure medium (HSM, token, or cloud key vault). Under China's Electronic Signature Law Article 15, CA providers must obtain a licence from the SCA. Under eIDAS, QTSPs must be listed on the EU Trusted List and audited against ETSI standards.

Certificates may be revoked before expiry due to key compromise, CA compromise, subscriber identity fraud, or organisational change (merger, dissolution). Revocation information is published via CRL (Certificate Revocation List) and/or OCSP (Online Certificate Status Protocol). PAdES B-LT and B-LTA signatures embed revocation data at signing time, so verification works even years later when the CA may no longer operate. Without embedded revocation data, a signature becomes unverifiable after certificate expiry — a common failure in legacy eSignature implementations.

Enterprise signing programmes should plan certificate renewal 60-90 days before expiry. For sealed documents (regulatory filings, compliance certificates), renewal must happen before expiry to maintain a continuous chain of trust. China's SCA-licensed CAs typically issue 3-year certificates; EU QTSPs issue 2-5 year certificates. eSign.AI manages renewal automatically for cloud-based certificates and sends reminders for subscriber-managed certificates.