[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.
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. On Wed, 11 Mar 2026 at 07:22, Ilari Liusvaara <[email protected]> wrote: > On Wed, Mar 11, 2026 at 06:18:23PM +0900, Seo Suchan wrote: > > I suggested jws because ACME already based on JWT > > messages signed by account key, so it doesn't > > bring anything new to the table. If Eve is able to > > forge acme message we are toasted anyway > > This is certificate key, not account key. The only place where ACME > currently uses JWS for certificate key is revoke-by-private-key. > > ... Which has an issue that if certificate key is something that is > not supported by JWS, then it can not be revoked by private key. > > And using JWS here would similarly have an issue that it does not > support signature keys that are not supported by JWS (but are supported > by some other protocol the keys are for). > > > > > -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]
