R: [Cap-Talk] Re: Is there a capability RFC?
Thu, 12 Jul 2001 08:15:39 +0200
----- Original Message -----
From: David L. Nicol <email@example.com>
To: John Stracke <firstname.lastname@example.org>
Cc: <email@example.com>; <firstname.lastname@example.org>
Sent: Wednesday, July 11, 2001 6:23 PM
Subject: [Cap-Talk] Re: Is there a capability RFC?
> John Stracke wrote:
> > Could you expand on how capabilities would let us do away with mutual
> > relationships? It seems to me that a capability actually encodes a
> > trust relationship.
> The overview draft defers encoding of trust relationships to the
> implementations. Providing a standard encoding method for them would
> increase interoperability. "To post to the calendar, use the attached
> key" could be given, without verifying that the CUA that will be used
> uses the same vendor-extended key protocol.
> > > For instance, the "ability to flood a calendar system with bogus
> > > requests" could be greatly mitigated by use of capabilities in the
> > > basic archtecture.
> > How? You still need to examine each request to determine whether it's
> > authenticated.
> a capability could, for instance, be associated with an upper limit
> of number of posts can be made with it. This can be done with user
> accounts as well, certainly, and the complexity is about equal, and
> associating a capability with a user account would be a reasonable way
> to implement the limit.
There could also be one-time capabilities by setting the upper limit to 1
(this sounds "like" Kerberos tickets).
Capabilities could also have a time duration, expressed in lifetime (days,
hours, or whatever) or by an expiry date, and this could be considered as an
automatic revokation mechanism that forces the capabilities to be
invalidated when the duration expires.
> > > If every event is persistently tagged with the
> > > capability under which it was posted, removing (and submitting for
> > > re-moderation) all events posted under a compromised capability
> > > trivial.
> > (a) How is this different from removing events posted by a particular
> > during a particular time range?
> "By a particular user" is more vague, as it doesn't address how we know it
> was them.
> > (b) What about events posted by the legitimate user of the capability?
> "... and submitting for re-moderation"
> Anyway, what about entities that are not individual people? Wedging
> them into "user accounts" is standard practice, yes, but that doesn't
> make it elegant.
> cap-talk mailing list