[Feature Request] Multiple level subkey

[lesto fante]

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

yes i did with all of my email. I *should* have reply to all by
default, but seems not the case.

>I still don't get why you would want amazon and your bank to see the
same identity key

Mainly to be able to replace ANY other key in a completely automated
fashion, starting by having ONLY the identity key. Imagine to lose the
device with the SIGN and many or all APPLICATION key; you will have to
revoke the master key, but only using the IDENTITY key. Oh, and then
issue a new SIGN key, that will issue new APPLICATION key (that your
wallet will distribute to the devices that require them, but again,
that is not part of gpg)

>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

this seems to me to be at risk of re-usability, or it is a one-time
token, then if you want something that buy biscuit for you, like a
"dash button", he need to have your amazon AND bank key.. and you
DON'T want to give the bank key to the dash button.


>I think I no longer get what you call masterkey.

this is why I didn't use anywhere this term, and i clearly stated my
terminology :)

>That is to mean you can already have a signing subkey per device if you want to

I'm outside for a late party, someone show me the new cool app with
gpg AND market support, and want to show me, so he ask me to join so
we can be friend and check our signature.
case 1: Oh, too bad, i don't have my smartcard with me. I never have
it with me when i need it!
case 2: Oh, too bad, i lost my smartcard somewhere on the dancefloor.
Why did i even take it with me?! Now i have to MANUALLY give a new key
to ALL MY SERVICE AND PEOPLE.
case 3: you use your public and private key with the app, that is just
a scam, and as your private key is also connected to you facebook and
bank, the app will shap itself on FB and then clean your bank account.
Yes, you can still charge back the transaction, but until the bank
does not approve it, you have no money. Its not a nice situation.

with this system:
you issue a new key for the service. As it is connected with your
identity, it will automatically be recognized by your bank as soon as
it get uploaded to the key server. The key get automatically.. 10€? so
you can but the nice premium-feature, and even if it was scam,
charging back is still an option.


2017-09-10 20:27 GMT+02:00 Leo Gaspard <leo at gaspard.io>:
> (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).