RE: ASN.1 Encoding/Decoding Compatability

Ryan, Olivier, Richard, Michael,
I can only encourage you to progress on that incompatibility issue and see which of the option below better suit your implementations.
As chair my favorite choice goes for option 1 or 2.
We really need to come across that problem and move on towards PR (or go back to WD in case of substantial changes).
Do you want that we set up a call so that we all discuss that  ?
Thanks for your reactivity.
Regards,
Virginie


-----Original Message-----
From: Ryan Sleevi [mailto:sleevi@google.com]
Sent: mercredi 2 décembre 2015 04:33
To: public-webcrypto@w3.org
Cc: Richard Barnes; Oliver Hunt; Michael Jones
Subject: 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?

________________________________
 This message and any attachments are intended solely for the addressees and may contain confidential information. Any unauthorized use or disclosure, either whole or partial, is prohibited.
E-mails are susceptible to alteration. Our company shall not be liable for the message if altered, changed or falsified. If you are not the intended recipient of this message, please delete it and notify the sender.
Although all reasonable efforts have been made to keep this transmission free from viruses, the sender will not be liable for damages caused by a transmitted virus.

Received on Wednesday, 2 December 2015 17:07:23 UTC