ISSUE-44 and ISSUE-46

Generally:

In researching these, I went back and read the WebIDL spec on dictionaries,
and discovered that all dictionary entries are in fact optional.
<http://www.w3.org/TR/WebIDL/#idl-dictionaries>

This is something that I don't think the current spec really accounts for,
and might merit being it's own ISSUE.  Comments on 44 and 46 follow.


On ISSUE-44:

If we want to do this, I think it could be done without a huge amount of
effort:
-- Define a string (say, "auto") that can be used as a parameter where an
IV would be
-- In the encrypt() method, instead of calling with resolve() with the
ciphertext, call it with a dictionary containing the algorithm, key, and
ciphertext.
-- (Not technically required, but I would do the same thing with the other
"CryptoOperation" methods for symmetry.)

That seems to me to be a cleaner API, even disregarding auto-generation.
 If you're going to do something with a ciphertext or signature value, you
need to have the algorithm and parameters too.  For example, if you're
going to send the ciphertext to someone, you need to send them the IV as
well, so that they can decrypt it.  If the crypto API doesn't pass this
stuff through, then the JS has to store it elsewhere.

(If there's any concern that the holder of the promise won't be authorized
to have the key/algorithm, you can strip it with one line,
crypto.subtle.encrypt().then(function(result) { return result.ciphertext;
}); )

This is no more complex to implement, since the code that implements the
encryption will need to store the algorithm and IV anyway.



On ISSUE-46:

This one has three parts.
1. Make several fields default to empty ArrayBufferViews
2. Make AesGcmParams.iv non-optional
3. Make AesGcmParams.tagLength non-optional or provide a default

Number (2) has been implemented.

Reviewing the WebIDL spec has given me some pause about this issue. In the
section on dictionaries, there is the following phrase: "On a given
dictionary value, the presence of each dictionary member is optional."  So
in fact, the algorithms in this document need to handle any of the fields
not being present, either by throwing or by providing a default value.  In
the cases highlighted in the issue, it seems much simpler to define default
values in the WebIDL than to specify them in the text.