Re: [Feature Request] Multiple level subkey
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
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
>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
> 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: Re: [Feature Request] Multiple level subkey
>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
>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
> 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
>(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 l
Re: [Feature Request] Multiple level subkey
>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
(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
Re: [Feature Request] Multiple level subkey
>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
>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
(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 w
Re: [Feature Request] Multiple level subkey
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
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
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 arose here…) > >
[Feature Request] Multiple level subkey
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