Archived
TD0431: Modification to Cipher Suites for TLS
Publication Date
2019.07.30
Protection Profiles
PP_BASE_VIRTUALIZATION_V1.0
Other References
FAU_GEN.1, FCS_IPSEC_EXT.1.15, FCS_TLSC_EXT.1, FCS_TLSC_EXT.2, FCS_TLSS_EXT.1, FCS_TLSS_EXT.2
Issue Description
Support for TLS_RSA_WITH_AES_128_CBC_SHA is no longer mandated and additional cipher suites are allowed. Resolution
Updated 09/05/2019: This TD also supersedes TD 156. This TD supersedes TDs 166, 213, 252, 265, and 403. In addition, TDs 244 and 267 will be updated since the changes related to this PP are also incorporated in this TD. For FAU_GEN.1: The Application Note for FAU_GEN.1: Audit Data Generation is modified as follows: Application Note: The ST author can include other auditable events directly in Table 1; they are not limited to the list presented. The ST author should update the table in FAU_GEN.1.2 with any additional information generated. “Subject identity” in FAU_GEN.1.2 could be a user id or an identifier specifying a VM, for example. If ‘additional information defined in Table 3’ is selected, it is acceptable to include individual entries from Table 3 without including the entirety of Table 3. Appropriate entries from Tables 2, 4, and 5 should be included in the ST if the associated SFRs and selections are included. The Table 1 entry for FDP_VNC_EXT.1 refers to configuration settings that attach VMs to virtualized network components. Changes to these configurations can be made during VM execution or when VMs are not running. Audit records must be generated for either case. The intent of the audit requirement for FDP_PPR_EXT.1 is to log that the VM is connected to a physical device (when the device becomes part of the VM’s hardware view), not to log every time that the device is accessed. Generally, this is only once at VM startup. However, some devices can be connected and disconnected during operation (e.g., virtual USB devices such as CD-ROMs). All such connection/disconnection events must be logged. Table 1: Auditable Events is modified as follows: FMT_SMR.2 row is removed. The text in Annex B immediately preceding Table 3 is replaced with: The following additional auditable events may be claimed by the ST author if “additional information defined in Table 3” is selected in FAU_GEN.1. Any subset of Table 3, including individual entries, may be included in the ST; it is not necessary to include the entirety of Table 3. Table 3 in Annex B is replaced with:
For FCS_IPSEC_EXT.1.15 - the 3rd paragraph in app note is changed to the following: The configuration of the peer reference identifier is addressed by FMT_MOF_EXT.1.2 in the selected EP. FCS_TLSC_EXT.1 is modified as follows: FCS_TLSC_EXT.1 TLS Client Protocol FCS_TLSC_EXT.1.1 The TSF shall implement [selection: TLS 1.2 (RFC 5246), TLS 1.1 (RFC 4346)] supporting the following cipher suites: [selection: · TLS_RSA_WITH_AES_128_CBC_SHA as defined in RFC 3268 · TLS_RSA_WITH_AES_256_CBC_SHA as defined in RFC 3268 · TLS_DHE_RSA_WITH_AES_128_CBC_SHA as defined in RFC 3268 · TLS_DHE_RSA_WITH_AES_256_CBC_SHA as defined in RFC 3268 · TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA as defined in RFC 4492 · TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA as defined in RFC 4492 · TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA as defined in RFC 4492 · TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA as defined in RFC 4492 · TLS_RSA_WITH_AES_128_CBC_SHA256 as defined in RFC 5246 · TLS_RSA_WITH_AES_256_CBC_ SHA256 as defined in RFC 5246 · TLS_DHE_RSA_WITH_AES_128_CBC_ SHA256 as defined in RFC 5246 · TLS_DHE_RSA_WITH_AES_256_CBC_ SHA256 as defined in RFC 5246 · TLS_RSA_WITH_AES_128_GCM_SHA256 as defined in RFC 5288 · TLS_RSA_WITH_AES_256_GCM_SHA384 as defined in RFC 5288 · TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 as defined in RFC 5288 · TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 as defined in RFC 5288 · TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 as defined in RFC 5289 · TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 as defined in RFC 5289 · TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 as defined in RFC 5289 · TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 as defined in RFC 5289 · TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 as defined in RFC 5289 · TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 as defined in RFC 5289 · TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 as defined in RFC 5289 · TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 as defined in RFC 5289 ]. Application Note: The ST author should select the cipher suites that are supported and must select at least one cipher suite. The cipher suites to be tested in the evaluated configuration are limited by this requirement. However, this requirement does not restrict the TOE's ability to propose additional cipher suites beyond the ones listed in this requirement in its Client Hello message. That is, the TOE may propose any cipher suite but the evaluation will only test cipher suites from the above list. It is necessary to limit the cipher suites that can be used in an evaluated configuration administratively on the server in the test environment. GCM cipher suites are preferred over CBC cipher suites, ECDHE preferred over RSA and DHE, and SHA256 or SHA384 over SHA. TLS_RSA_WITH_AES_128_CBC_SHA is not required despite being mandated by RFC 5246. If any cipher suites are selected using ECDHE, then FCS_TLSC_EXT.1.4 is required. In a future version of this PP TLS v1.2 will be required for all TOEs.
FCS_TLSC_EXT.1.2 The TSF shall verify that the presented identifier matches the reference identifier according to RFC 6125. Application Note: The rules for verification of identity are described in Section 6 of RFC 6125. The reference identifier is established by the user (e.g., entering a URL into a web browser or clicking a link), by configuration (e.g., configuring the name of a mail server or authentication server), or by an application (e.g., a parameter of an API) depending on the application service. Based on a singular reference identifier’s source domain and application service type (e.g., HTTP, SIP, LDAP), the client establishes all reference identifiers which are acceptable, such as a Common Name for the Subject Name field of the certificate and a (case-insensitive) DNS name, URI name, and Service Name for the Subject Alternative Name field. The client then compares this list of all acceptable reference identifiers to the presented identifiers in the TLS server’s certificate. The preferred method for verification is the Subject Alternative Name using DNS names, URI names, or Service Names. Verification using the Common Name is required for the purposes of backwards compatibility. Additionally, support for use of IP addresses in the Subject Name or Subject Alternative name is discouraged as against best practices but may be implemented. Finally, the client should avoid constructing reference identifiers using wildcards. However, if the presented identifiers include wildcards, the client must follow the best practices regarding matching; these best practices are captured in the assurance activity.
FCS_TLSC_EXT.1.3The TSF shall establish a trusted channel only if the peer certificate is valid. Application Note: Validity is determined by the identifier verification, certificate path, the expiration date, and the revocation status in accordance with RFC 5280. Certificate validity shall be tested in accordance with testing performed for FIA_X509_EXT.1.
FCS_TLSC_EXT.1.4: The TSF shall present the Supported Elliptic Curves Extension in the Client Hello handshake message with the following NIST curves: [selection: secp256r1, secp384r1, secp521r1] Application Note: If cipher suites with elliptic curves were selected in FCS_TLSC_EXT.1.1, then this component is required. This requirement does not limit the elliptic curves the client may propose for authentication and key agreement. Rather, it asks the ST author to define which of the NIST curves from FCS_COP.1(2) and FCS_CKM.1 and FCS_CKM.2 the TOE supports. This extension is required for clients supporting Elliptic Curve cipher suites. Assurance Activity:
FCS_TLSC_EXT.2 will be modified as follows: FCS_TLSC_EXT.2 TLS Client Protocol with Mutual Authentication FCS_TLSC_EXT.2.1 The TSF shall implement [selection: TLS 1.2 (RFC 5246), TLS 1.1 (RFC 4346)] supporting the following cipher suites: [selection: · TLS_RSA_WITH_AES_128_CBC_SHA as defined in RFC 3268 · TLS_RSA_WITH_AES_256_CBC_SHA as defined in RFC 3268 · TLS_DHE_RSA_WITH_AES_128_CBC_SHA as defined in RFC 3268 · TLS_DHE_RSA_WITH_AES_256_CBC_SHA as defined in RFC 3268 · TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA as defined in RFC 4492 · TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA as defined in RFC 4492 · TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA as defined in RFC 4492 · TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA as defined in RFC 4492 · TLS_RSA_WITH_AES_128_CBC_SHA256 as defined in RFC 5246 · TLS_RSA_WITH_AES_256_CBC_ SHA256 as defined in RFC 5246 · TLS_DHE_RSA_WITH_AES_128_CBC_ SHA256 as defined in RFC 5246 · TLS_DHE_RSA_WITH_AES_256_CBC_ SHA256 as defined in RFC 5246 · TLS_RSA_WITH_AES_128_GCM_SHA256 as defined in RFC 5288 · TLS_RSA_WITH_AES_256_GCM_SHA384 as defined in RFC 5288 · TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 as defined in RFC 5288 · TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 as defined in RFC 5288 · TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 as defined in RFC 5289 · TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 as defined in RFC 5289 · TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 as defined in RFC 5289 · TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 as defined in RFC 5289 · TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 as defined in RFC 5289 · TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 as defined in RFC 5289 · TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 as defined in RFC 5289 · TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 as defined in RFC 5289]. Application Note: The ST author should select the cipher suites that are supported and must select at least one cipher suite. The cipher suites to be tested in the evaluated configuration are limited by this requirement. However, this requirement does not restrict the TOE's ability to propose additional cipher suites beyond the ones listed in this requirement in its Client Hello message. That is, the TOE may propose any cipher suite but the evaluation will only test cipher suites from the above list. It is necessary to limit the cipher suites that can be used in an evaluated configuration administratively on the server in the test environment. GCM cipher suites are preferred over CBC cipher suites, ECDHE preferred over RSA and DHE, and SHA256 or SHA384 over SHA. TLS_RSA_WITH_AES_128_CBC_SHA is not required despite being mandated by RFC 5246. These requirements will be revisited as new TLS versions are standardized by the IETF. If any cipher suites are selected using ECDHE, then FCS_TLSC_EXT.2.5 is required. In a future version of this PP TLS v1.2 will be required for all TOEs.
FCS_TLSC_EXT.2.2 The TSF shall verify that the presented identifier matches the reference identifier according to RFC 6125. Application Note: The rules for verification of identity are described in Section 6 of RFC 6125. The reference identifier is established by the user (e.g., entering a URL into a web browser or clicking a link), by configuration (e.g., configuring the name of a mail server or authentication server), or by an application (e.g., a parameter of an API) depending on the application service. Based on a singular reference identifier’s source domain and application service type (e.g., HTTP, SIP, LDAP), the client establishes all reference identifiers which are acceptable, such as a Common Name for the Subject Name field of the certificate and a (case-insensitive) DNS name, URI name, and Service Name for the Subject Alternative Name field. The client then compares this list of all acceptable reference identifiers to the presented identifiers in the TLS server’s certificate.
The preferred method for verification is the Subject Alternative Name using DNS names, URI names, or Service Names. Verification using the Common Name is required for the purposes of backwards compatibility. Additionally, support for use of IP addresses in the Subject Name or Subject Alternative name is discouraged as against best practices but may be implemented. Finally, the client should avoid constructing reference identifiers using wildcards. However, if the presented identifiers include wildcards, the client must follow the best practices regarding matching; these best practices are captured in the assurance activity.
FCS_TLSC_EXT.2.3 The TSF shall establish a trusted channel only if the peer certificate is valid. Application Note: Validity is determined by the identifier verification, certificate path, the expiration date, and the revocation status in accordance with RFC 5280. Certificate validity shall be tested in accordance with testing performed for FIA_X509_EXT.1.
FCS_TLSC_EXT.2.4 The TSF shall support mutual authentication using X.509v3 certificates.
Application Note: The use of X.509v3 certificates for TLS is addressed in FIA_X509_EXT.2.1. This requirement adds that this use must include the client must be capable of presenting a certificate to a TLS server for TLS mutual authentication.
FCS_TLSC_EXT.2.5 The TSF shall present the Supported Elliptic Curves Extension in the Client Hello with the following NIST curves: [selection: secp256r1, secp384r1, secp521r1] and no other curves. Application Note: If cipher suites with elliptic curves were selected in FCS_TLSC_EXT.2.1, this component is required. This requirement limits the elliptic curves allowed for authentication and key agreement to the NIST curves from FCS_COP.1(2) and FCS_CKM.1 and FCS_CKM.2. This extension is required for clients supporting Elliptic Curve cipher suites.
FCS_TLSS_EXT.1 is modified as follows: FCS_TLSS_EXT.1 TLS Server Protocol FCS_TLSS_EXT.1.1 The TSF shall implement [selection: TLS 1.2 (RFC 5246), TLS 1.1 (RFC 4346)] supporting the following cipher suites: [selection: · TLS_RSA_WITH_AES_128_CBC_SHA as defined in RFC 3268 · TLS_RSA_WITH_AES_256_CBC_SHA as defined in RFC 3268 · TLS_DHE_RSA_WITH_AES_128_CBC_SHA as defined in RFC 3268 · TLS_DHE_RSA_WITH_AES_256_CBC_SHA as defined in RFC 3268 · TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA as defined in RFC 4492 · TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA as defined in RFC 4492 · TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA as defined in RFC 4492 · TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA as defined in RFC 4492 · TLS_RSA_WITH_AES_128_CBC_SHA256 as defined in RFC 5246 · TLS_RSA_WITH_AES_256_CBC_ SHA256 as defined in RFC 5246 · TLS_DHE_RSA_WITH_AES_128_CBC_ SHA256 as defined in RFC 5246 · TLS_DHE_RSA_WITH_AES_256_CBC_ SHA256 as defined in RFC 5246 · TLS_RSA_WITH_AES_128_GCM_SHA256 as defined in RFC 5288 · TLS_RSA_WITH_AES_256_GCM_SHA384 as defined in RFC 5288 · TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 as defined in RFC 5288 · TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 as defined in RFC 5288 · TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 as defined in RFC 5289 · TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 as defined in RFC 5289 · TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 as defined in RFC 5289 · TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 as defined in RFC 5289 · TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 as defined in RFC 5289 · TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 as defined in RFC 5289 · TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 as defined in RFC 5289 · TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 as defined in RFC 5289]. Application Note: The ST author should select the cipher suites that are supported and must select at least one cipher suite. It is necessary to limit the cipher suites that can be used in an evaluated configuration administratively on the server in the test environment. If administrative steps need to be taken so that the cipher suites negotiated by the implementation are limited to those in this requirement, then the appropriate instructions need to be contained in the guidance. GCM cipher suites are preferred over CBC cipher suites, ECDHE preferred over RSA and DHE, and SHA256 or SHA384 over SHA. TLS_RSA_WITH_AES_128_CBC_SHA is not required despite being mandated by RFC 5246. These requirements will be revisited as new TLS versions are standardized by the IETF. If any cipher suites are selected using ECDHE, then FCS_TLSS_EXT.1.3 is required. In a future version of this PP TLS v1.2 will be required for all TOEs. FCS_TLSS_EXT.1.1, Test 4, bullet 2 is updated as follows:
"(conditional): If an ECDHE or DHE cipher suite is selected, modify the signature block in the Client’s Key Exchange handshake message, and verify that the server rejects the client’s Certificate Verify handshake message (if using mutual authentication) or that the server denies the client’s Finished handshake message." FCS_TLSS_EXT.1.1, Test 4 bullet 4 is modified as follows: [conditional] After generating a fatal alert by sending a Finished message from the client before the client sends a ChangeCipherSpec message, send a Client Hello with the session identifier from the previous test, and verify that the server denies the connection. This test is not required for applications with a TLS implementation that does not support session IDs.
FCS_TLSS_EXT.1.2 is replaced with the following: FCS_TLSS_EXT.1.2: The TSF shall deny connections from clients requesting SSL 2.0, SSL 3.0, TLS 1.0, and [selection: TLS 1.1, TLS 1.2, none]. Application Note: All SSL versions and TLS v1.0 shall be denied. Any TLS versions not selected in FCS_TLSS_EXT.1.1 should be selected here.
FCS_TLSS_EXT.1.3 is replaced with the following: FCS_TLSS_EXT.1.3 The TSF shall [selection: perform RSA key establishment with key size [selection: 2048 bits, 3072 bits, 4096 bits]; generate EC Diffie-Hellman parameters over NIST curves [selection: secp256r1, secp384r1, secp521r1] and no other curves; generate DiffieHellman parameters of size [selection: 2048 bits, 3072 bits]]. Application Note: If the ST lists a DHE or ECDHE cipher suite in FCS_TLSS_EXT.1.1, the ST must include the Diffie-Hellman or NIST curves selection in the requirement. FMT_MOF_EXT.1.2 in the selected EP addresses the "Ability to configure the cryptographic functionality" which allows for the configuration of the key agreement parameters in order to establish the security strength of the TLS connection. FCS_TLSS_EXT.2 is modified as follows: FCS_TLSS_EXT.2 TLS Server Protocol with Mutual Authentication FCS_TLSS_EXT.2.1 The TSF shall implement [selection: TLS 1.2 (RFC 5246), TLS 1.1 (RFC 4346)] supporting the following cipher suites: : [selection: · TLS_RSA_WITH_AES_128_CBC_SHA as defined in RFC 3268 · TLS_RSA_WITH_AES_256_CBC_SHA as defined in RFC 3268 · TLS_DHE_RSA_WITH_AES_128_CBC_SHA as defined in RFC 3268 · TLS_DHE_RSA_WITH_AES_256_CBC_SHA as defined in RFC 3268 · TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA as defined in RFC 4492 · TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA as defined in RFC 4492 · TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA as defined in RFC 4492 · TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA as defined in RFC 4492 · TLS_RSA_WITH_AES_128_CBC_SHA256 as defined in RFC 5246 · TLS_RSA_WITH_AES_256_CBC_ SHA256 as defined in RFC 5246 · TLS_DHE_RSA_WITH_AES_128_CBC_ SHA256 as defined in RFC 5246 · TLS_DHE_RSA_WITH_AES_256_CBC_ SHA256 as defined in RFC 5246 · TLS_RSA_WITH_AES_128_GCM_SHA256 as defined in RFC 5288 · TLS_RSA_WITH_AES_256_GCM_SHA384 as defined in RFC 5288 · TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 as defined in RFC 5288 · TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 as defined in RFC 5288 · TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 as defined in RFC 5289 · TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 as defined in RFC 5289 · TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 as defined in RFC 5289 · TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 as defined in RFC 5289 · TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 as defined in RFC 5289 · TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 as defined in RFC 5289 · TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 as defined in RFC 5289 · TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 as defined in RFC 5289]. Application Note: The ST author should select the cipher suites that are supported and must select at least one cipher suite. It is necessary to limit the cipher suites that can be used in an evaluated configuration administratively on the server in the test environment. If administrative steps need to be taken so that the cipher suites negotiated by the implementation are limited to those in this requirement, then the appropriate instructions need to be contained in the guidance. GCM cipher suites are preferred over CBC cipher suites, ECDHE preferred over RSA and DHE, and SHA256 or SHA384 over SHA. TLS_RSA_WITH_AES_128_CBC_SHA is not required despite being mandated by RFC 5246. These requirements will be revisited as new TLS versions are standardized by the IETF. If any cipher suites are selected using ECDHE, then FCS_TLSS_EXT.2.3 is required. In a future version of this PP TLS v1.2 will be required for all TOEs.
FCS_TLSS_EXT.2.1, Test 4, bullet 2 is updated as follows:
"(conditional): If an ECDHE or DHE cipher suite is selected, modify the signature block in the Client’s Key Exchange handshake message, and verify that the server rejects the client’s Certificate Verify handshake message (if using mutual authentication) or that the server denies the client’s Finished handshake message."
FCS_TLSS_EXT.2.1, Test 4, bullet 4 is updated as follows: [conditional] After generating a fatal alert by sending a Finished message from the client before the client sends a ChangeCipherSpec message, send a Client Hello with the session identifier from the previous test, and verify that the server denies the connection. This test is not required for applications with a TLS implementation that does not support session IDs.
FCS_TLSS_EXT.2.2 is replaced with the following: FCS_TLSS_EXT.2.2: The TSF shall deny connections from clients requesting SSL 2.0, SSL 3.0, TLS 1.0, and [selection: TLS 1.1, TLS 1.2, none]. Application Note: All SSL versions and TLS v1.0 shall be denied. Any TLS versions not selected in FCS_TLSS_EXT.1.1 should be selected here.
FCS_TLSS_EXT.2.3 is replaced with the following: FCS_TLSS_EXT.2.3 The TSF shall [selection: perform RSA key establishment with key size [selection: 2048 bits, 3072 bits, 4096 bits]; generate EC Diffie-Hellman parameters over NIST curves [selection: secp256r1, secp384r1, secp521r1] and no other curves; generate DiffieHellman parameters of size [selection: 2048 bits, 3072 bits]]. Application Note: If the ST lists a DHE or ECDHE cipher suite in FCS_TLSS_EXT.2.1, the ST must include the Diffie-Hellman or NIST curves selection in the requirement. FMT_MOF_EXT.1.2 in the selected EP addresses the "Ability to configure the cryptographic functionality" which allows for the configuration of the key agreement parameters in order to establish the security strength of the TLS connection.
FCS_TLSS_EXT.2.4 Test 4 is changed as follows:
"Test 4: If the TOE supports sending a non-empty Certificate Authorities list in its Certificate Request message, the evaluator shall configure the client to send a certificate that does not chain to one of the Certificate Authorities (either a Root or Intermediate CA) in the server’s Certificate Request message. The evaluator shall verify that the attempted connection is denied. If the TOE doesn't support sending a non-empty Certificate Authorities list in its Certificate Request message, this test shall be omitted."
Table 4 in Annex B is replaced with:
Justification
See issue description. |