Hi Uri, all, Op di 4 okt. 2022 om 17:07 schreef Blumenthal, Uri - 0553 - MITLL < u...@ll.mit.edu>:
> CSR is supposed to be signed by the corresponding private key to prove > possession. Obviously, it cannot be done with a key such as described > above. How is this problem addressed in the real world? With AuthKEM and > KEMTLS, how would these protocols get their certificates? > Yeah, that's something that came up a few times while we were working on KEMTLS (and it eventually resulted in this paper by Güneysu, Hodges, Land, Ounsworth, Stebila, and Zaverucha [1]). They also have some nice references for the kinds of attacks that "sloppy" issuance could lead to in Appendix A. I've not tried to work out if they apply to TLS/KEMTLS/AuthKEM, but ruling them out anyway because of the many applications of certificates seems worth it. A different naive approach for issuance (that I have done zero security analysis on) could be simply creating the cert for key PK and encrypting it to a key encapsulated to PK. Then the owner of PK would need to decrypt the certificate; using it the first time immediately proves possession. Of course, in the real-world we also have things like CT logs and such; and it would be terribly annoying if I could spam you with CT log alerts for yourwebsite dot com. So this approach doesn't seem very favorable over a "fancy" ZKP or interactive approach. We weren't aware of CRMF, so it seems I've got some reading to do as I write some paragraphs on KEM certificates in my PhD thesis :) Cheers, Thom [1]: https://www.douglas.stebila.ca/research/papers/CCS-GHLOSZ22/
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
