----- Original Message -----
> From: "Justin Lebar" <justin.le...@gmail.com>
> To: "David Dahl" <dd...@mozilla.com>
> Cc: dev-tech-crypto@lists.mozilla.org
> Sent: Friday, April 20, 2012 2:22:31 AM
> Subject: Re: Feedback on DOMCryptInternalAPI
>
> I don't know if you're at the bikeshedding stage of this API's
> development -- if not, please ignore me and I'll come back later. :)
>
I have been bikeshedding for a months:) The WG will be publishing an updated
draft of the WebAPI soon, so this is helpful feedback.
> ****
>
> > interface CryptoHmac {
>
> Why isn't this CryptoMac? Surely the fact that it's an hmac is an
> implementation detail.
Sure, I don't imagine supporting any other MAC.
>
> ****
>
> It's pretty weird to me that you get a CryptoHmac and a CryptoHash
> via
> a constructor, but you get pk/sign via window.crypto. I'd prefer
> window.crypto.getHash(), window.crypto.getMac(), or something.
>
These were spec'd as constructors, but don't have to be.
We could also return the hash or hmac producing object like: var h =
window.crypto.hash(alg);
> ****
>
> Why is it that I get to stream data to the hash / mac provider, but I
> have to provide all my data upfront in order to encrypt / sign? I'd
> prefer if, for all four cases, we had the option to stream and give
> all the data upfront.
>
> ****
We have talked about a streaming encryption/decryption method. I am not sure if
I see the use case for a streaming signature method.
>
> Can we have a default algorithm for hash / mac like we have a default
> pk / sign? I totally buy the virtue of giving people a choice of
> algorithm, but otoh it's also nice to be able to say "hash this for
> me" without worrying about which algorithm(s) the browser supports.
>
I imagine we might for the WebAPI, however, for this internal API, I think we
should specify it.
David
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
