Thanks for the comments! Responses inline. On Thu, Oct 19, 2023 at 3:17 PM Ilari Liusvaara <ilariliusva...@welho.com> wrote:
> Some quick thoughts: > > - The multiple certificates from one ACME order really scares me. It > seems to me that can lead to all sorts of trouble. > Certainly open to different mechanisms, though could you elaborate on the trouble? We started with this one because it's actually just fixing a mechanism ACME *already has*. RFC 8555, 7.4.2 has this bit: The server MAY provide one or more link relation header fields [RFC8288] with relation "alternate". Each such field SHOULD express an alternative certificate chain starting with the same end-entity certificate. This can be used to express paths to various trust anchors. Clients can fetch these alternates and use their own heuristics to decide which is optimal. https://datatracker.ietf.org/doc/html/rfc8555#section-7.4.2 Whether anyone has ever used this, I don't know. The "and use their own heuristics to decide which is optimal" bit is quite absurd. :-) Relative to that, all we've done is: - Go ahead and define some format for a chain + properties... I like PEM much, but hey if ACME does that, we can just mimick that. - Fix the heuristic. You don't need heuristics when you have robust negotiation. But I suspect we'll want to define one where you make multiple orders too. That would probably work better for, e.g., Merkle Tree certs where the two issuances complete at very different times. But then, conversely, when the two paths actually share an end-entity certificate, I imagine a single order would be better so the CA knows it only needs to generate one signature. And then when they don't share an end-entity certificate but are similar enough in lifetime and issuance time, either seems fine, so we figured this was a reasonable starting point. > - If there can be only one certificate, one could send all the chains > in one go via fist sending the certificate, then issuer chains each > ended by entry describing the trust anchor. > I'm not quite sure if I've parsed this right, but are you thinking of one file that somehow describes all alternatives together? That's plausible too. Like I said, we mostly did this one because ACME already did it, so we inferred that was The ACME Way. :-) > - The latest version and previous version stuff seems pretty confusing > to me. > Yeah, it took us many iterations to find a good way to describe it, and I'm sure we haven't gotten it right yet. It's all to deal with version skew cleanly, when the relying party references a newer trust store than what the subscriber knew about at the time the certificate was issued. Since it seems your suggestion below relates to this, maybe some of the discussion below will help us clear it up and get to a better description? > - I am not sure this is useful for the client->server direction. > Eh, it costs ~nothing to define it in both directions, just a global s/client/relying party/ and s/server/subscriber/ across the document. :-) I figure we may as well define it in both directions, and if some client certificate deployments find it useful, cool. On the Chrome side, if the operating systems could give us something like this, with pre-made paths and unambiguous rules for when to send each, I would be overjoyed. We spend quite a lot of time helping people debug misconfigurations and quirks around client certificate selection. > What I think is a simpler version that might work: > > > Information from root program to CA: > > - Root program name. > - For each trust anchor: > * Trust anchor certificate. > * First version TA appeared in. > * Expiry time > * List of indices. > > Indices can be reused after all TAs using those have expired. > > > Information from CA to TLS server for each TA: > > - For each root program: > * Root program name > * The first version TA appeared in. > * List of indices. > > CA MUST NOT include entries that expire before the certificate. > > > Information from TLS client to TLS server: > > - Root program name. > - Root program version. > - List of revoked indices. > > The revoked indices specifies TAs that have been recently removed > before expiry (there could still be unexpired certificates out > there). > > > Chain is usable if it includes an entry where: > > a) Root program name matches, AND > b) Root program version is at least the first version, AND > c) Intersection of indices and revoked indices is empty. > > If TLS server has multiple configured certificates, it should skip ones > that have no usable chains. If no certificate has usable chain, it > should act like the extension was not sent. > If I'm parsing this right, I think the main issue here is this presumes a removed CA will stop issuing certificates: Suppose some CA is in v2 and then was removed in v3. We need to ensure certificates issued by that CA don't match a v3 client, so the server will send a different one. Immediately after removal, there are plenty of existing certs that predate v3's definition, so the relying party needs to ship in exclusion. However, we would like the exclusion to eventually fall off, or every historical removal will be sent in every ClientHello ever. If the CA ceases operation, the exclusions can be dropped then. But the CA may have good reasons to keep issuing. Consider root rotation. Unupdated clients won't trust the new root, and servers may still need to work with those clients for a long period of time. The CA may quite reasonably wish to continue issuing from that root until that is no longer the case. This may even happen during a distrust: it could be that one population of clients no longer trusts the CA, while another population of clients (perhaps some unupdatable devices somewhere) *only* trusts that CA. Servers that need to serve both populations could then deploy a different certificate for each, in which case the removed CA might continue issuing. It only takes *one* population of relying parties for it to be useful to keep issuing from that CA. And as long as *any* server has certificates from that CA installed, we need to account for them in cert selection somehow. The way to square this is to have both a lower bound *and* an optional upper bound. If the CA knows it in v1, v2, but not v3 onwards, it can tell the server this. Once you add the upper bound, I *think* your sketch is basically our design (though I may have missed something). The main difference is rather than store a range in manifest and inclusion list, we've just listed each version individually. If you've got a latest_version_at_issuance entry, it means the range has no upper bound. We listed them out because that makes versions a bit more independent, which allows the root program to adjust its label allocations over time. For example, maybe the root program later decides it'd be useful to mark CAs that use some algorithm. Or perhaps some keys changed hands and we'd like to reflect that in the labels. Now, there's a little subtlety here because label changes take some time to be reliable. But after max_age + max_lifetime, all certificates will have the new information available. (Before then, the trust expression creation process will just tell you that you need to account for both old and new entries, so you may need to add a few more labels.) Also, when we went to describe the root program operation, it was much more straightforward to just talk about versions as independent, with minimal cross-talk between them. Of course, labels probably won't change between versions much, so a range scheme would make the list more compact. We didn't go with that just because the exploded one was less complicated. We did some estimates and it didn't look like the compression was actually needed, so we omitted it. (These are not sent in TLS connections, just in the root program -> CA -> subscriber flow. We don't want them to be *humongous*, but we don't need to squeeze them that tightly.) But if folks prefer ranges, that's easy enough to add. > > ---------- Forwarded message --------- > > From: <internet-dra...@ietf.org> > > Date: Thu, Oct 19, 2023 at 11:36 AM > > Subject: New Version Notification for > draft-davidben-tls-trust-expr-00.txt > > To: Bob Beck <b...@google.com>, David Benjamin <david...@google.com>, > Devon > > O'Brien <asymmet...@google.com> > > > > Name: draft-davidben-tls-trust-expr > > Revision: 00 > > Title: TLS Trust Expressions > > Date: 2023-10-19 > > Group: Individual Submission > > Pages: 35 > > URL: > > https://www.ietf.org/archive/id/draft-davidben-tls-trust-expr-00.txt > > Status: > https://datatracker.ietf.org/doc/draft-davidben-tls-trust-expr/ > > HTML: > > https://www.ietf.org/archive/id/draft-davidben-tls-trust-expr-00.html > > HTMLized: > > https://datatracker.ietf.org/doc/html/draft-davidben-tls-trust-expr > > > > > -Ilari > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
