Divergence and Fragmentation section assumes a conclusion

[dadrian]

In Divergence and Fragmentation:

Trust Expressions and Trust Anchors, by enabling trust negotiation and a multi-certificate model, allow the existing Root Programs to diverge arbitrarily in their policies. This means Root Programs can adopt weaker security requirements than the CA/BF and websites can adopt these certificates without losing availability.

This suggests that trust anchor negotiation only allows root programs to loosen, rather than strengthen requirements. This is inaccurate in three ways:

1. Today, the purpose of the CA/BF baseline requirements is to facilitate the interoperability of independently-defined root program requirements to aid CA compliance. The areas in which root programs requirements do not agree are not specified in this baseline, both when such requirements are stronger than the baseline and when they are weaker than it. In other words, a root program can already choose to adopt weaker security requirements than in the CA/BF baseline requirements.
2. Trust Anchor Negotiation enables security-conscious root programs to enact stronger requirements that are currently unable to be adopted due to the need for ubiquitous consensus among must-support root programs, thus requiring the “weakest” root program to adopt all such requirements before they become possible to enforce, if ever.
3. Clients who require broad compatibility with servers that require compatibility with old devices are prevented from enforcing requirements on the servers if that would cause the servers to lose compatibility with old devices. In this way, lacking a negotiation mechanism anchors the strongest possible security to the lowest common denominator.

[dennisjackson]

Trust Expressions and Trust Anchors, by enabling trust negotiation and a multi-certificate model, allow the existing Root Programs to diverge arbitrarily in their policies. This means Root Programs can adopt weaker security requirements than the CA/BF and websites can adopt these certificates without losing availability.

This suggests that trust anchor negotiation only allows root programs to loosen, rather than strengthen requirements.

It does not. It states that 'can adopt weaker requirements' is a consequence of 'can diverge arbitrarily'.

2. Trust Anchor Negotiation enables security-conscious root programs to enact stronger requirements that are currently unable to be adopted due to the need for ubiquitous consensus among must-support root programs, thus requiring the “weakest” root program to adopt all such requirements before they become possible to enforce, if ever.

This is factually wrong. Root Programs already enforce requirements well in excess of the CABF baseline and do so as a matter of course. Example: Certificate Transparency.

Can you give a real or hypothetical example of a stronger requirement that is currently unable to be adopted?

3. Clients who require broad compatibility with servers that require compatibility with old devices are prevented from enforcing requirements on the servers if that would cause the servers to lose compatibility with old devices. In this way, lacking a negotiation mechanism anchors the strongest possible security to the lowest common denominator.

Can you give an example?

[nharper]

3. Clients who require broad compatibility with servers that require compatibility with old devices are prevented from enforcing requirements on the servers if that would cause the servers to lose compatibility with old devices. In this way, lacking a negotiation mechanism anchors the strongest possible security to the lowest common denominator.

Can you give an example?

That sounds like the same question as in https://github.com/dennisjackson/trust-negotiation-comments/issues/7#issuecomment-2241267048 - see my answer on that issue.

[dennisjackson]

Closing as a dupe of #7