27255 2014-11-06 01:30:58 +0000 Inconsistent handling of SPKI / PKCS#8 data between implementations 2016-05-23 22:38:45 +0000 1 1 1 Unclassified Web Cryptography Web Cryptography API Document unspecified All All RESOLVED MOVED P2 normal --- 1 sleevi sleevi mitar.w3 public-webcrypto rlb vijaybh virginie.galindo watsonm oldest_to_newest 114582 0 sleevi 2014-11-06 01:30:58 +0000 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). 126485 1 virginie.galindo 2016-05-23 21:17:28 +0000 This bug has been moved to webcrypto github repository https://github.com/w3c/webcrypto/issues/26