clarify issuer_signed_alg_values and device_signed_alg_values

[Sakurann]

resolves #548 which was remaining after we merged #500

accommodates identifiers defined in

• 18013-5 (including device mac auth)
• a fully-specified cryptographic algorithm spec
• else

[martijnharing]

I don't think this updated text addresses the issue:

My interpretation of the proposed text is that it says:

1. If the 'alg' COSE header is one of the algorithms defined in 9.1.2.4 (ES256, ES384, ES512 or EdDSA), the 'alg' COSE header must match one of the elements in the array.
2. If the 'alg' COSE header is one of the algorithms defined in [Jose-fully-specified] (ESP256, ESP384, ESP512, ESB256, ESB320, ESB384 or ESB512), the 'alg' COSE header must match one of the elements in the array.
3. If the 'alg' COSE header is anything else, the combination of the 'alg' value of the COSE header and the 'crv' parameter from the signing key must resolve to a fully-specified algorithm which must match one of the array values.

Since an mdoc not using one of the alg values as specified in 18013-5 will be uncommon at best (since it's not compliant to 18013-5), effectively 1. is the most common scenario. This means there is no way for the verifier to say "I support P-256, but not Brainpool256", or the other way round. Reading #500 , it seems that a (the?) reason to add this request parameter was to have a way for the verifier to indicate which curves it supports by having a 'crv' parameter. The 'crv' parameter was then removed noting that there is the [Jose-fully-specified] spec, but the currently proposed text doesn't actually allow the [Jose-fully-specified] spec to be used with the existing 'alg' parameters.

To support crv selection, either we need a crv_values parameter, or we need to allow the use of the [Jose-fully-specified] spec to be used when the 'alg' parameter in the header does not use an 'alg' from the [Jose-fully-specified] spec.

I think the intention is to do something like:
issuer_signed_alg_values: OPTIONAL. A JSON array containing cryptographic algorithm identifiers. If present, the credential must match one of the elements in the array. The credential matches a value in the array if one of the following is true:

• The value in the array matches the 'alg' value in the IssuerAuth COSE header.
• The value in the array is a fully specified algorithm according to [@!I-D.ietf-jose-fully-specified-algorithms] and the combination of the 'alg' value in the 'IssuerAuth' COSE header and the curve used by the signing key of the COSE structure matches the combination of the algorithm and curve identified by the fully specified algorithm.

As an example, if the 'IssuerAuth' structure contains an alg header with value -7 (which stands for ECDSA with SHA-256) and is signed by a P-256 key, then it matches an issuer_signed_alg_values element of -7 and -9.

Noting that the value of -9 is the requested value for ECDSA using P-256 curve and SHA-256.

[Sakurann]

Asia wg call discussion

To support crv selection, either we need a crv_values parameter, or we need to allow the use of the [Jose-fully-specified] spec to be used when the 'alg' parameter in the header does not use an 'alg' from the [Jose-fully-specified] spec.

• these are the options we have at hand. defining issuersigned_crv_values from IANA is probably a simpler and more future proof (from the perspective of new PQC algs being registered, for example).

[martijnharing]

I think this has the same issues as the issuer_signed_alg_values for the signing operation, see the other comment on how I think it could be addressed.
However this would not yet address the issue for maccing mentioned in the previous comment. Since 18013-5 always uses HMAC 256/256, specifying that algorithm just says that maccing is supported. It doesn't say which curves. So including device_signed_alg_values is not possible if you only support a subset of curves for maccing.
A possible solution could be to similarly define codes for 'fully' specified maccing algorithms to be used with this specification.

[Sakurann]

same as above, add devicesigned_crv_values

[awoie]

requested some changes

[awoie]

ISO does not use crv values but the signing algorithm can be represented by a COSE curve identifier. The curve used for the key in the signing algorithm is derived from the x5chain, i.e., the X.509 doc signer certificate. I'd also rename issuer signed -> issuer auth since more precise. Perhaps the following suggestion works:

Suggested change

	* `issuer_signed_alg_values`: OPTIONAL. A JSON array containing cryptographic algorithm identifiers. If the `IssuerSigned` structure of the presented mdoc is signed using an algorithm defined in section 9.1.2.4 of [@ISO.18013-5], the `alg` COSE header (as defined in [@!RFC8152]) MUST match one of the -5-style identifiers in the array. If 18013-5 is not used, but the signature uses a fully-specified algorithm as defined in [@!I-D.ietf-jose-fully-specified-algorithms], the `alg` value MUST match one of the array values. In all other cases — typically involving polymorphic algorithm identifiers — the combination of the `alg` value from the COSE header and the `crv `parameter from the signing key MUST resolve to a fully-specified algorithm, which MUST match one of the array values.
	* `issuer_auth_alg_values`: OPTIONAL. A JSON array containing cryptographic COSE algorithm identifiers. If present, the `IssuerAuth` structure as defined in [@ISO.18012-5] MUST be signed with an algorithm that matches one of the algorithms in the array. If the COSE algorithm identifier is polymorphic, it is RECOMMENDED to include `issuer_auth_crv_values` to clarify the ambiguity.
	* `issuer_auth_crv_values`: OPTIONAL. A JSON array containing cryptographic COSE curve identifiers. If present, the cryptographic curve of the key that signed the `IssuerAuth` structure as defined in [@ISO.18013-5] MUST match one of the curve identifiers included in the array.

[awoie]

I would also rename device signed -> device auth (since MAC and ECDSA is supported) and it is also more precise. Same as above but it should be noted that HMAC with DH key exchange is supported:

Suggested change

	* `device_signed_alg_values`: OPTIONAL. A JSON array containing cryptographic algorithm identifiers. If the DeviceSigned structure of the presented mdoc is signed using an algorithm defined in Section 9.1.3.6 of [@ISO.18013-5], the alg COSE header (as defined in [@!RFC8152]) MUST match one of the -5-style identifiers in the array. If mdoc MAC Authentication (as defined in Section 9.1.3.5 of [@ISO.18013-5]) is used, the alg COSE header MUST be HMAC 256/256. If 18013-5 is not used, but the signature uses a fully-specified algorithm defined in [@!I-D.ietf-jose-fully-specified-algorithms], the alg value MUST match one of the array values. In all other cases — typically involving polymorphic algorithm identifiers — the combination of the alg value from the COSE header and the crv parameter from the signing key MUST resolve to a fully-specified algorithm, which MUST match one of the array values.
	* `device_auth_alg_values`: OPTIONAL. A JSON array containing cryptographic COSE algorithm identifiers. If present, the `DeviceAuth` structure as defined in [@ISO.18012-5] MUST be signed or MACed with an algorithm that matches one of the elements in the array. If the COSE algorithm identifier is polymorphic, or MAC-based, it is RECOMMENDED to include `device_auth_crv_values` to clarify the ambiguity.
	* `device_auth_crv_values`: OPTIONAL. A JSON array containing cryptographic COSE curve identifiers. If present, the cryptographic curve of the key used to sign the `DeviceAuth` structure as defined in [@ISO.18012-5] or to derive the MAC key used for computing the MAC MUST match one of the identifiers listed in the array.

[paulbastian]

As much as I love fully-specified algorithms, it may be easier to implement to use the versions using crv as defined in -5

[awoie]

Doesn't seem to be simpler than defining an additional _crv param but still approving this.

[c2bo]

tried to fix the rendering/references issues and add document history - please check

[davidz25]

Looked through, seemed to match what we talked about in the DCP call earlier, thanks!

[tplooker]

Very confused to have seen this PR merged in this fashion considering the conversation that was had on the Asia call earlier in the day, this is not what was discussed or agreed. What was discussed and I believe there was agreement on, including multiple people in this issue referencing the same solution was the preference to have a second metadata element which communicated the curve.

The approach decided here limits our ability to be forward compatible with new algorithms that might get registered in the COSE IANA registry as we are limiting ourselves to only a subset of algorithms supported in COSE by pointing at a definition from a specific IETF document rather than just the underlying IANA registry. Even if fully specified algs is adopted tomorrow, there is going to be a long tail of implementations that support the current alg identifiers and this approach is going to cause implementations to have to constantly map identifiers to and from old to new ones.

[Sakurann]

I think what was discussed was that since we don't think we expect fully specified algs to be used, let's optimize for the solution for 18013-5 implementations. ( I forgot to ask for the note taker so we unfortunately do not have detailed notes, sorry about that.. )