Re: [Feature Request] Multiple level subkey

[lesto fante]

>And to be more precise, in the situation where the level-2 key is compromised, 
>you actually do not revoke the level-2 key itself (using the corresponding 
>level-2 private key), you revoke the trust signature on the level-2 key (using 
>the level-1 private key). The level-2 will then cease to be valid in the eyes 
>of your correspondents.

this is perfect, it also mean that revoking level2 i would also
invalidate all its subkeys. I will look into it.


>So you want to bring privacy to the housewife while at the same time make her 
>rely on someone else (the "son/trust person" you mentioned) to manage her 
>privacy? But is it still privacy then?

the idea is that the system is very simple for the end user, as of
now, you really have to KNOW exactly what you are doing, and if you
get something wrong you compromise your whole security; this scare
away all this less-than-perfect user (such as myself), the more the
system is error-resistant, the more likely they jump in, and do
themselves.
In reality the great improvement is more on the user interface side,
but i need to understand what i can do on the lower level, and build
up around it.
A housewife that need help to set this up (aka, install the software,
connect the hw wallet and press one button and add a password), is one
that need help to set up his homebank, email and socials; she would
use the same user/password for all the services, with the password
probably "password" or something else in the list of the 100 most used
password. So she is not really loosing any privacy over this; actually
we are making the system safer even for her.


2017-09-11 0:01 GMT+02:00 Damien Goutte-Gattat :
> On 09/10/2017 11:32 PM, lesto fante wrote:
>>
>> just to be sure I don't misunderstand, the level 2 key cannot revoke
>> the level 1 key, right?
>
>
> No it cannot.
>
> And to be more precise, in the situation where the level-2 key is
> compromised, you actually do not revoke the level-2 key itself (using the
> corresponding level-2 private key), you revoke the trust signature on the
> level-2 key (using the level-1 private key). The level-2 will then cease to
> be valid in the eyes of your correspondents.
>
>
>> My goal is to bring good privacy at the housewife, while making the
>> process even more easier (as it will be as easy as using a wallet).
>
>
> So you want to bring privacy to the housewife while at the same time make
> her rely on someone else (the "son/trust person" you mentioned) to manage
> her privacy? But is it still privacy then?
>
> If I had to trust someone else with my privacy, I think I would rather trust
> the faceless algorithms running in a Google datacenter than a person close
> to me and who keep telling me "don't worry, I'm taking care of everything,
> just relax."
>
> (If you think that your son or your "trust person" cannot betray you, well,
> by definition you can be betrayed *only* by someone you trust.)
>
> GnuPG (and free software in general) should empower users to take privacy in
> their own hands, not incite then to rely on a "trust person".
>
> That's only my opinion, of course.
>
> Damien
>

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: [Feature Request] Multiple level subkey

[Damien Goutte-Gattat]

On 09/10/2017 11:32 PM, lesto fante wrote:

just to be sure I don't misunderstand, the level 2 key cannot revoke
the level 1 key, right?


No it cannot.

And to be more precise, in the situation where the level-2 key is 
compromised, you actually do not revoke the level-2 key itself (using 
the corresponding level-2 private key), you revoke the trust signature 
on the level-2 key (using the level-1 private key). The level-2 will 
then cease to be valid in the eyes of your correspondents.




My goal is to bring good privacy at the housewife, while making the
process even more easier (as it will be as easy as using a wallet).


So you want to bring privacy to the housewife while at the same time 
make her rely on someone else (the "son/trust person" you mentioned) to 
manage her privacy? But is it still privacy then?


If I had to trust someone else with my privacy, I think I would rather 
trust the faceless algorithms running in a Google datacenter than a 
person close to me and who keep telling me "don't worry, I'm taking care 
of everything, just relax."


(If you think that your son or your "trust person" cannot betray you, 
well, by definition you can be betrayed *only* by someone you trust.)


GnuPG (and free software in general) should empower users to take 
privacy in their own hands, not incite then to rely on a "trust person".


That's only my opinion, of course.

Damien



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: [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 :
> (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 

Re: [Feature Request] Multiple level subkey

[lesto fante]

>You revoke the level-2 key, that will be enough to invalidate the signature on 
>the level-3 key.

>I merely pointed out what is already feasible with the current state of the 
>OpenPGP specification and the GnuPG implementation.

you are right, after all if it is there, it can be automated. The real
question is, would this break/interfere with something else?
Your solution is quite different from the other and i need more time
to evaluate it, but this is exactly why I'm there.

>Assuming the level-1 key is not on that device, then no.

just to be sure I don't misunderstand, the level 2 key cannot revoke
the level 1 key, right?

>I do not really care for this "user is an idiot, we cannot trust him/her to do 
>the right thing so we should do it for him/her" approach.

i do. EVERYBODY is an idiot, someone is idiot every day, someone after
10h of works, someone only when all the planets are aligned. But it
WILL happen to the majority of the population, even the best: and the
best cure is the prevention.

My goal is to bring good privacy at the housewife, while making the
process even more easier (as it will be as easy as using a wallet).

2017-09-10 21:50 GMT+02:00 Damien Goutte-Gattat :
> On 09/10/2017 09:17 PM, lesto fante wrote:
>>>
>>> If your level-3 key is compromised, you revoke it, generate a new one and
>>> sign it with the level-2 key. The new level-3 key will be automatically
>>> valid for your correspondents.
>>
>>
>> what if i lose the level-2 key too? imagine level-2 and level-3 key
>> are both on my phone, with NO other copy of the level-2 and level-3
>> private key.
>> Can i revoke all of them?
>
>
> You revoke the level-2 key, that will be enough to invalidate the signature
> on the level-3 key.
>
>
>> If my device is in the hand of a bad person, will he be able to
>> compromise my level-1 key
>
>
> Assuming the level-1 key is not on that device, then no.
>
>
>> Also i understand the key-level truthiness, but here i want to
>> AUTOMATE, make this thing MORE EASY to use than a common password
>> approach.
>
>
> I merely pointed out what is already feasible with the current state of the
> OpenPGP specification and the GnuPG implementation.
>
>
>> This approach MUST be "housewife proof"; her son/truth person will set
>> up the sign key for her and then just tell her to keep the smartcard
>> in a safe place. Then to choose a safe password for the SIGN key. That
>> is the only password out housewife need, unless she will loose or get
>> a compromised phone; at this point, she will call the trust person
>> that will take care revoke, and then issuing a new SIGN key on her new
>> phone. No need to go and reset ALL of her account and such; all the
>> key she had has been already replaced :)
>
>
> I do not really care for this "user is an idiot, we cannot trust him/her to
> do the right thing so we should do it for him/her" approach.
>
> Damien
>

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: [Feature Request] Multiple level subkey

[lesto fante]

>If your level-3 key is compromised, you revoke it, generate a new one and sign 
>it with the level-2 key. The new level-3 key will be automatically valid for 
>your correspondents.

what if i lose the level-2 key too? imagine level-2 and level-3 key
are both on my phone, with NO other copy of the level-2 and level-3
private key.
Can i revoke all of them?
If my device is in the hand of a bad person, will he be able to
compromise my level-1 key meanwhile I get in contact with someone that
can revoke the level-2 key (and so all of its subkey)?

Also i understand the key-level truthiness, but here i want to
AUTOMATE, make this thing MORE EASY to use than a common password
approach.
This approach MUST be "housewife proof"; her son/truth person will set
up the sign key for her and then just tell her to keep the smartcard
in a safe place. Then to choose a safe password for the SIGN key. That
is the only password out housewife need, unless she will loose or get
a compromised phone; at this point, she will call the trust person
that will take care revoke, and then issuing a new SIGN key on her new
phone. No need to go and reset ALL of her account and such; all the
key she had has been already replaced :)


2017-09-10 20:39 GMT+02:00 Damien Goutte-Gattat :
> On 09/10/2017 08:30 PM, lesto fante wrote:
>>>
>>> If your level-1 key is compromised, you revoke it, generate a new one and
>>> sign it with the level-2 key. The new level-1 key will be automatically
>>> valid for your correspondents.
>>>
>>> If your level-2 key is compromised, you revoke it, generate a new one,
>>> tsign it with the level-1 key
>>
>>
>> this is exactly what i DON'T want. The level 2 key (or level 1, it
>> seems you mixed them up)
>
>
> Sorry, I did mix level-1 and level-3 keys in the first sentence you're
> quoting. What I meant was:
>
> If your level-3 key is compromised, you revoke it, generate a new one and
> sign it with the level-2 key. The new level-3 key will be automatically
> valid for your correspondents.
>

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: [Feature Request] Multiple level subkey

[Damien Goutte-Gattat]

On 09/10/2017 09:17 PM, lesto fante wrote:

If your level-3 key is compromised, you revoke it, generate a new one and sign 
it with the level-2 key. The new level-3 key will be automatically valid for 
your correspondents.


what if i lose the level-2 key too? imagine level-2 and level-3 key
are both on my phone, with NO other copy of the level-2 and level-3
private key.
Can i revoke all of them?


You revoke the level-2 key, that will be enough to invalidate the 
signature on the level-3 key.




If my device is in the hand of a bad person, will he be able to
compromise my level-1 key


Assuming the level-1 key is not on that device, then no.



Also i understand the key-level truthiness, but here i want to
AUTOMATE, make this thing MORE EASY to use than a common password
approach.


I merely pointed out what is already feasible with the current state of 
the OpenPGP specification and the GnuPG implementation.




This approach MUST be "housewife proof"; her son/truth person will set
up the sign key for her and then just tell her to keep the smartcard
in a safe place. Then to choose a safe password for the SIGN key. That
is the only password out housewife need, unless she will loose or get
a compromised phone; at this point, she will call the trust person
that will take care revoke, and then issuing a new SIGN key on her new
phone. No need to go and reset ALL of her account and such; all the
key she had has been already replaced :)


I do not really care for this "user is an idiot, we cannot trust him/her 
to do the right thing so we should do it for him/her" approach.


Damien



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: [Feature Request] Multiple level subkey

[lesto fante]

(sent again because i forgot to add the mailing list in CC, sorry)

>If your level-1 key is compromised, you revoke it, generate a new one and sign 
>it with the level-2 key. The new level-1 key will be automatically valid for 
>your correspondents.
>
>If your level-2 key is compromised, you revoke it, generate a new one, tsign 
>it with the level-1 key

this is exactly what i DON'T want. The level 2 key (or level 1, it
seems you mixed them up) is way less safe than the level 1, as the
level 1 is on your smart-card, in a safe place, and the level 2 is in
your PC, on your smartphone, and you basically carry it with you every
time, as you want to be able to access new services without the hassle
of having the smart-card with you.

With all the security problem connected to having the smart-card with
you; I assume keeping in in your house, or even in a security box, is
way more safe.

So again: trust goes in one direction only, the same direction of
security. Level 1 > Level 2 > Level 3

>Slightly off-topic, but using a NFC-enabled token might be an easier way to 
>deal with that particular concern.

I have one of them.
Result:
 * I do not carry them with me, I'm to scared to lose it
 * The card does not have NFC
 * I don't have NFC on my emergency smartphone, so i need to also
carry the cable and hope the phone can handle it (driver + OTG usb)
 * If my smartphone/pc is compromised, when i connect the NFC they can
do whatever they want, even sign THEIR key and revoke mine. With my
system the level 2 key get revoked, and I know the device that have it
are compromised, so i will format/change them before issuing a new
level 2 key
 * I created some key on my pc and used them for a while for this
email, until the for an unfortunate accident i lost them and their
backup (remember to power up your USB key, they have an internal
battery that need to be recharged sometimes, should be 10 years...
should); if they would have somehow signed by my HW wallet (witch i
assume NOT having the same power-related issue), i could have issued a
new one, and uploaded them on the key server. Instead now i can't even
revoke them.

There are more, if i sit there and think about all frustration i had
to manage my keys, and for sure there is a lot to do in the wallet
side too.

2017-09-10 19:47 GMT+02:00 Damien Goutte-Gattat :
> Hello,
>
> On 09/09/2017 12:50 AM, lesto fante wrote:
>>
>> Tho achieve that, I think about a multilevel subkey system.
>
>
> The OpenPGP specification already has some support for a hierarchical
> system, in the form of "trust signatures".
>
> (Hereafter, I will use "trust-sign" as a verb to refer to the act of
> emitting a trust signature.)
>
> For a 3-levels hierarchy as you describe, you could do the following:
>
> a) You sign your level-3 key(s) with your level-2 key;
>
> b) You trust-sign your level-2 key with your level-1 key, with a trust depth
> of 1.
>
> c) Your correspondents trust-sign your level-1 key, with a trust depth of 2.
>
> If your level-1 key is compromised, you revoke it, generate a new one and
> sign it with the level-2 key. The new level-1 key will be automatically
> valid for your correspondents.
>
> If your level-2 key is compromised, you revoke it, generate a new one, tsign
> it with the level-1 key, and use it to re-sign your level-1 key (although if
> the level-2 key is compromised, you may want to assume that the level-1 key
> is compromised as well, and generate a new one). Again, the new level-2 key
> will be valid and trusted by your correspondents, since it bears a trust
> signature from the level-1 key.
>
> The problem you may have with this method is that it depends on your
> correspondents *trust-signing* your level-1 key. If they use a normal
> signature instead (or a trust signature with a trust depth < 2), no
> ownertrust will be assigned to the level-2 key and therefore the level-3 key
> will not be considered valid. So you have to tell your correspondents to
> *trust-sign* your level-1 key, but you cannot force them to do so.
>
> This is kind of a design feature of OpenPGP, by the way: the user is always
> free to choose whom he wants to trust, and to what extent. This is by
> contrast with the X.509 world, where the fact that a certificate can only be
> signed by *one* authority gave rise to an ecosystem of CAs that are
> "too-big-to-fail" (or "too-big-to-choose-not-to-trust").
>
>
>> Now the nice thing: i guess most of the people will use their phone
>> to keep the level 2 key, but we know those are not the most secure
>> stuff, especially when get old or wit some producer allergic to
>> patch.
>
>
> Slightly off-topic, but using a NFC-enabled token might be an easier way to
> deal with that particular concern. I know of at least two such tokens: the
> Yubikey NEO [1] and the Fidesmo Privacy Card [2].
>
>
> Damien
>
> [1] https://www.yubico.com/products/yubikey-hardware/yubikey-neo/
>
> [2] http://shop.fidesmo.com/product/fidesmo-privacy
>

Re: [Feature Request] Multiple level subkey

[lesto fante]

can you please explain what are C subkey?

unfortunately a search with those terms does not return nothing
relevant, a direct link to some docs would be nice.

Also i took a look at rfc4880bis but again i can't see how is related
to C key or this argument at all.

(sent again as sent only to andrew instead of all user list, sorry!)

2017-09-10 18:34 GMT+02:00 Andrew Gallagher :
>
>> On 10 Sep 2017, at 16:28, Leo Gaspard  wrote:
>>
>> 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.
>
> I think C subkeys are a *much* simpler solution for that use case. Better to 
> treat this scenario as "solved in principle" and put it aside for the time 
> being.
>
> A

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: [Feature Request] Multiple level subkey

[Damien Goutte-Gattat]

On 09/10/2017 08:30 PM, lesto fante wrote:

If your level-1 key is compromised, you revoke it, generate a new one and sign 
it with the level-2 key. The new level-1 key will be automatically valid for 
your correspondents.

If your level-2 key is compromised, you revoke it, generate a new one, tsign it 
with the level-1 key


this is exactly what i DON'T want. The level 2 key (or level 1, it
seems you mixed them up)


Sorry, I did mix level-1 and level-3 keys in the first sentence you're 
quoting. What I meant was:


If your level-3 key is compromised, you revoke it, generate a new one 
and sign it with the level-2 key. The new level-3 key will be 
automatically valid for your correspondents.




signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: [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 

Re: [Feature Request] Multiple level subkey

[Damien Goutte-Gattat]

Hello,

On 09/09/2017 12:50 AM, lesto fante wrote:

Tho achieve that, I think about a multilevel subkey system.


The OpenPGP specification already has some support for a hierarchical 
system, in the form of "trust signatures".


(Hereafter, I will use "trust-sign" as a verb to refer to the act of 
emitting a trust signature.)


For a 3-levels hierarchy as you describe, you could do the following:

a) You sign your level-3 key(s) with your level-2 key;

b) You trust-sign your level-2 key with your level-1 key, with a trust 
depth of 1.


c) Your correspondents trust-sign your level-1 key, with a trust depth of 2.

If your level-1 key is compromised, you revoke it, generate a new one 
and sign it with the level-2 key. The new level-1 key will be 
automatically valid for your correspondents.


If your level-2 key is compromised, you revoke it, generate a new one, 
tsign it with the level-1 key, and use it to re-sign your level-1 key 
(although if the level-2 key is compromised, you may want to assume that 
the level-1 key is compromised as well, and generate a new one). Again, 
the new level-2 key will be valid and trusted by your correspondents, 
since it bears a trust signature from the level-1 key.


The problem you may have with this method is that it depends on your 
correspondents *trust-signing* your level-1 key. If they use a normal 
signature instead (or a trust signature with a trust depth < 2), no 
ownertrust will be assigned to the level-2 key and therefore the level-3 
key will not be considered valid. So you have to tell your 
correspondents to *trust-sign* your level-1 key, but you cannot force 
them to do so.


This is kind of a design feature of OpenPGP, by the way: the user is 
always free to choose whom he wants to trust, and to what extent. This 
is by contrast with the X.509 world, where the fact that a certificate 
can only be signed by *one* authority gave rise to an ecosystem of CAs 
that are "too-big-to-fail" (or "too-big-to-choose-not-to-trust").




Now the nice thing: i guess most of the people will use their phone
to keep the level 2 key, but we know those are not the most secure
stuff, especially when get old or wit some producer allergic to
patch.


Slightly off-topic, but using a NFC-enabled token might be an easier way 
to deal with that particular concern. I know of at least two such 
tokens: the Yubikey NEO [1] and the Fidesmo Privacy Card [2].



Damien

[1] https://www.yubico.com/products/yubikey-hardware/yubikey-neo/

[2] http://shop.fidesmo.com/product/fidesmo-privacy



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: [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 

Re: [Feature Request] Multiple level subkey

[lesto fante]

Thanks!

I though a bit more and I have now a bit more clear ideas.

I want a "identity" key; this is the most important key and should be
super-secure, like a hw wallet/card. In the best case scenario it is used
to issue a master key, and never used again.

Then we have one (or more) master key; those are used to issue and revoke
subkey (application key). Those will be a bit less secure, as they will
stay on one or more user device regularly in use (I plan to use the
smartphone as central key storage and manager).

Then the application are what are used by the application. Notice they all
refer to the main identity; changing one of the key does not require
nothing else than revoke the old key and issue a new one.
The idea is to make the use and generation of subkey transparent and not
requiring the super-secure identity key; the master key is used, and if
compromised the super-secure identity key will revoke the master key and
issue a new one. Then automatically (depending on settings, but bear with
me) opening any application will trigger the recreation of a subkey
dedicated; as they are still rapresenting the same identity, no question is
asked by the service, as recognize the user.


The p2p system would be a nice way to share PUBLIC key and REVOKE between
peers.

Now, I have been pointed out that the sanity card in EU (for non EU; all EU
has the same sanity card.. So you can travel and not have to worry) come
with a certificate inside!

We could use that certificate, to sign a second certificate that sing our
master key. The second certificate is needed because that way we can revoke
it without having to revoke the identity (which could be difficult to
explain to your authority, even if you could "loose" the card, and then a
new certificate *should* be issued, but I don't know how it work. Also
seems the CA are regional, so there are multiple server for country)


My final goal is to have a secure key in case of big issue, and a series of
less secure key to make using them seminless, actually even more easy than
using a password or a password wallet!


On Sun, Sep 10, 2017, 17:03 Daniel Kahn Gillmor 
wrote:

> On Sat 2017-09-09 00:50:56 +0200, lesto fante wrote:
>
> > Maybe this is not the right place to discuss about this, please be
> > kind with a noob.
>
> this is the right place, welcome!
>
> > 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.
>
> That said, even offline primary keys aren't super easy-to-use at the
> moment, more work could be done to streamline that use case.
>
> > ps. is anyone aware of some kind P2P system to share keys?
>
> are you asking about secret key sharing (between devices controlled by
> the same person) or public key distribution?
>
> --dkg
>
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: [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  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 

Re: [Feature Request] Multiple level subkey

[Andrew Gallagher]

> On 10 Sep 2017, at 16:28, Leo Gaspard  wrote:
> 
> 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.

I think C subkeys are a *much* simpler solution for that use case. Better to 
treat this scenario as "solved in principle" and put it aside for the time 
being. 

A

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: [Feature Request] Multiple level subkey

[Leo Gaspard]

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



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Unable to sign or decrypt with card

[Werner Koch]

On Sat,  9 Sep 2017 14:54, philip.jack...@nordnet.fr said:

> Suggestions as to how to check and correct this situation would be
> appreciated.

Newer versions of gpg should print a better error message; at least with
-v.  I guess that your pinentry is not installed or can't be used.

Do you have the option "pinentry-program" in your gpg-agent.conf ?  Then
check that it is really there.

Is the environment variable GPG_TTY set as describen in the manual?

Do you get a prompt when calling "pinentry"?  If so, does it show up a
window after entering "getpin"?

More information about gpg-agent an pinentry interaction can be seen by
putting

--8<---cut here---start->8---
log-file /somewhere/gpg-agent.log
verbose
debug ipc
debug-pinentry
--8<---cut here---end--->8---

into gpg-agent.conf and restarting gpg-agent ("pkill gpg-agent" or
"gpgconf --kill gpg-agent").


Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


pgpUA6YozyS7t.pgp
Description: PGP signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users