cryptokeys comparison is unclear. Why the ordering?

[deeglaze]

The value stored under measurement-values-map key 12 is an array of $crypto-key-type-choice entries. $crypto-key-type-choice entries are CBOR tagged values. The array contains one or more entries in sequence.

The CBOR tag of the first entry of the Reference Value cryptokeys array is compared with the CBOR tag of the first entry of the ACS cryptokeys value. If the CBOR tags match, then the bytes following the CBOR tag from the Reference Value entry are compared with the bytes following the CBOR tag from the ACS entry. If the byte strings match, and there is another array entry, then the next entry from the Reference Values array is likewise compared with the next entry of the ACS array. If all entries of the Reference Values array match a corresponding entry in the ACS array, then the cryptokeys Reference Value matches. Otherwise, cryptokeys does not match.

This confuses me. I can't conceptualize the procedure this is describing, and I don't know why it only cares about tagged values. The $crypto-key-type-choice choice can be extended with non-tagged values. I don't know why it describes the tagged value comparison in two steps when it seems equivalent to just compare binary encodings.

It seems like it requires the size of the condition's key array to be less than or equal to the candidate's key array size, and that all elements of the condition's key array must be binary equal to the corresponding position in the candidate's key array. Seems strange to not allow some permutation in the comparison. Why is this not a subset semantics? Does this really need to impose an ordering?

The intended meaning of the triple is lost on me. It would help to have some supporting prose. Is it that the environment could be reasonably expected to give a proof of possession for these keys? I could see the ordering mattering if you're expecting the format of a CA bundle, but whether you're iterating from the left or right can cause problems due to bundle inconsistencies across server implementations as root..leaf or leaf..root