Signing Policy
This policy describes how CertAttestor creates, protects and verifies the digital signatures on the credentials and documents issued through it, what those signatures attest to, and how issued credentials are revoked. It applies to every credential and signed document produced by the service and its registered issuers.
1. What a signature attests — and what it does not
A signature demonstrates two things: that a credential was issued by a registered, vetted issuer, and that its contents have not been altered since issue. Any change to a signed credential — even a single character — causes verification to fail.
A signature is not a legal notarization and does not by itself carry statutory notarial effect. The service is not a government-accredited certificate authority, and the document-signing and employee certificates it issues are not government-qualified certificates (such as the Philippine PNPKI/DICT, eIDAS qualified signatures, or Adobe AATL). They establish authenticity and integrity within the service’s own trust domain and for anyone who chooses to trust the issuer.
2. Issuer registration and vetting
Organizations cannot issue credentials until they have been vetted and approved. Vetting is performed by a Registration Officer whose role is separate from certificate issuance, following a documented checklist that confirms the organization’s identity, the applicant’s authority to act for it, contact details, and domain ownership.
Each decision, the verification method used, and the officer responsible are recorded to a tamper-evident audit trail. Only the method and type of evidence are retained; identity-document numbers are not stored.
3. Signing keys and algorithms
Credentials are signed with ECDSA on the NIST P-256 curve using SHA-256, over a canonical (deterministically ordered) representation of the credential’s fields, so that identical data always produces an identical signature input.
Each issuing organization holds its own independent signing key, and a credential verifies only against the key of the organization that issued it. The platform’s own key may be held in a hardware-backed key-management service from which it cannot be exported. Private keys held on the platform are encrypted at rest.
Documents may additionally be signed using the PAdES standard with an RSA key, and organizations on the Pro plan may issue personal signing certificates to their employees from a company signing authority. These document and employee certificates are rooted in the issuing organization, not in a public trust program.
4. Certificate issuance
Every credential is signed at the moment it is issued. The signature covers the holder, the credential, the issuer, the issue and expiry dates, and any line-item detail (such as a transcript) included with it. The signed record is stored in the register.
5. Notarization
On a regular schedule, the fingerprints of newly issued credentials are combined into a single Merkle-tree root and published, so that anyone can confirm the records existed and were unaltered as of that time. Organizations on the Pro plan may additionally anchor these roots on the Base public blockchain as an independent timestamp.
Notarization proves existence and integrity at a point in time; it does not determine whether a credential is currently valid — that is governed by revocation.
6. Revocation
An issuer may revoke a credential at any time. Revocation takes effect immediately in the live register, which is the authoritative, real-time source of a credential’s current status.
Revoked credentials are also placed in a Certificate Revocation Tree whose root is notarized, and the complete, authenticated revocation set is published so that anyone can independently confirm whether a credential has been revoked. A credential is shown as valid only when its signature is valid, it has not expired, the live register reports it active, and it is cryptographically absent from the revocation set — and the public verification page checks both the issuance and the revocation proof in the visitor’s own browser before displaying a valid result.
7. Verification
Anyone can verify a credential without an account, by entering its number or scanning its QR code on the verification page. The signature, the notarized issuance proof and the revocation status are each checkable independently, and the published revocation set can be recomputed to confirm it matches the notarized root.
8. Key lifecycle and limitations
Automated rotation of issuer signing keys is not currently performed; regenerating an issuer key would invalidate credentials signed with the previous key. Because document-signing and employee certificates are rooted in the issuing organization rather than a public trust program, a PDF reader may report the signer’s identity as unknown until the recipient chooses to trust the issuing organization’s certificate.
The service supports notarization-facility workflows but is not itself a notary. Legal electronic notarization requires a commissioned electronic notary and, in the Philippines, a Supreme Court–accredited facility.
9. Data protection
Public blockchain anchoring publishes only cryptographic hashes and never personal data. Identity-verification records retain the method and type of evidence, not identity-document numbers.
10. Changes to this policy
This policy may be updated as practices evolve. Material changes will be reflected in the version and effective date shown below.
CertAttestor Signing Policy — version 1.0, effective August 12, 2026.