[Feature Request] Multiple level subkey

[Leo Gaspard]

On 09/10/2017 06:36 PM, lesto fante wrote:
> 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.

Oh yes sorry, I forgot to explain my terminology.

> 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

This is the terminology that would be used under your proposal, do I
understand correctly?

What I called C subkeys is based on the terminology for the three major
operations possible with keys under OpenPGP: Certify, Sign and Encrypt
(I seem to remember Authenticate also exists, although I never used it
myself).

Certify usually means “assert something about the owner of some other
key,” Sign means “assert I have written this content,” and Encrypt means
“make this content only accessible by someone.”

OpenPGP already has Sign and Encrypt (S and E) subkeys, but currently,
as far as I can remember, Certify (C) subkeys are hardly supported.

> Also i don't know what rfc4880bis ML is? is that some proposal somehow
> similar?

RFC4880bis ML is the place where the evolutions to RFC4880 (the RFC
describing OpenPGP) are usually discussed, although here is as good a
place as there for a first draft.

The “C subkeys” proposal would be to allow people to have a subkey with
the Certification capability (that is, allowed to perform this operation
on behalf of the masterkey).

Then, the proposal is close to what you proposed, except there is no
hierarchy of keys: you just have a masterkey, and S, E and C subkeys
directly signed by the masterkey. All these subkeys, when put together,
have all the power the masterkey has -- except the masterkey can revoke
them and issue new ones.

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

I fear you are going a bit too far in the future. Besides, there is no
need to give the same masterkey to your bank and your smart fridge, as
they will (likely?) not participate in the Web of Trust anyway.

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

Hmmm... The keyservers also exist and work quite well for public key
publishing and revocation, so I don't get why we would need something
else? It's the de-facto standard.

Then, the company should not run a keyserver, but just sign the keys of
all workers, and check the signature is valid and not revoked on use.

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

Do you mean not exposing your public identity key or your private
identity key?

If you mean public identity key, then how is the other side of the
contract supposed to ensure you are actually signing as yourself and not
as someone else?

If you mean private identity key, then there is already no need to
expose any private part of any key when signing, as everything happens
on your device and public-key cryptography ensures this property.

> 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 :)

I think I sort of get what you are doing, but don't really get the
advantage compared to things already possible with OpenPGP (with C
subkeys), that is:

Master keypair
 |- Signature keypair (or many such, all revocable)
 |- Encryption keypair (or many such, all revocable)
 `- Certification keypair (or many such, all revocable)

Cheers,
Leo