pkey: Use openssl generated pkcs8 key instead

[samuel40791765]

In the test_private_encoding_encrypted test, we have a rsa private key pem file that was generated with certtool. I'm not entirely sure if the command that was used to generated the file was correct though. Dumping out the ASN.1 contents of this file indicates that this file was generated with an additional --pkcs-cipher=aes-128. When I try running the same command as the documentation indicates, the pem file would be encrypted with the default 3des-pkcs12 instead.

• Note: ASN.1 contents were dumped out with der-ascii and running der2ascii -pem -i rsa.pem > rsa.txt.

The commentary above is fairly minor. The larger issue is that certtool's generated pkcs8 files aren't entirely consistent with RFC8018 Appendix A.2. certtool's PKCS8 private keys have a missing NULL field that should be paired with the Algorithm ID when using PBKDF2-PRF. OpenSSL doesn't seem to notice this, although this does fail with stricter parsers that explicitly check the field. I've cut an issue to GnuTLS regarding this, but it would be awesome if we could use a key file that's consistent with RFC guidelines for now instead.
OpenSSL's generated PKCS8 keys don't have the same issue described, so I've replaced the key file for an OpenSSL generated command along with the command I used to generate.

[rhenium]

This is interesting. The parameters field in AlgorithmIdentifier is marked as OPTIONAL in the ASN.1 module. RFC 8018 specifies the type is NULL, but nowhere in RFC 8018 does it say whether the field should be present or not.

I've looked at a few RFCs that use AlgorithmIdentifier and they're not consistent. I'm under the impression that the field may or may not be present in PBKDF2, too.

• RFC 4231 (HMAC test vectors) says "the parameter component SHOULD be present but have type NULL" in AlgorithmIdentifier with the same HMAC OIDs as in RFC 8018.
  https://datatracker.ietf.org/doc/html/rfc4231#section-3.1
• RFC 8017 (PKCS#1, published 2 months earlier than RFC 8018) says in Appendix B.1, parameters "should generally be omitted, but if present, it shall have a value of type NULL." This is about hash functions and not HMAC, however.
  https://datatracker.ietf.org/doc/html/rfc8017#appendix-B.1
• RFC 5754 (CMS) says "[CMS] Implementations MUST accept SHA2 AlgorithmIdentifiers with absent parameters. Implementations MUST accept SHA2 AlgorithmIdentifiers with NULL parameters. Implementations MUST generate SHA2 AlgorithmIdentifiers with absent parameters." This is also about hash functions.
  https://datatracker.ietf.org/doc/html/rfc5754#section-2

I didn't know there was such a difference between OpenSSL and GnuTLS, but I wonder if this might have accidentally revealed an edge case not considered in AWS-LC/BoringSSL if they don't parse it.

When I try running the same command as the documentation indicates, the pem file would be encrypted with the default 3des-pkcs12 instead.

I think it's the command @junaruga used to generate the current PEM block in #790. I tried with certtool from GnuTLS 3.8.8 and it used the same PBES2 parameters with AES. I imagine it could depend on the GnuTLS's version and other variables.