[chair hat off] Ilari said: > > I think if public key client ask is something that can signe things we could >> just ask client to sign a jws with key in question:
> That is not cryptographically kosher, and does not work with algorithms that are not in JWS. Currently, in order to get a cert you have to sign an ASN.1 CSR, regardless of what protocol you will eventually use that key / certificate for. So (I conjecture?) signing a JSON-based challenge instead of a CSR is not substantially different from a cross-protocol security perspective. That said, trying to define ACME PoP Challenges to match the protocol the certificate is for will mean an explosion of new ACME Challenges -- TLS, JWS, CWS, CMS, IKEv2, WiFi, etc etc etc -- and that sounds like an operational nightmare that will almost certainly became a security issue when people get it wrong. So I strongly vote that if we replace CSR with an in-band ACME PoP challenge, that we just do it once and not try to match the target protocol. On Tue, 10 Mar 2026 at 06:52, Ilari Liusvaara <[email protected]> wrote: > On Tue, Mar 10, 2026 at 05:57:23PM +0900, Seo Suchan wrote: > > I think if public key client ask is something that can signe things we > could > > just ask client to sign a jws with key in question: > > That is not cryptographically kosher, and does not work with > algorithms that are not in JWS. > > > > we need something else for kemtls though, because they can't sign > > anything but makeing new random shared session key > > Have server send challenge ciphertext, and then have client > decapsulate it and send MAC using the key. > > KEMTLS is not happening any time soon anyway. > > > > > -Ilari > > _______________________________________________ > Acme mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ Acme mailing list -- [email protected] To unsubscribe send an email to [email protected]
