Good to know. So the AS needs to expose a public key for the TPM to use for encryption. I am guessing you are not using a encrypted JWK for that. What is the format the TPM produces the wrapped key in?
John B. > On Nov 5, 2015, at 1:55 PM, Anthony Nadalin <tony...@microsoft.com> wrote: > > 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
