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 th
> 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-user
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 sof
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
>> 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
>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 dow
> 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
> 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.
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 res
>> 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
>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
som
>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 re
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 "po
> 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 las
> 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 r
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.
>(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
>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
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 co
(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
ope
>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 r
>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
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 b
(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
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
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, tsi
(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
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
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.
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; t
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 -
> 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 key
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
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
34 matches
Mail list logo
