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

[Daniel Kahn Gillmor]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wed 2007-04-18 03:34:29 -0400, Ludovic Courtès wrote:

> I think I'm only starting to get your point, sorry for the delay.  ;-)
>
> My understanding of what you're saying it this (where "I" is the
> server):
>
>   1. When I receive a connection from someone, I check the list of
>      signers contained in their public key (or "OpenPGP certificate", or
>      "transferable public key").
>
>   2. If that key is signed by someone I trust, then I can trust the
>      key-user ID binding itself.
>
>   3. _Since_ I trust the key-user ID binding, I can now make
>      authorization decisions based only on the user ID.
>
> And this is why the contents of user ID packets matters: URIs would
> indeed make it easier to implement step (3).  I think I got it.  :-)

Yes, exactly!  Thanks for persevering through my poor explanations.
Servers would have URIs in their User ID packets and humans (and other
clients) would continue to have rfc822 User ID packets, making it easy
for each one to recognize the other.

There's no *need* for servers to use URI User IDs, of course: a web
server at http://example.org/ could just offer a User ID of
"example.org web server <http at example.org>" (or some comparable
kludge).  In fact, they could offer both User ID packets without
trouble.  But there ought to be a convention so that connecting client
knows which User IDs to even bother looking for (or checking
signatures against), given the address she is connecting to.

> That's probably a useful usage pattern.  The problem that I see is
> that it would be non-standard, 

I'm not convinced that using User IDs for authorization is
non-standard.  Look, for example, at the existing model for mutual
key-based authentication for apache2's mod_ssl (which is one of the
things i'm hoping gnutls can provide an alternative to).  mod_ssl is
configured with a list of trusted certificate authorities
(SSLCACertificatePath).  Those authorities are trusted to identify the
clients who connect (assuming SSLVerifyClient is on).  mod_ssl then
exports the client's Distinguished Name (the X.509 equivalent of
OpenPGP's User ID) to the environment in $SSL_CLIENT_S_DN_*, and
alternately treats the user as though they had done HTTP Basic Auth
(SSLOptions +FakeBasicAuth), which leaves it up to an apache authz
module to do authorization.

In short, the client *authenticates* with her certificate, and the
server *authorizes* against her User ID.

The same is true from the other direction: our web browsers don't
store a list of certificates for every web site: they store a list of
certificate authorities, and trust the authorties to sign off on an
attribute of the offered server cert (the SubjectAltName or the CN),
which is then tested against the address of the service we're trying
to connect to.  The signature has to check out, (that is, it should be
properly *authenticated*) but the SubjectAltName also needs to match
the expected hostname for the browser to *authorize* a connection to
it.

> so (getting back to the original topic) it may be beyond the scope
> of GnuTLS.

By analogy with OpenSSL (which contains significant infrastructure for
managing X.509 certificate hierarchy trust), i would suggest that it
is not outside the scope of GnuTLS to implement a well-thought-out
scheme for trust checking when using OpenPGP certificates.

> What would be useful, though, is a set of tools to traverse the
> signer graph (as is required by step (2)).

gnupg contains a very thorough and well-tested trustdb mechanism,
which i was hoping we could rely on.  A standard convention for
matching User IDs with servers seems to be the only piece of the
puzzle that's lacking.

      --dkg
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8+ <http://mailcrypt.sourceforge.net/>

iD8DBQFGJjb+iXTlFKVLY2URAq4lAJ48Fcwu5sVxnbJYSXCIQ4jrnDVPrwCfQdwx
1lWvU655j98EATlgRsy3vtc=
=ve+Y
-----END PGP SIGNATURE-----