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

[Ludovic Courtès]

Hi,

Rupert Kittinger-Sereinig <address@hidden> 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
application-specific.

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
previous post)?

> - 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
sketched?

Thanks,
Ludovic.