Modernizing Web-of-trust for Organizations
lewisurn at gmail.com
Sat Jan 6 00:23:57 CET 2018
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.
More information about the Gnupg-users