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