Why 2.1 is delayed for so long

[Robert J. Hansen]

> Yes, this is the use-case. It's clearer architecturally. Longer-term 
> benefits include not accidentally using the master key for signing, 
> for a naive program that has access to your master key. If you
> prefer "less keys", why not default to Certify+Sign+Authenticate? I
> am not sure Certify+Sign makes sense from any position.

This may require a little bit of history.

Most people think of Occam's razor as "the simplest explanation is
best," but that's actually not right: William of Ockham's original
formulation was "do not multiply objects without necessity."

In the PGP 2.6 days there was only a single key which did everything.
Then the U.K. passed a law, the Regulation of Investigatory Powers Act,
which gave the government a way to demand encryption keys from suspects.
 This was troubling for PGP, since giving over your encryption key also
meant giving the government the ability to impersonate you.  In order to
defend against RIPA and RIPA-like laws, the OpenPGP community decided to
use separate encryption and signing keys.

Further, there was (at the time) some talk from the theoretical
cryptographic community that using the same key for encryption and
signing could lead to attacks on the system.  Although this research
didn't pan out (at least as applied to OpenPGP), this too caused a lot
of people in the community to think separating keys into signing and
encryption sets was a good idea.

All told, if my memory is right this took a couple of years of argument
and people implementing their own testbeds and everything else before
things got sorted out.

Occam approves.  Objects were multiplied, but only because they needed
to be -- and it took a good bit of time, which meant the changes were
judicious, thoroughly debated, and we had real-world tests before anyone
went off adopting them for large systems.

I don't think you've made a compelling case for multiplying them yet again.

> You are being hasty and this is extremely unproductive logic. We are 
> talking about what the defaults *should be*. You know that it's 
> extremely costly to distribute a fork; I start at a disadvantage if
> I want to test the validity of my ideas in the market.

Every new idea starts at a disadvantage, yet ideas displace other ideas
with astonishing speed.  It's like Bob Heinlein said: "Of course the
game is rigged, but don't let that stop you: you can't win if you don't
play."