Replace “SHOULD” with “MUST” for cryptographic algorithms to ensure compliance, auditability and operational security

The architecture Blueprint for the EUDI Wallet Ecosystem in Germany currently states:

“This section defines the cryptographic algorithms that should be used and are based on the recommendation of the BSI and SOG-IS.” (Reference: Security Requirements → Session Integrity)

Source: https://bmi.usercontent.opencode.de/eudi-wallet/eidas-2.0-architekturkonzept/content/ecosystem-architecture/crosscutting-concepts/security-requirements/

This is inconsistent with how BSI requirements need to be defined, SOG-IS recommendations, and security governance practices for German government-grade systems. Cryptographic algorithms in government software, especially for PID, EUDI Wallets, and high-assurance identity components, cannot be expressed with “SHOULD”. They must be normative and binding (MUST).

Issue Statement Formulating BSI/SOG-IS cryptographic requirements as “SHOULD” introduces:

  • ambiguity in conformance
  • inconsistent implementation profiles
  • weakened auditability
  • difficulty ensuring Level-High assurance under eIDAS
  • operational fragmentation across Wallet Providers

Rationale Experience from the German Telematic infrastructure demonstrates that non-mandatory cryptographic specifications inevitably lead to organizational and operational difficulties. When algorithms were “recommended” instead of “required”, implementers diverged, resulting in:

  • incompatible key lifecycles
  • inconsistent algorithm support
  • fragmented operational procedures
  • repeated audit escalations

This history provides concrete evidence that mandatory (“MUST”) algorithm definitions are essential to ensure interoperability, auditability, and sustainable operation in nation-scale digital identity systems.

To avoid repeating these issues in the National EUDI Wallet architecture, cryptographic algorithm requirements must be normative.

  1. BSI Technical Guidelines (TR-03116, TR-02102) use mandatory language exclusively

BSI crypto specifications classify algorithms into MUST, SHOULD NOT, and MUST NOT categories. The BSI does not define cryptographic algorithm usage with optional “SHOULD”.

  1. SOG-IS and eIDAS require deterministic cryptographic controls

High-assurance identity components (PID, WIA, WSCD/WSCA) must rely on explicitly mandated algorithms to:

  • guarantee interoperability
  • simplify Common Criteria / AVA_VAN assessment
  • ensure future-proof algorithm agility
  1. German Security Audits (TI case) have shown that optional crypto requirements lead to systemic issues

Historical challenges in the Telematic infrastructure arose because:

  • algorithm agility was inconsistently implemented
  • vendors interpreted “recommended crypto” differently
  • resulting incompatibilities caused security exceptions
  • auditability suffered due to divergent implementations

This directly maps onto the risks the EUDI Wallet must avoid.

  1. eIDAS Level High (LOA High) implicitly mandates prescriptive cryptographic controls

PID issuance, wallet attestation, and WSCD key protection require deterministic and audit-grade cryptographic algorithms—not implementation variability.

Requested Change

Replace all occurrences of: “cryptographic algorithms that SHOULD be used”

with

“cryptographic algorithms that MUST be used according to BSI TR-02102, BSI TR-03116 and SOG-IS recommendations for government-grade systems”

Add a normative box stating: Implementations MUST use the cryptographic algorithms and parameter sets defined by BSI TR-02102 and SOG-IS. No deviations are permitted without explicit approval by the responsible national authority.

Expected Benefits

  • Reduced fragmentation across Wallet Providers
  • Predictable certification pathways (CC/EAL + AVA_VAN)
  • Stronger defense against high attack potential adversaries
  • Clear interoperability across national and European implementations
  • Simplified conformance testing and audit
  • Alignment between established German and European security governance
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information