Sure, but unlike the CRL checks the server gets to directly know how recently the client fetched the update if my understanding is correct. Knowing which landmarks the client has would likely give you a fairly precise picture of the update time, since more frequent landmarks yields smaller MTC proofs.
Spitballing here, would it still meet the needs of the protocol if the client offered which MTCAs it has (no version information), the server sends back some “typical” depth (say, 3 levels up the tree), then the client can decide to either:
* Accept the MTC
* Request a deeper traversal, following some super linear growth like fib numbers. In that case, they’d communicate “give me up to 5 nodes above your leaf”
* Reject the MTC
* Request the full certificate for “traditional” validation
The server still has a side channel for “how recently updated is this client” by knowing how many levels of inclusion proofs needed to be shared, but this is much less signal than knowing exactly which landmarks a client has.
Spitballing here, would it still meet the needs of the protocol if the client offered which MTCAs it has (no version information), the server sends back some “typical” depth (say, 3 levels up the tree), then the client can decide to either: * Accept the MTC * Request a deeper traversal, following some super linear growth like fib numbers. In that case, they’d communicate “give me up to 5 nodes above your leaf” * Reject the MTC * Request the full certificate for “traditional” validation
The server still has a side channel for “how recently updated is this client” by knowing how many levels of inclusion proofs needed to be shared, but this is much less signal than knowing exactly which landmarks a client has.