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
