Interesting. It does seem that being more agile in PKI deployment is going to be a requirement in the next few years as we grapple with rolling out a potentiall

Interesting. It does seem that being more agile in PKI deployment is going to be a requirement in the next few years as we grapple with rolling out a potentially interesting variety of PQ signatures and hybrids. Especially considering exploding PQ signature and key sizes, this looks increasingly like a data synchronization problem between the server and clients. I wonder if we could kill two birds with one stone by using trust expressions consisting of a set of certificate indexes against a trust store database, instead of trust store versions and exclusion labels. In that model, a trust store is just a centrally managed list where each certificate is assigned a unique 64-bit index. For example, a client says "I use trust store database XYZ with certificate indexes: <ordered, integer compressed 64-bit index list, maybe a couple hundred bytes>". The server constructs (or pulls a cached copy of) a trust chain from one of the listed roots and sends it to the client. Intermediate certificates may also be stored in the trust store database - and cached on the client. In subsequent requests, the client may include those intermediate indexes in their request, allowing the server to respond with a shorter chain. Clients with an old, long trust chain might have a long first exchange, but after caching intermediates can have a much faster/shorter negotiation. As certificates expire, they are removed from both the trust store database, as well as the client's cache - naturally moving the 'working window' of certificates forward over time. This shifts a bit of work on the server, but dramatically reduce complexity on the client. The client just states which certificates it has and what algorithms it supports, and the onus is placed on the server to return the "shortest" chain that the client can use as a proof.