Access-certificate CA: certificate policy and practice statement
Version 1.0 · 19 October 2026 · applies to the access-certificate CA published by this site at /wrpac-ca.ashx?ca.
1. Introduction
The CA issues wallet-relying party access certificates: certificates with which a relying party (a website or app that requests data from EU Digital Identity Wallets) identifies itself to wallets. Certificate content and processes are modelled on ETSI TS 119 411-8 V1.1.1 (clause 6) and the requirements of Commission Implementing Regulation (EU) 2025/848, Annex IV, as far as stated below; they have not been assessed for conformity.
| Policy identifier | 2.25.195586870214937213748673734628273007303 (this CA’s own policy) |
|---|---|
| ETSI policy identifier | NCP-l-eudiwrp 0.4.0.194118.1.2 is not asserted while the CA key is in software and the CA is not audited |
| Subscribers | legal persons registered in this site’s relying-party register with a valid status |
| Certificate use | authentication of the relying party towards wallets (signing of presentation requests); no other use |
2. Publication
| CA certificate | /wrpac-ca.ashx?ca (DER), ?ca&format=pem |
|---|---|
| Revocation list (CRL) | /wrpac-ca.ashx?crl, free of charge, at any time |
| CA facts | /wrpac-ca.ashx?info |
| This document | /wrpac-cps.html (the CPS URI in every certificate) |
3. Identification and registration
- A certificate is issued only to a relying party with a valid registration in this site’s register (Implementing Regulation (EU) 2025/848, Art. 7(2)). The register holds the information of Annex I: official name, user-friendly name, official identifier, country, website, contact (at least one of support website, e-mail, phone), services, intended use, public-sector status and entitlements.
- The site administrator checks the relying party’s identity and the official identifier against the official record before registering it, and records who registered or changed it (register history).
- The certificate content comes from the register only; the certificate request contributes nothing but the public key.
4. Certificate lifecycle
- Request: a PKCS#10 certificate request with an ECDSA P-256 key; the request signature is checked (proof of possession). For this site’s own verifier the key is generated on the server.
- Validity: up to 825 days, never beyond the CA certificate.
- Revocation: on request of the relying party (for its own certificates), a supervisory body or a data protection authority, through the site administrator. A suspended or cancelled registration revokes all certificates of that relying party at once. Revocation is published in the CRL immediately, well within the 24 hours required by Annex IV, and takes effect on publication.
- CRL: rebuilt after every revocation and at least every 12 hours; next update 24 hours after issue. No OCSP service yet.
- Re-key: a new certificate request is needed for a new key; certificates are not renewed with the same key.
- CA replacement: the operator can replace the CA itself, for example to correct its name. The new CA has a new key; before the old CA key is destroyed, the old CA signs a final CRL that revokes every certificate it issued (reason cessationOfOperation, valid until the old CA expires; published at
wrpac-ca.ashx?crl&ca=<first 16 hex of its SHA-256>), so certificates issued under it must be replaced. The site’s own certificates are re-issued at once; relying parties are asked to request new certificates.
5. Facility, management and operational controls
- Only signed-in administrators of this site can register relying parties, issue and revoke; every action is logged with the acting account.
- Issued certificates and register records are kept for at least ten years after the last certificate based on them ceases to be valid (ETSI TS 119 411-8 OVR-6.4.6-02).
- Certificate Transparency logging is not used.
6. Technical security controls
| CA key | ECDSA P-256, generated on the server, stored encrypted with the operating system’s machine-level data protection, file access limited to the site; used only through the CA key store interface |
|---|---|
| Planned change | the CA key moves to an HSM; the CA software already separates the key store so that this is a change of the store, not of the CA |
| Signature algorithm | ecdsa-with-SHA256, deterministic signatures (RFC 6979) |
7. Certificate and CRL profiles
| CA certificate | self-signed; basic constraints CA, path length 0; key usage keyCertSign, cRLSign; 10 years |
|---|---|
| Subject (relying party) | countryName, organizationName (official name), organizationIdentifier (ETSI EN 319 412-1 form, e.g. VATMT-12345678), organizationalUnitName (instance, optional), commonName (user-friendly name) |
| Subject alternative name | support website (URI), e-mail (rfc822Name), phone (otherName id-at-telephoneNumber) – as registered; optional dNSName entries for x509_san_dns client identifiers |
| Key usage | digitalSignature (critical); no CA |
| Other extensions | certificate policies with CPS URI; authority information access (CA certificate); CRL distribution point; authority and subject key identifiers |
| CRL | X.509 v2, CRL number, authority key identifier, reason codes |
8. Audit
None yet. The ETSI policy identifier will only be asserted after the CA key is in an HSM and a conformity assessment against ETSI EN 319 411-1 and ETSI TS 119 411-8 has been passed.
9. Other matters
Test and private use: no warranty and no liability beyond what the operator of this site agrees in writing with a relying party. Questions and revocation requests: through the contact details of this site.