I should also note that with symmetric keys, the alg option of A128KW with an enc of A128CBC+HS256 effectively gives you signing and encryption in a single JWE.
That doesn't solve the asymmetric signing case, but may work for some people . John B. On 2012-11-06, at 10:37 AM, John Bradley <[email protected]> wrote: > 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
