Re: [Feature Request] Multiple level subkey

[lesto fante]

ok, just to clarify;

my original question boils down to be able to generate Sign key using a
subkey.

I guess there should be an arbitrary hard limit on the number of sub-subkey,

Aside from this, the validation algorithm should be made recursive, up to
the hard limit.

Would be possible to use the GnuPG code to create a fork, and add this kind
of behaviur?

2017-09-09 0:50 GMT+02:00 lesto fante :
> Hello,
>
> Maybe this is not the right place to discuss about this, please be
> kind with a noob.
>
> 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.
> Please i would love to hear any alternative.
> For the discussion purpose, we don't talk about HOW revoke and public
> key are exchanged between peers; it could be with existing key server,
> or other way.
>
> I would like to set up a system relatively secure, but with no hassle
> for everyday use.
>
> The idea is the following:
> A level 1 key, kept very safe (hw or paper wallet wallet). This key
> represent the identity is hopefully used only once to generate one
> subkey "level 2".
>
> The subkey level 2 is saved on one (or more, but trusted) main device.
> This key will be used to generate its own subkey (level 3), those
> subkey are used for various application and distributed between device
> using relatively unsafe method; losing, revoking or issuing a new key
> for a new application should be easy and transparent for the user.
>
> the idea is that the level 2 key is used for most of the normal
> operation, even in case one or more level 3 key are compromised;
> please remember that all they key just represent the identity of the
> level 1 key.
>
> This is very similar to the chain of trust with certificate.
>
> 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.
>
> In the unlucky case the level 2 key get compromised, the user can use
> the level 1 key to:
> 1. revoke the level 2 key. This of course will automatically revoke
> the level 3 key that are direct subkey of that level 2 key.
>
> 2. issue a new level 2 key. At this point the main device will issue
> new level 3 key to replace all the key revoked in the step above.
>
> please note a user could have multiple level 2 key active; this could
> be for different reason, like updating to different algorithm still
> not fully supported.
>
> Lesto
>
> ps. is anyone aware of some kind P2P system to share keys?
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: [Feature Request] Multiple level subkey

[Robert J. Hansen]

> While I have nothing against (rapid) prototyping in general, it is not
> the advisable method for each and every project or person.

Enthusiastically agreed.

> This, of course, should best be discussed elsewhere. ;-)

This, as well.  :)

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

Re: [Feature Request] Multiple level subkey

[Ralph Seichter]

On 15.09.2017 10:52, Robert J. Hansen wrote:

> Often, the best way to begin learning how to do something is to go out
> and do it.

While I have nothing against (rapid) prototyping in general, it is not
the advisable method for each and every project or person. I prefer
spending time designing software, with pencil and paper or what have
you, before writing the first lines of code. That helps with figuring
out what one is trying to achieve, and the basics of how to achieve it,
lowering the risk of getting bogged down in issues of design oversight
or of the chosen programming language.

This, of course, should best be discussed elsewhere. ;-)

-Ralph

___
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 understand what you say, but for now I'm still thinking if use a
certificate for lvl1 or a key.. For sure in the next days I want to produce
a basic schematic of the system, protocol, expected workflow..
I already attempted something but so far I always changed idea halfway
thought.

On Fri, Sep 15, 2017, 10:52 Robert J. Hansen  wrote:

> >> now's the time to go off and start committing code.
> >
> > hope you are kidding.. I'm not even finished to collect all the
> > information and ideas, then i need to crunch them up, come out with a
> > protocol schema, check with whatever is interested if sound..
>
> Nope.  Not kidding.
>
> The first version of your product will be awful.  That's to be expected.
>  Look into PGP 1.0 sometime: it was so terrible PRZ had to basically
> burn it down and start over.  And, you know, *that's okay*.
>
> Often, the best way to begin learning how to do something is to go out
> and do it.  Linus Torvalds was a mediocre C programmer who barely
> understood Minix when he first started working on Linux.  PRZ's initial
> PGP 1.0 was a joke.  Pretty much every successful software project you
> see today started from a bungled beginning, but the people working on
> the project learned from their mistakes and slowly things became very,
> very good.
>
> The best way to discover what problems you'll have to solve is to go out
> and encounter them.  Once you do that, *then* build solutions.
>
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: [Feature Request] Multiple level subkey

[Robert J. Hansen]

>> now's the time to go off and start committing code.
> 
> hope you are kidding.. I'm not even finished to collect all the
> information and ideas, then i need to crunch them up, come out with a
> protocol schema, check with whatever is interested if sound..

Nope.  Not kidding.

The first version of your product will be awful.  That's to be expected.
 Look into PGP 1.0 sometime: it was so terrible PRZ had to basically
burn it down and start over.  And, you know, *that's okay*.

Often, the best way to begin learning how to do something is to go out
and do it.  Linus Torvalds was a mediocre C programmer who barely
understood Minix when he first started working on Linux.  PRZ's initial
PGP 1.0 was a joke.  Pretty much every successful software project you
see today started from a bungled beginning, but the people working on
the project learned from their mistakes and slowly things became very,
very good.

The best way to discover what problems you'll have to solve is to go out
and encounter them.  Once you do that, *then* build solutions.

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

Re: [Feature Request] Multiple level subkey

[lesto fante]

>You've already heard a lot of good advice from people here

I got a couple of ideas, but so far the only real information is that
I cant do with actual system in place. And one nice idea from a guy to
use level of thrust already implemented, but i'm not sure if i
understand all of its possible downside, I'm still waiting for an
answer.
You say that i can use 90% of crypto out there, and you are right, and
i WANT to avoid writing code as much as possible.


>now's the time to go off and start committing code.

hope you are kidding.. I'm not even finished to collect all the
information and ideas, then i need to crunch them up, come out with a
protocol schema, check with whatever is interested if sound.. if i
have to write even a alpha version of a protocol/rfc is going to be
HUGE. That is why ii insist to find alternative to avoid writing code,
especially on the "cryptography" side

IF the crypt was there, and all i needed to do was to add a bit of
glue code, then yes, maybe i would be already writing the code. I hope
that when and if i will get result, will be fine to share them there
to get some feedback




2017-09-14 23:58 GMT+02:00 Robert J. Hansen :
>> But even if you don't agree with my "vision", lets keep it technical;
>> what would be the best way to implement this system in your opinion?
>
> Create a GitHub repo and start committing code.
>
> What you want to do is not something that's within the scope of the
> OpenPGP RFC.  It's close, but it's not quite there.  If you do this,
> you'll have to go beyond the RFC.  So go off, start with a clean sheet
> of paper, design a system, and start hacking.  Probably 95% of the
> crypto code is already written for you.  All you need to do is design a
> protocol, implement it, and give it to the world.
>
> You've already heard a lot of good advice from people here.  Now's the
> time to go off and start committing code.
>

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

Re: [Feature Request] Multiple level subkey

[Robert J. Hansen]

> But even if you don't agree with my "vision", lets keep it technical;
> what would be the best way to implement this system in your opinion?

Create a GitHub repo and start committing code.

What you want to do is not something that's within the scope of the
OpenPGP RFC.  It's close, but it's not quite there.  If you do this,
you'll have to go beyond the RFC.  So go off, start with a clean sheet
of paper, design a system, and start hacking.  Probably 95% of the
crypto code is already written for you.  All you need to do is design a
protocol, implement it, and give it to the world.

You've already heard a lot of good advice from people here.  Now's the
time to go off and start committing code.


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

Re: [Feature Request] Multiple level subkey

[lesto fante]

> Just because they don't expose the dials and switches to you doesn't mean 
> they don't exist.

my goal instead is became as invisible as possible for the end user.he
should forget about my app running in the background, of course a
password sometimes when he add a new service, but that is all.

After this infrastructure is in place, you can decide to DIY every
single step and personalize whatever you want. The problem here is the
lack of potentiality.

But even if you don't agree with my "vision", lets keep it technical;
what would be the best way to implement this system in your opinion?

2017-09-14 4:57 GMT+02:00 Robert J. Hansen :
>>> Your "average internet user" is a 1940s-style way of thinking. We need to 
>>> do better than that.
>>
>> Then explain FB, google, youtube, amazon... all of them does NOT
>> provide a great deal of personalization, if at all.
>
> They all provide intensely personalized experiences.  Just because they
> don't expose the dials and switches to you doesn't mean they don't exist.
>
> As an example: Google Chrome scans the content of webpages you visit,
> and uses that to guide autocomplete in the search bar.  Your
> autocomplete settings are automatically personalized based on your
> browsing history with no user intervention needed.
>
> Automatic personalization of user experience based on the software
> learning the user's behavior is pretty much the gold standard in UX
> design nowadays.  It's a commendable goal and worth pursuing.

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

Re: [Feature Request] Multiple level subkey

[Peter Lebbing]

On 10/09/17 17:23, lesto fante wrote:
> 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!


On 14/09/17 00:20, lesto fante wrote:
> I also hope the same apply on the rest of the EU, since AFAIK that
> certificate is on the European Health Insurance Card.

Dutch person here; I had no idea what a European Health Insurance Card
is. All I have is a credit-card sized piece of plastic that mentions my
customer number at OHRA, the insurance company where I have my health
insurance. The piece of plastic has a black bar where the magstripe is
located, but I'd be very surprised if it's a magstripe. It's just inked
to look similar to one. (Never understood why they do that)

I've looked on the interwebs what a European Health Insurance Card is,
and yes, many Dutch people can request one free of charge. But given
that I have never heard of it before, I don't think many people do. And
there are insurance companies that don't give them out at all.

And even if you got one, the Dutch information about the card says its
validity period depends on your insurance company as well, ranging from
just the duration of your stay abroad up to maximally one year.

This does not sound like an obvious target for Dutch people who want a
government-issued certificate.

My 2 cents,

Peter.

PS: Yes, I do travel abroad. But I simply depend on my travel insurance
and a "medication passport", which is a document that includes all the
standardized names of medication I have to take, in case I lose them.
Oh, and my organ donor card for when it really goes wrong :-).

-- 
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at 



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

[Robert J. Hansen]

>> Your "average internet user" is a 1940s-style way of thinking. We need to do 
>> better than that.
> 
> Then explain FB, google, youtube, amazon... all of them does NOT
> provide a great deal of personalization, if at all.

They all provide intensely personalized experiences.  Just because they
don't expose the dials and switches to you doesn't mean they don't exist.

As an example: Google Chrome scans the content of webpages you visit,
and uses that to guide autocomplete in the search bar.  Your
autocomplete settings are automatically personalized based on your
browsing history with no user intervention needed.

Automatic personalization of user experience based on the software
learning the user's behavior is pretty much the gold standard in UX
design nowadays.  It's a commendable goal and worth pursuing.

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

Re: Re: [Feature Request] Multiple level subkey

[lesto fante]

>Until and unless you present a usability study involving 100+ people composing 
>a representative sample of an identifiable community, you don't know a thing.

* I think * is NOT * I know *. I may be wrong: I don't care. First of
all i want to implement this for myself, and if i'm right and is
something that people like, that is good for them.

I will expose my reasoning instead; unfortunately i don't have the
resources or knowledge for a full study.

- smartphone outnumber pc since 2011
(http://www.marketwatch.com/story/one-chart-shows-how-mobile-has-crushed-pcs-2016-04-20)

- smartphone are already carried everyday by most people owning them
(http://www.nydailynews.com/life-style/addicted-phones-84-worldwide-couldn-single-day-mobile-device-hand-article-1.1137811)

- smartphone have NFC, BT, WiFi, making contacless payment or key
exchange extremly easy, convenient, and fast. In fact, i know payment
and even public transport access by NFC is already a reality. (no
source needed, i hope)

- smartphone are easy to loose or get stolen (45% of 18-24 years hold
has lost at least one phone according
https://www.statista.com/statistics/241365/us-cell-phone-users-whose-device-has-been-lost-or-stolen-by-age-group/)

- many smartphone are not safe
(http://thehackernews.com/2016/08/hack-android-phone.html)

- some documents in different country already come with a personal
certificate/key bound to the person

My idea is to make possible for the everyday user to add/manage new
services with a main password (by using the level 2 key, encrypted),
accessing services eventually passwordless (level 3 key), but in case
of the loss of the device, reissue all certificate in a automatic
fashion on the new device, staring from the  safe key describing the
original identity (level1)

Now, from the *user* point of view, I think we can all agree that the
reissuing of the key is quite a pain, and having safe way to do it
automatically is quite nice. but no stat on that.

On the server side, we already have something going in the right
direction with openID (but i don't think can be made
transparent-compatible, that is another big discussion)

>And without exception, not one has been successful.

better one more try, that one less

>Househusband. English has used this word since 1858.

TIL

>They may lack sophisticated technical skills, but that's not the same as being 
>foolish or clueless.

But my target is not fools or clueless, my target is who is lacking
the technical skill.
For those person is all about convenience; 50% of android user does
NOT lock the phone
(https://www.elie.net/blog/survey-most-people-dont-lock-their-android-phones-but-should).
Since apple has implemented touchID, they say >80% of the user use it.
(http://appleinsider.com/articles/16/04/19/average-iphone-user-unlocks-device-80-times-per-day-89-use-touch-id-apple-says)

This, in my opinion, is exactly the target, make the deploy of the key
easier, especially in case of device loss (aka level 2 and 3 key
compromised)

>Your "average internet user" is a 1940s-style way of thinking. We need to do 
>better than that.

Then explain FB, google, youtube, amazon... all of them does NOT
provide a great deal of personalization, if at all.
UX, usability, all is about create a "average user" out of your target
audience, and make things work for most of them. It is extremely hard
to do, but now we have much more literature.

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

Re: Re: [Feature Request] Multiple level subkey

[lesto fante]

>Such a thing already exists, at least here in Italy: CIE/CNS. X509-based certs.

exactly, this is what started the idea; we have no power over those
certificate for revoke, and i have no idea if a new certificate is
issued if you loose your document.

What I found out is that the CA seems to be region-based, so i will
have to track all of them. If you know something more, I am very
interesting to hear, all the info i got is pieces found here and
there. I also hope the same apply on the rest of the EU, since AFAIK
that certificate is on the European Health Insurance Card.

BUT, of course using a card reader is not possible, especially if we
think the smartphone as main device. So would be nice if somehow the
certificate can sign (and revoke! that is also important!) a "normal"
key, that is stored on the phone, and act as main key that generate
the subkey for all the application requiring it.

All the application save the user by the "certificate" identity, so
even changing key the user is automatically recognized.

Do you think this is feasible and i should research in this direction?

>Anyway that's something that IMVHO does not fit well with GPG.

Can you explain why? also, i said in my first email i am not sure
there is the right place, but i didn't know anywhere else where to
have this discussion, so tips on this regards are also appreciated.

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

Re: [Feature Request] Multiple level subkey

[NdK]

Il 12/09/2017 19:39, lesto fante ha scritto:

> i think my user-case if one of the most common, especially if we want
> to create something like a state-provided identity (on you
> smartacard-document), that want want to make easily usable on everyday
> services (remeber, all services is really "pointing" to the master
> identity, so any subkey can be reissued without having to re-register
> in the system.
Such a thing already exists, at least here in Italy: CIE/CNS. X509-based
certs. It's got its own set of weaknesses, but since you're thinking
about a trusted third party (the State), X509 is a better fit. Possibly
extended by another applet that handles service-tokens (actually wrapped
private keys + metadata). Anyway that's something that IMVHO does not
fit well with GPG.

Just my €.02 ...

BYtE,
 Diego

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

Re: [Feature Request] Multiple level subkey

[Robert J. Hansen]

> i think my user-case if one of the most common, especially if we want
> to create something like a state-provided identity...

Until and unless you present a usability study involving 100+ people
composing a representative sample of an identifiable community, you
don't know a thing.

Over the last 25 years I cannot count the number of people who were sure
their use case was common, or their pet idea would result in widespread
GnuPG usage, or what-have-you.  And without exception, not one has been
successful.

I understand you have a belief that your use case is common.  Until and
unless you present a study showing that it actually *is* common, I will
not share in your belief.  I suspect many people here share in this
sentiment.

>> Please don't default to using a woman as the canonical example
> non-technical/clueless user.
> 
> AFAIK housewife does not have any male translation, so it is
> technically genderless :)

Househusband.  English has used this word since 1858.

https://www.merriam-webster.com/dictionary/househusband

Either way, please don't use housewives or househusbands as examples of
"clueless users".  They are far from it.  They may lack sophisticated
technical skills, but that's not the same as being foolish or clueless.

If you want people to use your product, you need to start by respecting
your users.

> Sterile discussion aside, lets agree on a real definition like Average
> Internet User, or AIU for short.

No.  Big, emphatic, *NO*.

There is no average user.  Please repeat that sentence until it sticks.
There is no average user.  Average users don't exist.  They're myths.
Unicorns.  And if you design for an average user, you're going to make
it a poor experience for essentially everyone.

During WW2, the United States government spent a lot of money doing
measurements of fighter pilots.  Height, weight, build, length of arms,
length of legs, size of their hands, and more.  With all this data they
built cockpits that would be comfortable for 90% of pilots.  Pilots
hated their cockpits because they were terribly uncomfortable.  Real
people fell outside of the 90% mark in at least a few categories.  In
the course of making a cockpit that would fit almost everyone
comfortably, it fit almost no one comfortably.

Modern fighter jets have instead embraced customizability.  The American
F-15E fighter can accommodate pilots from 5'4" to 6'6" (1.62m to 1.98m),
a variety of builds, reaches, and more.  By recognizing there was no
such thing as an average pilot, the designers opened the door to make a
cockpit that was comfortable for the vast majority of users.

Your "average internet user" is a 1940s-style way of thinking.  We need
to do better than that.

___
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 understand that you're trying to make *your* life easier.

i think my user-case if one of the most common, especially if we want
to create something like a state-provided identity (on you
smartacard-document), that want want to make easily usable on everyday
services (remeber, all services is really "pointing" to the master
identity, so any subkey can be reissued without having to re-register
in the system.

>An OpenPGP certificate with a single master
certification-capable public key and several different
signing/encrypting/authenticating subkeys is already pretty complex

I am not aware of the implementation, but I see 2 issue there:

One is how to create a subkey of a subkey; as i know the maskerkey
sign the subkey, so we can do the same here, we have to define where
the information about the sign will be stored, or a flag to tell this
is a sub-sub key.

The second problem is the sharing of the keys and revoke certificate,
something that is already solved by keyserver.

>we have toolchains that are (starting to be) able to deal with that
situation.

If this is in the standard, and the standard is used, then is likely
that other tool will implement it. In general, we can be almost
completely retro-compatible if engineered in the right way (i'm
thinking, level 1 key is seen by legacy as invalid(?) key, level 2 as
master key, and level 2 as subkey of master. at this point, when we
revoke level 1 key, to keep retrocompatibility we always have to issue
a revoke for all level 2 key first.

>Keep it simple :)

How would you implement this?


> Please don't default to using a woman as the canonical example
non-technical/clueless user.

AFAIK housewife does not have any male translation, so it is
technically genderless :)

and why i can't use a female gender, but then discriminate against a role?

Sterile discussion aside, lets agree on a real definition like Average
Internet User, or AIU for short.

Characteristic (based on personal experience, so lets agree on that) are:

- its main device is the smartphone, where basically all the login are stored.
- generally stick with a "one password for all"
- is willing to make a bit more secure like 2 step authentication, but
setup is scary if take more than 2 passages
- understand the rick of phishing and opening attachment BUT
- open the .ppt sent by his friend in the email chain
- download that app too see X for free or get free life for the game Y
- always click the wrong download button before getting what he is looking for

Basically: he keep important stuff on his device. That has relatively
high possibility to be violated or lost, so WE need to make sure we
have a backup solution for him. (in my case, with the level1 key, the
user just have to revoke and reissue a new level 2 key! and he does
not even need to update the "password" or "key" to all its service, if
compatible with this system otherwise is the same old game as always.)

2017-09-12 18:01 GMT+02:00 Daniel Kahn Gillmor :
> On Sun 2017-09-10 21:17:33 +0200, lesto fante wrote:
>> here i want to AUTOMATE, make this thing MORE EASY to use than a
>> common password approach.
>
> I understand that you're trying to make *your* life easier.  But the
> choices you make also have an impact on the people who look at your
> public keys.  An OpenPGP certificate with a single master
> certification-capable public key and several different
> signing/encrypting/authenticating subkeys is already pretty complex, but
> we have toolchains that are (starting to be) able to deal with that
> situation.
>
> If you try to introduce this multi-level arrangement, you're pretty
> likely to force *other* people (whose toolchains you have even less
> control over) into situations that will be LESS EASY and
> NON-AUTOMATABLE.  I don't think this is a great tradeoff for the
> ecosystem.
>
> Keep it simple :)
>
>> This approach MUST be "housewife proof";
>
> Please don't default to using a woman as the canonical example
> non-technical/clueless user.  The computer security community already
> has enough problems with gender bias.  It's unfriendly and unwelcoming
> in ways that we need to outgrow.  And it's wrong -- real-world
> housewives (and "moms" and "grandmas" to name a few other common sexist
> "female clueless user" tropes) are often expected to figure out many
> things that are outside of their field of expertise and then aren't
> given any intellectual credit for navigating complex and changing
> requirements and exepctations.
>
> If you need an example of someone who doesn't really understand things
> at a technical level but needs to have stuff Just Work for them anyway,
> i've seen Cory Doctorow suggest using "your boss" as the canonical
> example :P
>
> All the best,
>
> --dkg

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

Re: [Feature Request] Multiple level subkey

[Daniel Kahn Gillmor]

On Sun 2017-09-10 21:17:33 +0200, lesto fante wrote:
> here i want to AUTOMATE, make this thing MORE EASY to use than a
> common password approach.

I understand that you're trying to make *your* life easier.  But the
choices you make also have an impact on the people who look at your
public keys.  An OpenPGP certificate with a single master
certification-capable public key and several different
signing/encrypting/authenticating subkeys is already pretty complex, but
we have toolchains that are (starting to be) able to deal with that
situation.

If you try to introduce this multi-level arrangement, you're pretty
likely to force *other* people (whose toolchains you have even less
control over) into situations that will be LESS EASY and
NON-AUTOMATABLE.  I don't think this is a great tradeoff for the
ecosystem.

Keep it simple :)

> This approach MUST be "housewife proof";

Please don't default to using a woman as the canonical example
non-technical/clueless user.  The computer security community already
has enough problems with gender bias.  It's unfriendly and unwelcoming
in ways that we need to outgrow.  And it's wrong -- real-world
housewives (and "moms" and "grandmas" to name a few other common sexist
"female clueless user" tropes) are often expected to figure out many
things that are outside of their field of expertise and then aren't
given any intellectual credit for navigating complex and changing
requirements and exepctations.

If you need an example of someone who doesn't really understand things
at a technical level but needs to have stuff Just Work for them anyway,
i've seen Cory Doctorow suggest using "your boss" as the canonical
example :P

All the best,

--dkg


signature.asc
Description: PGP 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]

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

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