mandate AES-256 support and promote its use

[TJ-91]

Here is my proposal to include AES-256 as a mandatory-to-implement algorithm and to promote its use as discussed in #74. I tried to consider all cases and find the best balance between forcing (and migrating to) AES-256 and interoperability with the older specs (RFC4880, Crypto Refresh).

Cases to consider are:

• Encrypting to a v4 certificate with a PQ/T encryption subkey
• Encrypting to a v4 certificate with only traditional keys
• Encrypting to a v6 certificate with any PQ(/T) key.
• Encrypting to a v6 certificate without any PQ(/T) key.
• Encrypting to certificates that explicitly indicate AES-128 or AES-256 support
• Encrypting to certificates that do not indicate AES-128 or AES-256 support
• Encrypting to any combination of the cases above

Another important aspect: If all involved parties use PQ(/T) keys, then AES-256 will be supported (and hopefully favored) by every party. To further push AES-256, I have added the following sentence to the security considerations:

An implementation SHOULD use AES-256 in the case of a v1 SEIPD packet, or AES-256 and OCB in the case of a v2 SEIPD packet, if all recipients indicate support for it (explicitly or implicitly).

The reason is that when carelessly implementing the specification, an implementation might otherwise choose to take the simple way of always encrypting via AES-128, even if every recipient uses the "Level 5" PQ algorithms.

---

Please also comment on:

• The place where the text is added and the names of the sections
• Is there a better place to state Implementations MUST implement AES-256?

---

If we want to ask for opinions on the mailing list, the argument is: AES-256 is the obvious choice and this will result in everyone using PQ(/T) + AES-256 in the long run. We are committed to AES-256 anyway by the KEM construction.

[TJ-91]

• I moved the SHOULD from the security considerations
• I added some text to justify the "SHOULD use AES-256" thing. Is it sufficient?
• I adjusted the titles of the two sections to match

[wussler]

Please add a note in the changelog :)

[TJ-91]

I rebased, added a changelog for the next version, and addressed Falko's comments