On Tue, Mar 10, 2026 at 10:00:17PM -0500, Mike Ounsworth wrote: > [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.
If it is safe or not gets rather far into the weeds on how exactly those things work. - TLS 1.3 signatures always start with 0x20. - X.509 signatures always start with 0x30. - JWS signatures always start with 0x65. - COSE_sign signatures always start with 0x84 or 0x85. * But countersignatures can also start with 0x86. - TLS 1.2 signatures start with 32 byte client-specified(!) prefix. ... > 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. Sigh, the only thing that works across all those are X.509 signatures. Which does not play nice with privilege separation, as it would require ASN.1 code in where you really do not want it. E.g.: - TLS has slhdsa_sha2_128f, which JWS and COSE_Sign do not. - JWS and COSE_Sign have ES256K, which TLS does not have. - COSE_Sign has ESB320, which JWS and TLS do not have. Altough it would be possible to use TLS 1.3 format, but encode the signature as X.509 signatureAlgorithm followed by X.509 signatureValue. That would avoid the issues with privilege separation, but still work with everything. I suppose one could use byte string for signature value, as I have never seen anything use bitstrip in signatureValue. For KEMs, all the modern stuff is nicely behaved (byte string I/O). It is only some legacy stuff (e.g., RSA, classical ECDH) where there are issues. -Ilari _______________________________________________ Acme mailing list -- [email protected] To unsubscribe send an email to [email protected]
