When working with public key algorithms, the operations are taking all keys, data and operations parameters in S-expressions. This makes the API simple, but some filtering or creation of FIPS service indicators more complicated. Some of the flags are disabled low-level (use-x931 flag), but some need to keep working internally, but are not allowed to be used by the users (for example rfc6979 for deterministic ECDSA). This brings us to the two possibilities:

• provide a FIPS service indicator where the calling application can check if the given flag/parameter/object is approved in FIPS mode
  • one option is something like was done in 4c1c8a707f9652dbfad8f8b531d8b84556f655f1 (initial draft) where the user can try all flags separately. Its not very user friendly, but code wise simple
  • the other option might be the user providing the whole S-exp and the libgcrypt parsing the flags/objects and return if this should or should not be allowed. This would be complicated in a way that we would probably need to report to the user what part was not allowed and in which context, which would again complicate (and duplicate) things.
• Allow these flags internally, but not externally -- this would require parsing and rejecting the flags in the visibility level, which I find cumbersome (and repetitive again).

Initial though (4c1c8a707f9652dbfad8f8b531d8b84556f655f1) was that we can list only the flags, but the random-override and label are not flags so we need to provide indicator for any object in the s-expression to my understanding. So the modification is now attached to the gitlab merge request mentioned in the links, also with clarified documentation and example.