A high level / managerial perspective. Apologies in advance
for where it drifts from actual specifications.
We are deep down the rabbit hole known as
_profiles v. algorithms_
It is worth standing back and thinking about this because
when V5 keys are looked it, it is possible that we could
solve this.
PGP was designed in the early 90s when algorithms were
thought to be all there was to crypto. Now, we know that's
wrong [1]. Now, we know it is all about applications and
users, and they want communication before security, and
security before crypto. From a crypto standpoint, profiles
are the only way forward, because they remove
interoperability issues, which improves communications.
But, still, today, OpenPGP prefers to indicate algorithms
not profiles, so what to do?
1. Leave it entirely out of the ECC document and let the
implementors discuss it. The problem with this is as
highlighted by the Willmer/Laurie case. They apparently had
to backtrack from their "cleanroom dox" implementation and
go find info that was "shared" not written. So we are
adding in an additional drag on the implementors.
That's fine if you believe that all implementors should talk
anyway, but not so fine if some only talk in Chinese and
others have poor social skills and good code is downloadable
from sourceforge.
2. "legislative" position in the ECC document. Something like:
OpenPGP-ECC has no implied preference,
and explicitly drops the TripleDES implied preference
of RFC4880. Each algorithm must be expressed.
The existance of preferences AES-128 and AES-256 only
MAY be taken as a signal that Suite-B is required.
Or somesuch. Plus side might be that it might mean less
interop testing and less code. That would be a big win for
ECC coders in the mobile field, as they could get a single
tight profile.
Minus side might be that it might be ignored. Or, it might
not, if we choose carefully. If it is ignored, we've lost
nothing. If it is followed, then we've won.
3. "Security Notes / Comments" to the effect that the world
has moved on and implementations should avoid using the old
stuff. Something like:
Although RFC4880 includes TripleDES as an obligatory
and common algorithm, this algorithm is out of date.
Implementors are likely to limit TripleDES to
interoperability testing only, and application
developers are likely to not offer TripleDES, or
offer it under override conditions only.
Implemetors should follow the profiles
suggested in Suite-B.
This means that implementors still have to write TripleDES
code and still have to interop test it. But application
developers can ignore it.
4. Two Key flags to specify Suite-B (S + TS) as suggested
by Andrey. This in effect adds profiles.
If we can do this for Suite-B, we can do it for RSA and
other things. Consider a Suite-RSA "for the rest of us":
Secret: AES-128, RSA-3072, SHA256
TopSecret: AES-256, RSA-8192, SHA512
But this might be better off being left for V5? Dunno.
iang
[1] This is not a new mistake. Kherdkoffs wrote about it in
1883.