I can say on all windows based devices (pc, xbox, phone, etc) with only TPM 1.1 this will be the approach so it will be commonly used
-----Original Message----- From: John Bradley [mailto:ve7...@ve7jtb.com] Sent: Wednesday, November 4, 2015 8:52 PM To: Anthony Nadalin <tony...@microsoft.com> Cc: Justin Richer <jric...@mit.edu>; <oauth@ietf.org> <oauth@ietf.org> Subject: Re: [OAUTH-WG] Proof-of-Possession Key Semantics for JWTs spec addressing final shepherd comment OK, no good reason unless the client is using a HSM that can do HMAC and can export a symmetric key wrapped in a asymmetric key provided by the AS. We don’t currently cover that use case of sending a wrapped symmetric key to the AS in POP key distribution. I don’t know how common that is going to be, but it is worth thinking about defining. John B. > On Nov 5, 2015, at 1:45 PM, Anthony Nadalin <tony...@microsoft.com> wrote: > > Not sure why you think its weaker as it would be a wrapped key that > the hardware produces > > -----Original Message----- > From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of John Bradley > Sent: Wednesday, November 4, 2015 8:43 PM > To: Justin Richer <jric...@mit.edu> > Cc: <oauth@ietf.org> <oauth@ietf.org> > Subject: Re: [OAUTH-WG] Proof-of-Possession Key Semantics for JWTs > spec addressing final shepherd comment > > In the asymmetric case the use of a HSM or secure element is the argument for > the client selecting the public key. In those cases the client is doing the > key gen in hardware so one hopes it is OK. In the symetric case the client > generating the key is weaker (as in I can’t think of any really good reason). > > >> On Nov 5, 2015, at 1:35 PM, Justin Richer <jric...@mit.edu> wrote: >> >> I’d argue that it’s best practice, and in line with other parts of OAuth, if >> we assume the server generates it in the normal case (issuer -> presenter). >> Client generated token keys should be an exception, especially in the >> asymmetric case. >> >> — Justin >> >>> On Nov 5, 2015, at 1:32 PM, John Bradley <ve7...@ve7jtb.com> wrote: >>> >>> Agreed the only real difference is the quality of the key. If the server >>> generates it, then it knows that the client is not using the fixed hex >>> value of DEADBEEF for everything. >>> >>> John B. >>>> On Nov 5, 2015, at 9:25 AM, Hannes Tschofenig <hannes.tschofe...@gmx.net> >>>> wrote: >>>> >>>> I agree that the effect is the same. From a security point of view >>>> there is only an impact if one of the two parties is in a better >>>> position to generate random numbers, which is the basis for >>>> generating a high entropy symmetric key. >>>> >>>> On 11/04/2015 11:51 PM, Mike Jones wrote: >>>>> Thanks for the detailed read, Brian. You’re right that in the >>>>> symmetric case, either the issuer or the presenter can create the >>>>> symmetric PoP key and share it with the other party, since the effect is >>>>> equivalent. >>>>> I suspect that both the key distribution draft and this draft >>>>> should be updated with a sentence or two saying that either >>>>> approach can be taken. Do others concur? >>>>> >>>>> >>>>> >>>>> -- Mike >>>>> >>>>> >>>>> >>>>> *From:*Brian Campbell [mailto:bcampb...@pingidentity.com] >>>>> *Sent:* Thursday, November 05, 2015 7:48 AM >>>>> *To:* Mike Jones >>>>> *Cc:* Kepeng Li; oauth@ietf.org >>>>> *Subject:* Re: [OAUTH-WG] Proof-of-Possession Key Semantics for >>>>> JWTs spec addressing final shepherd comment >>>>> >>>>> >>>>> >>>>> +1 for the diagrams making the document more understandable. >>>>> >>>>> One little nit/question, step 1 in both Symmetric and Asymmetric >>>>> keys shows the Presenter sending the key to the Issuer. It's >>>>> possible, however, for the key to be sent the other way. Presenter >>>>> sending it to the Issuer is probably preferred for asymmetric, >>>>> especially if the client can secure the private keys in hardware. >>>>> But I don't know if one way or the other is clearly better for >>>>> symmetric case and PoP key distribution currently has it the other >>>>> way >>>>> <https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2ftools.ietf.org%2fhtml%2fdraft-ietf-oauth-pop-key-distribution-02%23section-4.2&data=01%7c01%7ctonynad%40microsoft.com%7c9456670075d04a51f85508d2e59ba294%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=UgZEoqQiaUk9VdYpSQRvUeVVOQgIUg3UmAr18oQ7GtI%3d>. >>>>> Should the intro text somehow mention the possibility that the >>>>> Issuer could create the key and send it to the Presenter? >>>>> >>>>> I know it's only the introduction but it was just something that >>>>> jumped out at me. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On Wed, Nov 4, 2015 at 9:04 AM, Mike Jones >>>>> <michael.jo...@microsoft.com <mailto:michael.jo...@microsoft.com>> wrote: >>>>> >>>>> Thanks for suggesting the diagrams, Kepeng. They make the document >>>>> more understandable. >>>>> >>>>> -- Mike >>>>> >>>>> ------------------------------------------------------------------ >>>>> - >>>>> ----- >>>>> >>>>> *From: *Kepeng Li <mailto:kepeng....@alibaba-inc.com> >>>>> *Sent: *11/5/2015 12:57 AM >>>>> *To: *Mike Jones <mailto:michael.jo...@microsoft.com>; >>>>> oauth@ietf.org <mailto:oauth@ietf.org> >>>>> *Subject: *Re: Proof-of-Possession Key Semantics for JWTs spec >>>>> addressing final shepherd comment >>>>> >>>>> Thank you Mike. >>>>> >>>>> >>>>> >>>>> The diagrams look good to me. >>>>> >>>>> >>>>> >>>>> Kind Regards >>>>> >>>>> Kepeng >>>>> >>>>> >>>>> >>>>> *发件人**: *Mike Jones <michael.jo...@microsoft.com >>>>> <mailto:michael.jo...@microsoft.com>> >>>>> *日期**: *Thursday, 5 November, 2015 12:32 am >>>>> *至**: *"oauth@ietf.org <mailto:oauth@ietf.org>" <oauth@ietf.org >>>>> <mailto:oauth@ietf.org>> >>>>> *抄送**: *Li Kepeng <kepeng....@alibaba-inc.com >>>>> <mailto:kepeng....@alibaba-inc.com>> >>>>> *主题**: *Proof-of-Possession Key Semantics for JWTs spec addressing >>>>> final shepherd comment >>>>> >>>>> >>>>> >>>>> Proof-of-Possession Key Semantics for JWTs draft -06 addresses the >>>>> remaining document shepherd comment – adding use case diagrams to >>>>> the introduction. >>>>> >>>>> >>>>> >>>>> The updated specification is available at: >>>>> >>>>> · >>>>> https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2ftools.ietf.org%2fhtml%2fdraft-ietf-oauth-proof-of-possession-06&data=01%7c01%7ctonynad%40microsoft.com%7c9456670075d04a51f85508d2e59ba294%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=6hE6dOO0I1%2ffF005rVknyOFHuB18gdpZg9dftExLtCw%3d >>>>> >>>>> >>>>> >>>>> An HTML formatted version is also available at: >>>>> >>>>> · >>>>> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fs >>>>> e >>>>> lf-issued.info%2fdocs%2fdraft-ietf-oauth-proof-of-possession-06.ht >>>>> m >>>>> l&data=01%7c01%7ctonynad%40microsoft.com%7c9456670075d04a51f85508d >>>>> 2 >>>>> e59ba294%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=EQd4rUcuyqdS >>>>> P gmibtcfjMpJm6RWWwCZC85%2bCboEs54%3d >>>>> >>>>> >>>>> >>>>> -- Mike >>>>> >>>>> >>>>> >>>>> P.S. This note was also posted at >>>>> https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fself-issued.info%2f%3fp%3d1471&data=01%7c01%7ctonynad%40microsoft.com%7c9456670075d04a51f85508d2e59ba294%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=TMfX1tG5qucl%2be2KVpyMBuj72ZQ%2f%2bEKGoTyJyf%2bfJi4%3d >>>>> and as @selfissued >>>>> <https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2ftwitter.com%2fselfissued&data=01%7c01%7ctonynad%40microsoft.com%7c9456670075d04a51f85508d2e59ba294%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=LfFAjchzCTh0x%2fY9hr0W%2fSohPGgb0JVjL%2f2Az%2f12BCg%3d>. >>>>> >>>>> >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org <mailto:OAuth@ietf.org> >>>>> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fw >>>>> w >>>>> w.ietf.org%2fmailman%2flistinfo%2foauth&data=01%7c01%7ctonynad%40m >>>>> i >>>>> crosoft.com%7c9456670075d04a51f85508d2e59ba294%7c72f988bf86f141af9 >>>>> 1 >>>>> ab2d7cd011db47%7c1&sdata=ND3ydaXOsPMsoRhE0Uyq0uznGy6MdYOLZQJHLhEQK >>>>> J >>>>> s%3d >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fw >>>>> w >>>>> w.ietf.org%2fmailman%2flistinfo%2foauth&data=01%7c01%7ctonynad%40m >>>>> i >>>>> crosoft.com%7c9456670075d04a51f85508d2e59ba294%7c72f988bf86f141af9 >>>>> 1 >>>>> ab2d7cd011db47%7c1&sdata=ND3ydaXOsPMsoRhE0Uyq0uznGy6MdYOLZQJHLhEQK >>>>> J >>>>> s%3d >>>>> >>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fww >>>> w >>>> .ietf.org%2fmailman%2flistinfo%2foauth&data=01%7c01%7ctonynad%40mic >>>> r >>>> osoft.com%7c9456670075d04a51f85508d2e59ba294%7c72f988bf86f141af91ab >>>> 2 >>>> d7cd011db47%7c1&sdata=ND3ydaXOsPMsoRhE0Uyq0uznGy6MdYOLZQJHLhEQKJs%3 >>>> d >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww. >>> ietf.org%2fmailman%2flistinfo%2foauth&data=01%7c01%7ctonynad%40micro >>> s >>> oft.com%7c9456670075d04a51f85508d2e59ba294%7c72f988bf86f141af91ab2d7 >>> c d011db47%7c1&sdata=ND3ydaXOsPMsoRhE0Uyq0uznGy6MdYOLZQJHLhEQKJs%3d >> > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.i > etf.org%2fmailman%2flistinfo%2foauth%0a&data=01%7c01%7ctonynad%40micro > soft.com%7c9456670075d04a51f85508d2e59ba294%7c72f988bf86f141af91ab2d7c > d011db47%7c1&sdata=BLqSuDjWLY72fGm0UrpLwxQVnamMelggJeOpYJESVFs%3d _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
