This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
WebCrypto specifies "pkcs8" and "spki" format identifiers, but says nothing about how importKey and exportKey work for those. Most interestingly, which pics-1 AlgorithmIdentifiers should be supported, and how should they map to WebCrypto identifiers? As an example, it's unclear whether an "rsaEncryption" key may be imported as an RSA-PSS algorithm, or "id-RSASSA-PSS" must be used: id-RSASSA-PSS OBJECT IDENTIFIER ::= { pkcs-1 10 } RSASSA-PSS-params ::= SEQUENCE { hashAlgorithm [0] HashAlgorithm DEFAULT sha1Identifier, maskGenAlgorithm [1] MaskGenAlgorithm DEFAULT mgf1SHA1Identifier, saltLength [2] INTEGER DEFAULT 20, trailerField [3] INTEGER DEFAULT 1 } And when RSASSA-PSS-params are present, note that these include hash algorithm and salt length, which are conceptually not even part of algorithm in WebCrypto (they are passed as RsaSsaParams, which are only provided when using the key for signing or verification).
Agreed that there is an underspecification. This mapping is presumed to be part of the algorithm-specific definitions for importKey (that is, it should be specified as part of https://dvcs.w3.org/hg/webcrypto-api/raw-file/dffe14c6052a/spec/Overview.html#rsa-pss-operations ) However, there is an inaccuracy here. In the case of RSA-PSS, the RsaPssParams is used, not RsaSsaParams. PssParams does contain saltLength & hashAlgorithm fields. The 'intent' is that one can import an SPKI that contains either rsaEncryption - in which case, the exact type of key is dependent on the algorithm field supplied by the caller - or it may contain a more specific form, such id-RSASSA-PSS. The behaviour here is the same as the proposed behaviour for addressing JWK import. That is... rsaEncryption + null Algorithm dictionary = incomplete algorithm, operation fails rsaEncryption + ("RSAES-PKCS1-v1_5" / "RSASSA-PKCS1-v1_5"+RsaSsaParams / "RSA-OAEP"+RsaOaepParams / "RSA-PSS"+RsaPssParams) = complete algorithm, operation succeeds id-RSASSA-PSS + null Algorithm dictionary = complete algorithm, operation succeeds id-RSASSA-PSS + (anything BUT "RSA-PSS") = operation fails id-RSASSA-PSS + ("RSA-PSS" + mismatched parameters) = operation fails id-RSASSA-PSS + ("RSA-PSS" + compatible parameters) = complete and consistent algorithm, operation succeeds That is, it behaves consistent with the proposal for handling JWK usages / kty / extractable attributes and caller-specified parameters.
Thank you, this is very useful information! Sorry for the typo, I meant RsaPssParams indeed. However, importKey takes "None" parameters for all algorithms except for HMAC, so the parameter conflict won't happen during importKey, it will happen during sign or verify operations. Is this what you meant?
(In reply to Alexey Proskuryakov from comment #2) > Thank you, this is very useful information! > > Sorry for the typo, I meant RsaPssParams indeed. > > However, importKey takes "None" parameters for all algorithms except for > HMAC, so the parameter conflict won't happen during importKey, it will > happen during sign or verify operations. Yeah, this is underspecified, and this bug is an excellent one to track that - to make it specified :) importKey takes optional AlgorithmIdentifier, and it needs to be clarified what the expectations are. The expectation is that importKey will specify the behaviour (both the format of the CryptoOperationData keyData for each KeyFormat and the expectations of various AlgorithmIdentifiers) > > Is this what you meant?
I've begun the preliminary work at https://dvcs.w3.org/hg/webcrypto-api/rev/888b28091735 which should provide guidance - although it's non-normative. I'm still writing all the normative parts, but https://dvcs.w3.org/hg/webcrypto-api/rev/a0b7e7c69e69 is meant to show the direction of validation. This also overlaps with https://dvcs.w3.org/hg/webcrypto-api/rev/2fa3494f0179 (which attempts to resolve https://www.w3.org/Bugs/Public/show_bug.cgi?id=22571 ), since when you import a subjectPublicKeyInfo, you want to be able to have the same level of fidelity you had when it was exported - or that JWK provides. TL;DR: The hashAlgorithm for PSS has migrated into the generateKey params (from being a per-operation parameter), and similarly is now introduced for the importKey case, so as to provide a basis for implementing what I described in Comment 1. I'm not closing this out yet, because I still need to normatively specify the algorithm described in Comment 1, but hopefully this should provide a reasonable checkpoint to make sure this "makes sense" on the implementation side.
Note: I believe this has been resolved. The issue raised in the original description has been resolved, and appendices B and C provide some guidance on mappings. eg: Bug 24410 provided the normative text for RSA-PSS, resolved in https://dvcs.w3.org/hg/webcrypto-api/rev/102cf2326e92 Alexey, are you happy with closing this out as fixed?
It definitely appears that the task has been completed, and if there are still any omissions, then separate bugs should be filed. FWIW, I would find it helpful to have informative notes about ignored parameters (such as RSASSA-PSS-params saltLength).