No not really, Hannes's language is much closer to what I am looking for. I don't care if they are different kinds of CWTs. I care about impersonation.
> -----Original Message----- > From: Mike Jones <michael.jo...@microsoft.com> > Sent: Friday, June 22, 2018 10:44 PM > To: Jim Schaad <i...@augustcellars.com>; Hannes Tschofenig > <hannes.tschofe...@arm.com>; draft-ietf-ace-cwt-proof-of- > possess...@ietf.org > Cc: ace@ietf.org > Subject: RE: Key IDs ... RE: [Ace] WGLC on draft-ietf-ace-cwt-proof-of- > possession-02 > > I think you're looking for language something along these lines, right Jim? > > "Likewise, if PoP keys are used for multiple different kinds of CWTs in an > application and the PoP keys are identified by Key IDs, care must be taken to > keep the keys for the different kinds of CWTs segregated so that an attacker > cannot cause the wrong PoP key to be used by using a valid Key ID for the > wrong kind of CWT." > > -- Mike > > -----Original Message----- > From: Jim Schaad <i...@augustcellars.com> > Sent: Friday, June 22, 2018 7:59 AM > To: Hannes Tschofenig <hannes.tschofe...@arm.com>; Mike Jones > <michael.jo...@microsoft.com>; draft-ietf-ace-cwt-proof-of- > possess...@ietf.org > Cc: ace@ietf.org > Subject: RE: Key IDs ... RE: [Ace] WGLC on draft-ietf-ace-cwt-proof-of- > possession-02 > > That language works if you assume that there is only one CWT that an RS will > look to. If there are multiple CWTs then one needs coordination language > between them. > > > -----Original Message----- > > From: Hannes Tschofenig <hannes.tschofe...@arm.com> > > Sent: Friday, June 22, 2018 6:36 AM > > To: Jim Schaad <i...@augustcellars.com>; 'Mike Jones' > > <michael.jo...@microsoft.com>; draft-ietf-ace-cwt-proof-of- > > possess...@ietf.org > > Cc: ace@ietf.org > > Subject: Key IDs ... RE: [Ace] WGLC on draft-ietf-ace-cwt-proof-of- > > possession-02 > > > > Hi Jim, > > > > I would like to comment on this issue. > > > > ----- > > > > 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. > > > > > > The Key ID is a hint to help identify which PoP key to use. Yes, if > > > a Key > > ID is > > > sent that doesn't correspond to the right PoP key, failures may occur. > > > I > > view > > > that as usage bug - not a protocol problem. If keys aren't > > > consistently > > known > > > and identified by both parties, there are lots of things that can go > > wrong, and > > > this is only one such instance. That said, I can try to say > > > something > > about the > > > need for keys to be consistently and known by both parties, if you > > > think > > that > > > would help. > > > > > My problem is that if there are two different people with the same > > > Key ID, > > either intentionally or unintentionally, then using the key ID to > > identify > the > > key may allow the other person to masquerade as the first person. I > > am unworried about the instance of a failure to get a key based on a key id. > > That is not the problem you are proposing to address. > > > > ----- > > > > I think we should document this issue. Here is some text proposal that > could > > go into a separate operational consideration section (or into the > > security consideration section instead). > > > > " > > - Operational Considerations > > > > The use of CWTs with proof-of-possession keys requires additional > > information to be shared between the involved parties in order to > > ensure correct processing. The recipient needs to be able to use > > credentials to > verify > > the authenticity, integrity and potentially the confidentiality of the > > CWT > and > > its content. This requires the recipient to know information about the > issuer. > > Like-wise there needs to be an upfront agreement between the issuer > > and the recipient about the claims that need to be present and what > > degree of trust can be put into those. > > > > When an issuer creates a CWT containing a key id claim, it needs to > > make sure that it does not issue another CWT containing the same key > > id with a different content, or for a different subject, within the > > lifetime of the > CWTs, > > unless intentionally desired. Failure to do so may allow one party to > > impersonate another party with the potential to gain additional > privileges. > > " > > > > > > Ciao > > Hannes > > > > IMPORTANT NOTICE: The contents of this email and any attachments are > > confidential and may also be privileged. If you are not the intended > recipient, > > please notify the sender immediately and do not disclose the contents > > to > any > > other person, use it for any purpose, or store or copy the information > > in > any > > medium. Thank you. _______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
