They provide integrity protection for the encryption, that is very important for preventing padding oracle attacks.
AES GCM <https://tools.ietf.org/html/rfc7518#section-5.3> and AES_CBC_HMAC_SHA2 <https://tools.ietf.org/html/rfc7518#section-5.2> are both examples of Authenticated Encryption <https://en.wikipedia.org/wiki/Authenticated_encryption> in the sense that the received encryption is true and not that the sender is identified. English speakers have a hard time with the subtle difference between identification and authentication , so I wanted to be clear. That being said there is a special case where if the JWT ie encrypted with a symmetric key known only to two parties and it is “authenticated” and you didn’t create it, then by a process of elimination it cold have only come from one party. This is NOT a signature, however it is a useful trick that some people use to only encrypt and while still knowing with relative certainty who encrypted it. I should note that ECDH-SS rfc6278 a key agreement algorithm we didn’t put in the base JWA spec also has the property of providing encryption and authenticity based on the public keys of both sender and receiver. (note this is easier for implementers to get wrong than ECDH-ES but that is another debate:) Probably more than you wanted to know, but Nat started it:) John B. > On Jul 17, 2015, at 2:09 PM, Brian Campbell <bcampb...@pingidentity.com> > wrote: > > Though you want to be careful with that as the asymmetric algs in JWE don't > provide authentication of the sender. > > On Thu, Jul 16, 2015 at 11:26 PM, Nat Sakimura <n-sakim...@nri.co.jp > <mailto:n-sakim...@nri.co.jp>> wrote: > Hi Malla, <> > > > Just to add one more thing: > > If you just want to “sign” for the sake of integrity protection, you really > do not need to do it as all the algs in JWE are integrity protected. > > > > -- > > Nat Sakimura <n-sakim...@nri.co.jp <mailto:n-sakim...@nri.co.jp>> > > Nomura Research Institute, Ltd. > > > > PLEASE READ: > > The information contained in this e-mail is confidential and intended for the > named recipient(s) only. > > If you are not an intended recipient of this e-mail, you are hereby notified > that any review, dissemination, distribution or duplication of this message > is strictly prohibited. If you have received this message in error, please > notify the sender immediately and delete your copy from your system. > > > > From: OAuth [mailto:oauth-boun...@ietf.org <mailto:oauth-boun...@ietf.org>] > On Behalf Of John Bradley > Sent: Friday, July 17, 2015 7:45 AM > To: Malla Simhachalam <mallasimhacha...@gmail.com > <mailto:mallasimhacha...@gmail.com>> > Cc: oauth@ietf.org <mailto:oauth@ietf.org> > Subject: Re: [OAUTH-WG] Nesting Signatures and Encryption JWT Tokens > > > > https://tools.ietf.org/html/rfc7519#section-11.2 > <https://tools.ietf.org/html/rfc7519#section-11.2> > > > It is in the JWT spec. You can do it both ways however you really need a > good reason not to sign then encrypt, and then after you have a good reason > you should still sign then encrypt because you probably have not considered > everything, > > > > There are probably some edge cases that are exceptions to the rule, but they > are rare. > > > > John B. > > > > > > On Jul 16, 2015, at 11:33 PM, Malla Simhachalam <mallasimhacha...@gmail.com > <mailto:mallasimhacha...@gmail.com>> wrote: > > > > Hi, > > I am looking at the spec > https://datatracker.ietf.org/doc/rfc7520/?include_text=1 > <https://datatracker.ietf.org/doc/rfc7520/?include_text=1> for combining JWS > and JWE use case, I could not find it obvious that a JSON document should be > signed first and then encrypt or other way around.Are there any > recommendations one over the other? > > Thanks for help. > > Malla > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org <mailto:OAuth@ietf.org> > https://www.ietf.org/mailman/listinfo/oauth > <https://www.ietf.org/mailman/listinfo/oauth> > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org <mailto:OAuth@ietf.org> > https://www.ietf.org/mailman/listinfo/oauth > <https://www.ietf.org/mailman/listinfo/oauth> > >
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
