ASN.1 Encoding/Decoding Compatability

One concern with advancing to PR is that, although we have some degree
of implementation of the underlying cryptographic algorithms, there
still exists a large swath of compatability and compliance issues with
respect to the encoding and decoding of key material.

I'd like to propose that we HOLD on advancing to PR until we can agree
on a plan to resolve this, especially given that some of the options
may break backwards compatability. To put a concrete example on it,
Chrome and Firefox ECDH keys are not exchangable, due to a Chrome spec
issue. Further, Safari doesn't implement the spki/pkcs#8 bits at all,
and Edge doesn't support ECDH, so we fail to meet the necessary number
of minimum implementations for what is arguably a highly-desirable
algorithm!

As presently specified, the WebCrypto spec attempts to be very clear
exactly how the SubjectPublicKeyInfo and PKCS#8 PrivateKeyInfo are
encoded. However, as specified, this presents issues for
interoperability between browsers, but also between other
cryptographic libraries. The Chrome compat issue, for example, is
caused by the underlying BoringSSL library, and it's behaviour in
rejecting that key is consistent with that of all versions of OpenSSL.

Recall that the main reasons for including the ASN.1-based formats was two-fold:
- Support implementations that wished to defer the cryptographic
operations - including the handling of key material - to other
cryptographic libraries (such as those afforded by the operating
system)
- Support implementations that wished to communicate with other,
non-browser cryptographic libraries (e.g. browser to
server-running-OpenSSL)

A third, lesser priority was that the compact, binary encoding was far
more useful for key encapsulation (such as via RSA-OAEP), without
needing to resort to strange JSON hacks like space-padding or larger
key sizes to fit the larger JWK payloads.

Practically speaking, I see several ways to resolve this, and
especially wanted to get feedback from other implementers about
concerns and direction.


Option 1 [aka the current situation]) Require that implementers
(browsers) have ASN.1 encoders/decoders that conform to the spec.

As mentioned above, Safari doesn't support the ASN.1 encoding/decoding at all.
As I understand it, Edge is deferring to CryptoAPI at present, which
means it also does not conform (since CryptoAPI doesn't conform nor
should it necessarily)
Firefox is currently deferring to NSS, which does not conform spec.
Chrome is using BoringSSL, which does not conform to the spec.

So basically, everyone would need to implement DER encoding/decoding
themselves - for these specific types/formats.

On the one hand, it's DER (not BER), and so it's rather 'simple' to do
the right thing, and safely. (Firefox at present has four encoders,
the most recent of which was very quick to write and is the only
correct one :P)

On the other hand, this means handling cryptographic keying material
directly in the browser, and being unable to 'punt' on issues to
another library (BoringSSL, CryptoAPI, CommonCrypto, NSS).

Depending on the implementation strategy for handling JWK,
implementations MAY already be doing this (in part), or they may be
parsing the JWK and handing it to a crypto-library-specific,
encoding-independent structure.


Option 2) Remove support for SPKI and PKCS#8 entirely as KeyFormats.
Force everything as JWK.

This would remove a non-trivial part of the spec, and would certainly
throw out backwards compatability with previous versions of the API
(and previously authored scripts), but would not necessarily be the
end of the world.

Developers would need to write compatability shims if they wished to
deal with SPKI/PKCS#8, such as using asn1.js or the like, much like
they do for more advanced structures (such as X.509 or CMS messages)


Option 3) Reduce the level of detail in the spec, such that it's up to
individual implementations to 'figure out' what the encoding should
be.

To some extent, this is the state of the world in cryptographic
libraries today. For example, OAEP when within an SPKI MUST NOT
include the parameters, but OAEP when used as a key transport MUST
include the parameters. Given that the API is agnostic to the
application developers' intended usage of the public key, these sorts
of compat problems have long existed, and are generally left to
individual protocols to clarify.


I'm not terribly keen on Option 3 - I think leaving it unspecified is
worse for interop. Option 2 is sort of the nuclear option, but I'm not
clear what the positions are of other browsers with respect to Option
1. If Mozilla and Microsoft feel the same as Apple - that is,
SPKI/PKCS#8 is neither a priority nor something desired to be
implemented in the userland - then Option 2 really is our only option.

On the Chrome/Google side, we're happy to go with Option 1, and could
live with Option 2 if we have to, but would prefer not to.

Thoughts?

Received on Wednesday, 2 December 2015 03:34:20 UTC