"we" can. John can't. :-) -- Dick
On 2012-11-06, at 8:59 AM, John Bradley <[email protected]> wrote: > Probably not:) > > On 2012-11-06, at 11:10 AM, "Richard L. Barnes" <[email protected]> wrote: > >> +1 >> >> Can we please stop confusing signing and MAC? >> >> >> >> On Nov 6, 2012, at 10:54 AM, Jim Schaad <[email protected]> wrote: >> >>> <personal> >>> >>> Only if you have a really loose definition of signing - it gives you an >>> integrity check but not origination which is usually implied by the term >>> signing >>> >>> Jim >>> >>> >>>> -----Original Message----- >>>> From: John Bradley [mailto:[email protected]] >>>> Sent: Tuesday, November 06, 2012 10:50 AM >>>> To: Dick Hardt >>>> Cc: Jim Schaad; 'Mike Jones'; [email protected] >>>> Subject: Re: [jose] encrypting AND signing a token >>>> >>>> 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 >> > _______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
