Section 11.2 makes both points. Encrypting and then signing is likely only a special case used by some applications that are configured to understand what is going on. If you are going to do it in that order you would want to be certain that you don't accept a JWT that has no signature.
Stripping a signature shouldn't buy an attacker anything with a properly configured recipient. However it might possibly confuse some application logic. We are making a best practice recommendation in 11.2 but there are circumstances where it might make sense for a application to do something else. John B. In general any asymmetric On Oct 7, 2014, at 1:13 PM, Ted Lemon <[email protected]> wrote: > On Oct 7, 2014, at 10:57 AM, John Bradley <[email protected]> wrote: >> The main reason for signing inside the encryption, tends to be legal in that >> a signature over something you can't see is not considered enforceable most >> places. >> So if you are signing for non repudiation then inside the encryption is >> typically required. > > The document currently warns that if the signature is not encrypted, it would > be possible to encrypt the message, sign it, and then an MiTM could strip the > signature. This seems to contradict what you are saying here. Not being > an expert, I am probably missing something, but what you actually recommend > should be consistent; if in fact in the scenario you are talking about the > stripping of the signature wouldn't buy the attacker anything, you should say > so. > > To be clear, what I am asking for is just that the document make sense to > someone who doesn't know all the properties of all the crypto algorithms. > Based on what I've heard so far, I'm not suggesting that you need to add any > new requirements. And I'm just asking, so if I'm really talking through my > hat, you are free to just ignore me! :) > _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
