RFC 9151, "Commercial National Security Algorithm (CNSA) Suite Profile for TLS and DTLS 1.2 and 1.3", April 2022

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.

Report New Errata