GnuTLS support

[janbrasna]

This is a meta issue tracking the feasibility of supporting GnuTLS configurations either in the same template, or a separate template — to assess whether the current recommendations can be adapted to the necessary priority strings, able to redefine OS-level defaults etc. to apply meaningfully and in a predictable consistent way.

### Config compatibility
- [ ] https://github.com/mozilla/ssl-config-generator/issues/115

[gstrauss]

HandlebarJS might not be the best choice. At a certain point it may be easier to write the logic directly in javascript. GnuTLS priority strings are easier to construct with a language like javascript than to contort through more limited HandlebarJS templating directives.

[janbrasna]

The actual value for render would almost certainly be constructed within the js app and only passed to the output object for templates to (conditionally) use.

Where I am not sure considering the templating logic is, whether we'll be able to deliver both OpenSSL and GnuTLS options within a single config (given the lib used is defined for each template) without some UI & settings refactoring, or monkey patching one implementation atop the other if we only keep one defined in the configs.

(Compare to e.g. OpenSSL vs. JSSE implementations, where both IANA and OpenSSL input is understood, validated, and iterated over being translated to the underlying api by the server, making that issue opaque to us, allowing to just emit one config and let the server adapt the values for the actual implementation eventually used.)

The biggest challenge is whether the existing json data provide enough surface to even derive the possible priority strings. (It's super tricky to get them right, and I don't even know how well would they work across different systems. But that would definitely make an important addition to have that available here as a boilerplate.)

[janbrasna]

Ah, yeah there's .ifdef mentioned in #115 (comment) — https://www.exim.org/exim-html-current/doc/html/spec_html/ch-the_exim_runtime_configuration_file.html, so perhaps there is a chance even exim could be rendered for both in one template 💟 🚀

But the more I think of it, the less I'm sure we should invent the priority strings here — I'd say they ought to be defined directly in the recommendations, as a counterpart to the other configs, and only consumed here afterwards.

[gstrauss]

#115 already exists. I will be converting this open-ended discussion to a github Discussion.

This is a meta issue tracking the feasibility of supporting GnuTLS configurations

If there is a well-scoped item on which you plan to work to move that experiment forward, that can be created as an issue. If there is no commitment from anybody with the time or skills or inclination to move this forward, then please continue in a github Discussion.

[gstrauss]

Constructing a GnuTLS priority string, which includes TLS versions, ciphersuites, ciphers, groups/curves, (and more) could be done as a Handlerbars helper function -- which is javascript -- which takes _state.form and _state.output and returns a GnuTLS priority string. The Handlerbar templates would have to {{#if ...}} around all of the OpenSSL directives which would be replaced by the GnuTLS priority string. While it could be done in templates, I do not see any advantage to doing so and I do see many more template {{#if ...}} conditionals.

Expanding the guidelines to have entries for both OpenSSL syntax and GnuTLS priority string syntax for each parameter is another option, but for better code design the guidelines should specify the guidelines, and, separately, there should be tables (shared code in javascript) which map the guidelines to OpenSSL syntax and to GnuTLS syntax.

[gstrauss]

Prior technical work/survey on this topic was last touched in 2017 in
mozilla/server-side-tls#30 (comment)
mozilla/server-side-tls#30 (comment)