Why 2.1 is delayed for so long

[Ximin Luo]

On 23/09/14 15:31, Robert J. Hansen wrote:
>> 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.
> 
> [..]
> 
> 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.
> 

Yes, it would seem you're not learning *enough* from this history. New laws are being passed that make it legal (hah!) for intelligence services to hack into computers. I would rather different keys for different purposes be separated, and my master key moved offline. If my signature key gets compromised, at least they can only write emails claiming to be me, not sign fake keys on my behalf.

Plenty of skilled people are already using Certify-only master keys. I certainly want to, but it's awkward because I don't want to keep changing my long-term key. As soon as EdDSA is stable, I am going to generate a new one. Many GPG guides propose this. There is very little cost to the user in doing this automatically.

The case is as I said - clearer architecture, and less likely to make mistakes writing programs to interact with them. As security developers, we are trying to improve best practises. In the future, it should be easy to put your master key offline. So it is better to prepare for that situation now, instead of asking everyone to generate a new key and refresh everyone else's key when the time comes.

>> 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."
> 

Be careful what you wish for. http://lkml.iu.edu//hypermail/linux/kernel/0210.1/1834.html

X

-- 
GPG: 4096R/1318EFAC5FBBDBCE
git://github.com/infinity0/pubkeys.git

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20140923/93724c28/attachment.sig>