On Mon, Apr 13, 2026 at 12:19:48AM -0700, David Benjamin wrote: > On Sat, Apr 11, 2026 at 7:00 AM Ilari Liusvaara <[email protected]> > wrote: > > > MTC sigalgs_cert would not be useful. That RP supports MTC does not mean > > that RP supports the required signature algorithms. As noted above, > > there are cases where sigalgs_cert can not be ignored. > > > > And sigalgs_cert is only redundant with direct issuers using modern > > algorithms, not indirect issuers or legacy algorithms. > > > > Yup, I think we're agreed on that. I mentioned a pro forma sigalgs_cert > purely because TLS has this SignatureScheme <-> X.509 signatureAlgorithm > correspondence. I don't actually think it would be *useful*. (But I also > don't think sigalgs_cert is terribly useful in itself.) Just TLS tries to > match those up, so OK. I thought that's what you were referring to, but > sounds like you meant something else. *shrug*
Now that there can be only one CA cosigner per log, I think it would be useful to have new certificate property that causes sigalgs_cert to be ignored for that certificate when matched by ID. This would be useful for cases where there is direct signer that only ever uses one algorithm. Which is now always the case with MTCs. Also, if there is no MTC sigalgs_cert, that would keep MTCs away from default negotiation, which is very important for deployability (MTC accidentally ending in default negotiation is very bad thing). -Ilari _______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
