[gnutls-devel] GnuTLS | certtool: generated PKCS8 private keys inconsistent with RFC (#1632)

Read-only notification of GnuTLS library development activities gnutls-devel at lists.gnutls.org
Fri Dec 20 01:45:22 CET 2024



Samuel Chiang created an issue: https://gitlab.com/gnutls/gnutls/-/issues/1632



## Description of problem:
 gnu-tls/certtool outputs a PKCS8 file that's not coherent with RFC8018 Appendix A.2: https://datatracker.ietf.org/doc/html/rfc8018#appendix-A.2 The RFC states that the PBKDF2-PRF Algorithm identifier should have a NULL field paired with the algorithm id to be used.

      algid-hmacWithSHA1 AlgorithmIdentifier {{PBKDF2-PRFs}} ::=
          {algorithm id-hmacWithSHA1, parameters NULL : NULL}

The pkcs8 files I've generated with gnu-tls using `PBES2_AES_128` are missing this NULL field, which causes a parsing error in [AWS-LC](https://github.com/aws/aws-lc/blob/f45bc34b9132fbd7749c45431fa06a89198cdb4b/crypto/pkcs8/p5_pbev2.c#L292-L300) & [BoringSSL](https://github.com/google/boringssl/blob/be21ef7012f0812bb1c0c8fc226979fa6c301e8d/crypto/pkcs8/p5_pbev2.cc#L292-L300) due to their stricter checks.
Just as additional sanity test, the PKCS8 files I've generated with OpenSSL don't have this issue and correctly generate a PKCS8 file with the NULL field paired with the algorithm id.
* OpenSSL command: `openssl pkcs8 -in rsa_key_file.pem -topk8 -v2 aes-128-cbc -out output.p8 -passout pass:abcedf`

### Side note:
When running `certtool --to-p8 ... pkcs-cipher=...`, is `PKCS12_3DES_SHA1` the intended default? I noticed that there was this older commit 14 years ago that tried changing the default to `AES-128`: https://gitlab.com/gnutls/gnutls/-/commit/0d004a210db5d220c896456a165c81264fa4454a. That was changed a couple years later when some parts of `certtool` were reworked in https://gitlab.com/gnutls/gnutls/-/commit/d0ae20f780ac74857d70b4190166bf18195ef4d7. `pkcs_cipher` in the certtool application code doesn't have a default value assigned, which causes the [default `PKCS12_3DES_SHA1` schema](https://gitlab.com/gnutls/gnutls/-/blob/d0ae20f780ac74857d70b4190166bf18195ef4d7/lib/x509/privkey_pkcs8.c#L412-434) to be used instead. There isn't any explicit documentation on what the default for `pkcs-cipher` is however, I was more or less genuinely curious since the behavior's slightly inconsistent with past release notes and the commit history.


## Version of gnutls used:
gnutls-cli 3.6.13

Although this issue still seems to exist in gnutls today when looking at the relevant code here: https://gitlab.com/gnutls/gnutls/-/blob/master/lib/x509/pkcs7-crypt.c#L1349-1363

## Distributor of gnutls (e.g., Ubuntu, Fedora, RHEL)
Ubuntu

## How reproducible:

Steps to Reproduce:
1. Use a RSA private key to load into certtool and output a pkcs8 file:
```
certtool --load-privkey=rsa_key_file.pem --to-p8 --password=abcdef --pkcs-cipher=aes-128
```
2. There's a nifty tool called [der2ascii](https://github.com/google/der-ascii) that helps dump out all the ASN.1 contents of a file.
```
der2ascii -pem -i their-old-rsa-key.pem  > their-old-rsa.txt
```

## Actual results:
These are the ASN.1 contents of the PBKDF2 identifier I got:
```
SEQUENCE {
        # PBKDF2
        OBJECT_IDENTIFIER { 1.2.840.113549.1.5.12 }
        SEQUENCE {
          OCTET_STRING { `b1322c8a7ae134caf8a30533730606801d25` }
          INTEGER { `0927c0` }
          INTEGER { 16 }
          SEQUENCE {
            # hmacWithSHA256
            OBJECT_IDENTIFIER { 1.2.840.113549.2.9 }
          }
        }
      }
```
## Expected results:
These are the ASN.1 contents I got from OpenSSL. Notice the `NULL {}` field paired along with the `hmacWithSHA256` OID.
```
      SEQUENCE {
        # PBKDF2
        OBJECT_IDENTIFIER { 1.2.840.113549.1.5.12 }
        SEQUENCE {
          OCTET_STRING { `5b57711e03a7c6bc` }
          INTEGER { 2048 }
          SEQUENCE {
            # hmacWithSHA256
            OBJECT_IDENTIFIER { 1.2.840.113549.2.9 }
            NULL {}
          }
        }
      }
```

-- 
Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1632
You're receiving this email because of your account on gitlab.com.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnutls-devel/attachments/20241220/6dc87450/attachment-0001.html>


More information about the Gnutls-devel mailing list