This is an implementation issue that likely highlights a spec issue, so filing a bug.

The import key steps described in https://dvcs.w3.org/hg/webcrypto-api/raw-file/34df8cbba360/spec/Overview.html for RSASSA-PKCS1-v1_5 seem to conflict with various crypto libraries' implementations, including OpenSSL, BoringSSL, NSS, and (CAPI/CNG).

Namely:
WebCrypto requires that importing an RSASSA-PKCS1-v1_5 key as an SPKI or PKCS#8 key, the implementation must also recognize the oids sha1WithRSAEncryption, sha256WithRSAEncryption, sha384WithRSAEncryption, and sha512WithRSAEncryption.

Problem:
All of the cryptographic libraries reject such keys. They all require that the key be 1.2.840.113549.1.1 (rsaEncryption).

It also seems that the libraries will reject keys with id-RSASSA-PSS and id-RSAES-OAEP, which means that the security considerations from Section 8 of RFC 4055 can't be uniformly followed.

Proposed (Partial) Solution:
Remove the language and only support rsaEncryption for RSASSA-PKCS1_v1_5. This primarily limits the ability of wrapped key providers to explicitly limit the hash algorithm used with a particular key. Provided that the supplied wrapped key has not been previously used with a different hash function (or a different function altogether, such as RSA-PSS or RSA-OAEP), this should be fine.

Open Issue:
What to do for RSA-PSS and RSA-OAEP. Keeping the current language means, effectively, that current UAs will need to manually process the ASN.1 encodings and validate accordingly. This has benefits (correctness / full conformance) and downsides (ASN.1 parsing outside of the crypto library seems a recipe for disaster).