RE: Adding Kerberos use-case

On Nov 5, 2012 4:58 PM, "Thomas Hardjono" <hardjono@mit.edu> wrote:
>
>
> Thanks Ryan,
>
> > -----Original Message-----
> > From: Ryan Sleevi [mailto:sleevi@google.com]
> > Sent: Monday, November 05, 2012 2:45 PM
> > To: Thomas Hardjono
> > Cc: public-webcrypto@w3.org; ddahl@mozilla.com; Arun Ranganathan
> > Subject: Re: Adding Kerberos use-case
> >
> > On Mon, Nov 5, 2012 at 11:32 AM, Thomas Hardjono <hardjono@mit.edu>
> > wrote:
> > >
> > > David, Ryan, Folks,
> > >
> > > I was wondering if it is possible to add a use-case to the Web
> > > Cryptography API draft.
> > >
> > > We want to be able to implement the full Kerberos Client in
> > JavaScript
> > > and make use of the crypto APIs. In particular, we would love to
> have
> > > an additional API to handle Kerberos tickets (eg. fetching/storing
> > > tickets from the underlying OS).
> >
> > We definitely want to capture the use case as a possible user of the
> > API.
> > I leave it to Arun (CC'd) to figure out whether the Use Case doc
> being
> > prepared is meant to describe what things should be possible with
> this
> > API in V1, or what things are meant to be possible (in some yet
> > undetermined future version with all features).
>
> Thanks -- I can provide a paragraph of the use-case if that will help.
> >
> > Individually, I think an API for handling Kerberos Tickets would be
> an
> > entirely different API and document, with its own set of use cases
> and
> > supporting work. I think showing how it incorporates with the API
> > proposed is good, and it probably would belong in this group - after
> a
> > re-chartering effort (at least, as I understand our current
> charter).
>
> Sure, this would be one possible avenue.
> Do you think this "Kerberos API" work should be done
> in the W3C or elsewhere? (eg. IETF)

If for JS/WebApps, then W3C is the place to be, and I would suggest that of
WebApps, WebAppSec, and WebCrypto, ours is *probably* where it belongs
(with some degree of rechartering).

If *totally* high-level API, it *might* sit in WebApps.

>
>
> >
> > I would prefer not to spend too much energy discussing how that
> should
> > work until we've got the basic API (the editor/wg draft currently
> > called for in the charter), and then work on iterating and expanding
> > that in future versions and future documents.
>
> Agree, I understand that it is imperative to get the
> basic API agreed upon and  implemented by browser
> vendors (ie. would be a tremendous progress).
>
> I would definitely be interested expanding the API once
> the basic API is done.  I know the current WG charter
> excludes "crypto providers",  but some form of extensibility or
> "layering" of a richer set of APIs would be useful
> (e.g. something akin to a JOSE or CMS level of APIs).
>

We have been calling those high-level APIs, for which there is known and
acknowledged interest in.

The overlap between the two arguably exists in the Key object.

>
> >
> > >
> > > Maybe something that looks like the KeyStorage interface would be
> > > workable.
> >
> > I've proposed removing the KeyStorage API.
>
> Is the KeyStorage API work to be deferred for later,
> or is it completely abandoned?  I'm kind of thinking
> that there is a huge install base of PIV (PIV-I) smartcards
> that could benefit from a KeyStorage API (or similar).
> Then there is also several hundred million PCs out there with TPM
> chips, which (at its dumbest config) becomes a useful place to
> store keys. TPM-signed key pairs may also be useful
> for browsers and servers (SPs).
>
> I can contribute a TPM use-case if you need one :-)
>

I can provide a few myself, and did at our Face to Face. Its not at all
abandoned, but I think whether you are talking kerberos tickets or certs or
some other container, I think we need a key /discovery/ API. Of which I
made then withdrew a proposal for, and think we would want to revisit

We need to address key storage as a primary feature, but I am (currently)
arguing in the group that we do not and *should* not address
pre-provisioned or preexisting (not created by and stored by the site) keys
*yet*.

>
> Thanks.
>
> /thomas/
>
>
>
>
>
>