Fix #131: add CSR profile and ECDSA examples for provider sign/seal certificates

[andmoro]

Summary

This PR updates Task 3 to provide an implementable CSR profile for the sign/seal certificates defined by ETSI TS 119 412-6 and aligns the certificate examples with the WE BUILD cryptographic profile.

Main changes

• Adds a common WE BUILD cryptographic profile for PID, Wallet, EAA, QEAA, and PuB-EAA Provider sign/seal certificates:

  • ECDSA P-256 (secp256r1 / prime256v1) subject keys;
  • ecdsa-with-SHA256 certificate and CSR signatures;
  • ES256 when the corresponding provider key is used to sign JOSE objects;
  • RSA keys and signatures are excluded from these profiles.

• Adds a common PKCS#10 CSR profile covering:

  • CSR signature and proof-of-possession requirements;
  • subject requirements based on the applicable ETSI EN 319 412 profile;
  • extensionRequest requirements for keyUsage and subjectAltName;
  • CA-side CSR validation and rejection rules.

• Adds non-normative OpenSSL examples for:

  • generating an ECDSA P-256 key pair;
  • generating the CSR;
  • inspecting and verifying the CSR;
  • illustrative certificate issuance.

• Clarifies the Wallet Provider profile:

  • each Wallet Solution has a distinct key pair and sign/seal certificate;
  • the certificate URI SAN is bound to the Wallet Solution URI;
  • the key pair/certificate cannot be reused across Wallet Solutions;
  • the same Wallet Solution private key is used to sign its WIA, KA, and related Token Status Lists using ES256.

• Updates the non-normative PID, Wallet, EAA, QEAA, and PuB-EAA certificate examples from RSA to ECDSA P-256 / SHA-256.

Issue resolved

Closes #131.

[thodoris]

Thanks Andrea, I ran the openssl commands as written. Key, CSR and verification all work, and the
requested key usage is Type A, which EN 319 412-3 clause 4.3.1 says should be used.

Questions on the normative text

1. The profile also constrains the issuing CA, and does not say so.

The X.509 signature algorithm used to sign each certificate MUST be ECDSA with SHA-256
(ecdsa-with-SHA256).

The bullet before this one covers the subject key, which is what a provider generates. This one is
the signature on the certificate, which is made with the issuing CA's key. It is a requirement on the
CA, sitting in a list that otherwise tells providers what to put in a CSR. The issuance example says
"the issuing key in this example is also ECDSA P-256", so it looks intended. If it is, please label
it as a CA requirement.

2. The PuB-EAA profile has no keyUsage values.

CSR Validation step 5 says unsupported keyUsage requests MUST be rejected. PID and Wallet list Type
A, B, C or F. (Q)EAA lists A, B or F. The PuB-EAA row says only "REQUIRED.", so a CA has nothing to
reject against. That row needs its values.

3. The example CSR subject and the example certificate subject disagree.

The CSR generates

/C=DE/O=Example Wallet Provider/organizationIdentifier=VATDE-123456789/CN=Example Wallet Solution

and the Wallet Provider certificate example a few sections down has

O = Example of Wallet Provider, CN = Wallet Provider Example, organizationIdentifier = LEIDE-5493001KJTIIGC8Y1R12

Three of the four RDNs differ, and the CSR is meant to produce that certificate. Separately,
CN = Example Wallet Solution names the solution rather than the subject, while EN 319 412-3
LEG-4.2.1-8 asks for a name commonly used by the subject (the legal person) to represent itself.
As written, a CSR built from the example would not pass the document's own CSR Validation step 4.

4. Can the wallet solution URI be settled separately?

How the URI is generated and what guarantees its uniqueness is still open, along with the
consequence for the WRPRC data model and its runtime validation. This need not hold up the PR, but
the body says Closes #131, which takes it off the board.

A solution could be that the URI in the SAN stays the binding value and no generation scheme is
defined. Uniqueness is enforced at registration, with the Trusted List operator rejecting a wallet
solution URI already registered against another entry, so nothing changes in the CSR. UC-03's
separate optional "unique reference identifier of the wallet solution" (CIR 2025/849 Annex 2(a))
stays a distinct attribute for MVP+.

The CA checks the match at issuance, which is CSR Validation step 6. What remains is the runtime
check and where it belongs, which is the WRPRC point you raised.

This can be decided later, or in a new issue.

Editorial

• Broken link in Non-normative examples: [OpenSSL Commands](#openssl-commands), but there is no
  heading of that name. Simplest fix may be to rename the section to ## OpenSSL Commands, which is
  what Task 5 calls its counterpart, rather than to change the link.
• wallet_provider_ext.cnf is referenced but not given, so the issuance example can't be run.
  Task 5 has ### Extensions Configuration (rp_ext.cnf) with the [v3_wrpac] block inline; the same
  for [v3_wallet_provider] would finish the example.
• The new text gives the URI's home three different names: "the Wallet Provider's Trusted List" in
  the SAN row, "the Trusted List" in the Common CSR Profile and in CSR Validation step 6, and the
  table in the same document gives the trust anchor location as the Wallet Providers LoTE. Since
  step 6 tells a CA to resolve it and compare, it should name one artifact.
• Typos: "criptographic" → "cryptographic" (Wallet Provider section); "the provider' service
  onboarding data" → "the provider's" (CSR Validation, step 7).