Hi Thom, Your presentation today was good, but I just want to point out an elephant in the room that's missing from your slides: Public PKI is not currently equipped to issue KEM certificates because every cert enrollment protocol that I can think of uses CSRs at the bottom, and you can't sign a CSR with a KEM key. Back in 2021 I did some digging into which PKI enrollment protocols have Proof-of-Possession (PoP) mechanisms for encryption keys, which I presented at the Jan 2021 LAMPS Interim - see Slide 27 [1]; missing from that slide is: "ACME: No". If tls-authkem progresses, then we as a community need to have a whole debate about how much we care about PoP for cert enrollment and whether we're ok for CAs to accept un-protected CSRs (just nothing in the signature field), or whether we want to go down the rabbit hole of Zero Knowledge Proof based CSR protection such as the one proposed in [2], or re-design cert enrollment protocols to protect KEM CSRs in some other way (like CSRs signed with the ACME account key).
I am not trying to slow down draft-tls-authkem because it's good work, but please don't overlook that WebPKI is not currently equipped to issue KEM certificates and there is a fairly large amount of pre-requisite work that would need to happen before we can deploy tls-authkem at any kind of scale. [1]: https://datatracker.ietf.org/doc/slides-interim-2021-lamps-01-sessa-position-presentation-by-mike-ounsworth/ [2]: https://dl.acm.org/doi/abs/10.1145/3548606.3560560 --- Mike Ounsworth Software Security Architect, Entrust Any email and files/attachments transmitted with it are intended solely for the use of the individual or entity to whom they are addressed. If this message has been sent to you in error, you must not copy, distribute or disclose of the information it contains. Please notify Entrust immediately and delete the message from your system.
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
