背景
目前 hpm_signer 本地完成 CMS 签名，时间戳由 openssl ts 流程处理（读取 tsa.cnf / ts_signer.pem，生成 TSQ 并在本地产出 TSR）。相关逻辑主要集中在 cms_sign.c 的 timestamp 路径（如 tsa_request / tsa_signed 等）。
提议（尽量零负担、默认等价）
在不改变默认行为的前提下，引入可配置远程 TSA（RFC 3161 over HTTP[S]）能力。该变更仅影响时间戳路径，不改变现有 CMS 生成逻辑。
新增参数（示例命名）
--tsa-url <https://…>：RFC 3161 端点--tsa-auth <bearer:…|basic:…>：可选认证--tsa-cafile <FILE>/--tsa-insecure：TLS 校验或跳过--tsa-header "K:V"（可重复）：附加 HTTP 头
默认仍走现有本地 tsa.cnf 工作流；仅当提供 --tsa-url 时启用远程 TSA。远程失败可回退到本地流程；重试与日志在签名模块内收口，避免扩散到任务脚本，控制维护面。
可选开关（若社区接受）
考虑到部分实现存在细微差异，可提供厂商兼容开关，例如：
--vendor keyfactor：仅在启用时应用特定约定（如查询参数位置、部分状态码的重试策略等），以避免给主干逻辑带来长期负担。
若社区不建议引入任何厂商锁定参数，仅提交纯 RFC 3161 的远程 TSA 实现（不含厂商特化分支）的稳定性，以保证通用性；CMS 仍保持本地实现，避免不同厂商在 CMS“签名打包手法”上的差异带来的不确定性。如果没有厂商锁定参数，希望能集思广益得到一个更好的远程cms兼容办法。
请求
请社区评审上述方向是否可接受：
- 接受：提交“RFC 3161 远程 TSA（默认等价、可回退）”，并视意见决定是否保留
--vendor keyfactor开关； - 不接受厂商开关：仅提交“纯 RFC 3161”版本。说明：时间戳接口基本按标准走，而 CMS 的厂商差异较大，如无厂商开关，后续兼容性成本可能显著上升。
感谢！