I am a bit confused by your "C key" terminology, i assume you are referring to what i call "master key", or level 2 key, that now I want to call SIGN KEY.
Lets all agree on the terminology please. I propose this: level 1: IDENTITY key - keep super safe. Paranoid level safe. level 2: SIGN key - keep password protected on you main devices. Normal user level safe level 3: APPLICATION KEY - can be clear and shared between multiple device. Quite unsafe, but convenient; completely transparent login! And still way safer than the classic "cookie to remember my login" approach Also i don't know what rfc4880bis ML is? is that some proposal somehow similar? Back to your email: You totally get it right! Make the system CONVENIENT, keep your masterkey under you bed and forget about it. if you use that system on you bank, the bank does NOT care what "application key" (well, read later) you are using, as long as it is not revoked, as it is all the same identity. We SHOULD think a way to integrate some permission in the key itself, like the name of the service it is supposed to be used; if someone stole a APPLICATION key can't use it to login to a different service. So we can imagine a situation where you create a APPLICATION key with permission to you use your bank account for up to 50€/week (of course, the limit for key is something implemented by the bank), and then give this key to you smart-fridge. Your fridge will not be able to sniff your facebook account, read your email or drain your ban account; and if something goes wrong, you KNOW what device is compromised. This could be as simple as the service giving you a ID to add somewhere IN the key, similar to how name and email can be set for a certificate right now. A bit more complex would be to avoid duplicate ID. This permission thing could be also extended to SIGN KEY, eventually, but then I think could be just complexity without really added benefit, as in my idea normally there is only one master key. But that can be changed, just i have no idea of the categories to create. This make SUPER convenient to revoke one or all you SIGN KEY and/or APPLICATION KEY without need for ANY other change; the reissuing process for the new key can be totally automated. Again I'm NOT taking into consideration how you share APPLICATION and SIGN key between your devices, that is a problem for another day discussion (would be extremely nice to have a standard way for any DEVICE to request a application key with SUGGESTED permission to the main device, but we have already too much on the fire right now) What we NEED is a clear standard to publish public key and revoke, and we could simply use the existing key server. Think about a company, with is own key server that identify its worker, customer and such; you use you smartphone to clock-in and out your work, to start your (encrypted) work computer, sign and, encrypt and decrypt message, and be a step safer from scammer and social engineering. Another advantage, is that you could generate and use one application key "on the spot" with your smartphone/pc, for example to sign a contract, without exposing your identity key. Your sign key and all its application key are exposed, but changing them is pretty easy, just revoke it and issue a new one. Now, compromising your IDENTITY would be a pain; or you signed a second identity some reasonable time before the revoke, or you have some sort of CA that issue it and link it to the previous identity. Otherwise you simply lose it all. I think the system is not really complex, im just bad to explain it :) On Sun, Sep 10, 2017, 17:28 Leo Gaspard <l...@gaspard.io> wrote: > On 09/10/2017 04:36 PM, Daniel Kahn Gillmor wrote:>> My user case is > simple; maintain my identity even if my master key is > >> compromised. Tho achieve that, I think about a multilevel subkey > >> system. > > > > I'm not sure how the proposed multi-level system is an improvement over > > an offline primary key. It's certainly more complicated, but complexity > > is a bug, not a feature. can you explain why you think it's better? > > > > with an offline primary key, you only put subkeys on any device that's > > used regularly. > > I can think of at least one use case it covers in addition to an offline > masterkey (but that would also be covered by C subkeys): the ability to > sign others’ keys without using your masterkey. This would allow to not > have to expose the keysigning device to untrusted data/software/hardware > that would carry the to-be-signed key. > > It would also make an offline masterkey much more convenient to use, > given one could just do like it never existed (even for keysigning), > except once the subkeys become compromised -- and at that time, the > recovery operation would be 1/ re-generate subkeys, 2/ re-sign all keys > you had signed with your previous C subkey. > > What do you think about this? (maybe I should just raise the issue on > rfc4880bis ML, but as the question arose here…) > >
_______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
