Hello! This email is intended to summarize the outcome of the WGLC on draft-ietf-ace-cwt-proof-of-possession-02 to date. This call was started on May 8 [1] and discussion occurred around two reviews of this -02 draft:
** Jim Schaad [Schaad], per https://www.ietf.org/mail-archive/web/ace/current/msg02747.html ** Roman Danyliw [Danyliw], per https://www.ietf.org/mail-archive/web/ace/current/msg02793.html After discussion on the mailing list, -03 of the draft was produced. Synthesizing the robust mailing list discussion, I see the following previously identified issues as still needing closure. The nature of the resolution varies. Given the volume of the discussion threads, I may have missed a response or failed to line up a text change in -03 to an issue. Please correct the status of any given point of feedback below. ==[ -03 contains changes, but ML discussion doesn't indicate closure ]== The following feedback was made about the -02 draft; changes to the relevant text was made in -03; but follow-up discussions on the mailing list doesn't indicate closure of the issue. If the originator of the feedback (it looks like only Jim for this section) feels the issue is closed, please speak up. [Schaad #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. [Schaad #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. [Schaad #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. [Schaad #9] In section 3.1 the first two sentences appear to be contradictory. Members are used to identify the POP key. Other things than a POP key can be used than a POP key. If they are used to identify the POP key- why would they not deal with the POP key? I think that you should do a separation and define the 'cnf' file which can hold any number of confirmation methods and then have a section on defining some POP cnf method field holders. [Schaad #10] In section 3.1 P1 - I am not sure why you have something here about confirming the authenticity of the token as oppose to confirming the identity of the presenter. Why would that type of information be placed here where it is not useful.] ==[ change was proposed, but not made ]== The draft editors proposed a changes on the mailing list to address the issue but it did not appear in the -03 draft. See the inline text of https://www.ietf.org/mail-archive/web/ace/current/msg02788.html for the proposed changes for [Schaad #12, 13, 16, 21]. [Schaad #12] I am unclear why there should be a restriction on the number of POP keys that can be in a 'cnf' object. If there are multiple keys, then any or all of them are of equal value in doing the confirmation. Just like there can be multiple confirmation methods and an application could choose to use any one of them. [Schaad #13] Not sure which section this belongs in, but the use of an COSE_Encrypt0 would be one way to combat tracking of identities based on the key value being used. Different encrypted values could be sent to different servers and they would not necessarily know about use w/o internal collusion between them. Similar effect by using an encrypted CWT. Potentially requires use of TLS1.3 to protect the RPKs. YMMV [Schaad #16] Section 4 - Are audience restrictions not done in CWT? -- same issues as [Danyliw #12] [Schaad #21] Section 6.2.2 - the value type is not an array for COSE_Encrypt or COSE_Encyrpt0, these are the values. As written I could put in an array which is not one of those two structures and be valid. Ditto for COSE_Key, although w/ slightly less justification. See the inline text of https://www.ietf.org/mail-archive/web/ace/current/msg02802.html for the proposed change for [Danyliw #7]. [Danyliw #7] Page 6, Section 3.3, The sentence "The COSE_Key could, for instance, be encrypted using a COSE_Encrypt0 representation using the AES-CCM-16-64-128 algorithm" seems out of place. What is this text explaining relative to the examples? ==[ face to face discussion required ]== Certain issues were deemed sufficiently complex to required face-to-face discussion at IETF 102. [Schaad #14] I have real problems w/ the use of a KID for POP identification. It may identify the wrong key or, if used for granting access, may have problems w/ identity collisions. These need to be spelt out someplace to help people tracking down questions of why can't I verify w/ this CWT, I know it's right. -- See https://www.ietf.org/mail-archive/web/ace/current/msg02853.html for more detailed discussion -- related issue to [Danyliw #8]. Regards, Roman [1] https://www.ietf.org/mail-archive/web/ace/current/msg02744.html _______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
