Prson Network
← Back to home

Prson Identity CA: certificate policy and practice statement

Last updated: 3 November 2026

This legal document is provided in English.

1. Introduction

This document is the certificate policy and certification practice statement of the Prson Identity CA. It explains how Prson issues the certificates that people use to sign PDF documents with the Prson app, how those certificates are checked and revoked, and what anyone relying on a Prson signature should know. It follows the structure of RFC 3647, shortened for readability.

  • Document: Prson Identity CA certificate policy and practice statement, version 1.0, 3 November 2026.
  • Policy identifier: the certificates described here don't yet carry a certificate policy identifier (OID). The time-stamp tokens described in section 8 carry the time-stamping policy identifier 1.3.6.1.4.1.65908.2.1, under Yumankind OÜ's IANA Private Enterprise Number 65908.

What this is not. Prson's certificates support advanced electronic signatures under Article 26 of the EU eIDAS Regulation (EU) No 910/2014. They are not qualified certificates, and signatures made with them are not qualified electronic signatures. Prson is not a qualified trust service provider, is not on the EU Trusted Lists, and the phone is not a qualified signature creation device. The Prson Root CA is not on the Adobe Approved Trust List.

2. Who takes part

  • CA operator: Yumankind OÜ, Sepapaja 6, 15551 Tallinn, Estonia, registry code 16232402 ("Prson", "we"). We run every part of the CA described here.
  • Prson Root CA: the trust anchor. RSA 4096-bit key, self-signed, valid from 1 January 2024 to 1 January 2044. Its key is kept offline and only signs CA certificates.
  • Prson Issuing CA: the online CA under the root. RSA 3072-bit key, valid from 1 January 2024 to 1 January 2034. It issues people's signing certificates, Prson's own signing and time-stamping certificates, and the certificate revocation list (CRL).
  • Time-stamping unit: "Prson Timestamping Authority", certified by the Issuing CA. It adds an RFC 3161 time-stamp to each signature made by a person.
  • Subscribers: people who use the Prson app to sign PDFs, after the app has verified their passport or ID card from its chip.
  • Relying parties: anyone who receives a PDF signed with a Prson certificate and decides whether to rely on it, including organisations that ask people to sign through the Verifications API.

3. Certificates and what they may be used for

  • Personal signing certificates name a person and certify a key held on their phone. They may be used only to sign documents, mainly PDFs, through the Prson app.
  • The Prson Notary certificate certifies Prson's own company signing key. Prson uses it to sign PDFs it produces itself, such as the PDF that comes with an identity share. It doesn't name or speak for any person.
  • The time-stamping certificate may be used only to sign RFC 3161 time-stamp tokens.

No certificate under this CA may be used for website authentication, code signing, encryption, or as a qualified certificate. A personal signing certificate shows who held the key; it doesn't make the signer an agent of Prson or show that Prson approved the content of what they signed.

4. Where we publish

Compare the fingerprint above with the one your software shows before you trust the root.

5. How we check identity before issuing

  • Document check. The person reads the chip of their passport or ID card with the Prson app. Prson's server checks the chip data against the issuing country's signature, checks that the chip is genuine and not a copy, and checks that the document hasn't expired. This is verification level 5.
  • Face match (optional). At level 6, the person also passes a face match between a live selfie and the photo on the chip. The match runs on the person's phone, in the Prson app, and Prson checks the phone's attestation. Level 5 alone has no face match. The certificate shows which level applied (section 7), and an organisation can ask for level 6.
  • Name. The name in the certificate is the given names and surname read from the chip. Prson checks them against its own signed record of that chip read before issuing. We don't accept names typed by the person.
  • Request. The request comes from the person's Prson app, signed in to their wallet. The phone was checked with Apple App Attest or Google Play Integrity when it was linked to the wallet.
  • We issue only for a document that is still valid, and only at level 5 or 6.

What this proves: someone held that genuine, unexpired, uncloned document when it was checked, and (at level 6) a genuine Prson app on a genuine phone found that their face matched its photo. The liveness check is not certified presentation-attack detection.

6. Issuing, renewing and revoking certificates

Issuing

  • The app asks for a certificate when the person first signs a document, or when they have none that is valid.
  • Each new certificate replaces the person's previous one for that identity. The previous one goes on the CRL as superseded: signatures it made and that were time-stamped before stay valid, and it can't make new ones.
  • A wallet can be issued at most 10 certificates a day.
  • The certificate goes back to the person's phone. The person accepts it by using it to sign.

Validity and renewal

A personal certificate is valid for two years, or until the end of the day its identity document expires, whichever comes first. There is no renewal of the same certificate. The app asks for a new one, with a fresh identity check, when it is needed.

Revocation

We revoke a personal certificate when:

  • the person asks us to, for example because their phone was lost or their recovery phrase exposed (in the app where it offers this, or by writing to [email protected]);
  • the person removes the identity document the name came from;
  • the person deletes the identity or their Prson account;
  • the wallet is restored on a new phone with its recovery phrase;
  • a new certificate replaces it (superseded, as above);
  • we find that it was issued wrongly, or that its key or our CA was compromised.

Anyone else who believes a certificate should be revoked can write to [email protected]. We look into it and revoke the certificate if the reason is confirmed.

The CRL is signed by the Issuing CA each time it is fetched and says it is valid for 7 days. Copies may be cached for up to 1 hour, so a revocation shows within about an hour. It lists every revoked or replaced certificate until that certificate would have expired, with an RFC 5280 reason code:

  • keyCompromise when the person reports their key compromised, or we find it was. Don't rely on any signature made with that certificate, whenever it was made.
  • superseded when a new certificate replaced it, and cessationOfOperation when the document, identity, account or phone is gone. Signatures time-stamped before the revocation time stay valid.
  • No reason code when the person gave none. Treat these as you would a key compromise unless you have reason not to.

We don't run an OCSP responder. The CRL is the only revocation service.

7. What a certificate contains

All certificates are X.509 version 3, with a random 128-bit serial number, signed with SHA-256 and RSA.

Personal signing certificates

  • Issuer: CN=Prson Issuing CA, O=Prson, OU=Document Authority, C=PT.
  • Subject: the common name (given names and surname), givenName, surname, and an organisational unit showing the level: verified-L5 or verified-L6. There is no organisation: the person signs for themselves.
  • Public key: ECDSA P-256.
  • Validity: as in section 6. The start time is set one minute early to allow for clock differences.
  • Basic constraints: not a CA (critical). Key usage: digital signature and non-repudiation (critical). Extended key usage: document signing and email protection.
  • Subject alternative name: a URI of the form https://app.prson.net/id/<identity id>. The identity id is a Prson identifier, not a name.
  • Subject and authority key identifiers, the CRL address, and the address of the Issuing CA certificate.
  • A non-critical Prson extension (1.3.6.1.4.1.65908.1.1) carrying the identity id and verification level.

Prson's own certificates

  • Prson Notary: CN=Prson Notary, O=Prson, OU=Notary Service, C=PT; key usage digital signature and non-repudiation; valid ten years.
  • Time-stamping: CN=Prson Timestamping Authority, O=Prson, OU=Document Authority, C=PT; extended key usage time stamping only (critical); valid ten years.

CRL

Version 2, signed by the Issuing CA, with a CRL number that increases over time, the authority key identifier and, per entry, a reason code where there is one.

8. How signatures and time-stamps are made

  • The person chooses a PDF, or opens one an organisation sent. The app shows the document and the name the signature will carry, and signs only when the person confirms.
  • Prson's server prepares the PDF and sends the phone the data to sign. The phone signs it with the person's key (ECDSA P-256 with SHA-256). The server checks that signature against the certificate before finishing the file.
  • The result is a PAdES baseline B-T signature: the original PDF plus a signature and an RFC 3161 time-stamp over it. Any later change to the signed content breaks the signature.
  • The time-stamping unit takes its time from Prson's server clock, which is synchronised by our cloud provider, and states an accuracy of one second. Each token names its policy (1.3.6.1.4.1.65908.2.1) and includes the time-stamping certificate and its chain, so it can be checked offline. The time-stamping unit only time-stamps signatures made through Prson; it doesn't accept requests from others.
  • A signed PDF can be at most 12 MB.

9. How keys are protected

  • The person's key is created on their phone. The Prson app derives it from the wallet's recovery phrase, which the app keeps in the phone's secure storage. Prson receives only the public key and never holds the private key, so Prson can't sign for anyone. Anyone who learns the recovery phrase could recreate the key, so the person must keep the phrase secret. Restoring a wallet with its phrase revokes its certificates.
  • The Root CA key is kept offline, outside Prson's online systems. It is used only to certify CA certificates.
  • The Issuing CA, company and time-stamping keys are held as encrypted secrets in our cloud providers' secret stores (Cloudflare Workers and Google Cloud Secret Manager), and are available only to the service that uses them and to the few people who administer it. They are not held in a certified hardware security module. If the configured time-stamping key is unavailable, a server instance may create a temporary time-stamping key, certify it under the Issuing CA and never store it; tokens it signed stay checkable through the certificate inside them.
  • If the Issuing CA key were compromised, we would replace the Issuing CA, publish a new one, revoke what is affected, tell people and organisations who use it, and update this document. People would then need new certificates.

10. Operations, records and audits

  • The CA runs on our cloud infrastructure (Cloudflare and Google Cloud). Files are stored in the EU. Access to production systems is limited to the people who run them.
  • We log every issuance and revocation with the serial number, identity id and level, but no name.
  • We keep a record of each certificate: serial number, fingerprint, the identity and document it was issued for, level, validity and revocation status. It holds no name, because the name is only in the certificate, which stays on the person's phone. We keep these records for as long as the Issuing CA operates, so we can answer revocation questions.
  • We keep no copy of a PDF a person signs for themselves: it passes through our server only while it is prepared and signed (15 minutes at most). A PDF signed for an organisation's request is kept with the answer until 30 days after that request expires, as the Verifications API terms say.
  • No independent auditor has assessed this CA. We review our practices ourselves and will update this document when that changes.
  • If we stop operating the CA, we will give at least 90 days' notice where we can, stop issuing, and keep publishing the root certificate and a final CRL for as long as we reasonably can, so existing signatures can still be checked.

11. How to check a Prson signature

  • In the browser: open app.prson.net/check and drop in the PDF. It checks the signature, the chain to the Prson Root CA, the signer's name and level, and when it was signed. The file never leaves your browser.
  • In Adobe Acrobat or Reader: download the Prson Root CA certificate (section 4). Check that its SHA-256 fingerprint matches the one above. Add it to your trusted certificates and allow it as a trusted root for signatures only. Acrobat then shows Prson signatures as valid and names the signer. Before that, Acrobat shows the signer as unknown.
  • Check the CRL, or let your software do it, and check that the time-stamp comes before any revocation.

12. What subscribers and relying parties must do

Subscribers (people who sign):

  • use only your own passport or ID card, and keep your phone, its lock and your recovery phrase to yourself;
  • read what you sign: your signature carries your name from the chip;
  • ask us at once to revoke your certificate if your phone is lost or stolen or your recovery phrase may be known to someone else;
  • use the certificate only for signing documents.

Relying parties:

  • check the signature, the chain to the Prson Root CA (with its published fingerprint), the time-stamp and the CRL before relying on it;
  • look at the level: level 5 shows the document was genuine, but not that the signer's face matched it;
  • decide for yourself whether an advanced electronic signature is enough for your purpose. Some documents need a qualified or handwritten signature by law;
  • don't rely on a certificate for anything outside section 3.

14. Changes and contact

  • We publish each new version of this document here, with a new version number and date. Changes that affect how certificates are issued or checked take effect 30 days after publication, unless needed sooner for security.
  • Questions about this document or the CA: [email protected].
  • Revocation requests and security issues: [email protected].
  • Your personal data: [email protected].