[Feature Request] Multiple level subkey

[Leo Gaspard]

(you forgot to Cc: the list, I'm Cc-ing back as it doesn't seem
voluntary to me)

On 09/10/2017 07:50 PM, lesto fante wrote:
>> 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
> 
> not the same masterkey, but the same identity. Very important for
> changing the key transparently.

By “masterkey” I meant “most privileged key” (that is what you call
“identity key”). I'll try to use your terminology henceforth.

> You are right, I don't need the same identity for the fridge and the
> bank.. until I want the fridge to buy the milk.
> Or, for a more realistic example, i want my bank key and amazon key to
> be different, but to point to the same identity.. make more sense now?
> Yes, i could do it with the current master key and sub-key, but with
> the lack of a "master-master" key, a compromised master key would be a
> hassle to manage (that remember, is on the user device.. probably the
> smartphone. not exactly the safest device, and something quite easy to
> lose or get stolen).

I still don't get why you would want amazon and your bank to see the
same identity key. The only point of an identity key is to accumulate
signatures from the WoT, here there is no need of WoT and you could just
say amazon to connect you with one key and to pay with [some private key
you gave the corresponding public key to your bank].

>> 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.
> 
> if you sign the identity of the worker, how do you revoke your sign?

With OpenPGP's revocation signature, that GnuPG gives an “easy”
interface for?

> AFAIK you should create a certificate for each worker and then sign
> it, and use that certificate to sign the worker identity, so you can
> revoke the worker certificate. That, to me, seems a bit more complex,
> but on the bright side can be implemented right now.

No, currently you'd just sign the worker's masterkey with the company's
masterkey, and when the worker no longer works here you'd revoke the
previous signature.

> A company may want to run their own server maybe because they don't
> want to expose all the certificate for all their worker. To me make a
> lot of sense, especially for sector like security or social care.

Indeed they may want to, but it is not (or maybe “should not”?) be a
critical piece of the infrastructure: current keyserver software is most
likely not as secure as the cryptography underlying signatures is.

>> Do you mean not exposing your public identity key or your private
> identity key?
> 
> private identity key. Your public identity is well known, the private
> key should be the most safe thing you have. Losing it is like losing
> your documents.
> Well, actually my end goal is to REPLACE documents (like passport)
> with this system. This also help you to understand why is so important
> to protect the identity, but still have a way to be able to issue it
> to minor services for everyday usage.

Well, you should never expose your private identity key to anyone, or
any other private key linked to you for that matter.

To take back your example with amazon and your bank, there is absolutely
no need that the private key you give amazon is linked to your identity,
it just need correspond to the public key you gave your bank. You could
even not use public-key crypto, and only give the same 128-bit token to
both sides, and it should be enough (though your bank may insist on
public-key cryptography so that they can have a proof that such key
issued such payment order).

If you don't want to access your bank's website, you could just give a
128-bit token signed with your signing key or whatever to amazon
(disclaimer: I'm writing this without thinking about all the security
implications right now, just throwing an idea out in the air).

>> If you mean private identity key, then there is already no need to
> expose any private part of any key when signing
> 
> you dont expose it *mathematically*, bu you expose it to the outside
> world, where you can lose it, got it stolen.. and then all your
> identity and related is compromised, and you have no easy or automated
> way to get back the ownership.
> Losing the SIGN key is scary, but as soon as you get home (or you
> alert your "trust" person, that just have the revoke key for the SIGN
> key, so it does not need to be *that* trusty), you will have your
> master key revoked, and as soon as you create a new SIGN key, you will
> *automatically* regain access to all services.

I think I no longer get what you call masterkey.

>> 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:
> 
> this is interesting,  i cant find much on how certification key work;
> but if they can be used to create and revoke other key in the behalf
> of the master key, then seems to be exactly what I'm looking for. I
> just can't find anything, and I guess i'll have to find it on the RFC

It doesn't allow to create other keys on behalf of the masterkey (or at
least that's not how I'm seeing it to work).

It just allows to delegate some more power from the masterkey to the
subkeys.

Currently, you can delegate signing and encryption powers from masterkey
to subkeys. The only operation missing, from what I can tell, is
Certification, that is signing someone else's masterkey to strengthen
the WoT.

That is to mean you can already have a signing subkey per device if you
want to (encryption is a bit harder, but out of the scope of this
discussion if I understood where you're going).