Subject: RE: Is there a capability RFC?

From: "Roland H. Alden" <[email-masked]>
Date: Tue, 10 Jul 2001 09:51:36 -0700

> Can you define "capability" better, please? I don't follow 
> what you want it for.

Capabilities are one of the seminal building blocks of computer science,
dating back to the Cambridge Ring and Multics, if not even earlier. 

A capability is a hard-to-forge/tamperproof "pointer like" "token" which
provides the bearer with a certain set of rights ("capabilities") over a
resource. Some pioneering hardware architectures, like the Symbolics Lisp
Machine and Intel 432 actually gave memory pointers capability-like
characteristics (like read or execute only) and made them tamperproof and
unforgeable through hardware. The Cambridge Ring had a distributed file
system addressed by capabilities that were tamper resistant through early
cryptographic means (randomness). 

Capabilities can be interesting in certain security architectures because
they combine an access path with implicit (bearer) permission, and since
they offer indirection they can be revoked and expired. With today's
cryptographic science it is relatively easy to implement secure capabilities
in software and the application space of capabilities is certainly
wide/varied and interesting.

---

From: "Mark S. Miller" <[email-masked]>
Date: Tue, 10 Jul 2001 16:18:59 -0700

[Apologies to those who get this twice.  I'm sending it again because of a 
problem at [email-masked] that should now be cleared up.  I'm keeping 
the rest of you on the addressee list so that replies to this resent message 
will still go to the right places.  --MarkM]

At 06:55 PM Monday 7/9/01, David L. Nicol wrote:
>[...] it occurs to me that a Standard Capability Protocol [...]

The rest of you message shows that you're not thinking of a protocol, but 
rather a standard representation for distributed capabilities that can be 
carried or stored in conventional non-capability media.  Let's call this an 
off-line capability representation.

For off-line capabilities in support of off-line protocols, start with SPKI:

* SPKI http://www.ietf.org/rfc/rfc2693.txt is approximately a capability 
system, as explained at 
http://www.erights.org/elib/capability/ode/ode-pki.html .  It fall short of 
being a capability system in the ways explained at http://www.capcert.org/ , 
especially http://www.eros-os.org/pipermail/e-lang/2000-October/003886.html .
HP's E-Speak system started as a capability system (actually, a "split 
capability" system, an interesting variant).  But starting with E-Speak 3.0, 
they are using SPKI certificates as if there are capabilities.

* If you're looking for a SPKI-like system, but not broken, keep your eye on 
http://www.capcert.org/ .  But don't expect to see anything happen there for 
at least a year.

For off-line capability representations in support of on-line capability 
protocols, there are two.

* Take a look at E's "cap://..." URI string.  E ( http://www.erights.org/ ) is 
already a very well functioning prototype or better, and should be ready for 
production use within a year.  The corresponding on-line protocol it 
supports is Pluribus 
http://www.erights.org/elib/capability/ode/ode-protocol.html , 
http://www.erights.org/elib/distrib/vattp/index.html , and 
http://www.erights.org/elib/distrib/captp/index.html .

* Waterken ( http://www.waterken.com/ ) has a very clever way to encode 
essentially the same information as E's "cap:.." URI into an "https:.." 
string, and then to layer their protocol on top of https.  It looks solid to 
me, and all the critical parts are open sourced.

        Cheers,
        --MarkM

---

From: Al Gilman <[email-masked]>
Date: Wed, 11 Jul 2001 12:33:05 -0400

[Copy for info.  Re-sent because of antiSpam provisions on ietf-calendar.  Has
been sent earlier to John Stracke <[email-masked]>, [email-masked]. 
Primarily addressed to the last group.  If you wish to comment on these ideas
you may wish to include them in your distribution. -Al] 

It is possible that capability advocates will find a more receptive
audience in
the Global Grid Forum Security Working Group.

<http://www.gridforum.org/>http://www.gridforum.org

As I have indicated earlier, here is a community that knows it has a
problem of
restricted delegation, which I have at least once suggested to them should be
viewed as a matter of communicable categorized authorization.  Smells
something
like a capability?

The excuse for the fact that the Grid Forum isn't just an anonymous cluster of
IETF Working Groups is to achieve focus on some domains of metacomputing and
create a climate that is a notch more open to risk taking and innovation,
while
still targeting universal standardization as the end state of practice.  One
view is that it can serve as a lab in which to prepare technologies for IETF
consideration.  So consider it as an alternative to either MIME or CalSch as
your stepping stone and you may discover a path to daylight.

No guarantees.  I am a lurker there as here.  But from afar, it looks like a
possible fit.

Al

At 10:49 AM 2001-07-11 , John Stracke wrote:
>"David L. Nicol" wrote, on a separate list but CC:ed to me:
>
>> John Stracke wrote:
>> >
>> > "David L. Nicol" wrote:
>> >
>> > > it occurs to me
>> > > that a Standard Capability Protocol (capabilities are 1024 bits long,
>> > > they include time-stamps and encooded origin info in a standard way,
>> >
>> > Can you define "capability" better, please? I don't follow what you want
it
>> > for.
>>
>> "capability" is a robust method for delegating (and rescinding, and
>> tracking)
>> authority or all kinds.
>>
>> Not Authenticity, but Authority.
>>
>> X session cookies are a good example.  Another is the random codes that
>> prevent
>> fake mailing list subscriptions.  CGI session cookies too -- they are
>> random
>> strings of characters that give one the capability to use a particular
>> shopping
>> cart object.
>>
>> If iCal (or MIME, for that matter) had a standard CAPABILIT[Y|IES]: header
>> built
>> into it, I, as an operator of a calendar, could ask my calendar for some
>> posting
>> capabilities which would expire at the end of the year, and distribute
>> these
>> capabilities (they would look like PGP signatures -- you know, binary
>> garbage)
>> to the people who are authorized to list events on the calendar, and they
>> would
>> use capability-aware tools to submit the items to the calendar, which would
>> include the capability, associated with the event they are sending in, and
>> the
>> calendar would check the capability, and if it is good, go ahead and list
>> the event, and if it is not, the calendar would pass it on for moderating.
>>
>> I believe this is desired functionality which is not currently addressed by
>> the standard, in fact it is explicitly delegated to the implementors.
>
>And for good reason: the IETF generally avoids trying to do things that don't
>have wide experience yet; it makes for working groups that trail off into
death
>spirals.
>
>Implementers of the various iCalendar protocols can experiment with
capabilities
>on their own; if they turn out to be useful, then they can be standardized.
>
>> Capabilities could become a framework for authorization interoperability.
>>
>> I am not suggesting that any of the flexiblity in designing arbitrarily
>> complex authorization systems be taken from the implementors; I am merely
>> suggesting that specifying a place for such information to go, if it is
>> used in an implementation, would ease interoperability.
>>
>> Since a general purpose authority delegation scheme is larger than
>> calendaring
>> (standardizing VERPs comes to mind as another possibility -- a VAriable
>> Envelope
>> Return Path could be considered as a Capability that allows a MTA,
>> "exercising
>> it" by bouncing a mail to the address, to unambiguously report a problem
>> with
>> a particular address) I think an RFC on incorporating them into MIME, which
>> would then get inherited by all projects that rely on MIME, would be a
>> better
>> solution than including them in the iCalendar project.
>>
>> Including them in the iCalendar project, and expecting them to get
>> back-ported
>> into MIME, makes sense too.
>>
>> --
>>                                            David Nicol 816.235.1187
>>                    "Perl was born in downtown Hell!" -- Matt Youell
>
>--
>/================================================================\
>|John Stracke    | <http://www.ecal.com/>http://www.ecal.com |My opinions are
my own.  |
>|Chief Scientist |===============================================|
>|eCal Corp.      |We want forty million helicopters and a dollar!|
>[email-masked]|--"Dinosaurs"                                  |
>\================================================================/
>
>
>
>_______________________________________________
>cap-talk mailing list
>[email-masked]
><http://www.eros-os.org/mailman/listinfo/cap-talk>http://www.eros-os.org/m
ailman/listinfo/cap-talk

---

From: [email-masked]
Date: Wed, 11 Jul 2001 12:04:38 -0500

David:

The semantics that you are referring to as AUTHORITY has other meanings and
is implemented differently in many of the calendaring and scheduling
systems. For example, it can be implemented as a DELEGATION OF OWNERSHIP for
the calendar. I delegate ownership for viewing my calendar, scheduling
/responding to/rescheduling/cancelling events and tasks, as well other
capabilities to my administrative assistant. This I do, not in a particular
transfer of a scheduling method but out-of-band within the calendaring
system. You have thought of another method for providing some subset of
these capabilities, but with a different paradigm for action. There is no
current accepted-practice for this, as such as John indicated, there is no
common basis for standardization.

Of course, this wouldn't stop the IETF from specifying a standard method for
some of these capabilities ;-)

-- Frank