Simon Josefsson wrote:
* We're deprecating V3 keys. You should either not mention them, or
mention that they're deprecated.
What would a suitable reference for that decision be?
It's been debated on this list many times. I
don't think there is a suitable single for
this. Here's the summary of the issues that
I know of, but bear in mind that I am biased.
1. V3 keys are subject to a few quirky security
issues.
2. V3 usage is quite low. I don't think this has
been tested properly, but we are talking in the
low 1-10% area.
3. V3 architecture is old. A rewrite is well
over due. (Note that the same applies to the
V4 architecture which is now a good 8 years
old or so ;)
4. Supporting both key types is a drain on
the implementors. If they are supporting
old / dying key formats, they are not writing
other crypto code.
5. As it is security code, the notion of clearing
out deadwood is always good. Complexity
leads to security holes. This is different to
the (say) Microsoft world where customer
compatibility is the important issue. (hmmm,
maybe I need to revise that? Nah...)
6. Finally, deprecating the V3 in the standard
doesn't mean you can't support it. By all means,
support it if you think there is some use for it.
Dropping it from the standard just means that
we are not telling all the implementors that
they *have* to support it. So now, V3 can move
over to a market-driven retirement. In practice,
I suspect it will take another 5 years before the
major apps drop support for it.
7. Our decision not to support it in the Java
library is indicative of a small budget; there's
no way we can do "it all". I imagine a lot of
small implementors will think the same,
RFC2440bis is already so big that something
has to give.
Hmm... having written all that, I'm not sure
there is a case for keeping them above :) I'll
let someone else write that.
iang
--
News and views on what matters in finance+crypto:
http://financialcryptography.com/