A couple updates to this thread:
1) DOMCrypt seems to be moving along the W3C path. There isn't a
working group set up yet, but there seems to be sufficient interest
that a W3C activity appears to be spinning up around this effort.
2) Ian Fette met with a number of banks in South Korean and
For example, the CryptoHash
interface can be implemented independently of the rest of the API and
provides value by itself.
Moving forward on that part first sounds reasonable. I've been asked about
that specifically by some app developers that really aren't interested in
the other parts of
On Fri, Aug 5, 2011 at 12:09 PM, Michael Nordman micha...@google.com wrote:
For example, the CryptoHash
interface can be implemented independently of the rest of the API and
provides value by itself.
Moving forward on that part first sounds reasonable. I've been asked about
that specifically
Yes, hashing blobs. Here's the last line of the relevant meeting notes...
In the end, we all agreed that the main thing with the highest utility
would be a native hashing implementation that could accept strings, bytes,
or BLOBs.
On Fri, Aug 5, 2011 at 12:32 PM, Adam Barth aba...@webkit.org
Bytes and (likely) blobs are types we're planning to do in DOMCrypt.
Hashing strings is slightly more delicate because you need to pick an
encoding. Do you have a sense, if we did bytes and blobs, would that
be enough, or are strings really important also?
Thanks,
Adam
On Fri, Aug 5, 2011 at
I think bytes and blobs would be sufficient.
+f...@google.com
On Fri, Aug 5, 2011 at 12:58 PM, Adam Barth aba...@webkit.org wrote:
Bytes and (likely) blobs are types we're planning to do in DOMCrypt.
Hashing strings is slightly more delicate because you need to pick an
encoding. Do you have
Hey Adam,
I thought it might make sense to let the user specify a private key file
(e.g. an RSA-key) that is in the browsers KeyChain.
Would that make sense to have it implemented in the DOMCryptAPI?
Otherwise I can't see many use cases, because I think encryption on a high
OSI layer just
My sense is that the Mozilla folks want to start with the simple
building blocks first and then work up to more complicated things like
interacting with OS key stores and smart card readers.
DOMCrypt is also useful for protecting data at rest, which isn't
something you can do with TLS. For
Well, I think that makes sense... But not for me. I have the opinion that
cloud-hosted keys aren't keys anymore - right?
I mean, man-in-the-middle attacks are the 100% use case when it comes to
encryption due to buggy DNS-protocol that can't be updated.
I also think that this is kinda
These sorts of questions are probably better discussed on the whatwg
mailing list (where there is currently a thread about DOMCrypt)
because they're general questions about the use cases and features set
of the API and not about WebKit's implementation (or
non-implementation) of the API.
Thanks
I think we should let the spec mature a bit before diving in.
-Sam
On Jul 26, 2011, at 10:53 PM, Adam Barth wrote:
Hi webkit-dev,
As some of you are probably aware, Mozilla is experimenting with
exposing some basic cryptographic primitives to web applications:
Hi webkit-dev,
As some of you are probably aware, Mozilla is experimenting with
exposing some basic cryptographic primitives to web applications:
https://wiki.mozilla.org/Privacy/Features/DOMCryptAPISpec/Latest
I wanted to get a sense from the WebKit community about how interested
we are in
12 matches
Mail list logo
