[Help-gnutls] Re: OpenPGP certificate verification for TLS connections
ludovic.courtes at laas.fr
Mon Apr 16 14:03:43 CEST 2007
Rupert Kittinger-Sereinig <rks at mur.at> writes:
> From a design point of view, I think it would be a good decision to
> keep user identity and user privilege management separated. OpenPGP
> can be used for the first task, but the second task is probably very
> domain specific.
Agreed. FWIW, I use OpenPGP-based authentication in a peer-to-peer-like
application. Here, OpenPGP public keys serve as a means to identify
peers---the user ID packet of each key is not used for identifying
purposes. "Authorization" in a p2p system is "sloppy". The exact
authorization decision-making process can be quite complex, involving a
lot of different criteria: did I already meet the peer with key
"1234abcd" earlier? How much resources did it contribute to me or to
the service? How much trustworthy do I consider it? Etc.
So, clearly, in this context, authorization is very
This is of course way different from more centralized scenarios, like,
say, the archival service in a company. In such scenarios, X.509 might
prove to be more convenient than OpenPGP, I dunno.
> One example: a secure messaging service could have millions of
> users. A gnupg keyring of this size may be a bit problematic, but a
> database should handle this easily. To validate a client connection in
> this scenario, we would need to:
> - check for a trusted signature (including expiry and revocation), we
> can keep this as simple as checking for one trusted key if we want.
What do you mean by "trusted signature"? Something like an
"authorization certificate" signed by a "trusted authority" (see my
> - now that we know the ID is authentic, we can look it up in the
> database and decide what the client is allowed to do.
> As for he content of ids, I agree with Daniel: using URIs seems the
> logical choice to me, at least for servers.
Why? How does this derive from the authorization scheme you just
More information about the Gnutls-help