When signing with subFilter: "ETSI.CAdES.detached" (any PAdES level), PDFSignature.sign() always passes a resolved signingTime (defaulting to new Date()) into CAdESDetachedBuilder.create(), which emits it as a CMS signed attribute (1.2.840.113549.1.9.5). ETSI EN 319 142-1 Table 1 prohibits the signing-time attribute in PAdES baseline signatures — the claimed signing time belongs exclusively in the signature dictionary's /M entry (which sign() already sets). ISO 32000-2 §12.8.3.4 points the same way for the ETSI.CAdES.detached subfilter.
The code comment suggests the attribute "may be needed for Adobe to recognize the timestamp token", but pyHanko has never emitted it for PAdES signatures and its output validates in Adobe, and our pyHanko-validated B-T output without the attribute passes cleanly (green "Signed and all signatures are valid" incl. the embedded RFC-3161 timestamp) — the comment appears to stem from PDFBox's adbe.pkcs7.detached-era behavior.
Suggested fix: in the ETSI.CAdES.detached path, stop passing signingTime into the CMS builder (or gate the attribute on the subfilter), keeping it for adbe.pkcs7.detached where it is customary. If you'd rather keep the current default, an explicit opt-out (omitSigningTimeAttribute or PAdES-level-driven) would restore conformance.
Secondary question: the CAdES builder also unconditionally adds cmsAlgorithmProtection (RFC 6211). It is not among the signed attributes the PAdES baseline profile defines, and pyHanko deliberately omits it from PAdES signatures for that reason (see the comment in pyhanko/sign/signers/pdf_cms.py). Consider omitting it in the CAdES path as well — happy to send a PR covering both.
When signing with
subFilter: "ETSI.CAdES.detached"(any PAdES level),PDFSignature.sign()always passes a resolvedsigningTime(defaulting tonew Date()) intoCAdESDetachedBuilder.create(), which emits it as a CMS signed attribute (1.2.840.113549.1.9.5). ETSI EN 319 142-1 Table 1 prohibits thesigning-timeattribute in PAdES baseline signatures — the claimed signing time belongs exclusively in the signature dictionary's/Mentry (whichsign()already sets). ISO 32000-2 §12.8.3.4 points the same way for the ETSI.CAdES.detached subfilter.The code comment suggests the attribute "may be needed for Adobe to recognize the timestamp token", but pyHanko has never emitted it for PAdES signatures and its output validates in Adobe, and our pyHanko-validated B-T output without the attribute passes cleanly (green "Signed and all signatures are valid" incl. the embedded RFC-3161 timestamp) — the comment appears to stem from PDFBox's adbe.pkcs7.detached-era behavior.
Suggested fix: in the ETSI.CAdES.detached path, stop passing
signingTimeinto the CMS builder (or gate the attribute on the subfilter), keeping it foradbe.pkcs7.detachedwhere it is customary. If you'd rather keep the current default, an explicit opt-out (omitSigningTimeAttributeor PAdES-level-driven) would restore conformance.Secondary question: the CAdES builder also unconditionally adds
cmsAlgorithmProtection(RFC 6211). It is not among the signed attributes the PAdES baseline profile defines, and pyHanko deliberately omits it from PAdES signatures for that reason (see the comment inpyhanko/sign/signers/pdf_cms.py). Consider omitting it in the CAdES path as well — happy to send a PR covering both.