Re: [jose] encrypting AND signing a token

["Richard L. Barnes" <[e-mail]>]

+1

Can we please stop confusing signing and MAC?



On Nov 6, 2012, at 10:54 AM, Jim Schaad <[e-mail]> 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:[e-mail]]
>> Sent: Tuesday, November 06, 2012 10:50 AM
>> To: Dick Hardt
>> Cc: Jim Schaad; 'Mike Jones'; [e-mail]
>> 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 <[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
>>> 
> 
> _______________________________________________
> jose mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/jose