Re: Modernizing Web-of-trust for Organizations

[Lou Wynn]

On 02/18/2018 05:55 PM, Ben McGinnes wrote:
> So you took a system built from the outset on a security model founded
> entirely on public key exchanges between distributed and federated
> (both self-determining and self-governing) nodes ... and then spent a
> considerable amount of time and effort making that system centralised
> in order to meet certain types of common business use cases ...
>
> ... with a software package which ships with a complete implementation
> of S/MIME as well ...
No, there is no S/MIME implementation because the PKI model it relies on
is inherently precarious for enterprise usage because of using
third-party certificates. Once a 3rd party CA is trusted, all users it
certified becomes trusted while those users have no business
relationship with the enterprise.

> Hmm ...
>
> Okay, I just have one question:
>
> *Why?!*
The short answer is that neither S/MIME's PKI or OpenPGP's web-of-trust
is suitable for organizational uses in term of defining trusted people
for the organization. In addition, current clients of both require
considerable efforts at the end-user side to configure and use. For a
longer analysis, here is a white paper:
https://www.cs.utah.edu/~luzhao/pub/doc/autonomous-certificate-authority.pdf


Thanks,
Lou

>
>
> Regards,
> Ben


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

Re: Modernizing Web-of-trust for Organizations

[Ben McGinnes]

On Fri, Jan 05, 2018 at 08:47:29AM -0800, Lou Wynn wrote:
> 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.

I see ...

> 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.

So you took a system built from the outset on a security model founded
entirely on public key exchanges between distributed and federated
(both self-determining and self-governing) nodes ... and then spent a
considerable amount of time and effort making that system centralised
in order to meet certain types of common business use cases ...

... with a software package which ships with a complete implementation
of S/MIME as well ...

...

...

Hmm ...

Okay, I just have one question:

*Why?!*


Regards,
Ben


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

Re: Modernizing Web-of-trust for Organizations

[Lou Wynn]

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?

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

[Lou Wynn]

On 01/04/2018 04:31 PM, Lou Wynn wrote:
> I think that I simplified my original description too much. The two
> levels of protection works like this.
> 1. The employee chooses his own password, which is used to encrypt his
> private key.
>
> 2. Then the encrypted key is encrypted with the guard key.
>
> When a client plugin passes authentication, the sever decrypts from 2's
> result and sends it to the client.
I'm sorry for missing another step in sending a key to the client. After
the server decrypts the encrypted key material with the guard key, it
uses the public key of the client plugin to encrypt it and sends it to
the client. The client plugin decrypts it first with the plugin key, and
then the user's own password is required to decrypt the private key.

The guard key and the plugin key here are used to defy the
man-in-the-middle in either direction and provide secure channels.

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

[Lou Wynn]

On 01/04/2018 02:28 PM, Ben McGinnes wrote:
> On Wed, Jan 03, 2018 at 05:34:30PM -0800, Lou Wynn wrote:
>> The management of users' private key is a little more complicated. I
>> use two levels of protection. One level is at the organization. An
>> organization actually has a fourth key, which I call the guard key,
>> to encrypt the password of user's private key. This guard key is
>> also managed by the key management system. In addition, a user can
>> choose another her own password to encrypt the key password too.
> That just spreads the potential points of human failure and you run
> the risk that anyone with access to this guard key would be able to
> abuse the position to access an employee's credentials (saying they
> don't have access to the private key doesn't hold any weight on a
> company intranet where they've probably already got root/admin
> access).  So it'd be too easy for some unscrupulous sys admin (you
> might trust you, but what happens when you leave, do you know your
> successor?) has a personal issue with someone in, say, marketing and
> stitches them up with a few choice forged and signed emails.
>
> No, that's a *bad* plan and creates all sorts of horrible legal
> problems for the company or at least has the very real potential to do
> so.

I think that I simplified my original description too much. The two
levels of protection works like this.

1. The employee chooses his own password, which is used to encrypt his
private key.

2. Then the encrypted key is encrypted with the guard key.

When a client plugin passes authentication, the sever decrypts from 2's
result and sends it to the client. This key material is still encrypted
by the employee's own password. The decryption of 1 happens at the
client plugin.

My estimates is that there exist different types of organizations. Some
want to access employee's key, and some don't. So For the former, they
can choose to skip the first level of protection. For the latter, they
can require to use it. An organization can only change from using the
second protection only to using both, but not the other way around.

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

-- 

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

"At 18 our convictions are hills from which we look; At 45 they are
caves in which we hide."
(F. Scott Fitzgerald)



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 04:06 PM, Kristian Fiskerstrand wrote:
> But in the end it doesn't matter, as the organization anyways has access
> to the private key material of the employee. So a third party "auditing
> key" is irrespective of any access goals.
>
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.

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:04 AM, Lou Wynn wrote:
> On 01/04/2018 02:57 PM, Kristian Fiskerstrand wrote:
>> On 01/04/2018 11:24 PM, Lou Wynn wrote:
>> but you add the requirement that all end users sending email to you
>> require to validate the auditing key as well (auditing is likely wrong
>> word, archiving is more likely relevant). for auditing you certainly
>> want gpg-agent monitoring of assuan channel in separate domain.
> I don't get the exact meaning of this paragraph.
> 
> I'll try to explain a little. If the administrator sets up the auditing
> policy (which implies that the auditing is an option), then the plugins
> of employees will also use the auditing key to encrypt a message besides
> receiver's public key. This is a little different from what I said
> earlier about users' plugins because this is a design decision which has
> not been finalized: whether to make employees or employees plus partners
> to use the auditing key. This might become an option too.

But in the end it doesn't matter, as the organization anyways has access
to the private key material of the employee. So a third party "auditing
key" is irrespective of any access goals.

-- 

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

Aut dosce, aut disce, aut discede
Either teach, or study, or leave



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:57 PM, Kristian Fiskerstrand wrote:
> On 01/04/2018 11:24 PM, Lou Wynn wrote:
> but you add the requirement that all end users sending email to you
> require to validate the auditing key as well (auditing is likely wrong
> word, archiving is more likely relevant). for auditing you certainly
> want gpg-agent monitoring of assuan channel in separate domain.
I don't get the exact meaning of this paragraph.

I'll try to explain a little. If the administrator sets up the auditing
policy (which implies that the auditing is an option), then the plugins
of employees will also use the auditing key to encrypt a message besides
receiver's public key. This is a little different from what I said
earlier about users' plugins because this is a design decision which has
not been finalized: whether to make employees or employees plus partners
to use the auditing key. This might become an option too.

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

[Lou Wynn]

On 01/04/2018 02:59 PM, Kristian Fiskerstrand wrote:
> On 01/04/2018 11:14 PM, Lou Wynn wrote:
>> Compared to using two CAs, my design introduces two properties to a
>> certificate. One is the certificate type, which is "p" for a partner and
>> "e" for an employee.
> why not make it compatible with rfc4880 directly? your proposal would
> require client handling of e.g notation data?
This is exactly the reason for my modernizing web of trust. I cannot
find a way to make it compatible with rfc4880 and meet all my goals. I'd
love to hear your alternatives if it is possible. For example, I'd like
to deprecate how trust is assigned values and used in the rfc. However,
I'd love to use existing good mechanisms as many as possible, such as
the entire PGP data format.

As for changes to PGP, I do require new certificate properties and
certificate validations to enforce trust realms and groups.

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/04/2018 11:14 PM, Lou Wynn wrote:
> Compared to using two CAs, my design introduces two properties to a
> certificate. One is the certificate type, which is "p" for a partner and
> "e" for an employee.

why not make it compatible with rfc4880 directly? your proposal would
require client handling of e.g notation data?

-- 

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

Amantes sunt amentes
Lovers are lunatics



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

[Kristian Fiskerstrand]

On 01/04/2018 11:24 PM, Lou Wynn wrote:
> I guess that you missed the auditing key part. I introduced it to meet
> auditing requirements or scanning of messages without using end user's
> private keys.

but you add the requirement that all end users sending email to you
require to validate the auditing key as well (auditing is likely wrong
word, archiving is more likely relevant). for auditing you certainly
want gpg-agent monitoring of assuan channel in separate domain.

-- 

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

Amantes sunt amentes
Lovers are lunatics



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

[Ben McGinnes]

On Wed, Jan 03, 2018 at 05:34:30PM -0800, Lou Wynn wrote:
> 
> The management of users' private key is a little more complicated. I
> use two levels of protection. One level is at the organization. An
> organization actually has a fourth key, which I call the guard key,
> to encrypt the password of user's private key. This guard key is
> also managed by the key management system. In addition, a user can
> choose another her own password to encrypt the key password too.

That just spreads the potential points of human failure and you run
the risk that anyone with access to this guard key would be able to
abuse the position to access an employee's credentials (saying they
don't have access to the private key doesn't hold any weight on a
company intranet where they've probably already got root/admin
access).  So it'd be too easy for some unscrupulous sys admin (you
might trust you, but what happens when you leave, do you know your
successor?) has a personal issue with someone in, say, marketing and
stitches them up with a few choice forged and signed emails.

No, that's a *bad* plan and creates all sorts of horrible legal
problems for the company or at least has the very real potential to do
so.

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.  Perhaps they were fired or just became very ill or
any of a host of reasons with varying degrees of potential drama
attached.  This is a legitimate issue in the corporate environment,
but the solution to it is not to maintain an escrow on private keys
and passphrases which could subsequently be abused by a technically
proficient person within the company.

What you should do instead is keep an encrypted and archived copy of
the revocation certificate for each employee's key.  That way it is
still possible to declare that the key and/or employee is no longer
sanctioned, but without providing a means where anyone with access to
this system could either intercept encrypted communications sent to
that key or forge messages appearing to come from it.

Any other option is going to end up in a legal dispute eventually and
will probably cost *far* more than what you think you're saving
yourself from now.


Regards,
Ben


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

[Lou Wynn]

On 01/04/2018 02:08 PM, Kristian Fiskerstrand wrote:
> no, there isn't necessarily a client plugin, the gateway decrypts the
> message before it hits the internal email server, so end-user sees
> un-encrypted message, this is protecting transport, but security of
> on-site is ensures through different channels
I see. The gateway solution is contradictory to my end-to-end email
security goal, which requires that only the end user can use his own
private key. The gateway is a total disaster if the gateway is breached.
> I don't see this as disagreeing, this means you don't have any benefit
> from storing the email in encrypted form once it hits the corporate
> network, so you're better off decryption it at gateway anyways.
>
I guess that you missed the auditing key part. I introduced it to meet
auditing requirements or scanning of messages without using end user's
private keys.

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

[Lou Wynn]

On 01/04/2018 02:04 PM, Kristian Fiskerstrand wrote:
>> I don't think it necessary to use business unit level certifying keys in
>> my design. It introduces management overhead which shadows its benefits.
>> If you understand the concept of trust realm/trust group and its
>> verification methods I described before, then there is no need for a key
>> hierarchy at all. Can you describe a use case that demands the use of
>> unit level certifying key? I'll try to explain how to implement it with
>> trust realm and groups.
> I didn't necessarily say businsess unit level CA, but separation between
> employee and business partner CAs.
Compared to using two CAs, my design introduces two properties to a
certificate. One is the certificate type, which is "p" for a partner and
"e" for an employee. The other property is the trust group, which is a
list of groups and tells the certificate verifier the groups that the
key belongs to. These two properties are implemented as notations of the
certificate.

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/04/2018 10:58 PM, Lou Wynn wrote:
> It's doable, but I'd like to make sure that I understand what you
> mean by "within corporate infrastructure?" Do you mean the client
> plugin sends requests to the server to decrypt and verify received
> messages?

no, there isn't necessarily a client plugin, the gateway decrypts the
message before it hits the internal email server, so end-user sees
un-encrypted message, this is protecting transport, but security of
on-site is ensures through different channels

> This is definitely a trade-off between key security and performance.
> But I don't see any obvious benefits given that the user's computer
> that runs the client plugin also belongs to corporate infrastructure.
> If the user's computer is compromised, then the administrator simply
> clean up the computer and re-install or re-initialize user's email
> client, which includes the client plugin.

I don't see this as disagreeing, this means you don't have any benefit
from storing the email in encrypted form once it hits the corporate
network, so you're better off decryption it at gateway anyways.

-- 

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 committee is a group that keeps minutes and loses hours."
(Milton Berle)



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

[Kristian Fiskerstrand]

On 01/04/2018 10:38 PM, Lou Wynn wrote:
> On 01/04/2018 03:02 AM, Kristian Fiskerstrand wrote:
>> On 01/04/2018 02:34 AM, Lou Wynn wrote:
>>> No, there is no business unit level certifying key. An enterprise only
>>> has one root key, which is the ultimate certificate authority for its
>>> own employees and business partners.
>> I normally recommend separating those, as the value for external parties
>> that might want to trust this CA for certifying employees but not other
>> third parties.
> I don't think it necessary to use business unit level certifying keys in
> my design. It introduces management overhead which shadows its benefits.
> If you understand the concept of trust realm/trust group and its
> verification methods I described before, then there is no need for a key
> hierarchy at all. Can you describe a use case that demands the use of
> unit level certifying key? I'll try to explain how to implement it with
> trust realm and groups.

I didn't necessarily say businsess unit level CA, but separation between
employee and business partner CAs.

>> As for access to private key material, I normally recommend that the end
>> user never has access to any secret key material, but only access to
>> using subkeys (never the primary) using smartcard tokens.
> I completely agree, and indeed in my system, an end user never needs to
> directly access his secret key. Actually, he does not need to access his
> public key either. This is what I mean by zero configuration on client
> side, both for trust management and key management.
> 
> Thanks,
> Lou
> 


-- 

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

Carpe noctem
Seize the night



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 01:04 PM, Ben McGinnes wrote:
> On Thu, Jan 04, 2018 at 12:40:59AM +, MFPA wrote:
>> For example, my ISP [0] says "All staff keys are signed using the
>> company signing key. This is very much like a traditional company
>> seal. Only the director has access to this key and it is only used
>> for signing other keys. If/when a member of staff leaves a
>> revocation is issued of that signature and loaded on to keyservers."
>>
>> [0] 
> Cute, but they're fast approaching the point where anyone with a
> decent beowolf cluster and an axe to grind could mess with that 1K
> certification key they're using there.

Can you explain what the problem is? I don't really know what you mean,
but I've love to hear.

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

[Lou Wynn]

On 01/04/2018 01:31 PM, Kristian Fiskerstrand wrote:
> On 01/04/2018 10:21 PM, Lou Wynn wrote:
>> After a client plugin logs in successfully, the server sends the user's
>> encrypted email key to the client.
> Aren't you better off with a gateway solution like PGP Universal /
> Symantec Encryption Server (or for that matter if GPGRelay is still
> alive) ? That never exposes key material to client, i.e always operates
> within corporate infrastructure and removes a lot of complexity and
> allows for easier indexing/searching.
>
It's doable, but I'd like to make sure that I understand what you mean
by "within corporate infrastructure?" Do you mean the client plugin
sends requests to the server to decrypt and verify received messages?
This is definitely a trade-off between key security and performance. But
I don't see any obvious benefits given that the user's computer that
runs the client plugin also belongs to corporate infrastructure. If the
user's computer is compromised, then the administrator simply clean up
the computer and re-install or re-initialize user's email client, which
includes the client plugin.

In my design, each end user does not have a permanent identity like in
OpenPGP where he needs to accumulate his reputation for
"trustworthiness." The only authority is the organization's root key.
Among other things, a user's key is simply a way of declaring that the
email message is authorized by the user who has been certified by the
organization's root key. In this situation, a user's key is not more
important than his email account.

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/04/2018 10:21 PM, Lou Wynn wrote:
> After a client plugin logs in successfully, the server sends the user's
> encrypted email key to the client.

Aren't you better off with a gateway solution like PGP Universal /
Symantec Encryption Server (or for that matter if GPGRelay is still
alive) ? That never exposes key material to client, i.e always operates
within corporate infrastructure and removes a lot of complexity and
allows for easier indexing/searching.

-- 

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

"Leadership is a potent combination of strategy and character. But if
you must be without one, be without the strategy."
(Norman Schwarzkopf)



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 12:25 AM, Andrew Gallagher wrote:
>> On 4 Jan 2018, at 04:42, Lou Wynn  wrote:
>>
>> It has a client key and uses it to log into the server, which is
>> similar to SSH key authentication, to retrieve the private key after
>> authentication.
> This bit confuses me. If you already store a private key locally, why use it 
> to download a second private key? If you’re using a key escrow system then 
> surely you just need to upload the private key once and keep a local copy?
>
> A
There is no key escrow in my design because a user's private key should
not be accessible to anyone else including the administrator. For an
organization, granting the administrator too much, unnecessary privilege
is dangerous especially when he leaves.

Let me try to explain it in another way. Each end user has an email key.
When she uses multiple email clients, each client plugin has a key pair
serving as the identity of the client plugin. The client plugin
registers itself on the server with its public key when the client
plugin is installed or initialized. This key belongs to the plugin and
is used for the plugin to log into the server. The administrator and/or
the end user can monitor how many client plugins the user uses. The
administrator may disable the login of a particular client plugin if it
is compromised such as an employee loses his computer.

In addition, the administrator may optionally set up a policy that
requires the user to choose a login password except for the public-key
authentication of the client plugin.

After a client plugin logs in successfully, the server sends the user's
encrypted email key to the client.

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

[Ben McGinnes]

On Thu, Jan 04, 2018 at 12:40:59AM +, MFPA wrote:
> 
> For example, my ISP [0] says "All staff keys are signed using the
> company signing key. This is very much like a traditional company
> seal. Only the director has access to this key and it is only used
> for signing other keys. If/when a member of staff leaves a
> revocation is issued of that signature and loaded on to keyservers."
>
> [0] 

Cute, but they're fast approaching the point where anyone with a
decent beowolf cluster and an axe to grind could mess with that 1K
certification key they're using there.  Perhaps one of their loyal
customers with extensive experience in weird edge cases of PGP and GPG
use could smack them upside of the proverbial head with a
clue-by-four.  ;)


Regards,
Ben


signature.asc
Description: 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/04/2018 02:34 AM, Lou Wynn wrote:
> No, there is no business unit level certifying key. An enterprise only
> has one root key, which is the ultimate certificate authority for its
> own employees and business partners.

I normally recommend separating those, as the value for external parties
that might want to trust this CA for certifying employees but not other
third parties.

As for access to private key material, I normally recommend that the end
user never has access to any secret key material, but only access to
using subkeys (never the primary) using smartcard tokens.

Wrt your other discussion of ssh based scheme, an alternative for escrow
is actually using gnupg 2.1's gpg-agent through SSH socket forwarding so
key material never is available locally, a system could theoretically be
set up in a restricted setup so user doesn't actually get access to the
key material (but it would require some setup to ensure they don't have
it, so smartcard is generally easier)

-- 

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

Carpe noctem
Seize the night



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 4 Jan 2018, at 04:42, Lou Wynn  wrote:
> 
> It has a client key and uses it to log into the server, which is
> similar to SSH key authentication, to retrieve the private key after
> authentication.

This bit confuses me. If you already store a private key locally, why use it to 
download a second private key? If you’re using a key escrow system then surely 
you just need to upload the private key once and keep a local copy?

A

___
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/03/2018 04:40 PM, MFPA wrote:
>> It is already the case that an organisation does not need to depend on
>> third-party CAs to certify its staff's OpenPGP keys.
>>

It's true for OpenPGP because OpenPGP is a distributed system, there is
no single CA, or it doesn't have the concept of CA at all. My original
implicit reference is PKI based S/MIME.

The autonomous certificate authority model is different from both PKI
and web of trust. As I explained in one of my previous posts that this
model clearly defines what trustworthiness is. The short version is:

A trusted key or trustworthiness means that the sender's certificate is
verified to be in the same trust realm or in the same trust group with
the receiver, besides traditional signature verification.

In this model, end users are freed from managing trust relationship
completely because the trustworthiness can be checked mechanically and
it makes sense to organizational usages.

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

[MFPA]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi


On Thursday 4 January 2018 at 1:46:55 AM, in
, Lou Wynn wrote:-


> When I said for "both," I might have misunderstood what you meant by
> a shared keyring? Can you explain it a little bit? 

PGP and GnuPG traditionally store private keys in a secret keyring and
public keys in a public keyring. Each user's secret keyring has just
their own secret keys. Each user's public keyring contains their own
public keys, plus other people's public keys for encrypting messages
or checking signatures. Multiple users' OpenPGP installations could
theoretically all be configured to point to the same shared keyring
files instead of each user having their own local keyring files (or
all their local keyring files could be kept in sync with a central
copy).



> My system doesn't
> share anything that is related to user private keys, except for that
> encrypted private keys are saved in a database. 

If the user's OpenPGP software accesses that database each time it
needs to use the private key, the database is providing the same
function as the old secret keyring.



> An analogy is
> placing two people's encrypted PGP secret keyring on a file server,
> and decryption is still done at the client side. I'm not sure if
> this is what you meant by a shared keyring.

If my keyring and your keyring happened to be stored on the same
server but they were separate and there was no sharing or syncing
between them, it would not be a shared keyring.


- -- 
Best regards

MFPA  

Is it bad luck to be superstitious?
-BEGIN PGP SIGNATURE-

iNUEARYKAH0WIQSWDIYo1ZL/jN6LsL/g4t7h1sju+gUCWk2TLV8UgAAuAChp
c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0OTYw
Qzg2MjhENTkyRkY4Q0RFOEJCMEJGRTBFMkRFRTFENkM4RUVGQQAKCRDg4t7h1sju
+scSAP4vmeuwK8YCAyYjs4Psorv96r7m3oxgzLu7sJKF96yXTQEAgAjsz8M6S03n
8sLlKoRB8wlcCmjzECrzjtTytkNsfwSJApMEAQEKAH0WIQRSX6konxd5jbM7JygT
DfUWES/A/wUCWk2TP18UgAAuAChpc3N1ZXItZnByQG5vdGF0aW9ucy5vcGVu
cGdwLmZpZnRoaG9yc2VtYW4ubmV0NTI1RkE5Mjg5RjE3Nzk4REIzM0IyNzI4MTMw
REY1MTYxMTJGQzBGRgAKCRATDfUWES/A/5DkD/9BrPANt1BW46XokjuD/kcjuJxQ
F24osueo+o/Cu/+oRnXVExm8dj1zSmr5FH5WUPxejCHORzVxEZjeKAQaLOUoxNjr
hpWvJckeYi7O/+Iv7Mcvj5T88qawtebB/R8RseXak68ZIag6eFG9aMa6qIV75Jvq
60AFLEmZwOOtAoUxfwaIAgLqUc2ER2IYtdiUQX31xsNUrG60nIrWHl77mu7x31L3
FJm1t8wCI6WCKWHCygThkxFburohGIHhsC8z2MEfaN0/e/zy/ZNccC4pfhMOcAWR
1ArFEkRkluMVlkFPItPuwmSDINR3UltTyi77CQ0hYpceleJ47p2n+auYNnSS6Q+D
pIh1q4nMlVCG0TgUI98lKn4JcklHfiu7HGJhFgik+tvC+2TJ+U1NZtVWqZCsr+cA
YePtEyB8Pe82iu7SL3RF5AjtCJa4aS9DQjZixKwxe6WaOfVrcgd+Ne2z6nYX9vto
uSRmir5f5yVhP849AyZ5q31OLPJ8GsvyLF4hyBe1Of6SxhVnlggSZJaJg3/Z31Zr
/2J0U85bk8KyKtWbGn+t1KgrDt1N/u5ExuEkE3PU/5phip3gEHFymB8qqOrBCUAQ
cMcp9W5hI0LAGwGJJ8vKAieoIEQvyIG6d70i/Q1C6+ktNzJSlOfvIUJMFDnXdhAM
4x3CgH8LC0MuJEMRfQ==
=Ol4C
-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

[Lou Wynn]

On 01/03/2018 05:34 PM, Lou Wynn wrote:
>> Are you talking about something like a shared keyring? Or just　managing 
>> trust relationships by issuing key certifications and
>> revocations?
> The short answer is for both. End users do not need to manage their

When I said for "both," I might have misunderstood what you meant by a
shared keyring? Can you explain it a little bit? My system doesn't share
anything that is related to user private keys, except for that encrypted
private keys are saved in a database. An analogy is placing two people's
encrypted PGP secret keyring on a file server, and decryption is still
done at the client side. I'm not sure if this is what you meant by a
shared keyring.

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

[MFPA]

Hi


On Wednesday 3 January 2018 at 7:02:08 AM, in
, Lou Wynn wrote:-



> 1. Goals of the system

> a. An organization does not depend on third-party certificate
> authorities.

It is already the case that an organisation does not need to depend on
third-party CAs to certify its staff's OpenPGP keys.

For example, my ISP [0] says "All staff keys are signed using the
company signing key. This is very much like a traditional company
seal. Only the director has access to this key and it is only used for
signing other keys. If/when a member of staff leaves a revocation is
issued of that signature and loaded on to keyservers."



> b. Its employees and business partners do not manually manage their
> own keys and trust relationship, and the administrator centrally
> manages all certificates and trustworthiness for the organization.

Are you talking about something like a shared keyring? Or just
managing trust relationships by issuing key certifications and
revocations?



> c. Business units can flexibly define trust boundaries. For example,
> the security department can have some black hats as business
> partners but these black hats should be not be trusted by other
> employees of the organization.

Would the business unit achieve this by using their own certifying
key in addition to the enterprise-wide certifying key?



> d. Providing end-to-end security with public key ciphers. An end
> user's private key should not be exposed to anyone, namely, only the
> end user has access to his or her private key to ensure valid
> signature and decryption.

So each user would still generate their own key pair.



> When keys of business partners are certified by the CK, the above
> two design principles place the employees and business partners in
> the same trust realm and therefore trust each other, but not between
> two business partners because two business partners are not in the
> same trust realm.

Isn't it up to the two business partners to decide whether or not to
trust each others' keys?

Whether or not the business partners choose
to consider the presence of the certification from the company's
RK/CKs when making their respective decisions, isn't it ultimately not
really any of the company's business?


[0] 



-- 
Best regards

MFPA  

Zorba the Greek - before he zorbas you

pgpHAtU4iJ2jN.pgp
Description: 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

[Lou Wynn]

I just realized that I overloaded the meaning of signature verification.
Here, signature verification, both in my previous discussion and in the
receiver's UI, also includes the certificate verification described in
2.b, in addition to traditional signature verification.

Thanks,
Lou

On 01/03/2018 01:04 PM, Lou Wynn wrote:
> Yes, "trusted" keys do not mean much without contexts. There are few
> contexts to see what trustworthiness means.
>
> 1. From certificate verification point of view, a trusted key means that
> the certificate is verified to be in the same trust realm or in the same
> trust group with the receiver.
>
> 2. From the user interface point of view, a trusted key is reflected by
> marking the sender's signature is verified, and an untrusted key is
> marked by the warning that the signature cannot be verified. An
> automated or manual process can be applied to delete or quarantine
> messages whose signature verification fails. The screenshots on the web
> link show this intuitive UI. Of course, the final decision about what to
> do with such messages is up to the receiver. The warning of signature
> verification makes the receiver aware of the sender status, which is
> either certified to be in the same trust realm/group or not being
> certified as such.
>
> 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

[Lou Wynn]

On 01/03/2018 11:21 AM, Daniel Kahn Gillmor wrote:
> Hi Lou--
>
> On Tue 2018-01-02 23:02:08 -0800, Lou Wynn wrote:
>> b. Its employees and business partners do not manually manage their own
>> keys and trust relationship, and the administrator centrally manages all
>> certificates and trustworthiness for the organization.
> backing up a bit here -- what kind of "trustworthiness" are you talking
> about in your proposal?  your description includes several uses of the
> word "trust", but no clear explanation of what that trust entails.
>
> saying that keys are "trusted" doesn't mean much on its own.  What is a
> "trusted" key allowed to do that an "untrusted" key is not allowed to
> do?
>
> --dkg

Yes, "trusted" keys do not mean much without contexts. There are few
contexts to see what trustworthiness means.

1. From certificate verification point of view, a trusted key means that
the certificate is verified to be in the same trust realm or in the same
trust group with the receiver.

2. From the user interface point of view, a trusted key is reflected by
marking the sender's signature is verified, and an untrusted key is
marked by the warning that the signature cannot be verified. An
automated or manual process can be applied to delete or quarantine
messages whose signature verification fails. The screenshots on the web
link show this intuitive UI. Of course, the final decision about what to
do with such messages is up to the receiver. The warning of signature
verification makes the receiver aware of the sender status, which is
either certified to be in the same trust realm/group or not being
certified as such.

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

[Daniel Kahn Gillmor]

Hi Lou--

On Tue 2018-01-02 23:02:08 -0800, Lou Wynn wrote:
> b. Its employees and business partners do not manually manage their own
> keys and trust relationship, and the administrator centrally manages all
> certificates and trustworthiness for the organization.

backing up a bit here -- what kind of "trustworthiness" are you talking
about in your proposal?  your description includes several uses of the
word "trust", but no clear explanation of what that trust entails.

saying that keys are "trusted" doesn't mean much on its own.  What is a
"trusted" key allowed to do that an "untrusted" key is not allowed to
do?

--dkg


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