[Help-gnutls] Re: OpenPGP certificate verification for TLS connections

Daniel Kahn Gillmor dkg-debian.org at fifthhorseman.net
Tue Apr 17 20:18:42 CEST 2007

Hash: SHA1

On Tue 2007-04-17 05:27:47 -0400, Ludovic Courtès wrote:

> Rupert Kittinger-Sereinig <rks at mur.at> writes:
>> I mean trusted in the sense of the pgp trustdb. Ideally, every user
>> should be able to configure how he wants to construct his web of
>> trust.
>> E.g. for a server application, the admin could choose a handfull of
>> "user managers" whose keys he would put in the keyring and assign
>> ultimte trust to each one.

Yes, this is the most flexible, distributed variant of PKI that i've
seen offered yet.  It is *exactly* the functionality that we're
missing in the current X.509 architecture.

And that "user managers" don't need to be given ultimate trust.  Your
server authentication policy could be "at least two 'user managers'
must sign off on any given key for a user." Or it could be something
even more complicated.

Note that the OpenPGP web of trust infrastructure allows for clean,
arbitrary authentication policy, configurable by existing tools.  The
authentication question OpenPGP asks is: "to whom does the presented
key really belong?"  The answer it gives is a list of authenticated
User IDs: all User IDs that have been sufficiently validated by the
web of trust.

Given this list of User IDs, the system can now perform arbitrary
*authorization* policy checks: Are any of the presented User IDs
authorized to use the particular service?

Note that the authorization layer is completely agnostic about the
keys.  This is a feature, not a bug!  It means users can have multiple
keys (if each key is signed by the appropriate trusted people), users
can revoke old keys in the case of compromise, keys can expire, and so
on, all without any changes to the server itself or any centralized
control [0].

>> Another example: a user of web services could validate the server
>> key fingerprint, and locally sign them with his own key.
> Nitpick: As mentioned earlier in this thread, signing an OpenPGP
> public key means that "the signer is testifying to his or her belief
> that this public key belongs to the user identified by this user ID"
> [RFC 2440, Section 10.1].  I think this is not what you want here.

i think this is precisely what is needed, actually.  Take as an
existing example, the default form of key/identity matching used in
OpenSSH: the ~/.ssh/known_hosts file.  An entry in that file indicates
that the user trusts that the key is bound to that host (the host
being the agent who controls that key).

We don't want the user to trust the given key for any arbitrary host.
The user is explicitly testifying to the binding between the key and
the host itself, which is exactly what the signature means.

The model where individual agents (whether human or service) have
explicitly-defined authentication policies based on the OpenPGP
web-of-trust, and separate authorization policies based on User ID is
capable of emulating the two dominant forms of PKI in use today.  It
can emulate both:

 a) simple openssh-style point-to-point relationships (each agent only
    trusts themselves to identify other agents, and accepts/signs
    key/UID tuples on a case-by-case basis, and stores appropriate
    UIDs where needed for future authorization), and

 b) X.509 hierarchical models (each agent only trusts a single third
    party to identify other agents.  authorization is handled by an
    external policy layer)

And it opens the door for what i personally really want to see, which
is a universal, distributed trust model.


[0] publication of signatures/revocation certificates to a keyserver
    is semi-centralized, but given that any number of keyservers could
    be used, and there is no requirement that the keyserver be a
    locked-down or centrally-maintained service, the system is still
    quite decentralized.
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8+ <http://mailcrypt.sourceforge.net/>


More information about the Gnutls-help mailing list