On Thu, Jan 25, 2024 at 05:00:19PM -0500, David Benjamin wrote: > > Second, I wanted to take a step back and try to better articulate our > goals. I think the best way to look at this draft is in three parts: > > 1. A new multi-certificate deployment model (the overall goal) > > 2. Selecting certificates within that model (the TLS parts of the draft) > > 3. Provisioning certificates (the ACME parts of the draft)
I think a bit differently: a. What information does the server have, what information it dynamically receives from the client? b. How does this drive certificate chain selection? c. How the information from client is encoded? d. How the information server has is provisioned? The reason for splitting it this way is that b., c. and d. are all important problems, all three depend on a., but only b. and c. are in remit of TLS. Oh, and I regard d. as formidable challenge, by far the most difficult part. > We’d most like to get consensus on the first, as it’s the most important. > Trust expressions are a way to achieve that goal, but we’re not attached to > the specific mechanism if there’s a better one. Well, I certainly do not have ideas for solving the problem that are dramatically different from what is in there currently. > The aim is to get to a more flexible and robust PKI, by allowing servers to > select between multiple certificates. To do this, we need a way for the > servers to reliably select the correct certificate to use with each client. > In doing so, we wish to minimize manual changes by server operators in the > long run. Most ongoing decisions should instead come from TLS software, > ACME client software, and ACME servers. The thing that makes provisioning challenging is that there is fourth party involved: Application terminating TLS on server side. I am not aware of any current (I know one that existed in the past) deployments that have ACME client software directly interface with TLS software. And I have never encountered application configuration interface I could easily see how to make it work with something like this. Most because certificate lists are either static or unordered. A more reduced scope that is likely feasible with more applications is selecting among chains for single end-entity certificate. However, such restrictions do not affect the TLS-visible parts. > Why does this matter? PKIs need to evolve over time to meet user security > needs: CAs that add net value to the ecosystem may be added, long-lived > keys should be rotated to reduce risk, and compromised or untrustworthy CAs > are removed. Even a slow-moving, mostly aligned ecosystem is still made of > individual decisions that roll out to individual clients. This means, > whether we like it or not, trust divergence is a fact of life, if for no > other reason than out-of-date clients in the ecosystem. These clients could > range from unupdatable TV set-top boxes to some IoT device to a browser > that could not communicate with its update service. Or worse, SCADA systems. Unupdatable *and* very long-lived. > Now, some of these problems can be addressed with cross-signs between CAs, > but this is a partial solution at best. Without negotiation, this still > means sending certificates for the lowest common denominator to all > clients. This wastes bandwidth, particularly with post-quantum > cryptography, where every signature costs kilobytes. Additionally, an > individual server operator cannot unilaterally configure this. Cross-signs > apply to entire intermediate CAs, not just the individual server’s > certificate. Also, having certificate negotiation lets one in most cases drop intermediates, saving a chunk of bandwidth (e.g., Let's Encrypt RSA intermediate is 1306 bytes.) -Ilari _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
