TimeStampSigner: selecting SIGNATUREALGORITHM dynamically based on the request's messageImprint digest

[gustavoam-asdf]

Context

In TimeStampSigner, the signature algorithm used to sign the TimeStampToken (CMS SignerInfo.signatureAlgorithm) is read from the SIGNATUREALGORITHM worker property and applied as-is:

signatureAlgorithm = config.getProperty(SIGNATUREALGORITHM, DEFAULT_SIGNATURE_ALGORITHM);
...
ContentSigner cs = new JcaContentSignerBuilder(signatureAlgorithm)
    .setProvider(crypto.getProvider())
    .build(crypto.getPrivateKey());

So a worker configured with, for example:

SIGNATUREALGORITHM=SHA512WithRSAandMGF1
ACCEPTEDALGORITHMS=SHA256;SHA384;SHA512

…will sign every TimeStampToken with RSA-PSS over SHA-512, regardless of which digest algorithm the client used in the request's messageImprint. The messageImprint is preserved unmodified in TSTInfo, which is the standards-compliant behavior, but the signature algorithm chosen by the TSA is fixed.

I verified this against my own deployment (SignServer-CE 7.1.1): TSQs with messageImprint.hashAlgorithm = sha256 and sha512 both yield TSTs signed with the same SignerInfo.signatureAlgorithm = rsassaPss (SHA-512, MGF1-SHA-512). The behavior matches what I read in TimeStampSigner.java in main.

Use case / motivation

In our case we serve timestamps to a heterogeneous set of clients — some sign documents with SHA-256 + RSA PKCS#1 v1.5 (legacy ecosystem, public-sector validators that don't yet handle PSS), others with SHA-512 + PSS (modern PAdES-Baseline-T flows). We recently hit a real incompatibility where a strict validator rejected our TSTs because the TST was signed with RSASSA-PSS while the signer's own document signature was sha256WithRSAEncryption. The validator's pipeline did not handle the algorithm mismatch gracefully.

Today the only mitigation available is to fix SIGNATUREALGORITHM to a single common-denominator value across all clients (we did this: SHA512WithRSA), losing the benefit of PSS for clients that would accept it.

An alternative, currently-not-possible option would be: let the worker derive signatureAlgorithm from the digest the client already chose in its messageImprint. The intuition is that a client capable of producing a SHA-256 imprint is signaling it lives in an ecosystem where SHA-256 is acceptable; matching the TST's signature digest to that gives a "naturally consistent" token without forcing the operator to converge on a single algorithm.

Proposed configuration shape

Strawman — name and exact syntax up for discussion:

MESSAGEIMPRINT_SIGNATUREALGORITHM_MAP=SHA256:SHA256WithRSA;SHA384:SHA384WithRSA;SHA512:SHA512WithRSA
SIGNATUREALGORITHM=SHA512WithRSA   # fallback when the imprint digest isn't in the map

Semantics:

• If MESSAGEIMPRINT_SIGNATUREALGORITHM_MAP is unset, behavior is exactly today's — SIGNATUREALGORITHM applied as-is. Fully backwards compatible.
• If set, the worker looks up the messageImprint.hashAlgorithm of the incoming TSQ in the map and uses the mapped signatureAlgorithm to build the ContentSigner.
• If the imprint digest isn't a key in the map, fall back to SIGNATUREALGORITHM (existing behavior).
• The mapped sigalg's hash family does not have to match the imprint digest — operator decides. For example, an operator could even map SHA256:SHA512WithRSA if they want to upgrade weak imprints with a stronger signature.
• ACCEPTEDALGORITHMS continues to be the gatekeeper for which imprint algorithms the worker is willing to process at all.

A simpler variant some operators might prefer is an ADAPTIVE_SIGALG=true flag that just derives sigalg from the imprint digest using SHA256WithRSA/SHA384WithRSA/SHA512WithRSA automatically — but the explicit map is more flexible (PSS vs PKCS#1 v1.5, hash mixing, etc.) and avoids hardcoded assumptions.

Considerations / trade-offs I can already see

• Audit/trace: with this enabled, two TSTs from the same worker can have different SignerInfo.signatureAlgorithm. Operators relying on "all my TSTs verify with one algorithm" lose that property. Mitigation: the feature is opt-in, off by default.
• Policy alignment: the worker's declared DEFAULTTSAPOLICYOID may be tied (in the operator's CPS) to a specific sigalg. Operators enabling the map should ensure their CPS/policy declares all sigalgs they intend to emit. This is the operator's responsibility, not SignServer's.
• Client-controlled cryptographic choice: an attacker could deliberately pick the weakest sigalg in the operator's map. Mitigation is the same as today's ACCEPTEDALGORITHMS: the operator decides what the floor is.
• HSM/provider support: if a mapped sigalg isn't supported by the crypto token / provider, build will fail at request time rather than at worker activation. Maybe worth a startup-time validation pass over the map.
• eIDAS / ETSI alignment: I'm not aware of an explicit prohibition in ETSI EN 319 422 against varying sigalg per-request as long as each emitted sigalg is declared in the TSA's policy. But it'd be useful to hear from anyone who's been through a QTSP audit on this.

Questions

1. Is this kind of per-request sigalg selection something the SignServer team would consider in principle? Or is it a deliberate non-goal (e.g. for audit/policy reasons I'm not seeing)?
2. Is there a preferred shape — explicit map vs. simple "adaptive" flag — if it were to land?
3. Are there other places in the codebase (e.g. archive/audit log fields, status reports, the AdminGUI worker config UI) that assume one sigalg per worker and would need to be updated alongside this?
4. Would a PR exploring this — keeping the feature opt-in and behind the absence of MESSAGEIMPRINT_SIGNATUREALGORITHM_MAP for backwards compat — be welcome?

Happy to share more detail on the production use case if helpful. Thanks for considering.