OpenPGP certificate verification for TLS connections [Was: Re: [Help-gnutls] Re: Semantics of `gnutls_openpgp_key_check_hostname ()']

[Daniel Kahn Gillmor]

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

On Thu 2007-04-12 08:29:36 -0400, Simon Josefsson wrote:

> ludovic.courtes at laas.fr (Ludovic Courtès) writes:
>
>> In any case, I believe the user ID packet should just be thought of
>> as a human-readable hint, no more.  You don't make authorization
>> decisions based on what the user ID packet contains, but rather,
>> for instance, based on whether that key is in your list of
>> authorized keys for the purpose at hand.
>
> Hm.  That's true.

I disagree with this, actually.  One of the whole points of any PKI
(web of trust [0], X.509, etc) is that given the proper signatures,
you should be able to accept a previously-unknown key with confidence
that it belongs to the person/service you think it does.

To that end, i think that the "trusted key list" idea should *not* be
used for TLS authentication.  Instead, it should rely on the web of
trust model already provided by OpenPGP, combined with either:

 * a list or matching rule of authorized User IDs (from the
   perspective of a server), or

 * a "match" between the User ID and the service connected to (from
   the perspective of a client)

This model handles key expiration, revocation, and replacement in a
much cleaner way.

For domains that want centralized management (e.g. schools, corps,
etc), this model can also handle exclusion from a domain in a
centralized way.  This is something that X.509 offers, and we'd need
to be able to offer as well, if we want OpenPGP keys to be taken
seriously as a replacement model.

You can do a complete authorization cutoff by:

 0) establish a domain-wide authority OpenPGP key
    (e.g. "authority at example.org").

 1) use that key to sign users' keys for the domain, binding them to
    "username at example.org" with the authority's signature.

 2) establish a domain-internal keyserver, or rely on a public
    keyserver.  (call this keyserver.example.org)

 3) set up all your servers to authenticate clients using OpenPGP
    certificates in the TLS sessions.  For authentication decisions,
    your servers should only trust signatures made by
    authority at example.org.  Tell the servers to check with
    keyserver.example.org frequently (perhaps query for info about
    each key as requests are made?)

 4) When a user is to be excluded from the domain, simply revoke the
    authority at example.org signature, and publish the signature
    revocation to keyserver.example.org (this is the analog to CRLs or
    OCSP for X.509)

Likewise, you could update a server's OpenPGP key using a similar
series of steps, and an end user already enmeshed in the web of trust
could accept the new OpenPGP certificate offered without external
verification.

> The difference here is that you can look at a X.509 certificate and
> tell whether it is intended for use as a server certificate for a
> particular hostname.

Right.  This is a nice feature of X.509.  But why couldn't OpenPGP be
used in the same way?

The majority of User ID fields in existence now are RFC 822 values,
which are often bound to an individual who controls that e-mail
address.

What if we establish a convention that RFC 822 values *do* identify
people (or groups of people) who control a particular e-mail address.

That then frees up the entire range of non-822 strings to identify
other entities.

For example:

 User ID packets that contain only a URL (as defined in RFC 1738) are
 server User ID packets.  Signatures bound to these packets indicate
 that this key is used by the server responding to requests at that
 URL.

If we accept this convention, then:

 0) a domain's secure web server might have a key with User ID
    "https://example.org"

 1) the LDAP server in my previous example would claim
    "ldap://example.org" and/or possibly "ldaps://example.org"
    (depending on whether it was STARTTLS-enabled or TLS-wrapped).
    There's no harm in including both UIDs if both services are
    available.

 2) A mail transfer agent might offer "smtp://example.org" and
    "smtps://example.org" and "submission://example.org"

This proposed convention is probably too simple, and doesn't include
some things which might be nice (such as comments in the UID field in
addition to the URL itself, or an explanation of what
"https://example.org/~foo/" would mean in a UID).

I'd be curious to hear what people on this list think could be added
(or omitted) from this proposal.

> However, the difference between X.509 and OpenPGP is that for X.509,
> it is the CA who signed the server certificate who has to agree that
> the server certificate is responsible for that particular server, so
> the information has to be in the server certificate.  There is no
> similar concept in OpenPGP.

I actually think the OpenPGP signature concept is pretty much
analogous.  If you sign my key in OpenPGP, what you're really signing
is the binding of some particular User ID (or more than one) to the
public key.  If you think of a human as being a service provider for a
service with a given name and e-mail address (which is effectively a
URL for communication with that human), there's not much difference
from an authentication point of view.

> This logic suggests that GnuTLS should not check the hostname
> against the OpenPGP ID packet at all.  All authorization decisions
> should be based on the trusted key list.

I hope what i wrote above explains why i don't think this is a good
idea, but i'd be interested in hearing more arguments in this
direction so i can understand it better.

FWIW, i also don't think that adding a new packet type to OpenPGP is
the way to go.  All existing OpenPGP implementations can already
handle the User ID packet type, and since the RFC doesn't prohibit
non-RFC822 strings, I think we can legitimately propose this as an
extension, as long as we define our UID packets such that they don't
match RFC 822.

This discussion is a really good one.  I look forward to hearing other
proposals, or objections/concerns about the proposal laid out above.

Regards,

        --dkg

[0] http://www.rubin.ch/pgp/weboftrust.en.html
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8+ <http://mailcrypt.sourceforge.net/>

iD8DBQFGHk1giXTlFKVLY2URAmioAKCRQIfEYgySxaAUH0IPK6uP6DFiigCdHT77
CYWX743u+G9TFQPz0lQVCto=
=Dnk7
-----END PGP SIGNATURE-----