PKCS#5 PBES2: reject iteration counts below 1 and mismatching keyLength

[ManoharPaturi]

Problem

pkcs5_parse_pbkdf2_params() accepts any iterationCount from the EncryptedPrivateKeyInfo, including zero, and the PBES2 path silently discards a mismatching keyLength:

1. iterationCount has no lower bound. RFC 8018 §4.2 requires at least 1. With iterationCount = 0 the PBKDF2 loop derives the key from a single HMAC block, so whoever supplies the encrypted key file chooses the KDF cost. Verified against current development: patching the iteration INTEGER of framework/data_files/rsa_pkcs8_pbes2_pbkdf2_2048_aes128cbc.der from 2048 to 0 and calling mbedtls_pk_parse_key() runs the full decryption with the 0-iteration key (failing only later with PASSWORD_MISMATCH, i.e. the parameter was accepted and used).

2. keyLength is parsed then ignored ("we don't know if it was set or not"). RFC 8018 §A.2: when present it MUST equal the encryption key length. A hostile/misconfigured PBES2 parameter set is accepted instead of rejected.

Fix

• Reject iterationCount < 1 with MBEDTLS_ERR_PKCS5_INVALID_FORMAT.
• Use keylen == 0 as the "absent" sentinel (the declaration is zero-initialized and the ASN.1 getter only writes on success) and reject a present-but-mismatching keyLength.

Verification

Branch builds clean; the mutated-DER case above is now rejected at parse time. A test_suite_pkparse data entry with the modified DER makes this a regression test.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[bjwtaylor]

fixes Mbed-TLS/mbedtls#10836

[mpg]

fixes Mbed-TLS/mbedtls#10836

Which already has a PR: #844

Though it looks like this PR is also addressing another issue (keylength) at the same time.