Hi, Rupert Kittinger-Sereinig <[EMAIL PROTECTED]> 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. _______________________________________________ Help-gnutls mailing list [email protected] http://lists.gnu.org/mailman/listinfo/help-gnutls
