Re: [jose] encrypting AND signing a token

[Dick Hardt <[e-mail]>]

"we" can. John can't. :-)

-- Dick

On 2012-11-06, at 8:59 AM, John Bradley <[e-mail]> wrote:

> Probably not:)
>
> On 2012-11-06, at 11:10 AM, "Richard L. Barnes" <[e-mail]> wrote:
>
>> +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
>>
>