Sent from my iPhone
> On Nov 20, 2015, at 2:53 PM, John Bradley <ve7...@ve7jtb.com> wrote: > > I don’t know of any special requirements for representing HSM keys. I wasn't suggesting that there were separate requirements or different key types as that would not be the case, just that the discussions did not seem to be complete. > > How they are negotiated and stored is out of scope for this draft. > > I think Brian mentioned that we had an example that is different from the > default in the POP drafts. That can be looked at. > > I don’t think we want to get into key management. That should be left to > specifications that use this. > > Chuck’s example gets into proof mechanisms for token presentment. > That is also out of scope for this draft. There are two mechanisms as part > of the POP specs. Ok, sounds good. Thanks. > One is mutual TLS and the other is using a signed message. > I think the signed message one is what he is looking for. > https://tools.ietf.org/html/draft-ietf-oauth-signed-http-request-01 > > I suppose that you could over sign the token itself but there are perhaps > better ways to do it. > So if wrapping rules are needed that would probably be part of a pop token > proof presentment spec. Ok, thanks. Kathleen > > > John B. > >> On Nov 20, 2015, at 4:32 PM, Mike Jones <michael.jo...@microsoft.com> wrote: >> >> HSM-backed public keys would be represented in the same way that other >> public keys are - using the standard JWK representation for them. Likewise >> for TPM-backed public keys. That said, I'm not an expert in TPMs and know >> that they define TPM-specific signature formats but to my understanding, >> they're using standard kinds of keys. If this isn't the case, a new key >> type ("kty") would be needed to represent them, but they'd still be >> represented as a JWK in the JWT using that key type. The draft would still >> work fine for these use cases as written. Does that sound right to people >> or am I missing something here? >> >> For Chuck's nested JWT use case, that seems like it would work out as he >> described it. Note that he's primarily describing the protocol messages >> he's using to do the proof-of-possession - not just how to represent the PoP >> key in a JWT - which is the scope of this draft. The PoP protocol pieces >> are explicitly out of scope for this draft - it's just about PoP key >> representation. >> >> If I have the above right, does anyone believe that we nonetheless need to >> do an update to the draft? If so, can you supply proposed wording or at >> least the gist of the additional ideas that you'd like to have conveyed. >> >> Best wishes, >> -- Mike >> >> -----Original Message----- >> From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Kathleen Moriarty >> Sent: Friday, November 20, 2015 11:12 AM >> To: Chuck Mortimore <cmortim...@salesforce.com> >> Cc: <oauth@ietf.org> <oauth@ietf.org> >> Subject: Re: [OAUTH-WG] Proof-of-Possession Key Semantics for JWTs spec >> addressing final shepherd comment >> >> Hi, >> >> This draft was tossed over the fence to me, but it seems that there may be a >> few open questions that remain. Use of HSM and TPMwere raised in this tread >> and not addressed in the current draft version. >> >> Is guidance needed for nested JWTs? If not, why? >> >> In a separate thread, JWK is mentioned, but I'm okay with that text as there >> is a reference. >> >> I'd like to get this moving, os if we can wrap up these questions and if >> anything will be done about them, it would be helpful. >> >> Thank you, >> Kathleen >> >>> On Thu, Nov 5, 2015 at 3:07 PM, Chuck Mortimore <cmortim...@salesforce.com> >>> wrote: >>> The spec is very clear for most cases, but I think it could use some >>> guidance on nested JWTs. (Or perhaps I've got the approach wrong.) >>> >>> Here's the use-case: >>> We have devices that are self-issuing keys. Via token exchange, we're >>> going to except a self-signed JWT from the device that includes a "cnf" >>> claim of the key they generated. Assuming the signature checks out on >>> that JWT, we'll then bind that key into a "cnf" claim in a new token >>> that we issue and sign with a tenant key. >>> >>> When the device goes to use that token, the device would sign it, >>> constructing a nested JWT. The outer signature is the proof of possession >>> of the device's private key. The inner signature is our signature that >>> binds the public key used to validate the outer token. >>> >>> Does this sound correct? The processing order is a bit odd since you first >>> need to unpack and validate the inner token before you can validate the >>> outer token. Is there some other way this is intended to work? >>> >>> thanks >>> >>> -cmort >>> >>> >>> >>>> On Wed, Nov 4, 2015 at 8:58 PM, John Bradley <ve7...@ve7jtb.com> wrote: >>>> >>>> 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%7c9456670075d04a51f >>>>>>>>>> 85508d2e59ba294%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=6 >>>>>>>>>> hE6dOO0I1%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-0 >>>>>>>>>> 6.ht >>>>>>>>>> m >>>>>>>>>> l&data=01%7c01%7ctonynad%40microsoft.com%7c9456670075d04a51f85 >>>>>>>>>> 508d >>>>>>>>>> 2 >>>>>>>>>> e59ba294%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=EQd4rUcu >>>>>>>>>> yqdS 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%40micr >>>>>>>>>> osoft.com%7c9456670075d04a51f85508d2e59ba294%7c72f988bf86f141a >>>>>>>>>> f91ab2d7cd011db47%7c1&sdata=TMfX1tG5qucl%2be2KVpyMBuj72ZQ%2f%2 >>>>>>>>>> bEKGoTyJyf%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%7c72f988bf86f14 >>>>>>>>>> 1af9 >>>>>>>>>> 1 >>>>>>>>>> ab2d7cd011db47%7c1&sdata=ND3ydaXOsPMsoRhE0Uyq0uznGy6MdYOLZQJHL >>>>>>>>>> hEQK >>>>>>>>>> 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%7c72f988bf86f14 >>>>>>>>>> 1af9 >>>>>>>>>> 1 >>>>>>>>>> ab2d7cd011db47%7c1&sdata=ND3ydaXOsPMsoRhE0Uyq0uznGy6MdYOLZQJHL >>>>>>>>>> hEQK >>>>>>>>>> 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%4 >>>>>>>>> 0mic >>>>>>>>> r >>>>>>>>> osoft.com%7c9456670075d04a51f85508d2e59ba294%7c72f988bf86f141af >>>>>>>>> 91ab >>>>>>>>> 2 >>>>>>>>> d7cd011db47%7c1&sdata=ND3ydaXOsPMsoRhE0Uyq0uznGy6MdYOLZQJHLhEQK >>>>>>>>> Js%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%40m >>>>>>>> icro >>>>>>>> s >>>>>>>> oft.com%7c9456670075d04a51f85508d2e59ba294%7c72f988bf86f141af91a >>>>>>>> b2d7 c >>>>>>>> d011db47%7c1&sdata=ND3ydaXOsPMsoRhE0Uyq0uznGy6MdYOLZQJHLhEQKJs%3 >>>>>>>> d >>>>>> >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org >>>>>> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fw >>>>>> ww.i >>>>>> etf.org%2fmailman%2flistinfo%2foauth%0a&data=01%7c01%7ctonynad%40m >>>>>> icro >>>>>> soft.com%7c9456670075d04a51f85508d2e59ba294%7c72f988bf86f141af91ab >>>>>> 2d7c >>>>>> d011db47%7c1&sdata=BLqSuDjWLY72fGm0UrpLwxQVnamMelggJeOpYJESVFs%3d >>>> >>>> _______________________________________________ >>>> 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 >> >> >> >> -- >> >> Best regards, >> Kathleen >> >> _______________________________________________ >> 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 > _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
