From 8d53dc17ce997b52c7d5b8d703105c2290f660a0 Mon Sep 17 00:00:00 2001 From: Hagernesh Date: Wed, 12 Aug 2026 08:08:03 +0000 Subject: [PATCH] docs(eims): confirm signing algorithm and cert format against MoR's guide Cross-checked our RSA-SHA512 signing and raw-bytes certificate encoding against MoR's own "Guide to Generating and Using Certificate for E-Invoicing" (supplied today). Both were previously documented as our best inference from the Postman collection; the guide names SHA512withRSA explicitly (PKCS#1v1.5, matching Node's createSign default) and its own worked example certificate is byte-for-byte the same Subject:/Issuer: + 3-cert PEM chain text-file format ours is. No behavior change -- the comment now says confirmed, not assumed. Field order, section names, date format and the {request, signature, certificate} envelope in the guide's worked example all match our mapper exactly (order doesn't matter per the guide, but it's a further concordance check). The one guide/live disagreement -- its example shows "NatureOfSupplies": "Goods" where our actual 400 SCHEMA ERROR demanded lowercase "goods"/"service" -- is left as-is: the live, machine-generated schema error outranks a static doc example that may predate a schema change. Co-Authored-By: Claude Opus 5 (1M context) --- .../src/modules/eims/eims-signer.service.ts | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/apps/edr-freight-api/src/modules/eims/eims-signer.service.ts b/apps/edr-freight-api/src/modules/eims/eims-signer.service.ts index babec6b44..b91f306ab 100644 --- a/apps/edr-freight-api/src/modules/eims/eims-signer.service.ts +++ b/apps/edr-freight-api/src/modules/eims/eims-signer.service.ts @@ -8,9 +8,14 @@ import { EimsSignedRequest } from "./eims.types"; * * 1. compact `JSON.stringify` of the **inner** request object only, * 2. those exact UTF-8 bytes, - * 3. RSA + SHA-512 (`SHA512withRSA`, PKCS#1 v1.5 — Node's default RSA padding), + * 3. RSA + SHA-512 (`SHA512withRSA`, PKCS#1 v1.5 — Node's default RSA padding). Confirmed, not + * assumed: MoR's own "Guide to Generating and Using Certificate for E-Invoicing" names + * `SHA512withRSA` explicitly, which is PKCS#1v1.5 in Java (PSS would be named + * `SHA512withRSAandMGF1`) — the same padding `createSign("RSA-SHA512")` uses by default. * 4. base64 of the raw signature bytes (256 bytes for an RSA-2048 key), - * 5. base64 of the certificate file's exact bytes. + * 5. base64 of the certificate file's exact bytes. Also confirmed by the same guide: its own + * worked example certificate is the identical `Subject:`/`Issuer:` header + 3-cert PEM chain + * text-file format ours is, base64'd with no re-encoding. * * The outer `{request, signature, certificate}` envelope is never itself signed, and the request * object is never mutated after serialization.