So given that new programs will need to have 3DES anyway to cover the
transition case, and given that messages sent to a mixture of old and new
keys that are forced to use the cipher of last resort will end up as 3DES....
This is (mainly) about ECC keys, and specifically about the
implementations' [ability to enforce] Suite-B compliance.
As old applications won't be able to understand ECC keys *at
all*, we've "almost" got a clean sheet with what we do with
ECC keys. "Almost," because at present ECC keys inherit
3DES as the default cipher from 4880.
how is (B) different than the current cipher preference system with
AES listed before 3DES?
right - which is why my original proposal was for a stronger
suite B flag, which says implementations MUST NOT process
messages that fall outside of the Suite-B restrictions (that aside,
Andrey has written in "OpenPGP technical/documentation terms"
what I was originally trying to get across with my perhaps wrong
terminology of a Strict Suite-B "flag").
(And to directly answer your question, Andrey's B is slightly different,
in that while the preference system *is* ordered, implementations
currently have free rein at how they use the intersection of
recipient preferences; Andrey's B says that AES should be used
in place of 3DES - but as you've (now) pointed out, for non-ECC
keys this may mean some people receiving AES messages when
in fact they can e.g. only process 3DES ones).