> -----Original Message----- > From: Mike Jones [mailto:[email protected]] > Sent: Friday, October 27, 2017 7:43 PM > To: Jim Schaad <[email protected]>; draft-ietf-ace-cwt-proof-of- > [email protected] > Cc: [email protected] > Subject: RE: Review of draft-ietf-ace-cwt-proof-of-possession 00 > > Thanks for the detailed review, Jim. Replies inline... > > -----Original Message----- > From: Jim Schaad [mailto:[email protected]] > Sent: Sunday, October 22, 2017 5:21 PM > To: [email protected] > Cc: [email protected] > Subject: Review of draft-ietf-ace-cwt-proof-of-possession 00 > > > * Section 2 - Issuer " Party that creates the CWT and binds the claims with > the POP key" > > The proposed language suggests something that's not true - that the PoP key > is used to sign the CWT, or something like that. It's the signing key that binds > the claims.
You are right - would be better as "bind the claims to the POP Key" > > * Section 2 - The definition of "presenter" in this document is odd given that > we are looking at ways that a CWT can be transferred by a third part. > A better term would be "Holder" or "Holder of Key" > > I'm reluctant to undergo a wholesale change of terminology when this comes > directly from the already-approved RFC 7800. (I'm of course willing to > entertain clarifications.) I'll think about a response. > * Section 3.1 para 4 - The thus in the first sentence does not follow from the > requirement. There is nothing that says that the same key could not be in > both the COSE_Key and Encrypted_COSE_Key fields. > > I suppose that's true but why would an application do or want both > unencrypted and encrypted representations of the same content? Requiring > them to be mutually exclusive simplifies applications, it seems to me. I am not objecting to the mutual exclusivity of the field. The rational needs to be appropriate > > * Section 3.2 and 3.3 should be written in terms of the fields COSE_Key and > Encrypted_COSE_Key rather than in terms of symmetric and asymmetric > keys. > Then you can properly talk about public and private keys in each of the > sections and it is tied to the structure itself rather than inferred > > Again, unless the text is wrong or unclear, we plan to leave most descriptions > parallel to those in RFC 7800. Your suggestion would be a rewrite. In my opinion, it is poorly written and confusing as to what is being accomplished and what the fields are. Reordering in this way would make it clear where currently it is not. Copying unclear text is generally not useful. > > * Section 3.4 - I would consider this to be an unusable item for doing POP key > identification in all cases where the kid is not computed in a cryptographic > manner and the method of computation is included as part of the kid. > > If the key ID doesn't match, the worst that will happen is the PoP verification > will fail. This is analogous to why it's ok for the Key ID to be in an unprotected > header in COSE. In the case of COSE, if you identify the wrong key then it would not validate. In this case if you have two different keys that had been presented to you with the same Key ID value and two different keys, when you get the CWT you do not know which of two keys is the POP key and which is not. The cases are not analogous. > > * Section 3.5 - Huh? I don't know about typically for the demonstration. > It could just as easily be done by doing an encryption/decryption operation > or a key derivation operation such as in TLS for PSK. I don't know that this > section is providing any useful information. If you think that it is needed then > a simple statement that you are not specifying how to do POP is sufficient. > > If you want to supply some additional text about these other methods, that > would be welcomed. I'll try and remember to look at this. If I don't have anything by the F2F remind me. > > * Section 4 paragraph 2 - I can understand a reasoning for doing audience > restrictions, but I cannot for the life of me figure out why it would be of > greater importance for POP statements than for any other set of claims. > > It's not more important, nor does it say that it is. But in the RFC 7800 last call > process, several people wanted us to add this security consideration. I'll re-read. > > * Section 4 - I am surprised there is no statement about self-signed CWT > statements esp. as that is given as an example of how additional naming > claims would be understood > > What would you like the statement to say? Something along the lines of it is only as good as the original trust in that person. Self-asserted statements are always suspect. > > * Section 5 - Need to make a statement about the correlation information > that a CWT issuer would have as well? > > The issuer is aware of all the audiences that it is issuing CWTs for. Is that > what you were getting after? No, I was thinking that a CWT issuer would know all of the audiences/permissions that a client is asking for using the same authentication key to the CWT even if the keys used to the servers are different. > > ==== > > Thanks again for the thorough review, as always! Stay tuned for -01... > > -- Mike > > > _______________________________________________ Ace mailing list [email protected] https://www.ietf.org/mailman/listinfo/ace
