Ability to transfer opaque application data

[geonnave]

Addressing #3.

The idea is to use 'ciphertext' from COSE_Encrypt0, which already has a MAC (the authentication tag), with the added benefit that now it is possible for W to send encrypted opaque data to U.

[geonnave]

Some notes:

• I am not sure SCOPE is the best name here. Maybe OPAQUE_DATA or similar (open to ideas).
• I don't know if there is a rule for naming things like K_2 and info_label, so I just incremented them from the values already in the draft.

[geonnave]

Discussed in the design team meeting:

# from U to W:
now: plaintext = ID_U
desired: plaintext =

ENC_U_INFO = (
  ID_U: bstr
  ?opaque_info: bstr
    e.g. available_networks, e.g. mac address (previously u_hints)
)

# from W to U:
ENC_W_INFO = (
  ?opaque_info: bstr
    e.g. selected/proposed_networks, e.g. mac address (previously v_hints)
)

[geonnave]

Just to update on the above, what we really want is to enable transmission of an optional OPAQUE_INFO in the three cases below:

1. from U to W, within EAD_1 / Voucher_Info
ENC_U_INFO = (
  ID_U: bstr
  ?OPAQUE_INFO: bstr
    e.g. available_networks, e.g. mac address (previously u_hints)
)

2. from W to U, within EAD_2 / Voucher
plaintext of Voucher = (
  ?OPAQUE_INFO: bstr
    e.g. selected/proposed_networks, e.g. mac address (previously v_hints)
)

(note that in this case the MAC, which was originally the full content of the Voucher, will be the authentication tag generated during encryption)

3. from W to U, within Error message
plaintext of REJECT_INFO = (
    ?OPAQUE_INFO:            bstr,
)

In this PR, cases 1 and 2 are addressed (I am updating its title). Case 3 is being handled in PR #9, and will be updated once this one is settled, as it is now establishing some new terminology.

[geonnave]

@gselander I added an example of what could go in the voucher on commit 893d156. Could you please take a look?