Scheme information
What the Community ECTA Trusted List is, who runs it, on what basis, and what the values in the list mean. The list's scheme information address points here (ETSI TS 119 612 V2.4.1, clause 5.3.7).
The scheme
The Community ECTA Trusted List is a trusted list, in the format of ETSI TS 119 612 V2.4.1 (version identifier 6), of the certificate authorities of providers accredited in South Africa for advanced electronic signatures. Signing applications use it to check that a signer's certificate was issued by such a certificate authority, and that the authority's accreditation is in force.
It's a community project. It isn't a list approved or mandated by the State or the SAAA, and it isn't an EU trusted list. It records accreditation decisions; it doesn't make them.
The list covers South Africa (scheme territory ZA) and is in English only. Its addresses, and the archive of every list issued, are on the page for relying parties and developers.
Who operates it
The scheme operator is neodev (Pty) Ltd. The list names it as the scheme operator, and as the provider of the scheme's own certificate authorities with the registration identifier NTRZA-2026/511073/07. The scheme operator is not the Accreditation Authority, and is not listed as a provider for advanced electronic signatures, it is not approved by the SAAA. Its just a community collection of trust anchours who are owned by SAAA approved entities.
Legal basis
The Electronic Communications and Transactions Act 25 of 2002 (ECTA) defines an advanced electronic signature as an electronic signature that results from a process accredited by the Accreditation Authority under section 37. Sections 37 and 38 provide for the accreditation of authentication products and services in support of advanced electronic signatures, and set the criteria for it. The Accreditation Authority is the South African Accreditation Authority (SAAA).
A service is listed as accredited only on the strength of a current accreditation by the SAAA under these sections. The list adds nothing to that accreditation and takes nothing from it.
How services are listed
How providers are approved. A provider applies to the SAAA for accreditation. The SAAA assesses its products and services against its criteria and decides. The criteria, the assessment and the choice of assessors are the SAAA's, under ECTA and its regulations; the scheme operator has no part in them.
How the operator lists them. The scheme operator adds a provider's certificate authority, changes its status or removes it based on an SAAA decision and information provided by these providers. Each change carries that decision as evidence (its date, its scope, its reference if it has one, and the document), is approved by one or more different approvers, and is kept in a change record naming the first list that contains it. The list gives each service's status and when it took effect, with every earlier status in the service's history.
Responsibilities. The SAAA accredits providers, and revokes or ends their accreditation. Each provider runs its own certificate authorities and their revocation services. The scheme operator records the SAAA's decisions in the list, signs the list and publishes it; each list gives the date by which the next one is due (its next update).
Liabilities. The scheme operator accepts no liability. The list, this site, the API and the client library are provided “as is”, without warranty of any kind, as set out in the disclaimer. The SAAA and each provider are responsible for their own decisions and services.
Statuses
For a list outside the EU, ETSI TS 119 612 clause 5.5.4 leaves it to the scheme operator to declare the statuses, so they are declared here. Every service in the list has exactly one of them as its current status, and so does each period in its history.
http://uri.etsi.org/TrstSvc/TrustedList/Svcstatus/accredited
The SAAA has accredited the service under section 37 of ECTA, and the accreditation is in force.
http://uri.etsi.org/TrstSvc/TrustedList/Svcstatus/accreditationceased
The accreditation has ended without being revoked: it lapsed, or the provider stopped the service.
http://uri.etsi.org/TrstSvc/TrustedList/Svcstatus/accreditationrevoked
The SAAA has revoked the accreditation: the service, and possibly the provider, no longer meets the criteria it was accredited against.
https://ectasign.co.za/ns/trusted-list/v1#schemeOperatorService
Our own status, for the scheme operator's own certificate authorities, which issue the certificates that sign the list. It is not an accreditation, and such a service never counts for advanced electronic signatures.
The three standard values are those of ETSI TS 119 612 annex D.5. The EU's values, such as granted and withdrawn, are not used.
List type and status determination
The list names its type, and how its statuses are determined, with identifiers of its own, which ETSI TS 119 612 clauses 5.3.3 and 5.3.8 allow a list outside the EU to define. The standard's values for a national list describe a list approved or mandated by the State, which this list isn't. Our identifiers don't need to resolve; this page is where they're declared.
https://ectasign.co.za/ns/trusted-list/v1#communityList
A community list of this scheme, published by its scheme operator, not by or for the State.
https://ectasign.co.za/ns/trusted-list/v1#saaaAccreditation
Each status follows the SAAA's accreditation decisions under ECTA, as described under how services are listed.
The list's other fixed values are the standard's: the tag http://uri.etsi.org/19612/TSLTag, version identifier 6, and the scheme territory ZA.
Services and their purposes
Every service in the list is a certificate authority that issues certificates other than EU qualified certificates, of the type http://uri.etsi.org/TrstSvc/Svctype/CA/PKC (clause 5.5.1.2). Accreditation under ECTA is not qualification under EU Regulation 910/2014, so no EU qualified service type is used. Time-stamping authorities and OCSP responders are not listed.
Each period of a service, current or past, says what its certificates are for (clause 5.5.9.4):
http://uri.etsi.org/TrstSvc/TrustedList/SvcInfoExt/ForeSignatures
The certificate authority issues certificates for electronic signatures.
http://uri.etsi.org/TrstSvc/TrustedList/SvcInfoExt/ForeSeals
The certificate authority issues certificates for electronic seals. The scheme operator's own certificate authorities carry this purpose.
http://uri.etsi.org/TrstSvc/TrustedList/SvcInfoExt/ForWebSiteAuthentication
The certificate authority issues certificates for authenticating websites.
Only a service whose status in force is accredited, with the purpose for electronic signatures, counts for advanced electronic signatures. A signer's certificate counts only when it was issued by such a certificate authority, and is checked at the time of signing.
Extensions
The list carries two scheme extensions of our own. Neither is critical, so software that only knows ETSI TS 119 612 can ignore them. Both are in our namespace, https://ectasign.co.za/ns/trusted-list/v1#, and both signatures cover them.
PreviousListDigest
In every list after the first: the SHA-512 digest of the list before it, as the archive serves it at archive/tsl-<n−1>.xml. The digest is over that file's exact bytes: the whole file, with its XML declaration, both signatures and every extension, with no canonicalisation and no re-encoding. Lists have no byte order mark. The element's Algorithm attribute is http://www.w3.org/2001/04/xmlenc#sha512, and its text is the 64-byte digest in standard base64 (RFC 4648 section 4, with padding), with no line breaks or spaces. The lists form a chain, so a client moving from one list to a later one can check that none was left out or replaced. Anything that changes a byte of an archived list breaks the chain at the list after it.
SignerRevocationData
The certificate revocation lists of every certificate authority above the two certificates that sign the list, as Crl elements, and the certificates that sign those revocation lists, as CrlSigningCertificate elements, each in base64. Clients check the list's signers against them.
Signatures
The list is signed twice. Its own signature is an enveloped XAdES-B-B signature with ECDSA P-521 and SHA-512 (http://www.w3.org/2001/04/xmldsig-more#ecdsa-sha512), as clause 5.7 and annex B describe, which any trusted list reader can check. Inside it, a countersignature with ML-DSA-87 (http://www.w3.org/2026/08/xmldsig-more#ml-dsa-87) signs the first signature's value. A list is valid only when both signatures verify.
Our reading of annex B: its rules on the signature bind the list's own, outer ECDSA signature. The ML-DSA-87 countersignature is not that signature; it follows the same rules on canonicalisation and references, with an algorithm annex B does not list.
Other parties, such as the SAAA, may later co-sign the list: a further countersignature after ours, over the same signature value. If a list has a co-signature, it must verify, or the list is refused. A co-signature adds no trust and takes none away: the list's validity rests on our two signatures. No list has a co-signature yet.
Provider statements
When the organisation (O=) in a listed certificate is not the provider's name, the list names that organisation among the provider's trade names, and the service's scheme service definition address points to the scheme operator's statement that the certificate is issued to and owned by the provider (clause 5.5.3). The statements are on this site, at /scheme/providers/{registration identifier}/statement, with the registration identifier's slashes written as %2F.
Contact
You can write to the scheme operator at ectasign@neodev.co.za. The rules for listing services, how to read the list, and the disclaimer are in the scheme rules.