Change notice: ECDSA P-256 signing keys

From 11 December 2026 new end-user signing keys behind Cleverbase Signing and Cleverbase Identification are ECDSA P-256 instead of RSA-2048. This notice tells you what changes, what does not, where to test and what we ask from you.

Audience: integrators of Cleverbase Signing (Ondertekenen) through the Cloud Signature Consortium API (CSC v1), and relying parties of Cleverbase Identification (Identificatie) through OpenID Connect (OIDC) that request the com.cleverbase.proof scope

Published: 29 September 2026. This text is not corrected after publication; any change is announced as a new notice.

1. Summary

From 11 December 2026, every newly created end-user signing key behind Cleverbase Signing and Cleverbase Identification is an ECDSA key on the NIST P-256 curve (secp256r1), and signatures made with such a key use ECDSA with SHA-256. New keys are no longer RSA-2048.

The change is required by ETSI TS 119 312 V2.1.1 clause 8.4, which forbids issuing new certificates on RSA keys shorter than 3000 bits after 31 December 2026. Our ETSI certification and supervision rely on that standard, so the date is fixed.

Two interfaces are affected, one per product, and only where they expose the user's key or a signature made with it:

1. Signing: the CSC v1 API (specification 1.0.4.0): the responses of credentials/info and the request and response of signatures/signHash.
2. Identification: the OIDC identity federation: the content of the com.cleverbase.proof claim.

Everything else, including your authentication and authorisation flows, credential IDs and existing RSA-2048 credentials, keeps working unchanged. Details are in sections 3 to 5, the test facilities in section 6, and what we ask from you in section 7.

2. Key dates

3. What does not change

• Existing credentials. Every RSA-2048 credential that exists on 2026-12-11 keeps its credential ID and keeps signing with RSA (sha256WithRSAEncryption) until its certificate expires, at the latest on 2028-12-31. Your integration therefore has to handle both key types side by side from the switch date on.
• Authentication and authorisation. OAuth 2.0 authorization code flow, oauth2/authorize, oauth2/token, the signature activation data (SAD) flow, scopes and client registrations are unchanged.
• CSC v1 endpoints and JSON structure. No endpoint, field or error code is added or removed; only field values differ for a P-256 credential. credentials/list, info, auth/revoke and oauth2/revoke are unchanged.
• OIDC tokens. ID tokens and userinfo responses are signed by our OIDC provider, not by user keys. Their signature algorithm does not change. Only the XML document inside the com.cleverbase.proof claim is signed with the user's key.
• Issuing CA and trust anchors. End-user certificates are issued by the same issuing CA, which keeps its RSA-4096 key and RSASSA-PSS signature. Policy OIDs and trust anchors are unchanged.
• Existing users. Users who already have an RSA-2048 key keep it for now. They receive a P-256 key in 2027 in a separate step that we will announce in advance.

4. Signing: changes for CSC v1 API clients

4.1 credentials/info

For a P-256 credential the key object reports the EC algorithm OIDs, a key length of 256 and the curve OID. Today (RSA-2048) and from the switch (P-256):

// RSA-2048 credential (unchanged for existing credentials)
"key": {
  "status": "enabled",
  "algo": ["1.2.840.113549.1.1.1", "1.2.840.113549.1.1.11"],
  "len": 2048
}

// P-256 credential (new)
"key": {
  "status": "enabled",
  "algo": ["1.2.840.10045.2.1", "1.2.840.10045.4.3.2"],
  "len": 256,
  "curve": "1.2.840.10045.3.1.7"
}

The cert object carries an X.509 certificate whose SubjectPublicKeyInfo is id-ecPublicKey / secp256r1. The chain, authMode (oauth2code), SCAL (2) and multisign are unchanged.

What to check. Do not assume len == 2048 or a fixed RSA OID when selecting a signature algorithm or sizing buffers. Select the algorithm from key/algo and read key/curve when present.

4.2 signatures/signHash

Request. The API accepts two request forms today for an RSA-2048 credential: the signature-algorithm OID alone, or the key-algorithm OID with an explicit hashAlgo. For a P-256 credential it accepts the same two forms with the EC identifiers. signAlgoParams is omitted in all four.

The hash values remain base64-encoded SHA-256 digests, exactly as today.

An RSA signAlgo (1.2.840.113549.1.1.1 or 1.2.840.113549.1.1.11) for a P-256 credential, or an EC signAlgo for an RSA-2048 credential, is rejected with HTTP 400 and error = invalid_request ("Invalid parameter signAlgo"), the same error class the API returns today for an unsupported algorithm.

Response. Each entry in signatures is the base64 encoding of the ECDSA signature as a DER-encoded ECDSA-Sig-Value, SEQUENCE { r INTEGER, s INTEGER } (RFC 5480 Appendix A, RFC 3279 section 2.2.3). This is the encoding that the ecdsa-with-SHA256 identifier denotes and that CMS, CAdES, PAdES and X.509 expect, so the value can be placed into a SignerInfo as-is.

Consequences for your code:

• The signature is variable in length, at most 72 bytes and usually 70 to 72, instead of a fixed 256 bytes. Remove any fixed-length assumptions.
• If your signature format needs the raw r || s form (64 bytes, for example JWS ES256), convert from DER yourself.
• The SignerInfo / signature dictionary must state ecdsa-with-SHA256 (1.2.840.10045.4.3.2), not sha256WithRSAEncryption.

Example request and response:

POST /csc/v1/signatures/signHash
{
  "credentialID": "⟨credential ID⟩",
  "SAD": "⟨SAD⟩",
  "hash": ["THa3o2fIEKpxfsScr1vY7j7e79GXJB9r02mO1d4sTdw="],
  "signAlgo": "1.2.840.10045.4.3.2"
}

200 OK
{
  "signatures": ["MEUCIAupQw9leaMmzvJ5vYX/0vMDgCRMcvjmRYIbRvZ9pBtWAiEAsOwNuA2uS6Klj9jWl1/I+OpNn9WXrk+0/wSHqRZxAJU="]
}

The signature value in the example is a real ECDSA P-256 signature over the example hash, made with a throwaway test key; it does not verify against any Cleverbase certificate. Decoded, its 71 bytes are:

The leading 00 appears on r or s whenever the first significant byte is 0x80 or higher, which is why the DER length varies: 70 bytes with neither, 71 with one, 72 with both. Stripped to two 32-byte big-endian integers, the same signature in raw r || s form is:

C6lDD2V5oybO8nm9hf/S8wOAJExy+OZFghtG9n2kG1aw7A24Da5LoqWP2NaXX8j46k2f1ZeuT7T/BIepFnEAlQ==

That 64-byte form is what section 5 uses in XML-DSig, and what JWS ES256 expects.

4.3 Validation of the resulting document

A PAdES or CAdES signature produced with a P-256 credential validates against the same trust anchors as today. Verify with your usual validator that it accepts ecdsa-with-SHA256 and EC subject keys. Adobe Acrobat and Reader, and the EU DSS library, do.

5. Identification: changes for OIDC relying parties using com.cleverbase.proof

The claim keeps its shape: {"content": "<base64 XML>", "content_type": "application/xml"}. The XML is the signed identity declaration, an XAdES signature created with the user's signing key. For a user with a P-256 key the signature changes as follows.

Note that the ECDSA signature encoding differs between the two interfaces on purpose: DER in CSC signHash (section 4.2), raw r || s in XML-DSig. Each follows the convention of its own format. The worked example at the end of section 4.2 shows one signature in both forms.

What to check. Your XML Signature library must support ecdsa-sha256 and EC certificates. Standard libraries do (Apache Santuario / Java XML-DSig, .NET System.Security.Cryptography.Xml with ECDsa, xmlsec1, EU DSS). If you pin the SignatureMethod or the certificate key type in configuration, allow both values from the switch date on, because users with an existing RSA-2048 key keep producing rsa-sha256 proofs.

6. Where to test

6.1 Public CSC stub, from 2026-10-02

The Signing service stub is a publicly reachable mock of the CSC v1 API. It needs no onboarding and uses the shared development credentials from Registering your client. From 2026-10-02 it serves a P-256 credential next to the existing RSA-2048 credential, with exactly the values in section 4. Signatures returned by the stub are real ECDSA signatures made with an embedded P-256 test key, so you can verify the bytes you receive against the certificate in credentials/info. The Identification service stub does not serve a P-256-signed proof: relying parties using com.cleverbase.proof receive their first one on the acceptance environment (section 6.2).

The stub is a mock: it accepts fixed authorization codes and SADs and does not check the hash you send. It is meant to exercise parsing and algorithm selection in your integration, not end-to-end signature validity of your documents.

6.2 Acceptance environment with real credentials, from 2026-10-30

From 2026-10-30 the acceptance environment (https://connect.acc.cleverbase.com, see Environments and prerequisites, the same endpoints you use for pre-production testing today) issues real P-256 credentials for newly created test users, and the com.cleverbase.proof claim of such a user is signed with ecdsa-sha256. Signatures come from the acceptance qualified signature creation device (QSCD) cluster and validate against that environment's trust chain. Use this environment to validate your complete flow, including document validation. For OIDC relying parties this is the place to test.

Ask Willem-Jan Goossens for a test user with a P-256 credential if you cannot create one yourself.

6.3 Developer documentation

The updated CSC v1 documentation and the OIDC proof-claim documentation, with P-256 examples (credentials/info response, signHash request and response, XAdES excerpt, certificate chain and changelog), are published in draft on 2026-10-02 and final on 2026-10-30 at https://cleverbase.com/en/dev-docs/.

7. What we ask from you

We will contact you at each of the dates in section 2 to check progress and help with problems.

8. If you cannot be ready in time

Report a blocker to Willem-Jan Goossens as soon as you see it. Our engineers will work with you on it.

There is no per-client exception. Signing keys belong to users, not to your integration, and at enrolment we do not know which services a user will sign with. From 2026-12-11 every newly registered user therefore has a P-256 key, whichever client they use. A client that cannot process P-256 credentials or ecdsa-sha256 proofs by that date will fail for new users until it can. The regulation leaves no room to create RSA-2048 keys after 2026-12-31, so a blocker raised before 2026-12-04 is the only way for us to plan around it together.

9. Contact

Appendix: identifiers at a glance