On Mon, Oct 23, 2023 at 03:04:05PM -0400, David Benjamin wrote: > > The note about sharing an EE cert is just a SHOULD, not a MUST. RFC 8555 > doesn't say why, but our interpretation was, like you note, this was mostly > a concern for things like accounting for renewals and revocations. We tried > to firm that up a bit by saying this makes sense when you're willing to > issue and renew all the variants together. For something like ARI, I was > imagining the ACME client would just check all of them (we're already > assuming the ACME client has been updated) and, if it needs to renew any of > them, it goes ahead and renews all of them. Slightly wasteful if renewal > was triggered by one of them getting revoked, rather than them all expiring > together. But I expect that's not common enough to be worth optimizing for.
I think ACME client are expected to pick one of the alternates and discard the rest. > Do you think multiple orders would be better? A multi-order flow is > probably more complex than fits in this document (this ACME change is > pretty small), so we didn't start with it. Plus this initial version seemed > natural to us based on what ACME had already defined. But we're much more > interested in making this kind of multi-certificate deployment model > possible than any of the particular details. Happy to adjust things based > on what turns out to work best. (One nuisance with a multi-order flow is > that the CA will have a harder time linking the requests together, which > opens a can of worms around whether they do separate validations or not.) Multi-order flow is no more complex for ACME. It is also just requesting extended information. However, I think that the design space is severly constrained by TLS server configuration. I do not think any TLS server is capable of handling either flow without drastic changes to how certificate configuration works. What I think could work is shipping one certificate with its default issuer chain, plus alternate chains with trust expression info, all in one package. This would avoid the highly problematic variable grouping of certificates. When using certificate, the TLS server could select a certificate and then change to alternate chain depending on the RP support. > I think having to do a round of updating existing clients is fine here. > We'd already need to teach them to implement this thing. But if we think > putting them in one bundle is more convenient, that's fine by me too. I > don't actually care. I think that depending on the design, the TLS server changes may be less than fine. And at simplest designs, the ACME client changes could be just adding accept to certficate fetches and updating the type whitelists to accept the chain override info. > Exploring that direction a bit, won't that make issues around ARI and > different issuance rates worse? Bundling them means the system is further > inclined to treat them as one unit, but a lot of these problems come from > wanting to be able to treat each path separately, be it different renewal > times, different issuance times, potentially even different private keys > associated, etc. I also worry it'll get a bit thorny as it passes through > the layers. E.g. if the TLS serving software expects one PEM file to be one > certificate chain, but the TLS library secretly turns it into multiple > alternative chains, the rest of the logic will break. (E.g. imagine if the > serving software knows to set up OCSP stapling or otherwise associate data > with the cert it's serving.) Normal OCSP and SCT will work just fine even if TLS library secretly turns PEM files into multiple chains. The stuff that would break is quite exotic (e.g., multi-OCSP). And I expect vast majority of even such exotic stuff to work okay if TLS library just drops all the problematic stuff on chain override (e.g., downgrading multi-OCSP to normal OCSP). In contrast, if there are multiple distinct certificates or chains, those need to be handled as unit. Which is not something present TLS servers are capable of doing, because nothing else requires that. > Ah, this is "expiry" in the sense of actually removing the root from v2? > I.e. distinct from what our draft (somewhat confusingly) calls expiry. (Our > "expiry" relates to this cross-version issue.) Expiry in sense of removing the root from all versions. I have heard some roots are considering limiting the root certificate lifetime. So individual root programs might have different expiry date from the one contained in the root certificate (and there may be multiple versions of the same root with different lifetimes!). > Yeah, we don't have that right now. Though I think most cases don't need > explicit expiry information. Since this is used for negotiation, not trust, > it doesn't actually matter if v2 contains some roots that have expired, as > long as both RP and CA agree on when this happens. I.e. *for negotiation > purposes*, it makes no difference whether an expired, no longer issuing > root is in the v2 set or not. Of course, it does matter for security > purposes, so the RP definitely needs to no longer accept signatures from > that key. And if the RP and CA don't agree on the root's expiration time, > such that the CA continues to issue from the root, then that doesn't work > and we may need explicit expiry in the system. (Though I might suggest that > RP and CA disagreeing is kinda odd. We're talking here about cases where a > root would *automatically* get removed from v2, e.g. directly trusting a > short-lived intermediate. In that case, the CA should know this ahead of > time and, if they don't have a root that's of the desired lifetime, just > spin up a new one. The great thing about this deployment model is that > spinning up new roots for new purposes can be basically free.) Spinning up new roots is still quite expensive to do. > Anyway, happy to add something like that if folks think it's useful. The > main cost is a little complexity: one more moving part in the system, and > having to explain that (example, v2) is not actually a fixed set and slowly > shrinks over time. But I think it'd work just fine. Only CAs and RPs would have to care about expiry. TLS servers would not, because expiry is indirectly incorporated into information for TLS servers. > Oh, were you thinking that label changes propagate back to old versions, > and that way you just update the CA -> subscriber record for new issuances? > I was thinking they wouldn't, because then we have to reason about what > kinds of retroactive changes are compatible with older RPs. If we don't > retroactively change things, the CA -> subscriber message needs to support > saying things like "from v1 to v10 you had these labels, from v11 to v20 > you had these other labels". And if we're going down that road already, we > figured, eh, this is a premature optimization, we can just list all the > versions one by one and not worry about ranges. (But I'm also not opposed > to doing ranges. If people prefer that, sure, let's do that.) What labels seem to be used for is signaling to TLS server what trust anchors have been recently dropped that the TLS server might not know about yet. There is one situation where older RP uses labels, but it is SHOULD NOT, and presumably will use TA unique index. And changing TA unique index is Bad Idea and never necressary. And label changes do implicitly propagate back to older versions: The TLS server will usually use the newest version data it has available to interpret the indices it recevies. Things can break if interpretation of the indices has changed since! > One of our assumptions here is that arbitrarily out-of-date RPs may exist > indefinitely. Some RPs don't auto-update. Even among those that do (e.g. > browsers), some clients may not have talked to their update server. And > open source code ends up all over the place, so I don't want to discount > the possibility that some server may care about serving, say, arbitrarily > outdated Chromium derivatives. That means we shouldn't incompatibly change > the meaning of past trust expressions that refer to past trust store > versions. Easiest way to do that, I think, is to just keep the meaning of > "(example, v2)" fixed. Yup, old RPs can exist for very long time. Old servers can exist for certificate lifetime. One bit nasty edge case: Suppose a root is transferred from CA A to B. So its owner index is changed from idx_A to idx_B. Then very soon after, all roots of CA A are distrusted (but not the recently transferred root). RP can not send idx_A, because it could be misinterpretted by servers. Instead, it must send unique indices of all roots of CA A. > Oh yeah, I'm assuming you'd parse this into some seekable in-memory > structure. The sort order isn't *that* important because you could just as > easily sort them after parsing. Just an easy way to save some effort on the > receiver, and make validation straightforward. I suppose we could make an > actually seekable structure on the wire, but it wouldn't be very TLS-y, and > seems far, far more fuss than is worth it. :-) Or use B-Tree, which is auto-sorted. :-) -Ilari _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
