* I dislike the statement of what the specification claims to do. It will be misread by many people who are not familiar with how you are defining the word "presenter". If I intercept a CWT and present it to a validator, it does not make a claim that I possess a specific POP key. Given what a CWT is supposed to do, I believe that a much clearer statement of functionality would be "This specification describes how to associate a set of claims in a CWT with a particular proof-of-possession key." Among other things, this would allow a third party to "present" a CWT on behalf of another party. (See introspection.)
* I dislike the way that the second sentence of the introduction is written. Please remove the text about the presenter, that is not relevant to the holder-of-key assertion. * Section 2 - Issuer " Party that creates the CWT and binds the claims with 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" * Section 3 paragraph 1 - This paragraph is written with some things taken for granted that I am not user exist. 1) How is the issuer doing the declaration that a presenter possesses a key, is a POP of the key a requirement to issue the CWT that I have not yet seen? 2) Again I don't like the use of presenter as the key usage and transfer are not necessarily done at the same time. * Section 3 paragraph 2 - You need to be clearer about what you mean by identified. My reading would be that the presenter is identified by the POP key. If you want to talk about claims which contain other types of naming material, then you need to be clear that is what you are doing. * Section 3 paragraph 2 - I would skip most of the detail on the meanings of the different claims and just identify the number of claims and refer to the CWT document for details on what they mean. The current text is not clear, and hopefully, the CWT document is much clearer on what these mean. * General - Where are you defining the types and contents of the claims that are being registered in this document? I cannot find it and I expected it to be in section 3.1 * Section 3.1 para 1 - Based on the last sentence, I think that you need to make some type of statement about the purpose of the "cnf" claim that embodies both a POP key and the SAML stuff that you are adding. What are the requirements to be here? What are the relationships between statements? * Section 3.1 para 2 - It is fine to say that what the set of methods that must be present is application dependent, however without the presence of some type of profile identification, how is an application supposed to know if the meanings and relationships are what are expected and not from some other profile? * 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. * Section 3.1 para 4 - I don't understand the process defined in sentence #2 and why it is done this way. It would make more sense to me to say that it could be a new field with an array of cnf values. Doing the "additional to 'cnf'" would seem to cause potential problems when this CWT is grabbed by somebody which does not understand how these two fields are related. * Change the examples to use CBOR diagnostic notation. * 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 * 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. * 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. * 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. * Section 4 para 4 - How does a signed nonce prevent a replay attack with encrypted symmetric secrets? * 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 * Section 5 - Need to make a statement about the correlation information that a CWT issuer would have as well? _______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
