search

cwt-cnf / i-d

Working repository for draft-ietf-ace-cwt-proof-of-possession
0 stars 3 forks source link

AD review: Need to clarify case when a recipient rejects a CWT with Key ID cnf #21

Open LudwigSeitz opened 5 years ago

LudwigSeitz commented 5 years ago

Discussion from Ben's review:

o  A recipient can decide not to use a CWT based on a created Key ID
   if it does not fit the recipient's requirements.

I'm not sure I understand the semantics being described here. Are we saying that the issuer might give a presenter a CWT, and by the time the presenter presents the CWT to the recipient, the recipient says "this is no good" and denies the transaction in question, forcing the presenter to go back to the issuer and try again? (How do we know that the issuer would make any different choices the second time around?)

This risk always exists. In a constrained device world, the recipient may already have cleared out the key referenced by the key ID, which would force it to reject a CWT using this as proof-of-possession.

I'm not sure how to give good guidance in this case. The error message delivered by the recipient rejecting the CWT might be helpful I suppose. Do you think this merits some text?

It's not entirely clear to me that we need to add more text here, but if we did, it would focus on what "decide not to use" means at a protocol level, and perhaps how the CWT might not "fit the recipient's requirements" (e.g., the key id having fallen out of cache as you describe).

LudwigSeitz commented 5 years ago

Note this text in the previous paragraph:

For asymmetric keys, the Key ID value is normally going to be generated by the CWT recipient, thus the possibility of collisions is greater.

This also seems wrong ...

LudwigSeitz commented 5 years ago

I think this whole bullet list is underspecified. Mike, git blame seems to indicate you wrote this, can you have a look?

LudwigSeitz commented 5 years ago

Specifically I don't quite understand how the recipient would set a key ID for a presenter's key and communicate this information to the issuer and the presenter.

hannestschofenig commented 5 years ago

In PR #27 I deleted the respective text. While it may be that there are some corner cases where a recipient rejects the communication attempts from the presenter those are failure cases because state got out of sync. If that's true then a new protocol exchange is needed. I am not sure we need to describe those unless we want to create a specific status code in a protocol for it; this document would then be the wrong place to do so...