Re: ASN.1 Encoding/Decoding Compatability

On Dec 3, 2015 8:04 PM, "Harry Halpin" <hhalpin@w3.org> wrote:
>

> I was hoping the rest of the browser vendors would respond
> enthusiastically, and fixing key exchange between browsers is important.
> However, given I haven't seen a response, I'm worried that this bug may
> take a while to fix. It's not a bug in how the spec is written (the spec
> is correct), it's a bug in underlying key libraries.

No, that's not correct. The bug is either spec or implementation - the key
libraries are just an implementation detail, and from the POV of that
particular key library, it is entirely conforming to its spec.

>
>  Could one proposed solution simply be to *call* this bug out in the
> spec and say that the currently for cross-browser support JWK is
> recommended, and other key formats may not be interoperable?
>

No, that's just Option 3 by a different name - it's giving up and not
really a spec at that point.

> Since it may take some time, perhaps months (hopefully not years) to fix
> this issue, we could put non-JWK key compatibility as part of the
> 'maintenance mode' of the charter - and thus able to trigger a new
> CR/Rec of WebCrypto when fixed.
>

That's just Option 2 in another name.

>    cheers,
>       harry
>
> >
> > 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.
>