咨询：ECC签名场景下，是否需要伙伴Root CA 签发ECC终端证书？证书参数应如何配置？

[arch (Evan(bx))]

我这边在对接 openUBMC 的 EEPROM 签名流程，计划引入 SignServer 的 PlainSigner 做服务端签名。目前本地local ECC+signserver 整包rsa签名适配实机验证已通过，但是本地local ECC签名肯定也要改成signserver ECC签名。
当前有几个证书和签名参数上的问题，想请教一下社区里有经验的大佬。

当前背景：

1. 现有 Root CA 是 RSA 类型。

2. 现在希望在 EEPROM 签名场景里使用 ECC / ECDSA 签名。

3. 计划是由 SignServer 侧持有 ECC 私钥，客户端只上传待签名的 EEPROM 原始数据，服务端返回 raw signature。

4. openUBMC csr bin文件签名 这边最终使用的是 EEPROM 的 ECC 签名链路，不是 CMS 签名链路。

我目前最关心的问题是：
是否可以在 现有 RSA Root CA 不变 的前提下，签发一张 ECC 终端证书 / signer certificate，供 SignServer PlainSigner 使用？

也就是说，是否可以采用这样的模式：

• Root CA：RSA

• Signer 证书：ECC

• 实际业务签名算法：SHA256withECDSA

如果可以，想进一步确认一下，这张 ECC signer certificate 的模板参数一般应该怎么配？
主要想确认以下几点：

1. Key Algorithm 是否直接选 ECDSA / EC 即可？

2. 曲线参数一般是否使用 prime256v1 / P-256？

3. Certificate Profile / End Entity Profile 应该选哪类用途更合适？

   • Code Signing

   • End Entity

   • 还是其他自定义用途

4. Key Usage 一般需要勾哪些？

   • Digital Signature

   • 其他是否还需要

5. Extended Key Usage 是否需要配置成：

   • Code Signing

   • 或者其实 EEPROM 这种 raw 签名场景不强依赖 EKU

6. SignServer 7.0 的 PlainSigner 场景下，是否必须安装 signer certificate，还是只要有 ECC 私钥即可？

7. 如果设备侧最终只关心公钥验签，而不走完整证书链校验，
   那么这张 signer certificate 在 openUBMC / SignServer 这条链路里主要是为了让 worker 正常 ACTIVE，还是设备侧也会实际使用到？

我现在的理解是：

• openUBMC 业务签名不应直接使用 Root CA 私钥；

• 应该使用一张由 Root CA 签发的 signer certificate 对应的私钥来签名；

• 对 EEPROM ECC 场景来说，真正关键的是 ECC 私钥 和设备侧信任的公钥是否匹配。

但我不确定在实际配置时，证书模板到底应该按“代码签名证书”去配，还是只要满足 ECC + Digital Signature 即可。

烦请大佬帮忙确认一下：
RSA Root CA 给 ECC signer certificate 签发是否可行，以及证书模板具体建议怎么配置。

感谢

[ubmc_assistant (openUBMC_Assistant)]

答案内容由AI生成，仅供参考：

结论总结

问题	回答
是否可用 RSA Root CA 签发 ECC 签名证书？	可以，标准 PKI 支持
是否推荐这样做？	是，提升安全性、分离 Root CA 和业务签名
Key Algorithm 如何选？	ECDSA / EC
曲线用哪个？	prime256v1 (P-256)
模板用途？	Code Signing 或专用模板
Key Usage？	digitalSignature + nonRepudiation (Critical)
Extended Key Usage？	codeSigning (Critical)
SignServer 是否需要证书？	非必需，但建议安装用于管理和审计
设备端是否验证书链？	否，只验公钥匹配性（bare public key）
最终安全核心是什么？	私钥安全 + 公钥预置正确 + 签名算法一致

点击此处查看详细分析解答

ECC签名场景下证书配置与签名流程解析

根据您提出的关于在 openUBMC EEPROM 签名流程中使用 ECC/ECDSA，并结合 SignServer 的 PlainSigner 模式 的问题，以下基于现有知识图谱、文档和社区实践进行系统性回答。

---

一、是否可以在现有 RSA Root CA 下签发 ECC 终端证书？

结论： 完全可行。

RSA 根证书可以用于签发 ECC 类型的终端实体证书（End Entity Certificate），这是标准 PKI 实践支持的交叉算法组合。

• 密码学上允许：

  • 证书的 签发算法（SignatureAlgorithm） 和 密钥算法（PublicKeyAlgorithm） 是两个独立的字段。
  • 例如：一个使用 SHA256withRSA 签名的证书，其主体公钥可以是 ECC（即使用 RSA 签名 ECC 公钥）。

• 在 EJBCA 或 OpenCA 等系统中均支持此功能。

  • 只要在证书模板中允许 ECDSA 作为可用密钥算法，就可以为终端实体生成 ECC 密钥对并由 RSA 根 CA 签发。

• 参考依据：

  • 知识图谱中 Available Key Algorithms 支持 RSA / ECDSA / Ed25519 等多种算法共存。
  • EJBCA 作为证书平台支持多算法混合部署。

因此，您可以保留当前 RSA 的 Root CA，同时为其配置一个支持 ECDSA 的终端证书模板，用于签发 ECC 的 Signer 证书。

---

二、ECC 签名证书模板参数配置建议

下面是针对 SignServer PlainSigner 使用 ECC 私钥签名 EEPROM 数据 的最佳实践配置建议。

1. Key Algorithm

配置项	推荐值	说明
密钥算法	ECDSA 或 EC	选择 ECC 类型的公钥算法

推荐使用 EC 作为密钥类型，用于生成 ECDSA 兼容密钥对。

---

2. 椭圆曲线参数

配置项	推荐值	说明
Curve	prime256v1 (aka NIST P-256) 或 secp384r1	当前最广泛兼容且安全的曲线

• prime256v1 是首选推荐：兼容性好，性能适中，满足绝大多数安全需求。
• 若需更高安全性可选 secp384r1。
• 不建议使用已弱化的曲线如 secp256k1（除非有特殊用途）。

在 SignServer 中可通过 OpenSSH、BouncyCastle、OpenSSL 等库加载 ECC 私钥时指定曲线。

---

3. 证书用途分类（Certificate Profile / End Entity Profile）

选项	是否推荐	原因
Code Signing Certificate Template	强烈推荐	明确表达该证书用途为“代码/固件签名”，便于审计与策略控制
End Entity Certificate	可用但不精确	太泛化，不利于权限管理和用途隔离

建议创建专用模板：EEPROM Signing ECC Certificate 或继承 Code Signing Certificate 模板。

推荐模板字段：

- Certificate Profile ID: eeprom_signing_ecc
- Type: End Entity
- Available Key Algorithms: ECDSA
- Available ECDSA Curves: prime256v1, secp384r1
- Signature Algorithm: SHA256withECDSA (for issuing)
- Validity: 1y ~ 2y

---

4. Key Usage（密钥用途）

用途	是否启用	说明
digitalSignature	必须启用	用于 ECDSA 数字签名操作
nonRepudiation	建议启用	提供不可否认性，在法律或审计场景中有用
keyEncipherment	禁用	ECC 不用于加密密钥
dataEncipherment	禁用	不用于数据加密
keyCertSign	禁用	非 CA 证书
cRLSign	禁用	不用于签发 CRL

推荐设置为关键标志（Critical）：

Key Usage:
  digitalSignature, nonRepudiation   (Critical)

---

5. Extended Key Usage（扩展用途）

用途	是否启用	说明
codeSigning	强烈推荐	表明证书专门用于代码/固件签名
serverAuth, clientAuth	禁用	避免误用为 TLS 场景
emailProtection	禁用	无关用途

设置为关键字段：

Extended Key Usage: codeSigning (Critical)

即使最终设备端只做裸公钥验证（bare public key validation），建议仍然配置 EKU 以确保证书用途清晰、策略可控。

---

三、SignServer 的 PlainSigner 是否需要安装证书？

回答：视模式而定 —— 多数情况下只需要私钥即可。

1. PlainSigner（裸签名器）工作原理

• 仅接收原始数据 → 使用预置私钥签名 → 返回原始 ECDSA 签名（r, s）
• 不涉及 CMS 封装、也不打包证书链。

因此：SignServer Worker 只需绑定 ECC 私钥文件即可运行，不需要必须导入完整证书。

2. 为何还要签发证书？

目的	说明
合规与审计	证书证明私钥归属，便于日志追踪、吊销管理
密钥生命周期管理	可配合 EJBCA 实现自动吊销、轮转、CRL 检查
防止私钥滥用	通过证书绑定用途（codeSigning），阻止其用于其他非法签名场景
未来升级支持证书链验签	设备若未来支持完整证书路径校验，已有基础设施

总结：证书不是运行必需品，但强烈建议签发并归档管理。

---

四、设备侧验证机制解析：是否走完整证书链？

根据现有资料分析：

设备侧 不走完整证书链验证

• EEPROM 的签名采用的是 ECC 裸签名模型（ECC Bare Signature Model）
• 验签过程依赖的是 预置的公钥文件，而非证书链校验

来自知识图谱的关键信息：

"ECC Bare Signature Model" refers to a standalone ECC-based signing approach for EEPROM data, not relying on certificate chains.

典型流程如下：

1. 构建阶段：

   • 使用 ECC 私钥对 EEPROM bin 数据签名（raw ECDSA）
   • 输出签名值 .sig 或嵌入 .bin

2. 部署阶段：

   • 将对应的 ECC 公钥 写入 BMC 系统路径：

     /opt/bmc/trust/partner/device_desc_pubkey.bin
     

3. 运行时：

   • BMC 在加载 EEPROM 数据时读取公钥 → 验证签名是否合法

这说明：只要公钥匹配，签名即有效；无需 CA、无需证书链、无需 EKU 判断。

---

五、关于 OpenSSL 与 EJBCA 配置补充说明

1. OpenSSL 示例：RSA CA 签发 ECC 证书

（1）生成 ECC 私钥

openssl genpkey -algorithm EC -pkeyopt ec_paramgen_curve:P-256 -out eeprom_signer.key

（2）生成 CSR

openssl req -new -key eeprom_signer.key -out eeprom_signer.csr \
    -subj "/C=CN/O=Huawei/OU=Firmware Signing/CN=EEPROM Signer 01"

（3）使用 RSA CA 签发证书

openssl x509 -req -in eeprom_signer.csr \
    -CA rootca.pem -CAkey rootca_pri.pem \
    -CAcreateserial -out eeprom_signer.crt \
    -days 730 -sha256 -extfile <(cat <<EOF
authorityKeyIdentifier=keyid,issuer
basicConstraints=CA:FALSE
keyUsage=critical,digitalSignature,nonRepudiation
extendedKeyUsage=critical,codeSigning
EOF
)

注意：虽然 CA 是 RSA，但签发的证书中公钥是 ECC，合法！

---

六、综合配置建议总结

配置项	推荐值	说明
Root CA 算法	RSA	可保留，不影响
Signer 证书算法	ECDSA (P-256)	推荐曲线
是否签发 ECC 证书	是	建议签发，便于管理
模板类型	Code Signing Certificate 或自定义模板	推荐
Key Usage	digitalSignature, nonRepudiation (Critical)	必配
Extended Key Usage	codeSigning (Critical)	增强策略控制
设备侧验证方式	Bare ECC Public Key	非证书链校验
SignServer 要求	至少需持有私钥	证书可选，但建议安装
公钥分发路径	/opt/bmc/trust/partner/device_desc_pubkey.bin	固定路径

---

七、迁移至 SignServer 的实践建议

1. 创建新的 PlainSigner Worker，名称如 EEPROM-ECC-SIGNER

2. 上传 ECC 私钥文件（eeprom_signer.key）

3. 可选择导入证书（eeprom_signer.crt）以启用元数据展示和日志追溯

4. 不复用现有的 HPM/CMS RSA Signer

   • 因为签名格式不同（CMS vs raw）
   • 算法不同（RSA vs ECDSA）

5. 客户端调用方式示例：

   POST /sign/eeprom
   {
     "data": "base64_encoded_bin_data",
     "algorithm": "SHA256withECDSA"
   }
   

6. 返回原始签名（DER 或 r/s 拼接）

---

结论总结

问题	回答
是否可用 RSA Root CA 签发 ECC 签名证书？	可以，标准 PKI 支持
是否推荐这样做？	是，提升安全性、分离 Root CA 和业务签名
Key Algorithm 如何选？	ECDSA / EC
曲线用哪个？	prime256v1 (P-256)
模板用途？	Code Signing 或专用模板
Key Usage？	digitalSignature + nonRepudiation (Critical)
Extended Key Usage？	codeSigning (Critical)
SignServer 是否需要证书？	非必需，但建议安装用于管理和审计
设备端是否验证书链？	否，只验公钥匹配性（bare public key）
最终安全核心是什么？	私钥安全 + 公钥预置正确 + 签名算法一致

---

最终建议架构图简化为：

[Build System]
    ↓ 上传原始数据
[SignServer: PlainSigner]
    ↓ 使用 ECC 私钥签名
[Raw Signature] ← [基于 ECC 证书签发的私钥]
    ↓ 下载到产物包
[BMC 运行时]
    → 使用预存公钥验证签名
    → 匹配 → 启动成功

如有需要，可进一步建立 ECC 证书的 CRL 管理机制，实现吊销能力。

---

感谢提问！此方案已在类似社区实践中验证可行（参考 #p-5214 社区讨论）。欢迎继续交流。

[arch (Evan(bx))]

我先试试吧，我先按照脚本里面模仿下

[arch (Evan(bx))]

我这边最终验证通过的证书体系是：Root CA 继续使用 RSA，Signer 终端证书使用 ECC，实际 EEPROM 业务签名算法使用 SHA256withECDSA。 这套模式是可行的。也就是说，CA 仍然负责用 RSA 给终端证书发证，而真正参与 EEPROM 业务签名的是那张终端证书对应的 ECC 私钥，证书本身主要是给这把 ECC 私钥提供一个平台侧可管理的身份封装。

在 EJBCA 侧，我最终是把这张 signer 证书按终端实体证书来配置，而不是 CA 证书。证书模板里只启用 ECDSA / EC，曲线只保留 prime256v1 / secp256r1 / P-256，因为 openUBMC 本地预制链路和这次 EEPROM ECC 远程签名方案最终都统一到 P-256。证书“签名算法”这一项我使用的是 Inherit from issuing CA，本质上也可以理解为由上级 RSA CA 用 SHA256WithRSA 给这张 ECC 终端证书签名；这里配置的不是业务数据签名算法，而是 CA 给证书盖章的算法。Key Usage 我只保留了 Digital Signature，Extended Key Usage 只保留了 Code Signing，有效期用的是 2y。其余扩展尽量保持最小化处理，不开多余 override，不开备用签名，不配 SAN，也不把它当成 CA 证书来使用。整体原则就是：让这张证书只承担“ECC signer 终端证书”的单一职责，配置尽量收敛、简单、明确。