- From: Wan-Teh Chang <wtc@google.com>
- Date: Fri, 22 Jun 2012 16:14:10 -0700
- To: Mike Jones <Michael.Jones@microsoft.com>
- Cc: Ryan Sleevi <sleevi@google.com>, David Dahl <ddahl@mozilla.com>, "public-webcrypto@w3.org" <public-webcrypto@w3.org>
On Wed, Jun 20, 2012 at 1:52 PM, Mike Jones <Michael.Jones@microsoft.com> wrote: > As a data point, the IETF JOSE work intentionally has only algorithm > identifiers and no separate algorithm parameters. Instead, the particular > parameter choices are baked into the identifier. > > So for instance, rather than having a generic RSA signature algorithm and > hash functions as parameters, there are separate algorithm identifiers such > as: > > RS256 - RSA signature using SHA-256 hash algorithm > > RS384 - RSA signature using SHA-384 hash algorithm > > RS512 - RSA signature using SHA-512 hash algorithm I think this is a reasonable approach. This approach is reflected in the OIDs for signature algorithms in ASN.1. For example, PKCS #1 specifies signature algorithm OIDs such as sha1WithRSAEncryption and sha256WithRSAEncryption, and NIST specifies ecdsa-with-SHA256, ecdsa-with-SHA384, etc. PKCS #11 has "combo" signature mechanisms such as CKM_SHA256_RSA_PKCS and CKM_ECDSA_SHA1. (Note: PKCS #11 also has the "sign hash"-style signature mechanisms such as CKM_RSA_PKCS and CKM_DSA, similar to what I describe next.) On the other hand, in Windows CryptoAPI and CNG, a signature is generated by signing a hash that is computed separately. There is a clear separation of the hash component in the sign and verify operations. So they are in line with Ryan Sleevi's proposal :-) In my opinion, the hardest problem with choosing a signature algorithm is which hash algorithm should be used. It turns out the hash algorithm should match the signature key size. So "combo" algorithms such as "RS256" still won't help solve this problem. Wan-Teh
Received on Friday, 22 June 2012 23:14:39 UTC