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
