Hello Mark,Thank you for sharing your "key concern", but I don't think it is a concern at all. What you are describing is a RATS passport model and it is already covered in Sec. 4 of the proposal [3]. Some notes below:
On 17.07.25 23:03, Mark Novak wrote:
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?
Given that slide 2/9 in [1] is filled with a bunch of solutions (most of them /deployed/ already) is sufficient of an evidence that it is practical. There are a bunch of other /practical deployments/ which are not even listed on the slide, because the intention of the proponents was to show the technical design choices, and that fragmentation exists in the industry leading to a need for standardization.
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.
Whether it is "best" depends on the use case and the criteria, and cannot be generalized.
Anyway, both [1] and [2] point to the draft [3], and Sec. 4 of the draft [3] already covers this case. Could you tell precisely what in [1] and/or [2] leads you to believe that it is not covered?
[1]
https://datatracker.ietf.org/meeting/123/materials/slides-123-expat-design-space-of-attested-tls-00.pdf
[2]
https://github.com/tls-attestation/exported-attestation/wiki/BoF-Charter
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
