java - 为什么我的 key 标识符不匹配？

Question

我正在尝试解密 S/MIME 电子邮件(最初通过 Outlook 发送)，为此，我使用了 bouncycaSTLe API。不过，我遇到了麻烦。

我在 Windows 证书存储中有收件人的证书。我之前用它给对方发送了一封签名加密的邮件，对方又用它给我发了一封加密的回复。然后，我将证书(带有私钥)导出为 .pfx 文件，并将此 pfx 文件加载到 Java KeyStore 中。但是，它不起作用，我怀疑这是因为主题 key 标识符不匹配。

这是我用来从 KeyStore 获取主题 key ID 的代码:

KeyStore ks = KeyStore.getInstance("PKCS12");
char[]   pw = "password".toCharArray();

ks.load(new FileInputStream("d:\\cert_priv_key.pfx"), pw);

Enumeration en = ks.aliases();

while( en.hasMoreElements() )
{
    String alias = (String)en.nextElement();
    System.out.println(alias);

    if( ks.isKeyEntry(alias) )
    {
        Certificate[]   chain = ks.getCertificateChain(alias);
        X509Certificate cert  = (X509Certificate)chain[0];

        byte[] id = cert.getExtensionValue("2.5.29.14");

        System.out.println("  " + toHex(id));
    }
}

这会打印出以下 key 标识符:

04 16 04 14 88 ed bb 7c 64 7b 41 63 48 0a 24 40 2b 3c d0 78 72 3c 30 b3

但是，当我检查 Windows 证书存储时， key 标识符不同:

88 ed bb 7c 64 7b 41 63 48 0a 24 40 2b 3c d0 78 72 3c 30 b3

KeyStore 在前面返回额外的 4 个字节(主题 key 标识符应该是 key 的 160 位 SHA1 哈希值，因此长 20 个字节，对吗？)。

更令人困惑的是，当我使用 bouncycaSTLe API 解析 S/MIME 电子邮件并检查收件人 (SMIMEEnveloped.getRecipientInfos().getRecipients()) 时，唯一的收件人返回(应该只有一个)具有此主题 key 标识符:

04 14 88 ed bb 7c 64 7b 41 63 48 0a 24 40 2b 3c d0 78 72 3c 30 b3

...它只有两个额外的字节，而不是四个，我想这就是我无法用证书解密电子邮件的原因。

为什么这些主题键标识符都不匹配？我做错了什么？

Answer 1

如果您了解所有规范，所有这些答案都是一致的，但当然，如果您不了解，这意味着它们会令人困惑。首先要看的地方是RFC 5280, section 4.2.1.2 .在这种情况下，使用方法 (1)。接下来看section A.2在 KeyIdentifier 的定义处。它被定义为 OCTET STRING。现在看看一个 ASN.1 OCTET STRING should be encoded 是如何产生的.它应该以十六进制 04 开头，后跟以字节为单位的长度(20 个字节，或 14 个十六进制)，然后是实际的八位字节字符串(SHA1 哈希)。所以扩展的内容应该是

04 14 88 ed bb 7c 64 7b 41 63 48 0a 24 40 2b 3c d0 78 72 3c 30 b3

最后看一下Extension的ASN.1定义.它表示扩展值必须编码为 OCTET STRING。在这个特定扩展的情况下，最终效果是连续两次编码为 OCTET STRING。在这一层 OCTET STRING 是前一个 OCTET STRING，它包括两个头字节 04 14，所以长度是十六进制 16，编码是

04 16 04 14 88 ed bb 7c 64 7b 41 63 48 0a 24 40 2b 3c d0 78 72 3c 30 b3

这是 X509Extension.getExtensionValue() 返回的值方法。现在， key ID 中有趣的部分只是以 88 开头的 SHA1 哈希，因此这就是 Windows 实用程序显示的内容。显然，您使用的 bouncycaSTLe 方法显示了扩展名而没有进行额外的解码。