- From: Watson Ladd <watsonbladd@gmail.com>
- Date: Tue, 13 Jul 2021 21:55:16 -0700
- To: Justin Richer <jricher@mit.edu>
- Cc: Christopher Langton <chris@langton.cloud>, "public-credentials@w3.org" <public-credentials@w3.org>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
On Tue, Jul 13, 2021 at 5:03 AM Justin Richer <jricher@mit.edu> wrote: ><snip> Not only that, but it's supposed to be lower priority than other sources for this info, so if you're doing things right an attacker won't be able to substitute at all. Why have it at all? We have been down this road with JWT, and hack after hack later, finally sort of maybe learned how to do it right. Having this algorithm field invites mischief either through bug or doing things wrong, and signing it doesn't help. We should strive for specs that cannot be used unsafely, not ones that can be used safely. MACs and signatures are not the same. Using them interchangeably is a mistake. Letting the signer specify which one to use is a mistake. There's really no excuse here: store the signature algorithm with the verification key, not in the incoming data to be verified, even if you must call HMAC a signature. Sincerely, Watson Ladd -- Astra mortemque praestare gradatim
Received on Wednesday, 14 July 2021 04:55:41 UTC