[Feature Request] Multiple level subkey

[lesto fante]

(THIS IS THE FULL MAIL I FORGOT TO CC, for future reference)

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

yes, we can change it, but i think this is pretty understandable.


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

oh, OK, now I get it, I know those stuff :)

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

What im doing here is not create a super wall around my key killing
usability, but instead making the *inevitable* easier to fix.

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

never said to use something else, actually I said "[...] we could
simply use the existing key server [...]"

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

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.

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

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

This is a killer feature, in my opinion.


>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

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