[OAUTH-WG] regarding nested JWTs and security

[=JeffH <[e-mail]>]

"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