Re: Adding Kerberos use-case

kerberos depends on that the time is correct in client and server both.
my concern is
any vulnerabilities can be exposed because of different time between
browser and server.

regards
mountie

On Wed, Nov 7, 2012 at 7:21 AM, Ryan Sleevi <sleevi@google.com> wrote:

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


-- 
Mountie Lee

PayGate
CTO, CISSP
Tel : +82 2 2140 2700
E-Mail : mountie@paygate.net

=======================================
PayGate Inc.
THE STANDARD FOR ONLINE PAYMENT
for Korea, Japan, China, and the World