That’s only if you’re using good hardware to produce a key. We can’t assume that’s the only kind of client that will exist, and software generation is likely to be much more common for a while yet.
Perhaps what we really need is strong guidance on when to use which approach. “If you client has a strong random generator function then you can make your own key, but otherwise let the server do it for you." — Justin > 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%2fse >>>>> lf-issued.info%2fdocs%2fdraft-ietf-oauth-proof-of-possession-06.htm >>>>> l&data=01%7c01%7ctonynad%40microsoft.com%7c9456670075d04a51f85508d2 >>>>> e59ba294%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=EQd4rUcuyqdSP >>>>> 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%2fww >>>>> w.ietf.org%2fmailman%2flistinfo%2foauth&data=01%7c01%7ctonynad%40mi >>>>> crosoft.com%7c9456670075d04a51f85508d2e59ba294%7c72f988bf86f141af91 >>>>> ab2d7cd011db47%7c1&sdata=ND3ydaXOsPMsoRhE0Uyq0uznGy6MdYOLZQJHLhEQKJ >>>>> 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%40mi >>>>> crosoft.com%7c9456670075d04a51f85508d2e59ba294%7c72f988bf86f141af91 >>>>> ab2d7cd011db47%7c1&sdata=ND3ydaXOsPMsoRhE0Uyq0uznGy6MdYOLZQJHLhEQKJ >>>>> s%3d >>>>> >>>> >>>> _______________________________________________ >>>> 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%40micr >>>> osoft.com%7c9456670075d04a51f85508d2e59ba294%7c72f988bf86f141af91ab2 >>>> d7cd011db47%7c1&sdata=ND3ydaXOsPMsoRhE0Uyq0uznGy6MdYOLZQJHLhEQKJs%3d >>> >>> _______________________________________________ >>> 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%40micros >>> oft.com%7c9456670075d04a51f85508d2e59ba294%7c72f988bf86f141af91ab2d7c >>> d011db47%7c1&sdata=ND3ydaXOsPMsoRhE0Uyq0uznGy6MdYOLZQJHLhEQKJs%3d >> > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2foauth%0a&data=01%7c01%7ctonynad%40microsoft.com%7c9456670075d04a51f85508d2e59ba294%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=BLqSuDjWLY72fGm0UrpLwxQVnamMelggJeOpYJESVFs%3d _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
