clarify encryption keys use field

[c2bo]

Closes #642

[c2bo]

@QZHelen could i ask for your review as well? Couldn't select you for reviewers (probably because you didn't joint the gh org?).

[fkj]

The requirement that the Wallet MUST NOT select a key with the wrong use is new normative text, and surprisingly RFC 7517 does not contain any normative text saying what to actually do with a use parameter (e.g. that you MUST or SHOULD use a use=enc key only for encryption).

So this is technically a breaking change. However, I think any implementation that ignores use will never actually work anyway. So in this case I think we can make an exception. But this should be discussed in the WG. One option is to weaken the MUST NOT to a SHOULD NOT.

[QZHelen]

Looks good to me, many thanks for the work to clarify this!

[paulbastian]

My opinion is that "enc" actually fits well for the Credential Response encryption, while ECDH+MAC-based cryptographic holder binding should actually use sig value or register a new value for the use parameter. I believe the current language is a breaking change which we wanted to avoid.

[c2bo]

My opinion is that "enc" actually fits well for the Credential Response encryption, while ECDH+MAC-based cryptographic holder binding should actually use sig value or register a new value for the use parameter. I believe the current language is a breaking change which we wanted to avoid.

That is pretty much what the PR says? It just adds a simplification that if use isn't present, then encryption should be assumed as a simplification / leniency clause (since we've already seen implementations do that and it's strictly speaking not required right now).

[paulbastian]

approved after proper re-reading

[brentzundel]

Multiple positive reviews, sufficient review period, requests for changes all addressed, merging