Re: [jose] encrypting AND signing a token

[<[e-mail]>]

I think that it is NOT necessary to have ONE crypto op for signing and simultaneous encryption. 
I think we should define ONE signed and encrypted JWT.
As was stated in previous emails: This is a very common use case.

If this paper is true http://world.std.com/~dtd/sign_encrypt/sign_encrypt7.html then we have these options:
1) naming repair
2) sign/encrypt/sign
3) encrypt/sign/encrypt

The naming repair is difficult with JWT because we don't handle sender and recipient names. The other two seem to cost a lot.

I guess that in Dick's use case the naming repair will work and I think we should add senderID and recipientID to JWT and make it then mandatory for sign&encrypt.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of Mike Scott
Sent: Sunday, November 04, 2012 10:27 PM
To: [e-mail]
Subject: Re: [jose] encrypting AND signing a token

Signcryption?

http://www.signcryption.org/standards/

Mike Scott
________________________________________
From: [e-mail] [[e-mail]] on behalf of Jim Schaad [[e-mail]]
Sent: 04 November 2012 20:51
To: 'Dick Hardt'
Cc: 'Mike Jones'; [e-mail]
Subject: Re: [jose] encrypting AND signing a token

> -----Original Message-----
> From: Dick Hardt [mailto:[e-mail]]
> Sent: Sunday, November 04, 2012 2:56 PM
> To: Jim Schaad
> Cc: 'Dick Hardt'; 'Mike Jones'; [e-mail]
> Subject: Re: [jose] encrypting AND signing a token
>
> 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?

Everything I have seen does this as independent operations.

Jim

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