SAML performs this as separate operations. Now in some cases the assertion is signed then encrypted and then the message signed to deal with the AESCBC padding oracle attack.
There is non technical issue around the use of qualified signatures in cases where non repudiation is required. Signing a encrypted object has different connotations than signing a unencrypted one. I don't know what the status of a combined operation would be. It is probably not relevant to your use case. At IETF #83 I presented including ECDH-SS as an encryption option as it provides sender verification. I think that would answer your use case, depending on how you feel about EC. The work group rejected adding that algorithm at the time on the grounds that it is not used in places where it is supported. ECDH-ES is defined and is considered more secure than ECDH-SS mostly because it is harder to get wrong. I am not recommending revisiting the issue, but it would be a way to address the composite use case. Despite being a Canadian I am not shilling for certicom. Just saying. John B. On 2012-11-04, at 2:55 PM, Dick Hardt <[email protected]> wrote: > 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 _______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
