服务端多机构签署JSON文档的非区块链非商用技术方案咨询

以下为非商业、无区块链依赖的可落地方案：

1. 基于JWS（RFC7515）的多签扩展方案 #

JWS是IETF标准化的JSON签名协议，原生支持多签名主体场景，采用General JWS JSON Serialization格式即可承载多个机构的签名信息，所有签名存放在signatures数组中，每个数组条目对应单个机构的签名值、公钥/证书指纹、签名算法标识，不会修改原始JSON文档内容。

• 证书有效期适配：每个签名条目可附加x5c（证书链）、x5t#S256（证书SHA-256指纹）、签名时间戳字段，验签时仅需校验签名生成时间在对应证书有效期范围内即可，无需要求验签时证书仍有效；也可以提前预置各机构的根信任锚到验签服务，不需要依赖在线CA查询。
• 服务端能力适配：签名服务可内置机构身份权限控制，收到签名请求校验身份后，直接将新生成的签名条目追加到现有signatures数组即可；验签服务可直接从JWS结构中提取对应机构的公钥信息完成验签，也可根据请求即时返回指定机构的公钥/证书信息。

2. JSON-LD 多签方案（W3C标准） #

W3C定义的JSON关联数据签名标准，原生支持多主体联合签名，签名信息会作为proof数组附加到原始JSON文档末尾，每个proof条目对应单个机构的签名值、公钥标识、签名时间、算法信息，适合需要保留原始JSON文档可读性的场景。
该方案支持自定义proof扩展字段，可直接将证书有效期、公钥吊销状态标识附加到proof中，验签时可直接读取字段完成校验，无需额外存储关联数据。

3. 轻量自定义签名封装方案 #

如果标准协议过于厚重，可基于RFC8785 JSON规范化标准自研轻量方案：

• 第一步对原始JSON做规范化序列化：采用JSON Canonicalization Scheme（RFC8785）处理原始文档，消除JSON键顺序、空格、转义差异导致的哈希不一致问题
• 第二步封装统一签名块，结构示例如下：

{
  "original_doc_hash": "规范化后的原始文档哈希值",
  "signatures": [
    {
      "org_id": "机构唯一标识",
      "sig_alg": "SM2/RSA2048/ECDSA-secp256r1",
      "pub_key": "签名对应公钥内容",
      "cert_valid_start": 1672502400,
      "cert_valid_end": 1767225600,
      "sig_value": "签名值",
      "sig_timestamp": 1680000000
    }
  ]
}

• 验签时先校验原始文档规范化哈希与original_doc_hash一致，再逐一校验每个签名的合法性，同时校验签名时间是否在对应证书有效期范围内。

证书有效期问题通用处理思路 #

所有方案都可以配套以下逻辑解决证书有效期问题：

• 所有签名必须附加可信时间戳，确保签名生成时间不可篡改，验签时仅校验签名生成时证书处于有效期即可，证书后续过期不影响历史签名的合法性
• 可搭建内部轻量公钥查询服务，存储各机构的历史公钥、证书有效期范围、吊销状态，验签时可根据机构ID和签名时间查询对应有效公钥，无需将公钥全部附加在签名结果中。

服务端核心能力实现要点 #

• 签名模块：支持机构身份鉴权、原始JSON规范化处理、私钥签名、签名结果追加，多次签名不会覆盖历史签名
• 验签模块：支持批量校验多个签名的合法性，可根据请求返回指定机构的对应公钥/证书信息
• 可选配套内部时间戳服务，为所有签名提供可信时间基准，解决证书有效期校验的时间可信问题。

内容的提问来源于stack exchange，提问作者Jaime