Move external_aad to the end of structures using it and make its presence optional

[selfissued]

The external_aad feature is one not found in JOSE, CMS, XMLDSIG, or other commonly used cryptographic formats. While I am satisfied with the resolution of issue #16 keeping this feature because of the discussions about the CoAP use cases that occurred in Yokohama, I still would like to see the common case that doesn't use it simplified.

Currently, the sig_structure contains [ body_protected, sign_protected, external_aad, payload ]. I request that this be reordered to [ body_protected, sign_protected, payload, external_aad ] and the external_aad array element be specified to be not present when no external_aad value is supplied, so that in the no-external_aad case, the sig_structure value becomes [ body_protected, sign_protected, payload ]. It's no harder for the code to omit it than to include a zero-length binary value, as currently specified. And the code still signs the whole array - it's just that the array can have either 4 or 3 elements.

Similarly, please revise the hmac_structure and enc_structure, placing external_aad at the end and making its presence optional.

[jimsch]

I do not want to do this from a security point of view. Having a fixed sized array with that is always filled in leads to one less possibility of a coding error where you might have the external data but incorrectly fail to encode it. A single way of doing this is both simpler to think about and easier to encode. There is no significant burden to including the field even if you never support it.

[selfissued]

Invoking security seems incorrect and overstated here. These values are never parsed - which is when security issues tend to arise. They are just created internally and then used as serialized byte array inputs to cryptographic operations. There is no security problem with having both 3-member and 4-member array values for this intermediate temporary result.

Please capitalize on this opportunity to "keep simple things simple" - one of the working group principles stated by the chairs on slide 22 of their opening presentation at https://www.ietf.org/proceedings/93/slides/slides-93-cose-2.pdf. Especially in light of the fact that many implementations won't need support for external_aad, per issue #50, please make these implementations simpler by making the presence of the external_aad array member optional.

[jimsch]

Beauty is in the eye of the beholder on this in terms of what is easier.

However, while putting something other than the body last works for signatures with appendix schemes, it will not work correctly for signature recovery schemes. For such schemes the body needs to be last so that it is the part that is going to be recovered. Otherwise, there is no difference in the size of the message that is being transmitted. Recovering the external AAD information which is not transmitted does not help reduce the message size.