Dear all, I believe this draft has substantial security issues that are similar to ones that have been exploited unsafely, often and extremely well. This draft equates public key signatures with Message authentication codes. MACs depend on having a shared key that is secret, and anyone who knows the key can make a signature. Public key signatures separate a private and a public key, and those with the private key may sign, those with the public key can verify. These are different notions with different requirements on what the material they are used on must have. But the draft uses exactly the same container and the same language to refer to them, inviting that same confusion in the mind of a reader, and the library author to blithely permit the algorithm in the message to be used. This mistake in JWT lead to bug after bug in library and application. Now we learn nothing, and choose once again to invite disaster with a small oversight on the part of application authors. No, security considerations will not prevent this mistake, and the ones in the draft are woefully inconsiderate: they do not clearly indicate who must do what, or refer to the details of the past bugs to indicate why it is required. I believe we need a section to describe what libraries must do with their interfaces to prevent such hazards and how application developers must avoid them in system design. Instead we get that the secure way is merely encouraged. This is not good enough: I believe the signature spec should remove the algorithm entirely, letting the key provided to verify indicate what is to be done. Or, if that isn't possible use MUST language to indicate that the allowed signature algorithm (singular) MUST be passed in with the key, that the verifier MUST NOT look at the message to find the algorithm used. This of course means revising 3.2 step 6 to remove looking at the message. Sincerely, Watson Ladd -- Astra mortemque praestare gradatim -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
