Re: Adding Kerberos use-case

On 11/05/2012 11:45 PM, Ryan Sleevi wrote:
>
>
> On Nov 5, 2012 4:58 PM, "Thomas Hardjono" <hardjono@mit.edu 
> <mailto:hardjono@mit.edu>> wrote:
> >
> >
> > Thanks Ryan,
> >
> > > -----Original Message-----
> > > From: Ryan Sleevi [mailto:sleevi@google.com 
> <mailto:sleevi@google.com>]
> > > Sent: Monday, November 05, 2012 2:45 PM
> > > To: Thomas Hardjono
> > > Cc: public-webcrypto@w3.org <mailto:public-webcrypto@w3.org>; 
> ddahl@mozilla.com <mailto: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 
> <mailto: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 concur. A Kerberos API would be useful, but first we need to get the 
primitives out. I guess what I'm interested in getting at is *what 
precise primitives* that we do not define (encrypt, decrypt, verify, 
sign) in JS would be necessary for someone to write a Kerberos API?

Then you can build it yourself with this API - and if people then need 
to standardize the API itself, that could go on elsewhere.

> >
> >
> > >
> > > 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.
>

Currently, David is working on a JOSE-format "higher-level" API.

> 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*.
>
I think once we get basic capabilities down better, we'll move in this 
direction. We are not pursuing a key discovery API right now, but we may 
deal with "multiple key containers" which could be a smartcard. There is 
also a possible SmartCard API in the SysApps WG you may want to look at.



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