Hello, Helge. Any default should be cautiously placed at the appropriate abstraction level.
In this particular case, the defaults are the responsibility of the layer, which knows it is working with JavaCard 2.2.2/3.0.1. Looks like NSS is not that one. Let assume NSS applies the defaults below. Let some NSS client mistakenly calls it w/o parameters and crypto-token is not JavaCard. The call must fail, but instead NSS will hide error and silently fool the client by applying unintended defaults. And, as Hanno suggested, different application may have different opinions about what is a reasonable default. Keep well, Konstantin. On 15.04.11 19:04, Helge Bragstad wrote:
Thank you for your feedback on this, and Konstantin for the feedback on EC. When it comes to implementing support for OAEP and PSS in smart cards, a major part of implementations will be based on JavaCard. In this case, the additional parameters can not all be assigned, and so some default values apply. It could save many some trouble if Mozilla, when taking these padding schemas into use would restrict itself to the same sub-set of parameters. As far as I can see, these are for JavaCard 2.2.2: OAEP not mentioning parameters, so these defaults should apply: * Hash function being SHA-1 * MGF using MGF1 with SHA-1 * Not assign any shared label PSS: * MGF using MGF1 with same hash function as the one used to hash the data * Use salt length corresponding to the length of the hash function. JavaCard 3.0.1 does allow setting salt length, but if not set, the value above is the default. Any particular reason not to use this value? The most troublesome is perhaps to be constrained to SHA-1 for OAEP. Regards, - Helge
-- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
