On May 4, 2008, at 12:25 PM, David Crick wrote:
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.
I understand that this is intended to be about ECC keys, but the slate
isn't even "almost" clean so long as as we're playing alongside 4880.
There are a bunch of messy cross cases that make this highly resistant
to cleanliness.
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").
This sort of thing risks putting restrictions in places that can't
always handle those restrictions. Take the restriction where the
implementation, in its Suite-B mode, must not allow the sending of
messages to keys that can't handle Suite-B: so much so that it's even
verboten to send two messages. Now take real-world examples like that
of Enigmail, which uses GPG as its crypto engine. How on earth is
GPG, the "OpenPGP implementation" in that system, supposed to stop
Enigmail from doing that? Forget GPG even - outside of a locked down
environment, how is any implementation supposed to stop the user from
doing that?
I'm okay with some magic flag that says "I do Suite-B", if we leave
the implementation alone to deal with it (within the bounds of
interoperability). I'm even more in favor of combining that with a
"OpenPGP Suite-B" document that lays out all the rules, whether they
pertain to the OpenPGP message format, or how a mail program is
allowed to send mail. A separate document, where those who need those
semantics can have them all specified in detail, but those who don't
need those semantics are not encumbered with by them.
David