JB: More clarification on the use of symmetric encryption algs for source authentication

John says:

in sec 4 we say "To encrypt, JWE [RFC7516] is used. Unless the algorithm used in JWE allows for the source to be authenticated"

In sec 10.1 it may be a good idea to say what encryption alg allow the source to be authenticated. That is not necessarily obvious to people. All of our supported enc algs are AEAD (Authenticated encryption with Associated Data". That identifies the sender as the one with the CEK. However the choice of alg "dir" or "A128KW" where both sides can identify each other via the common CEK or JWE Encrypted key-value. However it seems not to be obvious that als like "RSA-OAEP", "RSA1_5" , "ECDH-ES" , and "ECDH-ES+A128KW", do not have the property of having a shared secret, and allow anyone to encrypt a message to the receiver.
I think that is the source of the question around symmetric or asymmetric keys. Direct and symmetric KW have the property of authenticating the sender assuming the key is secret while the other alg, by design allow any sender to encrypt a "authenticated message" to the receiver.
I think the one review comment was trying to restrict the alg options to direct and AESKW if you are signing only. They didn't say that but I think that was what they were trying to get at. We can leave open the option to provide secrecy without sender authentication, and ust put it in the security section 10.1 or make it normatively more restrictive. The shortcut of encrypt only is a bit of a edge case and I prefer not to let people soot themselves in the foot with it.

I just don't want someone using RSA-OAEP without signing and believing that the auth request comes from the Client indicated in the issuer. You know someone will.

I will look at sec 5 again and propose some text for the security consider action to explain why.

Comments (4)