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

[Ludovic Courtès]

Hi,

Daniel Kahn Gillmor <dkg-debian.org at fifthhorseman.net> writes:

> 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.

[...]

> 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:

"Trusted key list" was just an example.  I did not exclude more
sophisticated approaches, including use of web of trust information.

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

What I did reject, though, is precisely this: making authorization
decisions based on user IDs (which is what the above bullet seem to
imply, IIUC).  This is for obvious reasons: one can put anything in the
user ID packet; if I know you'd grant access to your service provided my
user ID contains the string "example.org", then I'll just add that
string to my user ID.

> 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)

This approach differs from what I understood of the bullet I cited above
in that it does not rely on the user ID packet, AFAIUI.

This looks like a hierarchical authorization model à la X.509: if a
principle is authorized by the authority (i.e., if there exists an
_authorization_ certificate signed by "authority at example.org"), then it
allowed to access the service.  There is nothing in GnuTLS and
draft-ietf-tls-openpgp-keys-11.txt preventing you from implementing such
a policy.

(This assumes that the server has somehow previously established the
authenticity of the binding between the authority and the key that
allegedly belongs to it.)

Also, note that I used the term "authorization certificate".  A
signature packet in an OpenPGP certificate (or "transferable public
key", in RFC 2440 terms) would not do it since the sole meaning of these
signatures is 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].  So you need a specific kind of authorization
certificate in addition to the OpenPGP certificate.

In general, OpenPGP does not attempt to provide an _authorization_
framework.  Thus, one has to "roll their own" authorization scheme atop
OpenPGP-based authentication.

What you proposed above is indeed an authorization scheme.  I believe it
is beyond the scope of OpenPGP and draft-ietf-tls-openpgp-keys-11.txt.
But the cool thing is that while such an authorization scheme can be
implemented on top of OpenPGP, many other schemes can as well be
implemented, including the simple "list of trusted keys".  IMO, this
freedom of choice is also what makes OpenPGP-based authentication
attractive.

Nevertheless, if the hierarchical authorization scheme you proposed
appears to be useful and convenient in a large number of use cases, it
would certainly be worthwhile specifying it or providing an
implementation.

Thanks,
Ludovic.