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)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20180106/a7ad15ce/attachment.sig>