On 2010-07-15, at 5:29 PM, Dirk Balfanz wrote: > Hi Dick, > > you're right - after actually reading the paper :-), I agree that if you have > both sender and receiver in your payload, the order (of encrypting and > signing) doesn't seem to matter. > > I'm still hesitant, though, to optimize for the encryption use case now (even > though I do believe it will be important down the road). If I understand > correctly, then the envelope would remain unencrypted. What goes in there? > key_id? audience? issuer? timestamp? Do we know whether those things can > always remain unencrypted for the use cases we (vaguely) envision?
The envelope contains what is needed to do the crypto, regardless of it being signature verification or decryption. That would mean algorithm and key_id if used. Issuer would be needed if you need that to determine the key. Audience and issuer should also be in the payload per the paper. A library looking at the envelope would be able to decrypt the token and check the signature or just check the signature. The idea of the envelope is that the library only needs to look at the envelope to decide what to do. Message verification is something implementors get wrong all the time, so the easier we make it for libraries, the more likely there will be good libraries that people can use in different situations. > > Rather than guessing what would remain unencrypted, and what would be > encrypted (which I would have to decide today by specifying what goes into > the envelope and what doesn't), I think we should just spec out the > unencrypted version today, and spec out the encrypted version later when we > get to that bridge, taking care of the issues you brought up, like not > double-base64-encoding, etc. I don't think we need to guess now at all. We don't even have to figure out what needs to be in the envelope to do encryption. I am arguing for an architectural approach of an envelope and a payload rather than just a payload. (or in the case of digital signing, I am arguing for envelope, payload and signature rather than just signature and payload) This has several benefits: 1) the payload now can be encrypted independant of envelope (encryption inherently means there is a separate envelope -- only signing can take a shortcut and mix envelope data with payload since the payload is clear text) 2) we can use the same libraries in the future for all tokens 3) we have an extensibility model The benefits seem to outweigh the downside of having two JSON entities instead of just one. In many ways, this is similar to the header and body in HTTP requests. A separation of transport parameters from payload data has proven useful in many other architectures and protocols. -- Dick > > Dirk. > > On Fri, Jul 9, 2010 at 4:45 PM, Dick Hardt <dick.ha...@gmail.com> wrote: > Hi Dirk > > Responding to this now that you are back. > > From: > http://world.std.com/~dtd/sign_encrypt/sign_encrypt7.html > > (which is the whitepaper talking contrasting "encrypt-then-sign" and > "sign-then-encrypt") > > The simple solution seems to be to include both sender and recipient in the > plain text. > > At first glance your proposal of: > > encrypted_token = encryption(JSON_Token) || "." || envelope > envelope = base64(JSON(everything you need to know to decrypt)) > > This seems to work - I am unsure where the signature is. Ideally you encrypt > the binary of the signature rather than the base64url version. > > Ideally the JSON_Token would also have an envelope so that the same code > could look at the envelope to decide what to do with it regardless of if it > was encrypted or not. > > Perhaps the first string would always be an envelope that would contain > everything to either decrypt or verify the payload? > > -- Dick > > On 2010-06-22, at 10:57 PM, Dirk Balfanz wrote: > >> Hi Dick, >> >> interesting point about encrypted payloads. >> >> People more cryptographically-inclined than me might want to chime in, but I >> do seem to remember that there is a "correct" choice among the >> "encrypt-then-sign" and "sign-then-encrypt" alternatives. A quick search >> seems to suggest that the latter is what you want: >> https://www.pluralsight-training.net/community/blogs/craig/archive/2003/06/30/837.aspx. >> >> >> So I would suggest that encrypted payloads are implemented as an encryption >> of a JSON Token, as in: >> >> encrypted_token = encryption(JSON_Token) || "." || envelope >> envelope = base64(JSON(everything you need to know to decrypt)) >> >> What do you think? >> >> Dirk. >> >> >> On Mon, Jun 21, 2010 at 7:43 AM, Dick Hardt <dick.ha...@gmail.com> wrote: >> Thanks for writing this up Dirk. >> >> I would suggest that the token be: >> >> payload "." envelope "." signature >> >> This enables the payload to be encrypted and independent from the envelope. >> >> Token signing, verification, encryption and decryption code can then be >> generic and not understand the payload of the token. >> >> I would only include issuer, key_id and alg in the envelope. >> >> Audience, scope, nonce, and validation time information etc. would be in the >> payload. >> >> -- Dick >> >> On 2010-06-21, at 12:04 AM, Dirk Balfanz wrote: >> >>> Hi guys, >>> >>> I think I owe the list a proposal for signatures. >>> >>> I wrote something down that liberally borrows ideas from Magic Signatures, >>> SWT, and (even the name from) JSON Web Tokens. >>> >>> Here is a short document (called "JSON Tokens") that just explains how to >>> sign something and verify the signature: >>> http://docs.google.com/document/pub?id=1kv6Oz_HRnWa0DaJx_SQ5Qlk_yqs_7zNAm75-FmKwNo4 >>> >>> Here is an extension of JSON Tokens that can be used for signed OAuth >>> tokens: >>> http://docs.google.com/document/pub?id=1JUn3Twd9nXwFDgi-fTKl-unDG_ndyowTZW8OWX9HOUU >>> >>> Here is a different extension of JSON Tokens that can be used for 2-legged >>> flows. The idea is that this could be used as a drop-in replacement for >>> SAML assertions in the OAuth2 assertion flow: >>> http://docs.google.com/document/pub?id=1s4kjRS9P0frG0ulhgP3He01ONlxeTwkFQV_pCoOowzc >>> >>> I also have started to write some code to implement this as a >>> proof-of-concept. >>> >>> Thoughts? Comments? >>> >>> Dirk. >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >> >> > >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
