For relying parties and developers

Where the list is

The trusted list https://api.ectasign.co.za/trusted-list/tsl.xml The current list, exactly as signed, as application/vnd.etsi.tsl+xml. This is the distribution point the list itself names; fetch it from here, without a query string, and validate it before use.

Its digest https://api.ectasign.co.za/trusted-list/tsl.sha2 The SHA-256 of the current list's bytes, in lowercase hex. Fetch it to see whether the list has changed before you fetch the list again. It only tells you that something changed; it doesn't check the list.

The archive https://api.ectasign.co.za/trusted-list/archive/tsl-<n>.xml Every list published, by its sequence number n, starting at 1. A client that has missed lists fetches the ones in between, to check that each follows on from the one before it by its digest.

Certificate revocation lists http://api.ectasign.co.za/revocation/ML-DSA-87/root-2026.crl http://api.ectasign.co.za/revocation/ML-DSA-87/l1-2026.crl http://api.ectasign.co.za/revocation/ML-DSA-87/l2-2026.crl http://api.ectasign.co.za/revocation/P-521/root-2026.crl http://api.ectasign.co.za/revocation/P-521/l1-2026.crl http://api.ectasign.co.za/revocation/P-521/l2-2026.crl One CRL for each of our certificate authorities, at the address its certificates name as their CRL distribution point. Plain HTTP on purpose: a CRL is signed, and clients fetch it without TLS and without redirects. The list also carries the CRLs its own signers need.

Trust anchors to pin

The list is signed twice, with ECDSA and with an ML-DSA-87 countersignature, each by a certificate issued under one of these roots. Applications built with the EctaSign client library have them built in. If the fingerprint your application has built in, or is configured with, differs from the one here, don't trust the list, and let us know at ectasign@neodev.co.za.

EctaSign Trusted List Root CA P-521 - STAGING RC1 Valid 5 Oct 2026 to 5 Oct 2028

SHA-256 fingerprint 4F 34 4D 7D CF FC CC 12 63 0C DA B6 57 5A 80 DF 33 56 3E 5C 38 54 27 C0 22 51 90 31 7D 05 67 3B

ECDSA P-521 CN=EctaSign Trusted List Root CA P-521 - STAGING RC1, OU=NON-PRODUCTION, O=neodev (Pty) Ltd, C=ZA

EctaSign Trusted List Root CA ML-DSA-87 - STAGING RC1 Valid 5 Oct 2026 to 5 Oct 2028

SHA-256 fingerprint 2E 15 B4 69 09 51 A5 98 50 F6 F4 9B 96 D6 F5 2F 33 E8 EF 71 18 33 4A A6 20 4B 6D 18 17 E7 1A 8A

ML-DSA-87 CN=EctaSign Trusted List Root CA ML-DSA-87 - STAGING RC1, OU=NON-PRODUCTION, O=neodev (Pty) Ltd, C=ZA

Checking the hash chain

Every list after the first carries the digest of the list before it, in the scheme extension PreviousListDigest (namespace https://ectasign.co.za/ns/trusted-list/v1#). To check that list n follows on from list n−1:

Fetch the list before it Fetch https://api.ectasign.co.za/trusted-list/archive/tsl-<n−1>.xml and keep its bytes exactly as they arrive. Don't parse and save it again, change its line endings or add a byte order mark.
Hash its bytes with SHA-512 Over the whole file: the XML declaration, both signatures and every extension included, with no canonicalisation and no re-encoding.
Read the digest in list n The PreviousListDigest element in the scheme extensions, whose Algorithm attribute is http://www.w3.org/2001/04/xmlenc#sha512. Refuse any other algorithm. Its text is the 64-byte digest in standard base64 (RFC 4648 section 4, with padding), on one line with no spaces.
Compare them Decode the text and compare it with your digest, byte for byte. If they differ, list n doesn't follow on from list n−1; don't use it.

The chain only links the lists: check each list's signatures as well. The EctaSign client library does both when it updates, and fetches the lists in between from the archive when it has missed some.