Re: Adding Kerberos use-case

On Tue, Nov 6, 2012 at 2:11 PM, Thomas Hardjono <hardjono@mit.edu> wrote:
>
> Thanks Ryan & Harry,
>
>> 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.
>
> Thanks Ryan.  Is there a software architecture/model/diagram somewhere
> as the basis for the Web Crypto API work in W3C?  (ie. to help me
> understand where "crypto providers" fit it and where applications
> can make calls).

The Scope section of the Charter provides hopefully the clearest demarcation

- http://www.w3.org/2011/11/webcryptography-charter.html

Our primary features are really where the WG is focused at this point.

>
>
>> Harry:
>> 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.
>
> Thanks Harry.
> +1 agree, getting the basic spec that defines the
> agreed crypto primitives and getting all browsers to support
> the spec is the first step (and a big enough job as it is).
> Will the W3C also issue something like conformance spec/profile
> against which vendors need to show interoperability?
>
> Currently Kerberos uses GSSAPI (RFC4121).  GSSAPI seems to be
> undergoing a rebirth judging by the recent proposed mechanisms
> for GSSAPI in the IETF (e.g. Moonshot; Oauth2.0; Restful non-HTTP).
> It would be interested to see how GSSAPI may work with the new
> WebCrypto API (e.g. can a WebCrypto API implementation call
> GSSAPI mechanisms underneath it).

Individually as an implementor, I would hope not, and while I cannot
make broad commitment in terms of our product, I think there's a whole
host of security issues there. I'm not aware of any interest from our
side in providing protocol-specific APIs to JavaScript (content or
sysapps) at this time,

I think the moment that you start talking about an API for a
particular protocol - whether Kerberos, GSSAPI, TLS, S/MIME, CMS, PGP,
etc - that is meant to be implemented directly by a browser, then
you're almost certainly talking to/about another group, either sysapps
or webapps. But that's just me, individually.

Received on Tuesday, 6 November 2012 22:21:59 UTC