On Wed, Mar 11, 2026 at 08:35:38AM -0500, Mike Ounsworth wrote: > [chair hat off] > > Ilari You do make a good point that if you're trying to enroll a > certificate with a subject key on some crazy algorithm that is not > registered in JWS, then you'll have a problem.
Not all of those are totally crazy. There are apparently folks wanting to use SLH-DSA in TLS (damn the performance). Also, the Chinese SM* stuff. > On the other hand, the whole objective here is to remove the ASN.1-based > CSR from ACME so that ACME implementations don't need an ASN.1 parser and > replace it with "some kind of new ACME-native CSR-like thing". To this > effect, I think that some hacked together TLS 1.3 format + X.509 > signatureAlgorithm + X.509 signatureValue is not an improvement in terms of > _removing_ implementation complexity. And as for implementation complexity in ACME, mostly just concatenating stuff into buffer, and stuffing base64url-encoded algorithm blob and base64url-encoded signature into fields in message. Some possibly annoying details with ECDSA tho. If one used just the TLS 1.3 stuff, that would do everything JWS does and more, except for ECDSA using Bitcoin curve (secp256k1). And I think the rest of the unsupported stuff tends to be from the crazier end. I know COSE has some crazy stuff. -Ilari _______________________________________________ Acme mailing list -- [email protected] To unsubscribe send an email to [email protected]
