On Fri, Jan 26, 2024 at 12:52:44PM -0500, David Benjamin wrote: > On Fri, Jan 26, 2024 at 5:15 AM Ilari Liusvaara <ilariliusva...@welho.com> > wrote: > > > 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. > > > > Ah sure. I was mostly thinking a step before that split. From Prague, I got > the sense it'd be useful to focus the initial discussion about why a > multi-certificate model is useful, and perhaps the high-level shape of the > solution, separate from hashing out the protocol details. I suspect if > "what are we trying to do and why" vs "here's how to provision the server" > are lumped into one discussion thread, it'll be very difficult to keep > track of things. Also the former seems more useful for questions like > whether to adopt, while the latter seems like something we can hash out > later.
As note, there are already some certificate negotiation stuff in TLS, and some servers already support choosing among multiple certificates based on those. > Beyond that, my division between 2 and 3 was perhaps a bit sloppy > there, yeah. I was just trying to capture that we've been focusing a bit > less on the ACME bits for now. Not because they aren't important or tricky, > but because I think they're not *strongly* impacted by the rest of the > design. "Some way to get multiple certs" and "some metadata to attach to > the certs" is a pretty general thing to design for. Maybe some variability > around whether we need to believe metadata update and certificate refresh > are the same operation or different. There is already means in ACME to get multiple certificates: Making multiple orders. And I think that on ACME level the metadata should be associated with issuer chains instead of certificates. It is up to server to convert that to certificate chain metadata, if that is more convinient for the server. > > 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. > > > > Yeah the ACME client <-> server configuration interface is definitely on > the interesting side. I think it's more important to preserve the graph of > what components talk to each other (i.e. the operational considerations), > than to preserve the exact interfaces between them. Obviously, the less we > have to change, the better, but I think it's also okay to have to extend > those interfaces if push comes to shove. It is requiring drastic changes to interfaces when things get bit sticky. Example of (relatively) easy problem: One has unordered set of N>1 certificate chains all passing feasible candidate filtering. Which of those chain to chose to send, deadline is in less than a millisecond? > And yeah, reduced-scope versions for some cases could also be useful. > Although the single-leaf restriction does remove a lot of the flexibility > that we'd otherwise afford the server operator, so I think we should still > design for the general case. I would argue that ACME should assume single-leaf, and then software running on the server should multiplex that into multiple-leaf if it is capable of that. And single-leaf does have some of the benefits, such as saving bandwidth. > In particular, I think these reductions not only don't have to affect the > TLS-visible parts but also most of the ACME-visible parts either. Unless > I've just missed it, ACME itself does not specify how the certificates make > their way into server software. The ACME client can always filter out any > certificates the particular TLS software cannot handle. The ACME client can > freely transform its output to whatever the other end wants. If ACME hands > back multiple PEM bundles[*], but a single combined structure would be more > convenient for some server software, the ACME client can just combine them. I think it does not affact TLS-visible parts, but it does affect ACME- visible parts. It is much easier to go from single-leaf to multi-leaf than from multi-leaf to single-leaf. Yes, ACME technically allows multi-leaf. The way vast majority of ACME clients handle that is dropping all but one (and doing anything more fancy does not exactly seem feasible). > > Or worse, SCADA systems. Unupdatable *and* very long-lived. > > > > Yup. And in those environments, that may well be a reasonable choice! I > don't work on SCADA, so I can't really say much. But the Web has different > needs, and if you're a server that straddles both kinds of environments, > you will have a hard time today. I don't work on SCADA either, but have heard lots of horror stories. -Ilari _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
