Re: [Ace] WGLC on draft-ietf-ace-cwt-proof-of-possession-02
I have removed items where the proposed solution is probably sufficient. > -Original Message- > From: Mike Jones > Sent: Sunday, May 20, 2018 4:34 AM > To: Jim Schaad ; draft-ietf-ace-cwt-proof-of- > possess...@ietf.org > Cc: ace@ietf.org > Subject: RE: [Ace] WGLC on draft-ietf-ace-cwt-proof-of-possession-02 > > Thanks for your useful comments, Jim. Replies are inline below. > > -Original Message- > From: Jim Schaad > Sent: Wednesday, May 9, 2018 6:51 AM > To: draft-ietf-ace-cwt-proof-of-possess...@ietf.org > Cc: ace@ietf.org > Subject: RE: [Ace] WGLC on draft-ietf-ace-cwt-proof-of-possession-02 > > I'll pull out the list of comments that I wrote a month ago but didn't start that > computer up recently. > > 1. Are all of the authors necessary? As a chair I need to justify a count of > more than 5 to the IESG. > > The authors are the union of the set of authors of draft-jones-ace-cwt- > proof-of-possession-00 and draft-ietf-ace-oauth-authz-04, which both > contained independently developed and largely parallel treatments of the > CWT PoP confirmation subject. Ludwig was the primary author of this text in > the second, so he should definitely be retained as an editor. I'll leave it up to > the other authors of draft-ietf-ace-oauth-authz-04 to self-identify whether > they materially contributed to the CWT PoP confirmation text or not. Maybe > we can delete those who don't self-identify as contributors. > > 4. Terminology: I still think this is 'Presenter' is a very strange term to use for > this definition. I would really like to see it be made something that makes > sense and then say the term is the same as this in JWT. The term has a > model of use with it that I do not believe can be sustained even for the ACE > Oauth case but really not in other cases. > > This is the standard term for this role in the industry. For instance, Section > 1.2 (Terminology) of "SAML V2.0 Holder-of-Key Assertion Profile Version 1.0" > http://docs.oasis-open.org/security/saml/Post2.0/sstc-saml2-holder-of-key- > cd-01.pdf defines "Presenter" with an equivalent meaning. > > Also, for this reason, this is the same terminology used for this role in RFC > 7800. It is used pervasively throughout both this document and RFC 7800 - > including in the diagrams in the introduction of RFC 7800. I believe we would > be doing a disservice to readers and implementers if we were to use a > different term from that in RFC 7800 (and SAML) when the meaning is > identical. > > 5. Terminology: Recipient matches presenter, and it matches the OAuth > model > and not a trust model world. Relying party or service provider make far > more sense to me. > > Same response as to 4. We owe it to readers and implementers to keep the > terminology consistent with RFC 7800 and industry practice. > > 6. Under what circumstances would a 'sub' claim be present and it is not the > presenter? I can see that a holder of the key may be implicitly (or > anonymously) named, but putting something in the subject field which is not > identifying the presenter is something that I would reject without a good > presentation of why in the document. > > Just as in https://tools.ietf.org/html/draft-ietf-secevent-token-13 (which is > in the hands of the RFC Editor), it's dependent upon the profiling > specification how the "sub" claim is used. In some cases the subject and/or > presenter will be identified with some combination of "iss" and/or "sub". In > other profiles, different representations will be appropriate, such as the use > of the "subject_type" value in the RISC example in > https://tools.ietf.org/html/draft-ietf-secevent-token-13#section-2.1.4. > > Remember that in both JWT and CWT, the inclusion of *all* claims is left up > to the profile. The same is true of RFC 7800 and this spec (other than the use > of the "cnf" claim). We shouldn't tie the hands of profiles in a way that > prevents them from using the representation of the presenter that is most > natural for their use case. I think you have done a good job of arguing my case that this is something that should be removed. If it is appropriate to a specific profile then that should be stated in that profile and not in the general document. > > 7. I would disagree with the claim that if the 'sub' claim is missing then it > would normally be the issuer. For the world of IoT, I would expect that the > subject would not be present because there is no need to identify the > subject to the recipient. I.e. it is an anonymous subject. > > I'm fine adding language saying that in some use cases, such IoT use cases, > explicit identification of the presenter may not be necessary because in > some cases, the recipient already implicitly has this information. And I can > drop the "normally" language about "iss" and instead tone it down to talk > about "in some use cases". Again - this seems like a statement that should be made in a profile and not in this documen
Re: [Ace] WGLC on draft-ietf-ace-cwt-proof-of-possession-02
Thanks for your useful comments, Jim. Replies are inline below. -Original Message- From: Jim Schaad Sent: Wednesday, May 9, 2018 6:51 AM To: draft-ietf-ace-cwt-proof-of-possess...@ietf.org Cc: ace@ietf.org Subject: RE: [Ace] WGLC on draft-ietf-ace-cwt-proof-of-possession-02 I'll pull out the list of comments that I wrote a month ago but didn't start that computer up recently. 1. Are all of the authors necessary? As a chair I need to justify a count of more than 5 to the IESG. The authors are the union of the set of authors of draft-jones-ace-cwt-proof-of-possession-00 and draft-ietf-ace-oauth-authz-04, which both contained independently developed and largely parallel treatments of the CWT PoP confirmation subject. Ludwig was the primary author of this text in the second, so he should definitely be retained as an editor. I'll leave it up to the other authors of draft-ietf-ace-oauth-authz-04 to self-identify whether they materially contributed to the CWT PoP confirmation text or not. Maybe we can delete those who don't self-identify as contributors. 2. Is the last sentence in section 1 necessary? Are you actually defining any strings that could be case-sensitive? Sure - we can delete the text "Unless otherwise noted, all the protocol parameter names and values are case sensitive." It's a holdover from RFC 7800 that doesn't apply here. 3. Terminology: In the definition of Issuer please make 'its' clearer. It is not clear whose claims are being bound. We can change "its claims" to "the claims in the CWT". 4. Terminology: I still think this is 'Presenter' is a very strange term to use for this definition. I would really like to see it be made something that makes sense and then say the term is the same as this in JWT. The term has a model of use with it that I do not believe can be sustained even for the ACE Oauth case but really not in other cases. This is the standard term for this role in the industry. For instance, Section 1.2 (Terminology) of "SAML V2.0 Holder-of-Key Assertion Profile Version 1.0" http://docs.oasis-open.org/security/saml/Post2.0/sstc-saml2-holder-of-key-cd-01.pdf defines "Presenter" with an equivalent meaning. Also, for this reason, this is the same terminology used for this role in RFC 7800. It is used pervasively throughout both this document and RFC 7800 - including in the diagrams in the introduction of RFC 7800. I believe we would be doing a disservice to readers and implementers if we were to use a different term from that in RFC 7800 (and SAML) when the meaning is identical. 5. Terminology: Recipient matches presenter, and it matches the OAuth model and not a trust model world. Relying party or service provider make far more sense to me. Same response as to 4. We owe it to readers and implementers to keep the terminology consistent with RFC 7800 and industry practice. 6. Under what circumstances would a 'sub' claim be present and it is not the presenter? I can see that a holder of the key may be implicitly (or anonymously) named, but putting something in the subject field which is not identifying the presenter is something that I would reject without a good presentation of why in the document. Just as in https://tools.ietf.org/html/draft-ietf-secevent-token-13 (which is in the hands of the RFC Editor), it's dependent upon the profiling specification how the "sub" claim is used. In some cases the subject and/or presenter will be identified with some combination of "iss" and/or "sub". In other profiles, different representations will be appropriate, such as the use of the "subject_type" value in the RISC example in https://tools.ietf.org/html/draft-ietf-secevent-token-13#section-2.1.4. Remember that in both JWT and CWT, the inclusion of *all* claims is left up to the profile. The same is true of RFC 7800 and this spec (other than the use of the "cnf" claim). We shouldn't tie the hands of profiles in a way that prevents them from using the representation of the presenter that is most natural for their use case. 7. I would disagree with the claim that if the 'sub' claim is missing then it would normally be the issuer. For the world of IoT, I would expect that the subject would not be present because there is no need to identify the subject to the recipient. I.e. it is an anonymous subject. I'm fine adding language saying that in some use cases, such IoT use cases, explicit identification of the presenter may not be necessary because in some cases, the recipient already implicitly has this information. And I can drop the "normally" language about "iss" and instead tone it down to talk about "in some use cases". 8. It is not clear to me that either of the sub and iss claims would normally be present. They might be present but neither is needed. The subject can be anonymous and the issuer is identified by the key used to validate the security on the CWT. Per my response to 7, I c
