David Crick wrote:
"11.3. Interoperability with Suite-B profile" currently states:
"If TripleDES is the only shared algorithms for a set
of recipients, no Suite-B compliant recipient can be added to the
mentioned recipient set."
I had to look at all of 11.3 to try and make sense of this,
and found that whole subsection to be hopelessly confusing.
Can we have a simple statement as to whether an
OpenPGP-ECC key can be used with TripleDES or not? Can
messages be mixed-mode or not?
It seems to me that if an application creates and exports an
OpenPGP-ECC key (only) then that public key cannot be used
with TripleDES, as the document does not suggest it anywhere
(and implies it is ruled out). Which means there should be
a specific claim that this ECC draft overrules the
"guarantee" of TripleDES intersection in RFC4880.
(To me, this seems like a reasonable price to pay to get a
good, clear result.)
Alternatively, there should be a specific claim permitting
use of TripleDES and describing how/what.
(I should note that I do not recall the discussions of a few
months back. This should be a "good thing" because it
allows me to view it as a first time reader. My routine
excuse is that if I can't understand it from a simple
reading then I suspect we are putting an unnecessary burden
on first time readers, but not many agree with that!)
but doesn't state how this may be enforced by the *recipient*
(who may not currently have a way of specifying this to the
sender).
Personally, I would have said that the recipient should
reject the message with an error. If there is a mixed mode
message, then the sender is in error, allowing for a
potential attack. We might not be able to stop the attack
through a misbehaving client, but we should red-flag it when
we see it.
(but I've not seen the full sense yet, I may be wrong.)
(Apps have these flags to decrypt even when there are errors
in modes, so that's ok.)
I therefore have a suggestion:
implement a key-packet preference flag that says "strict SuiteB"
If this is set, then applications MUST NOT use any other cipher
other than one of the allowed AES sizes for that ECC key size.
This will allow us to disallow 3DES (and any other non-AES cipher)
by setting this key flag.
Independent of this, an application may additionally have an
--enforce-suiteB flag/checkbox
thoughts people?
these complexities will roll forward in history :( ...
iang