Thanks for your useful review, Jim. Replies are inline below...
-----Original Message----- From: Jim Schaad [mailto:i...@augustcellars.com] Sent: Tuesday, June 27, 2017 12:50 AM To: draft-jones-ace-cwt-proof-of-possess...@ietf.org Cc: ace@ietf.org Subject: Review of draft-jones-ace-cwt-proof-of-possession-00 Abstract - I am unclear how this is a profile of RFC 7800 rather than a restatement of that document. In what way does this qualify as a profile? The draft now says that it provides equivalent functionality to RFC 7800 rather than being a profile of it. Introduction - I do not understand the second half of the first sentence in the introduction. It claims that the document is going to show how proof of possession is done, however this seems to be explicitly declared as out of scope in section 3.5. You're right. I have deleted the second half. Section 2 - Since this document is currently planned to come from the ACE working group, I would suggest that it would be reasonable to provide the equivalent terminology to what is in this document. -- see actors Maybe we can talk about specific proposed edits in Prague. Section 3 - para 1 - missed a s/JSON/CBOR/ Fixed Section 3 - para 2 - I am not sure of the following: - Why this is included here and not a separate section It was here in RFC 7800. It could be moved and given its own section but wanted to start out with a completely parallel document. - Why the concept of an anonymous POP is not supported I assume you're talking about a situation in which the identity of the presenter is not known or revealed? I assume this is related to your next comment? - Why the concept of the issuer being inferred from the authentication key on the CWT is not supported If this is done in practice, particularly within ACE, this could be explicitly mentioned in the future. - I will note that draft-ietf-ace-oauth-authz does not require either of these fields to be present. Thanks for pointing this out. I've removed this requirement to give profiles full freedom of how to identify the presenter. Section 3.1 - The first two sentences seems to be slightly contradictory - the first says the cnf claim is used to identify the POP key. The second states that it may have something other than a POP key in it. It's really about saying that "confirmation" is broader than "confirmation-by-PoP". This draft covers the latter, but defines the "cnf" claim to enable the broader uses, as in SAML 2.0. I'll think about how to word this more clearly. Section 3.1 - I am not a fan of MUST ignore statements at this level. It should be profile statement if anything. The "MUST be ignored" is essential for future extensibility. Otherwise, anything new added breaks everything already deployed. Section 3.1 - last paragraph - Does this mean that only one claim can be in the cnf claim - or are some values of different levels? For example -can I have a COSE_Key and an Kid? This might be considered to be multiple POP keys. As long as the "kid" refers to the same key, you're golden. I think it already says that somewhere, but I'll look into it further. Section 3.2 - Profiles can require that additional elements can be required in the COSE_Key element - and example would be to require that the algorithm identifier be present. That's fine. The spec already says that other key elements can be included. Section 3.2 - I do not understand why this paragraph is doing in this section give the section title. Why is it not in section 3.3 or in a separate section. I think it makes mores sense at the end of the next section. Public keys are represented in the clear. That's different than the symmetric keys in 3.3, which have to be encrypted to prevent them from being revealed. Section 3.3 - Why is title not symmetric with section 3.2 and the word encrypted be absent? See the previous reply Section 3.4 - This section just makes me uncomfortable. Use a value that was potentially chosen for collisions does not seem to be a good idea. I think this really needs some additional guidance about using. If both parties already have the key, using a Key ID rather than transmitting the key is an optimization that is used in practice. What else would you like us to say about this? Section 4 - Is there any reason to suppose that the use of asymmetric secrets are immune from replay attacks? Is there particular Security Considerations text that you'd like to see included about this? Section 3.1 - para 1 -sentence #2 - I do not understand the implication that the POP key implies the authenticity of the token. That statement makes no sense to me. This would look like a self-signed certificate as the authentication point. See the SAML 2.0 comment earlier. Jim I plan to publish an updated version in the next day or so, after giving the authors of draft-ietf-ace-oauth-authz a chance to look it over. Thanks again, -- Mike
_______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
