Go crypto/x509 ML-DSA 怎样在读取证书密钥（输入边界）

我在把 Go 1.27 的 ML-DSA 证书接入现有读取器时，最容易踩到的坑不是 PEM 解码，而是把“证书使用了 ML-DSA 签名”和“证书里装着 ML-DSA 公钥”当成了同一件事。正确做法是先把 PEM 还原成 DER，再交给 x509.ParseCertificate；拿到 Certificate 后，分别查看 PublicKeyAlgorithm、PublicKey 和 SignatureAlgorithm。

官方文档：https://pkg.go.dev/crypto/x509

在 Go 1.27 及更高版本中，完整 X.509 证书应使用 ParseCertificate 读取；当 PublicKeyAlgorithm == x509.MLDSA 时，再把 Certificate.PublicKey 断言为 *mldsa.PublicKey 并读取参数集。若输入只是 PUBLIC KEY，才改用 ParsePKIXPublicKey。

先分清证书里的三种“算法信息”

Certificate.PublicKeyAlgorithm回答的是“证书公钥属于哪一类”，ML-DSA 证书会得到 x509.MLDSA。Certificate.PublicKey保存实际公钥，Go 1.27 中对应的具体类型是 *mldsa.PublicKey。而 Certificate.SignatureAlgorithm描述的是签发者对证书内容使用的签名算法，可能是 x509.MLDSA44、x509.MLDSA65 或 x509.MLDSA87。

这三个字段可以相互关联，但职责不同。读取器如果只看 SignatureAlgorithm，就可能把签名算法误当成证书公钥类型；只做类型断言，又会丢掉“当前证书不是 ML-DSA 公钥”的清晰诊断。

从 PEM 证书读出 Certificate.PublicKey

我会把读取函数的边界固定在“输入一张完整证书，返回一个 ML-DSA 公钥”。这样调用方不用猜 any 里的类型，也能区分空输入、DER 解析失败、非 ML-DSA 证书和类型不匹配。下面的代码只展示读取逻辑，输入证书由调用方提供：

package certreader

import (
    "crypto/mldsa"
    "crypto/x509"
    "encoding/pem"
    "fmt"
)

func readMLDSAPublicKey(certPEM []byte) (*mldsa.PublicKey, error) {
    // PEM 只是外层编码；ParseCertificate 需要里面的 DER 字节。
    block, _ := pem.Decode(certPEM)
    if block == nil {
        return nil, fmt.Errorf("证书不是有效的 PEM 数据")
    }

    // 先解析完整证书，Certificate.PublicKey 才会被填充。
    cert, err := x509.ParseCertificate(block.Bytes)
    if err != nil {
        return nil, fmt.Errorf("解析 X.509 证书失败: %w", err)
    }
    if cert.PublicKeyAlgorithm != x509.MLDSA {
        return nil, fmt.Errorf("证书公钥算法不是 ML-DSA: %v", cert.PublicKeyAlgorithm)
    }

    // 算法枚举通过后，再确认 any 字段里的具体对象类型。
    pub, ok := cert.PublicKey.(*mldsa.PublicKey)
    if !ok {
        return nil, fmt.Errorf("ML-DSA 公钥类型不匹配: %T", cert.PublicKey)
    }
    return pub, nil
}

关键点是最后的类型断言。*mldsa.PublicKey提供 Parameters()、Bytes() 和 Equal() 等能力；读取器不需要自己解析 ASN.1，也不应该依据公钥字节长度反推参数集。对我来说，把这些判断集中在一个小函数里，后面接证书链、缓存或日志都更容易保持一致。

参数集和签名算法不要混为一谈

得到公钥后，可以读取它所属的参数集。Parameters().String()会给出类似 ML-DSA-44 的名称；如果业务只允许某一个参数集，就在这里做明确分支。证书的 SignatureAlgorithm则应该单独记录，用来描述证书签名，不用它替代公钥对象的参数检查。

func describeMLDSA(cert *x509.Certificate, pub *mldsa.PublicKey) string {
    // 公钥参数描述证书内的 ML-DSA 公钥，不等同于签发签名字段。
    return fmt.Sprintf("公钥=%s，证书签名=%s，公钥字节数=%d",
        pub.Parameters().String(),
        cert.SignatureAlgorithm,
        len(pub.Bytes()),
    )
}

如果只拿到 PEM 类型为 PUBLIC KEY 的 SubjectPublicKeyInfo，而不是 CERTIFICATE，输入边界已经变了：这时使用 ParsePKIXPublicKey，它返回的仍然是包含 *mldsa.PublicKey 在内的具体公钥类型，但不会产生 x509.Certificate，自然也没有 SignatureAlgorithm 可以读取。

混合证书链里怎样处理边界情况

第一，运行环境必须是 Go 1.27 或更高版本；旧工具链没有同样的 crypto/mldsa 与 x509 支持，不能靠改一个类型断言解决。第二，非 ML-DSA 证书不是错误数据，读取器应根据调用场景选择返回“非目标算法”还是继续交给 RSA、ECDSA、Ed25519 分支。第三，证书签名是 ML-DSA，并不自动保证证书公钥也是 ML-DSA，所以两个字段都需要保留。

我会把输入判断写成三问：这是完整证书还是裸公钥？证书公钥算法是否为 x509.MLDSA？具体公钥的参数集是否在业务允许范围？三问分别对应容器解析、类型识别和策略判断，出现问题时日志也更容易定位。

常见问题

为什么不能直接把 Certificate.PublicKey 转成 mldsa.PublicKey？

Certificate.PublicKey的静态类型是 any，并且证书可能使用 RSA、ECDSA 或 Ed25519。应先判断 PublicKeyAlgorithm，再做安全的类型断言。

只有 PUBLIC KEY 文件时为什么找不到 SignatureAlgorithm？

因为它只包含 SubjectPublicKeyInfo，不是完整 X.509 证书。使用 ParsePKIXPublicKey 可以得到公钥，但签发者、证书有效期和证书签名字段并不存在。

读取到 ML-DSA-65 就一定能用于所有 TLS 场景吗？

不能从“成功读取”推出完整的 TLS 兼容性结论。本文只覆盖证书密钥读取；TLS 版本、对端能力和证书链策略应按对应的 crypto/tls 文档另行判断。

Go 1.27 的 ML-DSA 支持把公钥对象接进了标准 x509 读取路径，但调用方仍要守住输入边界：完整证书走 ParseCertificate，裸公钥走 ParsePKIXPublicKey，算法枚举、具体公钥类型和证书签名算法分别记录。