<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p><font size="+1">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.<br>
<br>
1. Goals of the system</font></p>
<p><font size="+1">a. An organization does not depend on third-party
certificate authorities.<br>
</font></p>
<p><font size="+1">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.<br>
</font></p>
<p><font size="+1">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.<br>
</font></p>
<p><font size="+1">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.<br>
</font></p>
<p><font size="+1">e. Support auditing of encrypted messages.<br>
<br>
2. Current system design<br>
<br>
After building a prototype based on PGP, I'd like to share the
parts that are closely related to, or dramatically different
from, PGP.<br>
<br>
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.<br>
<br>
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. <br>
<br>
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.<br>
<br>
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. <br>
<br>
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.<br>
<br>
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.<br>
<br>
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 <a class="moz-txt-link-freetext" href="http://www.secregen.com">http://www.secregen.com</a>.<br>
<br>
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.<br>
</font><br>
</p>
<pre class="moz-signature" cols="72">--
Thanks,
Lou
</pre>
</body>
</html>