[Feature Request] Multiple level subkey

[lesto fante]

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 <leo at 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…)
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20170910/1795e97c/attachment.html>