Thanks for the detailed review, Jim. Replies inline...
-----Original Message-----
From: Jim Schaad [mailto:i...@augustcellars.com]
Sent: Sunday, October 22, 2017 5:21 PM
To: draft-ietf-ace-cwt-proof-of-possess...@ietf.org
Cc: ace@ietf.org
Subject: Review of draft-ietf-ace-cwt-proof-of-possession 00
* 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'll look at revising this along the lines you suggest. The existing language,
of course, is a direct adaptation of that from RFC 7800.
* 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.
OK
* 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.
* 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.)
* 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.
I'll think about what you're saying, but "presenter" is one of the well-defined
roles in PoP interactions. You seem to not like the term, but it's the one in
common use.
* 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.
OK - I'll give the claims wording suggestion a shot.
* 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.
I'll try to strike a balance between incorporating this suggestion for
additional clarity and maintaining the spirit of the RFC 7800 language. (If we
deviate very much, people will rightly ask the question "Why does this have a
different meaning than the corresponding RFC 7800 text?")
* 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
I agree more needs to be done in this regard. The current text relies too much
on things that were implicit in JSON, rather than explicitly defining the CBOR
types.
* 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?
It's not adding SAML stuff. It's making an analogy to a SAML feature. I'll
try to make this clearer.
* 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?
The values are always processed and validated within the context of the
application profile. No identifier is needed to tell the application what its
validation rules are.
* 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.
* 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.
OK - I'll try to make this clearer.
* Change the examples to use CBOR diagnostic notation.
-01 will do that, thanks to Ludwig!
* 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.
* 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.
* 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.
* 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.
* Section 4 para 4 - How does a signed nonce prevent a replay attack with
encrypted symmetric secrets?
Because a different nonce would be required to be used for each CWT using the
PoP key. I'll try to clarify this.
* 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?
* 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?
====
Thanks again for the thorough review, as always! Stay tuned for -01...
-- Mike
_______________________________________________
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace
