FCS_TLSC_EXT.1.4 very confusing

[woodbe]

This SFR is written so it is almost inscrutable. Some of the selections only apply to specific TLS versions while others work for all, and the App note just says use the right ones (basically). It would almost be better to have 2 new SFRs based on the selection of what TLS versions are selected that would allow for the full selection of appropriate extensions. While this may duplicate some (where support overlaps), it would make it absolutely clear what options go with which TLS and what the specific details necessary actually are.

From the engineers working in this space:

This section also has a selection[] block that discusses TLS extensions and the same ambiguity exists there. In this case there follows the text “and shall not send the following extensions”, which suggests that this selection is not exclusive. An exclusive list of TLS extensions would be problematic as many protocol features depend on TLS extensions, e.g. the application_layer_protocol_negotiation (RFC 7301) extension is used to select protocols like HTTP/2 (RFC 9113). We feel that the document would be significantly clarified by being precise about the semantics of the selection blocks.

[jfisherbah]

On review of the requirement it doesn't appear as if the original issues apply any longer. The requirement now indicates clearly which extension SHALL be offered, which MAY be offered, and which SHALL NOT be offered.

The App Note clarifies the circumstances under which it is and is not necessary to include the selections in the "MAY be offered" group.

Ideally this could be written with an iteration as suggested, but at this point in the process it is not advisable. Leaving open as a note to revisit this in a subsequent version.