RE: ASN.1 Encoding/Decoding Compatability

> -----Original Message-----
> From: Ryan Sleevi [mailto:sleevi@google.com]
> Sent: Tuesday, December 01, 2015 7:33 PM
> To: public-webcrypto@w3.org
> Cc: Richard Barnes <rbarnes@mozilla.com>; Oliver Hunt <oliver@apple.com>;
> Michael Jones <Michael.Jones@microsoft.com>
> 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.

Ryan,

It would be useful to know if the does not conform applies to both spki and pkcs8 or just to one of these.  For Windows, there is support in the OS to deal with public keys that may not be present for private keys.  This is going to potentially be the case for other browsers depending on how they handle certificates.

> 
> 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 20:02:18 UTC