feature suggestion for selections

It is suggested that for tags, we have some sort of attribute that defines whether that particular selectable SHALL, MAY, or SHALL NOT be chosen (with MAY being the default if the tag is absent, since that's what will usually be wanted).

The use case for this would be to significantly reduce the complexity of Modified SFRs (and when SFRs are taken from functional packages) by allowing the PP author to conveniently tailor what is permitted in a given selection based on the module's needs.

This would require a separate formatting convention for selectable items that the ST author is obligated to claim in these situations, for example an underline.

An example of SHALL would be FTP_ITC.1 in the NDcPP where the module mandates the selection of IPsec but permits all other protocol selections (for example vpngw)

Current way to do this would be:
"The TSF shall provide a communication channel between itself and another trusted IT product using IPsec and [selection: DTLS, TLS, HTTPS, SSH, no other protocols]..."

Proposed change would be:
"The TSF shall provide a communication channel between itself and another trusted IT product using [selection: IPsec, DTLS, TLS, HTTPS, SSH]..."

An example of SHALL NOT would be various selections in the X.509 FP that a given PP does not want to accept. For example, we could apply SHALL NOT to the in FIA_X509_EXT.1 for the revocation checking scenario of "automatically treat any cert older than 24 hours as revoked".

In this case, the attribute would be metadata that would cause the selectable not to be displayed to the reader.

This would then feed into the automation tool by mandating (via the new formatting convention) or omitting particular selections. This would then be both human- and machine-readable.

When doing an xpath, this could be based on the 'id' value of the being modified.

Start by tracing how tags, their id values, and XPath processing are handled in the transforms repository. Review the proposed SHALL, MAY, and SHALL NOT metadata and formatting convention, then define the behavior needed for both human-readable output and automation; done means the convention and selection rules are specified and supported consistently.