hi Mark, On Thu, 17 Jul 2025 at 23:04, Mark Novak <mr.mark.no...@gmail.com> wrote: > > Looking forward to meeting everyone in person. > I am looking forward to discussing my key concern with this proposal: whether > it is really necessary to combine credential issuance with secure channel > negotiation. Not to say it’s impossible, of course it is, but is it > practical? Specifically, two most common types of workloads today are those > that horizontally scale, and serverless ones. In both cases you want to reuse > the same credential key and you want to limit the load on the verifier and > the credential issuer. The best approach is allay the most architecturally > sound one: separate the concerns; procure the credential once and not hit the > verifier each time a TLS channel is established.
The question can be reversed. Is the aCSR approach always practical? There are multiple dimensions at play. A few that spring to mind: the freshness requirements associated with the RP's appraisal policy, the expected lifetime of the secure channel compared to freshness expectations, and operational costs. Starting from the latter and moving backwards. Adding a CA/RA box to the system architecture incurs a high operational cost, in addition to the unavoidable cost of running an attestation verifier. In some deployments, it may be possible to amortise such costs, but this is not always feasible. If your RPs have tight freshness requirements, an aCSR-based solution would need to mint fresh, very short-term certificates at a sustained pace. Each certificate refresh would necessarily hit the back-end verifier, which renders the "better scalability” argument a bit moot. Besides, if the secure channel is long-lived, managing the periodic refresh of the attestation credential may be challenging. The two options I can see are: 1. Tear down the secure channel and re-establish it with the new credential. 2. Implement an application-specific refresh method. Both options are feasible, but not ideal: the former option requires extra coordination to handle the path switchover, and the latter option makes the application responsible for providing its custom RA protocol. We (or at least I) are big fans of aCSR. However, after giving this some thought, I’ve come to the conclusion that it cannot meet all requirements in all cases. To clarify the ethos of the expat effort: We are not claiming that expat is a better solution in general. We just want to add more standardised (and formally verified) mechanisms to the attestation toolbox so that people have more options. cheers! _______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
