"nested JWTs" are only nominally defined in draft-ietf-oauth-json-web-token-05
(and the term is missing from the terminology section).
the JWT spec implies that "signing and then encrypting" and "encrypting and then
signing" are equivalent. however they aren't in various ways.
Axel already raised this point in..
Re: [jose] encrypting AND signing a token
https://www.ietf.org/mail-archive/web/jose/current/msg01269.html
..and cited this paper (worth citing again)..
Defective Sign & Encrypt in S/MIME, PKCS#7, MOSS, PEM, PGP, and XML
Don Davis
http://world.std.com/~dtd/sign_encrypt/sign_encrypt7.html
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.28.7379&rep=rep1&type=pdf
One has to carefully compose signing and encryption in order to avoid various
vulnerabilities detailed in the latter.
I agree with Axel that there should be one carefully designed way to craft a
signed and encrypted JW*.
Note that in the JSMS draft (draft-rescorla-jsms-00; an early input into what
became the JOSE WG), sign & encrypt composition is declared..
> 4.6. Composition
>
> This document does not specify a combination signed and encrypted
> mode. However, because the contents of a message can be arbitrary,
> and encryption and data origin authentication can be provided by
> recursively encapsulating multiple JSMS messages. In general,
> senders SHOULD sign the message and then encrypt the result (thus
> encrypting the signature). This prevents attacks in which the
> signature is stripped, leaving just an encrypted message, as well as
> providing privacy for the signer.
..tho that's a drafty draft and I didn't review carefully enough to determine
whether it addresses the need for sign and encrypt to cross-refer (see S4.3 in
the paper).
HTH,
=JeffH
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
