RFC Errata
Found 1 record.
Status: Verified (1)
RFC 9151, "Commercial National Security Algorithm (CNSA) Suite Profile for TLS and DTLS 1.2 and 1.3", April 2022
Source of RFC: INDEPENDENT
Errata ID: 7724
Status: Verified
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: James Mayclin
Date Reported: 2023-12-08
Verifier Name: Eliot Lear
Date Verified: 2024-01-04
Section 5.2 says:
If RSASSA-PSS is supported (using rsa_pss_rsae_sha384 for example), then the implementation MUST assert rsaEncryption as the public key algorithm, the hash algorithm (used for both mask generation and signature generation) MUST be SHA-384, the mask generation function 1 (MGF1) from [RFC8017] MUST be used, and the salt length MUST be 48 octets.
It should say:
If RSASSA-PSS is supported then the hash algorithm (used for both mask generation and signature generation) MUST be SHA-384, the mask generation function 1 (MGF1) from [RFC8017] MUST be used, and the salt length MUST be 48 octets. If rsa_pss_rsae_sha384 is used then the implementation MUST assert rsaEncryption as the public key algorithm. If rsa_pss_pss_sha384 is used then the implementation MUST assert RSASSA-PSS as the public key algorithm.
Notes:
RFC9151 explicitly allows both rsa_pss_pss_sha384 and rsa_pss_rsae_sha384 RSASSA-PSS signatures (Sections 6.2, 6.3, 6.4, 7.1, 7.2). This conflicts with the requirement that “the implementation MUST assert rsaEncryption as the public key algorithm” because rsa_pss_pss_sha384 uses RSASSA-PSS as the public key algorithm.
The proposed corrected text updates the requirement to include the correct public key algorithm for rsa_pss_pss_sha384 signatures. The wording closely follows the language used in Section 4.2.3 of RFC 8446.