[Bug 27255] New: Inconsistent handling of SPKI / PKCS#8 data between implementations

https://www.w3.org/Bugs/Public/show_bug.cgi?id=27255

            Bug ID: 27255
           Summary: Inconsistent handling of SPKI / PKCS#8 data between
                    implementations
           Product: Web Cryptography
           Version: unspecified
          Hardware: All
                OS: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Web Cryptography API Document
          Assignee: sleevi@google.com
          Reporter: sleevi@google.com
                CC: public-webcrypto@w3.org, rlb@ipv.sx,
                    vijaybh@microsoft.com

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).

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Received on Thursday, 6 November 2014 01:31:00 UTC