Re: [jose] encrypting AND signing a token

[John Bradley <[e-mail]>]

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 <[e-mail]> 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 <[e-mail]> 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" <[e-mail]> 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: [e-mail] [mailto:[e-mail]] On Behalf Of
>>>> Dick Hardt
>>>> Sent: Friday, November 02, 2012 12:30 PM
>>>> To: Mike Jones
>>>> Cc: [e-mail]
>>>> 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 <[e-mail]>
>>>> 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: [e-mail] [mailto:[e-mail]] On Behalf
>>>>> Of Dick Hardt
>>>>> Sent: Friday, November 02, 2012 8:22 AM
>>>>> To: [e-mail]
>>>>> 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
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/jose
>>>> 
>>>> _______________________________________________
>>>> jose mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/jose
>>> 
>> 
>> _______________________________________________
>> jose mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/jose
>