Modernizing Web-of-trust for Organizations

[Lou Wynn]

I saw some interests in this mailing list about PGP's certification and
web-of-trust. I've been working on a system for enterprise customers
that dramatically changes how PGP key signing and verification work and
would like to discuss it here to see if someone is interested in it.

1. Goals of the system

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

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.

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.

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.

e. Support auditing of encrypted messages.

2. Current system design

After building a prototype based on PGP, I'd like to share the parts
that are closely related to, or dramatically different from, PGP.

a. The new "autonomous certificate authority" trust model. In this
model, an enterprise has a root key (RK) and a certifying key (CK). The
RK is used to certify the CK, and the CK is used to certify keys of
employees and business partners. Keys that are ultimately certified by
the same RK are "potentially" considered trusted to each other. The RK
represents the only certificate authority of the organization. The RK
can be stored offline, and the CK is online for normal certification
operations for security reasons. If the CK is compromised, then the RK
can be used to revoke it and certify a new CK.

b. Certificate verification. An organization has two types of users:
employees and business partners. Accordingly, the system distinguishes
two type of certificates: employee certificate and partner certificate.
For a communication pair (the receiver and the sender), two keys are
considered in the same trust realm if they are ultimately certified by
the same RK (through the CK chain) and one of the certificate types is
the employee certificate. Keys in the same realm are automatically
considered as trusted to each other.

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.

c. Trust groups. The employees and the administrator share security
responsibility of business partner's certificates. Employees know
business processes and understand which email addresses are business
partners, and the administrator does not have this knowledge. Therefore,
an employee invites an email address as a business partner by using an
automated process that certifies the partner's key. The administrator
can monitor which employee invites which email address as a business
partner.

When the employee invites a business partner, the former can specify or
name a trust group for the latter and optionally add other partners and
employees into the group. When the partner's key is certified by the CK,
the group information is hashed in the certificate. In addition, other
group members' certificates are updated to include the group information
automatically. Now the certificate verification process has an
additional constraint besides belonging to the same trust realm: the two
certificates must share a common group in order to be considered
trusted. However, this constraint is not applied if the two certificates
are both employee certificates. This ensures that two employees always
trust each other, but a business partner can only enter a trust group,
not the realm, that is defined by the group owner which is an employee.
This gives an organization the ability to define trust boundaries
according to its own business needs.

d. Auditing key. An organization also has an auditing key (AK) besides
the RK and CK. When a user certified by the organization sends an
encrypted email, the client plugin automatically encrypts the message
with the AK besides receiver's key. As a result, goals 1.d and 1.e can
be both achieved at the same time with help of other system design. The
administrator only needs to use the AK private key at the auditing
appliance to conduct business auditing or message scans.

3. System components. Since this has less relationship with PGP, I just
mention that the entire system includes four major components: an
organization key management system which runs the CK, the server which
manages all user keys and certificates securely, a web user interface
for the administrator, and a client plugin that performs encryption and
certificate verification. The client plugin is a traditional PGP client
with the above enhancement. I've implemented a chrome extension to demo
a simple end-user interface in Gmail, whose snapshots are available at
http://www.secregen.com.

4. It's worth of mentioning that I've used PGP's notation to hold the
certificate type and trust group information. There is much left unsaid
about the system, especially the management of user keys and
certificates which are critical to zero-configuration on end-user side,
but I would like to say this post is just my first-try to see if there
is enough interest to this new trust model and its application for
enterprise environments. Please feel free to ask questions or make
comments if you're interested in learning more about or discussing the
system.

-- 
Thanks,
Lou

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20180102/360009b8/attachment.html>