Re: Modernizing Web-of-trust for Organizations

[Kristian Fiskerstrand]

On 01/06/2018 12:23 AM, Lou Wynn wrote:
> On 01/05/2018 12:54 PM, Kristian Fiskerstrand wrote:
>> On 01/05/2018 05:29 PM, Lou Wynn wrote:
>>> The auditing key is certified by the root key and stays with the latter
>>> in my design. Only the administrator can make policy to turn on/off
>>> auditing, the client plugin takes corresponding actions automatically.
>>> End users don't need to do anything, namely, using or not using the
>>> auditing key to encrypt is completely transparent to end users. As a
>>> result, there is no such issue of "forgetting to add it."
>> Can you please elaborate on how this would be compatible with existing
>> implementations of RFC4880?
>>
>>
> If you asked about the auditing key compatibility, then it is probably
> not the right question because RFC4880 does not talk about it at all. My
> client plugin takes automatic action to encrypt a message with two keys
> and sends to one receiver, which I don't think violates the RFC.

The primary issue would be requiring everyone to use your client for the
scheme to work. There are ways to handle the issues you propose within
the existing ecosystem that won't have this requirement, and as such
will be superior.

-- 

Kristian Fiskerstrand
Blog: https://blog.sumptuouscapital.com
Twitter: @krifisk

Public OpenPGP keyblock at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3

"We can only see a short distance ahead, but we can see plenty there
that needs to be done."
(Alan Turing)



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

Re: Modernizing Web-of-trust for Organizations

[Lou Wynn]

On 01/05/2018 12:54 PM, Kristian Fiskerstrand wrote:
> On 01/05/2018 05:29 PM, Lou Wynn wrote:
>> The auditing key is certified by the root key and stays with the latter
>> in my design. Only the administrator can make policy to turn on/off
>> auditing, the client plugin takes corresponding actions automatically.
>> End users don't need to do anything, namely, using or not using the
>> auditing key to encrypt is completely transparent to end users. As a
>> result, there is no such issue of "forgetting to add it."
> Can you please elaborate on how this would be compatible with existing
> implementations of RFC4880?
>
>
If you asked about the auditing key compatibility, then it is probably
not the right question because RFC4880 does not talk about it at all. My
client plugin takes automatic action to encrypt a message with two keys
and sends to one receiver, which I don't think violates the RFC.

However, there is a potentially issue related to compatibility for the
system as a whole depending on the direction. For example, if you import
your current PGP key into my system, then you can still use the key
without a problem because as a part of the importing process the server
adds a new certificate with necessary properties made by the certifying
key. The client plugin of my system will recognize your key as valid
once you have this certificate.

In the other direction, if you export a key from my system and want to
use it in your current PGP client, you can do so because a key in my
system is still a valid PGP key. However, you don't have any benefits of
my system such as trust realm/group support because your current PGP
client does not enforce the autonomous certification authority model.

Thanks,
Lou



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

Re: Modernizing Web-of-trust for Organizations

[Kristian Fiskerstrand]

On 01/05/2018 05:29 PM, Lou Wynn wrote:
> On 01/05/2018 01:10 AM, Kristian Fiskerstrand wrote:
>> There are easily scenarios where a customer forgets to add the "auditing
>> key", making the data unavailable to the organization, in particular in
>> context of loss of employee.
>>
> The auditing key is certified by the root key and stays with the latter
> in my design. Only the administrator can make policy to turn on/off
> auditing, the client plugin takes corresponding actions automatically.
> End users don't need to do anything, namely, using or not using the
> auditing key to encrypt is completely transparent to end users. As a
> result, there is no such issue of "forgetting to add it."

Can you please elaborate on how this would be compatible with existing
implementations of RFC4880?


-- 

Kristian Fiskerstrand
Blog: https://blog.sumptuouscapital.com
Twitter: @krifisk

Public OpenPGP keyblock at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3

"A ship is safe in harbour, but that's not what ships are for"
(Will Shedd)



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

Re: Modernizing Web-of-trust for Organizations

[Lou Wynn]

On 01/04/2018 02:28 PM, Ben McGinnes wrote:
> It seems to me, though, that the idea was to provide a means for the
> company to repudiate an employee's key even if the employee was no
> longer available.

This is just one of the benefits enabled by my goals which I stated at
the beginning, and it is most related to central management of keys.
There are systems that have attempted to solve one or two of them with
the cost of sacrificing others. My take is doing them all with the new
trust model and its supporting mechanisms.

Thanks,
Lou


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

Re: Upgrading from gpg1 to gpg2: lots of trouble, need help

[Daniel Kahn Gillmor]

On Thu 2017-12-21 16:19:00 +1100, raf wrote:
> Sorry, I thought I already did. The 4th point above does not
> work. When the public-facing host connects via ssh to the
> key management host, and runs gpg, instead of it successully
> connecting to the existing gpg-agent process that I started
> minutes earlier, it starts a new gpg-agent process which
> doesn't know the passphrase and so the decryption fails.
>
> Here are the gpg-agent processes after I start the first gpg-agent
> process and preset the passphrase:
>
>   /usr/bin/gpg-agent --homedir /etc/thing/.gnupg --allow-preset-passphrase \
> --default-cache-ttl 3600 --max-cache-ttl 3600 --daemon -- /bin/bash 
> --login
>
> Here are the gpg-agent processes after an inoming ssh connection that
> attempts to use gpg:
>
>   /usr/bin/gpg-agent --homedir /etc/thing/.gnupg --allow-preset-passphrase \
> --default-cache-ttl 3600 --max-cache-ttl 3600 --daemon -- /bin/bash 
> --login
>   gpg-agent --homedir /etc/thing/.gnupg --use-standard-socket --daemon
>
> That second gpg-agent process should not exist. The gpg
> process that caused it to be started should have connected
> to the existing gpg-agent process. The sockets for it
> existed but perhaps there was some reason why it didn't use
> them.
>
> There must be some reason why gpg thinks it needs to start
> gpg-agent. Perhaps it's because it's a different "user
> session". They are from two different ssh connections after
> all.

this is the part that i'm unable to reproduce.

Are both of these processes running as the same user account?

does something at some point destroy or mask the standard socket created
by the first process, so that a new gpg invocation decides to start up a
new instance of gpg-agent?

if your old session was being terminated, then you'd expect the first
agent to actually disappear.  that's not happening.

and neither of these agents is beign launched by systemd, because if it
were it would have a --supervised .

> But when I su to the user in question, I get:
>
>   > systemctl --user is-enabled gpg-agent.service gpg-agent.socket 
> gpg-agent-ssh.socket gpg-agent-extra.socket gpg-agent-browser.socket
>   Failed to connect to bus: No such file or directory
>
> But it still reports as enabled with --global.
> Maybe that's enough. I don't know.

are you su'ing with a login shell (i.e. with - or -l or --login), or
not?

> I am completely failing to understand what's going on here. :-)
> Is systemd handling the sockets or not? There's no /run/user
> directory for this user so probably not. Maybe I don't
> understand --user and --global or systemd in general.

why is there no /run/user for this user?  if you're running a modern
version of systemd, and your user has actually started a session, there
should be a /run/user created automatically.

   --dkg

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

Re: Modernizing Web-of-trust for Organizations

[Lou Wynn]

On 01/05/2018 01:10 AM, Kristian Fiskerstrand wrote:
> There are easily scenarios where a customer forgets to add the "auditing
> key", making the data unavailable to the organization, in particular in
> context of loss of employee.
>
The auditing key is certified by the root key and stays with the latter
in my design. Only the administrator can make policy to turn on/off
auditing, the client plugin takes corresponding actions automatically.
End users don't need to do anything, namely, using or not using the
auditing key to encrypt is completely transparent to end users. As a
result, there is no such issue of "forgetting to add it."

Thanks,
Lou


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

Re: How do you find out the Keygrip of a v3 key?

[Kristian Fiskerstrand]

On 01/05/2018 02:59 PM, MFPA wrote:
> These old keys are not supported in GnuPG 2.1/2.2 and the
> - --with-keygrip option is not valid in GnuPG 2.0 or 1.4.
> 
> I have googled, but could not come up with a search term that produced
> any relevant hits.

I'd start with libgcrypt's gcry_pk_get_keygrip()

-- 

Kristian Fiskerstrand
Blog: https://blog.sumptuouscapital.com
Twitter: @krifisk

Public OpenPGP keyblock at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3

"Excellence is not a singular act but a habit. You are what you do
repeatedly."
(Shaquille O'Neal)



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

How do you find out the Keygrip of a v3 key?

[MFPA]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512



Is it possible to find out the Keygrip of a version 3 key?

These old keys are not supported in GnuPG 2.1/2.2 and the
- --with-keygrip option is not valid in GnuPG 2.0 or 1.4.

I have googled, but could not come up with a search term that produced
any relevant hits.


- --
Best regards

MFPA  

Was time invented by an Irishman named O'Clock?
-BEGIN PGP SIGNATURE-

iNUEARYKAH0WIQSWDIYo1ZL/jN6LsL/g4t7h1sju+gUCWk+E218UgAAuAChp
c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0OTYw
Qzg2MjhENTkyRkY4Q0RFOEJCMEJGRTBFMkRFRTFENkM4RUVGQQAKCRDg4t7h1sju
+tNWAQCWgeBFvYv9dqAvgkeG6GJOnhosGfFoPPTTyRxFhTKKsAD+Lbz6jwTXEMvj
aBQ/l+ZexkqtjcjFKn4YUy8qvdju7wOJApMEAQEKAH0WIQRSX6konxd5jbM7JygT
DfUWES/A/wUCWk+E218UgAAuAChpc3N1ZXItZnByQG5vdGF0aW9ucy5vcGVu
cGdwLmZpZnRoaG9yc2VtYW4ubmV0NTI1RkE5Mjg5RjE3Nzk4REIzM0IyNzI4MTMw
REY1MTYxMTJGQzBGRgAKCRATDfUWES/A/xPwEACPFcMFJeOe1QwSrtHeeVj0YTa1
9/xrjHeX4XKOFcexZiDjBiJKXg0PSc8eqwPoY7EHvbP9TmSeEeD4g270x3lYthwZ
96G5NAeSrXM6BUsPz/W724uS21YZSzTlh2E/SRg1d1WkJWwzpWXFDF9SG/5Rf7iq
ePVyZpcd6F2yYSp9Fi+CN+PNNKD+d4tLYM3sxrnT2lFF6oKiAcUIM2MkaiHKeWDR
RsXSnAG5nFdAvxTQvlAyCCbuTRx1q7e6CVYUXILGEnJaNb5gIjH7r+X9zYPH/jZl
jjZ5zs92lfWsVPjX+6yUUoC0paZPylxUBQwEZ28auEo5JM6y3DZl0j0cz+JHjOT/
L08Kz1EwEzgmkgh/+kgRv9XrwwTbGjwhmTXYY8zpPhb7qBsVsFF4IDO1OU/0f7mr
nb0TCFRY/77Uq1N5msNmsfC9OsLNUH+LVm8oxsT/sDo0DshTegHiW42Yw/8ZxpSw
/9J6mT/tVfd1DYhWLCcyXdWQei0exS7u3D6gcz/tY6bluBvMTTw+7XO1KwdHEvCz
re6cFQGA3xbsQQQCYexXqEinw4uSv2oheK2ZJm8R7GcvsWGqbQlebWLcyVXFHc0f
J6PuF9w2kUVWidlkFWnG8lkZRQSSOUtjnDMN5me2jAYQWU69y+OLfTnaPbDXrY45
XKhSFQ0AW77Zepl+Ug==
=Oc0k
-END PGP SIGNATURE-


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

Re: Modernizing Web-of-trust for Organizations

[Kristian Fiskerstrand]

On 01/05/2018 10:13 AM, Andrew Gallagher wrote:
> 
>> On 5 Jan 2018, at 08:41, Lou Wynn  wrote:
>>
>> The only need for an
>> organization to access their data is decrypting the encrypted data,
>> which is satisfied by the auditing key.
> 
> The standard way of doing this without allowing for impersonation is escrow 
> of the encryption subkey only. This can be done by encrypting the E subkey to 
> the auditing key, the private key of which is presumably well controlled. 

The issue with that is that as long as the employee has private key for
primary the individual can create new subkeys, and the primary will
always have signing capability (if not always specified as usage flag).
In most setups the employee won't need/shouldn't have the private key
info for the primary for this (and a few other) reasons.

-- 

Kristian Fiskerstrand
Blog: https://blog.sumptuouscapital.com
Twitter: @krifisk

Public OpenPGP keyblock at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3

"The journey of a thousand miles begins with one step."
(Lao Tzu)



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

Re: Modernizing Web-of-trust for Organizations

[Andrew Gallagher]

> On 5 Jan 2018, at 08:41, Lou Wynn  wrote:
> 
> The only need for an
> organization to access their data is decrypting the encrypted data,
> which is satisfied by the auditing key.

The standard way of doing this without allowing for impersonation is escrow of 
the encryption subkey only. This can be done by encrypting the E subkey to the 
auditing key, the private key of which is presumably well controlled. 

A

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

Re: Modernizing Web-of-trust for Organizations

[Kristian Fiskerstrand]

On 01/05/2018 09:41 AM, Lou Wynn wrote:
> On 01/05/2018 12:18 AM, Kristian Fiskerstrand wrote:
>> Businesses have reasonable need to access their data, so they need to
>> have access to his private keys, which contradicts "which
>> is meant to prevent others from using his private keys", although
>> reading it again I presume you're limiting the statement to
>> non-authorized personnel in the normal scenario?
> This reason is vague and invalid. The purpose of a private key is
> two-fold: encryption and message authorization. The only need for an
> organization to access their data is decrypting the encrypted data,
> which is satisfied by the auditing key. I don't see any valid reason to
> damage message authorization.

There are easily scenarios where a customer forgets to add the "auditing
key", making the data unavailable to the organization, in particular in
context of loss of employee.

-- 

Kristian Fiskerstrand
Blog: https://blog.sumptuouscapital.com
Twitter: @krifisk

Public OpenPGP keyblock at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3

"Success is getting what you want. Happiness is wanting what you get"
(Dale Carnegie)



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

Re: Modernizing Web-of-trust for Organizations

[Lou Wynn]

On 01/05/2018 12:18 AM, Kristian Fiskerstrand wrote:
> Businesses have reasonable need to access their data, so they need to
> have access to his private keys, which contradicts "which
> is meant to prevent others from using his private keys", although
> reading it again I presume you're limiting the statement to
> non-authorized personnel in the normal scenario?

This reason is vague and invalid. The purpose of a private key is
two-fold: encryption and message authorization. The only need for an
organization to access their data is decrypting the encrypted data,
which is satisfied by the auditing key. I don't see any valid reason to
damage message authorization. I'd suggest you read Ben McGinnes's post.

If you still insist that there is value in accessing employees' private
key, then I would say that you belong to the type of organizations that
*want* to access employee's private keys although doing so causes more
damages. I described the two categories of organizations when replying
Ben's post.

This is another reason that I want to modernize PGP for organizations
because when people use PGP in such an environment they tend to make
dangerous decisions such as key escrow or encryption gateway to meet
organizational management requirements while compromising message
authorization.

Thanks,
Lou



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

Re: Modernizing Web-of-trust for Organizations

[Kristian Fiskerstrand]

On 01/05/2018 01:46 AM, Lou Wynn wrote:
> On 01/04/2018 04:15 PM, Kristian Fiskerstrand wrote:
>> On 01/05/2018 01:12 AM, Lou Wynn wrote:
>>> I guess that you've missed somewhere I said in my previous posts that
>>> the end user chooses his own password to protect his key password, which
>>> is meant to prevent others from using his private keys.
>> At which point I'm wondering about your priorities, if the corporation
>> doesn't have access to the data (without the specific encryption key
>> being included) what is the value?
> Sorry, I don't get it. Can you explain your question again? What data,
> in which scenario?
> 

Businesses have reasonable need to access their data, so they need to
have access to his private keys, which contradicts "which
is meant to prevent others from using his private keys", although
reading it again I presume you're limiting the statement to
non-authorized personnel in the normal scenario?


-- 

Kristian Fiskerstrand
Blog: https://blog.sumptuouscapital.com
Twitter: @krifisk

Public OpenPGP keyblock at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3

"In politics stupidity is not a handicap."
(Napoleon Bonaparte)



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