SC-093: Include Validation Methods in Certificates

[clintwilson]

As discussed in #459 and previously in Ballot 226 (circa 2018), there is value in having data available within Certificates indicating what domain and/or IP Address Validation Methods have been used by a CA to verify Subscriber control or ownership of the SAN values included in the Certificate.

Building on the discussion and approach determined in 2018 as most appropriate for conveying this information, this Ballot introduces two new extensions which house the Validation Methods used to issue a Certificate.

[orangepizza]

as I said on issue, onion validation methods in appendix B needs care: I won't tell which way because I'm kinda shy from being a 'intrested party': I feels I'm not worth such name, but not want to create IP problem.

[CBonnell]

Consider creating an arc under joint-iso-itu-t(2) international-organizations(23) ca-browser-forum(140) certificate-extensions(3) for the TLS BR and assigning the three extension OIDs under that.

This will ensure that there will be no conflict if other CABF documents adopt similar extensions.

[aarongable]

The complexity of this section, combined with the readable simplicity of the new table proposed by #627, makes me ask: why is Onion validation still in an appendix?

We should remove Appendix B and pull the "provide a CSR signed by the onion key" method directly into a new subsection of 3.2.2.4. Then the entirety of this new 7.1.2.12.3 can become just a single bullet point in 7.1.2.12.1.

[miguelsan-gts]

Google Trust Services does not see meaningful utility or value add by including validation method information in certificates. Others have already commented on some of these issues before but we'll highlight some of them regardless:

• Any increase in certificate size should not be done lightly. There have been comments that PQC will have an even larger impact, but Merkle Tree Certificates and other possible formats could reduce the size of certificates for many use cases, even with Post-quantum protections. Merkle Tree Certificates may also reduce the information presented for many certificates, which would mean many certificate consumers may not see the validation method information even if it was available. It is not entirely clear how certificates will evolve, but traditional TLS certificates will be around for a long time using classic ciphers for devices that cannot be updated and tend to be performance limited, so we should resist the temptation to further increase certificate size simply because some certificates are likely to get bigger because of PQC.
• Beyond the efficiency aspect, as the 'iterate over possible bitmask approaches' show, there are a non-trivial number of edge cases that would make it challenging to ensure all validation methods are consistently and correctly included, and interpreted.
• Less secure validation methods should be generally forbidden by the CA/B Forum (e.g. ballots SC080 and SC091). Deciding which validation methods are trustworthy should not be a relying party responsibility.
• The continued trend towards shorter certificate lifetimes makes the value of adding this information directly into the certificate less useful.
• The value to subscribers and relying parties is limited, but comes with a clear cost.

While more ecosystem data is nice, there are other ways to get better data on validation methods without adding bits to every certificate. One possible way would be for CAs to self-report this data via the CCADB self-assessment and having the CCADB steering committee publish an annual report. This is just one way and there are likely others. GTS would be in favor of pursuing those alternate methods instead of adding this data to certificates directly.