Re: Bug 24774 - fix RSA SSA sample code by moving hash from sign call to generate call

On Thu, Apr 3, 2014 at 1:56 PM, Anders Rundgren <
anders.rundgren.net@gmail.com> wrote:

> Some three months ago I wrote a WebCrypto sample that worked fine in
> Google Canary (test-version of Chrome).
> Suddenly it ceased to work due to an update of Canary.
> This is of course completely OK since the standard is still a moving
> target.
>
> Anyway, I of course wanted to know why it didn't work anymore and
> apparently the API had changed so that generation of an RSA signature key
> also required the intended hash algorithm.
> In addition, the hash algorithm had been removed from the sign method as
> one can see in the draft's sample code:
>
> 20.1. Generate a signing key pair, sign some data
>
> var algorithmKeyGen = {
>   name: "RSASSA-PKCS1-v1_5",
>   // RsaHashedKeyGenParams
>   modulusLength: 2048,
>   publicExponent: new Uint8Array([0x01, 0x00, 0x01]),  // Equivalent to
> 65537
>   hash: {
>     name: "SHA-256",
>   }
> };
>
> var algorithmSign = {
>   name: "RSASSA-PKCS1-v1_5"
> };
>
> Although I assume that the WG doesn't care about my WebCrypto extension
> project
> https://bugzilla.mozilla.org/show_bug.cgi?id=978867
> I would at least "for the record" like to mention that removing the hash
> from the sign function
> complicates the use of the WebCrypto API with "alien" keys which typically
> do not come with
> specific hash algorithms.  The cost for reinstating (and double checking
> for standard WebCrypto
> keys), the hash for sign (and other methods that may be affected by this
> change), ought to be
> reasonable.
>

This is a claim without substantiation, and something already covered in
the spec.

Sorry, you're going to need to be clearer on what you see as "alien keys",
what you see the defect is in Web Crypto, and how you would propose to
resolve this defect.

The spec is clear on how to handle import of various key types, and in
various forms/structures - eg: JWK w/ or w/o an "alg" parameter, PKCS#8
with a variety of AlgorithmIdentifiers. There is no ambiguity on how to
"import" a key and bind it to a specific hash, so there is no need for
sign() to duplicate that.

Equally, for keys where such hash bindings are not as critical (eg: ECDSA),
the ability to supply the hash at sign() time is preserved.


>
> There are of course other ways to achieve the same result but they aren't
> very pretty
> such as setting the algorithm directly on the key object or using default
> algorithms.
>
> Yet another solution is creating a parallel ("similar") API but that seem
> like a really uncool idea.
>
> Thanx,
> Anders
>
>
>