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

On 2014-04-03 23:07, Ryan Sleevi wrote:
> 
> 
> 
> On Thu, Apr 3, 2014 at 1:56 PM, Anders Rundgren <anders.rundgren.net@gmail.com <mailto: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.

Ryan, you made my day!

This makes the WebCrypto extension described in the Mozilla bug report "upwardly compatible" with the existing syntax.

Cheers,
Anders

PS. The Workshop in September will (according to Virginie et al), also unveil a WebCrypto solution for smart cards, PKI etc., but since we haven't seen it yet, I continue as before DS.

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

Received on Friday, 4 April 2014 05:18:18 UTC