Hi, Daniel Kahn Gillmor <[EMAIL PROTECTED]> writes:
> On Thu 2007-04-12 08:29:36 -0400, Simon Josefsson wrote: > >> [EMAIL PROTECTED] (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. "[EMAIL PROTECTED]"). > > 1) use that key to sign users' keys for the domain, binding them to > "[EMAIL PROTECTED]" 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 > [EMAIL PROTECTED] 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 > [EMAIL PROTECTED] 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 "[EMAIL PROTECTED]"), 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. _______________________________________________ Help-gnutls mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/help-gnutls
