Re: [OAUTH-WG] proposal for signatures
If we were using PKCS#7 for certs, then why not PKCS#7 the payload as well? (No - I am not proposing to do it. Doing so with AES-128,192,256 is prohibitive in some language such as PHP, but just as a point of discussion to close this.) On Tue, Jun 22, 2010 at 6:33 PM, Ben Laurie b...@google.com wrote: On 22 June 2010 02:40, Manger, James H james.h.man...@team.telstra.com wrote: Nat and Ben, In addition to Ben's questions, I have another. For X.509, you seem to be using DER. How do you express the entire certificate chain using DER? (With PEM, you can just concatenate ... ) With DER you can concatenate, too, of course. There's also PKCS#n (for some value of n which I forget ... 12?) which allows bundling of cert chains. That's PKCS#12, I suppose. I had under an impression that PKCS#12 includes the private key, though. A *.p7c file can be used to hold any number of certificates. It is a BER-encoded PKCS#7 value, now known as Cryptographic Message Syntax (CMS) standard [RFC 5652]. It is the ASN.1 syntax used for S/MIME signed email. If you only want to send certificates, just leaving out the content-to-be-signed, and the signatures. Ah, thanks, I thought there was something less kludgey than PKCS#12. Such a file can hold any number of certificates, including public-key certificates, attribute certificates, or other certificate formats. It can also hold CRLs and other revocation information (including OCSP responses as per draft-turner-additional-cms-ri-choices). CMS/PKCS#7 is better for this purpose than PKCS#12. -- James Manger ___ 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 -- Nat Sakimura (=nat) http://www.sakimura.org/en/ http://twitter.com/_nat_en ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] proposal for signatures
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? 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. 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 Signatureshttp://salmon-protocol.googlecode.com/svn/trunk/draft-panzer-magicsig-00.html, SWT http://groups.google.com/group/WRAP-WG/files, and (even the name from) JSON Web Tokenshttps://groups.google.com/group/WRAP-WG/browse_thread/thread/a99369c4b74d4cd0# . 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 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 codehttp://code.google.com/p/jsontoken/source/browse/#svn/trunk/src/main/java/net/oauth/signaturesto 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
Re: [OAUTH-WG] proposal for signatures
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.
Re: [OAUTH-WG] proposal for signatures
Hi OAuthers, First of all, I think I should introduce myself. I work at Facebook on the Platform team (anything not facebook.comhttp://facebook.com). Before this I was at Yahoo! doing SearchMonkey (semantic web stuff). I've written a few OAuth applications and libraries, both at Yahoo and in my spare time. For Facebook apps we're going to use your signature scheme with the following changes: * the signature comes before the payload * we used the key 'algorithm' instead of 'alg' and 'expires' instead of 'not_before' * we aren't sending any keys except algorithm, expires, and oauth_token (since we're a special use case) * we named the parameter signed_request because it is the signed part of a request We would love if you could adopt those changes. Then you'd have a real world implementation out the door already :) We plan on launching July 20. Paul Sent from my iPhone On Jul 9, 2010, at 1:39 PM, Dirk Balfanz balf...@google.commailto:balf...@google.com wrote: On Wed, Jul 7, 2010 at 7:49 PM, Eran Hammer-Lahav mailto:e...@hueniverse.come...@hueniverse.commailto:e...@hueniverse.com wrote: Can we get an updated document based on the feedback received? Sure - I just got back from my vacation. I'll read through the thread and update the docs. Cheers, Dirk. EHL On 6/21/10 12:04 AM, Dirk Balfanz http://balf...@google.combalf...@google.commailto:balf...@google.com wrote: / / Hi guys, I think I owe the list a proposal for signatures. I wrote something down that liberally borrows ideas from Magic Signatures http://salmon-protocol.googlecode.com/svn/trunk/draft-panzer-magicsig-00.htmlhttp://salmon-protocol.googlecode.com/svn/trunk/draft-panzer-magicsig-00.html , SWT http://groups.google.com/group/WRAP-WG/fileshttp://groups.google.com/group/WRAP-WG/files , and (even the name from) JSON Web Tokens https://groups.google.com/group/WRAP-WG/browse_thread/thread/a99369c4b74d4cd0#https://groups.google.com/group/WRAP-WG/browse_thread/thread/a99369c4b74d4cd0# . 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-FmKwNo4http://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_ndyowTZW8OWX9HOUUhttp://docs.google.com/document/pub?id=1JUn3Twd9nXwFDgi-fTKl-unDG_ndyowTZW8OWX9HOUU http://docs.google.com/document/pub?id=1JUn3Twd9nXwFDgi-fTKl-unDG_ndyowTZW8OWX9HOUUhttp://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_pCoOowzchttp://docs.google.com/document/pub?id=1s4kjRS9P0frG0ulhgP3He01ONlxeTwkFQV_pCoOowzc I also have started to write some code http://code.google.com/p/jsontoken/source/browse/#svn/trunk/src/main/java/net/oauth/signatureshttp://code.google.com/p/jsontoken/source/browse/#svn/trunk/src/main/java/net/oauth/signatures to implement this as a proof-of-concept. Thoughts? Comments? Dirk. ___ OAuth mailing list OAuth@ietf.orgmailto:OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] proposal for signatures
I agree we don't want to end up like other protocols that were too generic. :) The use case I am arguing for is sending encrypted tokens. Higher levels of assurance require this and various people brought this up as a requirement when WRAP was presented at IIW 09B. -- Dick On 2010-07-10, at 11:06 AM, Eran Hammer-Lahav wrote: We need to get this into a proper draft (which I understand is on Dirk's list) and do a round of feedback before we promote this to a WG draft. I'm happy to help with editorial work if needed. Given the wide range of use cases, I think we need to keep this work focused on the use cases driving it, and not try to make it too generic. ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] proposal for signatures
On 2010-07-10, at 1:42 PM, David Recordon wrote: On Sat, Jul 10, 2010 at 1:29 PM, Dick Hardt dick.ha...@gmail.com wrote: On 2010-07-10, at 1:21 PM, David Recordon wrote: On Sat, Jul 10, 2010 at 11:00 AM, Dick Hardt dick.ha...@gmail.com wrote: * the signature comes before the payload * we used the key 'algorithm' instead of 'alg' and 'expires' instead of 'not_before' Good points to add to the discussion. Perhaps you would articulate why you made those choices? I think Naitik talked about the signature coming before the payload in this thread. Through implementations we've found that lsplit is easier in some languages. I think having an envelope as the first blob enables a parser to know what to do with the rest of the blobs, and that this trumps the mionor lsplit argument. And we think that adding an envelope creates unnecessary complexity for both server and client developers for the signature use cases. Obviously anything besides what you need for your use case adds complexity. The question is: are you willing to accept some complexity so that it works for use cases than yours? If not, then perhaps you should just define your own signature mechanism. I don't see parsing two base64url encoded JSON strings as being that much more complex than parsing one. Repeating one step that then enables extensibility for the future as to how to parse the rest of the token, and enables the same code to look at encrypted tokens in addition to tokens that have only been signed. The alternative is the client and server have to know ahead of time what is being sent and can't mix them -- that adds complexity later on. -- Dick ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] proposal for signatures
On Sat, Jul 10, 2010 at 2:22 PM, Dick Hardt dick.ha...@gmail.com wrote: Obviously anything besides what you need for your use case adds complexity. The question is: are you willing to accept some complexity so that it works for use cases than yours? If not, then perhaps you should just define your own signature mechanism. I think that you misunderstood what I was saying. The use case that Paul described is more limited than the signature use cases for OAuth 2.0. An envelope is not required for the signature use cases for OAuth 2.0. As you pointed out later, it could be required for different use cases of encrypting and signing requests. --David ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] proposal for signatures
On Wed, Jul 7, 2010 at 7:49 PM, Eran Hammer-Lahav e...@hueniverse.comwrote: Can we get an updated document based on the feedback received? Sure - I just got back from my vacation. I'll read through the thread and update the docs. Cheers, Dirk. EHL On 6/21/10 12:04 AM, Dirk Balfanz balf...@google.com wrote: / / Hi guys, I think I owe the list a proposal for signatures. I wrote something down that liberally borrows ideas from Magic Signatures http://salmon-protocol.googlecode.com/svn/trunk/draft-panzer-magicsig-00.html , SWT http://groups.google.com/group/WRAP-WG/files , and (even the name from) JSON Web Tokens https://groups.google.com/group/WRAP-WG/browse_thread/thread/a99369c4b74d4cd0# . 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 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 http://code.google.com/p/jsontoken/source/browse/#svn/trunk/src/main/java/net/oauth/signatures to implement this as a proof-of-concept. Thoughts? Comments? Dirk. ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] proposal for signatures
would your proposal allow to issue and use HMAC Verification Keys in the same way as the old token secrets, i.e. an AS would issue such keys along with tokens to the OAuth client? A special key id could be used to indicate this scenario. regards, Torsten. Am 21.06.2010 09:04, schrieb Dirk Balfanz: Hi guys, I think I owe the list a proposal for signatures. I wrote something down that liberally borrows ideas from Magic Signatures http://salmon-protocol.googlecode.com/svn/trunk/draft-panzer-magicsig-00.html, SWT http://groups.google.com/group/WRAP-WG/files, and (even the name from) JSON Web Tokens https://groups.google.com/group/WRAP-WG/browse_thread/thread/a99369c4b74d4cd0#. 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 http://code.google.com/p/jsontoken/source/browse/#svn/trunk/src/main/java/net/oauth/signatures 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
Re: [OAUTH-WG] proposal for signatures
What's the purpose of leaving out the key ID? It's one more field that developers have to learn and configure and type in. We should keep the simple case simple, while allowing for more complex cases. I think the fact that many providers now offer only a single, shared secret is an indication that the key ID is not required. On Jun 25, 2010, at 7:40 AM, Breno wrote: Key ids are an optimization in the case of rotating public keys, but pretty much an operational requirement if you wish to support automatic rotation of shared keys. On Jun 23, 2010 2:56 AM, Ben Laurie b...@google.commailto:b...@google.com wrote: On 22 June 2010 21:45, David Recordon record...@gmail.commailto:record...@gmail.com wrote: Hey Dick, in answering my quest... I don't understand why they are unnecessary no matter how keys are managed: if there's ever a possibility that you might have more than one key for someone, then key IDs are a useful optimisation. Put it another way: what's the purpose of leaving out the key ID? And yes, Applied Cryptography is worth reading. :) --David On Tue, Jun 22, 2010 at 12:5... ATT1..txt ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] proposal for signatures
On Fri, Jun 25, 2010 at 10:51 AM, Luke Shepard lshep...@facebook.com wrote: What's the purpose of leaving out the key ID? It's one more field that developers have to learn and configure and type in. We should keep the simple case simple, while allowing for more complex cases. I think the fact that many providers now offer only a single, shared secret is an indication that the key ID is not required. Are you arguing here that the key_id should be an optional field, or that it should not be part of the specification at all? On Jun 25, 2010, at 7:40 AM, Breno wrote: Key ids are an optimization in the case of rotating public keys, but pretty much an operational requirement if you wish to support automatic rotation of shared keys. On Jun 23, 2010 2:56 AM, Ben Laurie b...@google.com wrote: On 22 June 2010 21:45, David Recordon record...@gmail.com wrote: Hey Dick, in answering my quest... I don't understand why they are unnecessary no matter how keys are managed: if there's ever a possibility that you might have more than one key for someone, then key IDs are a useful optimisation. Put it another way: what's the purpose of leaving out the key ID? And yes, Applied Cryptography is worth reading. :) --David On Tue, Jun 22, 2010 at 12:5... ATT1..txt -- Breno de Medeiros ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] proposal for signatures
+1 for optional -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Breno Sent: Friday, June 25, 2010 11:02 AM To: Luke Shepard Cc: hannes.tschofe...@gmx.net; OAuth WG Subject: Re: [OAUTH-WG] proposal for signatures On Fri, Jun 25, 2010 at 10:51 AM, Luke Shepard lshep...@facebook.com wrote: What's the purpose of leaving out the key ID? It's one more field that developers have to learn and configure and type in. We should keep the simple case simple, while allowing for more complex cases. I think the fact that many providers now offer only a single, shared secret is an indication that the key ID is not required. Are you arguing here that the key_id should be an optional field, or that it should not be part of the specification at all? On Jun 25, 2010, at 7:40 AM, Breno wrote: Key ids are an optimization in the case of rotating public keys, but pretty much an operational requirement if you wish to support automatic rotation of shared keys. On Jun 23, 2010 2:56 AM, Ben Laurie b...@google.com wrote: On 22 June 2010 21:45, David Recordon record...@gmail.com wrote: Hey Dick, in answering my quest... I don't understand why they are unnecessary no matter how keys are managed: if there's ever a possibility that you might have more than one key for someone, then key IDs are a useful optimisation. Put it another way: what's the purpose of leaving out the key ID? And yes, Applied Cryptography is worth reading. :) --David On Tue, Jun 22, 2010 at 12:5... ATT1..txt -- Breno de Medeiros ___ 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
Re: [OAUTH-WG] proposal for signatures
Thanks for writing this. A few questions... Do we need both `issuer` and `key_id`? Shouldn't we use `client_id` instead at least for OAuth? Can we write out algorithm instead of `alg`? How do you generate the body hash? Does websafe-base64-encoded mean that I can't just blindly use my languages built in base64 encode function? Don't we still have the more fundamental question to answer about decoupling what's being signed from the underlying HTTP request? --David On Mon, Jun 21, 2010 at 12:04 AM, Dirk Balfanz balf...@google.com 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
Re: [OAUTH-WG] proposal for signatures
btw, I wrote a very naive PHP sample. http://gist.github.com/448164 On Mon, Jun 21, 2010 at 11:03 PM, David Recordon record...@gmail.com wrote: Thanks for writing this. A few questions... Do we need both `issuer` and `key_id`? Shouldn't we use `client_id` instead at least for OAuth? Can we write out algorithm instead of `alg`? How do you generate the body hash? Does websafe-base64-encoded mean that I can't just blindly use my languages built in base64 encode function? Don't we still have the more fundamental question to answer about decoupling what's being signed from the underlying HTTP request? --David On Mon, Jun 21, 2010 at 12:04 AM, Dirk Balfanz balf...@google.com 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
Re: [OAUTH-WG] proposal for signatures
On 22 June 2010 02:40, Manger, James H james.h.man...@team.telstra.com wrote: Nat and Ben, In addition to Ben's questions, I have another. For X.509, you seem to be using DER. How do you express the entire certificate chain using DER? (With PEM, you can just concatenate ... ) With DER you can concatenate, too, of course. There's also PKCS#n (for some value of n which I forget ... 12?) which allows bundling of cert chains. That's PKCS#12, I suppose. I had under an impression that PKCS#12 includes the private key, though. A *.p7c file can be used to hold any number of certificates. It is a BER-encoded PKCS#7 value, now known as Cryptographic Message Syntax (CMS) standard [RFC 5652]. It is the ASN.1 syntax used for S/MIME signed email. If you only want to send certificates, just leaving out the content-to-be-signed, and the signatures. Ah, thanks, I thought there was something less kludgey than PKCS#12. Such a file can hold any number of certificates, including public-key certificates, attribute certificates, or other certificate formats. It can also hold CRLs and other revocation information (including OCSP responses as per draft-turner-additional-cms-ri-choices). CMS/PKCS#7 is better for this purpose than PKCS#12. -- James Manger ___ 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
Re: [OAUTH-WG] proposal for signatures
On 22 June 2010 07:03, David Recordon record...@gmail.com wrote: Thanks for writing this. A few questions... Do we need both `issuer` and `key_id`? Shouldn't we use `client_id` instead at least for OAuth? Can we write out algorithm instead of `alg`? How do you generate the body hash? Does websafe-base64-encoded mean that I can't just blindly use my languages built in base64 encode function? No, you need the websafe alphabet, which substitutes '-' and '_' for '+' and '/' in the standard alphabet. Which reminds me, Dirk needs to specify whether padding is used. Don't we still have the more fundamental question to answer about decoupling what's being signed from the underlying HTTP request? --David On Mon, Jun 21, 2010 at 12:04 AM, Dirk Balfanz balf...@google.com 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 ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] proposal for signatures
On 2010-06-21, at 11:03 PM, David Recordon wrote: Thanks for writing this. A few questions... Do we need both `issuer` and `key_id`? Shouldn't we use `client_id` instead at least for OAuth? it is the ID of the key, not the client -- used to rollover keys Does websafe-base64-encoded mean that I can't just blindly use my languages built in base64 encode function? correct -- but a growing number of languages are supporting websafe Don't we still have the more fundamental question to answer about decoupling what's being signed from the underlying HTTP request? I have no idea what you mean by this question -- Dick ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] proposal for signatures
On Tue, Jun 22, 2010 at 7:17 AM, Dick Hardt dick.ha...@gmail.com wrote: Thanks for writing this. A few questions... Do we need both `issuer` and `key_id`? Shouldn't we use `client_id` instead at least for OAuth? it is the ID of the key, not the client -- used to rollover keys I don't think key id is necessary, but adding Hannes since he called me crazy for saying that at IIW. =) The average client is going to have very few keys. Probably just 1. 3 at the outside. If a server needs to verify, it can literally iterate over all of the keys associated with the client until it finds the right one. There is some precedent for this approach: http://support.microsoft.com/kb/906305/en-us. Cheers, Brian ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] proposal for signatures
Having a key ID is an optimization. If you're using public key signatures is having to do potentially 3x the signatures going to be a problem? -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Brian Eaton Sent: Tuesday, June 22, 2010 9:43 AM To: Dick Hardt; hannes.tschofe...@gmx.net Cc: OAuth WG Subject: Re: [OAUTH-WG] proposal for signatures On Tue, Jun 22, 2010 at 7:17 AM, Dick Hardt dick.ha...@gmail.com wrote: Thanks for writing this. A few questions... Do we need both `issuer` and `key_id`? Shouldn't we use `client_id` instead at least for OAuth? it is the ID of the key, not the client -- used to rollover keys I don't think key id is necessary, but adding Hannes since he called me crazy for saying that at IIW. =) The average client is going to have very few keys. Probably just 1. 3 at the outside. If a server needs to verify, it can literally iterate over all of the keys associated with the client until it finds the right one. There is some precedent for this approach: http://support.microsoft.com/kb/906305/en-us. Cheers, Brian ___ 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
Re: [OAUTH-WG] proposal for signatures
On Tue, Jun 22, 2010 at 2:36 AM, Ben Laurie b...@google.com wrote: On 22 June 2010 07:03, David Recordon record...@gmail.com wrote: Thanks for writing this. A few questions... Do we need both `issuer` and `key_id`? Shouldn't we use `client_id` instead at least for OAuth? Can we write out algorithm instead of `alg`? How do you generate the body hash? Does websafe-base64-encoded mean that I can't just blindly use my languages built in base64 encode function? No, you need the websafe alphabet, which substitutes '-' and '_' for '+' and '/' in the standard alphabet. Which reminds me, Dirk needs to specify whether padding is used. (Padding _is_ part of the base64 specification IIRC; I think it'd be sufficient to artfully include it in the primary example -- and have a second example crafted so that there happens to be zero padding :) ). You can construct base64url() from base64() plus a substitution pass for -+ and _/ so it doesn't seem too onerous. (Make sure to include one of these characters in the examples too.) Don't we still have the more fundamental question to answer about decoupling what's being signed from the underlying HTTP request? Aside/my $.02: This is a key issue which Salmon+Magic Signatures evades by essentially treating the HTTP request (the method, URL, headers, etc.) as advisory/transport hints, to be ignored when reading the data, and making sure the protocol works even if the data is sent via carrier pigeon; all important information must be contained in the signed, structured body. This is much much harder if you have to deal with totally arbitrary kinds of requests with arbitrary semantics. This also means that you're effectively using HTTP as a simple transport to move envelopes around, in much the same way you can use the ocean to transport messages in bottles around, but a bit more efficiently. I've banged my head against this a bit and have not come up with a better solution but if there is one I'd love to hear it. --David On Mon, Jun 21, 2010 at 12:04 AM, Dirk Balfanz balf...@google.com 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 ___ 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
Re: [OAUTH-WG] proposal for signatures
Aside/my $.02: This is a key issue which Salmon+Magic Signatures evades by essentially treating the HTTP request (the method, URL, headers, etc.) as advisory/transport hints, to be ignored when reading the data, and making sure the protocol works even if the data is sent via carrier pigeon; all important information must be contained in the signed, structured body. This is much much harder if you have to deal with totally arbitrary kinds of requests with arbitrary semantics. This also means that you're effectively using HTTP as a simple transport to move envelopes around, in much the same way you can use the ocean to transport messages in bottles around, but a bit more efficiently. I've banged my head against this a bit and have not come up with a better solution but if there is one I'd love to hear it. +1 ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] proposal for signatures
All of the OAuth 1.0 implementations which I'm aware of either have the server provide a shared secret to the client or the client upload their public key to the server. In the case of the server providing a shared secret to the client, what would the value of key_id be? In the case of a client uploading their public key to the server, what would the value of key_id be? Thanks, --David On Tue, Jun 22, 2010 at 12:14 PM, Dick Hardt dick.ha...@gmail.com wrote: I could imagine an architecture striving to be efficient, scalable, distributed and secure where there are hundreds of servers each with a unique private key baked into each server. All the public keys would be in one file. Having a key id would help debugging as well as the signer is clearly indicating which key should be used. If the signing fails, it could be the key, could be signature calculation, could be ... The downside of having a key_id seems heavily outweighed by the advantages to me. On Tue, Jun 22, 2010 at 10:30 AM, Anthony Nadalin tony...@microsoft.com wrote: If a server needs to verify, it can literally iterate over all of the keys associated with the client until it finds the right one. Depends on how the server stored the keys, this can be a very expensive operation w/o a key_id to match/index on -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Brian Eaton Sent: Tuesday, June 22, 2010 9:43 AM To: Dick Hardt; hannes.tschofe...@gmx.net Cc: OAuth WG Subject: Re: [OAUTH-WG] proposal for signatures On Tue, Jun 22, 2010 at 7:17 AM, Dick Hardt dick.ha...@gmail.com wrote: Thanks for writing this. A few questions... Do we need both `issuer` and `key_id`? Shouldn't we use `client_id` instead at least for OAuth? it is the ID of the key, not the client -- used to rollover keys I don't think key id is necessary, but adding Hannes since he called me crazy for saying that at IIW. =) The average client is going to have very few keys. Probably just 1. 3 at the outside. If a server needs to verify, it can literally iterate over all of the keys associated with the client until it finds the right one. There is some precedent for this approach: http://support.microsoft.com/kb/906305/en-us. Cheers, Brian ___ 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 ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] proposal for signatures
Hey Dick, in answering my questions you made my point. If keys are managed out of band – as is done in OAuth 1.0 and what was done in the OAuth 2.0 Core spec until signatures were extracted – then having a key id is not needed. I certainly understand what they're used for, but don't find them relevant as part of the OAuth conversation today. And yes, Applied Cryptography is worth reading. :) --David On Tue, Jun 22, 2010 at 12:59 PM, Dick Hardt dick.ha...@gmail.com wrote: David key_ids are used when you need to identify which key to use of all the keys you might have. If you are doing discovery of document that is bound to the identifier of the signer, this is useful. Since OAuth 1.0 did not have discovery and required an out of band key management process, key_ids have little value. To answer your question, key_ids dont' make sense if the keys are being managed how you describe them. I would suggest that key_ids are not included if public keys are managed independent from how Dirk had described them be discovered. I don't think key_ids make sense for shared secrets as they inherently have an out of band process for sharing them. If you would like to learn more about cryptography, I have found Bruce Schneier's book Applied Cryptography to be pretty educational. Here is a link to the Kindle version: http://www.amazon.com/Applied-Cryptography-Protocols-Algorithms-ebook/dp/B000SEHPK6/ref=kinw_dp_ke?ie=UTF8m=AG56TWVU5XWC2qid=1277236054sr=8-1 -- Dick On Tue, Jun 22, 2010 at 12:20 PM, David Recordon record...@gmail.com wrote: All of the OAuth 1.0 implementations which I'm aware of either have the server provide a shared secret to the client or the client upload their public key to the server. In the case of the server providing a shared secret to the client, what would the value of key_id be? In the case of a client uploading their public key to the server, what would the value of key_id be? Thanks, --David On Tue, Jun 22, 2010 at 12:14 PM, Dick Hardt dick.ha...@gmail.com wrote: I could imagine an architecture striving to be efficient, scalable, distributed and secure where there are hundreds of servers each with a unique private key baked into each server. All the public keys would be in one file. Having a key id would help debugging as well as the signer is clearly indicating which key should be used. If the signing fails, it could be the key, could be signature calculation, could be ... The downside of having a key_id seems heavily outweighed by the advantages to me. On Tue, Jun 22, 2010 at 10:30 AM, Anthony Nadalin tony...@microsoft.com wrote: If a server needs to verify, it can literally iterate over all of the keys associated with the client until it finds the right one. Depends on how the server stored the keys, this can be a very expensive operation w/o a key_id to match/index on -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Brian Eaton Sent: Tuesday, June 22, 2010 9:43 AM To: Dick Hardt; hannes.tschofe...@gmx.net Cc: OAuth WG Subject: Re: [OAUTH-WG] proposal for signatures On Tue, Jun 22, 2010 at 7:17 AM, Dick Hardt dick.ha...@gmail.com wrote: Thanks for writing this. A few questions... Do we need both `issuer` and `key_id`? Shouldn't we use `client_id` instead at least for OAuth? it is the ID of the key, not the client -- used to rollover keys I don't think key id is necessary, but adding Hannes since he called me crazy for saying that at IIW. =) The average client is going to have very few keys. Probably just 1. 3 at the outside. If a server needs to verify, it can literally iterate over all of the keys associated with the client until it finds the right one. There is some precedent for this approach: http://support.microsoft.com/kb/906305/en-us. Cheers, Brian ___ 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 ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] proposal for signatures
The only additional value might be during key rotation. If key_id is removed, then both (or n) have to be checked. Probably not a huge issue. Thanks, George On 6/22/10 4:45 PM, David Recordon wrote: Hey Dick, in answering my questions you made my point. If keys are managed out of band -- as is done in OAuth 1.0 and what was done in the OAuth 2.0 Core spec until signatures were extracted -- then having a key id is not needed. I certainly understand what they're used for, but don't find them relevant as part of the OAuth conversation today. And yes, Applied Cryptography is worth reading. :) --David On Tue, Jun 22, 2010 at 12:59 PM, Dick Hardtdick.ha...@gmail.com wrote: David key_ids are used when you need to identify which key to use of all the keys you might have. If you are doing discovery of document that is bound to the identifier of the signer, this is useful. Since OAuth 1.0 did not have discovery and required an out of band key management process, key_ids have little value. To answer your question, key_ids dont' make sense if the keys are being managed how you describe them. I would suggest that key_ids are not included if public keys are managed independent from how Dirk had described them be discovered. I don't think key_ids make sense for shared secrets as they inherently have an out of band process for sharing them. If you would like to learn more about cryptography, I have found Bruce Schneier's book Applied Cryptography to be pretty educational. Here is a link to the Kindle version: http://www.amazon.com/Applied-Cryptography-Protocols-Algorithms-ebook/dp/B000SEHPK6/ref=kinw_dp_ke?ie=UTF8m=AG56TWVU5XWC2qid=1277236054sr=8-1 -- Dick On Tue, Jun 22, 2010 at 12:20 PM, David Recordonrecord...@gmail.com wrote: All of the OAuth 1.0 implementations which I'm aware of either have the server provide a shared secret to the client or the client upload their public key to the server. In the case of the server providing a shared secret to the client, what would the value of key_id be? In the case of a client uploading their public key to the server, what would the value of key_id be? Thanks, --David On Tue, Jun 22, 2010 at 12:14 PM, Dick Hardtdick.ha...@gmail.com wrote: I could imagine an architecture striving to be efficient, scalable, distributed and secure where there are hundreds of servers each with a unique private key baked into each server. All the public keys would be in one file. Having a key id would help debugging as well as the signer is clearly indicating which key should be used. If the signing fails, it could be the key, could be signature calculation, could be ... The downside of having a key_id seems heavily outweighed by the advantages to me. On Tue, Jun 22, 2010 at 10:30 AM, Anthony Nadalin tony...@microsoft.com wrote: If a server needs to verify, it can literally iterate over all of the keys associated with the client until it finds the right one. Depends on how the server stored the keys, this can be a very expensive operation w/o a key_id to match/index on -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Brian Eaton Sent: Tuesday, June 22, 2010 9:43 AM To: Dick Hardt; hannes.tschofe...@gmx.net Cc: OAuth WG Subject: Re: [OAUTH-WG] proposal for signatures On Tue, Jun 22, 2010 at 7:17 AM, Dick Hardtdick.ha...@gmail.com wrote: Thanks for writing this. A few questions... Do we need both `issuer` and `key_id`? Shouldn't we use `client_id` instead at least for OAuth? it is the ID of the key, not the client -- used to rollover keys I don't think key id is necessary, but adding Hannes since he called me crazy for saying that at IIW. =) The average client is going to have very few keys. Probably just 1. 3 at the outside. If a server needs to verify, it can literally iterate over all of the keys associated with the client until it finds the right one. There is some precedent for this approach: http://support.microsoft.com/kb/906305/en-us. Cheers, Brian ___ 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 ___ 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
[OAUTH-WG] proposal for signatures
Hi guys, I think I owe the list a proposal for signatures. I wrote something down that liberally borrows ideas from Magic Signatureshttp://salmon-protocol.googlecode.com/svn/trunk/draft-panzer-magicsig-00.html, SWT http://groups.google.com/group/WRAP-WG/files, and (even the name from) JSON Web Tokenshttps://groups.google.com/group/WRAP-WG/browse_thread/thread/a99369c4b74d4cd0# . 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 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 codehttp://code.google.com/p/jsontoken/source/browse/#svn/trunk/src/main/java/net/oauth/signaturesto implement this as a proof-of-concept. Thoughts? Comments? Dirk. ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] proposal for signatures
On 21 June 2010 08:04, Dirk Balfanz balf...@google.com 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 signature is a base64-encoded string of the signature bits. should be websafe-base64? the current time is not after the expiration time of the token (defined as not_before + session_length) should be not_before + token_lifetime, right? But I'd prefer a not_after instead. What is a Service Descriptor? Is this something to do with webfinger, or something else? In the HMAC keys section you describe the keys as symmetric, which is strictly accurate, but more normally called shared keys for this use. Obviously you'll need to be a bit more specific about what you mean by RSA-SHA256. 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 As you know, I hate the term non-repudation. Can't you just call it signing? Protection against leaked authentication tokens: Protocols such as OAuth2 use bearer tokens, which may leak when used over non-SSL. Signing requests when using bearer tokens lets the recipient of such a request verify that the issuer of the request was a legitimate holder of the bearer token. - only true if you make the checking of the nonce a MUST instead of may. And even then, MitM wins, of course. Why is body_hash optional? 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 You use the abbreviation AS before the full name Authorization Server. I also have started to write some code to implement this as a proof-of-concept. Thoughts? Comments? Nice. 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
Re: [OAUTH-WG] proposal for signatures
Hi Dirk, In addition to Ben's questions, I have another. For X.509, you seem to be using DER. How do you express the entire certificate chain using DER? (With PEM, you can just concatenate ... ) And here is some comments: If body_hash is not used, it seems it is just doing the client authentication via asymmetric crypto. This is a valid use case, and actually is quite nice. I think this is the main use case. If we wanted to make sure that the request itself is not tampered, we need to sign the body. For this, I somehow feel that Magic Signatures is more interoperable since it actually sends the armored ASCII strings with it. =nat On Mon, Jun 21, 2010 at 8:18 PM, Ben Laurie b...@google.com wrote: On 21 June 2010 08:04, Dirk Balfanz balf...@google.com 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 signature is a base64-encoded string of the signature bits. should be websafe-base64? the current time is not after the expiration time of the token (defined as not_before + session_length) should be not_before + token_lifetime, right? But I'd prefer a not_after instead. What is a Service Descriptor? Is this something to do with webfinger, or something else? In the HMAC keys section you describe the keys as symmetric, which is strictly accurate, but more normally called shared keys for this use. Obviously you'll need to be a bit more specific about what you mean by RSA-SHA256. 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 As you know, I hate the term non-repudation. Can't you just call it signing? Protection against leaked authentication tokens: Protocols such as OAuth2 use bearer tokens, which may leak when used over non-SSL. Signing requests when using bearer tokens lets the recipient of such a request verify that the issuer of the request was a legitimate holder of the bearer token. - only true if you make the checking of the nonce a MUST instead of may. And even then, MitM wins, of course. Why is body_hash optional? 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 You use the abbreviation AS before the full name Authorization Server. I also have started to write some code to implement this as a proof-of-concept. Thoughts? Comments? Nice. 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 -- Nat Sakimura (=nat) http://www.sakimura.org/en/ http://twitter.com/_nat_en ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] proposal for signatures
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
Re: [OAUTH-WG] proposal for signatures
On Mon, Jun 21, 2010 at 10:26 PM, Ben Laurie b...@google.com wrote: On 21 June 2010 14:22, Nat Sakimura sakim...@gmail.com wrote: Hi Dirk, In addition to Ben's questions, I have another. For X.509, you seem to be using DER. How do you express the entire certificate chain using DER? (With PEM, you can just concatenate ... ) With DER you can concatenate, too, of course. There's also PKCS#n (for some value of n which I forget ... 12?) which allows bundling of cert chains. That's PKCS#12, I suppose. I had under an impression that PKCS#12 includes the private key, though. And here is some comments: If body_hash is not used, it seems it is just doing the client authentication via asymmetric crypto. This is a valid use case, and actually is quite nice. I think this is the main use case. If we wanted to make sure that the request itself is not tampered, we need to sign the body. For this, I somehow feel that Magic Signatures is more interoperable since it actually sends the armored ASCII strings with it. =nat On Mon, Jun 21, 2010 at 8:18 PM, Ben Laurie b...@google.com wrote: On 21 June 2010 08:04, Dirk Balfanz balf...@google.com 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 signature is a base64-encoded string of the signature bits. should be websafe-base64? the current time is not after the expiration time of the token (defined as not_before + session_length) should be not_before + token_lifetime, right? But I'd prefer a not_after instead. What is a Service Descriptor? Is this something to do with webfinger, or something else? In the HMAC keys section you describe the keys as symmetric, which is strictly accurate, but more normally called shared keys for this use. Obviously you'll need to be a bit more specific about what you mean by RSA-SHA256. 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 As you know, I hate the term non-repudation. Can't you just call it signing? Protection against leaked authentication tokens: Protocols such as OAuth2 use bearer tokens, which may leak when used over non-SSL. Signing requests when using bearer tokens lets the recipient of such a request verify that the issuer of the request was a legitimate holder of the bearer token. - only true if you make the checking of the nonce a MUST instead of may. And even then, MitM wins, of course. Why is body_hash optional? 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 You use the abbreviation AS before the full name Authorization Server. I also have started to write some code to implement this as a proof-of-concept. Thoughts? Comments? Nice. 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 -- Nat Sakimura (=nat) http://www.sakimura.org/en/ http://twitter.com/_nat_en -- Nat Sakimura (=nat) http://www.sakimura.org/en/ http://twitter.com/_nat_en ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] proposal for signatures
On 21 June 2010 16:33, Nat Sakimura sakim...@gmail.com wrote: On Mon, Jun 21, 2010 at 10:26 PM, Ben Laurie b...@google.com wrote: On 21 June 2010 14:22, Nat Sakimura sakim...@gmail.com wrote: Hi Dirk, In addition to Ben's questions, I have another. For X.509, you seem to be using DER. How do you express the entire certificate chain using DER? (With PEM, you can just concatenate ... ) With DER you can concatenate, too, of course. There's also PKCS#n (for some value of n which I forget ... 12?) which allows bundling of cert chains. That's PKCS#12, I suppose. I had under an impression that PKCS#12 includes the private key, though. Doesn't have to, though admittedly it isn't quite designed for this application. Presumably if we went down this route we'd have do no encryption and a well-known secret for the HMAC key. And here is some comments: If body_hash is not used, it seems it is just doing the client authentication via asymmetric crypto. This is a valid use case, and actually is quite nice. I think this is the main use case. If we wanted to make sure that the request itself is not tampered, we need to sign the body. For this, I somehow feel that Magic Signatures is more interoperable since it actually sends the armored ASCII strings with it. =nat On Mon, Jun 21, 2010 at 8:18 PM, Ben Laurie b...@google.com wrote: On 21 June 2010 08:04, Dirk Balfanz balf...@google.com 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 signature is a base64-encoded string of the signature bits. should be websafe-base64? the current time is not after the expiration time of the token (defined as not_before + session_length) should be not_before + token_lifetime, right? But I'd prefer a not_after instead. What is a Service Descriptor? Is this something to do with webfinger, or something else? In the HMAC keys section you describe the keys as symmetric, which is strictly accurate, but more normally called shared keys for this use. Obviously you'll need to be a bit more specific about what you mean by RSA-SHA256. 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 As you know, I hate the term non-repudation. Can't you just call it signing? Protection against leaked authentication tokens: Protocols such as OAuth2 use bearer tokens, which may leak when used over non-SSL. Signing requests when using bearer tokens lets the recipient of such a request verify that the issuer of the request was a legitimate holder of the bearer token. - only true if you make the checking of the nonce a MUST instead of may. And even then, MitM wins, of course. Why is body_hash optional? 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 You use the abbreviation AS before the full name Authorization Server. I also have started to write some code to implement this as a proof-of-concept. Thoughts? Comments? Nice. 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 -- Nat Sakimura (=nat) http://www.sakimura.org/en/ http://twitter.com/_nat_en -- Nat Sakimura (=nat) http://www.sakimura.org/en/ http://twitter.com/_nat_en ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] proposal for signatures
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 think you can still do that even if payload and envelope are combined.
the signed json would become:
{
signer: whoever-signed
encrypted_for: intended-destination
encrypted_payload: the-encrypted-payload
}
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] proposal for signatures
I'm not emphatic about either, but my vote is to remove the envelope.
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Brian
Eaton
Sent: Monday, June 21, 2010 9:49 AM
To: Dick Hardt
Cc: OAuth WG
Subject: Re: [OAUTH-WG] proposal for signatures
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 think you can still do that even if payload and envelope are combined.
the signed json would become:
{
signer: whoever-signed
encrypted_for: intended-destination
encrypted_payload: the-encrypted-payload }
___
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
Re: [OAUTH-WG] proposal for signatures
A couple of advantages of separating:
1) everything but the envelope data (key_id, signer, algorithm) gets
encrypted
2) if the encrypted data is an object in the JSON, then it has been base64
encoded, and then gets base64 encoded again. Much more efficient to include
the base64 encoded binary of the encrypted data as a separate field (this is
what motivated me to this separation to begin with
-- Dick
On Mon, Jun 21, 2010 at 10:54 AM, Justin Smith justi...@microsoft.comwrote:
I'm not emphatic about either, but my vote is to remove the envelope.
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of
Brian Eaton
Sent: Monday, June 21, 2010 9:49 AM
To: Dick Hardt
Cc: OAuth WG
Subject: Re: [OAUTH-WG] proposal for signatures
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 think you can still do that even if payload and envelope are combined.
the signed json would become:
{
signer: whoever-signed
encrypted_for: intended-destination
encrypted_payload: the-encrypted-payload }
___
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
Re: [OAUTH-WG] proposal for signatures
On Mon, Jun 21, 2010 at 4:18 AM, Ben Laurie b...@google.com wrote: On 21 June 2010 08:04, Dirk Balfanz balf...@google.com 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 signature is a base64-encoded string of the signature bits. should be websafe-base64? Yes. the current time is not after the expiration time of the token (defined as not_before + session_length) should be not_before + token_lifetime, right? Yes. But I'd prefer a not_after instead. Either way is fine with me. I picked token_lifetime b/c it tends to take up a little less space than a not_after, but I don't feel strongly about it. What is a Service Descriptor? Is this something to do with webfinger, or something else? Something else. I'm proposing that an OAuth Client be identifiable by a URL. You resolve the URL, you get everything you need to know about that Client. Simpler than webfinger. In the HMAC keys section you describe the keys as symmetric, which is strictly accurate, but more normally called shared keys for this use. Obviously you'll need to be a bit more specific about what you mean by RSA-SHA256. Right. Any suggestions what RSA-SHA256 should specifically refer to? If I stick that into a Signature.getInstance() call in Java, it returns _something_. Any idea what that is? I'd like say that whatever that is is what I mean by RSA-SHA256. 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 As you know, I hate the term non-repudation. Can't you just call it signing? What would you say is the advantage of public-key signatures over shared-key signatures? I do want to point out that this proposal includes public-key signatures, and therefore brings to advantages to the table. Protection against leaked authentication tokens: Protocols such as OAuth2 use bearer tokens, which may leak when used over non-SSL. Signing requests when using bearer tokens lets the recipient of such a request verify that the issuer of the request was a legitimate holder of the bearer token. - only true if you make the checking of the nonce a MUST instead of may. And even then, MitM wins, of course. MITM wins while the token is valid as per not_before and token_lifetime (or not_after). Why is body_hash optional? Maybe some Clients/PRs don't care? I remember that in OAuth 1, we couldn't ever get agreement on what to do about POST body signing, so I made it optional. I'm not going to stand in the way if people want this to be required. 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 You use the abbreviation AS before the full name Authorization Server. Oops - sorry. :-) I'll try to do a revision later tonight... Thanks for the feedback! Dirk. I also have started to write some code to implement this as a proof-of-concept. Thoughts? Comments? Nice. 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
Re: [OAUTH-WG] proposal for signatures
On Mon, Jun 21, 2010 at 6:22 AM, Nat Sakimura sakim...@gmail.com wrote: Hi Dirk, In addition to Ben's questions, I have another. For X.509, you seem to be using DER. How do you express the entire certificate chain using DER? (With PEM, you can just concatenate ... ) Good question: strawman answer: Don't put cert chains into the server info document. The verifier hopefully fetches the server info document over SSL, and can verify all the cert chains it wants in the SSL layer. We simply need a public key in the server info document. The option to include a certificate is purely there in case it's easier for you to generate an X.509 cert than a Magic Key. For example, if you already have concatenated PEMs, throw all but the first away, remove the newlines, prepend X509. and you have a valid representation of a public key, as far as JSON Tokens are concerned. What do you think? Dirk. And here is some comments: If body_hash is not used, it seems it is just doing the client authentication via asymmetric crypto. This is a valid use case, and actually is quite nice. I think this is the main use case. If we wanted to make sure that the request itself is not tampered, we need to sign the body. For this, I somehow feel that Magic Signatures is more interoperable since it actually sends the armored ASCII strings with it. =nat On Mon, Jun 21, 2010 at 8:18 PM, Ben Laurie b...@google.com wrote: On 21 June 2010 08:04, Dirk Balfanz balf...@google.com 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 signature is a base64-encoded string of the signature bits. should be websafe-base64? the current time is not after the expiration time of the token (defined as not_before + session_length) should be not_before + token_lifetime, right? But I'd prefer a not_after instead. What is a Service Descriptor? Is this something to do with webfinger, or something else? In the HMAC keys section you describe the keys as symmetric, which is strictly accurate, but more normally called shared keys for this use. Obviously you'll need to be a bit more specific about what you mean by RSA-SHA256. 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 As you know, I hate the term non-repudation. Can't you just call it signing? Protection against leaked authentication tokens: Protocols such as OAuth2 use bearer tokens, which may leak when used over non-SSL. Signing requests when using bearer tokens lets the recipient of such a request verify that the issuer of the request was a legitimate holder of the bearer token. - only true if you make the checking of the nonce a MUST instead of may. And even then, MitM wins, of course. Why is body_hash optional? 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 You use the abbreviation AS before the full name Authorization Server. I also have started to write some code to implement this as a proof-of-concept. Thoughts? Comments? Nice. 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 -- Nat Sakimura (=nat) http://www.sakimura.org/en/ http://twitter.com/_nat_en ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] proposal for signatures
Nat and Ben, In addition to Ben's questions, I have another. For X.509, you seem to be using DER. How do you express the entire certificate chain using DER? (With PEM, you can just concatenate ... ) With DER you can concatenate, too, of course. There's also PKCS#n (for some value of n which I forget ... 12?) which allows bundling of cert chains. That's PKCS#12, I suppose. I had under an impression that PKCS#12 includes the private key, though. A *.p7c file can be used to hold any number of certificates. It is a BER-encoded PKCS#7 value, now known as Cryptographic Message Syntax (CMS) standard [RFC 5652http://tools.ietf.org/html/rfc5652#section-5.1]. It is the ASN.1 syntax used for S/MIME signed email. If you only want to send certificates, just leaving out the content-to-be-signed, and the signatures. Such a file can hold any number of certificates, including public-key certificates, attribute certificates, or other certificate formats. It can also hold CRLs and other revocation information (including OCSP responses as per draft-turner-additional-cms-ri-choiceshttp://tools.ietf.org/html/draft-turner-additional-cms-ri-choices). CMS/PKCS#7 is better for this purpose than PKCS#12. -- James Manger ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
