Alexander Sosedkin
commented:
So, the effective configuration now, with a config specifying "hard-disabled" and "config-priority" is:
- for non-TLS: "everything - hard-disabled",
- for TLS not using
@SYSTEM: "priority",
- for TLS using
@SYSTEM:extra-priority: "config-priority +- extra-priority - hard-disabled".
And what we're aiming for given a config that specifies "soft-disabled", "hard-disabled" and "config-priority":
- for non-TLS: "everything - soft-disabled +- new-api - hard-disabled",
- for TLS not using @system: "priority +- new-api",
- for TLS using @system:extra-priority: "config-priority - soft-disabled +- extra-priority +- new-api - hard-disabled".
(italics signify what's under the application control)
Questions:
- did I get your proposal right?
- do we want new API to affect TLS or not? why?
- will we have everything soft-disabled reenableable with either priority strings or new-api?
- will we have priority-string-format keywords for everything, so that a TLS app could forego new-api and only use priority string?
- if we will have priority-string keywords for everything, can we simplify it somehow? The "priority - soft-disabled +- extra-priority +- new-api - hard-disabled" might be not that hard to merge, but sounds hard to comprehend.
- how orthogonal are new-api and adding soft-disablement?
And now for something completely different: maybe my original request is misguided. Now I'm not sure why vendors go the disabling way at all (redhat-crypto/fedora-crypto-policies#22). Maybe we should do soft-enabling instead, for writing future-proof config files that don't change effective configuration on gnutls adding new algorithms? Or allow both with smth like default=everything / default=nothing?
This is hard =)
Locked
