Modernizing Web-of-trust for Organizations

[Lou Wynn]

Hi MFPA,

On 01/03/2018 04:40 PM, MFPA wrote:
> Hi
>
>> 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?
The short answer is for both. End users do not need to manage their
keys, both private and public; nor do they need to trust the company key
as described in your reference "It is up to you if you wish to trust the
company key to sign others, but we recommend you trust it to sign any
@aa.net.uk or @aaisp.net.uk email addresses on keys".

Your first comment above mentioned no 3rd-party CA is needed for PGP
users, but the reference still requires users to manage their trust. In
my opinion, PGP has an unnecessarily complicated trust management
recommendation: the web of trust, when used in an enterprise
environment. My goal is to simplify user-side trust management work to
zero, and the result is the concept of trust realm and trust group. They
are explicitly validated by certificate verification which is carried
out together with the signature verification when a message is received.

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.

>> c. Business units can flexibly define trust boundaries. For example,
> Would the business unit achieve this by using their own certifying
> key in addition to the enterprise-wide certifying key?
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.
>> 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.
That is correct technically. A goal here is to make this process as
transparent to users. As I mentioned above, the only operation for a
user to do with key management is choosing a user own password to
protect the private key.
>> 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?
Totally agree, I've designed the trust realm and the group to establish
trustworthiness between employees and their immediate business partners,
not among partners.
> 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] <http://aa.net.uk/contact-pgp.html>
>

Thanks,
Lou