IETF 草案中的 Ed25519 PKCS8 私鑰範例似乎格式錯誤

格式錯誤的 PKCS8 密鑰

Ed25519、Ed448、X25519 和 X448 的算法標識符，用於 Internet X.509 公鑰基礎結構§ 10.3。Ed25519 私鑰的範例說明如下：

An example of the same Ed25519 private key encoded with an attribute
and the public key:

-----BEGIN PRIVATE KEY-----
MHICAQEwBQYDK2VwBCIEINTuctv5E1hK1bbY8fdp+K06/nwoy/HU++CXqI9EdVhC
oB8wHQYKKoZIhvcNAQkJFDEPDA1DdXJkbGUgQ2hhaXJzgSEAGb9ECWmEzf6FQbrB
Z9w7lshQhqowtrbLDFw4rXAxZuE=
-----END PRIVATE KEY-----

The same item dumped as ASN.1 yields:

 0 114: SEQUENCE {
 2   1:   INTEGER 1
 5   5:   SEQUENCE {
 7   3:     OBJECT IDENTIFIER '1 3 101 112'
      :     }
12  34:   OCTET STRING, encapsulates {
14  32:     OCTET STRING D4 EE 72 DB F9 13 58 4A D5 B6 D8 F1 F7
                69 F8 AD 3A FE 7C 28 CB F1 D4 FB E0 97 A8 8F 44
                75 58 42
      :     }
48  31:   [0] {
50  29:     SEQUENCE {
52  10:       OBJECT IDENTIFIER '1 2 840 113549 1 9 9 20'
64  15:       SET {
66  13:         UTF8String 'Curdle Chairs'
      :         }
      :       }
      :     }
81  33:   [1] 00 19 BF 44 09 69 84 CD FE 85 41 BA C1 67 DC 3B
             96 C8 50 86 AA 30 B6 B6 CB 0C 5C 38 AD 70 31 66
             E1
      :   }

最後一位似乎不是有效的有效 PKCS8 私鑰。這是來自PKCS8的私鑰的 ASN.1 定義：

PrivateKeyInfo ::= SEQUENCE {
 version                   Version,
 privateKeyAlgorithm       PrivateKeyAlgorithmIdentifier,
 privateKey                PrivateKey,
 attributes           [0]  IMPLICIT Attributes OPTIONAL }

ASN.1 定義有一個標記號為 0的特定於上下文的標記，而我的第一個片段具有兩個特定於上下文的標記 - 一個標記號為 0，一個標記號為 1。

ASN.1 標準是否允許將任意字元串附加到 ASN.1 編碼對象？因為這似乎就是“用屬性和公鑰編碼的私鑰”正在做的事情……

替代方法

在我看來，如果作者想讓私鑰包含公鑰，他們可以將公鑰添加到PrivateKeyAlgorithmIdentifier. 引用它的定義：

PrivateKeyAlgorithmIdentifier ::= AlgorithmIdentifier

AlgorithmIdentifier  ::=  SEQUENCE  {
    algorithm               OBJECT IDENTIFIER,
    parameters              ANY DEFINED BY algorithm OPTIONAL  }

（算法標識符在RFC5280中定義）

DSA 私鑰執行此操作。DSA 參數 $ p $ , $ q $ 和 $ g $ 在 AlgorithmIdentifier 的參數欄位中定義。因此，該欄位的使用並非沒有先例（例如，參見RFC5912）。

另一種可能性：只是劫持ECPrivateKey。只要做到這一點，Ed25519 只能與 NamedCurve 一起使用，並在使用 Ed25519 時以不同方式解析 publicKey 和 privateKey（如 RFC8032 中所指定） ……

該範例私鑰不是用 PKCS#8 編碼的，而是用RFC 5958中描述的格式編碼的，它應該替換 PKCS#8（至少，用 IETF 的說法，RFC 5958 “過時” RFC 5208，它是PKCS#8 v1.2)。如果呼叫 ASN.1 類型OneAsymmetricKey：

OneAsymmetricKey ::= SEQUENCE {
  version                   Version,
  privateKeyAlgorithm       PrivateKeyAlgorithmIdentifier,
  privateKey                PrivateKey,
  attributes            [0] Attributes OPTIONAL,
  ...,
  [[2: publicKey        [1] PublicKey OPTIONAL ]],
  ...
} 

該結構類似於PrivateKeyInfoPKCS#8 中的結構，但publicKey末尾有一個額外的欄位（可選）。另請注意，version欄位是INTEGERPKCS#8 的值為 0，而 ; 的值為 1 OneAsymmetricKey。這意味著允許某種程度的向後兼容性，因為解碼器OneSymmetricKey可以接受編碼的PrivateKeyInfo，並將使用該version欄位來應用適當的語義（即解碼私鑰 blob 的內容）。

我必須說，到目前為止，我從未OneSymmetricKey在野外遇到過結構。命令行工具在 PKCS#8 中對openssl密鑰進行編碼，應用程序往往會這樣。RFC 5958 的狀態為“建議標準”，但有時您無法強制接受。

引用自：https://crypto.stackexchange.com/questions/59850