Re: [jose] encrypting AND signing a token

["Jim Schaad" <[e-mail]>]

<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
> >