Thanks Jim. An interesting historical reference. In my use case, who signed or who the token is for is not a secret. The payload needs to be kept a secret.
Does no one sign and encrypt SAML tokens? Is this not a common use case? If it does need to be solved, it would seem to me that a standards body would be the place to have lots of eyes look at how to sign and encrypt a token so that people do not do naive sign and encrypt. Q: does anyone else need to sign and encrypt? -- Dick On Nov 4, 2012, at 10:24 AM, "Jim Schaad" <[email protected]> wrote: > <personal> > > I would note that the original PKCS#7 specifications had a mode that > provided a similar sign and encrypt as a single operation mode. When the > PKCS#7 specifications where adopted by the IETF as part of the CMS work, > this mode was discussed and very deliberately dropped because of numerous > security problems that had been found. These included (but are not limited > to) the fact that it was signed or who signed it was sometimes a security > leak. Also there were attacks where the signed and encrypted mode could be > converted to just an encrypted mode. > > I would think that there would be a need for a very detailed security > analysis that we are not prepared to do in order to support a signed and > encrypted mode. > > Jim > > >> -----Original Message----- >> From: [email protected] [mailto:[email protected]] On Behalf Of >> Dick Hardt >> Sent: Friday, November 02, 2012 12:30 PM >> To: Mike Jones >> Cc: [email protected] >> Subject: Re: [jose] encrypting AND signing a token >> >> Not only is my original token increasing in size by 4/3, I am also adding >> another header, payload and signature. >> >> One of the objectives of JWT was to enabled compact tokens. It would seem >> that we should be able to support both signing and encryption of the same >> token. >> >> All the encryption use cases I can think of involving asymmetric keys > would >> also require signing with the senders private key. >> >> My suggestion is to be explicit in what the algorithm etc. is used for: >> >> Rather than "alg" and "enc", we have: >> >> "algs" - algorithm for token signing >> "algk" - algorithm for content management key encryption "alge" - > algorithm >> for payload encryption >> >> Similiarly, >> >> "kids" - key id for signing >> "kidk" - key id for content managment key encryption >> >> We could probably make these three or even two letter codes if you want to >> save a couple bytes. >> >> -- Dick >> >> On Nov 2, 2012, at 8:46 AM, Mike Jones <[email protected]> >> wrote: >> >>> The way you put it brings one straightforward solution to mind. Solve > 1-3 >> with a JWE. Solve 4-5 by signing the JWE as a JWS payload. Done. >>> >>> I do understand that the 4/3 space blowup-of double base64url encoding >> the JWE motivates your earlier proposal about nested signing. (See Dick's >> 10/29/12 message "[jose] signing an existing JWT".) I also understand > that if >> you could do integrity with the asymmetric signature then the integrity >> provided by the JWE itself may be redundant. I don't have a specific > proposal >> on how to do that. >>> >>> -- Mike >>> >>> -----Original Message----- >>> From: [email protected] [mailto:[email protected]] On Behalf >>> Of Dick Hardt >>> Sent: Friday, November 02, 2012 8:22 AM >>> To: [email protected] >>> Subject: [jose] encrypting AND signing a token >>> >>> I am trying to figure out how to implement JWT/JWS/JWE to solve a real >> world problem. >>> >>> 1) Bob sends a token to Charlie via Alice. (Alice gets token from Bob >>> and then Alice gives token to Charlie) >>> 2) Alice must be prevented from reading the token. (token needs to be >>> encrypted) >>> 3) Bob and Charlie can share a symmetric key. >>> >>> I can solve this with JWE. >>> >>> Now let's add another condition. >>> >>> 4) Charlie wants non-repuditation that Bob created the token. >>> 5) Bob has a private key and a public key >>> >>> I don't see how to do this using JWE. It seems I have to sign the same > token >> I had previously with JWS. This seems inefficient since I should be able > to >> replace the JWE integrity computation done with the symmetric key with the >> private key -- but the "alg" parameter is the same in both encrypting and >> signing. >>> >>> Now let's expand this to replacing the symmetric key with a > public/private >> key pair for encryption. Bob encrypts with Charlies public key and signs > with >> Bob's private key (we also need to make sure we are not doing naive >> encryption and signing here, would be a really useful to specify what > needs >> to be done there). Now we need to have parameters for both public/private >> key pairs in the header. >>> >>> Am I missing something here? >>> >>> Seems like we can do this if we change the header parameters to specify > if >> they ("alg", "kid", et.c) are for token signing, payload encryption or > content >> key encryption. >>> >>> -- Dick >>> >>> >>> _______________________________________________ >>> jose mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/jose >> >> _______________________________________________ >> jose mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/jose > _______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
