Ian G wrote:
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?
OK, the suggestion noted. The support for TrippleDES follows from RFC 4880.
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.
The quote above is an example. It has an "IF" in it. I didn't imply in
11.3 to rule TrippleDES out.
(To me, this seems like a reasonable price to pay to get a good, clear
result.)
I think it is important that new keys seamlessly integrate with existing
keys and deployed applications. It's a good cause to allow
non-government users to increase the strength of their public keys at
lower cost that ECC provides.
We have similar issue with FIPS.
Alternatively, there should be a specific claim permitting use of
TripleDES and describing how/what.
I will add an assertive statement about TrippleDES.
(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 agree. When Suite-B profile is involved user may not be able to send
out (encode). Splitting a message into two, one using 3DES and another
one using AES, is not an option. Depending on how the discussion about
choosing the Suite-B goes (key or software?), I will add stricter
statement about the the failure on the sender's side.
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